Software Estimation BlogInformation on Cost Estimation & Software Estimating

By Robert P Hunt (Galorath Incorporated), Paul J. Solomon (Performance-Based Earned Value), and Dan Galorath (Galorath Incorporated)

Often, traditional earned value approaches do not deal sufficiently with the idiosyncrasies of software intensive programs.  However, successful management of software intensive programs can be achieved by focusing on establishing the requirements, developing a reliable baseline estimate for cost and schedule, selecting effective software metrics, applying Performance-Based Earned Value® (PBEV), and using analytic processes to project cost and schedule based on actual performance.

Introduction

The Department of Defense estimates that software now accounts for 40% of all research, development, test and evaluation (RDT&E) spending[i].  Software intensive projects that achieve their original cost and schedule projections are rare.  Many information technology projects have been declared a disaster area by commercial and government managers.  These projects have been too costly, too late, and often don’t work right.  Applying appropriate technical and management techniques can significantly improve the current situation.

Inaccurate estimates can threaten project success causing poor project implementations, shortcutting critical processes, and emergency staffing to recover schedule.   The lack of well defined project requirements and specifications may result in significant growth in cost and schedule.   Symptoms of this growth may include constantly changing project goals, frustration, customer dissatisfaction, cost overruns, missed schedules, and the failure of a project to meet its objectives.

PMI published an analysis of several government defense and intelligence agency large-scale acquisition programs that experienced significant cost and schedule growth.  This analysis shows that several critical factors need to be addressed in the pre-acquisition phase of the acquisition cycle.  The principal causes of growth on these large-scale programs can be traced to several causes related to overzealous advocacy, immature technology, lack of corporate technology roadmaps, requirements instability, ineffective acquisition strategy, unrealistic program baselines, inadequate systems engineering, and work-force issues.[ii] This paper will discuss some key elements associated with:

• Establishing a process for requirements definition and developing the cost and schedule baseline
• Developing a reliable cost and schedule baseline,
• Identifying critical software management metrics,
• Applying Performance-Based Earned Value (PBEV), and
• Using an analytic process (such as SEER Control;) to project cost and schedule based on actual performance.

Read the rest of this entry »

Packaged Applications – The Hidden Costs of Snake-Oil

By David DeWitt

Most of us remember the dubious “doctor” in Huckleberry Finn who proclaims to have the cure for any malady.  From the back of the crowd his shill would loudly proclaim that he himself had been healed by the magical elixir.   Oh my, but the quantity of snake oil they sold before the townsfolk discovered they had been duped – and the doctor long gone.   From the tone of many internet blogs it seems the same buyer’s remorse is lingering in the “Packaged Application” world.

Before we get into the discussion of packaged applications let’s take a step back and remember how these wonder cures manifested.   In the late 1980’s – (when disco was dying) manufacturing companies wanted to shape supply chain management and enterprise resource planning.  In short, they wanted to encourage the concept of a “process in a box.” (my quotes).  Somehow over the last ten years the industry has forgotten that part about the need for the organizational “process” to change; and as we shall see, that is a key cause of hidden costs.

To belabor the point of “snake oil” for just a moment longer – what exactly is a packaged application?

1.       You can’t see the ingredients (What is the quality of the code?)

2.       You don’t know the recipe (How was it developed?)

3.       You don’t know how it’s to be served (Is it designed for my architecture?)

4.       When done – you hope it won’t upset your stomach (Will it run on or corrupt my databases?)

But it heals the sick and will bring peace and joy to the world … if it’s configured just right!

The top ten hidden costs are – in no specific order:

Read the rest of this entry »

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'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.