People generally provide estimates in units of calendar time. I prefer to estimate the effort (in labor-hours) associated with a task, and then translate the effort into a calendar-time estimate. A 20-hour task might take 2.5 calendar days of nominal full-time effort, or 2 exhausting days. However, it could also take a week if you have to wait for critical information from a customer or stay home with a sick child for two days. I base the translation of effort into calendar time on estimates of how many effective hours I can spend on project tasks per day, any interruptions or emergency bug fix requests I might get, meetings, and all the other places into which time disappears. If you track how you actually spend your time at work, you’ll know how many effective weekly project hours you have available on average (Wiegers 1996). Typically, this is only about 50 to 60 percent of the nominal time people spend at work, far less than the assumed 100 percent effective time on which so many project schedules are planned.

The task-switching overhead associated with the many activities we are all asked to do reduces our effectiveness significantly. Excessive multitasking introduces communication and thought process inefficiencies that reduce individual productivity. I once heard a manager say that someone on his team had spent an average of eight hours per week on a particular activity, so therefore she could do five of them at once. 40 hours per week divided by 8 is 5, right? In reality, she’ll be lucky if she can handle three or four such tasks. Some people multitask more efficiently than others. If some of your team members thrash when working on too many tasks at once, set clear priorities and help them do well by focusing on just one or two objectives at a time.

Estimate how much time your team members spend on training activities annually and subtract that from the time available for them to work on project tasks. You probably already subtract out average values for vacation time, sick time, and other assignments; treat training time the same way. Recognize that the high-tech field of software development demands that all practitioners devote time to ongoing education, both on their own time and on the company’s time. Arrange just-in-time training when you can schedule it, as the half-life of new technical knowledge is short unless the knowledge is put to use promptly. Attending a training seminar can be a team-building experience, as project team members and other stakeholders hear the same story about how to apply improved practices to their common challenges.

When you prepare estimates for your work, write down those estimates and document how you arrived at each of them. Understanding the assumptions and approaches used to create an estimate will make them easier to defend and adjust when necessary. It will also help you improve your estimation process. Train the team in estimation methods, rather than assuming that every software developer and project manager is instinctively skilled at predicting the future. An excellent resource is McConnell’s Software Estimation (2006). Develop estimation procedures and checklists that people throughout your organization can use.

The Wideband Delphi method is an effective group estimation technique. Wideband Delphi builds on the principle that multiple heads are better than one. The Delphi estimation method asks a small team of experts to anonymously generate individual estimates from a problem description and reach consensus on a final set of estimates through iteration. The outputs from the process include a complete list of project and quality-related tasks and an estimate for each task, in whatever units the team chose (such as dollars, weeks, or labor-hours). Participation by multiple estimators and the use of anonymous estimates to prevent one participant from biasing another make the Wideband Delphi method more reliable than simply asking a single individual for his best guess. See Chapter 11, for more about Wideband Delphi.

Many commercial tools are available to help project managers estimate entire projects. Based on large databases of actual project experience, these tools can give you a spectrum of possible schedule and staff allocation options. They’ll also help you avoid the "impossible region," combinations of product size, effort, and schedule where no known project has been successful. The tools incorporate a number of "cost drivers" you can adjust to make the tool more accurately model your project, based on the technologies used, the team’s experience, and other factors. You can calibrate the tool with your own project data to make it an even better predictor of the future. A good tool to try is Estimate from Construx Software (www.construx.com). Others include KnowledgePlan (www.spr.com), SLIM-Estimate and Estimate Express (www.qsm.com), and Cost Xpert (www.costxpert.com). You can compare the estimates from the tools with the bottom-up estimates generated from a work breakdown structure. Reconcile any major disconnects so you can generate the most realistic overall estimate.

Projects never go precisely as planned. The prudent project manager incorporates budget and schedule contingency buffers (also known as management reserve) at the end of major phases to accommodate the unforeseen. Use your project risk analysis to estimate the possible schedule impact if several of the risks materialize and build that projected risk exposure into your schedule as a contingency buffer. Even more sophisticated is critical chain analysis, a technique that pools the uncertainties in estimates and risks into a rational overall contingency buffer (Leach 2000).

Your manager or customer might view these contingency buffers as padding, rather than as the sensible acknowledgment of reality that they are. To help persuade skeptics, point to unpleasant surprises on previous projects as a rationale for your foresight. If a manager elects to discard contingency buffers, he has tacitly absorbed all the risks that fed into the buffer and assumed that all estimates are perfect, no scope growth will occur, and no unexpected events will take place. The reality on most projects is quite different. I’d rather see us deal with reality—however unattractive—than to live in Fantasyland, which leads to chronic disappointments. See Chapter 10, for more about contingency buffers.