Skip to main content

Author: Karl Wiegers

Karl Wiegers is Principal Consultant with Process Impact, a software development consulting and training company in Portland, Oregon. He has a PhD in organic chemistry. Karl is the author of 13 books, including Software Development Pearls (from which this article is adapted), The Thoughtless Design of Everyday Things, Software Requirements, More About Software Requirements, and Successful Business Analysis Consulting. Karl has also written many articles on software development, design, project management, chemistry, military history, consulting, and self-help, as well as 18 songs. You can reach Karl at tinyurl.com/sdpearls.

Work Plans Must Account for Friction

I overheard this conversation at work one day:

Manager Shannon: “Jamie, I know you’re doing the usability assessments on the Canary project right now. Several other projects are also interested in usability assessments. How much time do you spend on that?”

Team Member Jamie: “About eight hours a week.”

Manager Shannon: “Okay, so you could work with five projects at a time then.”

Do you see any flaws in Shannon’s thinking? Five times eight is forty, the nominal hours in a work week, so this discussion seems reasonable on the surface. But Shannon hasn’t considered the many factors that reduce the time that individuals have available each day for project work: project friction (as opposed to interpersonal friction, which I’m not discussing here).

There’s a difference between elapsed hours on the job and effective available hours. If people don’t incorporate friction factors into their planning, they’ll forever underestimate how long it will take to get work done.

Task Switching and Flow

People do not multitask—they task switch. When multitasking computers switch from one job to another, there’s a period of unproductive time during the switch. The same is true of people, only it’s far worse. It takes a little while to gather all the materials you need to work on a different activity, access the right files, and reload your brain with the pertinent information. You need to change your mental context to focus on the new problem and remember where you were the last time you worked on it. That’s the slow part.

Some people are better at task switching than others. Maybe I have a short attention span, but I’m pretty good at diverting my focus to something different and then resuming the original activity right where I left off. For many people, though, excessive task switching destroys productivity. Programmers are particularly susceptible to the time-sucking impact of multitasking, as Joel Spolsky (2001) explains:

“When you manage programmers, specifically, task switches take a really, really, really long time. That’s because programming is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at programming. A programmer coding at full throttle is keeping zillions of things in their head at once.”

When I was a manager, a developer named Jordan said he was flailing. He would work on task A for a while, then feel guilty that he was neglecting task B, so he’d switch to that one, accomplishing little as a result. Jordan and I worked out his priorities and a plan for allocating time to tasks in turn. He stopped flailing and his productivity went up. Jordan’s task-switching overhead and priority confusion affected both his productivity and his state of mind.

Advertisement
[widget id=”custom_html-68″]

When you’re deeply immersed in some work, focused on the activity and free from distractions, you enter a mental state called flow. Creative knowledge work like software development requires flow to be productive (DeMarco and Lister 2013). You understand what you’re working on, the information you need is in your working memory, and you know where you’re headed. You can tell you’ve been in a state of flow when you lose track of time as you’re making great progress and having fun. Then your phone pings with a text message, an e-mail notification pops up, your computer reminds you that a meeting starts in five minutes, or someone stops by to talk. Boom—there goes your flow.

Interruptions are flow killers. It takes several minutes to get your brain back into that highly productive state and pick up where you were before the interruption. A realistic measure of your effective work capacity is based not on how many hours you’re at work or even how many hours you’re on task, but how many uninterrupted hours you’re on task (DeMarco and Lister 2013).

To achieve the high productivity and satisfaction that come from an extended state of flow, you need to actively manage your work time. Jory MacKay (2021) offers several recommendations for reducing context switching and its accompanying productivity destruction.

  • Timeblock your schedule to create clearer focus boundaries. Planning how you will spend your day, with dedicated blocks of time allocated to specific activities, carves out opportunities for extended deep concentration.
  • Employ routines to remove attention residue as you migrate from one task to the next. A small transition ritual or distraction—a cup of coffee, an amusing video—can help you make a mental break into a new work mode.
  • Take regular breaks to recharge. The intense concentration of a state of flow is great—up to a point. You must come up for air occasionally. To minimize eyestrain, periodically focus your eyes on something in the distance for a few seconds instead of the screen. Short mental breaks are refreshing before you dive back into that productive flow state.

Effective Hours

At-work hours seep away through many channels. You attend meetings and video chats, respond to e-mails, look things up on the web, participate in retrospectives, and review your teammates’ code. Time gets lost to unexpected bug fixes, kicking around ideas with your coworkers, administrative activities, and the usual healthy socializing. Working from home offers myriad other distractions, many of them more fun than project work. Even if you work forty hours a week, you don’t spend anywhere near that many on your project.

One software group of mine measured how we devoted our time on projects for several years (Wiegers 1996). Individuals tracked the hours they spent working on each project in ten activity categories. We didn’t try to make the weekly numbers add up to any total. We just wanted to know how we really spent our time, compared to how we thought we spent our time, compared to how we were supposed to spend our time.

The results were eye-opening. In the first year we collected data, we devoted an average of just 26 hours per week to project work. The time tracking made us all more conscious of finding ways to focus our time more productively. However, we never exceeded an average of 31 hours per week of project time.

Several of my colleagues have obtained similar results, averaging five to six hours per day on project work. Rather than relying on published figures to estimate your effective project time, collect your own data. Recording how you work for a few typical weeks will provide a good idea of how many hours per week you can expect to devote to project tasks. Knowing the team’s average effective weekly work hours helps everyone make more realistic estimates, plans, and commitments.

Other Sources of Project Friction

Besides the daily frittering away of time on myriad activities, project teams lose time to other sources of friction. For instance, most corporate IT organizations are responsible for both new development and enhancing and repairing current production systems. Since you can’t predict when something will break or a change request will come along, these sporadic, interruptive maintenance demands usurp team members’ time with unplanned work.

The team composition can further impose friction if project participants speak different native languages and work in diverse cultures. Unclear and volatile requirement priorities can chew up hours as people spend time researching, debating, and adjusting priorities. The team might have to temporarily shelve some incomplete work if a new, higher-priority task inserts itself into the schedule. Unplanned rework is yet another time diversion.

Distance between project participants can retard information exchanges and decision-making. A contract project that involved a customer in the eastern United States and a vendor in western Canada planned some peer reviews of certain deliverables. However, the long-distance reviews took longer than expected, as did follow-up to verify the corrections made. Sluggish iteration to resolve requirements questions and ambiguity about who the right contact people were for each issue were further impediments. These—and other—factors put the project behind schedule after just the first week and eventually contributed to its failure.

Planning Implications

I estimate how long individual tasks will take as though I will have no distractions or interruptions, just focused and productive time. Next, I convert that ideal effort estimate into calendar time based on my effective work-hour percentage. I also consider whether any of the other aforementioned sources of friction could affect my estimates. Then I try to arrange my work so that I can focus on a single task at a time until it’s complete or I hit a blocking point.

My colleague Dave described what happens on his current project, whose manager doesn’t consider the impacts of time lost to excessive multitasking:

“The manager likes to split people up between teams, 50 percent here and 50 percent there, or 50, 25, and 25. But when this happens, it seems like they forget the percentages and think the team has all full-time people. Then they seem surprised at how long things take. Also, being on multiple teams means more overhead in meetings and less coding time.”

If people always create estimates without accounting for the many ways that time splitting and project conditions can slow down the work, they’re destined to overrun their estimates every time.

References

DeMarco, Tom, and Timothy Lister. 2013. Peopleware: Productive Projects and Teams, 3rd Ed. Boston: Addison-Wesley.

MacKay, Jory. 2021. “Context switching: Why jumping between tasks is killing your productivity (and what you can do about it).” https://blog.rescuetime.com/context-switching.

Spolsky, Joel. 2001. “Human Task Switches Considered Harmful.” https://www.joelonsoftware.com/2001/02/12/human-task-switches-considered-harmful.

Wiegers, Karl E. 1996. Creating a Software Engineering Culture. New York: Dorset House Publishing.

Project Management Best Practices: Tracking and Learning

In the previous three articles in this series, I’ve described seventeen practices the project manager can apply to lay the foundation for a successful project, plan the project, and estimate the work to be done. In this final article I share three good practices for tracking your progress throughout the project and one practice for learning how to execute future projects more successfully.

Tracking Your Progress

Practice #18: Record actuals and estimates.

Unless you record the actual effort or time spent on each project task and compare them to the estimates, your estimates will forever remain guesses. Someone once asked me where to get historical data to improve her ability to estimate future work. My answer was, “If you write down what actually happened today, that becomes historical data tomorrow.” It’s really not more complicated than that. Each individual can begin recording estimates and actuals, and the project manager should track these important data items on a project task or milestone basis. In addition to effort and schedule, you could estimate and track the size of the product, in units of requirements, user stories, lines of code, function points, classes and methods, GUI screens, or other units that make sense for your project.

Practice #19: Count tasks as complete only when they’re one hundred percent complete.

We tend to give ourselves a lot of partial credit for tasks we’ve begun but not yet fully completed: “I thought about the algorithm for that module in the shower this morning, and the algorithm is the hard part, so I’m probably about sixty percent done.” It’s difficult to accurately assess what fraction of a sizable task has actually been finished at a given moment.

One benefit of using inch-pebbles (see Practice #6 in Part 2 of this series) for task planning is that you can break a large activity into a number of small tasks (inch-pebbles) and classify each small task as either done or not done—nothing in between.

Your project status tracking is then based on the fraction of the tasks that are completed and their size, not the percent completion of each task. If someone asks you whether a specific task is complete and your reply is, “It’s all done except…,” then it’s not done! Don’t let people “round up” their task completion status. Instead, use explicit criteria to determine whether an activity truly is completed.

Practice #20: Track project status openly and honestly.

An old riddle asks, “How does a software project become six months late?” The rueful answer is, “One day at a time.” The painful problems arise when the project manager doesn’t know just how far behind (or, occasionally, ahead) of plan the project really is. Surprise, surprise, surprise.

If you’re the PM, create a climate in which team members feel it is safe for them to report project status accurately. Strive to run the project from a foundation of accurate, data-based facts, rather than from the misleading optimism that can arise from the fear of reporting bad news. Use project status information and metrics data to take corrective actions when necessary and to celebrate when you can. You can only manage a project effectively when you really know what’s done and what isn’t, what tasks are falling behind their estimates and why, and what problems, issues, and risks remain to be tackled.

The five major areas of software measurement are size, effort, time, quality, and status. It’s a good idea to define a few metrics in each of these categories. Instilling a measurement culture into an organization is not trivial. Some people resent having to collect data about the work they do, often because they’re afraid of how managers might use the measurements. The cardinal rule of software metrics is that management must never use the data collected to either reward or punish the individuals who did the work. The first time you do this will be the last time you can count on getting accurate data from the team members. Read Chapters 12 and 13 of my book Practical Project Initiation to learn about basic principles of software measurement and metrics traps to avoid.

Learning for the Future

Practice #21: Conduct project retrospectives.

Retrospectives (also called postmortems and post-project reviews) provide an opportunity for the team to reflect on how the last project, phase, or iteration went and to capture lessons learned that will help enhance your future performance. During such a review, identify the things that went well, so you can create an environment that enables you to repeat those success contributors. Also look for things that didn’t go so well, so you can change your approaches and prevent those problems in the future. In addition, think of events that surprised you. These might be risk factors to look for on the next project. Finally, ask yourself what you still don’t understand about the project, so you can try to learn how to execute future work better.

It’s important to conduct retrospectives in a constructive and honest atmosphere. Don’t make them an opportunity to assign blame for previous problems. Chapter 15 of Practical Project Initiation describes the project retrospective process and provides a worksheet to help you plan your next retrospective.

It’s a very good idea to capture the lessons learned from each retrospective or process improvement exploration and share them with the entire team and organization. This is a way to help all team members, present and future, benefit from your experience. Chapter 14 of Practical Project Initiation talks about best practices, worst practices, and a way to record lessons learned.

The twenty-one project management best practices I’ve described in this series of articles won’t guarantee your project a great outcome. They will, however, help you get a solid handle on your project and ensure that you’re doing all you can to make it succeed in an unpredictable world.

Don’t forget to leave your comments below.

Stop Promising Miracles: Wideband Delphi Team Estimation, Part 3

The first two articles in this three-part series, adapted from my book Practical Project Initiation: A Handbook with Tools, described the first four steps in the group estimation technique called Wideband Delphi (see Figure 1). This article, completes the description of Wideband Delphi by describing the final steps in the process.
wiegers May22 Img1

Assembling Tasks

The Delphi session isn’t finished when the estimation meeting concludes. Either the moderator or the project manager assembles the project tasks and their individual estimates into a single master task list. This person also merges the individual lists of assumptions, quality- and process-related activities, and waiting times.

The merging process involves removing duplicate tasks and reaching some reasonable resolution of different estimates for individual tasks. “Reasonable” doesn’t mean replacing the team’s estimates with values the project manager prefers. Large estimate differences for apparently similar tasks might indicate that estimators interpreted that task in different ways. For example, two people might both have a task called “implement a class.” However, one estimator might have included unit testing and code review in the task, while the other meant just the coding effort. All estimators should define their tasks clearly to minimize confusion during this merging step. The merging step should retain the estimate range for the tasks. If one estimator’s task estimate was wildly different from that of the other estimators, understand it and then perhaps discard or modify it.

Review Results

In the final step, the estimation team reviews the summarized results and reaches agreement on the final outcome. The project manager provides the other estimators with the overall task list, individual estimates, cumulative estimates, assumption list, and any other information. Bring the team back together for a brief review meeting to bring closure to the estimation activity. This meeting also provides an opportunity for the team to contemplate this execution of the Wideband Delphi process—a retrospective—and suggest ways they can improve it for future applications.

The participants should make sure the final task list is as complete as possible. They might have thought of additional tasks since the estimation meeting, which they could add to the task list now. Check to see whether tasks that had wildly different individual estimates have been merged in a sensible way. The ultimate objective is to produce an estimate range that allows the project manager and other key stakeholders to proceed with project planning and execution at an acceptable confidence level.

Completing the Estimation

The estimation process is completed when specified exit criteria are satisfied. Exit criteria help you determine when a process execution is done so you can declare victory and move on with your life. Typical Wideband Delphi exit criteria are that:

 The overall task list has been assembled.
 You have a summarized list of estimating assumptions.
 The estimators have reached consensus on how their individual estimates were synthesized into a single set with an acceptable range.

Now you must decide what to do with the data. You could simply average the final estimates to come up with a single point estimate, which is what the person who requested the estimate probably wants to hear.

However, a simple average is likely to be too low, and there is merit in retaining the estimate range. Estimates are predictions of the future, and the range reflects the inherent fuzziness of gazing into the crystal ball.

Following are several ways to present the results from the Delphi session, using the five estimates from Round 3 (shown in Figure 4 of the second article in this series) as an example.

  • Present just the average of the final individual estimates. (example: 1974 hours)
    wiegers May22 Img2
  • Present a single estimate calculated as follows (example: 1966 hours):
  • Present a range, with the average of the final estimates as the planned case, the minimum value as the best case, and the maximum value as the worst case. (example: 1974 hours planned, 1650 hours best case, 2250 hours worst case)
  • Present a range, with the average as the planned case, the upper bound being (maximum value – average) and the lower bound being (average – minimum value). (example: 1974 hours, +276 hours, –324 hours)

Each estimate has a certain probability of coming true, so a set of estimates forms a probability distribution. There are mathematically precise ways to combine multiple estimates and their uncertainties to generate an overall estimate with upper and lower prediction intervals (Watts Humphrey, A Discipline for Software Engineering, Addison-Wesley, 1995). Another sophisticated approach is to perform a Monte Carlo simulation to generate a probability distribution of possible estimate outcomes based on the final estimate values; see Nicholas A. Campanis, “Delphi: Not the Greek Oracle, but Close,” PM Network, vol. 11, no. 2 (Feb. 1997), pp. 46-49.

The results of a Delphi session might not be what the movers and shakers want to hear. But this information helps them determine whether they want to plan their project at a 10 percent confidence level, a 90 percent confidence level or somewhere in-between. Be sure to compare the actual project results to your estimates to improve your future estimating accuracy.

Wideband Delphi Evaluated

No estimation method is perfect; if it were, it would be called prediction, not estimation. However, the Wideband Delphi technique incorporates some solid estimating principles. The team approach acknowledges the value of combining multiple expert perspectives. The range of estimates produced reflects the variability intrinsic to the estimation process. Steve McConnell has found that Wideband Delphi can cut estimation errors by 40% to 60% (Software Estimation, Microsoft Press, 2006). It’s particularly useful in avoiding very large estimation errors.

Although it takes time and requires a panel of experienced estimators, Wideband Delphi removes some of the politics from estimation and filters out extreme initial values. This approach illustrates my philosophy of the correct answer to any request for an estimate: “Let me get back to you on that.”

Don’t forget to leave your comments below.

Stop Promising Miracles: Wideband Delphi Team Estimation, Part 2

In the first article in this three-part series I described some of the reasons why estimates often deviate wildly from reality, and I introduced an effective technique for group estimation called Wideband Delphi (see Figure 1). This article continues the description of Wideband Delphi, showing how the individual preparation and estimation meeting steps are carried out.
wiegers IMG01 APril24

Individual Preparation

Let’s assume you wish to estimate the total amount of work effort (typically expressed in labor hours) needed to complete a certain project. The estimation process begins with each participant independently developing an initial list of the tasks that will have to be completed, using a form like that in Figure 2. Figure 2 illustrates a very small estimation activity, developing the requirements for a new project cleverly titled Project X. The person who completed this form initially identified five tasks that would be involved in developing requirements, the first five items listed under the “Task” column heading.

Each participant then estimates the effort each task will consume. Decompose each activity down into tasks that are small enough to estimate accurately. State the tasks clearly because someone will have to merge all of the participant task lists into a single composite list. Total the estimates you produce for each project task, in the agreed-upon units, to generate your initial overall estimate. Returning to Figure 2, the column headed “Initial Estimate” shows the labor hours this estimator assigned to each of the five identified tasks, for a total of 67 hours estimated for developing the requirements for this project.

In addition to identifying the project tasks, separately record any tasks for related or supporting activities, such as quality tasks, process activities, and waiting time that impose delays. In my first Wideband Delphi session, every participant forgot to list tasks dealing with quality control and assurance, configuration management, and process-related activities on the first cycle. We caught this quickly and added them in for the next iteration. Be sure to include rework tasks following testing or inspection activities. Reworking to correct defects is a fact of life so you should plan for it. If you’re estimating a project schedule, also identify any overhead activities that aren’t specific to the project that you might have to build into your planning. These include meetings, vacation, training, other project assignments, and myriad other things that suck time out of your day.wiegers IMG02 APril24

Since radically different assumptions can lead to wide estimate variations, record any assumptions you made while preparing your estimates. For example, if you assumed that you will purchase a specific component library or reuse one from a previous project, write that down. Another estimator might assume that the project will custom-develop that component library, which will lead to a mismatch between your two overall estimates.

Keep the following estimation guidelines in mind, even if they don’t reflect exactly how the project work will be performed:

  • Assume one person will perform all tasks.
  • Assume all tasks will be performed sequentially; don’t worry about sequencing and predecessor tasks at this time.
  • Assume the worker can devote uninterrupted effort to each task. This may seem absurdly optimistic but it simplifies the estimation process.
  • In units of calendar time, list any known waiting times you expect to encounter between tasks. This will help you translate effort estimates into schedule estimates later on.

Estimation Meeting

The moderator begins the estimation meeting by collecting the participants’ individual estimates and creating a chart such as the one shown in Figure 3. Each participant’s total project estimate is plotted as an X on the “Round 1” line. Each estimator can see where his initial value fits along the spectrum. The initial estimates probably will cover a frighteningly large range. Just imagine the different conclusions you might have collected had you asked just one of these five individuals for his estimate!

The moderator does not identify who created each estimate. This anonymity is an important aspect of the Delphi technique. Anonymity prevents an outspoken colleague from intimidating the other participants into seeing things his way. It also means team members are less likely to defer to a more respected participant’s judgment when their own analyses lead to different conclusions.

Each estimator reads his initial task list aloud, identifying any assumptions made and raising any questions or issues, without revealing their task estimates. Different participants will think of different tasks. Combining these individual task lists leads to a more complete list than any single estimator would produce. This approach will work for up to several dozen individual tasks. If you have more tasks than that you might want to break the problem into several subproblems and estimate them individually.wiegers IMG03 APril24

During this discussion, the team members also talk about their assumptions, estimation issues, and questions they have about the problem. As a result, the team will begin to converge on a shared set of assumptions and a common task list. Retain this final task list to use as a starting point the next time you must estimate a similar activity.

After this initial discussion, all participants modify their estimates concurrently (and silently) in the meeting room. They might revise their task lists based on the information shared during the discussion, and they’ll adjust individual task estimates based on their new understanding of the task scope or changed assumptions. All estimators can add new tasks to their forms and note any changes they wish to make to their initial task estimates. The net change for all tasks equals the change in that participant’s overall project estimate.

Let’s continue with the example in Figure 2. Perhaps this estimator learned that some of the user representatives were already identified so he could remove one hour from his estimate for that task. This change of minus 1 hour appears in the column headed “Change #1”. He might have concluded that additional user requirements workshops would be needed and that more reviewers should look at the resulting specification. This resulted in increased estimates for those two tasks, as well as an increase in the estimated time to write the requirements specification. Maybe a developer in the workshop stated that he expected to use a more efficient prototyping tool, so our estimator reduced that task effort by eight hours. However, during the discussion for estimation round 1, someone else’s task list included the step of correcting errors found during the requirements review. Our estimator added that new task to his list, estimating five hours of effort. The cumulative change from these adjustments made during the second estimation round was an increase of 10 hours, for a revised total estimate of 78 hours.

The moderator collects the revised overall estimates and plots them on the same chart, on the Round 2 line. As Figure 4 illustrates, the second round might lead to a narrower distribution of estimates centered around a higher mean than the mean of the Round 1 values. Additional rounds should further narrow the distribution. The cycle of revising the task list, discussing issues and assumptions and preparing new estimates continues until one of the following conditions is fulfilled:

  • You have completed four estimation rounds.
  • The estimates have converged to an acceptably narrow range (defined in advance).
  • The allotted estimation meeting time (typically two hours) is over.
  • All participants are unwilling to alter their latest estimates.

wiegers IMG04 APril24
The moderator keeps the group on track, time-boxing discussions for each round to 15 or 20 minutes to avoid endless rambling. While preserving the anonymity of individual estimates is important for the first couple of rounds, the team members might agree at some point to put all their cards on the table and reach closure through an open discussion. This gives them a chance to discuss tasks for which their estimates vary substantially. Otherwise, though, the moderator should not identify the individual who produced each final estimate until the session is completed.

The final article in this series will describe the wrap-up process steps of assembling tasks into a single comprehensive list, reviewing the results, and completing the Wideband Delphi estimation session.

Don’t forget to leave your comments below.

Stop Promising Miracles: Wideband Delphi Team Estimation, Part 1

When I was a software developer I once received a phone call from my manager. “Got an hour?” he asked. My manager had received what seemed to be a trivial request from one of our customers. However, by the time I had understood the customer’s real need and wrote a small application to satisfy it, I had devoted 100 hours to this project. Not all project estimates are off by a factor of 100 but this is a striking example that it is indeed possible to go that far wrong.

This three-part series (adapted from my book Practical Project Initiation: A Handbook with Tools) describes an effective technique for group estimation called Wideband Delphi. The Wideband Delphi method pools the experience and knowledge of several estimators to come up with more realistic estimates than any one of them could have devised his own.

Estimation Shortcomings

Most software professionals must provide estimates for their work, but few of us are skillful estimators. Many of us haven’t been trained in estimation techniques. We’re too optimistic, with short memories that mask the painful overruns from previous projects. And we often overlook necessary aspects of an activity, so when we eventually confront those tasks, we either perform them—thereby exceeding our estimates—or skip them, perhaps compromising quality in the process.

The “Cone of Uncertainty” illustrated in Figure 1 cautions that estimates created very early in a project have very large deviations from the ultimate reality (see Steve McConnell, Software Estimation, Microsoft Press, 2006). Preliminary estimates based on limited information and many assumptions can be off by a factor of four on both the high side and the low side. Nonetheless, stakeholders do want some kind of estimates early in the project, recognizing that estimates will become both more accurate and more precise as the project continues.

Wiegers March27 img1

There are several ways to become a better estimator. The most basic is to record effort, duration, or size estimates along with your estimating processes and assumptions, and then record the actual results from each estimated activity. Comparing actual outcomes to the estimates helps you to generate more accurate estimates in the future. Estimation procedures and templates that itemize tasks help avoid the common problem of overlooking necessary work.

Another approach builds on the principle that multiple heads are better than one. Developed at the Rand Corporation in 1948, the Delphi estimation method uses 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. In the early 1970s, Barry Boehm and his Rand colleagues modified this method into Wideband Delphi, which included more estimation team interaction. Mary Sakry and Neil Potter of The Process Group (www.processgroup.com) later created a repeatable procedure for performing Wideband Delphi estimation on software projects.

Wideband Delphi

Using the Wideband Delphi method provides several advantages over obtaining just one estimate from a single individual. First, it helps build a comprehensive task list or work breakdown structure for major activities, because each participant will think of different tasks to perform. The consensus approach helps eliminate bias in estimates produced by self-proclaimed experts, inexperienced estimators, or influential individuals who have hidden agendas or divergent objectives. People are generally more committed to estimates they help produce than to those that others generate. No participant in an estimation activity knows the “right” answer; creating multiple estimates acknowledges this uncertainty. Finally, users of the Delphi approach exploit the value of iteration on any complex activity.

Wideband Delphi can be used to estimate virtually anything: the labor months needed to implement a specific subsystem, the lines of code or number of classes in an entire product, or the gallons of paint needed to redecorate your house. I used Wideband Delphi once with a process improvement group to estimate the effort it would take a particular organization to achieve a specific process improvement objective.

The Delphi method helps you develop a detailed work breakdown structure, which provides the foundation for bottom-up size, effort, or schedule estimation. The starting point for a Delphi session could be a specification of the problem being estimated, an initial high-level task list, or a preliminary project schedule. The outputs are: a detailed project task list; a list of associated quality, process-related and overhead tasks; estimation assumptions; and a set of task and overall project estimates, one from each participant.

Figure 2 illustrates the Wideband Delphi process flow. During planning, the project manager defines the problem being estimated and selects the participants. The kickoff meeting gets all estimators focused on the problem. Each participant then individually prepares his initial task lists and estimates. Estimators bring these items to the estimation meeting, during which several estimating cycles lead to a more comprehensive task list and a revised set of estimates. The moderator or project manager then consolidates the assorted estimation information offline, and the team reviews the estimation results. The session is completed when some predetermined exit criteria are satisfied. The resulting range of estimates will almost certainly be a more realistic predictor of the future than any single estimate could be. Let’s look at each of these process steps in turn.

Wiegers March27 img02

Planning

A Wideband Delphi session begins with defining and scoping the problem. Large problems are broken down into manageable portions that can be estimated more accurately, perhaps by different teams. The person who initiated the estimation activity assembles a problem specification that will give the participants enough information to produce informed, credible estimates.

The estimation participants include a moderator, who plans and coordinates the activity, the project manager, and two to four other estimators. The moderator should be informed enough to participate as an estimator, but the moderator acts as an impartial facilitator who won’t skew the results with his own biases or insights. The moderator and project manager select participants who understand the problem or project and the associated estimation issues.

The Kickoff

An initial kickoff meeting gets all participants up to speed on the estimation problem. The moderator explains the Wideband Delphi method to team members who aren’t familiar with it. He supplies the other estimators with the problem specification and any assumptions or project constraints.

The team reviews the estimation objectives and discusses the problem and any estimation issues. The participants agree on the estimation units they will use, such as weeks, labor hours, dollars, or lines of code. If the moderator concludes that all team members are sufficiently knowledgeable to contribute to the estimation activity, the group is ready to roll. The moderator might elect to replace certain estimators with others who can generate more accurate estimates.

To determine whether you’re ready to proceed with the Wideband Delphi session, check your entry criteria, the prerequisites that must be satisfied for you to proceed with subsequent process steps. Before you dive into the estimation exercise, ensure that the following conditions are satisfied:

  • Appropriate team members have been selected.
  • The kickoff meeting has been held.
  • The participants have agreed on the estimation goal and units.
  • The project manager can participate in the session.
  • The estimators have the information they need to participate effectively.

The next article in this series will describe what the estimation participants do during their individual preparation and also how the all-important estimation meeting is carried out.

Don’t forget to leave your comments below.

  • 1
  • 2