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!

Big picture = big map (HT @galleman)

Now that I’m somewhat out from under, I’ve caught up with some of the usual suspects on my reading list.  Glen Alleman is timely with another reminder (here) that an integrated master plan is essential.

Program-level plans are as welcome in IT circles as garlic on a Twilight movie set, and I’ve never quite understood why.  As Glen notes elsewhere, you need a map to know where you’re going.  But too many IT folk believe that such “high level” pictures are only needed because their managers as pointy-haired buffoons.  These “detail” men believe that the only valid plan is one derived from detailed task-level plans.

But consider the map metaphor.  How many of us would try to assemble an itinerary from the individual turn instructions?  We wouldn’t, naturally.  We pick where we want to start, how we want to travel (boat, plane, car, or on foot makes a difference), and where we want to end up.  Paper, Google, and program maps get built the same way: you need to know where you’re going to know when to turn (or not).

%d bloggers like this: