[consulting] Estimation-Blowout case-studies wanted

[Elvis McNeely]

Found to be clean, 
0X-Spam-Status: No
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server2.lafayetteweb.com
X-AntiAbuse: Original Domain - drupal.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - mcneelycorp.com

For what it is worth... Last year at the DrupalCon Boston, a Drupal shop 
owner answered my "how do you estimate more accurately" question like 
this; Review the specs, estimate in hours like you normally would, then 
multiply that by 1.7 (or 170%). I have used that model with some success.

I also try to weigh clients. Are they laid back, high maintenance, know 
what they want, a puppet for the board (who decides what goes or stays) 
etc. If any red flags come out of the initial consultation I make note 
and change that 1.7 by some factor.

It is not easy to have accurate estimates. If too many red flags come up 
early on, you always have the choice to walk away. Would you rather 
slave under a "estimate blowout" and tarnish your reputation or know 
you/staff are getting paid fairly and get more referrals?

Nice conversation. I am interested in hearing more how Drupal 
freelancers / shop owners handle this...

====================
Elvis McNeely
office: (765) 463-6221
skype me: elvis.mcneely
blog: http://elvisblogs.org
Web Developer / Freelancer / Drupal Specialist
Recent Work: http://elvisblogs.org/drupal-work
What is Drupal? http://drupal.org

Brian Vuyk wrote:
> 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
>>   
> 
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
> 
> 
> ------------------------------------------------------------------------
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.0.237 / Virus Database: 270.11.2/1964 - Release Date: 02/21/09 11:05:00
>