+64 4 499 1701
Mon - Fri: 07:00 am - 05:00 pm
Follow
BRAND NEW AGILE TECH!
Psoda is bridging the gap between physical and electronic kanban boards
Learn More
>
BRAND NEW AGILE TECH!
Psoda is bridging the gap between physical and electronic kanban boardsLearn More
>
Title Image

How to rescue a project in trouble

How to rescue a project in trouble - who, what, why, how, when, who

Welcome to the latest “Ask a project manager” blog. This week’s question is about how to rescue a project that’s in trouble.

Our questioner asks:

I’ve got a bit of a dilemma. My boss has asked me to take on a project that’s in real trouble and I don’t quite know where to start. I’m worried that I’ll make the situation worse and end up harming my own career in the process. Help.

Thanks for getting in touch. Firstly, congratulations – you must be a really good project manager as, in my experience, only the good ones are asked to fix projects that have gone wrong.

Why do projects get into trouble?

Projects get into trouble all the time. In fact, the PMI’s 2018 Pulse of the Profession showed that more projects are failing than in the previous year.

They get into trouble for all sorts of reasons, but some of the more common ones are:

  • Scope creep
  • Budget over runs
  • Inaccurate requirements
  • Poor change management
  • Key people either leaving or not supporting the project

It’s normally a combination of problems that have come together and created a perfect storm.

Recovering the project

So, you’ve been given the project – where do you start? There are a number of steps you should take to resolve the situation.

Current state assessment

Before you even start trying to plan the recovery you need to know what the current status of the project is. The best way to do this is to audit the project. If you can, it’s worth getting an expert in to do this bit of work as they’ll know exactly what to look for. If you can’t, here’s a process you can use:

1. Document review

The document review will give you a lot of critical information. You should be able to understand exactly what the project was supposed to deliver, when and how it was to deliver it. Documents you need to review include:

  • Project requirements specifications
  • Project charter
  • Contracts
  • Project plans
  • Work packages
  • Budgets
  • Resource plans
  • Quality plans
  • Metrics
  • Stage gate reviews
  • Status reports
  • Change requests

When you’re reviewing the documents there are a number of red flags you should be looking for:

  • Vague or incomplete requirements. These set the project up to fail. Poor requirements mean that everything the project does is built on sand and it will likely be subject to a lot
    of changes throughout the lifecycle.
  • Unrealistic benefits in the charter. This indicates that the project manager and sponsor don’t have a handle on what it is they want to achieve with the project
  • Too tight or too loose contracts. Both scenarios are bad news. Too tight, means there’s less wiggle room when needed and too loose means anything goes.
  • No work packages or work packages that are light on details. As these are the key documents for the people actually doing the work, they won’t deliver what you want them to deliver
    if they are short on details.
  • Lots of change requests. This is one of my big red flags. This tells me that either the project hasn’t been planned properly in the first instance or that the tolerances are too
    low.
  • The names of people assigned to the project keep changing. Again, this is a big red flag to me as this can indicate serious morale problems. It can also be a sign that the business
    has lost confidence in project.
  • The Gantt chart is updated too often or not often enough. By looking at the updates on the Gantt chart, you can see if the project manager has a handle on what’s going on or has
    let things slip. Personally, I find if it’s being updated more frequently than once a week the project manager is too into micromanaging. If it’s updated less than fortnightly,
    then the project manager has lost control.
  • The number of versions the documents have gone through. This might seem a strange one but if there are too few or too many revisions it can indicate a disengaged steering
    committee, or an overzealous one. Both of which are bad news.
  • Project status reports have no bad news. If the project status reports are consistently Pollyanna in their outlook, this tells you that you either have a project team in denial or
    one which doesn’t care. Not good.

Once you’ve finished the document review you should have a good idea where the project’s at. It’s time to move on to the next phase of the audit.

2. Interviews with the key stakeholders

Never underestimate the power of a face-to-face interview. This is often the point where you’ll get to the real root cause of the project’s problems.

You should aim to sit down with the following people:

  • The client(s)
  • Project team
  • Project steering committee
  • Sponsor
  • PMO

You’re looking to get insights into why those parties think the project is in trouble and if they have any ideas on how to get the project back on track. This can be a useful source of information you may not otherwise get access to.

Questions I tend to ask are:

  • Why do you think the project is failing?
  • How do you think it can get back on track?
  • Should it be revived?

During the interviews, make sure it’s clear that anything said is confidential and that you’re looking for a full and frank discussion.

3. Document your findings

You’ve finished the audit, now it’s time to document the findings. You’ll be making a recommendation at this point as to whether you think the project is worth saving or not. You need to make sure you present all of the reasons the project is failing and include any remedial actions you could take to bring everything back on track.

I’ll be very clear here – if you think the project cannot be saved, you need to document that here. You will be presenting your findings to the project steering committee and they should sign off on any recommendations. This will be your formal record.

This point is worth reiterating. This is your only realistic chance to tell the steering committee that the project is not worth saving. Do not commit to salvaging the project if you do not believe it is salvageable. The damage to your reputation is not worth it!

In reality, some projects just cannot be saved and as the project manager you need to be able to make a judgement call as to whether it is worth the time, effort and expense of trying to recover a project – or if it would be better to simply close the project down and start from scratch.

Recovery plan

You presented your findings to the steering committee and they have given you the go ahead to recover the project. Before you can begin, you need to develop the recovery plan.

Bear in mind that this plan is not the same as a standard project plan. You’re going into a very tricky situation where team morale is likely to be low and you’re going to face resistance. Once this project has been re-baselined it cannot, under any circumstances, slip again. So any plan you do develop needs to be realistic and achievable.

Your project is going to be under extraordinary scrutiny by a number of different people so you must be ready to defend any actions and decisions you make.

Your recovery plan needs to include:

  • How you will address fundamental changes in scope, time and cost
  • The monitoring and control mechanisms you will employ
  • How you will communicate, as well as the frequency of the communications
  • The ways you will improve team morale
  • Establishing and controlling the project schedule
  • Project reporting requirements
  • Actively manage risks and issues
  • Conflict resolution
  • Project tolerances and metrics

Once you’ve got the recovery plan documented you need to present it to the steering committee. Don’t start work without the formal approval of the steering committee! They need to formally sign off on the plan first.

Work the plan and report the progress.

In some respects, this is the easiest part of the recovery process. You’ve got a plan and now you follow it.

All work should have formal work packages that are agreed with the people who will be doing the work. These should contain tolerances and reporting requirements as well as the details about the actual work to be done.

Be prepared to be a micromanager. This is not a recommended management style under normal circumstances. However, in the case of a troubled project it is unfortunately the only one that’s likely to work. You need to be all over everything. At the slightest hint of a problem, you need to have it resolved and bring the project back on track.

You will need to track the project schedule meticulously, record reasons for any deviations, recalibrate the plan regularly – normally fortnightly and under no circumstances commit to a new baseline unless it is achievable. You will also need to make sure you are actively managing your risks so that they don’t turn into issues. During a recovery project, issues can be fatal.

Report on progress religiously. By letting the client, steering committee and other relevant parties know how you are tracking with the recovery plan, you will build confidence in your ability. Don’t be tempted to hide anything that’s going wrong. If you need help, ask. Remember – everyone will be invested in this project succeeding!

I hope this has helped and has given you a process you can use to recover your project. Please let me know how you get on!

Psoda plug

If you’re looking for a tool to help you recover projects that are in trouble, or to make sure they don’t get there in the first instance, then look no further than Psoda. With our interactive dashboards you can monitor, track and report on portfolio, programme and projects in real time. Helping you make quick, efficient decisions. Sign up for a free trial today!

Post a comment