How to Rescue a Major Project or Program in 10 Steps

There are many reasons major projects or programs may need to be rescued: stakeholder disengagement, resource constraints, excessive delays, costs spiralling beyond contingency allowances and many more. Whatever the reason, it's useful to have a process in place to assess whether a rescue is wise — or even possible — and to proceed accordingly.

“ Rescue effort planning can last weeks”

"When a major project or program is performing poorly against its key performance indicators, and multiple attempts at remediation have already failed, a sense of despair often sets in," says Matt Light, research vice president at Gartner. "Where undeniable business value is still apparent, Gartner's 10-step process can help drive an effective turnaround."

Step No. 1: Issue a "stop work" order

To stop spending time and money on a major project or program is easier said than done. Rescue effort planning can last weeks, disrupting time allocated to skilled resources. It's easier to stop purchasing hardware and software, harder to break up a team of people. Are valuable, productive reassignments available? How long will it be until the team reassembles?

Step No. 2: Talk with everyone

Interview all major stakeholders or their representatives (usually fewer than 10 people). Guarantee anonymity to encourage frank and honest assessments of problems and issues. It's important that these interviews assess politics and culture, and that they gather all stakeholders' positions on what they consider to be allowable and viable rescue outcomes.

Step No. 3: Set boundaries

Define the point of failure. How much cost or investment is too much for a rescue? Not all projects or programs can be rescued, so build an agreement with stakeholders on when to stop trying.

“ Killing the project or program should always be an option”

Step No. 4: Find root causes

Stakeholder interviews typically identify several problems in general terms, such as "high complexity" or "unclear objectives." These kind of responses lack the situational specificity needed to address issues effectively. Probe these causes with increasingly detailed questions that reveal specific details. One technique used for this kind of questioning is the lean management approach of "the five whys."

For example: Your car is not starting.

• First why: The battery is dead.
• Second why: The alternator is not functioning.
• Third why: The alternator belt has broken.
• Fourth why: The alternator belt was well beyond its useful service life and not replaced.
• Fifth why: The vehicle was not maintained according to the recommended service schedule (root cause).

Step No. 5: Assess the risks

If delivery has been unsuccessful so far, there is a risk that the root causes are not addressable, and it is therefore not a good idea to attempt a rescue. Moreover, new risks may become significant in the process of rescue. Identify the risks involved in rescue and have a plan to mitigate them. Key areas of risk include: complexity, technology, operational, external, organizational, schedule and financial.

Step No. 6: Prepare for "war"

Prepare to meet with key stakeholders and decision makers to hammer out a plan of action. This includes:

• Creating a timed agenda in advance
• Soliciting input and feedback from all who will be present
• Building a collaborative workspace to share information and encourage preparation and discussion before the workshop begins
• Preparing all materials and information ready to support discussion and analysis with facts and statistics

Step No. 7: Re-engage key stakeholders

Once all the preparations have been made, gather the key sponsors, stakeholders and decision-makers into one room — ideally face to face. Work through different prepared scenarios and agree on next steps.

This workshop is not a fact-finding session or a place to pose new questions. It is up to the session's leader — often the project manager — to prevent such derailments and keep discussions on track. The key questions to answer are:

• Is the business case still valid if we take into account the rescue costs?
• If not, is there a new business case that justifies the rescue?

Killing the project or program should always be an option on the table at this stage.

“ It's important that individuals and teams explicitly confirm their responsibilities”

Step No. 8: Determine the go-forward status

Even if the decision is to kill the project or program, substantial follow-up will be necessary post-workshop. Assuming the workshop has re-engaged the key stakeholders with an amended plan, it's time to bring in other participants and make some final decisions about next steps. It's extremely important to build off the workshop's momentum and finalize decisions as quickly as possible — ideally within a day. Quickly gather any extra information needed to turn tentative commitments into firm plans.

Step No. 9: Confirm responsibilities

Validate the plan. If the project or program has been on hold for a while, some resources may no longer be available and will need to be recommissioned or replaced. Also, where priorities and plans have changed from the failed iterations, it's important that individuals and teams explicitly confirm their responsibilities for the new path ahead.

Step No. 10: Reset expectations

With the rescue underway, and key stakeholder responsibilities affirmed (or reaffirmed), it's time to communicate changes to the profile, shape and size of the new project beyond the core team. Emphasize the expected outcomes and the strategic alignment, and clearly explain the ramifications of the changes. Although the communication may state that feedback is welcome, it should be clear that the new course is set and the project is proceeding.