At a time when some software organizations have achieved close to perfect on-time delivery records, 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.
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.
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).
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.”
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.
A close cousin to Deadly Sin #4 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 theRational Unified Process, Extreme Programming, and to some extent (despite my best intentions to the contrary) my own Software Project Survival Guide. 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.
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.
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.”
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 the 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. 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.
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.
The Nine Deadly Sins of Project Planning: Published in IEEE Software, September/October 2001, pages 5-7