[consulting] Estimation-Blowout case-studies wanted

Sun Mar 1 21:53:55 UTC 2009

A number of folks at CivicActions have been watching this conversation with
great interest. We've had similar challenges over the last couple of years,
and several months ago decided to create a tool to assist with estimating.
We ended up with a OpenOffice spreadsheet called
ca_template_estimating_worksheet. I posted it to the list here last week,
but it was rejected due to it's size. If you would like to check it out,
please find it posted at our website:
http://civicactions.com/estimating-worksheet

Owen Barton, a partner at CivicActions and our Engineering Group Manager is
the maintainer of the tool. Last Friday he released version 1.1 and we
thought it might be of use to other Drupal consultants so we're publicly
releasing it for use under the Creative Commons Attribution Share Alike 3.0
license. You are free to use under the terms of this license. In the spirit
of the community in which we work, we would also appreciate that you share
any improvements with the rest of the community (back on this list would be
great).

The file (posted at http://civicactions.com/estimating-worksheet) contains
five worksheets:

1. Intro contains important notes on the tool.
2. Line-Item Estimate is for estimates of individual work items based on the
provided RFP/documentation. The totals from this are used in the other
sheets.
3. RFP Estimate calculates final hour and cost estimates and includes all
functionality that is reasonable to implement from the RFP or documentation
provided.
4. Recommended Estimate calculates final hour and cost estimates and makes
allowances to avoid major custom work and focus on high-value out-of-the-box
functionality. This is generally only used when the estimate for the RFP
exceeds the available budget. Please note that this sheet is disabled by
default - to enable use the switch on the sheet.
5. Client Summary is a friendly summary of the information we normally
include with our proposals. The values from this sheet can be copy and
pasted from this sheet into a new spreadsheet file or into the proposal
document.

Overview of Features:
● Takes into account the certainty of the line item estimates (allowing for
vague RFPs, technical risks and areas that need research) to produce low and
high estimates, in addition to the 'normal' estimate that give an idea of
the expected range of variability.
● Allows us to recommend reduced, simplified or alternative functionality
than what is requested (especially useful for clients with dreams bigger
than their pockets).
● Calculates cost estimates based on actual role rates, rather than blended
rates.

Types of estimates rolled into the total:
● Line-item estimates are the traditional estimates that we have done.
Typically we would only do engineering line-item estimates at the proposal
stage - the other roles would be valuable however if we re-estimate post-IA
or post-strategy, where we have more information and need specific
information for budgeting and scheduling.
● Duration estimates account for the fact that it takes a certain amount of
our time just to keep a project rolling.
● Proportional estimates allows us to base an estimate on a proportion of
some other estimate, which is a useful way to estimate some of the QA and PM
work.
● Manual estimates are a way to include a single aggregate estimate into the
totals - for example creative estimates sometimes use this.

Not directly related to the spreadsheet, but other things to bear in mind
when estimating:

● Things always take longer than you think, be generous (but not silly!)
with your estimates. Getting this balance right is a fine art and takes time
to learn.
● Make sure you think about, and state each assumption you make when
estimating.
● Write any assumptions and notes in client friendly language - these notes
will often be included in the proposal.
● If any RFP line item is looking too big, or actually is several things
rolled into one, split the line item into multiple work items.
● Estimate each area of work (engineering, theming, configuration,
communication) separately, and make sure you include adequate time for
communication, both with the client to clarify the requirements, and also
internal communication between team members.
● If the work includes new, untested code, e.g., writing a new module or
including a (non-standard) contrib module, add time in the estimate for unit
testing which could include the writing of simpletests and flag this to the
QA team as a place that will require additional QA.
● You personally might be able to get a task done very fast, but others may
end up doing that work and may be slower - make sure your estimates allow
for this.
● Vary the amount or research with the size of the line item - if you are
not sure about something, but it would only take 5 hours to build from
scratch, just put 5 hours - if you need to integrate with some 3rd party
system, and it might be a weeks work make sure that you understand the
requirements very well (ask the client questions to clarify where needed)
and research things fully.
● Never (ever!) estimate 'to' a budget - your estimates for each line item
should disregard any information we have about the available budget. Instead
think purely in terms of how long it will take to get the job done. If the
hours exceed the budget we will discuss a reduced feature set (at least
initially) with the client. If the overall costs look like they will
massively exceed the budget then ask the client to prioritize first and
estimate a subset of the items.

We maintain a list of suggested improvements for the tool, and are happy to
release future versions to anyone interested.

Cheers.
>
>
>
> On Fri, Feb 20, 2009 at 6:34 PM, John Saward <john at also.com.au> 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
>>
>
>
>

-- 
Henry Poole, Partner, CivicActions LLC
Co-Founder, Virtual Artists
Board Member, Free Software Foundation
Blog: http://www.civicactions.com/blog/henripoole/

Cell: +1 510 684 3180

**************************************************************

Henry: Now in Berkeley

**************************************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/consulting/attachments/20090301/ed5cab97/attachment-0001.htm 