Recovering Failed Projects

What does a project failure mean? For the project manager, a definition can be not meeting the triple constraint criteria: scope, cost and time. On the other hand for the customer is more important the business value delivered by the project. Therefore the business value along with the triple constraint are defining the project success or failure criteria.  

There are several reasons for a project failure. Most of them are related to the:

• Requirements: missing, incorrect or ambiguous requirements, lack of stakeholder involvement in the requirement definition.
• Enterprise environmental factors: Improper processes to which the project must comply, lack of support from the top management, etc.
• Resources: not enough or lack of ressources, high turnover rate, not the right resources.
• Project Management: unrealistic estimates, tight schedules, scope creep, communication issues, lack of stakeholder management, lack of the risk management, wrong assumptions, wrong type of contract.
• Technology: Not the right technology, usage of immature technologies

There are 4 steps for fixing a project: 

1. Understand the project. 
2. Audit the project 
3. Find trade-offs and prepare a recovery plan. 
4. Align trade-offs with the stakeholders.
5. Fix the root causes of the issues which caused the project failure. 
6. Deliver according with the recovery plan.

1. Understand the project

       The first step in recovering a project is to understand the project. Thus you have to:

• Check the project history
• Determine the project objectives.
  Determine the business needs.
• Determine the assumptions and constraints
• Make a stakeholder analysis (Who are the stakeholders? What interests do they have in the project? How is their influence in the project?).
• Understand the company processes and their impact on the project. 

2. Audit the project 

In this step you have to find an answer to the following questions: 

• Where is the project staying from the point of view of schedules and costs? How big are the variances? An answer can be given using the earned value calculation (assuming you apply a classical project management) or a release burndown chart in the case you are using an agile methodology as Scrum.
• Is the current scope still valid?   
• What is the priority of each feature which needs to be delivered? You should be able to set priorities at least at the following levels: high priority (must have), medium priority (nice to have), low priority and not needed.
• How the key stakeholders (customers, users, top management, development team) are seeing the project? Are they happy with the project? If not, what is the reason? Furthermore, are there powerfull stakeholders which are opposing the project. Is there enough support from the project sponsor?
• How does the issue log looks? Are there old unresolved issues? The issue log, if a such issue log exists, can provide valuable information about day to day project work.
• Are there people issues in the project? Are the team members motivated? Do you have the right people in the team? How is the team's work-life balance? How is the team morale? You have to involve here the full team.
• Is there any risk with major impact occurred? Does the project have any risk management proceses?
• How is the quality of the deliverables? Are there any quality management processes embraced? 
• Are the company policies and processes appliable to the type of the executed project?   

You might need to consider other areas, as well. But after finding an issue you have to conduct a root cause analysis.

3. Find trade-offs and prepare a recovery plan

After auditing the project, you might discover that the initial targets of the project cannot be reached without to do some tradeoffs. In simple situations you can fix the found project issues and then try to reach the initial goals by doing a „fast tracking“ of the remained work packages (execute the work packages in parallel and not in sequence) and by „crashing“ (put more ressources on the work packages located on the critical path). But in complex situations you might need to do much more. Thus in this third step, trade-off phase, you have to: 

• If the scope is changed, plan to deliver the new scope.
• Prepare the trade-offs related to the scope. In the previous step you prioritized the remaining features/work packages as: high (must have), medium (nice to have), low priority and not needed.
• Determine what is more important for the customers. Can the budget be increased? Can the schedule be extended? Can we still achieve a higher business value with a smaller scope, while keeping the same cost and deadlines? 
• Determine, prioritize and plan the steps to be done in order to fix the root cause of the current situation.
• Determine the new risks, reassess the old risks and prepare a plan to deal with them.
• Assemble a recovery plan.

4. Align trade-offs with the stakeholders.

In this step you have to get a buy-in from the stakeholders for your recovery plan. If it is it still possible to save the project, you have to sincerely ensure them that the situation can be fixed and you have a plan for fixing it. The customers shall agree with the proposed trade-offs. You may:

• Negotiate with the stakeholders a smaller scope, for example without the low priority features.
• Negotiate an increase of the project budget.
• Negotiate an extension of the project deadlines.
• Negotiate a combinations of all from above, but each of the variables to a lower extent. 

The recovery plan will be updated according with the result of the trade-off negotiations. 

5. Fix the root causes of the issues which caused the project failure.

Now that you have an approved recovery plan, you can start to fix the root cause of the issues which caused the project failure. You might need to:

• Discuss the learnt lessons with the team.
• Present to the team the agreements reached with the stakeholders.
• Add, remove, train team members. Start building your team. 
• Change the way how the project is managed.
• Improve the processes which are governing the project (related to change management, quality, risk, type and extent of the project management processes).
• Allow the right level of stakeholder involvement in the project. Fully engage the sponsor and other important stakeholders to secure their support for the project.   

6. Deliver according with the recovery plan

In the last step, the team shall work to deliver the project deliverables according with the recovery plan. But this time the project will be under a higher scrutinity and you, as a project manager, have to:

• Enforce the new agreed processes. Check their effectivity periodically, propose and apply improvements.
• Measure regularily the project progress against the plan and execute corrective actions in case of variances.
• Do a "Fast Tracking"  of the work packages or "Crash the schedule" to win time.  
• Perform risk management.
• Solve the issues timely according with their priority.
• Ensure an efficient communication with the team and the stakeholders.
• Manage the stakeholder expectactions.
• Build and motivate the team. Insulate the team from the external pressure.
• Use an issue log.
• Measure team performance.
• Create forecasts.
• Asses the quality and apply preventive and corrective actions.   

In conclusion, recovering a failed project is a complex activity which requires audit, stakeholder negociations, replanning and a lot of support from the stakeholders, especially from the customers and top management. For any project have to be done periodically sanity checks to discover as early as possible the signs of a failure. In that case, corrective and further preventive actions have to be done immediately. If done too late it's not possible to guarantee that a successfully recovery can still be achieved.