How to Perform a Project Rescue Operation

By Lisa Venter, Head of Delivery

Our largest project, looks like it is failing, what do we do?

There are many reasons major projects may need to be rescued, ranging from non-delivery of features, features not meeting the expected functional delivery, delays, increased costs, and stakeholder disengagement, to name a few.  Whatever the reason may be it is important to have a process in place to assess whether a rescue is possible and to proceed accordingly.

Realising you need Project Rescue:  In a lot of cases the company does not realise that the project is actually in “trouble” until it is a substantial way through the project.  Usually identified if the delivery is not as far down the project plan as anticipated or that requirements are not meeting the expectations of end users or customers.  As an organisation you need to acknowledge this and put in steps to implement project changes.  Do not keep doing the same things you were doing before as you will be in the same position in a few months.

Take stock:  Take the time needed to take stock of where you are with the project.  Do not play the blame game as that will waste valuable time in this process, only assess what was originally specified for delivery and what has been delivered up to the point of taking stock.  It is important to analyse what is of value and what can be re-used.  Once all the relevant teams have determined what they still need to do, you can plan for the next stage.  It is important to have a period of “tools down” in order to do this. If the team continue to deliver while trying to take stock this will result in rework at a later point, increase costs, and even add time to the rescue project.

Assess the risks:  Identify and document the risks involved in the rescue project and submit a plan to mitigate them. Present this plan to company executives for approval.

Responsibility for delivery:  Make sure the organisation identifies someone who can span the whole project and ensure that they have access to all the stakeholders and delivery teams, and that they have the authority to run with the rescue project.  This is normally a Program or Portfolio Manager.  The PM will need to be someone who drives the delivery in the overall teams, has authority of the sponsor, and can make decisions for teams to pivot in the correct direction if needed.

Project Rescue Planning:  Review all the project documentations and conduct interviews with stakeholders in order to document what is required.  Transparency is very important so that there are no surprises later down the line.  Make sure each team confirms their responsibility in the rescue project.  Always remember that “You are only as good as your team.”  Make sure you have the correct people in the correct roles.  Induce a culture of trust and cooperation and let them clearly see that working together as a team and supporting each other is the only way to turn the project around.

Guidelines for planning:

• Ensure the project goals are clearly documented and communicated to the teams.
• Dependencies between teams are known and understood.
• Check that the architecture of the system forms the foundation needed to move forward.
• Focus on the revised Product descriptions (epics and stories) and the minimum viable product. Only deliver what is essential for success.
• Re-align the scrum teams, testing teams and dev-ops teams.
• Setup the communication plan for the project such as:
• Regular team meetings need to be held through stand-ups, development meetings, and weekly project meetings.
• Weekly sponsor meetings and feedback by the PM, being transparent as the objective is to regain the trust.
• Monthly updates to executives on progress.

Execution and Control:  The execution of the rescue project is vital, and you need to make sure your delivery is carefully controlled.  When issues arise address them at all levels, no matter how high in the organisation and do not be afraid to make bold decisions.  Simplify the delivery as you go as much as possible.  Keep the whole team informed and make sure key decisions are always communicated clearly.

Continuous learning:  If deliverables are not going to plan, make sure you readjust and get back on track as quickly as possible.  Reward great behaviour and delivery, thus creating a culture of performance and accountability within the teams.  In this way the teams will also be continuously pivoting and learning.

Rescuing a project can be one of the most stressful periods in a CTO’s career, so if you have a project that is just not going to plan and /or not delivering what it was meant to; then get in touch with us as we can help.