[consulting] Estimation-Blowout case-studies wanted
Brian Vuyk
brian at brianvuyk.com
Wed Feb 25 15:10:29 UTC 2009
Every single project I've worked with where the designer was not
familiar with Drupal has had issues like this.
I learned after the first one to tell the client outright that he would
save costs by having me eye over the designs his designer put out, and
suggest corrections and changes as necessary. An hour of working over
the design can save the client many hours of writing form
customizations. For each feature, I let them know approximately how much
it would cost for them to do it 'their way', and how much it would cost
them to do it 'my way'. Usually, they are more than happy to save the hours.
The worst was a client who spent several thousand dollars on a
'useability' consultant to assist the design team when designing the
site. I ended up having to modify just about every stock portion of
Drupal visible to the end user, including a bunch of admin pages for
various modules that his editors would be using... All in all, the
modifications I made to things stock Drupal forms & workflow more than
doubled the cost of his project for, in my opinion, a very small
increase in usability.
Brian
Ashraf Amayreh wrote:
> 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
> <mailto: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
> <http://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 <http://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 <http://www.drupal.com.au>
> > 03 5968 1541
> > ==============
> >
> > _______________________________________________
> > consulting mailing list
> > consulting at drupal.org <mailto: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 <mailto:consulting at drupal.org>
> http://lists.drupal.org/mailman/listinfo/consulting
>
>
>
>
> --
> Ashraf Amayreh
> http://aamayreh.org
> ------------------------------------------------------------------------
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
More information about the consulting
mailing list