Five Immutable Principles of Project Success

Project failure starts when we can’t tell what “done” looks like in any meaningful way.

Without some agreement on our vision of “done”, we’ll never recognize it when it arrives, except when we’ve run out of time or money or both.

We’ve all seen the project failure numbers before. We’ve all been told how bad things are. We’ve all heard that large numbers of projects fail because of poor planning or poor project management. Whether this is true or not, how can we increase the probability of our own project’s success?

First, we must recognize that without a clear and concise description of done, the only measures of progress are the passage of time, consumption of resources, and production of technical features. These measures of progress fail to describe what business capabilities our project needs to produce or what mission we are trying to accomplish.

The myth that this description of done can emerge, is just that a Myth.

The requirements that implement done can certainly emerge since they are not likely to be fully defined on day one. But without some description of done in Measures of Effectiveness and Measures of Performance, the project is a Death March as stated by Yourdon.

These Five Immutable Principles are simple and straightforward and applicable to all project domains, all project management processes, and all product development methods.

1. What does “done” look like?
2. How are you going to reach “done”?
3. Do you have all the resources you need to reach “done”?
4. What impediments will you encounter along the way to “done”?
5. How are you going to measure progress toward “done” in units
6. meaningful to the decision makers?

Once there are answers to these five questions, there are Five Practices that must be in place.

1. Define the needed capabilities. These are not the technical or operational requirements. Those come later. These are the Capabilities delivered to the stakeholders needed to accomplish their mission and vision.
2. Define the technical and operational requirements needed to implement those capabilities.
3. Establish a Performance Measurement Baseline (PMB) for performing the work that implements the requirements. This baseline can be a formal Integrated Master Schedule or it can be an informal Product Roadmap with a Release Plan. But some agreed-upon description of what will be delivered in the project is needed at the top level
4. Execute the Performance Measurement Baseline. Follow the plan. When the Plan needs to be changed, change the Plan. The Plan is a Strategy for project success. Strategies require tests to confirm they are the right strategy.
5. Perform Continuous Risk Management (CRM) on everything you do on the project. Risk Management is Project for Adults - Tim Lister

Once the principles and practices are in place, there are five processes needed to manage the business and technical activities of the project.

1. Organize the project through some work breakdown structure (WBS) and an organizational breakdown structure (OBS) to show what is being delivered and who is delivering it.
2. Plan, schedule, and budget the work needed to produce the deliverables. This can ne a formal WBS and OBS, or it can be a breakdown of the Features to be provided by the project.
3. Account for the time and money used to implement the deliverables.
4. Analyze the variances that result between the planned time and cost and the actual time and cost and measure the physical percent complete from those measures to determine actual progress to plan.
5. Maintain the integrity of all the information, so forecasts of the project’s future performance of the project are based on a solid assessment of past performance.

These principles, practices, and processes are neither new nor unique. All projects can be managed using this approach. No matter the size, complexity, or domain, the principles, practices, and processes can be applied to increase the probability of success.