Performance-Based Earned Value
Comparison of Deficiencies in EIA-748 (EVMS Standard) compared with
PMBOK® Guide:
- Silent on "product" and "product baseline"
- Silent on technical or capability requirements
- Silent on "requirements traceability" to WBS
- Cites "program work scope" instead of "technical work scope" or "product scope"
- Silent on risk management
- Silent on project procurement management such as
1. Technical requirements and requirements traceability matrix flowed down
to sellers
2. Sellers technical performance status
DOD Adaptive Acquisition Framework vs. EIA-748
EIA-748 does not meet the needs of the DOD Adaptive Acquisition Framework (AAF) with regard to the above deficiencies.
The following table shows elements of DODD 5000.01 and DODI 5000.88 which are not covered by EIA-748 but are covered in PMBOK Guide.®
Elements of Adaptive Acquisition Framework (AAF) not covered by EIA-748 Guidelines
Note: parenthesized comments are not in document
DODD 5000.01 The Defense Acquisition System (DAS)
k. Employ Performance Based-Acquisition Strategies
“Performance-based strategy” means a strategy that supports an acquisition approach structured around the results to be achieved (technical baseline or product scope) as opposed to the manner by which the work is to be performed (statement of work).
DODI 5000.88 Engineering of Defense Systems
3.4 Program Technical Planning and Management
a. Systems Engineering Plan (SEP)
(3) For MDAPs, ACAT II, and ACAT III programs, the SEP will contain these elements, unless waived by the SEP approval authority:
(b) The engineering management approach to include technical baseline management; requirements traceability; CM; risk, issue, and opportunity management; and technical trades and evaluation criteria. (c) The software development approach to include architecture design considerations; software unique risks; software obsolescence; inclusion of software in technical reviews; identification, tracking, and reporting of metrics for software technical performance, process, progress, and quality; software system safety and security considerations; and software development resources.
(g) Specific technical performance measures and metrics, and system engineering leading indicators to provide insight into the system technical maturation relative to a baseline plan. Include the maturation strategy, assumptions, reporting methodology and maturation plans for each metric with traceability of each performance metric to system requirements and mission capability characteristics.
(k) The timing, conduct, and entry and exit criteria for technical reviews.
(l) A description of technical baselines (e.g., concept, functional, allocated, and product), baseline content, and the technical baseline management process.
3.4.c Configuration and Change Management
(3) Provide for traceability of mission capability to system requirements to performance and execution metrics.
3.4 f. Risk, Issue, and Opportunity Management.
(2) Risk management plans will address risk identification, analysis, mitigation planning, mitigation implementation, and tracking. Technical risks and issues will be reflected in the program’s Integrated Master Plan and Integrated Master Schedule.
4.1.1.1, 5.2.3.1 Product scope description
This documents the characteristics of the product that the project will be undertaken to create.
Progressively elaborates the characteristics of the product, service or result described in the project charter
and requirements documentation.
5.2.3.1 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
Acceptance criteria
5.1.3.2 Requirements Management Plan
Components include:
How requirements activities will be planned, tracked, and reported
Product metrics that will be used
Traceability structure to reflect which requirements attributes will be captured on the traceability matrix
5.2.3.2 Requirements Traceability Matrix (RTM)
Grid that links product requirements from their origin to the deliverables that satisfy them. It provides a
means to track requirements throughout the project life cycle.
Includes tracing requirements for:
Project scope/WBS objectives
Product design
Product development
Test strategy and test scenarios
High-level requirements to more detailed requirements
Attributes associated with each requirement can be recorded in the RTM. Typical attributes used in the RTM
may include current status (such as active, cancelled deferred, added, approved, completed), and
acceptance criteria.
5 Scope
In the project context, the term scope can refer to:
- Product scope - the features and functions that characterize a product
- Project scope - the work performed to deliver a product...with the specified features and functions
5.3.3.2 WBS Dictionary
May include quality requirements, acceptance criteria
5.5 Validate Scope
Process of formalizing acceptance for the completed product deliverables.
5.6 Control Scope
Completion of the product scope is measured against the product requirements.
8.3.1.5 Work Performance data
Contains measurements for technical performance.
11 Project Risk Management
Conduct risk management planning, identification, qualitative risk analysis, quantitative risk analysis,
response planning, response implementation, and monitoring risk
11.5.3.2 Project Management Plan Updates
Schedule baseline. Changes in the schedule baseline are incorporated in response to approved changes
in schedule estimates that may arise from agreed-upon risk responses.
Cost baseline. Changes in the cost baseline are incorporated in response to approved changes in cost
estimates that may arise from agreed-upon risk responses.
11.7.2.1 Data Analysis
TPM compares technical accomplishments during project execution to the schedule of technical
achievement. It requires definition of objective quantifiable measures of technical performance which can
be used to compare actual results against targets. Such TPMs may include weight, transaction times,
number of delivered defects, storage capacity, etc.
12 PROJECT PROCUREMENT MANAGEMENT
Project Procurement Management includes the processes necessary to purchase or acquire products, ….
from outside the project team. Project Procurement Management includes the management and control
processes required to develop and administer agreements such as contracts,…
12.3.1.2 PROJECT DOCUMENTS Project documents that can be considered as inputs to this process include
but are not limited to:
· Requirements documentation may include…technical requirements the seller is required to satisfy, and
· Requirements traceability matrix…links product requirements from their origin to the deliverables that
satisfy them.
12.3.1.6 WORK PERFORMANCE DATA contains seller data on project status such as technical performance;
activities that have started, are in progress, or have completed; and costs that have been incurred or
committed.
12.3.3.2 WORK PERFORMANCE INFORMATION includes information on how a seller is performing by
comparing the deliverables received, the technical performance achieved, and the costs incurred and
accepted against the SOW budget for the work performed.
Project Management Institute (PMI)
Project Management Body of Knowledge (PMBOK® Guide) Excerpts