The Project Recovery Model ™

The Project Recovery Model
Recovery of troubled projects is a combination of art, science, and craft.

Many have tried to translate project recovery in a “fits all” framework, methodology or process. After more than a decade of doing project recoveries, I’m of the opinion that this is a futile exercise. The reality is just different.

What has really helped me over all these years is something a little different: a conceptual model of a project recovery and the steps it typically goes through.

The Project Recovery Model ™ is such a conceptual model. Where a mental model captures ideas in a problem domain, a conceptual model represents 'concepts' and relationships between them.

A conceptual model in the field of computer science is also known as a domain model. The aim of a conceptual model is to express the meaning of terms and concepts used by domain experts to discuss the problem and to find the correct relationships between different concepts.

A conceptual model acts as a key artifact of business understanding and clarity. The concepts of the conceptual model can be mapped into actual implementations that will be different for each organization and project.

The Project Recovery Model ™ contains eight concepts (or steps). Each one has a relationship with the others.

1) Outcome
2) Recognition
3) Mandate
4) React
5) Review
6) Tradeoff & Negotiation
7) Intervention
8) Transition

The diagram below offers a visual representation of the model.
The Project Recovery Model
You cannot put “gates” into this series of steps. Their relationships are fluent. One step will most likely not be completed before you will have to start the next one.

Now that we've looked at the Project Recovery Model ™ in a broad sense, let’s take a closer look at each concept.


A project recovery can have only three possible outcomes:

1) Delivery of the project without significant changes in scope, time and/or costs. This is very rare and only possible when trouble is identified early and action is taken immediately.

2) Delivery of the project with significant changes in scope, time and/or costs. There will be an impact on the business case.

3) Termination of the project because costs and benefits or value are no longer aligned. Note that termination does not necessarily mean that everything done up to this point should be written off as sunk costs. Some parts might be salvageable.


As soon as a project is identified as in trouble you can start thinking about project recovery. Identifying a problem project as such is a very important precondition for any successful project recovery. It takes a great deal of political savvy and courage to recognize and admit that a key project is in serious trouble.


The purpose of a mandate is simple. Obtaining executive support for a project recovery attempt by appointing a project recovery manager and releasing budget for such an attempt.

The mandate of the project recovery manager should be defined clearly, and he/she needs strong executive support, especially when the recovery manager is working with the current (or new) project manager instead of replacing him/her.

The project recovery manager can be an internal role, but there are a number of good reasons to hire an external project recovery manager.


You cannot ignore that the project is ongoing while you start the recovery. It takes time to get to a solution, but it is also necessary to limit spending on a failing project. You have two options.

1) Halt the project

2) Curb the bleeding

Typically number 2 is the best option.


The review is a critical assessment of the project's existing status. You will look at what went wrong and what can be corrected rather than looking for someone to blame. A project review is all about the probability of project success. A review will give you a good understanding of the current status of the project and how it is on track to deliver against your definition of project success on three levels:

1) Project delivery success

2) Product or service success

3) Business success

Tradeoff & Negotiation

As soon as you have the necessary information for decision making as well as the team's support for the recovery you can start negotiating. It will be highly unlikely that the original requirements can still be met without some serious tradeoffs. You must now work with the team and determine the tradeoff options that you will present to your project sponsor and other stakeholders. The goal is to redefine (and agree on) your project success criteria on the aforementioned three levels.


Assuming the sponsor and stakeholders have agreed to new success criteria, and approved a recovery plan on how to achieve them, you are now ready to start intervention of the project. This means, among other things:

> Briefing the team on the outcome of the negotiations

> Making sure the team learns from past mistakes

> Introducing the team to the agreed-upon recovery plan including the agreed-upon milestones

> Introducing any changes to the way the project will be managed

> Fully engaging the project sponsor as well as the key stakeholders for their support

> Identifying any changes to the roles and responsibilities of the team members

> Restoring team confidence


As soon as the project is in a normal state again the project recovery manager (when he/she does not have the project manager role) can transfer the responsibility for the recovered project and close the recovery. When the project recovery manager also has the role of project manager he/she can decide to close the recovery and manage the project as if it was a freshly started project or keep the project in recovery mode until the project is delivered.