
Can we put an end to this ‘Estimate’ game of fools? - ohjeez
http://blog.frankel.ch/can-we-put-an-end-to-this-estimate-game-of-fools
======
herm
The true value of an estimate is not about what you thought the project would
initially cost, but rather, the true value of an estimate is as a tool to
estimate the final cost of the project once the project is underway.

Trying not to get into too much detail here, but, when you devise your initial
estimate you should have a list of deliverables and you should determine what
you think those deliverables will cost to implement. Your initial estimate
will then become your baseline, and is mainly used to keep track of what you
initially agreed upon (scope) and as a way to measure your progress.

Imagine that based upon your original estimate you have a deliverable that to
implement will cost $50,000, but you have already spent $30,000 to implement
it and are only 10% done. Well then your new estimate would now balloon out to
$300,000 and it will take 10x as long. If you replicate this process out
across all of your deliverables based on their progress you will have a new
estimate, as the project continues your estimate will become more and more
accurate.

Beyond having a better understanding of what your project will actually cost,
you will also have a tool to handle scope changes by management and/or the
client. You will automatically have an idea of based upon your prior
performance on this project the feature that they ask will cost them $X
additional dollars and increase the duration of the project by Y Days, or, as
a way to negotiate a reduction in scope in order to stay within your budget.

There are certain mega engineering firms that make all their money solely off
of defining the estimate and scope at a very detailed level up front and then
renegotiating the (hell out of the) price as new scope is introduced.

Here's a link for more information:

[http://en.wikipedia.org/wiki/Earned_value_management](http://en.wikipedia.org/wiki/Earned_value_management)

------
mathattack
The reality is very few projects will ever be approved in every field with "I
don't know?" as the answer to "How much will it cost?"

Estimation is by far the trickiest project management tool. 2 identical
projects with identical caliber teams will come up with very different
results. All you can do is use the estimate for a very imprecise first guess
to get things started.

Of course very little is known for sure early on. The scope isn't final. The
tolerated risks aren't final. The project team isn't final. The target quality
level isn't final.

So what can you do? Admit that these are in flux, and be proactive about
managing them. "Ok, now that we know more, it looks like things are more
expensive. Do we fix the cost and reduce the scope, or fix the scope to reduce
the cost? If hitting the budget is the most important thing, should we
preemptively cut scope?" These are the way discussions have to be managed.

------
VikingCoder
A team of 4 was told to move 7 tons of bricks 100 yards. Dutifully, they
loaded a wagon by hand, moved the wagon 100 yards and dumped the bricks out.
Again and again. After about 1 ton, Management wanted to know how long it
would take to move all the bricks. The team multiplied their time spent so far
by 7. Management wasn't happy.

Trying to be helpful, Management bought 6 more wagons.

The team said that with 4 team members, they couldn't productively use more
than 4 wagons. Could we please have another team member? Management wasn't
happy.

Trying to be helpful, Management set a deadline, and gave a speech about how
important the deadline was to the company.

The deadline was completely unrealistic. The team worked to move bricks as
fast as it could. After moving about 3 tons of bricks, they missed their first
deadline. Management wasn't happy.

Trying to be helpful, Management set a deadline, and changed the goal to be to
move the bricks 60 yards.

The team was pretty happy for a while... Until they realized that management
wanted them to move those first 3 tons of bricks BACKWARDS 40 yards. They
tried to explain that this was like moving 3 * 140 + 7 * 60 = 840 brick-ton-
yards, rather than 7 * 100 = 700 brick-ton-yards, and was therefore an even
harder goal! Management wasn't happy.

Trying to be helpful, Management hired a consultant.

The team was told to stop moving bricks for a while, and talk about everything
with the consultant. The consultant gave some fun presentations, and coached
the team through a lot of soul searching... They decided to have stand-up
meetings every so often, to talk about their progress, and their plans for the
day. The meetings took more time, and bricks weren't moving themselves. The
team now had about 1 ton of bricks at the 100 yard line, 2 tons of bricks at
the 60 yard line, and 4 tons of bricks at the 0 yard line. Management wasn't
happy.

Trying to be helpful, Management bought 7 tons of gravel, and dropped it the 0
yard line, and said the new goal was to move the gravel 75 yards. They also
hired an offshore team, but all they could really do was try to dial in to
conference calls at weird hours of the day, and they really couldn't help move
any of the gravel. Then one of the Managers was fired, and the new Manager
said the goal was to move 1 ton of bricks and 2 tons of gravel 186 miles, in
the back of an El Camino, that has no tires and no engine, and there's no
budget for either...

...then some manager four levels up in the company decided to spend enough
money to rent a few pieces of construction equipment, brought in an external
team, and moved all 7 tons of bricks and all 7 tons of gravel the whole 186
miles in record time. With scorn, he talks to his peers about how awful his
team is. No raises. No bonuses.

