Does Software Project Estimation Have to Be Difficult?

One thing that I hear from project managers on a regular basis is that estimating a software project is a really tough thing to do. I have to tell you that it doesn’t have to be that way. Here are some reasons why project estimation can be easier than you think.

• Many people think they have to hit the schedule and the budget right on the dot. That is not the case. Estimates should be used for planning purposes with a certain amount of buffer built in. There is uncertainty in everything we do and a good estimation approach takes that into account.

• Many project managers will spend days or even weeks making educated guesses about how many hours each person is going to work on each task before they know the big picture. This shouldn’t be where they begin. They should start with a macro level estimate on the whole project, using historical data and empirically-based models before doing all of that detailed planning.  This can save a lot of time and money on the planning phase and design and development re-work.

• Many project managers rely on home-grown estimation spread sheets. Instead of trying to build an estimation model yourself, consider a commercial model that is time-proven and tested and that has an industry database so the research is being done for you.

• Try to find an estimation tool that doesn’t require an estimating expert or a mathematician to run. (I’m biased but SLIM-Estimate is a great place to start.)

• There is a common misconception that you need to capture a lot of different metrics in order to be successful at estimating. This is simply not true. Larry Putnam, Sr. co-authored a book called Five Core Metrics, which focuses on the measures that matter the most. These are: duration, effort, size, productivity, and reliability. He proves that you don’t need hundreds of data points to get credible estimates.

• Sizing is usually the biggest challenge. It’s great if you can count the units of work, but if you can’t, then use some ballpark sizing measures like big, small, and medium, or some high level measures like Business Requirements or User Stories. Then use an estimation tool that allows you to take into account the uncertainty. Run an initial estimate and then run the model again asking for the 90% chance. Now you have a conservative estimate to bank on and it only took a few minutes.

• Use the same estimation tool or process to sanity-check your estimate against industry trends. This way you can negotiate the cost and schedule of your project and feel confident that your estimate is realistic.

• Don’t commit to a number. Instead, commit to a chance of hitting that number, and a chance of hitting another number. Take some of the pressure off. Remember it’s an estimate for planning purposes. Don’t sell it as a guarantee.

The bottom line is if you use the right tools and processes and if you present the numbers the right way, software estimation does not have to be difficult.