[consulting] Estimation-Blowout case-studies wanted

[Adam Mordecai]

We have a very strict formula in place. We take our developers  
estimates and then add three line items to the estimates. Each is  
determined on a percentage basis from the total cost of the proposal  
(sans the three items below).

1. Project Management 30%
2. Contingency 30-50%
3. Quality Assurance 30%

This essentially doubles our estimates (which mean more declined  
proposals) but gives us protection against disasters, and keeps  
clients happier in the long run.

Depending on the client, the specificity of their requirements, and  
the expected personality of said client contingency percentage  
changes. If we think they are going to add a ton of things down the  
road, we add that to contingency and explain to them at the beginning  
that contingency is explicitly based on how many extra things they  
add. If they are happy with how things stand at the beginning, and  
have a very specific RFP then contingency could be 0, but  
realistically some things will change. When initially talking to the  
client, we can usually tell if they know what they want or if they are  
gonna change their mind a ton. Additionally if they make a major  
change, we estimate it out separate from the original estimate and  
make them sign off on it.

After a project is over, if there were a lot of estimates that seemed  
out of wack, we review each developers project time and see where  
their overages were. We sit down with our dev, ask them why certain  
things went over, which gives them and us perspective for the next  
project they estimate. Rinse wash repeat.



On Feb 20, 2009, at 7:34 PM, John Saward wrote:

I'm currently very interested in people's experiences with
'estimation-blowout'.

In my experience, and discussions with Project Managers, Developers
and Clients I find that quite often the number of hours to actually
complete a Drupal project or task, is considerably more than the
number of hours estimated beforehand. This creates problems
(budgetary and otherwise) and stress and even resentments to all
involved whether the work is being performed on a
fixed-price-quotation, estimated or actual-hours basis.

I note the comment from the team who recently updated drupal.org from
5 to 6, "So while we crafted a fine plan for the upgrade, it took a
few more hours then originally planned." http://drupal.org/node/376454.

I'm understanding that the preparation and planning for the upgrade
was a mammoth task, when I read the report of the upgrade sprint, at
http://drupal.org/node/366562. Those at the sprint, and other
contributors, worked hard doing all that was humanly possible to
prepare and plan for the upgrade so that least downtime as possible
would be entailed.  One outcome of the sprint would have been an
estimation of how many hours would be required for the final push,
the working time that would necessarily entail site downtime. And now
I see that the actual upgrade was more intricate and time-consuming
than that prediction.

My thinking is that these guys are some of the most experienced
Drupal engineers around; and most familiar with the entire drupal.org
infrastructure. If they are unable to predict the hours beforehand,
even after going into 'fine planning' .... well.... who could have?

What does it take to accurately estimate a significant Drupal
project? Experience obviously, but it seems that is not always enough
in itself. Are there just always too many unknowns, too many
variables, too many 'what ifs' to be overlooked, in any
more-than-basic Drupal work?  Is accurate estimation for anything
other than highly-repetitive tasks.... verging on the impossible?

I'm interested in hearing views and experiences about this.

And also I'm interested to know if the upgrade team has a record of
hours predicted against actual hours taken, for the upgrade.

John

==============
John Saward
www.drupal.com.au
03 5968 1541
==============

_______________________________________________
consulting mailing list
consulting at drupal.org
http://lists.drupal.org/mailman/listinfo/consulting