Page 125 - DCAP304_DCAP515_SOFTWARE_PROJECT_MANAGEMENT

Unit 6: Effort Estimation

It is common for non-technical people to assume that programmers pad their estimates. They Notes
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 is “putting
one over” on them, mostly because the entire engineering process is, to them, a mystery. This
lack of trust causes engineers to automatically pad their estimates, because they know they
won’t be given enough time otherwise. And even when the situation is not this bad (although it
often is), some environment of distrust still exists to a lesser extent in many organizations.

In many of these organizations, there are some kinds of estimates—especially those for quality
and requirements tasks—that are particularly likely to not be taken seriously.
Senior managers are often willing to take the programmers’ estimates at face value, even when
those estimates are clearly padded. This is because, to them, programming is opaque: managers
and stakeholders don’t understand how code is written, so they assume that all programming
tasks are difficult. They are more likely to trust programmers’ estimates, even when those
estimates are highly padded. Requirements analysts, on the other hand, often produce
specifications using nothing more than a word processor. A manager or stakeholder is much
more likely to trivialize that work and distrust the estimate because he (incorrectly) feels that he
has an intuitive grasp on the work being done. Even worse, in some organizations there is a
“rule” that testing should always take exactly one-third (or some other fixed ratio) of the
programming time, which causes the testing effort to be shortchanged by only allowing exactly
that much time for it instead of the actual amount of time testing would require.
Distrust in a software organization can be a serious, endemic problem. It starts with a kernel of
distrust between management and the engineering team; the distrust grows until management
simply won’t accept the team’s estimates. For example, a senior manager may decide that the
team plans to spend too much time testing the software, even though the team reached consensus
and all team members stand behind the estimates. A project manager must be especially careful
to explain this and support that consensus when senior managers start to pick apart the team’s
estimates. If deadlines are handed down that do not allow enough time for the team to complete
the work, it can lead to serious morale problems—and the project manager will be blamed for
the delay, often by the same people who caused it in the first place.
An important part of running successful software projects is reaching a common understanding
between the engineers, managers, and stakeholders. One way to do that is with a consistent set
of practices. This allows the engineers’ work to be transparent to the rest of the organization.
Similarly, the managers’ and stakeholders’ needs and expectations must be transparent to the
engineers. By having key managers attend the estimation session, a project manager can show
them that the estimates are made systematically, using an orderly and sensible process, and that
they are not just made up on a whim. When the team is having trouble reaching convergence on
a task, team members should bring up examples of past results for tasks of similar size and
complexity. This transparency helps everyone present (especially the observers) understand
why these estimates come out as they do.
Estimation is the calculated approximation of a result which is usable even if input data may be
incomplete or uncertain.
In project management (i.e., for engineering), accurate estimates are the basis of sound project
planning. Many processes have been developed to aid engineers in making accurate estimates,
such as:

 compartmentalization (i.e., breakdown of tasks),
 parametric estimating,
 structured planning,
 educated assumptions,

LOVELY PROFESSIONAL UNIVERSITY 119