Software Estimation BlogInformation on Cost Estimation & Software Estimating

It helps with the metaphor

If you recall, last week I talked about the first step that anyone doing anything with software estimation needs to do – that is to establish the ‘what’ and the ‘why’. And I said that these two aspects are your cornerstone, the start of your foundation. Now it’s time to move to step two and lay the rest of that foundation. Don’t worry, I’m not going to continue with home construction metaphor much longer, it’s just that for this instance it’s fitting.

So, now that we know what we want to estimate, and why we want to estimate it, it’s to start getting to the ‘how’. To do so, we’re going to take that simple question and break it down into three main areas.

The first of these three areas is the technical baseline, which as the name suggests, is where everything is measured from. To make your baseline perform best, and the rest of your estimation follows suit, it’s best to follow the kitchen sink approach. Working with software? Incorporate how each piece of the software interacts with each other piece and how that software would integrate with the outside world. Toss in every binary build, every delivery time. When every step is due, and how much they’re supposed to cost.

Then, move to the second part of the ‘how’ – establish your ground rules. Special considerations, technology involved, everything have to be done in blue? Yeah, those go here.

Which brings us to the last part, assumptions. Go ahead and forget the cliché your mother used to repeat, you know that that so cleverly starts “Every time you assume, you…” Because now I want you to do the opposite. Kinda. Here’s where you’ll make a list of things you’ll need to complete the project, but that you don’t already have. So, you’re not making assumptions about performance (as your mother so warned)but rather assumptions about supplies (which I’m telling you is cool.)

It's the one in the lower corner

There’s a running gag between myself and a few of my friends and associates – if possible, how much information would you cede over to software estimation? Theoretically, software that was smart enough, and fed enough information could serve as a nice expert opinion, specifically when involved in an argument with a significant other. After all, it’s hard to refute a computer that gives a quantifiable reason against turning the television away from the game, or not wearing that specific tie. Granted, the battle between spouse and computer would be settled quickly (with the edge going to the spouse), but the comic examples do serve an actual purpose – the first rule of software estimation is you need to know what you’re estimating.

As good as software estimation is (and it can be really good), you need to know what you wish to estimate before you start feeding in data. To that end, it helps to establish an estimate scope, purpose, and starting point for your estimate.

The first part, the purpose, is perhaps the most important. What do you wish your estimation to do? The more specific you are in your purpose, the better prepared you’ll be when you move through the process and more useful the estimate will be. Scope’s pretty important. That’s the general goal of your estimate – will this estimate be the completion of your project, or will the estimate impact how your project proceeds? And finally, before you even begin your estimate, you need to establish your base points of contact. This is the general areas where you’ll be culling your data from.

It takes a while to really get the hang of these three areas, but they’re important for creating the foundation of a solid estimate. Once you’ve got them down, your estimates can work better for you, and maybe, just maybe, you can software estimation to settle household disputes and convince the significant other that watching the game is the best decision possible.