Software Estimation BlogInformation on Cost Estimation & Software Estimating

Better hope it's pointed exactly right

There’s a popular cliché amongst rocket scientists “a launch that is off by one degree will miss the moon by miles.” Okay, so maybe the authenticity of that phrase is leaves a lot to be desired, but the spirit of the statement – the accuracy of a rocket is only as sound as the accuracy of the initial trajectory – makes a lot of sense. Even a target as big as the moon can easily be missed if the foundation is shoddy.

How does this relate to software estimation? Easy, your estimate is built on data collection, and your initial data collection creates your foundation. As you collect your data, the results compile into the launch structure that will put your estimation rocket on the correct path.

Cheesy metaphors aside, there are some best practice tips for ensuring that your data collection is accurate and you don’t miss the moon.

Customized Worksheets are a must. A standard worksheet is good, as it allows for data to be collected in a uniform fashion. A custom worksheet allows for a more complete and tailored set of data to be collected. Doing so allows you to flesh out the project more so before hand.

Break the worksheet down into components of the project. If you’re working on a large piece of software, this means a separate worksheet for each CSCI. For other project estimates, say for manufacturing, you’ll need to make worksheets for each step of the fabrication process.

Make sure your collected data jives. Double check your numbers. Make sure the vision of your estimate is on par with what the customer envisioned. Check to make sure that any necessary resources (contractors, developers, etc) are available.

Once you have these issues sorted out, you should have a nice foundation for your project. You have the forest and you can move to sketching out the trees.

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.