Page 45 -

open. Writing down the assumption allows the team to go back and revise the estimate
later if it turns out the assumption is wrong—which means that it is vital that everyone
understands that the assumptions are allowed to be incorrect. That way, if the team esti-
mated that they would build a command-line program but later the decision was made to
go with a full user interface, everyone will be able to explain why the schedule is delayed.

Another benefit of discussing assumptions is that it brings the team together very early on in
the project to make progress on important decisions that will affect development. It’s all too
common for a developer to make estimates after reading the vision and scope document but
before ever talking to anyone about the details of the project. Even if she writes down her
assumptions, she has almost certainly missed many others. A moderated discussion of
assumptions gives the project team a very effective forum to discuss the unknowns of the
project. Identifying unknowns eliminates the source of many inaccuracies in the estimates.

One side effect of writing down the assumptions is that it puts pressure on the senior man-
agers to allow the project to be estimated again if any of the assumptions prove to be
incorrect. This is why the project manager should plan on having the vision and scope
document updated to include any new assumptions that were identified during the esti-
mation session. This gives the stakeholders and management a chance to review those
assumptions and accept or reject them very early on, before they have had a chance to
interfere with the development of the software. By having the senior managers review the
assumptions, a project manager can reduce a source of future project delays.

Distrust Can Undermine Estimates
Estimates can either be a source of trust or distrust between the project team and their
managers. If the team knows that they are given the opportunity to fully justify their esti-
mates, and that they will be allowed to reestimate if the scope of the project changes, that
they won’t be punished for making an honest mistake in estimation, then each team
member will work very hard to produce accurate estimates. In this case, estimation can be
an effective tool for team motivation. Estimates are most accurate when everyone on the
project team feels that he was actively part of the estimation process. Every team member
feels a personal stake in the estimates, and will work very hard to meet any schedule
based on those estimates.

Estimation is, by its nature, a politically charged activity in most organizations. When a
team is asked to create estimates for work, they are essentially being asked to define their
own schedule. Stakeholders need the project completed but usually do not have software
engineering experience, so they may not be equipped to understand why a project will
take, say, six months instead of three. For this reason, project managers must take care to
make the estimation process as open and honest as possible so that the stakeholders can
understand what’s going on.

It is common for nontechnical people to assume that programmers pad their estimates. They
often have a “rule” by which they cut off a third or half of any estimate that they hear, and
expect that to be the “real” deadline. They often feel, fairly or not, that the engineering team

ESTIMATION 37