[consulting] Estimation-Blowout case-studies wanted

Mon Feb 23 00:05:34 UTC 2009

Estimating time is indeed difficult. We've had success with applying a 
strict method of using fixed amounts of time and breaking tasks down. We 
estimate in man hours, and use a fixed scale of units: 1, 2, 5, 10, 20, 
50, 100. The rule of thumb is to pick the higher of the two if your 
estimate lies between two. If unsure, divide and conquer - break down 
the task and estimate each subtask.

It's better with a mix of 10's, 20's and 50's than multiple 100 hour 
blocks as the risk of error stands in proportion to the size of the 
estimate. This way, you can better control potentially inaccurate 
estimates. By assigning a complexity and risk rating to each estimated 
item you can also take risk and complexity in account when doing project 
planning. We've had good success and produced eerily accurate estimates 
this way.

As many of you have observed, making accurate estimates is 
time-consuming, especially with Drupal where many features can be 
implemented by combining existing modules and code. You can usually 
spend half an hour to an hour to make a rough estimate based on your 
experience with an accuracy of a few hundred hours.  That's what we do 
as part of a quote for a client, and we can also see roughly what 
competence is needed where and include that as well.

If the client wants more precision, what we offer them is a pilot study 
that lays the foundation for the development process. Many people can 
build Drupal sites but not all can do it well, The Drupal Way, as we 
say. Most programmers can use Drupal to implement anything 
monolithically and not reuse existing modules and combine them. However 
if you want to work efficiently with Drupal you need to know the 
terrain, know how to use existing modules to build what the client 
needs. This task is what we refer to as Drupal architecture, and it 
takes an experienced Drupal developer to tell where a custom module is 
needed and where an existing one can do the job. More importantly, 
sometimes a client can relax some requirements and thereby get 95% of 
the functionality at 50% of the time it would take to implement 
something exactly to spec by going with an existing solution.

In our dreams we get to take care of everything from design to 
implementation and have a concise unambiguous specification to work 
with. In reality you often get a complete design mockup in your hand and 
you're told to implement it. The time estimates for mockup designs tend 
to get high as there are a lot of details that need customized 
solutions. When we talk to them about The Drupal Way, clients get 
excited when they hear how much time they can save by doing things a 
little bit differently than their designer envisioned.

As part of a pilot study we include suggested implementation guidelines 
(a "recipe") with time estimates and complexity rating. It explains how 
to build the site on Drupal exactly to spec and how a similar solution 
that depends on existing functionality (The Drupal Way) can cut 
implementation time considerably and what effects it has. Such 
guidelines can then be used by the client to make informed decisions 
before the actual development work starts. Since the pilot study is a 
service we offer we can dedicate time to building small test sites and 
evaluate the solutions we suggest. That enables us to make time 
estimates that are based on actual hands-on experience rather than 
extrapolated numbers and projections based on experience.

Being honest and telling your client you can't give an estimate, that 
the information provided is insufficient and that you'd rather focus on 
producing a pilot study for them is often a good idea. Clients that are 
familiar with software development understand your reasons and will 
consider you a more serious partner than a company that gives a fixed 
even price (say 200 000). After all, a successful project is something 
both you and your client will benefit from. Showing that you do not want 
to compromise your relationship by running the risk of selling something 
you cannot deliver on time and with the quality required strengthens 
that relationship.

Cheers,

Jakob

-- 
Jakob Persson
Co-founder and Consultant at NodeOne
"Empower the user"
-------------------------------------------
STOCKHOLM:          GOTHENBURG:
Kåkbrinken 11A      Vita gavelns väg 10
SE11127 Stockholm   SE42671 Västra Frölunda
SWEDEN
Phone: +46 31 780 02 23
http://www.nodeone.se

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
>   

-- 
Jakob Persson
Co-founder and Consultant at NodeOne
"Empower the user"
-------------------------------------------
STOCKHOLM:          GOTHENBURG:
Kåkbrinken 11A      Vita gavelns väg 10
SE11127 Stockholm   SE42671 Västra Frölunda
SWEDEN
Phone: +46 31 780 02 23
http://www.nodeone.se