[consulting] Estimation-Blowout case-studies wanted

Mon Mar 2 01:07:46 UTC 2009

Wow! Thank you so much for this Henry!

Would you be willing to do a BoF at DrupalCon (assuming you'll be
there) to go over this?

Also- what would be the best way for us to contribute to this effort?
This something we struggle with as well, and your calculations seem
pretty spot on for me.

Thanks again, this really is a huge help!

--
Alex Urevick-Ackelsberg
ZivTech, LLC
http://zivtech.com
alex at zivtech.com
office: (267) 940-7737
cell: (215) 866-8956
skype: zivtech
aim: zivtech

On Sun, Mar 1, 2009 at 4:53 PM, Henry Poole <poole at civicactions.com> wrote:
> 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
>
> **************************************************************
>
> _______________________________________________
> consulting mailing list
> consulting at drupal.org
> http://lists.drupal.org/mailman/listinfo/consulting
>
>