Don McAlister's Blogsite

Forensic assessments of failed and troubled projects often reveal that the direct causes of the problems, and/or the contributing factors, are self-inflicted. The damage caused by these project management “friendly-fire” incidents can be significant and long lasting.

Consider these real-life self-inflicted Project damage examples:
• You improve a local process within the project with insufficient consideration of the affects the changes may have on the rest of the project system. The overall project is sub-optimized at the expense of making one element look better.
• You fail to measure your project performance in the same way your customer does. The customer metrics may not be fair or right, but if you’re not looking at things they way they are, then trouble is just down the road.
• You shield your team from unfavorable news or feedback to keep them from being distracted. Transparency may be uncomfortable and sometimes even risky, but it builds trust, and engages everyone in early avoidance/resolution of the emerging problem.
• You provide quick recognition of problem solving heroics. Unfortunately, often the work of the most heroic goes unnoticed. You should focus on celebrating team accomplishments and let them identify their own heroes.
• You implemented a rigorous project earned value management system by breaking-down your work packages down to the lowest level, requiring a bi-monthly earned value review cycle, and setting minimum cost and schedule variation thresholds for action. Unfortunately you now spend so much time crunching the raw data through the financial systems and pressing the team leaders for analyses, reports and variance explanations, that you lose your real-time feel for the pulse of the project and emerging changes in context. Earned value metrics are important, but tailor your process rigor to meet the real needs and means of the project.
• You stoically maintain your project cost and schedule baselines in their original configuration, even though significant changes in project customer requirements and performance have occurred that have created variances which are unrecoverable and for the most part, irrelevant to current project conditions. You’ve done this because both you and your management believe you should “own” all variances and you want to show at least some progress in reducing these “original sins” them during the project life cycle. The problem is, that these large “artifact of the past” variances that your team are dutifully measuring, and repeatedly explaining, may be obscuring subtle, near-term adverse trends that could have a significant impact on the current and future performance of the project. It may be time to “bite the bullet” and discuss with your customer and management the implementation of a project re-baseline. For more on this, see my blog, “Knowing When to Re-Baseline Your Project.”

These are all real examples of situations I’ve encountered while analyzing the cause network for troubled or failed projects. Projects are complex; people systems with lots of opportunities for human error. Good people, with good intentions will make errors that cause some damage. But, thoughtful review of shared examples like those listed above and others you may have experienced,  can go a long way to reducing the likelihood and consequences of the risk of self-inflicted project damage on your next project.

Your thoughts on this topic are welcomed.