C o p y r i g h t © 2 0 0 1 S t e v e n C . M c C o n n e l l . A l l R i g h t s R e s e r v e d . S e p t e m b e r / O c t o b e r 2 0 0 1 I E E E S O F T W A R E 5

from the editor

The Nine Deadly Sins ofProject PlanningSteve McConnell

E d i t o r i n C h i e f : S t e v e M c C o n n e l l � C o n s t r u x S o f t w a r e � s o f t w a r e @ c o n s t r u x . c o m

At a time when some software organiza-tions have achieved close to perfecton-time delivery records,1 others con-tinue to suffer mediocre results. Sur-veys generally indicate that poor pro-ject planning is one of the top sources

of problems. How can you recognize a badly planned

software project? Here are nine of the dead-liest sins I’ve found in project plan-ning.

1. Not planning at allBy far the most common plan-

ning problem is simply not planningat all, and this sin is easily avoided.A person need not be an expert plan-ner to plan effectively. I’ve seen nu-merous instances of projects plannedby rank amateurs that have run wellsimply because the people in charge

had carefully considered their project’s specificneeds. Forced to choose between an expert pro-ject planner who doesn’t carefully think throughhis plan or an amateur who has thoroughly eval-uated his project needs, I’ll bet on the amateurevery time.

2. Failing to account for all projectactivities

If Deadly Sin #1 is not planning at all,Deadly Sin #2 is not planning enough. Someproject plans are created using the assumptionthat no one on the software team will get sick,attend training, go on vacation, or quit. Coreactivities are often underestimated to a greatdegree. Plans created using unrealistic assump-tions like these set up a project for disaster.

There are numerous variations on thistheme. Some projects neglect to account forancillary activities such as the effort needed to

create setup programs, convert data from pre-vious versions, perform cutover to new sys-tems, perform compatibility testing, and otherpesky kinds of work that take up more timethan we would like to admit.

Some late projects propose to catch up byreducing their originally planned testing cycle;they reason that there probably won’t be verymany defects to detect or correct. (I leave as anexercise for the reader to determine why—ifthis is really the case—they didn’t plan for ashorter testing cycle in the first place.)

3. Failure to plan for riskIn Design Paradigms,2 Henry Petroski ar-

gues that the most spectacular failures in bridgedesign were generally preceded by periods ofsuccess that led to complacency in the creationof new designs. Designers of failed bridgeswere lulled into copying the attributes of suc-cessful bridges and didn’t pay enough attentionto each new bridge’s potential failure modes.

For software projects, actively avoiding fail-ure is as important as emulating success. Inmany business contexts, the word “risk” isn’tmentioned unless a project is already in deeptrouble. In software, a project planner who isn’tusing the word “risk” every day and incorpo-rating risk management into his plans probably isn’t doing his job. As Tom Gilb says, “If you donot actively attack the risks on your project,they will actively attack you.”3

4. Using the same plan for everyproject

Some organizations grow familiar with aparticular approach to running software pro-jects, which is known as “the way we do thingsaround here.” When an organization uses thisapproach, it tends to do well as long as the newprojects look like the old projects. When new

6 I E E E S O F T W A R E S e p t e m b e r / O c t o b e r 2 0 0 1

FROM THE EDITOR

projects look different, however, reusingold plans can cause more harm thangood.

Good plans address specific condi-tions of the project for which they arecreated. Many elements can be reused,but project planners should think care-fully about the extent to which each el-ement of a previous plan still applies tothe new project context.

5. Applying prepackagedplans indiscriminately

A close cousin to Deadly Sin #3 isreusing a generic plan someone else cre-ated without applying your own criticalthinking or considering your project’sunique needs. “Someone else’s plan”usually arrives in the form of a book ormethodology that a project planner ap-plies out of the box. Current examplesinclude the Rational Unified Process,4

Extreme Programming,5 and to someextent (despite my best intentions to thecontrary) my own Software ProjectSurvival Guide6 and my company’s Cx-One. These prepackaged plans can helpavoid Deadly Sins #1 and #2, but theyare not a substitute for thinking aboutand optimizing your plans to theunique demands of your project.

No outside expert can possibly un-derstand a project’s specific needs aswell as the people directly involved.Project planners should always tailorthe “expert’s” plan to their specific cir-cumstances. Fortunately, I’ve foundthat project planners who are awareenough of planning issues to read soft-ware engineering books usually alsohave enough common sense to be selec-tive about the parts of the prepackagedplans that are likely to work for them.

6. Allowing a plan to divergefrom project reality

One common approach to planningis to create a plan early in the project,then put it on the shelf and let it gatherdust for the remainder of the project.As project conditions change, the planbecomes increasingly irrelevant, so bymid-project the project runs free-form,with no real relationship between theunchanging plan and project reality.

This Deadly Sin is exacerbated byDeadly Sin #5—project planners who

embrace prepackaged methodologieswhole-hog are sometimes reluctant tochange them midstream when they’renot working. They think the problem iswith their application of the planwhen, in fact, the problem is with theplan. Good project planning should occur and recur incrementally through-out a project.

7. Planning in too much detailtoo soon

Some well-intentioned project plan-ners try to map out a whole project’sworth of activities early on. But a soft-ware project consists of a constantlyunfolding set of decisions, and eachproject phase creates dependencies forfuture decisions. Since planners do nothave crystal balls, attempting to plandistant activities in too much detail isan exercise in bureaucracy that is al-most as bad as not planning at all.

The more work that goes into creat-ing prematurely detailed plans, thehigher the likelihood the plan will be-come shelfware (Deadly Sin #6). Noone likes to throw away previouswork, and project planners sometimestry to force-fit the project’s reality intotheir earlier plans rather than labori-ously revising their prematurely de-tailed plans.

I think of good project planning likedriving at night with my car’s head-lights on. I might have a road map thattells me how to get from City A to CityB, but the distance I can see in detail inmy headlights is limited. On a medium-size or large project, macro-level pro-ject plans should be mapped out end-to-end early in the project. Detailed,micro-level planning should generallybe conducted only a few weeks at atime and “just in time.”

8. Planning to catch up laterFor projects that get behind sched-

ule, one common mistake is planningto make up lost time later. The typicalrationalization is that, “The team wasclimbing a learning curve early in theproject. We learned a lot of lessons thehard way. But now we understandwhat we’re doing and should be able tofinish the project quickly.” Wrong an-swer! A 1991 survey of more than 300

DEPARTMENT EDITORS

Bookshelf: Warren Keuffel, wkeuffel@computer.org

Country Report: Deependra Moitra, Lucent Technologiesd.moitra@computer.org

Design: Martin Fowler, ThoughtWorks,fowler@acm.org

Loyal Opposition: Robert Glass, Computing Trends,rglass@indiana.edu

Manager: Don Reifer, Reifer Consultants,dreifer@sprintmail.com

Quality Time: Jeffrey Voas, Cigital, voas@cigital.com

STAFF

Senior Lead Editor Dale C. Strok

dstrok@computer.org

Group Managing EditorCrystal Chweh

Associate EditorsJenny Ferrero and

Dennis Taylor

Staff EditorsShani Murray, Scott L. Andresen,

and Kathy Clark-Fisher

Magazine AssistantsDawn Craig

software@computer.org

Pauline Hosillos

Art DirectorToni Van Buskirk

Cover IllustrationDirk Hagner

Technical IllustratorAlex Torres

Production ArtistsCarmen Flores-Garvey and Larry Bauer

Acting Executive DirectorAnne Marie Kelly

PublisherAngela Burgess

Assistant PublisherDick Price

Membership/CirculationMarketing ManagerGeorgann Carter

Advertising AssistantDebbie Sims

CONTRIBUTING EDITORS

Greg Goth, Keri Schreiner, and Gil Shif

Editorial: All submissions are subject to editing for clarity,style, and space. Unless otherwise stated, bylined articlesand departments, as well as product and service descrip-tions, reflect the author’s or firm’s opinion. Inclusion inIEEE Software does not necessarily constitute endorsementby the IEEE or the IEEE Computer Society.

To Submit: Send 2 electronic versions (1 word-processedand 1 postscript or PDF) of articles to Magazine Assistant,IEEE Software, 10662 Los Vaqueros Circle, PO Box 3014,Los Alamitos, CA 90720-1314; software@computer.org. Ar-ticles must be original and not exceed 5,400 words includingfigures and tables, which count for 200 words each.

S e p t e m b e r / O c t o b e r 2 0 0 1 I E E E S O F T W A R E 7

FROM THE EDITOR

projects found that projects hardly evermake up lost time—they tend to getfurther behind.7 The flaw in the ratio-nalization is that software teams maketheir highest-leverage decisions earliestin the project—the time during whichnew technology, new business areas,and new methodologies are the leastwell understood. As the team works itsway into the later phases of the project,it won’t speed up; it will slow down asit encounters the consequences of mis-takes it made earlier and invests timecorrecting those mistakes.

9. Not learning from pastplanning sins

The deadliest sin of all might be notlearning from earlier deadly sins. Soft-ware projects can take a long time, andpeople’s memories can be clouded byego and the passage of time. By the endof a long project, it can be difficult toremember all the early decisions thataffected the project’s conclusion.

One easy way to counter these ten-dencies and prevent future deadly sinsis to conduct a structured project post-

mortem review.8 A postmortem reviewmight not erase the sins of projectspast, but it can certainly help preventsins on future projects.

References1. S. Ahuja, “Laying the Groundwork for Suc-

cess,” IEEE Software, vol. 16, no. 6, Nov.–Dec. 1999, pp. 72–75.

2. H. Petroski, Design Paradigms, CambridgeUniv. Press, Cambridge, U.K., 1994.

3. T. Gilb, Principles of Software EngineeringManagement, Addison-Wesley, Reading,Mass., 1988.

4. P. Kruchten, The Rational Unified Process: AnIntroduction, 2nd ed., Addison-Wesley, Read-ing, Mass., 2000.

5. K. Beck, Extreme Programming: EmbraceChange, Addison-Wesley, Reading, Mass.,2000.

6. S. McConnell, Software Project SurvivalGuide, Microsoft Press, Redmond, Wash.,1997.

7. M. van Genuchten, “Why Is Software Late?An Empirical Study of Reasons for Delay inSoftware Development,” IEEE Trans. Soft-ware Eng., vol. 17, no. 6, June 1991, pp.582–590.

8. B. Collier, T. Demarco, and P. Fearey, “A De-fined Process for Project Postmortem Review,”IEEE Software, vol. 13, no. 4, July–Aug.1996, pp. 65–72.

EDITOR IN CHIEF: Steve McConnell

10662 Los Vaqueros CircleLos Alamitos, CA 90720-1314

software@construx.com

EDITOR IN CHIEF EMERITUS:Alan M. Davis, Omni-Vista

ASSOCIATE EDITORS IN CHIEF

Design: Maarten Boasson, Quaerendo Invenietisboasson@quaerendo.com

Construction: Terry Bollinger, Mitre Corp.terry@mitre.org

Requirements: Christof Ebert, Alcatel Telecomchristof.ebert@alcatel.be

Management: Ann Miller, University of Missouri, Rollamillera@ece.umr.edu

Quality: Jeffrey Voas, Cigitalvoas@cigital.com

Experience Reports: Wolfgang Strigel, Software Productivity Center; strigel@spc.ca

EDITORIAL BOARD

Don Bagert, Texas Tech UniversityRichard Fairley, Oregon Graduate Institute

Martin Fowler, ThoughtWorksRobert Glass, Computing Trends

Natalia Juristo, Universidad Politécnica de MadridWarren Keuffel, independent consultantBrian Lawrence, Coyote Valley Software

Karen Mackey, Cisco SystemsDeependra Moitra, Lucent Technologies, India

Don Reifer, Reifer ConsultantsSuzanne Robertson, Altantic Systems Guild

Wolfgang Strigel, Software Productivity CenterKarl Wiegers, Process Impact

INDUSTRY ADVISORY BOARD

Robert Cochran, Catalyst Software (chair) Annie Kuntzmann-Combelles, Q-Labs

Enrique Draier, PSINetEric Horvitz, Microsoft Research

David Hsiao, Cisco SystemsTakaya Ishida, Mitsubishi Electric Corp.

Dehua Ju, ASTI ShanghaiDonna Kasperson, Science Applications International

Pavle Knaflic, Hermes SoftLabGünter Koch, Austrian Research Centers

Wojtek Kozaczynski, Rational Software Corp.Tomoo Matsubara, Matsubara Consulting

Masao Matsumoto, Univ. of TsukubaDorothy McKinney, Lockheed Martin Space Systems

Nancy Mead, Software Engineering InstituteStephen Mellor, Project Technology

Susan Mickel, AgileTVDave Moore, Vulcan Northwest

Melissa Murphy, Sandia National LaboratoriesKiyoh Nakamura, Fujitsu

Grant Rule, Software Measurement ServicesGirish Seshagiri, Advanced Information Services

Chandra Shekaran, MicrosoftMartyn Thomas, Praxis

Rob Thomsett, The Thomsett Company John Vu, The Boeing Company

Simon Wright, Integrated ChipwareTsuneo Yamaura, Hitachi Software Engineering

MAGAZINE OPERATIONS COMMITTEE

Sorel Reisman (chair), James H. Aylor, Jean Bacon,Thomas J. Bergin, Wushow Chou, William I.

Grosky, Steve McConnell, Ken Sakamura, NigelShadbolt, Munindar P. Singh, Francis Sullivan,

James J. Thomas, Yervant Zorian

PUBLICATIONS BOARD

Rangachar Kasturi (chair), Angela Burgess (pub-lisher), Jake Aggarwal, Laxmi Bhuyan, Mark Chris-

tensen, Lori Clarke, Mike T. Liu, Sorel Reisman,Gabriella Sannitti di Baja, Sallie Sheppard, Mike

Williams, Zhiwei Xu

November/December ’01: Extreme Programming from a CMM Perspective

January/February ’02: Building Systems Securely from the Ground Up

March/April ’02: Building Internet Software

May/June ’02: Knowledge Management in Software Engineering

U p c o m i n g T o p i c s