Earned Value Management (EVM) is a Project Management technique for measuring project performance and progress in an objective manner. It’s a key integrating process in the management and oversight of acquisition programs, to include Software Management. EVM must be applied to manage and control software development and the strategy should be included in the Software Development Plan (SDP).
In order to facilitate the implementation of EVM for software, the Program Management Office (PMO) should: 
- Ensure the Work Breakdown Structure (WBS) is provided at the lowest level of tasks managed and includes appropriate critical software tasks and milestones tied to the EVM work package level. The objective is to establish a program WBS which mirrors the actual product(s) developed:
- Typical WBS elements for software include the Software Specification Review (SSR), Preliminary Design, Preliminary Design Review (PDR), Detailed Design, Critical Design Review (CDR), Code & Unit Test, Integration Test, Software Qualification Test (SQT), System Test, and User/Field Test.
- Place software elements in the WBS at appropriate levels which are consistent with the developed product architecture and hierarchy.
- It is imperative that preliminary requirements be defined prior to establishing WBS estimates, since the Budgeted Cost of Work Scheduled (BCWS) for software cannot be determined without them.
- Ensure that all software work is defined in work packages, and that the software work packages are managed and used as the basis for status reporting. This includes software work that may occur subsequent to software qualification, such as hardware/software integration and flight test.
- Assess and understand the impacts or limitations of selected earned value reports such as the Contract Performance Report (CPR), and establish reporting requirements which facilitate the level of software insight desired.
- If the software elements, appropriately placed in the WBS to reflect the to-be built product design, do not facilitate the desired identification and reporting of software status (e.g. system reporting at level 3 only and software elements are at lower levels), then the Contractor Data Requirements List (CDRL) should be tailored to include special reporting requirements to achieve the desired software earned value reporting. This special reporting could, for example, require collection and amalgamation of software earned value data from across the numerous WBS elements containing software for reporting as a single software report, or alternately, reporting of software earned value status could be required at the subsystem level to provide more detailed software insight.
- It is important to establish reporting levels with enough granularity such that visibility into significant software development problems at the lower level components is not lost (washed out) in the reporting roll-up. Typical software reporting is done for subsystem design, code and test. For more granularity, track by candidates for change (e.g., Baseline Change Requests (BCRs)). For example, design for each BCR can be tracked as tasks to prepare for a common system or subsystem PDR and CDR.
- Ensure the program cost accounts and work packages reflect the WBS structure and are consistent with the software effort and schedule estimates for the program.
- Ensure the work package schedules integrate into and are consistent with the program Integrated Master Schedule (IMS) and the working schedules used by developer‘s software managers.
- Require the contractor to provide descriptions of how Earned Value (EV) is earned on software design, development, and test tasks. Develop an understanding of how the contractor earns value on these tasks (e.g., as a percentage of code size, as a percentage of test cases executed, 50% for starting a task and 50% for completing it), and how this impacts EV reporting.
- Collect and review EV data to determine actual software effort and schedule status against the budgeted effort and schedule for the software components (schedule and cost variances). Status is determined by measuring technical progress and EV at the work package level.
- Establish on-line collaborative (real-time or near-real-time) access to EV data to provide timely insight into software development status. Minimize the lag time between the end of an EV reporting period and the availability of EV analysis to more quickly identify problems or risks.
- Use the software EV reporting to identify specific or systemic software development problem areas for focused monitoring or resolution, by identifying deviations and patterns of deviation from planned budget and schedule.
AcqLinks and References:
- USAF Weapon Systems Software Management Guidebook
- Open Technology Development (OTD): Lessons Learned & Best Practices for Military Software, – 16 May 2011
- Mil-STD-498 “Software Development and Documentation” – 5 Dec 1994
- Joint Software Systems Safety Engineering Handbook (JSSSEH) – 27 Aug 2010
- Journal: Journal of Software Technology