Re: IS AN ESTIMATE A COMMITMENT?

[Jill Burgchardt <jburgcha -at- PESTILENCE -dot- ITC -dot- NRCS -dot- USDA -dot- GOV>]

Estimates deal in variables, such as number of pages, number of
screens, or number of modules. In addition to quantity we need to
calculate a per item time.  When I give an estimate, the quantity
may change (beyond my control), but I'm committing to a per item
time/cost.

For example, if I go to the ballpark and order one hot dog, I
expect to pay $2.50.  If I order three, I expect to pay $7.50.
Now, if I'm taking my daughters to a game, I know they never eat
more than one each. I can accurately estimate that I'll need money
for a total of three hot dogs and three drinks. However, I'll take
a $20 bill with me, not the $15 that food will cost. The $5 is
"just in case."

Estimating usually includes a factor for some "unknowns." How
large that factor is depends on the degree to which some variable
may change. My daughters appetites are fairly predictable. If they
were to invite friends to come along, I'd be concerned that a
single hot dog wouldn't be enough. Then, I'd probably set some
limits, such as "no more than two hot dogs."

The same is true in a work estimate. I'm specific in the areas I
know well and I define what I'm willing to commit to in the gray
areas.  For example, I may estimate that a new module in the help
system will require 3 major topics and 22 definitions. When it
changes to 5 major topics and 54 definitions, I alert my manager
that the scope has changed and I quantify it.

If I should have known about the other two categories, my manager
has a right to be upset. (I was provided with the quantity
information and didn't use it.) But, if the developers added new
functionality my estimate is still an accurate reflection of the
original requirements. The new tasks are additional and that's
easy to point to and discuss with a manager.

Now, had I assumed that the stadium had $2.50 hot dogs and then
discovered they cost $5.00 my kids would be hungry and mad. If
your estimate was off in the time required for each item, you have
to look at entirely different factors. While I find some of my
business/systems analysis books better for itemizing quantity, I
think Hackos' book deals best with estimating time per item.  It
reduces some common factors (team experience, information
availability, etc.) to fuzzy logic. Each factor has a probability
of impacting the time required to do a task. If this is the
problem area, I'd suggest reading that section of Hackos'. Then,
take a pessimistic view estimating each of the factors until you
get used to working with them.  At least then you're likely to err
in the other direction.

Jill Burgchardt
jburgcha -at- pestilence -dot- itc -dot- nrcs -dot- usda -dot- gov