[consulting] Estimation-Blowout case-studies wanted

[Brian Vuyk]

What you mention below is the main reason I tend to go over my initial 
hourly projections - it's impossible to know the specific problems you 
will face implementing a lot of non-core functionality until you've done 
it!

With my projects, I've taken to estimating the hours involved before 
hand on paper. Then I add up to 50% more hours, depending on the scope 
and complexity of the project. This usually brings me fairly close to 
the hours a project ends up working out to. Of course, this approach 
probably doesn't work for everyone; I think I have a bad habit of 
estimating low and requiring such a safety margin. On the (fairly rare) 
occasion where I come in a ways under what I quoted on, I will usually 
implement a few 'extra' features that may have been tossed around with 
the client, but put aside for various reasons.

As per Victor Cane's comments on specifications changes, my clients 
usually sign to a set of specifications prior to the project beginning 
building. Any major specification changes are negotiated as they come 
up. That is, I will give the client an estimate on the extra cost and 
schedule impacts that these changes will bring.

Brian

Sam Cohen wrote:
>
> To start, if a client wants any non-core functionality, there's the 
> issue of whether or not a module exists that can do this.  And if 
> there is,  how close will it get. 
>
> It's often not possible or practical to do the research it would take 
> to determine these things up front, so there's an enormous amount of 
> guess work involved. 
>
> Sam
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>