The Unpredictability of Project Estimation

One of the hardest jobs in the software business is estimating new projects.  It takes a substantial mix of experience, brute force effort, and a little luck.  Estimation really is an art that refuses to be mastered, taking constant re-learning in order to improve over time.  I'm by no means perfect at it (I doubt anyone really is), but I've certainly learned a lot about it over the years.  Here, I'll share some of my experiences.

Mike Morris, EVP, Business Development and Marketing
Posted

One of the hardest jobs in the software business is estimating new projects.  It takes a substantial mix of experience, brute force effort, and a little luck.  Estimation really is an art that refuses to be mastered, taking constant re-learning in order to improve over time.  I'm by no means perfect at it (I doubt anyone really is), but I've certainly learned a lot about it over the years.  Here, I'll share some of my experiences.

First, I try to understand what we're being asked to build (duh).  What are all the moving parts?  What are the primary architectural components?  What specific features are being requested?  How "big" is this thing?  Once these questions can be answered, I collect them in a list.  Spreadsheets work great for this, but there are certainly tools out there that can assist.  Everybody that's ever had to do large-scale estimation in a software company probably has their own spreadsheet they like to use for this part of the process.  Mine includes grouped tasks, risk factors, columns for different team resources, automatic rounding, etc.  Using rules of thumb or point scoring strategies for certain types of tasks works well too.  Back in March I saw Jakob Persson's session at Drupalcon which had some good tips.  Truth is, there is no perfect way for sizing up a project from the bottom up.  However you can, break the problem down into as many distinct parts as you feel comfortable putting hours on.  For the numbers themselves, get inputs from the people that are closest to actually doing the work.  Get developer inputs on technical tasks, get designer inputs for the creative bits.  Beware things like integrations with unqualified or unknown systems.  Those type of tasks generally carry pretty high risk factors and have a good chance of going way off track.

Next, I try some top down exercises.  How similar is this to other projects that we have hard performance numbers for?  What is my gut telling me about the complexities here?  How hard is this project going to be to manage?  There has been a hot topic around the office lately about the exponential complexities that come into play as projects get bigger and bigger.  Extrapolating LOE estimates out linearly definitely does not work.  You have to think about who's involved.  How many levels of stakeholders?  Are other vendors or consultants involved?  How many people need convincing of our technical strategy?  How may people do you have to get design approval from?  Multiplying lines of communication add up to more and more effort needed for project management, including expectation setting, artifact sign-offs, technical education, user training, documentation, and just general hand-holding.  Suffice it to say, anticipating all these factors is not easy, and I certainly don't claim  perfection in this area - not even close.

Ideally, the bottom up approach and the top down approach meet somewhere in the middle, preferably close to a number that matches a "gut feel" I already had bouncing around in my head somewhere.  It's never perfect, that's for sure.  And then there is the ever-present acknowledgment that you just don't (and can't) know everything.  No matter what the project owners may tell you, there is something they forgot or are mischaracterizing as simpler than it really is.  It's not even malicious, it's just a natural confirmation bias that happens when someone is about to drop a lot of money on a software system.

 

Mike Morris

Mike Morris

EVP, Business Development and Marketing