The black art of “project rescues” explained

In my career I have focussed a lot of energy and time on “project rescues” – the bigger the problem, the more hostile the stakeholders, the worse the management controls, the greater the lack of belief, the more complex it becomes to disentangle the situation, the stronger the blame game … yes, you get the picture.

I know so many Project Managers who simply bail out when they see a project going wrong, or if they’re brought in to fix a situation up that’s gone to poo then they won’t go anywhere near these situations. They don’t want to deal with someone else’s stuff up. They think they’re going to fail too. They’re scared it’s going to destroy their career. “Too much risk” they mutter, and slink off, Gollum-like, into the darkness.

Well, I’m here to tell you that as far as I am concerned one of the best jobs as a project manager is “project rescue”.

“What?!” I hear you cry, Dear Reader? “Young Tippo’s been on the vino collapso again!”

Nope. I really mean it. Indeed, as long as you apply a few basics up front then you can have a lot of fun.

Think about it, the very worst job you can do, when everybody thinks you’re going to fail, is to meet their expectations. Yet ironically, it’s exactly when everything has gone to pot, that it’s so much easier to make a significant difference. Give me a real juicy crisis, every time. I love them.

How many Project Managers does it take to deliver a project?

A mate of mine measures project complexity as a “One PM”, “Two PM” or “Three PM” project.

With a “One PM” project, his theory is that some projects will be delivered by the first PM assigned. The sponsor, users, and business understand their roles and the company has a level of maturity to deliver the project.

In a “Two PM” situation, the stakeholders need to get a shock when the project dives and, after appointing a new PM, with wider powers and more respect, they will pull their socks up.

And sadly, other projects require the stakeholders to feel repeated pain to finally be serious about taking ownership. They are a “Three PM” project, or sometimes, terrifyingly, even more.

The trick, my learned friend told me, was to ensure you were always the final PM – the Third PM – so you delivered the goods.

As I’ve focussed much of my project management career on project rescues I’ve often been the second PM in a “Two PM” project or the third PM in a “Three PM” project and – as happens – on a couple of occasions, I’ve sadly been the second PM on a “Three PM” project, too. That stinks. Don’t go there. Good for your experience level, bad for the blood pressure, and someone else gets all the kudos.

My advice? Don’t be Sisyphus.

Remember Sisyphus? He was the guy who was sentenced to push a rock up a hill all day long, but just as he gets it to the top, it always rolls down again. Day after day, forever.

Let’s look at how many rescues are approached.

Okay, so let’s say the project has turned turtle and the rats are heading overboard at a rate of knots – we’re talking Cost Over-runs, Missed Deadlines, Dysfunctional Team, and, as night follows day, Jobs On The Line.

Obviously this must all be the Project Manager’s fault (*cough*). The sponsor decides he/she needs a new, stronger, more experienced Project Manager and one is duly assigned. The new Project Manager downs a strong Double Espresso and does something like this:

1. Determines the current status of the project by reviewing all the tasks to determine exactly where it’s at, with a particular focus on budget and schedule. (Fundamental to regaining control is that you have a known – and hopefully agreed – baseline.)
2. Next, our PM re-confirms the aim of the project. And then works out the best way forward.
3. And builds a detailed Plan. And is rigorous. And. And. And.

After a while, though, it becomes clear that the deck chairs on the Titanic have been moved around, but the iceberg is still embedded squarely below decks and it’s now women and children first time. Because what the new PM is doing is eerily similar to what his or her predecessor was doing.

So why would you think you can do the same things – only better, of course – and achieve a different outcome? As we all know, doing the same thing and expecting a different result is a widely accepted definition of madness.

So let me suggest another way. I do not say my way is better – it just suits me well and works well with my approach. Well, actually, I do say it’s better, I just acknowledge that you really have to believe in it – and work it – for it to be better.

First: understand why projects fail

Okay, I’ve previously written about what it takes to be successful at delivering change and the obvious reasons of failure:

1. Lack of active user involvement
2. Lack of executive support
3. Inappropriate project management rigour (whether that means too much, or too little)

You see, projects are about people. They’re not about process. Not about budgets. Not about plans. Not about BAC, COQ, EVM, LOE, OBS, PSWBS, RAM, ROI or even my personal favourite SWAG. (A gold star – no, hang it, a bottle of bubbly – to whoever emails me and names each of those first).

Sure, they’re all important. But it’s people that make or break a project. So first, stop and ask:

• Is the executive strong enough to drive the outcome?
• Are the users involved so they will drive and accept the change?
• Is everyone working towards a common goal?
• Is your sponsor measured on the success of the project?
• Is the level of project management control appropriate to the culture of the organisation?
• Are the team’s needs being met?
• Are the team members valued?
• Are their partners happy with the hours they’re working?
• Did they miss out on seeing their kid’s graduation because they had to work and no one gave a damn they missed it?

That’s right. Understand the human side first and foremost. Because the best discipline in the world won’t deliver without people.

So what’s our methodology for success in these situations?

What follows is pretty much a very high-level view of The Different Company’s approach and we do a little fine tuning depending on the client’s culture. I’ll focus on the stuff we do up front, as this is to me the key to a successful outcome.

1. Determine if you have the necessary support to succeed before you accept the job, no matter how desperate the client is or how much they’re prepared to pay. Indeed, if they are totally desperate and paying over the odds, listen to the alarm bells that should be ringing loud and clear. Don’t worry about their budget – first worry about whether you will be supported.
2. Get all stakeholders aligned, and re-confirm the aim of the project and agree the measures of success.
3. Determine the status of the project and the necessary adjustments needed – up to and including, perhaps – kill it, even if that means you walk away after a short while.
4. Agree and re-baseline.

The project is in the red. Can you rescue it?

The first thing you want to know is whether you have the support to succeed. Without this support you can’t succeed, no matter how talented or hard working you are.

1. Meet all the key people. That means the sponsor, the previous PM if you can, the project team, the project control board (PCB), and all users. All of them. If you can’t, listen to those clanging bells again.
   1. Explain your approach.
   2. Determine if they are each senior and empowered enough to do their roles. And do they understand their roles? Do they have the right skills? Will they perform when the going gets tough? (The going will get tough. It always gets worse before it gets better. Always. Immutable Law of the Universe, trust me.)
   3. Ask them each to describe the scope of the project (both inside and outside the organisation) and what it is trying to achieve. How will success be measured?
   4. Work out what all the hot buttons and contentious issues are. Why did the project go red? What is it going to take to fix it? Can it be fixed? What needs to be done differently? Do they really want the change? No matter what, NEVER denigrate the previous Project Manager – it’s easy to knock someone when they’re vulnerable, but often the best thing you could do is retain them for their historical knowledge.
   5. Meet with the sponsor again.
      1. Present what you have found and make any recommendations (e.g. “I need more user representation”.)
      2. Ask directly if the sponsor will support you should you recommend killing the project – even if you don’t want to at this stage – this is a simple and critical test of their level of support and influence, and personal courage.
      3. Decide if you have the support to take on the job.

And last but by no means least: if you don’t have the support, but must take the job, then be a good PM and make sure you log the risks, and get them mitigated, in advance.

Now. Get some alignment.

Other than anecdotally – through the meetings you’ve had – you haven’t drilled down into the detail of the project yet. Many traditional approaches would have this being the first thing to do – get the known baseline. But I must confess, I don’t like doing unnecessary work. Why do all that detailed review now if we are going to bring to the surface an impasse between key stakeholders that simply cannot or will not be successfully resolved?

So let’s use our noodles. Before we do anything else, it’s now time to get everyone on the same page.

1. Have the sponsor call an extraordinary Project Control Board (PCB) meeting.
   Fully brief your sponsor beforehand. Prepare a detailed agenda and supporting packs. Your sponsor MUST chair the meeting – all PCB meetings – don’t let them defer to you. This will ensure they know the status of the project at all times and own the results.
2. I follow this general agenda
   1. Formalities.
   2. Outline the Project Rescue approach and that this meeting is to ensure alignment.
   3. Agree the intent of project.
   4. Agree the project drivers (see below).
   5. Agree the critical success factors.
   6. Gain agreement on all contentious issues and hot buttons identified.
      Use the agreed project drivers to resolve the issues.
   7. Agree what success would look like.
   8. Agree who the stakeholders are and who’s involved.
   9. Agree next steps.

And now?

i.     You will now do a detailed review of the project.

ii.     You will compare today’s outcome against the project’s status.

iii.     You will comeback with Project Change Requests to ruthlessly cut any activity not directly aligned with today’s outcomes, or

iv.     You will comeback with a recommendation to kill the project.

OK, now let’s get on with some great Project Managing!

Project still happening? Right, now it’s time to determine the current status of the project.

• Review all the tasks to determine exactly where it’s at.
• Identify the stuff that isn’t aligned with the PCB’s intent.
• Look for anything that’s delivering something that doesn’t achieve the project’s critical success factors, and raise a Project Change Request (PCR) to kill it.
• Look for scope creep, and raise a PCR to kill it.
• Focus on scope, budget and schedule.
• Raise a PCR for all the changes you’re making and present them to the PCB for approval.
• And remember, if the project is a basket case sometime the most humane thing is to put it down.

Once expectations have been re-set and PCRs approved, re-baseline the project and get on with managing it.

I’ll leave you with a couple of ground rules to help you settle in with your new team

1. Once again: never – never – denigrate the previous PM. This person was working with the team and it’s very possible he/she is still their friend, or at least someone they sympathise with. You weren’t there, you didn’t know all the ins and outs. They won’t warm well to someone coming on board and knocking his or her work – apart from anything else, they’ll take it that you’re knocking them too.
2. Build the team up. The project team’s morale, having lived through the stress of the failing project, is likely to be at an all-time low. You’re going to need to navigate this mine field with a deal of sympathy and a lot of empathy. Show you support them, involve them, and have faith in them. If you really don’t have faith in someone, manage them out humanely.
3. Give the team something to strive for! Find out what each team member wants to achieve, whatever it is. A new role as a PM? More money so they can better support family back home? Strengthen a particular skill set to advance their career? Then find a way to help them achieve it. You may not be in a position to give it to them but there’s normally some way you can help them progress and nothing builds success like the team thinking they have an advocate who cares about them as individuals.
4. Explain the project’s drivers to the team and ask them to let it guide their decision making. Trust in them and they’ll reward your trust with better productivity and higher quality.
5. Hold your sponsor and your PCB accountable. Don’t let them slack off and leave it to you. The moment you do you’ve entered the slippery slide to red from which there is rarely any return …

Finally, I’ll leave you with this quote.

When the best leader’s work is done the people say, “We did it ourselves.”  Lao Tzu

Addendum: The Vital Importance of “Project Drivers”

One of the most important things we do when picking up a project – any project – is to have the PCB agree what the key drivers for the project are.

Note: the key drivers are not your project’s intent or critical success factors, rather, they are the main drivers for decision making. Is meeting budget more important than meeting the schedule? Is having a resilient solution the most important outcome?

By sitting down and having the PCB agree to the top three drivers, in order, it gives you and your team a framework on which to base all decisions going forward. It makes your life so much easier and gives you something to refer back to justify decisions during a project audit.

In a basic form, have your PCB rank Schedule, Budget and Quality/Scope in order of importance. This simple analysis will help drive many of your decisions.

In a recent project, for example, we went to the next level of detail when we understood that Quality/Scope was more important than the budget and the schedule (within reason of course).

So we then further defined the following drivers: 1 Resilience. 2. Simplicity. 3. Scalability. Armed with this knowledge the architects could design a solution that best met the PCB’s drivers without constant referencing back.

Rob Thomsett in the Agile Project Manager’s toolkit uses the following seven drivers which are ranked against each other using a concept of sliders where they can move from ‘off’ to ‘on’ or any shade in between.

1. Satisfied Customers
2. Objectives
3. Budget
4. Time
5. Add Value
6. Quality
7. Satisfied Team

No matter which approach you use, life is a lot clearer when you understand these drivers and can refer back to them to support the decisions you need to make every day.

And if you ever find the PCB start weighing in with something other than your drivers then it’s time to re-set the drivers and get a new agreement.

Remember, good decision-makers are exactly the same as the rest of us. The only difference is they make more decisions.

And if they make a wrong decision? They make another decision.

The Different Company uses proprietary IP, ethical standards and street smarts to deliver project management outcomes that directly benefit your organisation and the community. Can we help? We’re always ready for a confidential chat. Just drop us a line, or give us a ring.