Good Project , Poorly Done - what to do?

A good project is one that ultimately adds value to the company. Some projects reduce costs, some don't seem to add value or reduce costs - I'll get back to these in a future post. What I want to discuss in this post is a Good Project (one that adds measurable value) executed poorly. A good example of a good project is iTunes - easy to see and measure the value added. Value Add is determined by the hard $'s returned on investment and the softer, tough to measure, $'s through brand recognition, secondary benefits (for iTunes it would be another reason to by an iPod, etc.). A good example of a poorly executed - good project - was/is MSN (like most of Microsoft's projects - good idea bad execution).

SO - back to Good Project - Poorly Done. What to do?? A lot depends on when the fact that the project is being 'poorly done' is caught. Was it during requirements? Execution/coding? Implementation? Go-live? Or is it live and a bomb? Obviously, the sooner caught the less costly the solution and easier to resolve. However, regardless of when it is caught the same basic steps need to take place:

• Realize that there is an issue: often the toughest part of the process. EVERYONE needs to understand that there is an issue and that some corrective action needs to take place. Often there is a feeling that some more effort, a few extra hours, etc. is all that is required, perhaps - be careful not to be to pessimistic or to optimistic.
• Triage: quickly determine the issues from a high level perspective. This will help focus the corrective activities. Don't stop, unless necessary, corrective activity that people are taking at this point, since they might be making positive progress.
• Review the issues with ALL stakeholders, determine the real impact on the project value and start determining the corrective areas of focus.
• Stop - Breath - Plan: This is where the PM needs to get down and dirty. Don't rush, but move fast (some quote I heard, but not sure where/who). You need to quick switch the teams focus from fixing to thinking. There's a typical reaction to a problem - work harder - the real solution is often to take a step back, think about it, plan a course of corrective action and aggressively execute against the plan.
• Involve everyone - get all project related resources involved in the definition of the issue and steps to address it. Additional resources, equipment, etc. should be determined by the corrective plan and cost/benefit analysis (needs to be done) AND SHOULD NOT be determined by gut feel or base re-activeness.
• Constant/on-going review: throughout the corrective stage it's important to reevaluate the product to determine if there are other issues and/or gaps. Be objective, but keep your eyes open, the mistake that got you to the near failure point is often an indication that there is a base problem that could have caused other and/or deeper issues within the project.
• Understand but don't blame: Once the corrective action (well planned) is underway, the time is right for an evaluation of the root cause. What caused the issues within the project? are they specific to this project? to the team? company wide? Be objective, be thorough, understand that someone will be upset with your findings - most importantly be honest and brave. Don't associate issues with any specific people, first understand the root cause and keep it non personal. Once the facts are in, the corrective action to the root cause should be apparent to all and those that have the power (higher ups) need to understand the issue, the approach to correct and the short and long term consequences of their corrective actions.

The most important thing to do during a crisis is stick with the process. It's often a mad rush to fix, but in doing so, the issue is often made worse. PM process, etc. are put into place for the bad times not the good (if everyone did everything perfectly all of the time there would be no need for processes, etc.).