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 »

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