Performance-Based Earned Value
Defense AT&L Magazine
"Integrating Systems Engineering with Earned Value Management", May 2004
EV quantitatively linked with:
Technical performance measurement (TPM)
Progress against requirements
but EVMS Standard states that EV is a measurement of the quantity, not quality, of work accomplished.
EVM can be more effective as a program management tool if it is integrated with technical performance and if the EVM processes are augmented with a rigorous systems engineering process.
"Systems Engineering (SE) and EVM Support for Performance-Based Awards," Jan. 2007 SE and EVM article atl 2007.pdf
Provides practical advice for defining the technical performance requirements and desired program outcomes in SE terms.
EV can also be a valid basis for award fee determination if it is tied to technical performance, not just to work accomplished.
"Earned Value Management Acquisition Reform", Nov. 2010 Link to PDF
DoD reported to Congress that EVM no longer serves its intended purpose as a management tool. Pending legislation addresses EVM acquisition reform. Program Managers can get more value from EVM by linking EV to technical performance. Guidance to integrate cost, schedule and technical objectives is not provided by the EVM Standard, ANSI/EIA-748. Project management standards and best practices that are used by commercial companies should be considered for acquisition reform.
Major DoD acquisitions require contractor’s processes to comply with ANSI/EIA-748. However, a contractor may be compliant with the ANSI/EIA-748 guidelines but fail to link EV to technical performance or quality. The implementation and management value of EVM have been strongly criticized by DoD, the GAO, and Congress...Commercial corporations that use EVM do notbase their best practices on EVMS, ANSI/EIA-748.It is time to ask whether DoD, and other federal agencies, should continue to rely on ANSI/EIA-748 or should adopt the best practices of commercial companies that use EVM voluntarily, not because of a contractual mandate.
Some examples of compliant practices that led to misleading management information and that would not be permitted if the Quality Gap were closed are:
· Taking EV based on percent of drawings or software modules complete even though the hardware design did not meet requirements or the software did not meet planned functionality.
· Including budget and schedule for tests and rework in Management Reserve instead of in the initial PMB, work packages, and planning packages.
· Taking EV for rework and engineering changes based on the actual vs. estimated percent of units, iterations, or problem reports instead of on the percent of requirements met.
· Taking EV for software releases based on turning over the release, even though some of its baselined functionality was deferred to the next release.
· Not taking negative EV to show the true, net percent complete when the number of drawings or other units increased from the baselined number, with no change in the technical requirements.
· Not taking EV for drawings or other units returned for rework, when rework is planned in the same work package as the initial work.
"Path to EVM Acquisition Reform," May 2011Link to PDF
DoD should consider revising its DoDI 5000.02 and DFARS to require that earned value be linked to technical performance or quality, not just to the quantity of work performed. The quality objectives should be defined in the technical baseline and linked with the Performance Measurement Baseline.
The EVMS sections of DFARS should be changed to add “product scope” to work scope, and to require that the use of TPMs to measure progress be mandatory, not optional.
"A Contract Requirement Rule for Program Managers," Nov. 2015
Recommends replacement of EVMS Standard ANSI/EIA-748 with Project Management Institute Standard, PMBOK® Guide. (See PMBOK® Guide Excerpts)
EVM, based on ANSI-748, is used primarily by federal contractors when contractually required. A more powerful tool is the ANSI standard that is used world-wide on a voluntary basis when there are no federal requirements. It is the PMBOK® Guide.
A Program Manager’s needs that are covered by PMBOK® Guide but are absent in ANSI-748 include:
· Technical or product baseline
· Requirements management and traceability
· Risk management
PMBOK® Guide contains many subjects that are absent from ANSI-748 including:
· Product scope description - Documents the characteristics of the product that the project will be undertaken to create. Progressively elaborates the characteristics of the product…described in the project charter and requirements documentation.
· Project scope – The work that needs to be accomplished to deliver a product..with the specified features and functions
· Requirements Documentation - Requirements baseline; unambiguous (measurable and testable), traceable, complete, consistent, and acceptable to key stakeholders. Components include, functional requirements, non-functional requirements, quality requirements, and acceptance criteria.
· Requirements Management Plan – include…product metrics that will be used
· WBS Dictionary includes quality requirements, acceptance criteria
· Scope Baseline includes product scope description, project deliverables, and defines product user acceptance criteria
· Control Scope - Process of monitoring the status of the project and product scope and managing changes to the scope baseline. Completion of the product scope is measured against the product requirements.
· Requirements Traceability Matrix (RTM) – includes requirements to project (including product) scope/WBS objectives, product design, test strategy and test scenarios
· Conduct risk management planning, identification, qualitative risk analysis, quantitative risk analysis, response planning, and controlling risk.
PMBOK® Guide also covers EVM topics including scheduling (including network diagrams), PMB, control accounts, work packages, earned value, variance analysis, estimate at completion, and management reserve.
CrossTalk, the Journal of Defense Software Engineering
"Basing Earned Value on Technical Performance," Jan. 2013
Recommends contract language and project monitoring techniques to ensure that contractors integrate technical performance and quality, including software functionality, with EVM. Key enablers are a contractually-required IMP and linkage to systems engineering work products and best practices. Proposes tailored EVMS guidelines.
Require that anIMP be a contract deliverable.
Implementation of the recommended acquisition management processes and new contractual requirements will provide the following benefits:
• Close the EVMS Quality Gap
• Insightful IBRs and technical reviews
• Valid contract performance reports - Objective technical/schedule status - Credible EAC
• Early detection of problems - Program performance - EV measurement and compliance
Note: Contents of article in tutorial format: NDIA SE Conference, Oct. 2012, Tutorial, "Integrating SE with TPM"
“Practical, Performance-Based Earned Value” May 2006
College of Performance Management (CPM) Measurable News
“Integrating Systems Engineering with Earned Value Management, Part 2," 2016 Issue No. 4, page 36
“Performance-based EV in Commercial IT Projects" , 2010 Issue No. 2, page 1
“Integrating Risk Management with Earned Value Measurement (Risk Management Comes Out of the Closet)" , June1998
Journal of Software Management
"Agile Earned Value and the Technical Baseline ," Sept. 2009, page 9
Define Baselines for each Build (Technical, Schedule, Cost)
Once the Product Baseline is approved, establish the schedule in the IMS and the cost baseline in the EVM database… When planning incremental builds, allocate the functional requirements in the Product Baseline to each build in each block. Document each build’s technical baseline.
For valid reporting of project status, EV should reflect the results of deferring functionality from its baselined iteration, build, or block. When functionality is deferred from the current iteration to the backlog,…the deferral has the following major impacts: If all the requirements planned for iteration are not completed, then the EV for the deferred requirements cannot be earned as part of the iteration. It is behind schedule.
“Improving the Quality of EVM Information ," July 2011, page 32.
PMs rely on DCMA to assure that the supplier’s EVM data is reliable and accurate for decision making purposes. However, even if DCMA reports that the supplier is EVMS-compliant, the EV information is often inaccurate and misleading. This reliance on DCMA’s blessing is an immaculate misconception...A PM is vulnerable because of the Quality Gaps in Intent Guidelines 7, 14, and 30.
DoD SSTC Conference, April 2009
Tutorial, "Integrating SE with EVM"
•Require SE best practices in Request for Proposal (RFP)
•Confirm contractor’s proposal includes integration of SE with EVM
•Verify integration in Integrated Baseline Review
•Confirm achievement of success criteria in technical reviews
•Monitor consistency and validity of status reports and variance analyses
NDIA SE Conference, Oct. 2012
Tutorial, "Integrating SE with TPM"
Note: Contents of tutorial in article: CrossTalk, the Journal of Defense Software Engineering, "Basing EV on Technical Performance," Jan. 2013