Drupalcon London - Drupal Estimation Techniques BoF

Here are the notes from the Drupal Estimation Techniques discussion I organized at Drupalcon London. Feel free to share :)

I want to thank Drupalcon organizers for making this possible -- we really appreciate all the effort that went into the creation of this conference and its BoFs. Second, thanks to Jakob Persson (Co-founder & Web Strategist at NodeOne) for co-chairing and to everyone who came to share their ideas and experiences with the group. We all had a lot to say, hopefully some presentations for Denver will come out of this!

We asked a series of questions at the beginning of the BoF hoping to spark conversation. The goal of this BoF was to understand the challenges the participants face, and how they addressed them (successfully and unsuccessfully). We decided to hold this BoF because the Drupalcon sessions didn't specifically address these issues this year, and Jakob and I are both very interested in maintaining conversation about them.

I hope the responses/ideas/experiences we generated below will be useful to you!

Best,
Shannon Vettes
Bluespark Labs Project Manager

ps: notes were taken quickly & during discussion so, they risk being incomplete! Please feel free to comment below so we can add more info here!

Q: What makes Drupal estimation different from non-framework development?

Top responses were:
=> Research: we need to see what's out there already to know what we can exploit
=> Testing: we probably need to test out things to verify functionality & expectations
=> Dependencies: There may be 3rd party code we need to interface with or other modules we're dependent on
=> Security updates & maintenance: there is more involved in maintaining your code, especially with custom work or new Drupal versions

Interesting point:
Most of the group aren't including these things in estimations, proposals, etc. Most are putting numbers on quotes that represent the time it takes to *do* the work w/o including the prep work or maintenance. But is this the best approach? The things listed above are very valuable to a client, who is buying a product, but they're also buying your expertise!

Q: What kind of projects are people estimating right now?

Top responses were:
=> Fixed bid: this seemed to be the most common response. The client provides a list of requirements, the company works to create them for a specified budget.
=> Time/Materials: only 2 or 3 shops at our BoF were doing this kind of work with no fixed scope & budget.

Other questions:
I wonder if this is a European trend? It seems to me (just a gut feeling, not based on any real data), that a lot of shops in the US are moving away from fixed bids. Anyone care to weigh in?

Q: What should we consider when estimating? What "factors" affect the numbers?

Top responses were:
=> Developer(s) experience level(s) (Consider experience with Drupal itself, the version in question and with the feature being estimated)
=> The context (ie: which Drupal version? Are all necessary elements ported to that version yet? Is there custom work? Is there a migration or integration points?)
=> The client (Is this a client who is easy-going and manageable or someone who will constantly challenge scope & ask for more work? Note: if the latter, more PM time should be added for change management)
=> The constraints (do they need this done quickly? Is that going to jeopardize other projects -- maybe a rush fee should be applied if that is the case.)

Q: What techniques work well for Drupal development estimation?

Top responses:
=> building in 10% into the budget for research & architecture into your quotes
=> letting the client know how Drupal works and that there may be some dependencies (see list above) and level expectations from the start
=> planning poker / delphi method ---> there's an online tool listed below that's useful (see resources below)
=> spreadsheet to estimate that takes into account bottom-up estimation techniques with an average of high-med-low guesses to get a more accurate guess
=> padding estimations considering the developer's past experience (ie: developer says 3hrs, but I know he's slow, so I'll plan on 5)
=> always orienting the estimation toward the option that favors the business need to trim scope & the estimation time according to what is most valuable to the client!
=> collecting previous estimation data & benchmarking your results for usage on other projects

Q: What techniques don't work with regard to estimation & proposal preparation?

Q: Disaster stories you learned from (what blew up in your face)? What are the lessons learned?

=> Working with inexperienced Drupal developers
-- LL: know who your developers are and their skill level before estimating & agreeing to a project

=> Accepting rescue missions without proper investigation:
-- code/site audits are crucial to being able to evaluate the necessary effort
-- not having a clear idea of scope when starting these missions will bring imminent failure
-- level expectations about changes & issues that may crop up "this is not my code, ergo, it's unpredictable!"
-- LL: really *know* your project. These kinds of projects are great candidates for waterfall methodology or for a retainer allowing you to do fixes over time and better manage budget, scope & expectations.

Shannon Vettes -
Project Manager. Operations. -
When she joined Bluespark Labs as a Project Manager, Shannon brought more than 10 years of varied IT experience in roles that included user experience design, information architecture, and project management.

5 Comments

Wow, very nice write up and i have learned about some very interesting points above. My work involves providing estimates on a day to day basis on development tasks involving mostly Drupal where i quote on jobs. The Tips & Tricks section here will certainly help make things easier.
Thanks

Shannon Vettes -
Tue, Aug 30 2011 at 4:04am

Thanks Jay! Glad you liked it! Maybe you can share w/ us your own tips/tricks sometime & we can keep adding to the list :)
-Shan