Guidance for building a credible plan

Glen Alleman suggests that you download this and put it to work on projects.  However, for some the defense focus and jargon are daunting or off putting.  My suggestion for putting this guidance to work: first transform the tables into a checklist or two. 

  1. The “validity” topic focuses you on whether a plan is ready for “prime time”.  Use this when evaluating early stage gates. 
  2. The “effective”  items are obviously relevant as one evaluates the quality of your projects’ execution.  These items should be a part of regular status reporting.

Then learn what “level of effort” means!

Still looking down in checklists?

Just saw this article of the power of checklists in medicine (here) which reminded me that I had forgotten to include a link in an earlier post (here).  Atul Gawande wrote a long piece in the New Yorker a little more than a year ago simply entitled “The Checklist“.  It is far too rich to summarize effectively — please read the whole article — but below are a few snippets

[I]t’s far from obvious that something as simple as a checklist could be of much help in medical care. Sick people are phenomenally more various than airplanes… Mapping out the proper steps for each is not possible, and physicians have been skeptical that a piece of paper with a bunch of little boxes would improve matters much.

In 2001, though, a critical-care specialist at Johns Hopkins Hospital named Peter Pronovost decided to give it a try. He didn’t attempt to make the checklist cover everything; he designed it to tackle just one problem, the one that nearly killed Anthony DeFilippo: line infections…. These steps are no-brainers; they have been known and taught for years. So it seemed silly to make a checklist just for them. Still… [i]n more than a third of patients, [doctors] skipped at least one. 

The results were so dramatic that they weren’t sure whether to believe them: the ten-day line-infection rate went from eleven per cent to zero. So they followed patients for fifteen more months. Only two line infections occurred during the entire period. They calculated that, in this one hospital, the checklist had prevented forty-three infections and eight deaths, and saved two million dollars in costs.

Still think your project is too complicated to benefit from a checklist or two?

Checklists and Change Programs

Jerry Manas’s post at PM Think (here) is a useful reminder to avoid a common error made when PMOs first implement processes and controls — over-engineering.   I can only say “Amen” to what Jerry notes:

We create forms, templates, and stage gates, in an attempt to gain control. But in doing so, we also create such barriers to implementation that it becomes like the Twelve Trials of Hercules just getting something implemented. P lus we lose flexibility (and I might add, credibility) as well. 

We’ve succumbed to that syndrome ourselves and Jerry’s prescription is a fine cure.  Our PMO finds checklists especially effective in two situations:

  • Initial design, communication, and usage of a new or changed process.  Checklists reinforce the basics and ease process adoption.  Only once the change program is past the awareness and understanding phases — in other words, early adopters are actually using the process — does developing sophisticated templates or tools make sense. 
  • Handling process handoffs.  Process and value chains are generally weakest where there are handoffs (e.g., between sales and delivery).  These handoffs are particularly severe when the personnel who accepted the leading process or phase deliverables aren’t directly responsible for the successor phase.  In this example, delivery management may have to accept/approve a statement of work, but the project manager hasn’t been selected.  Rather than force the PM to recapitulate the phase or process closing process, we use a checklist so the project manager can validate the quality of the handoff him/herself.

IT Capability Checklist for non-IT leaders

I liked this checklist from Susan Cramm (article here, Word checklist here) because it’s targeted at managers who are rotating through IT.   Obviously, it is a critical rotation in industries where IT can be a differentiator.   But getting involved with — never mind leading — technology projects can be a bit daunting.

Leaders who have worked in these roles do so with a mixture of excitement and apprehension. On the positive side, the prospect of charting new territories is incredibly stimulating. On the negative, it’s also frustrating – navigating IT can be like traveling in a foreign country without an interpreter or a guidebook.

The aura of the dawn of the computer age persists in the software business.  Many IT professionals insist that what they do is beyond the ken of normal humans.  Not so… IT is amenable to rational analysis [unlike my blog].  Cramm says it perfectly here:

It doesn’t have to feel this way. IT is just like any other business function – challenged with developing and delivering products and services to demanding “customers” in the context of constrained resources and changing competitive, organizational and technological landscapes.

%d bloggers like this: