This is the second article in a series on the Project Recovery Model™, a proven approach for bringing troubled projects back to success. This article will be a deep dive into the Recognition of troubled projects.
Most of my work as a project recovery consultant is with what you can call «troubled projects.» But what does this actually mean?
Many organizations I have worked with seem to be stuck in the Project Management Institute (PMI) view of things. The Project Management Body of Knowledge (PMBOK®) Guide defines the successful project as a project that meets its objectives in terms of quality, schedule, budget, and scope (and sometimes customer satisfaction), and considers a project a temporary endeavor undertaken to create a unique product, service, or result.
The guide does not define a troubled project but by taking the opposite of the above you can formulate a starting definition for troubled projects: “A troubled project is a project with overrun in quality, schedule, budget, and scope that exceeds the acceptable tolerance limit.”
The real meaning of trouble
In my opinion, the above definitions of successful and troubled projects are not useful because they only capture a very small part of what successful or troubled projects are. Project success should be defined across three levels:
1) Project delivery success is about defining the criteria by which the process of delivering the project is successful.
Essentially this addresses the classic triangle of scope, time, and budget. It is limited to the duration of the project and success can be measured as soon as the project is officially completed (with intermediary measures being taken, of course, as part of project control processes).
2) Product or service success is about defining the criteria by which the product or service delivered is deemed successful.
For example, the system is used by all users in scope, uptime is 99.99 percent, customer satisfaction has increased by 25 percent, operational costs have decreased by 15 percent, and so on.
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 immediately at the end of the project itself.
3) Business success 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 example, this could be financial value contribution (increased turnover, profit, etc.) or competitive advantage (market share won, technology advantage).
The PMI view only looks at the first level: project delivery success. Personally, I think this level matters very little if levels 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 seven months, delivering great results for the client and company and still «fail» because some project manager without a clue about software development, without a team in place, and without a deep understanding of the client requirements decided that the scope could be delivered in four months.
A troubled project should be defined by the same three levels and key performance indicators (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 objectives and key results), and what it can be expected to be (your measurements and projections) exceeds the acceptable tolerance limits (your minimum and maximum 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.
Recognizing trouble
So now we have a definition for troubled projects, but how does this help me in recognizing, or even better, preventing one?
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.
In project management, we often talk about “lagging” and “leading” indicators. Lagging indicators are typically output-oriented, easy to measure but hard to improve or influence. Leading indicators, on the other hand, are typically input-oriented, harder to measure but easier to influence.
Let me illustrate this with a simple example. Let’s imagine you are responsible for managing a customer support team, and your goal is to resolve any high-priority incidents within 48 hours. Currently, you only succeed in 70 percent of such incidents.
The output is easy to measure: You either solve these incidents in 48 hours or not. But how do you influence the outcome? What are the activities you must undertake to achieve the desired outcome?
For instance: Make sure your team starts working on such incidents immediately when they occur. Make sure that incidents are assigned to the right people with the right skillset and that this person isn’t already overloaded with other work.
This could be translated into the following leading indicators:
> % of incidents not worked on for 2 hours
> % of open incidents older than 1 day
> % of incidents dispatched more than 3 times
> Average backlog of incidents per agent
When you start measuring these indicators on a daily basis and focus on improving these, I would think it is extremely likely to see an improvement in reaching your goal.
All the project success criteria on the three different levels discussed above are so-called lagging indicators. A lagging indicator is a measurable fact that records the actual performance of a project. They all represent facts about the project, the resulting product/service, and the benefits of it to the organization.
But things start to go wrong in a project well before the performance measure turns the traffic light on the scorecard red.
Using only metrics that measure past events is like driving while looking through the rear window. It’s easy to miss an opportunity or threat on the road ahead until you hit it.
Leading indicators for trouble
A leading indicator is a measurable factor that changes before the project starts to follow a particular pattern or trend. Leading indicators are used to predict changes in the project, but they are not always accurate.
Examples of leading indicators for a project’s success:
1) Poorly defined (or undefined) done: 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.
2) Poorly defined (or undefined) success: A project can only be successful if the success criteria are defined, ideally upfront. Therefore, the lack of these definitions on the three levels as described above is a great leading indicator for project trouble.
3) Stability, quality, and availability of project team: A lot of change in the project team is a good leading indicator for trouble. The same for missing skills and experience. Also, team atmosphere is a great leading indicator.
4) Engineering practices: The practices that are implemented are a good leading indicator of engineering quality.
5) Risk management: The presence or lack of risk management is a great leading indicator of the impact of negative surprises.
6) Availability of up-to-date RAID lists: The quality of these lists is a great indicator for awareness of trouble.
7) Engagement of stakeholders and steering committee: When the stakeholders do not care about your project, then why should you?
8) Runway: The burn rate of a project is a lagging indicator as it describes how money is spent (or lost) for any period of time. The runway is a leading indicator as it predicts how long the budget would last with a specific burn rate.
9) Milestones: Missing or achieving the deadline on a milestone is a lagging indicator. But it is also a leading indicator for the following milestones.
10) Project size: The bigger the project, the higher the probability it will fail.
All leading indicators can be used for identifying troubled projects before it is too late to do something about it. Just be aware that just because a leading indicator is positive, it does not mean the final outcome will be positive. Nor does a negative leading indicator automatically mean a negative outcome.
Trouble is not the same as a crisis
A troubled project is typically something that happens over time and because of some wrong decisions in the beginning and/or bad project management in the broadest sense. This is different from a sudden unexpected (or low-probability) event occurring and spiraling the project into a crisis. Why is this different? Because when the project was solid before the crisis, it will be solid again after the crisis is solved. In such a case there is no need for a project recovery manager, project review, etc.
Here are some examples of project crises I have personally experienced:
> The sudden departure of the only person that could explain how that ancient legacy system works.
> The main supplier going suddenly bust because of a lost litigation case.
> The main supplier being bought by our biggest competitor.
> Discovering that your supplier oversold big time; the key system functionality that drives your business case does not exist, and will never exist.
> The whole external consultant team being poached by another competitor.
> Performance problems shortly after going live, so bad that complete teams were walking out of the building because they could not access their documents anymore.
The manner in which a project team, an organization, its executive team, and its board responds to and handles a project crisis will often determine the overall impact the crisis has.
In a nutshell: In project management, using only metrics that measure past events is like driving while looking through the rear window. It’s easy to miss an opportunity or threat on the road ahead until you hit it. And only when you have identified a project as in trouble can you start thinking about project recovery. It takes a great deal of political savvy and courage to recognize and admit that a key project is in serious trouble.
This is the second article in a series on the Project Recovery Model™, a proven approach for bringing troubled projects back to success. We’ll be publishing more deep dives into the individual concepts of this model and their relationships. The next article will discuss Mandate.
Other articles in this series
Links will be added as soon as the corresponding article is published.
> The Project Recovery Model – An Introduction
> The Project Recovery Model – Recognition
> The Project Recovery Model – Mandate
> The Project Recovery Model – React
> The Project Recovery Model – Review
> The Project Recovery Model – Tradeoff & Negotiation
> The Project Recovery Model – Intervention
> The Project Recovery Model – Transition
> The Project Recovery Model – Conclusion
