Software Estimation BlogInformation on Cost Estimation & Software Estimating

Professor Charlie Eppes, solving crime no doubt

For a few years, CBS has been running a television show called Numb3rs. The premise is the standard take off on the brothers-solving-mysteries cliché that has been around since at least the Hardy Boys. Granted, Numbers has a couple of differences – the boys are older and employed. Don Eppes, the older of the pair, runs a team of FBI agents based in Los Angeles – a fair step above the amateur sleuthing of the Hardy boys. Charlie Eppes, the younger brother, is a math genius and a professor at the fictional “Cal Sci”.

Each week, Don and his street-savvy FBI team encounter a problem, usually a time sensitive one, which is just too tough to figure out through traditional police work. Like clockwork, Professor Charlie Eppes and his team of socially-awkward yet brilliant mathematicians are able to use some form of advanced mathematics to accomplish a whole list of things from predicting where a kidnapping will happen next to the contents of boxes.

And while a great deal of that is Hollywood magic, taking lab theory and shoehorning it into unrealistic time periods with even less realistic amounts of data, there is one part of the show that I always admire. At some point, the young Professor Eppes must explain a complex, doctoral-level mathematical system in terms that team of FBI agents can understand. This happens every single episode with such predictability that the character in the show have started to expect it, even making jokes and attempting to give their own explanations.

Charlie’s explanations are clearly a plot device to convince the audience that his brilliant mathematical insights aren’t simply a weekly deus ex machine. However, just as Charlie has to explain how his math models the real world, the use of software estimation can often seem just as improbable. True, you can sit back and say “Well, the program relies on parametric modeling of our current situation,” but that look is far more likely to generate blank stares than anything else.

To that end, I’m currently working on a good lay definition of parametric modeling and a few handy examples. Stay tuned for those.

I’ve written before on the predictive nature of estimation software. Using software estimation products as project management software can help show you aspects of your project which you haven’t accounted for, particularly things like risk.

You can't take that leap back

However, software estimation products can do more than highlight areas which you haven’t seen, they can also peer around the corner and show that which you haven’t done yet. Through the software’s rather developed, and mathematically sound, understanding of your project, that understanding can be leveraged towards making theoretical changes.

Think about it this way, software estimation project management software allows you, the project manager to play the “What if…” game. What if I doubled my workforce? What if I reduced everyone’s workload by 10%? What if deadlines were all extended by 10%? What if I assigned every part of the project to just one person?

The questions can seem trivial, even comical, however they point to a very interesting application for such software – they ability to control, limit, and even potentially mitigate risk. The questions I just posed all center around one significant area – the sharing of a workload to make a project easier on employees.

How does making project members work easier help to control risk? Well, for one thing, for projects which are heavily dependent on multiple deadlines all being satisfied in a particular order, specifically where one group is waiting on the work of another, each deadline represents a potential point of failure. By making deadlines easier to achieve, the risk of failure is thus avoided.

Of course, deadlines represent just one area of risk. I like to use them as an example because hard deadlines seem to exist in every area from newspapers to software companies to automobile manufactures. The flexibility of project management software which employees these estimation techniques means that project managers can juggle all sorts of variables in a project finding the optimal mix. In the end, such juggling helps to control the risk of uncertainty.

This is a blog post by none-other than Dan Galorath, the Chief Architect for the SEER-SEM software. He talks about the difference between the types of project management software and sheds some light on not only the various differences that exist, but also where the two different types of software can be useful.

One of the desired end results of any project is producing a seamless product. Said project could be a company manual, a piece of software, or an automobile, in the end the product should be perceived a single, cohesive entity. The entirety of your project should feel as if it were birthed whole and flawless, crafted with one brush in a single masterstroke.

Reality, however, has you painting a much different picture. Large projects take large groups of people. Large groups of people are broken down into several smaller teams. Even teams themselves can be further divided. Responsibilities trickle down through the ranks and deadlines are attached. Pieces of the project start to rely on each other as deadlines overlap and dependencies are built. A holdup in one team can literally delay an entire project. The larger the project, the more your single masterstroke starts to look a lot more like Chaos.

In an attempt to make things easier, many project managers turn towards some sort of project management software. The logic is fairly simple – obtain a single piece of software which can keep track of all the pieces of a project simultaneously. The ideal piece of software is busy monitoring deadlines and progress while doling out further responsibilities, all the while ensuring the desired end result.

Active Versus Passive Project Management

Problems arise when we think that all project management systems are created equal. The fact is that software systems can be broken down into two primary categories – passive and active. Passive systems reflect exactly what you put into them, in essence telling you what you already know, albeit in an organized and open manner. Active project management systems, often called estimation software, are able to make projections based on various algorithms and complex models. The difference between the two can be rather severe. If passive project management software reflects what you know, like a mirror, than active project management software reflects what you want to know, like a magic mirror.

Both types of software start at the same point, with the users supplying what is currently known. Both types then organize what is known and keep track of it. For large projects this typically takes into account a host of items such as individual employees, individual pieces of a project, and time allotments. Whether using passive or active project management software, the collection of this information creates an important foundation for any project.

The difference between active and passive software comes into play after this foundation is laid. With passive software, the user builds on that foundation, establishing milestones and to-do list items, creating the framework for the entire project based on the manager’s own understanding of his or her employees and their individual skill sets. The duty of then updating that software falls on either the project manager or users further down the pipeline. The software might take some proactive steps, such as emailing those with looming deadlines, but for the most part such project management software relied heavily on users to keep it updated.

With estimation software, however, the program itself starts to bear a fair amount of the management burden. Prime examples of good estimation software are able to calculate project requirements not just on the known quantities such as those involved, but also on the harder to measure areas like project complexity, available technologies, and the immeasurable factor: uncertainty. Active project management software thus builds a more complete idea of a project. From that idea, the software is able to extrapolate a mathematical understanding of a project. This grounding in math creates measurable and comparative results which are more easily justified than obtuse human guesswork.

The active aspect of this type of project management software comes from what the program can tell users about the future. Because of the amount of data implemented as a project’s foundation in these management tools, solid software estimation programs will account for time, effort, quality, and risk. From that, theoretical changes can be made within the software, reflecting the results without having to actually enact them. This grants project managers the ability to play with trial and error solutions without risking real life resources.

The need for project management software obviously differs based on the project at hand. For some projects, particularly those which have repeating and regular deadlines, a passive project manager might be ideal. For projects with multiple parts which are leading towards a single cohesive product, a more active piece of project management software might be in order. In such instances, much will obviously be gained from understanding the exact situation at hand. The determining factor is whether you want your resources checking in with a mirror which reflects what’s currently known, or if you want a mirror which can help you accomplish your goals by telling you what you don’t yet know.

There are two types of Project Managers out there, those who get estimation software, and those who think it’s a magical box which turns hard working developers into robots. Here’s a list of the most cruel and unusual questions posed by the latter.

5. Two hours of sleep is plenty, right?

4. How much will productivity increase if we institute a “2 Devs Enter, 1 Dev Leaves” policy?

3. How much does the cost for desk shackles affect our bottom line?

2. Yes, but what if we had a thousand monkeys?

1. Great, now how do we finish the project with half the people in half the time for twice the money?

So, you’ve checked over all of your initial data, and nothing seemed out of the ordinary. You’ve double checked with the client and you know exactly what they think that they want. And you’ve plugged all of that carefully measured data into your software estimation program of choice and hit the enter key.

Congratulations and welcome to the baseline!

You’re now at the moment where if nothing changes (they will) and everything goes according to plan (they won’t), this is exact estimate of cost, team-size, and time relating to your project.

It’s a sound idea to take a good look at the baseline estimate before releasing it either internally or to the client on the offhand chance that there was an actual mistake on the initial data collection. If you’ve worked on similar projects before, and you have previous baseline estimates, these can be helpful for a quick comparison.

If everything appears to be in order, then the fun begins – the collection of “What if”s that can skillfully whittle down a baseline estimate into a lean, productive, completed project that lands under-budget and ahead of time.

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.

By know you should have a pretty good idea on what project software estimation is and how it works, but I bet you’re wondering just who uses software estimation. The blanket term, software estimation, is often applied to software which is so powerful that it can be used to ease otherwise cumbersome ordeals like estimating IT projects, or taking over the world. In these circumstances, software estimation helps prevents missteps that would cause a product to fall behind and thus not ship on time.

Ta-da!

But what else can project software estimation do? Could it, by chance, rock? You’re darn right it can. Both iTunes and the Zune packed a mild form of software estimation into their latest versions with the iTunes “Genius” and Zune’s “mixview”. How are these considered software estimation? We’ll, both programs take a look at the listeners current library and make recommendations based on what they already listen to. Pandora uses a similar tactic, but breaks down songs into their attributes, and then builds a radio station off of those shared attributes. Mog.com, a social network, finds friends and creates social networks based on the songs in a user’s library and how often they listen to them.

Of course, software estimation is used in a lot of other areas. Another term for software estimation is software recommendation. Basically anytime a computer recommends something for you – be it a product on Amazon.com or a website on Google, what happened in the background is some sort of software estimation.

This makes the answer to your question, well, most likely you.

Here lies the difficult question. How does software estimation actually work? Conceptually speaking its simple, in practice however, that’s where things become more difficult. I’m sure some of you have a book somewhere by a fellow named Steve McConnel. The book, Software Estimation, carries the subtitle “Demystifying the Black Art” which paints software estimation in a light that it doesn’t really deserve, addressing software estimations reputation as being complex and uncertain.

From a conceptual basis, and certainly when done right, software estimation is not complex at all. Why? Because the computer does all the heavy lifting. The human aspect of software estimation largely relies on regular data entry, supplying the software with as complete a data set as possible.
Why would you need a large data set? That reasoning is the difference between a census and a sample. A sample survey asks a set of questions from a portion of a population, and then extrapolates the results of that survey to make estimates regarding the population at large. A census survey asks a set of questions to the entire population, removing the need to extrapolate.

So, once you plug in all of the relevant information for whatever you wish to estimate, that’s when the computer goes to work, and here’s McConnel’s ‘black art’ stuff. Depending on what you wish to solve, the software estimation tool of your choosing is going to rely on any number of technologies including, but not limited to, parametric algorithms, simulation-based probability techniques, grouping, and historical conclusions. And, of course, each software estimation tool uses different combinations to perform estimations.