One of the hardest things to do when you are deep into managing a project is to see precisely when it is going off the rails. Meaning, you are so busy working the project day-to-day that it could start to have significant issues, and you won’t notice. Or you do see you are having problems, but you don’t know what to do to recover the project.

Well, the project recovery process does not have to be that hard, and you do not necessarily need high priced consultants to come in and fix it for you. Let’s spend some time now and look at a simple 3-step process to recover a project.

Steps to recovering a project

1. 1. Determine how the project was managed.
   2. Determine how the development methodology was completed.
   3. Determine how well the project was adopted.

Sounds simple right?

Well, not really, but that’s ok. Let’s spend some time now and look into exactly how we achieve each of those steps. I think you will find it is easier than you think.

Before we start, it’s important to note that you don’t have the current project manager do this (he/she may be too close to the effort and won’t be objective anyway). It is a best practice to have a 3^rd party person do this assessment. Then, you will get the most objective viewpoint.

Step 1 – Determine how the project was managed

There are four main things to look for in this process:

• PM Methodology – How was the PM hygiene of the project managed? Are the Risks and Issues current, does the project have an updated project schedule, and do we hold weekly status meetings?
• Customer Engagement – How engaged was the customer on the project? Did they help you throughout the project? Were there missed meetings, or emails left unresponded to?
• Organizational Change Management – Were any change management methodologies applied to the project to increase adoption? Did people know it was coming?
• Risks/Issues/Roadblocks – What were the roadblocks, big issues, and risks that the development team faced? Have they been resolved? Do we know who we need to fix them?

In this step, you are tracking how well the project manager managed the project. I would strongly suggest you use a project audit form for this process as it will provide you with a detailed list of the items you are looking for—meaning which ones are there and which are not there.

Step 2 – Determine how the development methodology was completed

Just like the first assessment, there are also four main things to look for in this process. Let’s look at these now:

• What development methodology did you use? – Was it working, did all players play their part, and was each step followed? Was it a hybrid of both Waterfall and Scrum?
• Roles and Responsibilities – Did the project have a RACI? Was it followed? Did we have all the team members for each component of the project? Was the project to produce PowerBI reports, but a report developer never hired, for example?
• Team Issues – How well did the team get along? Were there significant issues? Did we have some team members not supporting each other?
• Risks/Issues/Roadblocks – What were the roadblocks, significant issues, and risks that the development team faced? Have they been resolved? Do we know who we need to fix them?

Development teams can have many challenges, especially nowadays. When we are cramming Waterfall and Scrum together (“Waterscrum”), it can cause some big issues in the development portion of the project. Watch for these things on the project! Perhaps they were the reason the project went off the rails.

Step 3 – Determine how well the project was adopted

If there was anything I could do over looking back at my career, it would be to put more attention and focus on adoption and customer readiness. Time and time again, we see how important it is to the success of a project. As with the other two steps, there are four areas I would suggest to review in this last process:

• What OCM methodology is the project using? – Was everyone familiar with it, and was the process used from the start of the project, or just at the end?
• Were the customers connected? – Again, we see low adoption rates because the customers are not connected to the project. Using a structured OCM methodology on the project will help bring along your customers and increase their support for the project.
• Mandatory or optional – One of the areas we find in organizational change management is around the leadership’s requirement on the use of the product. If the leadership team does not require people to use the product, it significantly reduces the adoption rate.
• Risks/Issues/Roadblocks – What were the roadblocks, issues, and risks that the development team faced? Have they been resolved? Do we know who we need to fix them?

What do you think? It’ really not that hard when you break it down into these three simple steps with four areas to focus on each. It is essential when recovering a project that you have a structural process to follow. I hope that what I have outlined above will help to point you in the right direction.

I look forward to your comments and feedback! And to learn more, please watch my on-demand webinar on the topic. We cover some of what is described above, as well as what you should document and report your findings.