Page 56 -

Sometimes there may be a team member who disagrees with the team’s assessment esti-
mate for a task, and continues to disagree with it over the course of the project. The
project manager must be careful in this situation, especially if the disagreement is over a
task that will be assigned to that team member. An important part of the Delphi process is
that it generates consensus among the team about the final schedule. That consensus can
be much harder to achieve if any of the team members feels like her objections are being
ignored. One way for the project manager to make sure that this does not happen is to call
an additional meeting to discuss the outlying estimates. During this meeting, the project
manager must take the time to listen to everything that the person who differs from the
rest of the team has to say. The final decision about the effort still lies with the project
manager; however, if there is a genuine disagreement, then the person who disagrees
with the rest of the team will at least feel like his objections were heard and evaluated on
their merits, rather than just rejected outright.

Review results

Once the results are ready, the project manager calls a final meeting to review the estima-
tion results with the team. The goal of the meeting is to determine whether the results of
the session are sufficient for further planning. The team should determine whether the
estimates make sense and if the range is acceptable. They should also examine the final
task list to verify that it’s complete. There may be an area that needs to be refined: for
example, a task might need to be broken down into subtasks. In this case, the team may
agree to hold another estimation session to break down those tasks into their own sub-
tasks and estimate each of them. This is also a good way to handle any tasks that have a
wide discrepancy between the best-case and worst-case scenarios.

Other Estimation Techniques

Wideband Delphi is not the only technique that can be effective in estimating software
tasks. Here are a few popular and effective alternatives.

PROBE
Proxy Based Estimating (PROBE), is the estimation method introduced by Watts Hum-

phrey (of the Software Engineering Institute at Carnegie Mellon University) as part of the
Personal Software Process (a discipline that helps individual software engineers monitor,
test, and improve their own work). PROBE is based on the idea that if an engineer is
building a component similar to one he built previously, then it will take about the same
effort as it did in the past.

In the PROBE method, individual engineers use a database to keep track of the size and
effort of all of the work that they do, developing a history of the effort they have put into
their past projects, broken into individual components. Each component in the database is
assigned a type (“calculation,” “data,” “logic,” etc.) and a size (from “very small” to “very
large”). When a new project must be estimated, it is broken down into tasks that corre-
spond to these types and sizes. A formula based on linear regression is used to calculate

48 CHAPTER THREE