By Tom Mochal
Projects have problems. Most problems arise and are solved. On some projects, however, the problems add up and are compounded to a point where they cannot be resolved successfully. These are sometimes called “troubled projects.” These projects may limp along to the finish line. However, if the sponsor and management stakeholders have the perception that the project cannot get to the finish line, a project rescue should be attempted.
Project rescues are radical measures. A formal project rescue means that you have given up on the ability of the project manager to right the ship. Project rescue is not an attempt to repair a sinking ship. It is an attempt to raise a ship that is already underwater.
First Things First—Is the Project Really in Trouble?
When you are looking at a “troubled” project, the first thing to validate is whether the project is, in fact, in trouble or not. In many cases, there is the perception of a problem when there really is not one at all. In other cases, a project may be in trouble, but the project manager might already have begun a process of damage control and correction. Sometimes the project has problems, but the problems are not significant enough for the project to be considered troubled. For instance, if a nine-month project is scheduled to complete a week late, you would need to decide whether it really is in trouble.
The following provide some examples:
- The project is trending over its estimated budget by a greater percent than the agreed-upon acceptable tolerance.
- The project is trending over its estimated deadline by a greater percent than the agreed-upon acceptable tolerance.
- The project appears within tolerances, but only by compromising on quality to the point that the value and integrity of the deliverable are called into question.
- The client is extremely dissatisfied with the performance of the project team. If the client had to do the project again, he or she would not use the same project team.
- The client-project team relationship is dysfunctional. This could include situations such as the client and sponsor losing interest in the success of the project or major animosity between the project team and the client.
Minimizing the Risk of Troubled Projects
By their nature, project rescues are very risky. There is a lot that can go wrong and, if you are not careful, the rescue can be dragged under just as the original project was. However, by structuring the project rescue correctly, you can manage these risks successfully.
Step #1: Isolate the Rescue Work into a Separate Recovery Project
This is the key to success. The recovery project is the project that will rescue the troubled project. Many organizations view project rescue as a time for the cavalry to come charging up the hill. Instead of just jumping in, the first thing that needs to happen is to recognize that the work to recover the troubled project is itself a project. The project manager accountable for the recovery project is most likely not the project manager on the troubled project, but someone with a demonstrated track record in rescuing troubled projects. When the troubled project is in crisis, the sponsor and key stakeholders will be looking for strong leadership that can organize and execute the project back to the regular routine of any project.
Since the recovery is a project itself, the first thing that needs to happen is a definition and planning process. Just as with a regular project, the definition and planning process gives you a chance to validate the following:
- The purpose of the recovery project (overview and objectives)
- The deliverables to be produced (scope)
- The other aspects of scope including validating the organizations that will be included in the recovery project, the portions of the project to recover, etc.
- The sponsor, project manager, and other key stakeholders of the recovery project (project organization)
- The estimated duration and cost of the recovery project
- The assumptions and risks associated with the recovery project, and how the risks will be managed
It is important to make sure that the project manager of the recovery project is in synch with the sponsor of the work that is to be done as a part of the rescue. Once the recovery project has been defined and planned, the sponsor and appropriate stakeholders should approve the project charter.
Step #1A: Gain Agreement with the Sponsor on the Deliverables of the Recovery Project
This is actually a subset of the first step, but it is important enough to have its own headline. In many recovery projects, the primary deliverables are a revised project charter and project schedule for the troubled project. The charter and schedule cover, at a minimum, what is often referred to as the recovery plan. Additional deliverables might include:
- New/revised project management procedures
- New/revised risk plan
- New/revised communication plan
- New/revised team members, probably including the project manager of the troubled project
- Assessment (of the troubled project)
- Alternatives and recommendation (to address the troubled project)
You want the recovery project to create or update the project management deliverables for the troubled project. However, the more work that is required from the recovery project, the riskier the recovery will be.
Step #2: Assess the Troubled Project to Determine What Went Wrong and Why
It is very risky to propose alternatives for rescuing a project without first doing an assessment of the causes. As a part of the initial briefing, you are likely to talk with the sponsor or other key stakeholders. They will certainly brief you on the background and the problems. However, they are just one voice that you will need to listen to. Even information that comes from the sponsor should be validated and confirmed by others before the assessors make any decisions.
To be effective, the assessment must include:
- Project team
- Sponsor
- Client managers
- Users
- Vendors, suppliers, and other third parties who have a high degree of involvement
Assessing all the major stakeholders will not only allow you to see a more balanced view of the project, but will also help you in implementing the recovery plan. People tend to respond better to adversity and change if they think they have been consulted and had input into the recovery process.
Step #3: Be Open to Every Possible Alternative, Including Canceling the Project
After the assessment is complete, alternatives should be developed along with a recommendation. The alternatives will vary greatly depending on the causes that were uncovered during the assessment. However, a couple of alternatives will normally always be considered:
- Stop the project. If a project is in bad enough shape that a rescue is required, the team should always leave open the possibility that the project should just be canceled.
- Do nothing. Let the project continue as is. In some cases, the sponsor may determine that the cost of a project rescue is not worth pursuing. For example, a project may be projected to complete at a budget 90% higher than estimated. However, the assessment may determine that the project cost was underestimated. In this case, there is not much that can rescue the project. The sponsor is forced to accept the higher cost of the project, cancel the project, or scope back the deliverables.
- Make specific recommendations. In most cases, the recovery team will propose alternatives and make a specific set of recommendations for the work required to complete the troubled project.
The sponsor needs to evaluate the options and choose how to proceed. The trick is to pick an option that provides the best chance of success on the remaining work. The risk of choosing the wrong rescue option is managed by making sure that your sponsor and management stakeholders approve the recovery plan, taking the alternatives and recommendations into account. If a broad audience was consulted to create the alternatives, and if these same people buy in to the final recovery plan, the chances of the rescued project completing within revised expectations will increase dramatically.
Step #4: Activate, Measure, and Monitor Recovery Plan
Once you have gained agreement on the recommendation, you will now activate, measure, and monitor the recovery plan. There are two options for implementing the recovery plan. The first is to implement the recovery plan as a part of the recovery project. This implies that there is no longer a need for the originally troubled project and the recovery project will now complete the remaining work. The second option is to close the recovery project and execute the recovery plan in the troubled project. In this case, the troubled project (i.e., the newly rescued project) is now adjusted to complete the work according to the recovery plan.
There is always a risk that the newly rescued project will have additional problems after the recovery plan is in place. This risk has to be managed through proactive monitoring and measurement to validate the status of the recovery plan and the project in general. The worst result of a project rescue is that the recovery itself fails. If this happens, not only is the entire project likely to be canceled, but there may be repercussions for those involved, including a loss of credibility.
Depending on the duration remaining on the project, this may also be a time when the project manager needs to use techniques for micromanagement. Normally, you might not want to be involved in the team work activities on a detailed basis. However, when you are in a recovery, you may need to keep a close watch and follow up on all outstanding work.
Summary
Project rescues are not for the faint of heart and they are not appropriate for a project that is having typical problems. However, if you have a large and important project that is off the rails, it might be time for this radical intervention.
If you perform a project rescue, be smart about it. Can you image a worse scenario than trying to rescue a project, only to see the rescue effort itself fail?
The way to manage the risks associated with a project rescue is to structure the rescue work itself as a project. This isolates the rescue work into a separate entity with its own project charter, schedule, and deliverables. The purpose of the rescue project is to not to carry on the work of the failed project. The purpose of the rescue project is to come up with the new project charter, new schedule, new estimates, new deliverables, and anything else that is required for the original troubled project. The rescue project then ends and goes away. The sponsor, project manager, and management stakeholders must then do a much better job of managing and monitoring the formerly troubled project to ensure that it can now be finished within the revised set of expectations.
Tom Mochal(Tom.Mochal@TenStep.com) is president of TenStep, Inc. (a company focused on methodology development, training, and consulting) and president of The TenStep Group (the network of TenStep offices in the United States and around the world). Tom is an expert instructor and consultant on project management, project management offices, development lifecycle, portfolio management, application support, people management and other related areas. He has work experience at Geac Computers, The Coca-Cola Company, Capgemini, and Eastman Kodak.
