[consulting] Estimation-Blowout case-studies wanted

Mon Mar 2 01:29:45 UTC 2009

Hi Alex,

I'll be at Drupalcon, and would be happy to go though the estimating
template and how we use it during a BoF, as well as discuss estimating and
related topics. Accurate estimating is definately an art form, but there are
many ways to improve it - in our experience even with a (mostly) agile
project methodology high quality estimates have been critical to setting
client expectations from the very first conversation onwards (and we
re-estimate throughout the project).

Thanks!
- Owen

On Sun, Mar 1, 2009 at 5:07 PM, Alex Urevick-Ackelsberg <Alex at zivtech.com>wrote:

> 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
> >
> >
> _______________________________________________
> 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/20090301/ffe717cd/attachment-0001.htm 