Tuesday, June 11, 2013

Project Patterns - introduction and two examples

Ok, it took me slightly ;-) more than two weeks to write the next blog entry. Sorry for that.

In this post I talk in more details about my ideas of 'project pattern' and give you some initial examples. 

Just to be clear, we are not talking about the theory of project management or whether or not some project management framework makes sense. I am sure you have an awesome lot of standards, methods or guidelines to follow when running your IT project and do not need any additional ones. 'Project patterns' come into play when the project situations requires decisions or actions that go beyond what you typically do in your daily life as a project manager. In such situations the process frameworks and any other project management toolbox are of limited help only. 

Let’s describe two concrete 'project patterns' that might sound familiar to you. The flashy names are invented just on the spot - so no need to do any web research to gather more information.

Example one, let’s call it the ‘uncertainty trap’. You are managing a project where virtually all of your customers get a new month end or yearend report with detailed legally binding accounting information. The report can contain any type of transaction details covering hundreds of partly complex accounting use cases. All works fine, but no one knows how good the overall test coverage is and from time to time the business team discovers additional errors. Some more risk adverse team members are escalating the issues and are afraid of going live. However the release is part of a bundle already announced to your customer base and a non-delivery would lead to a high reputation damage or even have legal impact.    

Example two, the ‘dead end’: Suppose you have a frozen project scope in a medium or even smaller size enhancement release of a fairly aged business application. The application represents an overall investment of roughly 150 Mio. Dollar and serves as a global, business critical MIS environment. Even being rather small, the release is containing some legally required changes that the project need to promote to production in a few weeks. The project is reported ‘red’ since several weeks, all possible and impossible actions supporting you as a project manager and the project team have been taken without proving sustainable success. You are under heavy pressure to handover the new software build to the User Acceptance environment where business intends to perform the final tests ... but the software is simply not mature enough to be tested against the initial set of requirements.

In both situations described above you are running out of time and more often than not in complex, highly interdependent and fairly exposed environments the standard project mitigation approaches are falling apart. The options to do some sort of re-planning in the areas or resources and costs, project timelines or feature scoping are not working.

Handling 'project patterns' successfully can make the difference between success and failure of an undertaking. As the tooling cannot be found in a project management checklist we have to search elsewhere for ideas to overcome the challenge. Not surprisingly we very quickly talk about soft factors such as communication, transparency, empathy and team acceptance in conjunction with a sound risk management.

You mean so far this is just ‘stating the obvious'. Ok, somewhat true. Promised, the next blog post takes you directly into the discussion on how to enforce fruitful compromises and sharing risk evenly between stakeholders the two key elements for the above 'project patterns'.

Sunday, March 24, 2013

The first blog entry - about my motivation


The title of this blog is ‘Rethink your IT projects’ and might sound a bit ambitious. Ok fair enough, but after more than 15 years of working as a project manager in many IT projects of all flavors I decided to open this blog to discuss my thoughts with you.

Rethinking will help for sure in future projects, but it is in in a first place reflecting about past projects and their decision or even turning points, about conflicting interests to be aligned within these projects 
and all other sorts of issues you come across in your life as a project member. 

An additional and important reason for this blog is to share with you my thoughts and my perception on the evolution of project management in the past fifteen years. How did project management as a discipline evolve and what other changes did occur within this period of time. In short I strongly believe that project management became even more challenging since I started to work as an IT project manager back in 1998.

Definitely not a reason to open this blog is that I would think to have managed my projects at the very state of the art or that I would want you to learn some hard facts from my experiences. No, in fact I think you will need to do your own experiences, but while doing so you might recognize what I call typical project patterns. They are again and again occurring turning points when you should decide not knowing what are the best next steps and what recommendations you should give to the steering bodies. You only know that a decision is needed. Never mind, even after fifteen years of intense experience this is not completely different. The challenges remain the same.

In short this blog is about elaborating and discussing project patterns. Typically I will dedicate one subject to each blog entry and you can expect my blogs roughly in a bi-weekly rhythm. Follow @felixhonold on Twitter to see what's up.

If you are interested in a particular subject … even better …. please let me know. . Let’s see where it takes us from here. Maybe we even discover some dos and don’ts in project management.