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'.