[consulting] Estimation-Blowout case-studies wanted

[Victor Kane]

Interesting topic!

First of all, this is true of all software projects, not just Drupal!

Secondly, apart from the excellent points made by Ben, one of the "culprits"
is the failure to take into account change management.

Here, there is a kind of "apples to oranges" fallacy.

It has been estimated (I think the US Department of Defense were interested
in this very same question some time ago) that during the course of any
software project, there is a minimum change of 40% in the requirements as
the project progresses.

So, right off the bat, it is very difficult to do 140% of the work in 100%
of the time.

Something else to consider is the success of iterative and incremental
approaches is very high when compared to the "waterfall" method implicit in
your question: 1) figure out what you want, 2) do it, 3) wonder why it took
so long.

If the project is split into iterations, and these into releases, the
estimation / implementation game can be handled in many bite size chunks,
and the team gets better and better at that.

Just a few ideas on a very complex subject. See this 1994 Scientific
American article: Software's Chronic Crisis
http://www.cis.gsu.edu/~mmoore/CIS3300/handouts/SciAmSept1994.html
It is interesting because it is dated... and it mentions an early form of
CMM (Capability Maturity Model).

Victor Kane
http://awebfactory.com.ar
On Sat, Feb 21, 2009 at 1:03 AM, Ben West <westbywest at gmail.com> wrote:

> Predicting the future is indeed a hard trick to pull off each and
> every time.  ;)  This task is especially difficult for freelancers who
> have concern about particular projects requiring more hours than their
> client is willing to pay for.
>
> I'm not sure if there can ever be an overall methodology for
> predicting hours spent, but there are always some common-sense
> inspired points to keep in mind, e.g
>
> - How many person-hours did a similar job require in the past, e.g.
> upgrading drupal.org from v4.7 to 5.0?
>
> - Were many hours spent debugging items like usability and browser
> compatibility?  For my estimates, I try to give very rough guesses for
> time spent on usability and browser issues as additional line items,
> using values like 1hr per each unproven module or 30min per each page
> built from scratch.
>
> - What some people call "padding hours" I tend to call "guard band."
>
> - What are actual milestones to "completion" and/or satisfaction of
> the client?  If these 2 things are not actually identical, then there
> is possibility for feature creep to increase the # of hour spent.
>
> On Fri, Feb 20, 2009 at 8:34 PM, John Saward <john at also.com.au> 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
> >
>
>
>
> --
> Ben West
> westbywest at gmail.com
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20090221/8b444559/attachment-0001.htm