Using CMMI® to Improve EVM
Organizations that want to integrate technical performance or quality with cost and schedule performance should consider using Capability Maturity Model Integration® (CMMI) as a framework for process improvement.
CMMI includes many Specific Practices (SP) and examples that, if incorporated into an organization’s EVM processes, will improve the quality of EVM information. The improvements will focus management attention on progress towards defining the technical baseline and meeting the technical requirements instead of just measuring the quantity of work performed.
The 2002 CMMI Technical Note, “Using CMMI to Improve Earned Value Management,” by Paul Solomon, was published by the Carnegie Mellon Software Engineering Institute (SEI). It provides guidance for cost-effective process improvement. It includes mapping and comparison tables between CMMI and the ANSI/EIA-748, the EVM System standard (EVMS) that can be used to identify practices and work products within CMMI that are not included in EVMS but, if added to an organization's processes, will close the Quality Gap in their EVM system descriptions.
CMMI has been revised several times since 2002. The latest version, “CMMI for Development, Version 1.3,” was published in Nov. 2010. This version has significant revisions in the Requirements Development (RD) and Requirements Management (RM) Process Areas (PA) with regard to:
· Functional and Quality attribute requirements
· Allocating requirements to delivery units
· Aligning the requirements baseline with the project plan and work products.
The following tables should be used to augment the Technical Note.
Process Area: Requirements Development (Not in Technical Note) | EVMS sections |
Specific Practice 2.1 (v. 1.3 changes in red) Establish and maintain product and product component requirements, which are based on the customer requirements. The customer functional and quality attribute requirements can be expressed in the customer’s terms and can be nontechnical descriptions. The product requirements are the expression of these requirements in technical terms that can be used for design decisions. | None (EVMS Quality Gap) |
SP 2.1 Example Work Products 1. Derived requirements 2. Product requirements 3. Product component requirements 4. Architectural requirements, which specify or constrain the relationships among product components SP 2.1 Subpractices 1. Develop requirements in technical terms necessary for product and product component design. 2. Derive requirements that result from design decisions. | None |
Specific Practice 2.2 Allocate the requirements for each product component. | None |
SP 2.2 Subpractices (v. 1.3 changes in red) 1. Allocate requirements to functions. 2. Allocate requirements to product components and the architecture. 3. Allocate design constraints to product components and the architecture. 4. Allocate requirements to delivery increments. 5. Document relationships among allocated requirements. Relationships include dependencies in which a change in one requirement can affect other requirements.
|
None |
Process Area: Requirements Management (Table 2 in Technical Note, revised per v. 1.3) (v. 1.3 changes in red) | EVMS sections |
Specific Practice 1.5 Ensure that project plans and work products remain aligned with requirements | |
Subpractices: 1. Review project plans, activities, and work products for consistency with requirements and changes made to them. 2. Identify the source of the inconsistency (if any). 3. Identify any changes that should be made to plans and work products resulting from changes to the requirements baseline. 4. Initiate any necessary corrective actions. |
2.1.c
2.5.a, 2.5.d, 2.5.e |
The Technical Note and CMMI v 1.3 may be downloaded from SEI:
Technical Note
CMMI for Development v 1.3