Book review: Rescue the Problem Project

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

Project Management book coverBy 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 Failureir?t=wwwelizabharr 21&l=as2&o=2&a=0814416829, 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.ukir?t=wwwelizabharr 21&l=as2&o=2&a=0814416829

 

12 Comments

    1. Tracy – glad you are enjoying it! It is a good, comprehensive read. I just hope that you aren’t in a situation where you have a project to rescue…!

    2. Tracy – glad you are enjoying it! It is a good, comprehensive read. I just hope that you aren’t in a situation where you have a project to rescue…!

  1. Interesting review, I agree it’s a clever idea for a book, given so many titles assume away the possibility that you’d ever get into trouble with a project as long as you’re following their advice, and yet so many projects fail. And I totally agree with this “assigning blame to an individual or group of individuals is rarely the largest part of getting a project back on track.” 
    The other thing I’d love to see more of though it reference class forecasting, I think that with estimates more grounded in reality (i.e. historical data on how long tasks tool in the past) we’d have fewer “red” projects in the first place.

    1. Simon, this is a really good point, thank you. For all we talk about lessons learned and post-implementation reviews, I don’t feel that project management as a discipline is particularly good at learning the lessons of the past. We have a lot of real data to help with future forecasting, but it isn’t often captured in a way that makes it useful for new estimates. If you have any tips on that I’d be pleased to hear them!

  2. Cool, I really enjoyed your blog about rescuing a problem project.. which can end up in either the “round file” or the deadzone.   Here is a blog post you might enjoy on “The Piddle Principle” as we call it. 

    Thanks again for the interesting info from your book.
    Catherine
    [link removed as no longer working]

    1. Hi Catherine, thanks! The Piddle Principle is an interesting idea about how small things make a difference. Systems thinking isn’t used much in my project management world, but it’s a really valid concept that I think we should adopt more, especially in situations where projects need rescuing. Sometimes changing a small thing makes all the difference.

  3. Great review, Elizabeth! Todd’s been a cornerstone of the online project management community at least for as long as I’ve been a part of it. I really love the quote about “slowing the bleeding”. It makes so much sense, doesn’t it? If you stop the project dead before you investigate, you force all the bad stuff underground where it can’t be properly identified.

    1. Absolutely! Project managers shouldn’t be at all scared of recommending that projects are slowed down so that proper investigation can take place.

Leave a Reply

Your email address will not be published. Required fields are marked *