Estimates, Expectations, and Evolution
“With Drupal features are cheap and details expensive” — Vesa Palmu, CEO of Wunderkraut
We’ve all been there with a client. Back when the project kicked off (days, weeks, months, or even years ago) there was some type of mutual understanding of the time, timeline, and cost of their project. Unfortunately, things happened along the way! Conversations sparked new ideas. Assumptions turned out to be incorrect. Life happened and someone left the team. Whatever the reason(s), the scope of the project today is no way matches what was discussed at the very beginning of the relationship.
How did we get here?
Perhaps a better question: how could we NOT get here?
While it seems like a cop-out to say that there it’s impossible to accurately estimate a Drupal project, the reality is that features are cheap and details are expensive. Want a fully functional, world-class eCommerce solution for Drupal? You can literally download and enable Drupal Commerce in minutes! Want to make a super customized and flexible coupon system and recommendation engine? You could sink 100 (or 1000) hours into that one feature alone. And no matter how much time is spent in an RFP, it will almost all get thrown out that window once conversations begin and new ideas start to form (and that’s a good thing!).
Perhaps a better approach is to go into a project setting the expectations that estimates are not fixed numbers carved in stone, but evolve as they go from mere ideas (with high variability of cost and complexity) to increasingly more refined values.
That sounds all nice and theoretical, but how does one go about this? Over the years as a technical project architect, I’ve adapted a process by Seth Brown (see The Art of Estimations) to include a time component into the mix. One can start off with coarse estimates during the RFP and pre-sale process and then save snapshots of the estimations over time as things evolve and move through discovery, definition, designs, etc.
This talk will involve a mix of theory and actual case studies where this technique was used to either increase budgets when/where appropriate and/or defend removing or eliminating functionality that simply could not fit within the original budget. Used properly, all members of the team can contribute towards the evolution of this document and stay on the same page with the client at all times during the evolution of the project.
Rick graduated from MIT with a BS and PhD in Materials Science and Engineering (where he also coached track and field) before joining the Drupal community in 2008. If you ever want to know about the quantum electrodynamic interactions of carbon nanotube systems, he’s your guy! In addition to his considerable talent in all things technical, his specific expertise is in understanding the big picture, and helping identify challenges and provide solutions long before a problem has a chance to develop. His analogous nickname here is the Swiss Army Knife. Rick’s a software developer, media technologist and project manager, but please don’t ask him to design anything. We all have our limits. Rick loves to learn, share, and connect with like-minded people, and he lives in the greater Denver area with his wife Emily and their dog Linus.