[consulting] Estimation-Blowout case-studies wanted

Sat Feb 21 18:01:53 UTC 2009

These are all great ideas.

The problem is that everyone is still clued into getting from A to B, with
change seen as the exception rather than the rule.

Change is the way the client finds out what they want. The only way that can
help instead of hinder is if the client participates directly in the work;
and if the work is done in iterative, incremental short bursts, or sprints,
or phases.

Change doesn't just mean "I want green instead of grey". It also is the way
people realize what it is they wanted in the first place, or what they
thought they meant.

The rapid feedback of the short sprints can save everyone time, and everyone
gets better at it as time passes.

Otherwise things get too mechanical and no-one gets what they want.

Just my two cents.

Victor Kane
http://awebfactory.com.ar
http://projectflowandtracker.com (behind schedule :)

On Sat, Feb 21, 2009 at 3:36 PM, Gwennie Cakes <gwenniecakes at gmail.com>wrote:

> One strategy a friend has pursued with some success is to put a client
> friendly hour cap on fixed rate work. Most clients are willing to be fair
> (tho often not generous) about compensation, so if you spend a little time
> explaining the issues involved in estimating hours (new requirements coming
> up, guessing how much time will be wasted by communications snafus, weird
> bugs in 3rd party code, etc.), they're often cool with putting a max hourly
> cap on work. Particularly if you mention you usually charge $x an hour for
> hourly work and skew max hours in their favor, it feels like they're getting
> a discount.
>
> For drupal specifically, someone I know puts a clause into their contracts
> that says something like: "I'm going to use x, y and z modules to meet a, b
> and c requirements to build your site faster. Work estimated only includes
> installation, configuration and basic themeing of these 3rd party modules.
> If I need to write extra custom code b/c the module developer did something
> not exactly how you want it, we'll have to negotiate for extra work."
>
> Finally, for estimating hours, most project managers I know *at least*
> double developer estimates, sometimes going as high as 3x if it's a large
> project with lots of moving parts. If you're playing project manager to
> yourself, it can feel weird to do this, but it's a smart thing to do since a
> lot of delays are client side (slow/bad communication, changing
> requirements, delayed decision making, super nitpicky, etc). Elvis' point
> about gauging your client is really spot on when it comes to adjusting the
> multiplier.
>
> gwen
>
>
> On Sat, Feb 21, 2009 at 8:50 AM, Elvis McNeely <office at mcneelycorp.com>wrote:
>
>> 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
>> >
>> _______________________________________________
>> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20090221/2a2e9b60/attachment.htm 