Some people believe the time spent writing a plan could be better spent writing code, but I don’t agree. The hard part isn’t writing the plan. The hard part is actually the planning—thinking, negotiating, balancing, asking, listening, and thinking some more. Actually writing the plan is mostly transcription at that point. The time you spend analyzing what it will take to solve the problem will reduce the number of surprises you encounter later in the project. Today’s multi-site and cross-cultural development projects demand even more careful planning and tracking than do traditional projects undertaken by a co-located team.

A useful plan is much more than just a schedule or task list. It also includes:

Your organization should adopt a standard software project management plan template, which each project can tailor to best suit its needs. A useful starting point is IEEE Std 1058-1998, the "IEEE Standard for Software Project Management Plans" (IEEE 1999). This standard describes a comprehensive plan template, sufficient for the largest projects. Study this template to see what sections would make sense for the types and sizes of projects that you work on. Shrink and adjust it to suit the nature and size of your own projects. The process assets on the Web site that accompanies this book include a suggested project management plan template that will get you started.

If you commonly tackle different kinds of projects, such as major new product development projects as well as small enhancements, adopt a separate project plan template for each project class. Avoid overburdening small projects with excessive documentation that adds little value. The project plan should be no longer or more elaborate than necessary to make sure you can successfully execute the project. But always write a plan.

Note

Either overplanning or underplanning a project. Projects never go exactly as planned, so there’s no point in trying to pin down every possible activity and eventuality. However, the other extreme of skimping on planning and just diving into the project is an invitation for rude surprises that will make it impossible to meet your commitments.

Inch-pebbles are miniature milestones (get it?). Breaking large tasks into multiple small tasks helps you estimate them more accurately, reveals work activities you might not have thought of otherwise, and permits more accurate, fine-grained status tracking. Select inch-pebbles of a size that you feel you can estimate accurately. I feel most comfortable with inch-pebbles that represent tasks of about 5 to 15 labor-hours, or about one to three days in duration. Overlooked tasks are a common contributor to schedule slips. Breaking large problems into smaller bits reveals more details about the work that must be done and improves your ability to create accurate estimates.

You can track progress based on the number of inch-pebbles that have been completed at any given time, compared to those you planned to complete by that time. Defining the project’s work in terms of inch-pebbles is an aid to tracking status through earned value analysis (Lewis 2000). The earned value technique compares the investment of effort or dollars that you’ve made to date with progress as measured by completed inch-pebbles.

If your team frequently undertakes certain common tasks—such as implementing a new class, executing a system test cycle, or performing a product build—develop activity checklists and planning worksheets for these tasks. Each checklist should include all of the steps the large task might need. These checklists and worksheets will help each team member identify and estimate the effort associated with each instance of the large task he must tackle. People work in different ways and no single person will think of all the necessary tasks, so engage multiple team members in developing the worksheets. Using standard worksheets will help the team members adopt common processes that they can tune up as they gain experience. Tailor the worksheets to meet the specific needs of individual projects.

I’ve seen project task lists in which the author assumed that every testing experience will be a success that lets you move into the next development activity. However, almost all quality control activities, such as testing and peer reviews, find defects or other improvement opportunities. Your project schedule or work breakdown structure should include rework as a discrete task after every quality control activity. Base your estimates of rework time on previous experience. For example, you might have historical inspection data indicating that, on average, your developers find 25 defects per thousand lines of code by inspection and that it costs an average of 40 minutes to fully repair each code defect. You can crunch these numbers to come up with the average expected rework effort for various types of work products. If you don’t actually have to do any rework after performing a test, great; you’re ahead of schedule on that task. Don’t count on it, though.

If you don’t identify and control project risks, they will control you. A risk is a potential problem that could affect the success of your project, a problem that hasn’t happened yet—and you’d like to keep it that way. Risk management has been identified as one of the most significant best practices for software development (Brown 1996). Simply identifying the possible risk factors isn’t enough. You also have to evaluate the relative threat each one poses so you can focus your energy where it will do the most good.

Risk exposure is a combination of the probability that a specific risk could materialize into a problem and the negative consequences for the project if it does. To manage each risk, select mitigation actions to reduce either the probability or the impact. You might also identify contingency plans that will kick in if your risk control activities are not effective. Suppose you’re concerned that your top developer might move to Australia to be with her new boyfriend, who she met at a conference. Consider the following possible risk-management actions:

A risk list does not replace a plan for how you will identify, prioritize, control, and track risks. Incorporate risk tracking into your routine project status tracking. For reference by future projects, record which risks materialized and which mitigation actions were effective. See Chapter 6, for more about how to identify and mitigate project risks.

Your team members are already swamped with their current project assignments, but if you want the group to rise to a higher plane of software engineering capability, you’ll have to invest some time in process improvement (Wiegers 1999). Set aside some time from your project schedule, because software project activities should include making process changes that will help your next project be even more successful. Don’t allocate 100 percent of your team members’ available time to project tasks and then wonder why they don’t make any progress on the improvement initiatives. Some process changes can begin to pay off immediately, whereas you won’t reap the full return on your investment in other improvements until the next project. View process improvement as a strategic investment in the sustained effectiveness of your development organization. I liken process improvement to highway construction: It slows everyone down a little bit for a time, but after the work is done, the road is a lot smoother and the throughput is greater.

The time and money you spend on training, reading and self-study, consultants, and developing improved processes are part of the investment your organization makes in sustained project success. Recognize that you’ll pay a price in terms of a short-term productivity loss—the learning curve—when you first try to apply new processes, tools, or technologies. Don’t expect to get fabulous benefits from new approaches on the first try, no matter what the tool vendor’s literature or the methodology consultant’s brochure claims. Instead, build extra time into the schedule to account for the inevitable learning curve. Make sure your managers and customers understand the learning curve and accept it as an inescapable consequence of working in a rapidly changing, high-technology field.