How to Turn a Project Around

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. 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 3rd 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.

 

Next Webinar

Don’t Underestimate the Importance of Strong Leadership for Project Success

Written by Bill Dow
Bill Dow, PMP, is a published author and project management professional with more than two decades of experience in information technology, specializing in software development and project management. Bill has built and operated large project management offices (PMOs) and is the author of three project management books. The latest is Project Management Communication Tools, co-written with Bruce Taylor. Contact Bill at billdow@dowpublishingllc.com.
Share This Post
Have your say!
00
3 Comments
  1. I really enjoy your material (past and present)! A few additional thoughts I had about recovering a project.

    1. Can the scope be reduced?
    2. What change requests are currently being worked on?
    3. Is there to much dependency on a small number of key resources?
    4. Does the project depend on factors that are out of the PM’s control?
    5, What happens if you realize the project is really a program – usually a group of related projects working toward the completion of a single deliverable?
    Take care – Ron

  2. Thanks Ron, let me tackle them.

    1. Yes, it sure can be reduced, that is going to depend on when you tackle this recovery process, but yep, great option.

    2. Yes, change requests do play a role for sure. Again, some of those same change requests could be triggers into getting this project turned around.

    3. I like that, these resources are so busy these days and so many people are working on some many projects. Imagine if you have those super busy resources critical to your project, it could lead to failure for sure.

    4. Yes, that could happen for sure. A project could be a a pet project from an executive who doesn’t have a ton of power of influence in the organization, but wanting to make a org wide change. That happens and puts PMs in tough spots!

    5. So true, some times project explode into programs and the PMs are ready for that change. Or the org is not ready for that change.

    All great points, thanks for reading…

    Remember, you can always come find me and chat with me on my blog, LinkedIn, or my Dow Publishing LLC Youtube channel.

    Thanks again!
    Bill

  3. Good article, and I agree with Ron’s comments. But I feel there is one step missing. Reassessing the project schedule. Does it need to be changed to more realistically represent an achievable schedule? If not, a revised schedule should be developed, otherwise the project team is most likely working under unrealistic target dates. Once the revised schedule is developed, it must be reviewed with the team and reviewed/agreed upon with the sponsors. If the sponsors disagree with any revised target date(s), they have 3 choices. 1) revise scope 2) adjust resources (more, higher commitment to project, etc.) or 3 accept new target date(s). Bottom line, everyone needs to be on the same page with the (assuming) new target dates.

Leave a Reply