In this article we'll look at the actions you need to take to rescue a project.

Delivering IT projects is extremely difficult, and this is proven by the high failure rate. At least 65 per cent of projects are stopped before cutover, go over budget or don’t deliver the expected benefits. This is an astonishing failure rate, and it has been consistent for over two decades. The result is a high number of projects that must be rescued. Some projects have an immovable deadline regardless of the issues and challenges. A few examples include:

• A payroll system with a fixed delivery date due to the retirement of the application. 
• New systems or updates to existing applications to meet regulatory requirements.
• Delivery of complex operational, system, data, security and infrastructure changes when major organisations merge. 

Rescuing a project is always challenging, but when it has a hard deadline with operational, financial or reputational risks, this adds additional pressure.

What are the critical project rescue actions?

To illustrate the approach and actions, we’ll use an example payroll system project. 

The key points in this project are:

• The project has been running for a year.
• The new application must go live in four months. This is not negotiable.
• Failure to deliver the project will result in severe operational and reputational damage. (Staff not being paid is very serious!)
• The project has experienced delays relating to the new business processes, data quality, system configuration, integrations and testing.
• The support team has not been involved in the project.
• The dates in the project plan have been missed, and the stakeholders do not have any confidence that the project will be delivered by the required date.
• The RAG status is red.

Immediate actions in this scenario would include:

• Confirm the minimum viable product that must be delivered by the fixed deadline. In this example the ability to make accurate payments and calculate pension contributions correctly are must-have deliverables. Reporting is critical, but this functionality could be implemented after go-live.
• Review and confirm the status of all critical activities.

Questions to ask to determine the current project status

Minimum Viable Product

• What are the critical business functions that must be supported on day one after cutover?
• What is the roadmap for the other features?

Development/Configuration

• Has all development/configuration been completed?
• Is the handover documentation complete?
• Have any required third-party application upgrades been completed?

Infrastructure Build

• Has the infrastructure build been completed?
• Have all integrations, including BAU timings, been proven?

Data

• Have all data quality assurance activities been completed?
• Have the data migration activities, including timings for cutover, been proven?
• Has the data been signed off by the business stakeholders?

Testing

• Have the tests to date been valid? (Check that the data hasn’t been forced through to achieve test pass results.)
• Are the test progress reports accurate?
• Do the tests reflect real-world processing?
• Does the test data represent BAU data?
• Do the tests include data flow over the integration points?
• Have the tests proven the end-to-end timing of the complete business process?
• Have the security tests been completed successfully against the to-be production configuration?
• Has performance and non-functional testing been completed?
• Have all the end-user reports been tested?

Parallel Runs

• If required, have the parallel runs been completed?
• Will parallel runs be required after cutover?

Quality Assurance

• Have all quality assurance activities been completed?
• Is the project on track to achieve the agreed quality thresholds?

Training

• What is the status of training?
• Has the critical training been completed? If not, is it on schedule?
• Have the quick reference guides been prepared?

Dress Rehearsals

• Are dress rehearsals underway/completed?

Monitoring

• Is all system monitoring in place?
• Has monitoring been tested?

Superusers

• Have the superusers received all their training?
• Are they aware of their support role after cutover?

Cutover

• Has the availability of all cutover resources been confirmed?
• Have backup resources been confirmed?
• Where is the project in regard to CAB approval?
• Has the analysis of rollback or fix forward options been completed?
• Have the Go/No Go meetings been scheduled? 
• Has the go-live communication been prepared?

Handover to the Support Team

• Has the support team reviewed and accepted the project documentation?
• Has the support model been signed off?

Risk Assessment

• What is the current risk assessment?
• What are the critical risk management activities?

Stakeholders

• When was the last update to the stakeholders?
• Are the stakeholders aware of the issues and challenges?

Current Project Assessment

• What are the root causes that required project rescue?

Please note that these are example questions based on typical project rescue scenarios. Every project is different and will require individual analysis of the issues.

Critical Project Rescue Actions

Time is always of the essence when you are rescuing projects.

Please consider the following key actions:

1. Gather the information from the questions above as quickly as possible. If the information is not readily available, start planning by assuming that minimal progress has been made.

2. Base your assessment of the project on facts, not opinions.

3. Review the current plan, but don’t hesitate to create a new one. This is usually the best option.

4. It may be difficult, but please build in contingency wherever possible.

5. Review the critical path and be realistic about the effort required and elapsed time.

6. Start work on the critical actions immediately. Don’t wait until you have the plan complete. In a project rescue scenario, you do not have this luxury.

7. Resource constraints are a common theme on failing projects. Identify and secure the required level of resource as a matter of urgency. Secure the most skilled resource possible. This is always recommended, but on a failing project it’s critical.

8. Double-check the infrastructure build, security configuration, integrations and data. These items usually have long lead times, and a number of go-live prerequisites will depend on them.

9. Review all actions and complete as many as possible in parallel. If you are in a regulated environment, analyse the options to secure sign-offs without delaying progress.

10. Complete a risk assessment. Pathway has a simple, but highly effective, approach for risk evaluation. 

11. Review test progress to date and determine if dress rehearsals can provide the required level of assurance while the standard test phases are completed in parallel. This is an example of options that must be considered to deliver a failing project to a hard deadline.

12. Update the stakeholders with the revised plan. A note of caution: ensure that the plan is viable. The last thing you want to do is to go back to the stakeholders with the news that the team cannot deliver to the revised plan. The stakeholders will already have a high level of concern if a project is being rescued. Ensure you have a credible plan that can be delivered.

13. Manage all risks and issues proactively and review the status on a daily basis. (More frequently if required.)

14. If any activities in the revised plan turn red, hold short status meetings as many times a day as you need to in order to turn the activity green. Keep all stakeholders updated with your progress on this.

15. Schedule usiness and cutover dress rehearsals to ensure the highest level of readiness for go-live.

16. Prepare the information for the Go/No Go meetings and schedule them.

17. Ensure that the project team, support team and superusers are ready for go-live. A project that has been rescued usually requires a higher level of support after cutover.

Approach

It is essential to remain calm and focus on resolving the issues. If anyone starts to question why it has happened, politely explain that the circumstances will be analysed after the issue is resolved. Don’t be distracted; focus on resolving the issues as quickly as possible.

One of the keys to resolving issues efficiently is having the correct people involved. This includes subject matter experts (SMEs) and key business and IT staff.

Open, honest communication is critical.

Do not allow anyone to start apportioning blame. This behaviour will create problems with communication and morale and will delay resolving the issues. 

Lessons Learnt

As part of a professional project rescue, capturing lessons learnt is critical. This will, hopefully, prevent the same issues from happening again. The following approach has been proven on major projects and transformation programmes:

• Focus on resolving the issues and delivering to the deadline. This must be the highest priority.     
• Take backups of code, configuration, etc. as required to provide reference information for the lesson learnt report.       
• Prepare the outline of the report and add draft information as you work through the issues. Think of this as a rough draft for your reference. This should take a minimum amount of time, but it will save considerable time later. This approach will allow you to deliver the report shortly after go-live.

The report should include a summary of the project status when the rescue activities started, the core issues, the root cause of the issues, actions taken to resolve them, current project status, additional support requirements, and recommended actions to reduce risk on future projects. (Please add additional information relevant to your projects.)

The lessons learnt meeting should take place as soon as possible after go-live. It should include the project team and all business and IT stakeholders.

The tone of the meeting is very important. Make it clear at the start of the meeting that the objective is to ensure future projects are not impacted by the issues, and it is not about apportioning blame.  

Summary

Rescuing a project is challenging, but it is rewarding when it is delivered on time. Always be realistic about the potential issues after go-live when you rescue a project. It is best practice to let the stakeholders know that the organisation may encounter issues and plan support accordingly.