How do YOU define project failure?

An early project management lesson learned is that it is a good practice to start with the end in mind, especially when it comes to defining what done looks like. Without working through this at some level of detail, project teams risk experiencing a similar pain to reaching the finish line at the end of a marathon only to have the judges move that line back by a mile.

Beyond defining the criteria for project closure it is also a good idea to ensure there is a consistent understanding of what success will look like. This takes us from the “Why” to the “What”. If there is disagreement on how success is defined key stakeholders might disagree on whether the project was successful or not.

With risks it is recommended that we not focus solely on threats as we might miss the chance to benefit from opportunities. So why spend time only defining what project success is? By doing so we run the risk that stakeholders will assume that any outcome other than project success represents failure.

Don’t think this is an easy task!

At the beginning of a project unless key stakeholders are worried about some challenging schedule, cost or quality constraints, their moods are likely to be ebullient. Forcing them to think about and define the conditions which they feel represent project failure might not be a pleasant discussion but having this information will improve the quality of planning through the life of the project.

A minimal way to do this is to understand the relative priority of project constraints. With this knowledge, when the team encounters a critical issue they will assess recovery options using the context of failure criteria. This information also helps to focus risk analysis and response activity on those risks which will cause project failure.

Our project glass needs to be considered half-full and half-empty at the same time!