Preparing for Project Rescue: Diagnosis

In my last project management blog post, I talked about performing triage on a project portfolio.  Over at the Oracle Infogram blog, they picked up on our post with a reminder that triage is a pervasive activity, and one that is essential to project management:

“Triage runs from the queuing on the CPU all the way up to the user’s daily calendar entries, it is a concept that should always be kept in mind when planning and building projects.”

The result of the triage effort is to identify those projects most in need of immediate intervention.  Just as in the medical world, the next step after triage is diagnosis; now it’s time to focus on projects in the third group and perform project diagnostics. If you are tasked with rescuing a failing project, here are the first steps that you should take to find the root cause(s) of the project’s difficulties.

patient history1. Obtain a thorough patient history: Skilled medical diagnosticians may not rely solely on the patient’s recollection. In some cases they need to interview family and friends to obtain information on subtle symptoms.  Likewise, the skilled project diagnostician should combine the skills of Dr. Gregory House and Dr. Cal Lightman.  When trying to diagnose failing projects, they shouldn’t don’t rely solely on direct interviews of the project team. A multi-perspective view of the situation is needed:

  • Have a closed-door session with the project sponsor: Find out what the key issues are with the project and begin to explore areas where a rescoping might help bring things back on track. Find out what kind of scope reductions are likely to be accepted by the business, and which might require significant salesmanship or a fierce battle. Understand the organization’s politics so that you can factor them into your corrective action plan.
  • Talk to the project stakeholders about their original expectations, their current concerns, and any difficulties they may be experiencing with the project team.
  • Create comfortable communication channels with all members of the project team, and dig deeper than project plans, status reports and issues logs. Find out what is causing project anxiety within the team.  There are often valuable clues here. Be sure to probe any areas that are glossed over or brushed aside quickly.

 2. Next, take the project’s vital signs:

  • Pulse check: Assess the burn rate. Are you eating up budget faster than you anticipated? What is the new estimated total cost?
  • Blood pressure: perform a risk assessment, in terms of what could happen between now and the go live date to cause a significant incident. Various frameworks exist for this assessment. The Six Sigma FMEA template can be modified to suit your needs here, giving you an objective framework for assessing all possible places where your solution could fail, and steering your future corrective actions toward those that have both the highest likelihood of occurrence and greatest criticality.
  • Temperature:  Red yellow green heat sheet with respect to key milestones. This should be part of your regular status report, along with some basic trending. For example, we once managed a huge portfolio of interdependent concurrent projects with weekly reviews that tracked both last week’s and the current week’s milestone status. Because we were in an M&A situation facing TSA deadlines, we had not time to bring up robust project portfolio management tools, so we kept things moving with simple, homegrown Excel tracking tools.
  • Other specialized diagnostic tests as needed—assess the scope (original and current), review the technology strategy, development strategy, testing strategy, release strategy and change management strategies.

After performing these steps, you should have insight into why the project has gotten off track. Our next blog post will cover some of the intervention steps to take after the diagnosis is complete.

4 thoughts on “Preparing for Project Rescue: Diagnosis

  1. Thanks for the mention of our blog, but could you correct the name? It’s the Oracle Infogram. The title came about because we use it as the foundation for a customer newsletter. But if you call something ‘newsletter’ people just delete it. So I called it the Infogram. That way people open the email, look at it, say ‘oh, a newsletter’ and delete it. but we get that extra two seconds of attention while they determine content. And some people have reported actual instances of reading it.

  2. Dear Joanne, thanks for discovering and sharing another splendid medical analogy! Since now I have also discussed medicine approaches as beneficial for business, especially project management. My concept of value added project management office (PMO) is built from running a clinic, where dr. House could be the PMO manager, and healing the patients is running the projects. Both, projects and patients depend on usage of different specialists, etc etc… Since my wife is a MD i get these kind of enlightenings all the time.

    Here’s a rough Google translation from slovenian language of the article “PMO as a clinic”: http://translate.google.com/translate?prev=hp&hl=sl&js=y&u=http%3A%2F%2Fprojektni-blog.blogspot.com%2F2009%2F01%2Fprojektna-klinika.html&sl=sl&tl=en&history_state0=

    Keep up the good work! I’ll be following your posts,

    best regards
    Primoz

  3. Pingback: DRAFT: Restoring Projects to Peak Performance « Edgewater Technology Weblog

Leave a comment