Project Planning Requires Simplicity, Not Volumes of Standards

by Ross Sivertsen | Dec 30, 2009 | Blog, Uncategorized

I'm surprised at how complicated the subject of project planning has become. I have served on the board of directors of a couple of non-profit organizations, and as the CIO of a small publicly traded company.

It’s surprising to me, though, how many organizations either
can’t or don’t think in those terms. Project management is seen as either too
complex, or out of reach for some organizations.

From my experience, simplicity is a key factor in planning
and communicating projects.

I believe anyone would agree that in terms of process
maturity just beginning the act of planning, and thinking in terms of some
things must be done before others, takes a project from being ad-hoc to almost
achievable.

So, for me, I boil project management down to few very
simple things:

• Before you do ANYTHING else, decide where you
  want to go, and clarify the goal with all of the project stakeholders. As the cliché
  states, “when you don’t know where you’re going, any road will get you there”
  is true in both life and managing projects.

• Once you’ve identified the goal in terms of
  where you want to go, start listing out the what’s about what the goal looks
  like when you’re finished. I break requirements gathering in to very simple to
  understand pieces of information, I also don’t use the term “requirements” I use
  something more approachable like a “Needs List.” Each need (requirement) have 5
  attributes:

a.      
For each requirement use some type of unique
identifier, I use numbered lists, but they could be anything simple and unique.

b.     
Describe the need (requirement) in 4^th
grade English. It’s easy to have an academic understand the requirement. But when
you can describe the need so that your 4^th grade daughter or son can
understand it, then chances are YOU understand the requirement. Don’t be overly
legalistic here, if the need appears to be too ambiguous then you should strive
for further decomposition of the need in to more chunks until you have a good
simple explanation of a single requirement in a sentence or two.

c.      
Describe what the need looks like if it’s
successfully filled, oddly enough, it’s the success criteria for the need being
completed. Again, I don’t make it more complicated than it needs to be. The law
of parsimony definitely applies here.

d.     
Then describe in as simple of terms as possible
how to check to see if the success criteria has been met. This then becomes the
basic test of completing the requirement.

e.     
Finally, any additional comments.

So, a good requirement (IMHO) might look
something like:

            – Need  #1
            – Description: All information must usable on
multiple computers.
            – Success Criteria: Information can be transported
to different computer and used by the same application.
            – How to check the success criteria: With the same
application on two different computers; use the information from a portable
drive on a different computer than the computer that first saved the
information.
            – Comments: The removable drive does not need to
be a USB thumb drive, it can be any number of removable storage devices, as
long as it is reasonably portable.

• Once I’ve created a needs list, then I create a
  list of risks that might derail the project; again, simple is better. Risk
  management and mitigation can get complicated quickly, but just getting people
  to think about risk to a project is a big step to a successful project. A
  simple risk list relates to back to the project’s goals and needs. So a simple
  risk list has 5 attributes:

a.      
The risk list starts with, again, a unique
identification of the risk itself. Like the needs list I use a numbered lists.

b.     
No risk is arbitrary, and every risk should
relate either to a clarifying component of the project goal, or one of its
needs. So, identify the relationship here as a reference to the number of the
need item, or if I have a numbered list for a clarifying component of the goal,
I list it here.

c.      
I then describe the risk in a simple sentence or
two, in simple English.

d.     
Then I rate the impact on the project as either
high, medium, or low.

e.     
Finally, describe in a single sentence or two in
simple English the current plan to mitigate the risk.

A good risk item (IMHO) might look
something like:

–         
Risk #1

–         
Relating to: Need #1

–         
Description: Drives used for in the application may
fail during transportation between workstations.

–         
Impact to project: High

–         
Current Mitigation: Insure that storage devices
used for the application are hardened to withstand severe environments with a
failure time of no less than 50,000 hours of use.

• Finally, using the information from one two and
  three above, put together a simple schedule of high level milestones for the
  project, simpler, here, is always better. I typically start out with no more
  than between 6 and 10 milestones, depending on the project, and refine the
  schedule from there.

From these four basic elements, in very simple terms, look
what has been accomplished:

• 
  A project goal statement has been created
• Objectives in the form of clarifying statements
  to the goal have been defined
• A list of requirements has been created
• A remedial test plan has been created through
  the use of success criterion and criterion checks
• A simple risk management plan has been created
  through identifying and quantifying the risks
• A risk mitigation plan has been created through
  mitigation identification.

The project management purists would criticize the
simplistic approach to project planning I’ve listed here, but keep in mind that
not all projects need a PMP, and complicated earned value analysis.

“It's not
the plan that is important, it's the planning.” –Dr Graeme Edwards