[consulting] Estimation-Blowout case-studies wanted

Wed Feb 25 11:13:17 UTC 2009

I think the most worrying part of an estimate is the gap between design and
implementation. Except for projects that are totally in-house, a client
usually wants to get a custom design that simply does not reflect on what
modules provide, then time is totally wasted on forcing modules to look some
very awkward way or creating new UI facets for them.

I believe that even more of a risk is when a designer conceptualizes a
totally different way for doing something which can be done with less effort
by a combination of modules.

A Drupal developer/designer is a true asset when it comes to that as he
would be designing based on his knowledge of modules and their default
implementations. Although similar risks apply when dealing with new projects
and new modules.

Has anyone faced this problem? How do you begin to tackle it? What do you do
when the client wants the design to come out from his side and you know the
deisnger will totally be someone unacquainted with Drupal? And in some cases
I faced, not acquainted with web development!

On Mon, Feb 23, 2009 at 2:05 AM, Jakob Persson <jakob at nodeone.se> wrote:

>
> 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
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>

-- 
Ashraf Amayreh
http://aamayreh.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20090225/870bca68/attachment.htm 