Estimating a project can be very confusing to those who’ve never done it before.  Approached incorrectly, it’s impossible even to get started, and people who are unfamiliar with the process are hesitant to put anything on paper for fear of being wrong.  After all, how can one come up with a reasonably accurate time estimate on a medium or large project without first doing detailed requirements analysis and design?  My answer is “decomposition and experience.”

The most important part of project estimation is decomposition.  It’s impossible to estimate a project of any meaningful size without first breaking it down into smaller pieces.  Some people like to think in terms of subsystems:  user interface, data access, business logic, etc.  I find that a functional breakdown is more effective.  People also differ on the granularity of their tasks.  Some say to break it down into week-sized chunks and estimate from there, some say one to three days.  The approach I use is to break a project down into chunks that I can think about in isolation–tasks that are small enough to fit into my head.  Only then do I try to attach time estimates to the pieces.  I like to end up with chunks that take no longer than a week to complete.  That way, I can see measurable progress on a weekly basis and I can readjust the schedule if things start getting out of control.

When it comes to estimating a project, experience is very helpful.  As an e-business consultant, many of the projects to which I’m assigned are very similar.  They all require some kind of database access, user interface, server interaction, business logic, and reporting.  I’m able to draw on experience from many other projects, saying “this project is similar to the one I did last year,” and applying some rules of thumb.  Even if I have no detailed information about the client’s business process, I can infer certain requirements.  At minimum, I can make a reasonable estimate by considering the average, best, and worst cases of similar projects.

When working with a team that has never used our estimating techniques before, it’s sometimes hard to get the other developers to move ahead without more detailed requirements.  We always manage to do it, though, and they are surprised at the end of the project that we managed to come very close to the original time estimate.  If you look at the individual tasks estimates-versus-actuals, you’ll see quite a bit of variation, but the overall project comes in pretty close to right on time:  maybe a little under, maybe a little over.  This happens even when large parts of the project plan are changed:  some requirements dropped and others added.  My boss says that this is an example of “the law of large numbers,” the idea being that if you get enough things with sufficient granularity, the overs and shorts will balance each other out.  Whatever the reason, I’ve found over the years that it works.