A troubled project is a project with overrun in quality, schedule, budget and scope that exceeds the acceptable tolerance limit and might be recovered.
Therefore, a specific effort is required to either define and execute a possible recovery or deciding for an early project termination, as both options are considered a solution for troubled projects.
The Meaning of Trouble
From my point of view, this definition of a troubled project is not useful because it only captures a very small part of what a successful project is. As discussed in a previous article, project success is defined across three levels:
1) Project delivery success: this is about the process of delivering the project is successful. Essentially this addresses the classic triangle "scope time, budget, and quality?" It is limited to the duration of the project and success can be measured as soon as the project is officially completed. Intermediary measures are easy to do as part of project control processes. Besides the typical project delivery KPIs you can also look at KPIs like overtime, project member satisfaction, stakeholder satisfaction, lessons learned (improved project delivery capabilities), etc.
2) Product or service success: this is about defining the criteria by which the product or service delivered is deemed successful (e.g. system is used by all users in scope, uptime is 99.99%, customer satisfaction has increased by 25%, operational costs have decreased by 15%, etc.). These criteria need to be measured once the product/service is implemented and over a defined period of time. This means it cannot be measured during or directly at the end of the project itself.
3) Business success: this is about defining the criteria by which the product or service delivered brings value to the overall organization, and how it contributes financially and/or strategically to the business. For examples: financial value contribution (increased turnover, profit, etc.), competitive advantage (5% market share won, technology advantage), etc. In most cases, these business success factors can only be measured once the product/service is implemented and over a longer period of time.
These three levels combined (and therefore measured by the combined set of KPI's from these levels) will determine your overall project success. Once you have taken the effort of defining all your project success criteria on each level (KPIs) you can define min, max and target values for them. Success is rarely a single point or value.
The PMI view only looks at the first level: project delivery success. Personally, I think this level matters very little if level 2 and 3 are not met. Another issue with focusing on level 1 is that you measure success against estimations. I can have the best team, doing the absolute best work for 7 months, delivering great results for the client and company "failing" because some project manager without a clue about software development, without a team in place, and no deep understanding of the client requirements, decided that the scope could be delivered in 6 months.
In my opinion, a troubled project should be defined by the same three levels and KPIs as a successful project. Hence a troubled project can be defined as a project where the difference between what it is defined to be (your KPIs), and what can be expected to be (your measurements and projections) exceeds the acceptable tolerance limits (your min and max values), pushing it into a course that will inevitably lead to failure.
A troubled project is a project where the difference between what it is defined to be, and what can be expected to be, exceeds the acceptable tolerance limits, pushing it into a course that will inevitably lead to failure.
How Does This Help you?
So now we have a definition for troubled projects, but how does this help me recognizing, or even better, preventing one? It doesn't. It is just the first step of a longer process. The PMI view on troubled projects is easy to implement and measure. As shown above, all project delivery success criteria can be measured during and directly at the end of a project. But product/service success and business success cannot. So we have to work with leading indicators and assumption validations in order to make meaningful measurements for those criteria during the project. See "10 Leading indicators of troubled projects" for a number of examples of such indicators.
Posted on Sunday, February 11, 2018 by Henrico Dolfing