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.<br>
<br>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. <br><br clear="all">--<br>Alex Urevick-Ackelsberg<br>
ZivTech, LLC<br><a href="http://zivtech.com">http://zivtech.com</a><br><a href="mailto:alex@zivtech.com">alex@zivtech.com</a><br>office: (267) 940-7737<br>cell: (215) 866-8956<br>skype: zivtech<br>aim: zivtech<br>
<br><br><div class="gmail_quote">On Sun, Mar 1, 2009 at 8:07 PM, Alex Urevick-Ackelsberg <span dir="ltr"><<a href="mailto:Alex@zivtech.com">Alex@zivtech.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Wow! Thank you so much for this Henry!<br>
<br>
Would you be willing to do a BoF at DrupalCon (assuming you'll be<br>
there) to go over this?<br>
<br>
Also- what would be the best way for us to contribute to this effort?<br>
This something we struggle with as well, and your calculations seem<br>
pretty spot on for me.<br>
<br>
Thanks again, this really is a huge help!<br>
<br>
--<br>
<font color="#888888">Alex Urevick-Ackelsberg<br>
ZivTech, LLC<br>
<a href="http://zivtech.com" target="_blank">http://zivtech.com</a><br>
<a href="mailto:alex@zivtech.com">alex@zivtech.com</a><br>
office: (267) 940-7737<br>
cell: (215) 866-8956<br>
skype: zivtech<br>
aim: zivtech<br>
</font><div><div></div><div class="Wj3C7c"><br>
<br>
<br>
On Sun, Mar 1, 2009 at 4:53 PM, Henry Poole <<a href="mailto:poole@civicactions.com">poole@civicactions.com</a>> wrote:<br>
> A number of folks at CivicActions have been watching this conversation with<br>
> great interest. We've had similar challenges over the last couple of years,<br>
> and several months ago decided to create a tool to assist with estimating.<br>
> We ended up with a OpenOffice spreadsheet called<br>
> ca_template_estimating_worksheet. I posted it to the list here last week,<br>
> but it was rejected due to it's size. If you would like to check it out,<br>
> please find it posted at our website:<br>
> <a href="http://civicactions.com/estimating-worksheet" target="_blank">http://civicactions.com/estimating-worksheet</a><br>
><br>
> Owen Barton, a partner at CivicActions and our Engineering Group Manager is<br>
> the maintainer of the tool. Last Friday he released version 1.1 and we<br>
> thought it might be of use to other Drupal consultants so we're publicly<br>
> releasing it for use under the Creative Commons Attribution Share Alike 3.0<br>
> license. You are free to use under the terms of this license. In the spirit<br>
> of the community in which we work, we would also appreciate that you share<br>
> any improvements with the rest of the community (back on this list would be<br>
> great).<br>
><br>
> The file (posted at <a href="http://civicactions.com/estimating-worksheet" target="_blank">http://civicactions.com/estimating-worksheet</a>) contains<br>
> five worksheets:<br>
><br>
> 1. Intro contains important notes on the tool.<br>
> 2. Line-Item Estimate is for estimates of individual work items based on the<br>
> provided RFP/documentation. The totals from this are used in the other<br>
> sheets.<br>
> 3. RFP Estimate calculates final hour and cost estimates and includes all<br>
> functionality that is reasonable to implement from the RFP or documentation<br>
> provided.<br>
> 4. Recommended Estimate calculates final hour and cost estimates and makes<br>
> allowances to avoid major custom work and focus on high-value out-of-the-box<br>
> functionality. This is generally only used when the estimate for the RFP<br>
> exceeds the available budget. Please note that this sheet is disabled by<br>
> default - to enable use the switch on the sheet.<br>
> 5. Client Summary is a friendly summary of the information we normally<br>
> include with our proposals. The values from this sheet can be copy and<br>
> pasted from this sheet into a new spreadsheet file or into the proposal<br>
> document.<br>
><br>
> Overview of Features:<br>
> ● Takes into account the certainty of the line item estimates (allowing for<br>
> vague RFPs, technical risks and areas that need research) to produce low and<br>
> high estimates, in addition to the 'normal' estimate that give an idea of<br>
> the expected range of variability.<br>
> ● Allows us to recommend reduced, simplified or alternative functionality<br>
> than what is requested (especially useful for clients with dreams bigger<br>
> than their pockets).<br>
> ● Calculates cost estimates based on actual role rates, rather than blended<br>
> rates.<br>
><br>
> Types of estimates rolled into the total:<br>
> ● Line-item estimates are the traditional estimates that we have done.<br>
> Typically we would only do engineering line-item estimates at the proposal<br>
> stage - the other roles would be valuable however if we re-estimate post-IA<br>
> or post-strategy, where we have more information and need specific<br>
> information for budgeting and scheduling.<br>
> ● Duration estimates account for the fact that it takes a certain amount of<br>
> our time just to keep a project rolling.<br>
> ● Proportional estimates allows us to base an estimate on a proportion of<br>
> some other estimate, which is a useful way to estimate some of the QA and PM<br>
> work.<br>
> ● Manual estimates are a way to include a single aggregate estimate into the<br>
> totals - for example creative estimates sometimes use this.<br>
><br>
> Not directly related to the spreadsheet, but other things to bear in mind<br>
> when estimating:<br>
><br>
> ● Things always take longer than you think, be generous (but not silly!)<br>
> with your estimates. Getting this balance right is a fine art and takes time<br>
> to learn.<br>
> ● Make sure you think about, and state each assumption you make when<br>
> estimating.<br>
> ● Write any assumptions and notes in client friendly language - these notes<br>
> will often be included in the proposal.<br>
> ● If any RFP line item is looking too big, or actually is several things<br>
> rolled into one, split the line item into multiple work items.<br>
> ● Estimate each area of work (engineering, theming, configuration,<br>
> communication) separately, and make sure you include adequate time for<br>
> communication, both with the client to clarify the requirements, and also<br>
> internal communication between team members.<br>
> ● If the work includes new, untested code, e.g., writing a new module or<br>
> including a (non-standard) contrib module, add time in the estimate for unit<br>
> testing which could include the writing of simpletests and flag this to the<br>
> QA team as a place that will require additional QA.<br>
> ● You personally might be able to get a task done very fast, but others may<br>
> end up doing that work and may be slower - make sure your estimates allow<br>
> for this.<br>
> ● Vary the amount or research with the size of the line item - if you are<br>
> not sure about something, but it would only take 5 hours to build from<br>
> scratch, just put 5 hours - if you need to integrate with some 3rd party<br>
> system, and it might be a weeks work make sure that you understand the<br>
> requirements very well (ask the client questions to clarify where needed)<br>
> and research things fully.<br>
> ● Never (ever!) estimate 'to' a budget - your estimates for each line item<br>
> should disregard any information we have about the available budget. Instead<br>
> think purely in terms of how long it will take to get the job done. If the<br>
> hours exceed the budget we will discuss a reduced feature set (at least<br>
> initially) with the client. If the overall costs look like they will<br>
> massively exceed the budget then ask the client to prioritize first and<br>
> estimate a subset of the items.<br>
><br>
> We maintain a list of suggested improvements for the tool, and are happy to<br>
> release future versions to anyone interested.<br>
><br>
> Cheers.<br>
>><br>
>> On Fri, Feb 20, 2009 at 6:34 PM, John Saward <<a href="mailto:john@also.com.au">john@also.com.au</a>> wrote:<br>
>>><br>
>>> I'm currently very interested in people's experiences with<br>
>>> 'estimation-blowout'.<br>
>>><br>
>>> In my experience, and discussions with Project Managers, Developers<br>
>>> and Clients I find that quite often the number of hours to actually<br>
>>> complete a Drupal project or task, is considerably more than the<br>
>>> number of hours estimated beforehand. This creates problems<br>
>>> (budgetary and otherwise) and stress and even resentments to all<br>
>>> involved whether the work is being performed on a<br>
>>> fixed-price-quotation, estimated or actual-hours basis.<br>
>>><br>
>>> I note the comment from the team who recently updated <a href="http://drupal.org" target="_blank">drupal.org</a> from<br>
>>> 5 to 6, "So while we crafted a fine plan for the upgrade, it took a<br>
>>> few more hours then originally planned." <a href="http://drupal.org/node/376454" target="_blank">http://drupal.org/node/376454</a>.<br>
>>><br>
>>> I'm understanding that the preparation and planning for the upgrade<br>
>>> was a mammoth task, when I read the report of the upgrade sprint, at<br>
>>> <a href="http://drupal.org/node/366562" target="_blank">http://drupal.org/node/366562</a>. Those at the sprint, and other<br>
>>> contributors, worked hard doing all that was humanly possible to<br>
>>> prepare and plan for the upgrade so that least downtime as possible<br>
>>> would be entailed. One outcome of the sprint would have been an<br>
>>> estimation of how many hours would be required for the final push,<br>
>>> the working time that would necessarily entail site downtime. And now<br>
>>> I see that the actual upgrade was more intricate and time-consuming<br>
>>> than that prediction.<br>
>>><br>
>>> My thinking is that these guys are some of the most experienced<br>
>>> Drupal engineers around; and most familiar with the entire <a href="http://drupal.org" target="_blank">drupal.org</a><br>
>>> infrastructure. If they are unable to predict the hours beforehand,<br>
>>> even after going into 'fine planning' .... well.... who could have?<br>
>>><br>
>>> What does it take to accurately estimate a significant Drupal<br>
>>> project? Experience obviously, but it seems that is not always enough<br>
>>> in itself. Are there just always too many unknowns, too many<br>
>>> variables, too many 'what ifs' to be overlooked, in any<br>
>>> more-than-basic Drupal work? Is accurate estimation for anything<br>
>>> other than highly-repetitive tasks.... verging on the impossible?<br>
>>><br>
>>> I'm interested in hearing views and experiences about this.<br>
>>><br>
>>> And also I'm interested to know if the upgrade team has a record of<br>
>>> hours predicted against actual hours taken, for the upgrade.<br>
>>><br>
>>> John<br>
>>><br>
>>> ==============<br>
>>> John Saward<br>
>>> <a href="http://www.drupal.com.au" target="_blank">www.drupal.com.au</a><br>
>>> 03 5968 1541<br>
>>> ==============<br>
>>><br>
>>> _______________________________________________<br>
>>> consulting mailing list<br>
>>> <a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br>
>>> <a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
>><br>
>><br>
><br>
><br>
> --<br>
> Henry Poole, Partner, CivicActions LLC<br>
> Co-Founder, Virtual Artists<br>
> Board Member, Free Software Foundation<br>
> Blog: <a href="http://www.civicactions.com/blog/henripoole/" target="_blank">http://www.civicactions.com/blog/henripoole/</a><br>
><br>
> Cell: +1 510 684 3180<br>
><br>
> **************************************************************<br>
><br>
> Henry: Now in Berkeley<br>
><br>
> **************************************************************<br>
><br>
> _______________________________________________<br>
> consulting mailing list<br>
> <a href="mailto:consulting@drupal.org">consulting@drupal.org</a><br>
> <a href="http://lists.drupal.org/mailman/listinfo/consulting" target="_blank">http://lists.drupal.org/mailman/listinfo/consulting</a><br>
><br>
><br>
</div></div></blockquote></div><br>