From the Editor
IEEE Software, September/October 2001
Nine Deadly Sins of
Project Planning
At a time when some software organizations have achieved close to perfect
on-time delivery records,1 others continue to suffer mediocre
results. Surveys generally indicate that poor project planning is one of the
top sources of problems.
How can you recognize a badly planned software project? Here are some of
the deadliest sins I’ve found in project planning.
1. Not Planning At All
By far the most common planning problem is simply not planning at all, and
this sin is easily avoided. A person need not be an expert planner to plan
effectively. I’ve seen numerous instances of projects planned by rank
amateurs that have run well simply because the people in charge had
carefully considered their project’s specific needs. Forced to choose
between an expert project planner who doesn’t carefully think through his
plan or a rank amateur who has thoroughly evaluated his project needs, I’ll
bet on the rank amateur every time.
2. Failing to Account for All Project Activities
If Deadly Sin #1 is not planning at all, Deadly Sin #2 is not planning
enough. Some project plans are created using the assumption that no one
on the software team will get sick, attend training, go on vacation, or
quit. Core activities are often underestimated to a great degree. Plans
created using unrealistic assumptions like these set up a project for
disaster.
There are numerous variations on this theme. Some projects neglect to
account for ancillary activities such as the effort needed to create setup
programs, convert data from previous versions, perform cutover to new
systems, perform compatibility testing, and other pesky kinds of work that
take up more time on projects than we would like to admit.
Some projects that fall behind plan to catch up by reducing their
originally-planned testing cycle; they reason that there probably won’t be
very many defects to detect or correct. (Determining why—if this is really
the case—they didn’t plan for a shorter testing cycle in the first place is
left as an exercise to the reader.)
3. Failure to Plan for Risk
In Design Paradigms 2 Henry Petroski
argues that, in bridge design, the most spectacular failures have generally
been preceded by periods of success which led to complacency in the creation
of new designs. Designers of failed bridges were lulled into copying the
attributes of successful bridges and didn’t pay enough attention to each new
bridge’s potential failure modes.
For software projects, actively avoiding failure is as important as
emulating success. In many business contexts, the word "risk" isn’t
mentioned unless a project is already in deep trouble. In software, a
project planner who isn’t using the word "risk’ every day and incorporating
risk management into his plans probably isn’t doing his job. As Tom Gilb
says, "If you do not actively attack the risks on your project, they will
actively attack you."3
4. Using the Same Plan for Every Project
Some organizations grow familiar with a particular approach to running
software projects, which is known as "the way we do things around here."
When this approach is used, the organization tends to do well as long as the
new projects look like the old projects. When new projects look different,
however, reusing old plans can cause more harm than good.
Good plans address specific conditions of the project for which they are
created. Many elements can be reused, but project planners should think
carefully about the extent to which each element of a previous plan still
applies to the new project context.
5. Applying Pre-Packaged Plans Indiscriminately
A close cousin to Deadly Sin #3 is reusing a generic plan someone else
created without applying your own critical thinking or considering your
project’s unique needs. "Someone else’s plan" usually arrives in the form of
a book or a methodology that a project planner applies out of the box.
Current examples include the Rational Unified Process,4
Extreme Programming,5 and to some extent (despite my best
intentions to the contrary) my own Software Project Survival Guide6
and my company’s CxOne. These pre-packaged plans can help to avoid
Deadly Sins #1 and #2, but are not a substitute for thinking about and
optimizing your plans to the unique demands of your project.
No outside expert can possibly understand a project’s specific needs as
well as the people directly involved in the project. Project planners should
always tailor the "expert’s" plan to their specific circumstances.
Fortunately, I’ve found that project planners who are aware enough of
planning issues to read software engineering books usually also have enough
common sense to be selective about the parts of the pre-packaged plans that
are likely to work for them.
6. Allowing a Plan to Diverge from Project Reality
One common approach to planning is to create a plan early in the project,
then put it on the shelf and let it gather dust for the remainder of the
project. As project conditions change, the plan becomes increasingly
irrelevant to the project, and, by mid-project, the project runs free-form,
with no real relationship between the unchanging plan and the project
reality.
This Deadly Sin is exacerbated by Deadly Sin #5—project planners who
embrace prepackaged methodologies whole-hog are sometimes reluctant to
change them midstream when they’re not working. They think the problem is
with their application of the plan when, in fact, the problem is with the
plan. Good project planning should occur and recur incrementally throughout
a project.
7. Planning in Too Much Detail Too Soon
Some well-intentioned project planners attempt to map out a whole project’s
worth of activities early in the project. But a software project consists of
a constantly unfolding set of decisions, and each project phase creates
dependencies for future decisions. Since no project planner has a crystal
ball, attempting to plan distant activities in too much detail is an
exercise in bureaucracy that is almost as bad as not planning at all.
The more work that goes into creating prematurely detailed plans, the
higher the likelihood the plan will become shelfware (Deadly Sin #6). No one
likes to throw away previous work, and project planners sometimes try to
force fit the project’s reality into their earlier plans, rather than
laboriously revising their prematurely detailed plans.
I think of good project planning as like driving at night with my car’s
headlights on. I might have a road map that tells me how to get from City A
to City B, but the distance I can see in detail in my headlights is limited.
On a medium-size or large project, macro-level project plans should be
mapped out end-to-end early in the project. Detailed, micro-level planning
should generally be conducted only a few weeks at a time, and should be
conducted "just in time."
8. Planning to Catch Up Later
For projects that get behind schedule, one common mistake is planning to
make up lost time later. The typical rationalization is that, "The team was
climbing a learning curve early in the project. We learned a lot of lessons
that hard way. But now we understand what we’re doing, and we should be able
to finish the project quickly." Wrong answer! A 1991 survey of more than 300
projects found that projects hardly ever make up lost time—they tend to get
further behind.7 The flaw in the rationalization is that software
teams make their highest-leverage decisions earliest in the project—the time
during which new technology, new business areas, and new methodologies are
the least well understood. As the team works its way into the later phases
of the project, it won’t speed up; it will slow down as it encounters the
consequences of mistakes it made earlier and invests time correcting those
mistakes.
9. Not Learning from Past Planning Sins
The deadliest sin of all may be not learning from earlier deadly sins.
Software projects can take a long time, and people’s memories can be clouded
by ego and the passage of time. By the end of a long project, it can be
difficult to remember all the early decisions that affected the project’s
conclusion.
One easy way to counter these tendencies and prevent future deadly sins is
to conduct a structured project post mortem review.8 A post
mortem review might not erase the sins of projects past, but it can
certainly help prevent sins on future projects.
References
1. Sanjiv Ahuja, "Laying the Groundwork for Success" (Interview),
IEEE Software, Nov/Dec 1999, pp. 72-75.
2. Henry Petroski, Design Paradigms, Cambridge University Press,
1994.
3. Tom Gilb, Principles of Software Engineering
Management. Wokingham, England: Addison-Wesley,
1988.
4. Phillippe Kruchten, The Rational Unified Process: An Introduction, 2d
Ed., Reading, Mass.: Addison Wesley, 2000.
5. Kent Beck, Extreme Programming: Embrace Change, Reading, Mass.:
Addison Wesley, 2000.
6. Steve McConnell, Software Project Survival Guide, Redmond, WA.:
Microsoft Press, 1997.
7. Michiel van Genuchten. "Why is Software Late? An Empirical Study of
Reasons for Delay in Software Development." IEEE Transactions on Software
Engineering, vol. 17, no. 6 (June 1991), pp. 582-590.
8. Bonnie Collier, Tom Demarco, and Peter Fearey, "A Defined Process For
Project Postmortem Review," IEEE Software, July 1996, pp. 65-72.
Editor: Steve McConnell, Construx Software, 11820 Northup
Way, Suite E200, Bellevue, WA 98008.
E-mail: steve.mcconnell@construx.com
- WWW:
http://www.construx.com/stevemcc/
