Page 58 -

extra time, are a chronic source of estimates that are too high. Senior managers giving unre-
alistic, overly aggressive deadlines are a chronic source of estimates that are too low. In both
cases, this can lead to morale problems.
There is a basic tug-of-war going on here. Engineers prefer higher estimates, giving them
as much time and as little pressure as possible to do their work. Managers prefer to deliver
things more quickly, in order to please stakeholders. The only way for a project manager
to avoid this conflict is to work with the team to produce estimates that are as accurate as
possible. By adopting a sound estimation process that allows the team and the project
manager to reach a consensus on the effort involved in the work, the morale is main-
tained and the work is much more predictable.

Padded Estimates Generate Distrust
In some organizations, the project team drives the entire estimation process and the
project manager simply builds a schedule around their estimates. This can be comfortable
for the team, but it does not always work well for the organization, and it can eventually
lead to an environment where the managers don’t trust the programmers.
There are many reasons why estimates are wrong that have nothing to do with the work
being done. Software engineers are often overoptimistic by nature—it’s easy to be very
positive about a project before doing any of the work, and it’s easy to ignore problems that
may come up later. It’s very tempting to pad estimates, since they lead to longer schedules
and less pressure.
The situation is especially bad when someone with no formal training in software engi-
neering and little experience estimating software tasks is asked by her manager to give
estimates. She is forced into a difficult situation: if her estimates come up short, she will be
penalized at her next review. She could pad the estimates, but that would be dishonest.
Her manager will eventually catch on and start cutting down any estimate she provides.
Either of these options can lead to unreliable estimates that throw off the entire project
planning process. She feels like she’s left hanging with little support, and if her manager
sees that her estimates are off, he could end up distrusting ones she makes in the future.
A programmer who knows that there will be ramifications—a poor review, a lower raise—

if he does not meet his estimates may pad them, often extending his estimates by a factor
of two or three. Managers will usually catch onto this, making it clear that they don’t trust
the programmer’s estimates and asking for the tasks to be done early. The programmer, in
turn, will only pad the estimates more. This “arms race” usually leads to a complete break-
down of the planning process.

A project manager could avoid the problem of estimates that are chronically padded by
having the team reach a consensus on their estimates in an open meeting, where team
members are less likely to pad their numbers. Team members who have thoroughly dis-
cussed their assumptions about the estimates are much less likely to be overly optimistic—
they remain more grounded in the facts of the project, and will not sweep as many details
aside. It may be tempting to pad estimates when delivering them by email; it is much

50 CHAPTER THREE