Interesting topic!<br><br>First of all, this is true of all software projects, not just Drupal!<br><br>Secondly, apart from the excellent points made by Ben, one of the "culprits" is the failure to take into account change management.<br>
<br>Here, there is a kind of "apples to oranges" fallacy.<br><br>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.<br>
<br>So, right off the bat, it is very difficult to do 140% of the work in 100% of the time.<br><br>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.<br>
<br>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.<br><br>Just a few ideas on a very complex subject. See this 1994 Scientific American article: Software's Chronic Crisis <br>
<a href="http://www.cis.gsu.edu/~mmoore/CIS3300/handouts/SciAmSept1994.html">http://www.cis.gsu.edu/~mmoore/CIS3300/handouts/SciAmSept1994.html</a><br>It is interesting because it is dated... and it mentions an early form of CMM (Capability Maturity Model).<br>
<br>Victor Kane<br><a href="http://awebfactory.com.ar">http://awebfactory.com.ar</a><br><div class="gmail_quote">On Sat, Feb 21, 2009 at 1:03 AM, Ben West <span dir="ltr"><<a href="mailto:westbywest@gmail.com">westbywest@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Predicting the future is indeed a hard trick to pull off each and<br>
every time. ;) This task is especially difficult for freelancers who<br>
have concern about particular projects requiring more hours than their<br>
client is willing to pay for.<br>
<br>
I'm not sure if there can ever be an overall methodology for<br>
predicting hours spent, but there are always some common-sense<br>
inspired points to keep in mind, e.g<br>
<br>
- How many person-hours did a similar job require in the past, e.g.<br>
upgrading <a href="http://drupal.org" target="_blank">drupal.org</a> from v4.7 to 5.0?<br>
<br>
- Were many hours spent debugging items like usability and browser<br>
compatibility? For my estimates, I try to give very rough guesses for<br>
time spent on usability and browser issues as additional line items,<br>
using values like 1hr per each unproven module or 30min per each page<br>
built from scratch.<br>
<br>
- What some people call "padding hours" I tend to call "guard band."<br>
<br>
- What are actual milestones to "completion" and/or satisfaction of<br>
the client? If these 2 things are not actually identical, then there<br>
is possibility for feature creep to increase the # of hour spent.<br>
<div><div></div><div class="Wj3C7c"><br>
On Fri, Feb 20, 2009 at 8:34 PM, John Saward <<a href="mailto:john@also.com.au">john@also.com.au</a>> wrote:<br>
> I'm currently very interested in people's experiences with<br>
> 'estimation-blowout'.<br>
><br>
> In my experience, and discussions with Project Managers, Developers<br>
> and Clients I find that quite often the number of hours to actually<br>
> complete a Drupal project or task, is considerably more than the<br>
> number of hours estimated beforehand. This creates problems<br>
> (budgetary and otherwise) and stress and even resentments to all<br>
> involved whether the work is being performed on a<br>
> fixed-price-quotation, estimated or actual-hours basis.<br>
><br>
> I note the comment from the team who recently updated <a href="http://drupal.org" target="_blank">drupal.org</a> from<br>
> 5 to 6, "So while we crafted a fine plan for the upgrade, it took a<br>
> few more hours then originally planned." <a href="http://drupal.org/node/376454" target="_blank">http://drupal.org/node/376454</a>.<br>
><br>
> I'm understanding that the preparation and planning for the upgrade<br>
> was a mammoth task, when I read the report of the upgrade sprint, at<br>
> <a href="http://drupal.org/node/366562" target="_blank">http://drupal.org/node/366562</a>. Those at the sprint, and other<br>
> contributors, worked hard doing all that was humanly possible to<br>
> prepare and plan for the upgrade so that least downtime as possible<br>
> would be entailed. One outcome of the sprint would have been an<br>
> estimation of how many hours would be required for the final push,<br>
> the working time that would necessarily entail site downtime. And now<br>
> I see that the actual upgrade was more intricate and time-consuming<br>
> than that prediction.<br>
><br>
> My thinking is that these guys are some of the most experienced<br>
> Drupal engineers around; and most familiar with the entire <a href="http://drupal.org" target="_blank">drupal.org</a><br>
> infrastructure. If they are unable to predict the hours beforehand,<br>
> even after going into 'fine planning' .... well.... who could have?<br>
><br>
> What does it take to accurately estimate a significant Drupal<br>
> project? Experience obviously, but it seems that is not always enough<br>
> in itself. Are there just always too many unknowns, too many<br>
> variables, too many 'what ifs' to be overlooked, in any<br>
> more-than-basic Drupal work? Is accurate estimation for anything<br>
> other than highly-repetitive tasks.... verging on the impossible?<br>
><br>
> I'm interested in hearing views and experiences about this.<br>
><br>
> And also I'm interested to know if the upgrade team has a record of<br>
> hours predicted against actual hours taken, for the upgrade.<br>
><br>
> John<br>
><br>
> ==============<br>
> John Saward<br>
> <a href="http://www.drupal.com.au" target="_blank">www.drupal.com.au</a><br>
> 03 5968 1541<br>
> ==============<br>
><br>
> _______________________________________________<br>
> consulting mailing list<br>
> <a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br>
> <a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
Ben West<br>
<a href="mailto:westbywest@gmail.com">westbywest@gmail.com</a><br>
</font><div><div></div><div class="Wj3C7c">_______________________________________________<br>
consulting mailing list<br>
<a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br>
<a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
</div></div></blockquote></div><br>