[consulting] Estimation-Blowout case-studies wanted

Mon Mar 2 01:43:55 UTC 2009

I guess I forgot to state the overall goal of the prototype I presented
above with regards to time estimation. By conveying visual features to the
client you eliminate the possibility of miscommunication and missing
requirements (the prototype essentially freezes client requirements in a
visual way). You also restrict a designer to a design that is Drupal
friendly (he needs to stick to the architecture/prototype).

This will ultimately help in creating a more accurate project estimate,
would clarify the site flow, and prevent the case where a design handed down
from the client is a total Drupal design nightmare. Or at least that's the
theory :)

-- 
Ashraf Amayreh
http://aamayreh.org

On Mon, Mar 2, 2009 at 3:38 AM, Alex Urevick-Ackelsberg <Alex at zivtech.com>wrote:

> Here's a question: are developers able to share their rates amongst each
> other? I'm not a lawyer, so don't take my word for it, but I'd be careful
> about posting your rates on the Consultant list, as someone might consider
> it an attempt at "price fixing"/collusion.
>
> I think it's a gray area, and I don't know if anyone out there really cares
> about whether Drupal shops publicly share their rates, but I thought I'd put
> that out there.
>
> --
> 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 8: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/20090302/4a94907a/attachment-0001.htm 