Book review: Rescue the Problem Project

(This post contains affiliate links. Read my full disclosure.)

By the time I was half way through the introduction I liked Todd Williams. I liked his way of thinking, his faith in project management and in people, and his ability to tell stories. I was sold on the idea of a book telling me how to rescue a problem project, even though I wasn’t working on one. Let the lessons begin.

Todd Williams’ book, Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure, really does live up to its name. If you were ever in doubt about how to spot a project teetering on the brink of going ‘red’, then this is the book for you.

A five step recovery approach

Williams presents a five step approach to project recovery. The steps are:

1. Realisation: you must recognise that there is a problem before you can attempt to solve it.
2. Audit: carry out an objective project audit to determine the problems.
3. Analysis: analyse the data from the audit to establish root causes and begin to form the solutions.
4. Negotiation: mediate between the parties involved to establish an acceptable solution.
5. Execution: implement the recovery plan.

So, when you are faced with a project that has fallen off the edge of a cliff, should you stop it completely so that you can put this five step approach into action? Absolutely not. Williams recommends that instead of stopping the project, you should “slow the bleeding”. He writes:

To properly diagnose a system, it must be running. Stopping the project also stops the errant behavior and makes it difficult to find problems and their root causes… Although some situations may benefit from stopping a project following either the audit or the analysis, these are rare. A better approach is to slow the bleeding by implementing remedial fixes.

Whose fault is it?

When a project falters, the easy option is to point to the project manager and blame her. But is it really the fault of the project manager when it all goes wrong? Williams doesn’t think so—at least, he believes that there is more at play than just one person not doing a very good job:

Projects become red because they faltered under the guidance and supervision of the existing steering committee, project sponsor, executive management, and PMO. This group of executives has failed to identify and correct problems before the project fell into serious trouble…The project manager should be accountable for all that has gone on, but the project’s management should have checks and balances to minimise the chances of failure.

In some cases, the problem does not lie so much with people but with policies. Williams writes about a software development project where internal IT policies prevented the product from being tested on computers outside the company’s firewall. As a result, many bugs were missed, the deployment was a disaster and customers were unhappy.

Issues can also arise through poor methods, or poor application of methods. “The organisation’s project management philosophy may be a poor fit for the project,” Williams writes. In short, there are many reasons why projects fail. Analysing the reasons is important, but assigning blame to an individual or group of individuals is rarely the largest part of getting a project back on track.

I enjoyed this book because it felt new. I read a lot of project management books, and many of them—especially those aimed at non-academics—are not half as ‘new’ as this one. You don’t have to be working on a failing project to get some value out of Rescue the Problem Project, because the case studies will help you avoid getting to this position in the first place. But if your project is troubled and constantly reporting a status of Red or Amber, then get your hands on a copy now.

Buy on Amazon.co.uk