Page 254 -

One reason is that the organization already committed to an earlier date for the software,
and changing that expectation is difficult or impossible for the manager. This means that
the project was not planned properly. The solution is to apply the project planning and
estimation tools and techniques to bring the project under control. If the estimate does not
meet the needs of the organization, the manager has several options: the scope of the
project can be scaled back; the software can be released in phases; the deadline can be
renegotiated; resources can be added; or some combination of all of these can be done.
The team will generally respect the decision, as long as it was clearly based on honest esti-
mates and planning rather than an artificial date.
The second reason that an estimate may be second-guessed is that this second-guessing is a
misguided attempt to motivate the team. For some reason—and nobody is really sure why
some people believe this—there are managers who think that telling somebody that they can
do a task in less time than they estimated will cause them to “step up to the plate.” Somehow,
knowing that their manager believes that they can do it is supposed to increase their produc-
tivity. Unfortunately, this sort of second-guessing becomes a self-fulfilling prophecy. As the
team realizes that their estimates will always be cut, they will start padding those estimates.
This can create an environment of distrust between the team and their manager.
The third reason managers will second-guess their teams’ estimates is to force them to
work overtime. By enforcing an overly aggressive deadline, some managers find that they
can squeeze five, ten, or more extra hours per week out of all of their team members. This
is especially dishonest, and it almost always breeds resentment. If the team is expected to
work overtime—and in some cases, this is a valid and realistic expectation—that should be
taken into account when the effort estimates are turned into a project schedule. This way,
the team is not blindsided by the extra work and can plan their lives around it. (Some-
times managers forget that people have lives outside the organization!)

In all of these cases, the key to understanding how the team members react to second-
guessing is to recognize that they believe their manager is sending them a clear message:
he does not trust their estimates. The solution to this is to establish trust by making deci-
sions in a transparent manner. (A good way to do this is to use a repeatable estimation
process like Wideband Delphi—see Chapter 3.)

This does not mean that the project manager does not need to understand estimates. It is
important for a project manager to not only understand the reasons why the team esti-
mated a certain effort for a task, but to question the estimate if it looks inaccurate, unreal-
istic, or seems to be based on incorrect assumptions. As long as the questions are
reasonable and can be answered with facts, the team will generally respect them and work
to answer them. If it turns out that the estimate is, in fact, unrealistic, the team will be
glad that the project manager pointed out a potential problem with it!

Don’t expect consensus all of the time
Over the course of almost any project, there will be disagreements between team mem-
bers. Some project managers make the mistake of expecting the team members to settle all
of these disagreements, reaching a consensus on their own. The project manager treats all

246 CHAPTER TEN