Posted on April - 20 - 2009

Applying Earned Value Management to Software Intensive Programs

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 »

Posted on November - 15 - 2008

On Data Collection and the Moon

Better hope it

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.