V20FullModel PDF

2019-08-06 17:35:49 This copy is licensed solely to Solangel Rico, who agrees not to reproduce, duplicate, copy, sell,
resell, assign, transfer or exploit any portion of this

document without express written permission by CMMI® Institute. Usage by others is prohibited.
2
Copyright © 2018 CMMI Institute
THIS CMMI INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS.
TO THE MAXIMUM EXTENT ALLOWED BY LAW, THE CMMI INSTITUTE SPECIFICALLY DISCLAIMS ALL
WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY, REGARDING OR RELATING
TO THE CAPABILITY MATURITY MODEL INTEGRATION (CMMI), AND ALL MODEL CONTENT, INCLUDING
THE CMMI V2.0 PRODUCT SUITE, CMMI METHOD DEFINITION DOCUMENT, CMMI ADOPTION AND
TRANSITION GUIDANCE, CMMI MODEL, AND CMMI MODEL VIEWER (“CMMI CONTENT”), INCLUDING
ALL IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE,
NONINFRINGEMENT, USAGE OF TRADE, AND COURSE OF DEALING OR PERFORMANCE.
CMMI Institute owns all copyright, trademark, and all other intellectual property rights in the CMMI
Content. You may not reproduce, duplicate, copy, sell, resell, assign, transfer, create derivative works of,
incorporate in any software or tool, or commercially exploit any portion of the CMMI Content, without
express written permission by CMMI® Institute. You are solely responsible for your use of the CMMI
Content, and agree to defend, indemnify and hold CMMI Institute harmless from any claims, liability,
damages, costs or expenses incurred by CMMI Institute arising from your use of the CMMI Content.
2019-08-06 17:35:49 This copy is licensed solely to Solangel Rico, who agrees not to reproduce, duplicate, copy, sell, resell, assign, transfer or exploit any portion of this
3
CMMI Model
Document Change History
Version Date Description

2.0 28 March 2018 Initial baseline release of CMMI Model with
Development view.
2.1 4 December 2018 Updates include:

• Addition of content for Services and
Supplier Management views, including
changes to graphics
• Changes to address change requests from
community feedback received through
August 2018
• Refer to the Release Notes, available
through the Model Viewer for more details
4
CMMI V2.1 Model
Table of Contents
Overview ........................................................................................................................ 9
Part One: About CMMI and Executive Summary ............................................................ 9

Why use the CMMI? ............................................................................................................................. 10
Benefits ................................................................................................................................................. 11
Improve Your Performance ................................................................................................................... 12
Purpose ................................................................................................................................................ 13
Audience ............................................................................................................................................... 13
Model Structure and Content................................................................................................................ 13
Model Content Organization ................................................................................................................. 14
CMMI V2.0 Product Suite ..................................................................................................................... 14
Part Two: Successfully Adopting CMMI ......................................................................... 35

Elevating Performance through Process Improvement ........................................................................ 35
Part Three: Process Persistence and Habit .................................................................. 40

Sustaining Habit and Persistence......................................................................................................... 41
Part Four: Achieving High Maturity ................................................................................ 43
Practice Areas ............................................................................................................. 48
Part Five: Practice Areas ............................................................................................... 48

Causal Analysis and Resolution (CAR) ......................................................................... 49
Level 1 .................................................................................................................................................. 52
Level 2 .................................................................................................................................................. 53
Level 3 .................................................................................................................................................. 56
Level 4 .................................................................................................................................................. 62
Level 5 .................................................................................................................................................. 65
Configuration Management (CM) .................................................................................. 66

Level 1 .................................................................................................................................................. 70
Level 2 .................................................................................................................................................. 71
Continuity (CONT) ......................................................................................................... 80

Level 1 .................................................................................................................................................. 81
Level 2 .................................................................................................................................................. 83
Level 3 .................................................................................................................................................. 88
Decision Analysis and Resolution (DAR)....................................................................... 94
5
Level 1 .................................................................................................................................................. 98
Level 2 ................................................................................................................................................ 100
Level 3 ................................................................................................................................................ 106
Estimating (EST) ......................................................................................................... 108

Level 1 ................................................................................................................................................ 113
Level 2 ................................................................................................................................................ 114
Level 3 ................................................................................................................................................ 122
Governance (GOV) ..................................................................................................... 126

Level 1 ................................................................................................................................................ 128
Level 2 ................................................................................................................................................ 129
Level 3 ................................................................................................................................................ 138
Level 4 ................................................................................................................................................ 141
Implementation Infrastructure (II) ................................................................................ 142

Level 1 ................................................................................................................................................ 144
Level 2 ................................................................................................................................................ 145
Level 3 ................................................................................................................................................ 149
Incident Resolution and Prevention (IRP) ................................................................... 154

Level 1 ................................................................................................................................................ 157
Level 2 ................................................................................................................................................ 158
Level 3 ................................................................................................................................................ 163
Managing Performance and Measurement (MPM) ..................................................... 168

Level 1 ................................................................................................................................................ 174
Level 2 ................................................................................................................................................ 177
Level 3 ................................................................................................................................................ 195
Level 4 ................................................................................................................................................ 206
Level 5 ................................................................................................................................................ 220
Monitor and Control (MC) ............................................................................................ 226

Level 1 ................................................................................................................................................ 231
Level 2 ................................................................................................................................................ 233
Level 3 ................................................................................................................................................ 244
Organizational Training (OT) ....................................................................................... 252

Level 1 ................................................................................................................................................ 255
Level 2 ................................................................................................................................................ 256
Level 3 ................................................................................................................................................ 258
Peer Reviews (PR) ...................................................................................................... 267

Level 1 ................................................................................................................................................ 270
Level 2 ................................................................................................................................................ 271
Level 3 ................................................................................................................................................ 275
Planning (PLAN) ......................................................................................................... 276

Level 1 ................................................................................................................................................ 283
6
Level 2 ................................................................................................................................................ 286

Level 3 ................................................................................................................................................ 305
Level 4 ................................................................................................................................................ 317
Process Asset Development (PAD) ............................................................................. 320

Level 1 ................................................................................................................................................ 323
Level 2 ................................................................................................................................................ 324
Level 3 ................................................................................................................................................ 327
Process Management (PCM) ...................................................................................... 342

Level 1 ................................................................................................................................................ 346
Level 2 ................................................................................................................................................ 351
Level 3 ................................................................................................................................................ 356
Level 4 ................................................................................................................................................ 364
Process Quality Assurance (PQA)............................................................................... 366

Level 1 ................................................................................................................................................ 370
Level 2 ................................................................................................................................................ 371
Level 3 ................................................................................................................................................ 377
Product Integration (PI) ............................................................................................... 378

Level 1 ................................................................................................................................................ 381
Level 2 ................................................................................................................................................ 382
Level 3 ................................................................................................................................................ 391
Requirements Development and Management (RDM)................................................ 397

Level 1 ................................................................................................................................................ 402
Level 2 ................................................................................................................................................ 403
Level 3 ................................................................................................................................................ 413
Risk and Opportunity Management (RSK) .................................................................. 425

Level 1 ................................................................................................................................................ 429
Level 2 ................................................................................................................................................ 431
Level 3 ................................................................................................................................................ 434
Service Delivery Management (SDM) ......................................................................... 442

Level 1 ................................................................................................................................................ 444
Level 2 ................................................................................................................................................ 445
Level 3 ................................................................................................................................................ 456
Strategic Service Management (STSM) ...................................................................... 458

Level 1 ................................................................................................................................................ 460
Level 2 ................................................................................................................................................ 461
Level 3 ................................................................................................................................................ 466
Supplier Agreement Management (SAM) .................................................................... 468

Level 1 ................................................................................................................................................ 471
Level 2 ................................................................................................................................................ 474
Level 3 ................................................................................................................................................ 482
7
Level 4 ................................................................................................................................................ 489
Supplier Source Selection (SSS) ............................................................................... 491

Level 1 ................................................................................................................................................ 492
Level 2 ................................................................................................................................................ 496
Level 3 ................................................................................................................................................ 504
Technical Solution (TS) ............................................................................................... 506

Level 1 ................................................................................................................................................ 509
Level 2 ................................................................................................................................................ 510
Level 3 ................................................................................................................................................ 516
Verification and Validation (VV) ................................................................................... 524

Level 1 ................................................................................................................................................ 527
Level 2 ................................................................................................................................................ 529
Level 3 ................................................................................................................................................ 534
Appendices ................................................................................................................ 536
Part Six: Appendices ................................................................................................... 536

Appendix A: Core Practice Areas, Categories, and Capability Areas ................................................. 536
Appendix B: Predefined Model Views – Maturity and Capability Levels ............................................ 550
Appendix C: CMMI Adoption and Transition Resources .................................................................... 569
Appendix D: Common CMMI Misperceptions .................................................................................... 571
Appendix E: Glossary ......................................................................................................................... 574
Appendix F: Abbreviations .................................................................................................................. 593
Appendix G: CMMI Development History ........................................................................................... 596
Appendix H: References ..................................................................................................................... 597
Appendix I: Acknowledgements.......................................................................................................... 598
8
List of Figures
Figure 1. Why Build Capability? ............................................................................................................9
Figure 2. Why use CMMI? .................................................................................................................. 10
Figure 3. Driving Performance through Capability ................................................................................ 12
Figure 4. Model Content Organization................................................................................................. 14
Figure 5. CMMI V2.0 Product Suite ..................................................................................................... 15
Figure 6. Integrated CMMI Product Suite ............................................................................................ 16
Figure 7. Structural vs. Content Architecture ....................................................................................... 17
Figure 8. CMMI Model Structure ......................................................................................................... 18
Figure 9. CMMI Model Component Structure ....................................................................................... 19
Figure 10. CMMI Model Component Structure - Views ......................................................................... 21
Figure 11. Planning and Managing Work Capability Area View.............................................................. 22
Figure 12. Categories and Associated Capability Areas......................................................................... 23
Figure 13. Practice Area Organization ................................................................................................. 25
Figure 14. Definitions of Evolutionary Level Characteristics .................................................................. 26
Figure 15. Example Icon, DAR ........................................................................................................... 29
Figure 16. Model Content Relationships .............................................................................................. 29
Figure 17. Four Stages of Process Discipline ....................................................................................... 36
Figure 18. Four Characteristics of Process Persistence and Habit .......................................................... 40
Figure 19. Maturity Levels 2 & 3 vs. 4 & 5 .......................................................................................... 44
Figure 20. Using High Maturity to Determine if Work Should be Accepted ............................................. 46
Figure 21. Two Approaches to Improvement ...................................................................................... 47
Figure 22. Core Practice Areas ......................................................................................................... 537
Figure 23. Practice Areas by Domain ................................................................................................ 538
Figure 24. Categories and Capability Areas ....................................................................................... 539
Figure 25. Practice Area vs. Practice Structure .................................................................................. 551
Figure 26. Evolutionary View of Practice Group Levels in Practices ..................................................... 553
Figure 27. Capability Level Rating Progression – CM Example ............................................................ 554
Figure 28. Maturity Levels Summary................................................................................................. 555
Figure 29. CMMI Development, Maturity Levels 2-5 ........................................................................... 557
Figure 30. CMMI Services, Maturity Levels 2-5 .................................................................................. 561
Figure 31. CMMI Supplier Management, Maturity Levels 2-5 .............................................................. 565
Figure 32. Development and Multi-Model Capability Area View Examples ............................................ 568
9
Overview
Part One: About CMMI and Executive Summary
CMMI® (Capability Maturity Model® Integration) is an integrated set of best practices that
enable businesses to improve performance of their key business processes. This model was
developed by product teams with members from industry and CMMI Institute. At its heart, the
CMMI provides a clear roadmap for building, improving, and sustaining capability. Figure 1
provides some key reasons to build capability.
Figure 1. Why Build Capability?
The architecture and design of the CMMI V2.0 Product Suite is a radical departure from its
predecessors to make it more useful and adoptable for customers and businesses. One of the
key drawbacks of complex maturity models is the time and resources it takes to make updates
and keep them current with business, technology trends, and market demands. To address this
challenge, the architecture of CMMI was specifically designed to be flexible, agile, and evolve as
these and other factors change. This enables rapid development and addition of relevant new
content at the speed of business, technology, and change.
CMMI provides guidance for applying this set of best practices in a business or organization, to
ensure quality and timely solutions that delight customers and end users. Every company or
organization can benefit from improving performance and reducing risk. The CMMI provides a
roadmap that guides improvement from ad hoc activities to disciplined and consistent processes
for achieving business objectives related to:
• Performance
• Quality
• Cost
• Schedule
• Functionality
10
Why use the CMMI?

CMMI helps a business understand its current level of capability and performance. If business
needs and objectives are not being met, CMMI practices can guide improvement to elevate and
optimize performance. Focusing primarily on business benefits and performance drives process
improvements to better serve the needs of the business and, ultimately, the customer. To
accomplish this:
• An effective and sustainable improvement program needs to be in place
• The focus of improvement needs to be on performance
• Executive management must visibly and actively support the effort to improve
Figure 2 summarizes the results of an assessment of capabilities and processes that CMMI
directly addresses.
Figure 2. Why use CMMI?
11
Benefits
Using CMMI provides many benefits, including:
• A positive return on performance and process improvement investments
• Meeting commitments that result in:
o More timely delivery
o Fewer last-minute crunches
o Enhanced cost control
o Increased quality of solutions
• Management visibility which results in:
o More rapid response to issues and risks
o Fewer surprises
o High quality solutions that meet customer needs and expectations
o Reduced customer complaints
o Reduced rework
o Lower employee turnover
12
Improve Your Performance

It is important to understand the organization’s current level of performance, and the extent
that it aligns to the current business needs and objectives. If performance is not meeting
business needs and objectives, then process improvement is used to raise performance to the
needed level. Performance should be managed at all levels in the business and be a key driver
for process change. Figure 3 provides a summary of how CMMI addresses performance and
capability improvement.
Figure 3. Driving Performance through Capability
13
Purpose
The CMMI model is an organized collection of best practices for business and performance
improvement. Best practices in the model focus on what needs to be done to improve
performance, not how to do it. Successful adoption of the CMMI is dependent on each situation.
One specific approach may not be successful in every situation. CMMI has been explicitly
designed to be understandable, accessible, and flexible to a broad variety of businesses and
types of work. It facilitates faster, easier, and successful improvement to address:
• Increasing performance
• Industry-specific needs
• Multiple types of organizations or projects
• Market drivers, such as:
o Business and industry trends
o Regulatory requirements
o New or changing technologies
Audience
The audience for CMMI includes anyone interested in improving performance in any business
environment. Whether you are seeking information to begin improving your performance or are
already familiar with the concept of capability maturity models, the CMMI can be useful to you.
CMMI can also be effectively used for performing due diligence in the selection of potential
suppliers, or on an organization you might be interested in acquiring.
As part of the integrated CMMI V2.0 Product Suite, the CMMI Institute has published guidance
to help you begin or continue your performance improvement journey by adopting or
transitioning to CMMI. Refer to Appendix C: CMMI Adoption and Transition Resources, for the
CMMI adoption and transition guidance and a list of additional resources that address critical
business performance and capability challenges.
Model Structure and Content

Rather than having all the material contained in a single, linear document or book, the CMMI
model supports providing content to users in different formats, different level of detail, and with
different emphasis depending on the views defined or needed. This allows for a robust set of
information tailored to specific uses and needs.
14
Model Content Organization

To make it easier to present the model content in a more approachable and easier-to-
understand manner and make future updates easier, the model content has been broken into 6
parts, organized by three primary sections, including the overview (this section), Practice Areas,
and Appendices. Refer to Figure 4.
Figure 4. Model Content Organization

Part
Title Description
Number
Section: Overview
Part 1 About CMMI V2.0 Provides an overview of the CMMI V2.0 Product Suite, including
an Executive Summary of the model.
Part 2 Successfully Adopting Provides the context for understanding and using CMMI in a
CMMI manner that achieves tangible business results.
Part 3 Process Persistence Describes how to build and sustain business performance
and Habit improvement and capability throughout an organization.
Part 4 Achieving High Builds on early performance success from adopting the model
Maturity and elevates it to optimizing performance through understanding
variation and performance objectives.
Section: Practice Areas
Part 5 Practice Areas Containing the majority of the content of the model, this part
contains all the practice areas of the model.
Section: Appendices
Part 6 Appendices A-I More detailed information on adopting the CMMI, understanding
the predefined views and levels it contains and how they work,
as well as the glossary, acronym list, index and
acknowledgements.
CMMI V2.0 Product Suite

At its core, CMMI is a set of predefined and customized views that apply to different business
environments. The CMMI V2.0 Product Suite contains five components as shown in Figure 5.
15
Figure 5. CMMI V2.0 Product Suite
16
Figure 6 shows the entire integrated CMMI V2.0 Product Suite. This integrated approach was
designed to reduce the “stovepiping” of product suite components.
Figure 6. Integrated CMMI Product Suite
A CMMI V2.0 architecture design goal is to provide a flexible performance improvement model
and structure that can adapt to meet short- and long-term needs. The architecture and
substructures will accommodate all CMMI Institute’s existing and future models and content.
17
There are two key design aspects addressed by the CMMI architecture. One deals with structure
and the other describes the content contained in that structure. The difference between
structural and content architecture is illustrated in Figure 7.
Figure 7. Structural vs. Content Architecture
Another design goal is to reduce the size and complexity of the model, yet not lose the ability to
have extensive explanatory material for advanced users who want an in-depth understanding of
a topic area. This goal has been accomplished, in part, by moving to an electronic format with
links to external informative material. This allows the informative material to be updated to
accommodate technical changes without having to update the core model.
This approach makes it possible for end users to create a view of the model to meet their
organization’s performance improvement needs. This enables the CMMI model to be effective
for a wide range of organizations, such as when the model is used as a part of a supplier
selection process only a subset of model components may be critical for a specific supplier
selection. The organization can construct a custom view that fits those priorities, so they and
their potential suppliers know what is expected.
Historically, CMMI models focused separately on key process issues for development, services,
and supplier management. However, businesses rarely focus on only development, only
services, or only supplier management. For example, besides developing a product, a
development organization may also provide help desk services to end users. By integrating the
separate CMMI models and other models or sources, e.g., the People-CMM (P-CMM), this
provides an integrated and holistic approach to performance improvement by allowing
organizations to focus on the areas of improvement that they find most relevant.
18
Except for the overview of the model and the appendices within the model, the format of the
material follows a common modular structure. Figure 8 shows the high-level overview of the
modular structure of the CMMI model.
Figure 8. CMMI Model Structure
19
At the highest level, the CMMI model is a container of Practice Areas and composed of five
components, described in Figure 9.
Figure 9. CMMI Model Component Structure
20
21
This architecture provides a core model that contains material that applies to any context, along
with additional helpful information for organizations wishing to understand and adopt the
model, or use it in a specific context, such as agile with Scrum, development, services, etc. This
modularization allows the model to be extended and updated with new examples, technologies,
and methods without having to update the entire model.
View
Views may be subject to change over time. A view is a window into the model which allows an
organization or project to focus on what is important to them or their organization. There are
predefined views that an organization can select. Or if none of the predefined views meet
business needs, organizations can construct their own custom view as shown in Figure 10. For
example:
• An organization that primarily performs software development, could choose the
predefined view of CMMI Development (CMMI-DEV)
• An organization wanting to improve their work management capability could choose a
view for the Planning and Managing Work Capability Area (refer to Figure 11) to help
them manage their work management performance
For a complete listing of current CMMI Institute predefined model views, refer to Appendix A.
Figure 10. CMMI Model Component Structure - Views
Constructing a view consists of selecting what CMMI model components to include in the view.
Capability Area
A Capability Area is a group of related practice areas that can provide improved performance in
the skills and activities of an organization or project. A Capability Area view is a subset of the
CMMI model that describes a predefined set of Practice Areas that make up a specific Capability
22
Area. Capability Areas are a type of a view. Figure 11 illustrates a view of the Planning and
Managing Work Capability Area that includes all current and future planned associated Practice
Areas. Note: Future planned or potential Capability Areas and Practice Areas are shown in gray.
Figure 11. Planning and Managing Work Capability Area View
Categories for Capability Areas

Categories are logical groups or views of related capability areas that address common
problems encountered by businesses when producing or delivering solutions. One of the lessons
learned from industry experience is that creating small groups of similar topics in a list makes
them easier to understand and remember. Incorporating this approach into the CMMI V2.0
Product Suite makes training and adoption more effective. Additionally, the categories match a
typical performance improvement path, moving from doing simple tasks, to managing them to
be more efficient, to enabling them to be more effective, and finally to continually improving
them to achieve better performance. Categories are types of views.
The categories are:
• Doing – Capability Areas for producing and delivering quality solutions
• Managing – Capability Areas for planning and managing implementation of solutions
• Enabling – Capability Areas for supporting solution implementation and delivery
• Improving – Capability Areas for sustaining and improving performance
23
Figure 12 shows how the capability areas are organized into the categories.
Figure 12. Categories and Associated Capability Areas
These view categories help to prioritize, organize, and plan resources while focusing attention
on the most critical issues facing the business.
For example:
• Customer satisfaction is both a primary objective and a challenge for most
organizations. The Doing category provides several sets of best practices to consistently
produce and deliver solutions that satisfy the customer.
• For organizations that want to improve their planning capabilities, or that have
problems consistently planning and managing the work, the Managing category
provides several sets of best practices to help resolve these issues.
24
• Organizations typically have challenges in addressing complexity and managing change.

The Enabling category provides a clear set of approaches to control, decide, and
communicate how complexity and change are being addressed.
• Many organizations recognize a need to improve performance but lose momentum and
focus once marginal gains have been achieved. The Improving category enables
effective and sustainable performance improvement.
Practice Area (PA)

A Practice Area is a set of practices that collectively describe the critical activities needed to
achieve a defined intent and value. Practice Areas are composed of:
• Practice Area Name & Icon
• Required PA Information
o Intent – to explain what results and accomplishments are expected as an outcome
of the PA
o Value – business value achievable by adopting practices in the PA
o Additional Required Information - remaining description of the practice area which is
important and useful to better understand the meaning of the practice area intent
and required information and may not be present for every PA
• Explanatory PA Information
o Practice Summary
o Additional Information
o Related Practice Areas – The PA(s) reflected in this section represent common
relationships, but are not intended to be reflective of all possible relationships
o Context Specific Information, if applicable
• Practice Groups
o Organizing structure for practices within a practice area to support understanding
and implementation
o Practice groups allow for different ways of organizing similar information and
practices. For example, evolutionary levels can be used to show increasing capability
for performance and organizational standardization. In other examples, practices
may be grouped by logical function, theme, or thread, e.g., ISO uses clauses and
sub clauses, which are similar organizing concepts as practice groups.
25
Figure 13 shows a summary view of how CMMI Practice Areas are organized.
Figure 13. Practice Area Organization
Practice Group
Within practice areas, the practices are organized into a set of evolutionary levels labeled Level
1, Level 2, etc. which provide a path for performance improvement.
Each evolutionary level builds on the previous levels by adding new functionality or
sophistication resulting in increased capability.
26
Figure 14 provides a brief definition of the evolutionary levels.
Figure 14. Definitions of Evolutionary Level Characteristics
Each level:
• Builds on the practices at lower levels
• Represents an increase in functionality and capability
• May add new functionality
Levels include the following:
• Level 0
o Incomplete approach to addressing the intent of the PA
27
o May or may not be meeting the full intent of any practices

• Level 1
o Basic practices that describe an initial approach to addressing the intent of the PA
o Not a complete set of practices to meeting the full intent of the PA
o What you would expect to see from an organization or project just starting the
journey towards improvement
o Starts to focus on performance issues
• Level 2
o Simple, but complete set of practices that address the full intent of the PA
o Does not require the use of organizational assets or standards
o The intent of the set of practices can be met in various ways based on the project
o Identifies and monitors project performance objectives
• Level 3
o Uses organizational standards and includes tailoring of processes to address unique
project and work characteristics
o Uses and contributes to organizational assets
o Manages both project and organizational performance
• Level 4
o Use of statistical and other quantitative techniques to detect or refine the area of
focus or to predict if quality and process performance objectives will be achieved
o Understands performance variation statistically or quantitatively and manages
progress against quality and process performance objectives
• Level 5
o Use of statistical and other quantitative techniques to optimize performance and
enhance the achievement of objectives including business, measurement and
performance, and quality and process performance objectives
The order of the practices in each practice area and group does not imply or require a
sequential order as performed in a process. Processes that meet the intent of the practice areas
and practices may be performed iteratively, in parallel, or in any other order that best meets
the needs of an organization’s business.
Practices
The practices in the CMMI product suite consists of:
1. Required Practice Information:
• Practice statement
• Value statement: Business value of using this component (why do it?)
• Additional required material that further describes the scope and intent of the practice
and supports clear and consistent understanding and interpretation
2. Explanatory Practice Information:
• Additional Explanatory Information
• Example Activities
28
• Example Work Products

• Related Practice Areas, as needed
• Context Specific Information (there may be multiple context instances):
o Context specific identifier and description
o Additional informative material, as needed
o Example Activities, as needed
o Example Work Products, as needed
o Related Practice Areas, as needed
Practices provide the ability to include external material that is determined important to
associate with the model and enables understanding and adoption. These can include:
• Extended informative material including domain specific implementation examples
• Process and implementation assets such as templates, process descriptions, etc.
• Training modules, tools, methods, etc.
• Case studies
• Other helpful material
Language Conventions: In the CMMI V2.0 Product Suite, when the term “or” appears, it is
used in the inclusive sense, and can mean both “and” as well as “or”:
• “and” as in “manage plans and activities” can mean managing both plans AND
managing activities
• “or” as in “manage risks or opportunities” can mean managing either risks OR
opportunities OR both
Certain words in the CMMI product suite have special meaning. When applicable, that term is
included in the glossary. Otherwise the common English meaning, e.g. Webster or Oxford
dictionary, applies.
Additional Content Characteristics

As a means for more effective identification, recall and learning, each Practice Area includes an
identification icon used for multiple purposes, including:
• Showing relationships
• Training
• Online selection buttons or tiles
• Sorting and grouping practices
• Memory aides
For each icon, there are three primary elements:
• The shape and color of the outline of the icon, e.g., square, triangular, which denotes
the capability area associated with the practice area
• Within the shape, a unique pictorial icon representing the intent of the practice area
• The acronym for the practice area
For example, Figure 15 is the icon for Decision Analysis and Resolution (DAR), included in the
Supporting Implementation Capability Area. For more information about Capability Areas, refer
to Appendix A.
29
Figure 15. Example Icon, DAR
Figure 16 shows the complete set of relationships between the categories, current and
planned Capability Areas, and Practice Areas. Current Capability Areas and Practice Areas are in
color, while planned or potential Capability Areas and Practice Areas are in gray. This serves as
a high-level quick reference for the current and future planned content of the CMMI model.
Note: Future planned or potential Capability Areas and Practice Areas are in gray. CMMI
Development is shown last.
Figure 16. Model Content Relationships
30
31
32
CMMI Development
For more information on the categories and current and future Capability Areas and Practice
Areas, refer to Appendix A.
Explanatory vs. Context Specific

The model does not imply any specific methodology, work product type, or implementation and
is not a recipe or a “one size fits all” checklist. The model is not a set of implementable
33
processes. This means that each project or organization must understand how to implement
their processes to address their unique situation. Organizations with different disciplines,
different business activities, and different organizational structures or sizes should apply the
model practices within their own contexts. Practice statements are designed and written to be
clear, unambiguous, and applicable to any context. The informative material, including the
context specific sections, helps with this understanding, and must not be ignored.
Within the CMMI model there are two types of informative material: “explanatory” and
“context specific”.
Separating content into “Explanatory” and “Context Specific”:
• Provides flexible and faster adoption for evolving:
o Industry-specific needs
o Market drivers
o Trends
o Technologies
• Keeps the model compact and easier to maintain
• Allows updates to the informative material without releasing a major version
The “Explanatory Information” section contains information describing a model component
and applies to all contexts. Explanatory information material aids users in understanding the
intent and business value of using the component. The example activities and work products
are neither prescriptive nor exhaustive. Consider other work products and activities that meet
the intent of the practice when implementing processes. The core template covers six areas of
information:
• Additional explanatory information
• Example activities
• Work product examples and definitions, attributes, or types of things to include in the
work product content, e.g., a plan would include strategy, resources, schedule
• Related Practice Areas
• External links or information, e.g., training, templates, example assets
The “Context Specific” section contains information that is relevant to a context and
establishes common ground for a specific industry, methodology, or discipline. The context
specific information mirrors the structure of the required and explanatory information, including
links to additional informative material. It includes the:
• Context specific identifier and description
• Context specific explanation
• Intent and value of the context specific information as it relates to the practice, as
needed
• Example activities in addition to those listed in the explanatory information material, as
needed
• Context specific work product examples and definitions, attributes, or type of things to
include in the work product content in this context, as needed
• External links or information, e.g., training, templates, example assets
Examples of contexts may include:
• Development
34
• Services
• Supplier Management
• Security
• Safety
• People Management
Additionally, the architecture supports adding other context specific informative material,
including implementation guidance for domains such as:
• Information Technology
• Cybersecurity
• Healthcare, e.g., medical devices, pharmaceuticals, healthcare providers
• Telecommunications
• Aerospace
• Finance
• Transportation
• Education
• Government
• Hospitality
• Consulting
The architecture also works with, supports, and improves other methodologies, standards, or
models such as:
• Agile with Scrum
• DevOps
• Kanban
• Lean
• COBIT
• ISO
• AS9100
• Automotive SPICE
• ITIL
35
Part Two: Successfully Adopting CMMI
First and foremost, align performance improvement with the organization’s business strategies
and objectives. The CMMI is best used to address challenges an organization is encountering
and to continuously improve organizational performance in areas that are most important to
them and their customers.
Elevating Performance through Process Improvement

It is important to understand the organization’s current level of performance, and how that
meets the current business needs and objectives. If the performance is not meeting business
needs and objectives, then use process improvement to raise performance to the needed level.
Address performance at all levels in the business and use it as a key driver for process changes.
Focusing primarily on business benefits and performance drives process improvement to better
serve the needs of the business and ultimately the customer. Because of this, an effective and
sustainable improvement program needs to be in place, focused on performance, and actively
supported.
The root of process improvement is to instill discipline in the organization’s culture. This
includes the way work is perceived, done, and improved. Figure 17 shows the four stages of
process discipline that organizations typically go through when implementing process
improvement. As the organization progresses through the stages, process capability and
maturity increase, leading to improved performance.
36
Figure 17. Four Stages of Process Discipline
Stage one, process execution is ad hoc and undisciplined. Individuals follow their own,
unrecorded processes which result in varied outcomes and prevent systemic organizational
learning. The need for performance improvement is recognized, but the ability to improve is
limited and is only achieved unintentionally.
Stage two, there is conscious realization that processes are ad hoc and unrecorded, limiting
both consistency of execution and the organization’s ability to improve its performance and
processes.
Stage three, record processes and establish mechanisms to ensure fidelity of process execution.
Organizational support structures, including consistent senior management oversight,
encourage the continued use of the processes and associated improvements.
Stage four is achieved when the processes and performance are clearly understood, followed,
and persistent and habitual (see Part Three: Process Persistence and Habit). Keys to
performance and process improvement are to:
• Demonstrate visible and active senior management support
Continued and consistent senior management sponsorship is critical to success. Without
constant vigilance, positive pressure, and active support by senior management,
performance and process improvement fails. Though providing funding is important, it is
not enough. Because senior management’s most valuable resource is time, people
notice where and how management spend their time and act accordingly. In other
words, if senior management demonstrates they do not pay attention, no one else will.
37
• Involve the people who do the work

The people who perform a task need to be involved in describing and recording the
process so it reflects how the work is actually performed. This makes it more likely that
the process is followed and becomes the normal way work is done. If people are not
involved, they typically resist the process and fail to follow it. Active involvement in both
the process and its ongoing improvement leads to pride of ownership and active
support.
• Record the “As Is” first
When recording processes, resist the temptation to record what you think you should be
doing and focus on recording what is currently being done, i.e., the “as is” process. Also,
resist the temptation to improve the process as you record it. Record potential
improvements in a consistent way, so they can be analyzed, prioritized, and addressed
later as a part of the normal improvement process to ensure they positively impact
performance.
• Focus on meeting business objectives
Performance and process improvement initiatives must support the organization’s
business objectives. If an improvement does not trace to the business objectives,
carefully consider whether to implement it. Additionally, align the improvement priorities
with the organization’s priorities. Without this, support for the initiatives dissipates.
• Communicate, communicate, communicate
In employee satisfaction surveys, lack of communication is typically the number one
issue. People want to know planned changes, how management supports these
changes, and how the change affects them. Expect that people are naturally resistant to
change and tend to go back to what is comfortable. Clear, consistent, and frequent
communication reduces the anxiety that people experience with change. Studies show
that a message must be given multiple times in multiple ways to ensure that it is
received and acted on by at least 90% of the people.
Items that communication should cover include:
o What is changed?
o What is not changed?
o Why it is being changed, e.g., benefits and impacts, and business objectives driving
the change?
o What help is available, e.g., training, mentoring, support materials?
o How can people contribute to success?
o How is success measured?
o What methods are available for providing positive and negative feedback for
improvement?
• Establish a clear improvement infrastructure
The organization needs to ensure funding, resources, tools, training, and support are in
place to manage and champion performance and process improvement. This includes
people with appropriate skills and experience, along with clear responsibility, authority,
and accountability. This follows the management proverb that if no one is explicitly
responsible, then nothing gets done. This function can be a part time assignment for an
38
individual in a small organization, to one or more full-time groups of individuals in a

larger organization.
• Target the right level of detail
“Do not let perfect be the enemy of good enough.” Process documents need to be at
the right level of detail. Focus on performance and process improvement, not
implementing and deploying the perfect process. Know when you have reached the
“good enough” and then start improving as it is used. When recording processes:
o Determine the appropriate level of process control
o Recognize that not every eventuality can be anticipated
o Realize that if the process is too prescriptive, it impacts adoption, and if it is written
too high level, the processes have little value
o Target an 80% solution to record a process, and then rely on continuous
improvement to address the remaining 20% of issues
• Plan and provide training
Upgraded skills are vital for supporting new behaviors and reinforcing desired behaviors.
Training should, at a minimum, cover the full scope of processes and tools for
individuals doing the work.
Providing just-in-time training is also a best practice to ensure that training supports
effective process implementation.
There are many ways to provide effective training:
o Classroom training
o Mentoring
o Formal on-the-job training
o Process walkthrough
o Brown bag lunches
o Virtual or elearning
• Measure to achieve business results
Put more simply, “That which is measured is performed.” Remember that measuring
requires investment, so make sure there is a reason for every measure that is collected
and that it provides business value and performance improvement. Make sure people
understand why to collect measures and how they are useful to the project and the
organization. Measurements drive behavior. Be cautious of “measurement for
measurement sake”, and prioritize more analysis over more measures. Do not use
process measures to evaluate people for either reward or punishment. If they are,
people learn to make the measurement system work for them, adversely affecting data
quality.
• Reinforce good behavior
Modifying behaviors requires consistent reinforcement. Plan how to reinforce new
behaviors and how to address resistance. Positive reinforcement, e.g., rewarding people,
is typically more effective than negative reinforcement, e.g., punishing people. Base
rewards on merit and performance and not personal relationships.
Techniques to address resistance include:
39
o Rewarding desired behaviors

o Coaching or mentoring
o Training
• Manage stakeholder expectations
People tend to forget performance and process improvements often have a broad
impact across the organization and people beyond the immediate problem. Manage the
expectations and effects of the changes with internal or external customers and
suppliers. As the organization implements performance improvements, remember to
inform and educate your customers, suppliers, and other stakeholders.
• Plan for differences
There are right ways to implement process changes and more than a few wrong ways.
The success of performance and process improvement depends on organizational
context. What works well in one situation may be counterproductive in another.
Processes and changes must allow for differences in an organization and fit the culture.
For example, processes that work well in a development part of an organization may not
work very well or at all in a pure research part of the organization, even though they are
both in the same organization. Consider cultural differences for geographical dispersed
organizations. A litmus test to determine if a process improvement is effective is
whether it is providing value to the organization.
• Recognize change can overwhelm
People can only absorb so much change at one time. Introducing too much change
simultaneously, results in uneven adoption and some of the changes do not evolve into
habit. Implementing multiple changes at the same time makes it difficult to determine
which change was effective. Allow time to internalize the change and make it habitual.
Since it takes time to adopt new behaviors, process discipline can be fragile, especially
in times of stress.
40
Part Three: Process Persistence and Habit
In the CMMI model, the term “persistent and habitual” describes the routine way of doing
business and following and improving processes that an organization uses as part of its
corporate culture:
• Persistence: Firm or stubborn continuance in a course of action despite difficulty or
opposition
• Habit: A tendency or practice, especially one that is hard to give up
If a process is ignored, abandoned under pressure, or if disciplined execution of the process
erodes over time, then it is neither persistent nor habitual.
When an organization begins a performance improvement initiative, the goal is for the
improvements to last and become the “way we do business”. In other words, the organization is
forming new habits. Once established, a “new habit” becomes very difficult to break and is
persistent. Figure 18 describes the four key characteristics to understanding and creating
persistent and habitual practices within an organization.
Figure 18. Four Characteristics of Process Persistence and Habit
If people continue to consciously follow the process for several iterations, they ultimately
transition to the point where they are unconsciously following the process. They no longer need
to think about it; it is simply the way business is done in the organization. At this point the
processes have become persistent and habitual. Mentor newcomers to the organization until
they habitually follow the process. Even at higher levels of maturity, when introducing an
41
improvement, the organization can regress and must consciously establish the new or modified
habit to achieve performance and improve capability.
Sustaining Habit and Persistence

In the CMMI model, the Practice Areas in the Sustaining Habit and Persistence (SHP)
Capability Area enable a persistent and habitual organizational culture. The SHP practices
apply to the processes the organization develops and uses and NOT to the CMMI
practices.
SHP practices address organizational persistence and habit from two different perspectives:
• Governance (GOV)
• Implementation Infrastructure (II)
Governance
This Practice Area contains practices senior management performs to promote the way work is
accomplished that is relevant and important to the business and to the organization.
Visible and active management involvement is critical to the success of performance
improvement and process implementation in an organization. Management accomplishes their
role by:
• Setting the strategy, direction, and expectations for performance improvement
• Ensuring that processes are aligned with business needs and objectives
• Monitoring the performance and achievements of the processes
• Providing adequate resources for process and performance improvement
• Reinforcing and rewarding the development and use of processes to ensure their
continued use and improvement
The GOV practices are applied to processes, and their implementation and
improvement, not to CMMI model practices.
Implementation Infrastructure
This Practice Area describes the necessary infrastructure to build, follow, sustain, and improve
processes over time. The term “infrastructure” in this Practice Area refers to everything needed
to implement, perform, and sustain the organization’s set of processes. The infrastructure
includes:
• Process descriptions
• Resource availability aligned to needs, e.g., people, tools, consumables, facilities, time
to perform
• Funding to perform the processes
• Training to perform the process activities relevant to assigned responsibilities
• Objective process evaluations to ensure that work is performed as intended
Without an infrastructure, processes may not be followed, sustained, or improved over time.
Process descriptions should be clear and concise, and not require a significant amount of
administration. Process descriptions typically contain basic information about:
• Purpose – value
42
• Entrance criteria – when to start

• Activities – what to do
• Inputs and outputs – what the activities use and produce
• Exit criteria – when the process is done, and value achieved
The II practices are applied to processes, and their implementation and
improvement, not to CMMI model practices.
43
Part Four: Achieving High Maturity
In the CMMI product suite, the term “High Maturity” involves the use of statistical and other
quantitative techniques on selected processes. High Maturity represents a fundamental shift in
process understanding, management, and improvement. As organizations move up in process
maturity, they gain in-depth understanding of how processes are used and interact, which gives
them a clear competitive advantage. High Maturity organizations demonstrate a deeper
commitment to improving capabilities with a focus on continuous performance improvement.
High Maturity organizations can consistently and predictively lower their delivery risk while
increasing the quality of their solutions. The higher the organization’s maturity level, the better
its performance. High Maturity organizations anticipate and predict change and constantly
evolve, enabling them to rapidly pivot and respond to opportunities.
High Maturity organizations:
• Establish quantitative objectives for quality and process performance based on their
business objectives
• Have a clear, quantitative understanding of performance and process improvement
return on investment (ROI)
• Make data driven decisions
• Systematically analyze variation and understand its impact on quality and performance,
providing quantitative insight into risk
• Achieve key performance objectives more effectively
• Clearly understand process stability and capability and use them properly to manage
projects and improve process performance
• Increase predictability
• Increase schedule and cost performance
• Increase ability and probability of achieving goals and objectives
• Reduce rework
• Focus on innovation and being more competitive
• Have greater confidence in measurement indicators
Figure 19 shows some of the key differences in how processes and objectives are understood
and managed between Maturity Levels 2 and 3 and at Maturity Levels 4 and 5.
44
Figure 19. Maturity Levels 2 & 3 vs. 4 & 5
45
Impacts of poor data quality:

• Inability to conduct hypothesis tests and predictive modeling
• Inability to manage quality and performance
• Inability to meet budget and schedule
• Ineffective process changes instead of process performance improvement
• Improper architecture and design decisions drive up the lifecycle cost and reduce the
useful life of the solution
• Bad information leads to bad decisions
High Maturity organizations:
• Collect, validate, and use data with high quality and integrity throughout the
organization
• Use statistical and quantitative methods in their activities to plan and manage progress
against their objectives
• Provide insight into the operation of an organization and its processes based on data
and statistical analyses
• Use the measurement system to understand process performance and variation to:
o Construct process performance baselines to manage projects
o Target areas for improvement
o Evaluate the impact of proposed improvement on achieving quality and process
performance objectives
o Develop process performance baselines and models to understand the
relationships among processes and sub-processes and their performance
46
• Systematically and simultaneously improve quality, schedule, and cost performance with
an in-depth quantitative understanding of the tradeoffs
An example of the importance of High Maturity thinking:
• Based upon past performance, the organization uses a data distribution to show how
long it takes to deliver similar features
• A customer would like a feature added in 10 weeks and historical delivery time of
similar features is 9 to 11 weeks
• Determining to accept the work depends on the data distribution shown in Figure 20:
o If the distribution is represented by the left chart, most of the time the feature
will be delivered in ten weeks or m ore
o If the distribution is represented by the right chart, most of the time the feature
will be delivered in less than ten weeks
Figure 20. Using High Maturity to Determine if Work Should be Accepted
In High Maturity, a statistic is a measure of variation. This includes:

• Summary or characterization of a distribution, e.g., set of numbers
• Characterization of a central tendency, e.g. mean, median, and mode
• Characterization of dispersion, e.g., variance, standard deviation, and range
High Maturity organizations understand the balance between stability and change. They have
the capability to:
• Predict impacts of a change to performance and process and the ROI of the change
• Measure and determine effects of the change
Figure 21 below illustrates that improvements can shift the mean, reduce variation, or both.
Understanding the average and the amount of variation give you two different insights into
process performance.
47
Figure 21. Two Approaches to Improvement
48
Practice Areas
Part Five: Practice Areas
49
Causal Analysis and Resolution (CAR)
Required PA Information
Intent
Identify causes of selected outcomes and take action to either prevent recurrence of
undesirable outcomes or ensure recurrence of positive outcomes.
Value
Addressing root cause issues eliminates rework and directly improves quality and productivity.
Additional Required PA Information
This section left blank for future content.
Explanatory PA Information
Practice Summary
Level 1
CAR 1.1 Identify and address causes of selected outcomes.
Level 2
CAR 2.1 Select outcomes for analysis.
CAR 2.2 Analyze and address causes of outcomes.
Level 3
CAR 3.1 Determine root causes of selected outcomes by following an
organizational process.
CAR 3.2 Propose actions to address identified root causes.
CAR 3.3 Implement selected action proposals.
CAR 3.4 Record root cause analysis and resolution data.
CAR 3.5 Submit improvement proposals for changes proven to be effective.
Level 4
CAR 4.1 Perform root cause analysis of selected outcomes using statistical and
other quantitative techniques.
CAR 4.2 Evaluate the effect of implemented actions on process performance using
statistical and other quantitative techniques.
Level 5
CAR 5.1 Use statistical and other quantitative techniques to evaluate other
solutions and processes to determine if the resolution should be applied
on a broader scale.
50
Additional PA Explanatory Information

Causal analysis and resolution involves:
• Determining root causes of selected outcomes
• Proposing actions to address identified root causes
• Implementing selected action proposals
• Recording causal analysis and resolution data
• Submitting improvement proposals for changes proven to be effective
It is more cost-effective to prevent defects and problems from occurring than to detect defects
and problems after they have been introduced.
Since it is impractical to perform causal analysis on all outcomes, select targets by analyzing
tradeoffs between estimated investments and returns. Causal analysis and resolution activities
provide a mechanism for projects and the organization to evaluate their processes and look for
improvements that can be implemented. When improvements are judged to be effective,
following the processes that guide them, the information is submitted to the organizational level
for potential deployment in the organizational processes.
Related Practice Areas
Managing Performance and Measurement (MPM)
Context Specific
Agile with Scrum Guidance
Context Tag: Agile with Scrum
Context: Use processes to adapt agile with Scrum techniques.
Agile teams collect impediment and retrospective data during each iteration. A typical agile
implementation expects a team to address impediments, and selectively implement
improvements based on retrospective data.
An agile team employing causal analysis and resolution would organize this information, select
outcomes to analyze, identify causes, and implement selected improvements.
For example, a team that is consistently unable to complete the work defined for each sprint
would look for various causes, such as chronic distractions, using unreliable velocity data,
poorly defined user stories, exceeding team capacity, or underestimating complexity. The
underlying causes would be identified, ranked, and addressed.
Supplier Management
Context Tag: CMMI-SPM
Context: Use processes to identify, select, and manage suppliers and their agreements.
Causal analysis and resolution activities may include evaluating acquirer processes that interface
or connect with supplier processes. When acquirers and suppliers jointly perform causal
analysis, it can lead to improvement actions such as:
51
• Supplier improving its processes to conduct the project more effectively

• Acquirer improving its supplier interfaces or connections
• Changes in jointly used tools or technologies
52
Level 1
CAR 1.1
Required Practice Information
Practice Statement
Identify and address causes of selected outcomes.
Value
Helps to achieve business objectives.
Additional Required Information
Explanatory Practice Information
Additional Explanatory Information
Outcomes can be either positive or negative. Significant differences from what was expected
indicate where the project can improve its performance by:
• Determining why it went well and how to change to incorporate the experience into the
normal behavior
• Determining why expectations were not met and the changes needed to meet them
Example Activities
Example Activities Further Explanation
Select outcomes that differed from
expectation.
Investigate causes of outcomes.
Address causes and record changes
made to address the causes.
Example Work Products

Example Work Products Further Explanation
List of investigated outcomes May include:
• Outcomes
• Causes
• Changes made
53
Level 2
CAR 2.1
Practice Statement
Select outcomes for analysis.
Value
Focuses efforts on the outcomes with the greatest impact on achieving objectives.
This activity can be triggered by an event or planned periodically, such as at the beginning of a
new phase, iteration, or task.
Examples of when to perform causal analysis include:
• During the task when problems or successes warrant a causal analysis
• When a work product significantly deviates from its requirements
• When more defects than anticipated escape from earlier phases
• When process performance exceeds expectations
• When a process does not meet its quality and process performance objectives
Example Activities
Define the scope of the analysis. The scope should include the:
• Definition of issue or success
• Affected stakeholders
• Affected target
Collect relevant data.
Determine which outcomes to analyze When determining which outcomes to analyze further,
further. consider their:
• Source
• Impact
• Frequency of occurrence
• Similarity
• Cost of analysis
• Time and resources needed
• Safety considerations
• Security considerations
• Performance
Examples of methods for selecting outcomes include:
54

• Pareto analysis
• Histograms
• Box and whisker plots for attributes
• Failure modes and effects analysis (FMEA)
• Design of experiment
• Cause and effect analysis

Analysis results The results of high-level analysis selected for more detailed
causal analysis.
Outcomes selected for further analysis
CAR 2.2
Practice Statement
Analyze and address causes of outcomes.
Value
Reduces cost and time to more efficiently meet objectives.
Causal analysis of selected issues is best performed shortly after the problem is first identified,
while the event is still recent enough to be carefully investigated.
The formality of and effort required for causal analysis can vary greatly and can be determined
by factors including:
• Stakeholders who perform the work
• Risks
• Complexity
• Frequency
• Availability of data
• Available resources
55
Example Activities
Identify the affected stakeholders and Causal analysis is typically performed by those who have the
involve them. best understanding of the selected outcome and who are
responsible for performing the task.
Perform causal analysis.
Identify and analyze potential issues or
successes.
Implement selected actions.
Assess the impact of the actions on
performance.
Communicate results.

List of affected stakeholders
Identified causes These are the results of analyzing potential issues and
outcomes.
Actions to take Action lists may include potential:
• Cost and schedule impacts
• Performance impacts
56
Level 3
CAR 3.1
Practice Statement
Determine root causes of selected outcomes by following an organizational process.
Value
Increases likelihood of meeting objectives by promoting successes and avoiding problems.
A root cause is a fundamental reason for the occurrence of a problem or success. Root cause
analysis can include qualitative and basic measurement data.
Example Activities
Identify and involve stakeholders.
Collect data.
Follow an organizational process to Consider looking at individual outcomes as well as grouping
perform a root cause analysis. the outcomes.
Negative outcomes can be influenced by:
• Inadequate training and skills
• Breakdown of communication
• Not accounting for all details of a task
• Making mistakes in manual procedures, e.g., keyboard
entry
• Process deficiency
• Inadequate resource allocation
• Incomplete, ambiguous, or unclear contractual
requirements
• Ineffective management of changes to the supplier
agreement
Positive outcomes can be influenced by:
• New approaches to projects
• Process automation
• System or tool upgrades
• Pilots
• Process improvements
• Performance improvements
Examples of methods to determine causes include:
• Cause-and-effect (fishbone) diagrams
• Check sheets
57

• 5 Whys
If possible based on the scope, look at the outcomes in
several ways to ensure all potential root causes are
investigated. Where appropriate, look for patterns of root
causes across functions.
Record root causes.

List of root causes Should include selected outcomes and analysis results.
List of affected stakeholders
CAR 3.2
Practice Statement
Propose actions to address identified root causes.
Value
Reduces cost and time by preventing negative outcomes or producing positive outcomes.
Based on the analysis results, develop action proposals that will address selected outcomes in
accordance with an organizational process. These action proposals address the removal of root
causes so that they do not recur.
Example Activities
Develop an action proposal. Action proposals may include:
• Identified processes
• Training
• Tools
• Methods
• Solutions
Common ways to address underlying causes include:
• Changing a process to remove error-prone steps
• Updating a process based on previous successes
• Deploying the results of successful pilots
58

• Eliminating non-value-added tasks
• Automating all or part of a process
• Reordering process activities
• Adding process steps, such as task kickoff meetings, to
review common problems and actions to prevent them
Record action proposals.

Action proposals Should include the:
• Originator of the action proposal
• Description of necessary tasks
• Description of the outcome to be addressed
• Description of the root cause
• Root causes and actions categories
• Phase identified
• Description of the action
• Time, cost, and other resources required to implement the
action proposal
• Expected benefits from implementing the action proposal
• Estimated cost of not fixing the problem or leveraging the
success
CAR 3.3
Practice Statement
Implement selected action proposals.
Value
Implements changes that have the most impact on increasing the likelihood of meeting
objectives.
These actions should prevent or reduce the occurrence of negative outcomes or increase the
occurrence of positive outcomes.
59
Example Activities
Analyze action proposals and Criteria for prioritizing action proposals include:
determine their priorities. • Implications of not addressing the outcome
• Cost to implement actions to address the outcome
• Risk implications
• Expected impact on quality
Select action proposals to be Include criteria to be used for deciding which action
implemented. proposals to implement.
Develop action plans for implementing Action plans should include:
the selected action proposals. • People responsible for implementation
• Detailed description of the action
• Description of necessary tasks
• Description of the affected areas
• Schedule
• Cost expected
• Estimated cost of not addressing the issue
• Description of implementation actions
• Expected impact on performance
• Identified needed pilots
Implement action plans. To implement action plans:
• Update the processes
• Review the results
• Track action items to closure
Actions may be assigned to members of the causal analysis
team, members of the project team, or other members of
the organization.
Look for similar root causes that may
exist in other processes and solutions
and take action as appropriate.

Action proposals selected for
implementation
Action plans
Updated process assets

Decision Analysis and Resolution (DAR)
Process Asset Development (PAD)
60
CAR 3.4
Practice Statement
Record root cause analysis and resolution data.
Value
Recording and communicating improvement efforts across the organization can leverage
savings and increase productivity.
Collect data to know that you are:
• Improving project performance
• Preventing selected problems from recurring
• Leveraging superior performance
• Providing sufficient context for future use
Example Activities
Record root cause analysis data and Root cause analysis in this practice involves the use of
make the data available for use. qualitative and basic measurement data analysis.

Root cause analysis and resolution May include:
records • Data on outcomes that were analyzed
• Rationale for decisions
• Action proposals
• Action plans resulting from action proposals
• Cost of analysis and resolution activities
• Measures of changes to the process performance of the
recorded process
CAR 3.5
Practice Statement
Submit improvement proposals for changes proven to be effective.
61
Value
Projects across the organization can take advantage of the savings and increased productivity.
Ensure that other projects in the organization can benefit from the improvements.
Example Activities
Submit improvement proposals May include:
• Areas that were analyzed including their context
• Solution selection decisions made including the context of
their solution
• Actions selected including trade-off contexts evaluated
• Monitoring tasks including unintended side effects
• Results achieved including performance information with
context, even if expected outcome is not fully achieved by
the solution

Improvement proposals

Process Management (PCM)
62
Level 4
CAR 4.1
Practice Statement
Perform root cause analysis of selected outcomes using statistical and other quantitative
techniques.
Value
Improves the likelihood that the project will meet its quality and process performance
objectives.
Using results from statistical and quantitative techniques, evaluate, select, and implement
action plans and measure results.
Root cause analysis in this practice adds statistical and quantitative analysis to qualitative and
basic measurement data analysis.
Address outcomes including deficiencies in process stability and capability, deficiencies in
performance relative to its objectives, and unexpectedly positive results.
Root cause analysis typically depends on the availability of data, baselines, and models that can
be used in the analysis. Actions to take can range significantly in terms of effort and time
needed to determine, plan, and implement. It is difficult to know how much time is needed
without an initial analysis of the deficiencies.
Example Activities
Perform root cause analysis. To understand the impact on stability and capability and to
determine the reasons for positive and negative outcomes.
Process performance baselines and models are used in:
• Diagnosing deficiencies
• Diagnosing positive outcomes
• Identifying possible solutions
• Predicting future work and process performance
• Evaluating potential actions
Identify and analyze potential actions.
Identify measures of effectiveness.
Implement selected actions. Update solutions or processes.
63

Process and project performance Should include:
analyses • Statistical and quantitative analysis
• Data visualization used to understand process and project
performance and trends
Identified root causes
Identified measures of effectiveness May include:
• Impact on performance
• Impact on meeting quality and process performance
objectives
• Impact on stability and capability
Action plans Include changes to solutions or processes.
Updated solutions or processes
Related Practice Area

CAR 4.2
Practice Statement
Evaluate the effect of implemented actions on process performance using statistical and other
quantitative techniques.
Value
Maximizes the likelihood of meeting quality and process performance objectives.
Evaluate the effect of changes to verify that the process change is statistically significant.
Example Activities
Measure and analyze the change in Determines if the selected change has positively influenced
process performance of the project’s process performance.
effected processes. Statistical and other quantitative techniques, e.g., hypothesis
testing can be used to compare the before and after
baselines to assess the statistical significance of the change.
64

Determine the impacts of the change Determines whether the selected change has positively
on achieving the project’s quality and influenced the ability of the project to meet its quality and
process performance objectives. process performance objectives. Process performance
models can aid in the evaluation through prediction of
impacts and return on investment.
Submit process improvement proposals
for the organization when the
implemented actions are effective.

Analysis of change in process performance
Organizational improvement proposals
Related Practice Area

65
Level 5
CAR 5.1
Practice Statement
Use statistical and other quantitative techniques to evaluate other solutions and processes to
determine if the resolution should be applied on a broader scale.
Value
Leverages improvements across the organization to minimize cost and risk.
The intent of this practice is to learn from root cause analysis and determine if resolutions from
historical projects and solutions can be applied to other projects, processes, and solutions in the
organization.
Example Activities
Identify similar processes or solutions.
Analyze to determine candidates for change
and prioritize them.
Apply changes to selected processes or
solutions and communicate results.

Identified candidate processes and solutions
Results of changes
66
Configuration Management (CM)
Intent
Manage the integrity of work products using configuration identification, version control, change
control, and audits.
Value
Reduces loss of work and increases the ability to deliver the correct version of the solution to
the customer.
Practice Summary
Level 1
CM 1.1 Perform version control.
Level 2
CM 2.1 Identify items to be placed under configuration management.
CM 2.2 Develop, keep updated, and use a configuration and change
management system.
CM 2.3 Develop or release baselines for internal use or for delivery to the
customer.
CM 2.4 Manage changes to the items under configuration management.
CM 2.5 Develop, keep updated, and use records describing items under
configuration management.
CM 2.6 Perform configuration audits to maintain the integrity of configuration
baselines, changes, and content of the configuration management
system.
Planning for configuration management activities includes controlling work products developed
or modified by the project.
The work products placed under configuration management include:
• Deliverables to the customer
• Work products provided by the customer
• Designated internal work products, including:
67
o Solution-related components
o Support components, e.g., procedures
• Acquired solutions
• Systems or tools
Baselines represent an approved version of a work product and provide a clear and accurate
understanding for future use. Add new baselines to the configuration management system.
Systematically monitor and control changes to baselines and work products using:
• Configuration identification
• Configuration control
• Change management
• Configuration auditing functions of configuration management
Verification and Validation (VV)
Context Specific
Figure CM-1 shows where configuration management would typically be performed in an agile
project using Scrum. Control might vary from versioning and backup for retrospective data, to
read-only access for production code. Configuration Management processes should be used to
augment an agile with Scrum implementation to maintain the integrity of work products and
deliverables. In an agile project using Scrum, the definition of “done” is also a term that the
team will typically discuss and decide when conducting sprint planning, reviews, and
retrospectives, so that the entire team agrees on the criteria for knowing when the work
product or solution is complete. Understanding the definition of “done” is important to being
able to verify and validate that the correct versions are produced and delivered from each
sprint.
68
Figure CM-1: CM in an Agile Framework
Figure CM-2: Typical Configuration Items Placed Under Selected Levels of

Control
69
Figure CM-2 shows the typical agile with Scrum work products that would be placed under
selected levels of configuration control. An agile team can leverage existing change
management practices as a part of its configuration management implementation, such as
managing changes to the backlog before each sprint. Configuration management processes
should be used to track the various backlog versions and the ripple effects to design
information, code, test cases, and test results.
Context Specific
Development
Context Tag: CMMI-DEV
Context: Use processes to develop quality products and services to meet the needs of
customers and end users.
Examples of work products that can be placed under configuration management may include:
• Hardware and equipment
• Drawings, diagrams, and mockups
• Product specifications
• Tool configurations
• Code and libraries
• Compilers
• Test tools and test scripts
• Installation logs
• Product data files
• Product technical publications
• Plans
• User stories
• Iteration backlogs
• Requirements
• Architecture documentation and design data
• Product line plans, processes, and core assets
An example of a baseline is an approved description of a product that includes internally
consistent versions of requirements, requirement traceability matrices, design, discipline-specific
items, and installation, end user, and operations documentation.
For product lines, apply configuration management across the products in the product line and
across multiple versions of core assets and products. (See the definition of “product line” in the
glossary.)
70
Level 1
CM 1.1
Practice Statement
Perform version control.
Value
Increases customer satisfaction by ensuring that the correct solution is delivered.
Identify the correct versions of work products. This ensures the right versions are available for
use or for restoring to a previous version.
Example Activities
List the work products to be placed Include all versions and other relevant information, e.g.,
under version control and keep it location, ownership.
updated.
Control versions.

List of work products and their versions
71
Level 2
CM 2.1
Practice Statement
Identify items to be placed under configuration management.
Value
Reduces risk of rework and ensures that the right version is delivered to the customer.
Based on criteria established during planning, identify configuration items that need to be
controlled, managed, and accessed. Logical groupings provide ease of identification and
controlled access. Identification typically includes:
• Logical groupings of work products such as:
o Solutions delivered to the customer
o Designated internal work products
o Acquired solutions
o Tools, equipment, and other assets of the project’s environment
o Solution documentation and other support materials
• Why and how they are grouped
• How they are controlled, managed, and accessed
Example Activities
Assign unique identifiers to
configuration items.
Describe the important characteristics
for each configuration item.
Specify when each item is placed Describe the nature and timing of changes and when and
under configuration management. how they may affect the work products or solutions at each
stage.

Identified configuration items Characteristics may include:
• Owner or author
• Type of work product or solution
72

• Key features
• Purpose of the item
• Relationships to other items and solutions
• Retention
• Version
• Security
CM 2.2
Practice Statement
Develop, keep updated, and use a configuration and change management system.
Value
Reduces the cost and effort needed to control the integrity of work products and solutions.
Enables consistent and controlled access to work products and solutions and provides the ability
to restore a previous version, configuration, or baseline.
A configuration management system:
• May include both manual or automated methods, tools, or complete systems to control
work products and solutions
• May be embedded or integrated with other tools to produce work products and solutions
• Includes the procedures for accessing the system
The change management system:
• Provides a means for controlling changes to the identified configuration items
• Includes the storage media, procedures, and tools for recording and accessing change
requests
• Is typically integrated with a configuration management system
Example Activities
Describe how the items and changes to
them are controlled, used, and
managed throughout the solution
lifecycle.
73

Establish methods to manage multiple The level of control is typically selected based on work
levels of control. objectives, risk, type, and resources.
Example levels of control include:
• Uncontrolled: Anyone can make changes
• Version controlled: Authors or owners control changes
• Baselined: A designated authority authorizes and controls
changes, and notifies affected stakeholders
Provide access control to ensure
authorized access to the configuration
management system.
Store and retrieve configuration items Typically, storage and retrieval functions in a configuration
in the configuration management management system include a check-in and check-out
system. function.
Preserve the contents of the Examples of preservation functions of the configuration
configuration management system. management system may include:
• Backup and restoration of configuration management
items, e.g., files, physical artifacts
• Archive of configuration management files
• Recovery from configuration management errors
• Keeping previous versions according to retention rules
Update the configuration management
system as necessary.

Configuration management system
Change management system
Updated configuration items
CM 2.3
Practice Statement
Develop or release baselines for internal use or for delivery to the customer.
Value
Ensures the integrity of the work products.
74

Baselines help to formally control changes by establishing points where the status of controlled
work products is known and approved. Use changes to develop the next baseline. Typically, a
board or a group of people, e.g., the work team, an approval group, or a Change or
Configuration Control Board (CCB), formally approves baselines and changes to baselines. The
composition of this board may change over time depending on the impacted work products and
affected stakeholders. For example, if the baselines or changes are security related, security
experts may be invited to the board.
Represent a baseline by assigning an identifier to a configuration item or a collection of
configuration items and associated entities at a point in time. As a solution evolves, multiple
baselines can exist.
Example Activities
Obtain authorization or approval before An approval group will typically assess the impact and
developing or releasing baselines of necessity of changes to configuration items.
configuration items.
Develop or release baselines only from
configuration items in the configuration
management system.
Record the set of configuration items
contained in a baseline.
Make the current set of baselines Only stakeholders with approved access should be able to
available. access the baseline information. Additionally, other
techniques such as: “build cop,” “don’t break the build,”
“release on demand,” “continuous integration,” and
“continuous delivery” may be used to manage and control
baselines.

Authorization Includes establishing the baselines and changes to them.
Baselines Contains the configuration items and the associated changes.
Multiple baselines can exist for a single configuration item.
Context Specific
Development
Include hardware, software, and documentation work products as appropriate in baselines.
75
One common set of baselines includes the system level requirements, system element level
design requirements, and the product definition at the end of development or beginning of
production. These baselines are typically referred to respectively as the functional baseline,
allocated baseline, and product baseline.
A software baseline can include:
• A unique identifier
• Version release notes
• A set of requirements
• Design
• Interfaces
• Source code files
• Executable code
• Test environments, test cases, etc.
• Build files
• User documentation, such as installation, operational, help, etc.
A hardware baseline can include:
• A unique identifier
• Version release notes
• A set of requirements
• Design
• Interfaces
• Drawings or schematics
• Prototypes, simulations, breadboards, etc.
• Parts and materials
• Test environment
• Build or manufacturing instructions
• User documentation, such as installation, operational, help, etc.
CM 2.4
Practice Statement
Manage changes to the items under configuration management.
Value
Reduces costs and schedule impacts by ensuring that only authorized changes are made.
76

Analyze change requests to determine their impact on the work product, related work products,
budget, and schedule.
Maintain control over the configuration of the work product baseline by:
• Tracking the configuration of each item
• Approving changes to items and baselines
• Approving new configurations and baselines
Example Activities
Initiate and record change requests. Typically includes:
• Changes to requirements
• Failures and defects in work products
• Needs from stakeholders, end users, and customers
• Description of the impact to work products and solutions
Analyze the impact of change requests. Analysis should consider impacts to:
• Technical and project requirements
• Impact beyond the immediate project or contract
requirements
• Impact on release plans
• Cost
• Schedule
• Quality
• Functionality
• Commitments
Categorize and prioritize change Typically includes:
requests. • Allowing for emergency changes
• Allocating changes to future baselines
Review and get agreement on change An approval board typically:
requests to be addressed in the next • Reviews changes
baseline with affected stakeholders. • Records the disposition of each change request and the
rationale for each decision
• Reports results to stakeholders
Track the status of change requests to
closure.
Incorporate changes in a manner that Examples of check-in and check-out include:
maintains integrity. • Confirming the revisions are authorized
• Updating the configuration items
• Maintaining versions of work products
77

• Archiving the replaced baseline and retrieving the new
baseline
• Commenting on the changes made
• Assigning changes to related work products
Perform reviews or testing to ensure Examples:
changes have not caused unintended • Automated unit test
impacts. • Regression testing
• Performance testing
Record changes to configuration items
and rationale.

Change requests Typically includes:
• Description of the change
• Category of change
• Priority of change
• Status of change
• Impact of change
• Estimated implementation time
• Actual implementation time
Results of change impact analysis
Approval board records
Revision history of configuration items
Results of reviews or tests for
unintended impacts
Revised work products and baselines
CM 2.5
Practice Statement
Develop, keep updated, and use records describing items under configuration management.
Value
Accurate descriptions of the configuration items and status of changes enables reduction of
rework.
78

Record the configuration actions and status to enable recovery to previous versions and to
understand the status of the item and the changes that were or are being made.
Example Activities
Record configuration management
actions in sufficient detail so the
content and status of each
configuration item is known and
previous versions can be recovered.
Ensure that affected stakeholders have Examples of activities for communicating configuration status
access to and knowledge of the include:
configuration status of configuration • Providing access permissions to authorized users
items. • Making baseline copies readily available to authorized
users
• Automatically alerting affected stakeholders when items
are checked-in, checked-out, or changed, and of decisions
made regarding change requests
Specify the differences among These are often referred to as release notes.
previous, related, and latest versions of
baselines.
Identify the version of configuration Also, identify the changes used to develop that baseline.
items that constitute a specific
baseline.
Revise the status and history, e.g.,
changes, of each configuration item as
necessary.

Revision history or change log of
configuration items
Change request records
Status of configuration items
Differences between baselines
79
CM 2.6
Practice Statement
Perform configuration audits to maintain the integrity of configuration baselines, changes, and
content of the configuration management system.
Value
Increases customer satisfaction and stakeholder acceptance by ensuring that the customer
receives the agreed-on and correct versions of work products and solutions.
Configuration audits confirm:
• Configuration management records and configuration items are complete, consistent,
and accurate
• Integrity of the baselines, change requests, and associated items
Example Activities
Assess the integrity of baselines and Examples include:
generate action items to address • Physical work product reviews verifying changes
identified issues. • Functional work product reviews verifying changes
• Comparison of approved changes versus actual changes
made in a work product
Confirm integrity of configuration Typically, this includes confirming:
management records. • Correctly identified configuration items
• The completeness, correctness, and consistency of items
Review the structure and integrity of
items in the configuration management
system.
Record action items and track them to
closure.

Configuration audit or review results Contains the objectives for and outcomes of audits in enough
detail to take action.
Action items Describes actions needed to address findings from audits and
the criteria needed to determine when they can be closed.
80
Continuity (CONT)
Intent
Plan mitigation activities for significant disruptions to business operations so that work can
continue or resume.
Value
Enables continued operation when serious disruptions or catastrophic events occur.
Practice Summary
Level 1
CONT 1.1 Develop contingency approaches for managing significant disruptions to
operations.
Level 2
CONT 2.1 Identify and prioritize functions essential for continuity.
CONT 2.2 Identify and prioritize resources essential for continuity.
CONT 2.3 Develop, keep updated, and follow continuity plans to resume performing
essential functions.
Level 3
CONT 3.1 Develop and keep updated materials for continuity training.
CONT 3.2 Provide and evaluate continuity training according to the plan.
CONT 3.3 Prepare, conduct, and analyze results from verification and validation of
the continuity plan.
Continuity builds on the risk-related practices in Risk and Opportunity Management. The
Continuity Practice Area is a specialization of risk management that focuses on dealing with
significant disruptions to normal operations. Continuity activities include preparing business
systems, people, and resources for disruptions in operations so that a minimum critical level of
operations can continue. Continuity planning includes identifying minimum essential functions
and resources, along with acceptable time limits for restoration of operations.
Continuity applies when an event or series of events, is so disruptive that it is impossible to
conduct business as usual.
81
Examples of significant disruptions include:

• Loss or damage to critical infrastructure, e.g., significant facilities or equipment
malfunctions, power loss, and building collapse
• Natural disasters, e.g., pandemics, hurricanes, tornados, wildfires, floods, and
earthquakes
• Human events, e.g., civil unrest and acts of terrorism
Organizations may only have a short period of time in which to recover and resume operations
when disrupted.
Continuity activities cover developing, testing, and maintaining a continuity plan. First, identify:
• Essential functions that support the work the organization delivers
• Required resources
• Potential hazards or threats to these resources
• Susceptibility of the organization to the effects of each hazard or threat
• Potential impact of each threat on continuity
Use this information to develop a continuity plan to enable the organization to resume essential
operations, potentially at a degraded level. Complete and repeat the following activities as
needed to develop the continuity plan:
• Develop continuity plans based on the information previously collected
• Develop tests to validate the continuity plan
• Develop training materials and training delivery methods to enable affected stakeholders
to perform activities in the continuity plan
Do not wait until an emergency occurs to perform the activities in continuity plans for the first
time. Continuity plans should be validated on a periodic basis.
Conduct periodic tests to determine:
• Effectiveness of continuity plans in an actual emergency or significant disruption
• Changes needed to restore and deliver operations reliably
Incident Resolution and Prevention (IRP)
Risk and Opportunity Management (RSK)
Level 1
CONT 1.1
Practice Statement
Develop contingency approaches for managing significant disruptions to operations.
82
Value
Enables an organization to respond to potential disruptive events or situations and continue to
meet customer needs.
Example Activities
Record contingency approaches. Provides the approach when significant disruptions to
operations occur.
Specify trigger values. Identify triggers that could lead to initiating the contingency
approaches. Trigger values help the project or organization
determine when they need to spend resources, time, money,
or effort on implementing the contingency approaches.

Records of contingency approaches Use to manage exceptional risks with possible catastrophic
consequences.
Trigger values
83
Level 2
CONT 2.1
Practice Statement
Identify and prioritize functions essential for continuity.
Value
Enables continued operation of essential functions during an emergency or significant
disruption.
Identify and prioritize essential functions, processes, and related activities that must continue
during and after an emergency or significant disruption. Develop an understanding of all
operations to identify essential functions. Many important activities are not essential functions.
Sustain essential functions in an emergency or through significant disruption to support
continued business survival.
Involve a wide range of stakeholders to develop the appropriate priorities.
Example Activities
Develop continuity scenarios. Considerations include:
• Scale of disruption
• Full versus limited operations
• Coordination with multiple authorities
• Emergency services
• Infrastructure
Identify the essential functions on Essential functions can include pre-scheduled or on-demand:
which operations rely. • Manual processes
• Automated processes
• End user activities
• Operational activities
• Solution delivery activities
Analyze the criticality and the impact to In situations where a limited number of functions are
operations if the project cannot essential, action planning may be simplistic. If none of the
perform the essential functions. functions are essential, the course of action might be to
resume operations when the emergency ends.
Prioritize the list of essential functions. Consider the impact of the duration for the disruption, i.e.,
long versus short disruption.
84

Prioritized list of critical functions
Business impact analyses

Planning (PLAN)
Requirements Development and Management (RDM)
CONT 2.2
Practice Statement
Identify and prioritize resources essential for continuity.
Value
Maintain customer satisfaction and continue business operation during an emergency or
significant disruption.
Identify and prioritize resources required to maintain essential functions. Essential resources are
those necessary for operations to continue or restart during and after an emergency. These
resources are typically unique and hard to replace. Essential resources include critical
competencies, personnel, assets, data, and systems. Protect essential resources; identify
suitable substitutes and establish data backups and archives.
Include essential external resources when identifying resources. This might include defining
succession plans in the event critical resources are incapacitated or otherwise not available
when needed. Other commonly overlooked resources include consumables and vital records,
e.g., documents describing legal or financial obligations.
Identify essential resources by analyzing the:
• Organization’s operations
• Functions essential to continuity
• Agreements and standard operational definitions
• Dependencies among system components, affected stakeholders, and the operational
environment
85
Common resource dependencies include:

• Internal and external information and data sources
• Key personnel who make decisions or are significant contributors to operations
Essential resources generally fall into one of the following categories:
• Emergency operating resources, e.g., key personnel, equipment, consumables,
necessary to resume disrupted operations
• Legal and financial resources, e.g., contractual documents, essential to protect the rights
and interests of the organization and individuals directly affected by the emergency
Example Activities
Identify and record internal and
external dependencies.
Identify and record key personnel and
their roles in providing continuing
operations.
Identify and record organizational and
affected stakeholder responsibilities.
Identify and record resources required
to ensure continuity of essential
functions.
Evaluate and prioritize resources based For some critical resources, it may be necessary to identify
on the impact of their loss or lack of succession orders.
access.
Develop safety provisions for
operations personnel.
Ensure needed records and databases
are protected, accessible, and usable in
an emergency.

Records of critical resources required May include:
for continuity • Delegations of authority
• Orders of succession
• Directory of critical personnel with contact information
• Data and systems required to support identified essential
functions
• Internal and external resource dependencies
Records of agreements and contracts Includes agreements for alternate locations for operations
during recovery.
Backup and recovery records of legal These records typically identify the organization as a legal
operation charters entity and are stored offsite. May include legal copies of:
• Articles of incorporation
86

• Authorizations by local, state, national government
agencies
• Business records
Backup and recovery records for These records include:
human resource data • Personnel benefit balances
• Payroll data
• Insurance records

Planning (PLAN)
CONT 2.3
Practice Statement
Develop, keep updated, and follow continuity plans to resume performing essential functions.
Value
Minimizes impact on customer satisfaction by restoring services quickly.
Example Activities
Identify and record threats and Use information on threats and vulnerabilities to develop and
vulnerabilities to ongoing operations. keep updated the continuity plan. In the continuity plan,
record the events, threats, and vulnerabilities likely to lead to
initiating the plan. Plan different actions for different event
categories. Collect risk information about individual functions
and use as an input to this part of the plan.
Record continuity plans. An organization can keep updated one or multiple plans
covering different types of disruptions or operations.
Validate continuity plans with affected
stakeholders.
Ensure that secure storage and access
methods exist for continuity plans and
87

critical information and functions
needed to implement the plans.
Protect vital data and systems. Address the protection of vital data and systems, e.g.,
include developing additional system components.
Record the criteria and procedures for Record the acceptable levels for various outage scenarios,
shifting from the normal operations e.g., site, city, country.
environment to a Continuity of
Operations (COOP) environment.
Revise continuity plans as necessary. Examples of when to revise continuity plans include:
• Major changes to operations
• Changes to essential functions or infrastructure
• Changes to key dependencies on resources, both internal
and external
• Feedback warranting changes
• Identification of needed changes during review of the
continuity plan
• Changes to the delivery environment
• Newly identified significant threats or vulnerabilities

List of threats and vulnerabilities Include occurrences that could negatively affect the ability of
the organization to continue operations
Continuity plans Contents may include:
• Criteria defining significant disruptions
• Criteria for who has the authority to initiate continuity
plans
• Alternate resources and locations
• Records of the recovery sequence, including the decision
to stop the service
• Critical personnel roles and responsibilities
• Available backup equipment
• Methods for handling security-related material
• Methods of communication
• Cost benefit analysis
• Approach for testing response systems
• Approach for returning to normal operations after the
disruption ends

Peer Reviews (PR)
88
Level 3
CONT 3.1
Practice Statement
Develop and keep updated materials for continuity training.
Value
Prepares the organization to perform essential functions in response to catastrophic events.
Prepare for continuity training to enhance business resilience. Train people who use continuity
plans to increase the probability of successful plan performance. Include customers and end
users in continuity training as needed.
Examples of when to involve customers and end users in continuity training include:
• Situations in which events affect the customer and end user causing the organization to
initiate its continuity plan
• When a change required by a continuity plan affects customer or end user businesses
Examples of people needing training include:
• Personnel who respond to customer or end user requests
• Personnel who provide infrastructure support, e.g., information technology, utilities
• Senior leadership
• End users
• Suppliers
• Project managers and personnel
Examples of continuity training methods include:
• Role playing
• Scenario based training
• Classroom instruction
• Group discussions
Example Activities
Develop a strategy for conducting
continuity training.
89

Develop and record continuity training
for each category of threat and
vulnerability to operations.
Review continuity training material
with affected stakeholders.
Revise training material as needed to
reflect changes in continuity plans and
feedback on training effectiveness.

Continuity training strategy
Continuity training material Include revisions based on review and delivery feedback.
Continuity training review results Use to identify:
• Needed changes
• Action items to address

Peer Reviews (PR)
CONT 3.2
Practice Statement
Provide and evaluate continuity training according to the plan.
Value
Maximizes team members’ ability to restore or continue essential functions for the business.
This training enables people to perform essential business functions when disruptions to
business operations occur. The training also provides an opportunity for the organization to
collect feedback on continuity plan effectiveness to improve the continuity plan.
Example Activities
Deliver training that covers initiation
and implementation of continuity
plans.
90

Keep updated records of those who
successfully complete continuity
training.
Collect feedback on how well continuity
training has prepared those who will
implement the continuity plan.
Analyze training feedback and record Training feedback from attendees can provide suggested
suggested improvements to continuity improvements to continuity plans based on their experience.
plans and continuity training.
Update continuity plans and continuity
training as needed.

Training records
Evaluations of training effectiveness by
students and training specialists
Suggested improvements to the
continuity plan

Organizational Training (OT)
CONT 3.3
Practice Statement
Prepare, conduct, and analyze results from verification and validation of the continuity plan.
Value
Increases confidence and likelihood that the continuity plan is effective to meet requirements
and the operational needs of users.
Record requirements, key principles, activities, resources, and environments required to
effectively verify and validate continuity plans. Verify and validate continuity plans periodically,
e.g., annually, and on an event-driven basis. When making major changes to the system or to
the environment, review, revise, and test continuity plans.
91
Verifying and validating continuity plans helps prepare the organization for various threats and
vulnerabilities before a significant disruption occurs. This approach involves conducting reviews,
tests, and demonstrations in a controlled and simulated environment. Verify and validate
continuity plans by selecting methods, performing tests and simulations, and analyzing results.
Examples of verification methods include:
• Inspections
• Peer reviews
• Audits
• Walkthroughs
• Analyses
• Simulations
• Testing
• Demonstrations
• Sampling
While methods for validation can be the same as verification, their purposes are different.
Verification focuses on addressing continuity requirements and validation ensures that
continuity plans will work under emergency conditions.
Analysis of the verification and validation results of continuity plans helps to address issues and
improve ability to respond to significant disruptions.
Example Activities
Develop a plan for verifying and Verification and validation is not a one-time event. The
validating continuity. strategy should address how often to perform verification
and validation.
The plan typically includes:
• Strategy used for conducting verification and validation
• Categories of threats and vulnerabilities evaluated
• Categories of essential functions and resources
• Methods to evaluate the effectiveness of preparation
• Environments needed to support verification and
validation
• Criteria defining target levels of performance during
recovery operations
• Schedule of activities to conduct verification and validation
• Assigned resources
Prepare the environment to conduct
verification and validation.
Prepare checklists to verify and May include:
validate the continuity plan. • Readiness preparedness checklists
• Emergency preparedness materials checklist
• Business continuity self-assessment checklist
92

Review the verification and validation Affected stakeholders should understand and agree to the
plan with affected stakeholders. verification and validation strategy, methods, activities,
environments, and resources.
Decide on the procedures and criteria Procedures and criteria ensure that the elements of
to verify and validate the continuity continuity plans are correct, effective, and current relative to
plan. the categories of threats and vulnerabilities.
Conduct verification and validation of
the continuity plan.
Evaluate results of verification and Evaluation may include criteria for:
validation activities. • Achievement of restoration to agreed levels of operation
• Effectiveness of communication strategies
• Readiness of key resources
Collect improvement proposals for
business operations or system
components as appropriate based on
the analyses of results.
Provide information on defect Information includes verification methods, criteria, and the
resolution and initiate corrective action. verification environment.
Record the results and This may include:
recommendations of verification and • Feedback from training activities
validation activities. • Lessons learned
• Additional corrective actions
Record recommendations for improving Include changes to continuity plans identified:
the continuity plan. • When preparing for verification and validation
• From performing verification and validation activities
Update the continuity plan as
necessary.

Verification and validation plan for
assuring continuity
Evaluation methods used for
verification and validation
Description of environments necessary
to conduct verification and validation
Verification and validation procedures
Criteria for what constitutes successful
List of personnel and affected
stakeholders involved in continuity
verification and validation activities
93

Verification and validation analysis
reports
Recommendations for improvement These include improvement recommendations for:
• Continuity plans
• Continuity plan verification and validation activities

94
Intent
Make and record decisions using a recorded process that analyzes alternatives.
Value
Increases the objectivity of decision making and the probability of selecting the optimal
solution.
Practice Summary
Level 1
DAR 1.1 Define and record the alternatives.
DAR 1.2 Make and record the decision.
Level 2
DAR 2.1 Develop, keep updated, and use rules to determine when to follow a
recorded process for criteria-based decisions.
DAR 2.2 Develop criteria for evaluating alternatives.
DAR 2.3 Identify alternative solutions.
DAR 2.4 Select evaluation methods.
DAR 2.5 Evaluate and select solutions using criteria and methods.
Level 3
DAR 3.1 Develop, keep updated, and use a description of role-based decision
authority.
Decision analysis and resolution activities involve:
• Developing and updating guidelines to decide which decisions should be subject to a
structured, criteria-based decision-making process
• Applying a criteria-based decision-making process for selecting from a set of alternatives
Apply criteria-based decision-making processes to technical or nontechnical alternatives that
have multiple possible options for resolution. A decision-making process can be used for
decisions throughout the organization.
95
One key element that contributes to the success of effective decision making is the involvement
of affected stakeholders. Stakeholders can include:
• Those impacted by the decision
• Implementers of the decision
Examples of criteria-based decision making include:
• Trade studies
• Determination of what solutions will be acquired or developed
• Configuration control board change approvals
• Selection of suppliers
• Risk mitigation choices
• Analysis of alternatives
• A make-or-buy decision
• Choices of manufacturing processes or tools
• Selection of locations, premises, and work facilities
• Changes in organizational structure
For organizational decisions, specify conditions that require criteria-based decision making.
These conditions could include a combination of:
• Impact on the cost of the decision
• Impact on timelines and schedules
• Impact on the quality of the solution
• Impact on other related processes
• Convenience or disruption to the workforce
• Impact on motivation and morale of the workforce
Criteria-based decision-making processes can vary in formality, type of criteria, and methods
used:
• Less formal decisions can be analyzed in a shorter time and use fewer criteria, e.g.,
effectiveness, cost to implement
• More formal decisions can require more effort, and may include:
o A plan
o Multiple reviews to develop and approve criteria
o Simulations
o Prototypes
o Piloting
Planning (PLAN)
96

Context Specific
The decisions made by agile teams can include:

• Which agile tools to use
• Which features to include for each sprint, story, or epic
• Whether to undergo a significant refactoring of code that could result in further defects
• Criteria for acceptance from customer
Development
Efforts in development can use criteria-based decision making for alternatives that may include:
• Whether to opt for a short-term code fix that would increase technical debt, or a longer-
term solution
• Which design approach to pursue
• Whether to make, buy, or reuse software code
• Whether to invest in automated testing, and to what degree, given the upfront
investment needed
Supplier Management
The acquirer has the ultimate responsibility for ensuring that the appropriate decision-making
activities are performed. When the supplier is involved in decisions that affect the overall
solution, the acquirer engages with the supplier to provide oversight of the decision process to
meet business needs.
Use a repeatable, criteria-based decision-making process for:
• Critical decisions that define and guide the acquisition process
• Critical decisions made with the selected supplier
97
This decision-making process should be consistent with the acquisition strategy. Revisit these
criteria when considering changes or technology additions that affect requirements or other
critical project parameters. A formal process also helps the acquirer and supplier to
communicate decisions.
98
Level 1
DAR 1.1
Practice Statement
Define and record the alternatives.
Value
A clear definition and understanding of the alternatives to be made reduces potential rework.
Decisions do not always consider alternatives. It is important to reach a common understanding
of the alternatives, their potential impact, and the necessary decision.
Example Activities
Define the alternatives.
Involve stakeholders in defining the alternatives.

Statement of the alternatives Describe the alternatives and identify the people involved.
99
DAR 1.2
Practice Statement
Make and record the decision.
Value
Provides a clear understanding of rationale and decisions made and avoids constant revisions
and rework.
The rationale behind decisions may be lost or questioned in the future. Recorded decisions are
available for future reference to understand and learn from the decisions made and the issues
or contexts associated with them.
Example Activities
Make and record the decision.

Recorded decisions May also include:
• Alternatives
• Rationale
• Selection criteria
• People involved
100
Level 2
DAR 2.1
Practice Statement
Develop, keep updated, and use rules to determine when to follow a recorded process for
criteria-based decisions.
Value
Reduces costs by focusing on the most important decisions.
Not every decision is significant enough to require a criteria-based decision-making process.
Evaluate if a decision is significant based on the work, circumstances, and established
guidelines. Consider the cost of making the decision versus the impact of the decision.
Conditions when a criteria-based decision-making process may be needed include when there
are:
• Significant adverse effects on cost, quality, resources, or schedule
• Legal or contractual obligations
• Requirements resulting in significantly different alternative solutions
• Issues that have medium-to-high-impact risk
• Changes to work products under configuration management
• Impacts on people’s morale, motivation, and convenience
Example Activities
Develop and record rules and guidelines for when to
use a process for criteria-based decision making.
Follow rules and guidelines for criteria-based
decision making.
Communicate rules and guidelines to affected Inform affected stakeholders when a criteria-
stakeholders. based decision-making process will be used.

Rules and guidelines for criteria-based decision making
List of recorded criteria-based decisions.
101

Context Specific
Development
Examples of activities for which you may use a criteria-based decision-making process include:
• Making design implementation decisions when technical performance failure can cause a
catastrophic failure, e.g., safety-of-flight item
• Making decisions with the potential to significantly reduce design risk, engineering
changes, cycle time, response time, and production costs, e.g., to use different
approaches to assess form and fit capability before releasing engineering drawings and
production builds
• Developing new or changing existing requirements resulting in significantly different
alternative architectures or designs
• Make, buy, or reuse components
• Selecting testing tools and environment
• Determining alternative software coding approaches
Services
Context Tag: CMMI-SVC
Context: Use processes to deliver, manage, and improve services to meet customer needs.
Activities that an organization may use a criteria-based decision-making process for include:
• Selecting elements to include in standard service descriptions
• Selecting, terminating, or renewing suppliers
• Selecting personnel training
• Selecting a transition and support approach, e.g., disaster recovery, service levels
Supplier Management
Examples of when to use a criteria-based decision-making process include:
102
• Making decisions to trade off cost, schedule, and performance requirements during an
acquisition
• Selecting, terminating, or renewing suppliers
• Selecting a testing environment in which to validate the acquired solution
• Selecting an approach for ongoing support, e.g., disaster recovery, service levels
DAR 2.2
Practice Statement
Develop criteria for evaluating alternatives.
Value
Enables consistent selection of optimal solutions.
Both numeric and non-numeric criteria can be used with a process for criteria-based decision
making. Decisions based on explicitly defined criteria can remove barriers to stakeholder
agreement and acceptance.
Example Activities
Define the criteria for evaluating Can help to establish boundaries for making decisions.
alternative solutions.
Define, use, and keep updated the May involve:
range and weighting for evaluation • Developing weighting for relative importance of evaluation
criteria. criteria
• Identifying risks and impacts
• Ranking criteria according to the defined range and
weighting to reflect the needs, objectives, and priorities of
affected stakeholders

Recorded evaluation criteria May include:
• Rationale for the criteria
• Criteria ranking and weighting
103
DAR 2.3
Practice Statement
Identify alternative solutions.
Value
Increases the quality of the solution and customer satisfaction.
The number of alternatives may be limited at first. Through the analysis process, add other
alternatives to the list of potential alternatives. Generate and consider multiple alternatives early
in the decision-making process. This makes it easier to choose a solution that best meets the
criteria, and to understand the potential consequences of that decision.
Example Activities
Research information about similar This can help:
internal or external past decisions. • Provide a deeper understanding of the problem
• Identify alternatives to consider
• Uncover barriers to implementation
• Identify lessons learned from similar decisions
Identify additional alternatives to • Use evaluation criteria as a starting point for identifying
consider. alternatives. Evaluation criteria identify the priorities of
affected stakeholders and the importance of business,
performance, technical, logistical, or other challenges.
• Combine key characteristics of existing alternative
solutions to generate additional, sometimes stronger,
alternative solutions.
• Solicit alternative solutions from affected stakeholders,
e.g., though brainstorming sessions, interviews, and
working groups.
Record selected alternatives.

Recorded alternatives
104
Context Specific
Supplier Management
Suppliers may be needed to provide input to the decision analysis process, e.g. technical
expertise outside of acquirer’s capabilities. The acquirer has the ultimate decision-making
responsibility.
DAR 2.4
Practice Statement
Select evaluation methods.
Value
Optimizes the cost, schedule, and performance for the decision being made.
Evaluation methods are used to determine which alternative meets the stated criteria.
Example Activities
Select evaluation methods. Evaluation methods may include:
• Structured weighting matrix
• Testing
• Modeling and simulation
• Studies or benchmarking
• Surveys
• Prototypes
• Demonstrations
• Focus groups
• Expert judgment

Selected evaluation methods
105
DAR 2.5
Practice Statement
Evaluate and select solutions using criteria and methods.
Value
Ensures that the optimal solution is selected.
A variety of methods may be iteratively used for evaluating and making criteria-based decisions.
Example Activities
Evaluate proposed alternative solutions
following the recorded process for
criteria-based decisions.
Record the results of the evaluation. Record the rationale for adding new alternatives, adding new
methods, changing criteria, and the interim evaluation
results.
Assess the risks associated with There can be substantial risk when decisions are made with
implementing the recommended incomplete information.
solution.
Record and communicate the results It is important to record both why a solution is selected and
for the recommended solution to why other solutions were rejected.
affected stakeholders.

Evaluation results
Assessed risks
Recommended solutions

106
Level 3
DAR 3.1
Practice Statement
Develop, keep updated, and use a description of role-based decision authority.
Value
Reduces business risk by ensuring the appropriate levels of authority are making and approving
decisions.
Identify the decision review and approval authority. Approval authority is typically determined
by risk and financial, legal, or other business factors in an organization. Determine the
organizational approach to be used in decision-making including:
• The level of authority
• Stakeholder involvement
• Required reviews
• Review roles, such as reviewers, facilitators, and approvers
In addition, decision processes in different parts of the organization or at different levels of the
organization may be analyzed or approved differently.
Example Activities
Identify, record, keep updated, and communicate
the roles and levels of decision-making authority.

List of roles and decision-making Decision-making authority may involve roles in areas such as:
authority and responsibilities • Legal or regulatory
• Contractual
• Financial
• Personnel management
• Security
• Safety
• Technical
List of decision authority levels Elements of the list may include:
• Description of the level
• Roles involved include reviewer and approver
107

• Escalation procedures
• Communication requirements
108
Estimating (EST)
Intent
Estimate the size, effort, duration, and cost of the work and resources needed to develop,
acquire, or deliver the solution.
Value
Estimation provides a basis for making commitments, planning, and reducing uncertainty, which
allows for early corrective actions and increases the likelihood of meeting objectives.
Practice Summary
Level 1
EST 1.1 Develop high-level estimates to perform the work.
Level 2
EST 2.1 Develop, keep updated, and use the scope of what is being estimated.
EST 2.2 Develop and keep updated estimates for the size of the solution.
EST 2.3 Based on size estimates, develop and record effort, duration, and cost
estimates and their rationale for the solution.
Level 3
EST 3.1 Develop and keep updated a recorded estimation method.
EST 3.2 Use the organizational measurement repository and process assets for
estimating work.
Estimation provides the basis for making commitments. An estimate takes into consideration
the scope, size, and complexity of the work. Base the estimate on the available information.
Record any uncertainty as a risk.
Uncertainty or risk in a commitment can be handled by:
• Providing an initial commitment with an understanding that the initial commitment may
be changed if the scope changes
• Defining milestones to refine an initial commitment range to produce a final commitment
after more investigation
109
• Committing to the known parts of the project, and committing to the remainder of the
work after further investigation and definition
Historical data describing the relationship between measured size and resources such as effort,
cost, and schedule should be used when planning future work. A good understanding of
historical data is critical to successful estimating. Use historical data when planning future work
and to calibrate estimation formulas and models. Record qualitative information such as
context, methods, tools and techniques used, and lessons learned from past projects.
Estimate and track several aspects of the work to realize value. For example, based on Table
EST-1, how complete is the work?
Table EST-1: Example Tracking Information

Percent
Aspect
Completed
Size 10%
Effort 60%
Duration 50%
Cost 75%
This question cannot be answered if only effort is tracked. To get a complete picture of the
status, estimate and track the other aspects of the project. If all aspects are not estimated and
tracked, it could lead to an incomplete or misleading understanding of the work status. The
numbers in the table indicate a potential problem and should trigger an investigation to
determine the real status of the project. There are other aspects of the work, such as
complexity, that may affect the answer. For example, the size may only be 10% complete
because the project front loaded the highly complex components. Understanding the aspects
and their relationships will provide a more comprehensive estimate. The rationale of the
estimate should be based on historical data, rather than on the experience and knowledge of
the estimator.
Planning (PLAN)
Context Specific
In general, agile teams using Scrum estimate during the backlog grooming and sprint planning
steps:
• Estimates for backlog items are typically a rough order of magnitude.
110
• Some agile teams using Scrum develop a comprehensive estimate during release
planning for a set of stories or epics.
• Estimates for each sprint are typically more refined, allowing the team to understand
their commitments.
The typical agile estimation steps develop the following information:
• Size: During backlog review, assign backlog items, such as requirements and user
stories, a relative size using story points. Refer to Table EST-3. In addition to story
points, agile with Scrum teams may use such techniques as planning poker or t-shirt size
(small, medium, large, or extra-large) to estimate size. Often requirements are
converted into user stories before estimation is performed. Complex needs or
requirements may be transformed into an epic, which is typically a large user story that
can span more than one sprint. If the epic spans more than one sprint, it is typically
broken into smaller user stories. The transformation of user stories into story points
takes into account the size and complexity of the solution.
• Tasks and Effort: During sprint planning, agile teams using Scrum and the product
owner collaborate to select user stories off the backlog based on the priority of the
product owner and estimate them using relative sizing techniques such as planning
poker, t-shirt sizing, or the Team Estimation Game. Using the team’s known velocity as a
guide, prioritized stories are accepted by all stakeholders into the sprint. Some agile
teams estimate the task effort in hours for each story based on historical data or other
effort estimation technique.
o Determine how many user stories can be committed to the sprint when team
velocity is known (story points completed per sprint)
o Estimate effort at the task level and use the total to determine the amount of work
that can fit into a sprint based on available capacity
o Use known velocity numbers to make a first estimate of what can be committed to
in a sprint, and then use task breakdown and effort data to refine and validate the
decision
• Task Assumptions: Discuss and confirm assumptions during sprint planning events and
review during the retrospective to improve estimates. Record, clarify, and communicate
assumptions during these events. Refer to examples in Table EST-3.
Figure EST-1 shows where estimation is typically performed in an agile project. Table EST-2
and Table EST-3 show example estimation data and the model practices used to generate this
information.
111
Figure EST-1: Estimating in an Agile Cycle
Table EST-2: Backlog with Estimates
112
Table EST-3: Requirement/Task Estimation & Model Practices
113
Level 1
EST 1.1
Practice Statement
Develop high-level estimates to perform the work.
Value
A high-level estimate addresses work size, cost, and schedule uncertainties to avoid pursuing
work that may result in schedule or budget overruns.
The high-level estimate is typically:
• A rough draft, top-down estimate (also called a rough order of magnitude estimate)
• Based on identified or recorded assumptions and uncertainty
• Developed quickly
• Based on previous knowledge and experience
Example Activities
Review needs and assumptions and
determine high-level estimates with
stakeholders.

Rough order of magnitude estimate Includes:
• An estimate of the size, complexity, cost, effort, or
duration of the solution
• Assumptions
• Unit of measure
114
Level 2
EST 2.1
Practice Statement
Develop, keep updated, and use the scope of what is being estimated.
Value
Ensures the entire solution is addressed which increases the likelihood of meeting objectives
and avoiding rework.
The scope:
• Includes the work effort
• Defines the solution to be developed, delivered, or acquired
• Results in the information needed to estimate the size, effort, cost, and duration
• Addresses any resources that must be acquired or will be consumed during the project
• Establishes the work constraints, e.g., what is included and what is not included
Use an initial set of requirements and work objectives to form the basis for establishing the
scope. Defining and using the scope can help uncover missing or misunderstood requirements,
identify risks, and develop more detailed estimates. Inaccurate estimation is often the result of
not understanding the scope of the work. Update the scope as the project progresses to
address changes.
Example Activities
Review requirements and objectives
with stakeholders to determine scope.

List of tasks and activities or Work To more accurately estimate costs, include identified
Breakdown Structure (WBS) resources for tasks and durations.
List of needed resources Includes not just staff, but also other resources needed to
accomplish the work, e.g., facilities, acquired solutions, tools.
Work flow diagram Visualizes how tasks will flow between resources and what
conditions allow the sequence to move forward.
115

Context Specific
Supplier Management
Consider activities associated with the acquisition strategy when determining scope. For
example, a complex project can involve managing multiple supplier agreements with one or
more suppliers.
EST 2.2
Practice Statement
Develop and keep updated estimates for the size of the solution.
Value
Well-defined estimates allow work tracking and timely corrective actions to deliver the solution
on time and within budget.
Size is the primary input to many estimation models. Estimation is not a one-time activity that is
only performed before or at the start of the project. It is a recurring activity where the estimate
is adjusted as new information becomes available throughout the lifecycle of a solution,
operations and maintenance, or for services produced and delivered.
Estimating size provides a consistent basis for estimating effort, duration, and cost. A relative
level of difficulty or complexity may be associated with size estimates and is used in the
transformation to effort, duration, cost, and quality. For example:
• For services, size could be the type or number of service requests, number of calls
received in an hour, or the number of customers desiring a service delivery, etc.
• For software development, size could be the number of objects, the number of
components, the number of features, standard or customized function points, the
number of requirements, or the number of lines of code, etc.
• For hardware development, size could be the number of connections or connection
points, the number of welds, the number of boards, the number of components, or the
number of hardware and software integration points, etc.
116
• For supplier management, size could be the number of requirements, the number of
features, the number of items to be acquired, or the number and types of bidders, etc.
Example Activities
Use applicable methods to estimate the Methods for determining size include:
size and complexity of solutions and • Analogy
tasks. • Delphi
• 3-point estimation
• Parametric estimation
The project estimation methods and their use may change
over time as the understanding of the relationship of solution
characteristics to size improves.
Complexity is typically used in the transformation from size
to effort, duration, and cost. Complexity may also include
qualitative aspects of the solution, such as new vs. legacy.

Size estimate Typically includes:
• Size
• Unit of measure
• Rationale or basis for estimate, including assumptions and
constraints
• Complexity – could be a multiplier of size, or a modifier
(such as Hard, Medium, Easy), to take into account the
potential difficulty of implementing the solution
Context Specific
Services
Characteristics used to develop estimates include:

• Number and type of services
• Number of service levels
• Volume of service requests
Examples of tasks to develop size estimates for include:
• Service system development and delivery
• Service system monitoring
• Preventative maintenance or repair
• Training
• Incident management and resolution
117
• Updating equipment and supplies

• Logistical support
• Facilities maintenance
• Transition activities
• Monitoring for and addressing obsolescence
• System disposal
Supplier Management
Examples of characteristics used to estimate include:

• Effort needed by the acquirer to manage the supplier
• Number and complexity of acquirer work products
• Number and complexity of requirements in the solicitation package
• Number and complexity of clauses in the supplier agreement
• Amount and complexity of the work suppliers will address
• Number of potential suppliers
• Number of pages
• Prioritized solution features
Examples of work products for which size estimates include:
• Solicitation package
• Supplier agreement
EST 2.3
Practice Statement
Based on size estimates, develop and record effort, duration, and cost estimates and their
rationale for the solution.
Value
Enables a better basis for commitments and improves accuracy of the estimates, leading to
better decision making.
118

Transform the size estimate into estimates of effort, duration, and cost. Use estimation models,
historical data, expert judgment, or a combination of all three. Understanding the size of the
solution provides a more accurate basis for determining the effort, duration, and cost for the
solution. While performing the work, compare the rationale to actual conditions to identify
missing or unnecessary aspects in the original estimate. Identifying missing or unnecessary
aspects supports re-planning the current work or estimating future work.
Managers and leads typically perform top down estimation. Bottom up estimation is typically
performed by team members.
Develop and calibrate estimation models using available historical data. To increase confidence,
update estimation models as additional data becomes available.
Sometimes, historical data is not available, such as when efforts are unprecedented.
Unprecedented efforts are riskier and require more research to develop a basis of estimate.
Record rationale for what made the work unique to aid understanding of any assumptions made
in the initial planning phases.
Example Activities
Collect and use historical data to To ensure a high level of confidence in the estimate, use
develop, calibrate, or recalibrate multiple models or methods as needed, for example, based
models or methods to transform size on the most important set of tasks and activities.
and complexity into effort, duration, Historical data should include:
and cost estimates.
• Size, cost, effort, and schedule (duration) data from
previous completed projects
• Appropriate scaling data to account for differing sizes and
complexity
• In addition, information on factors that influenced the
performance and other contextual information will help
determine if past data can be included, excluded, or
adjusted
Historical data can also be used with analogies, e.g., if a
current project is 10% smaller than a similar historical
project, use the historical project’s results reduced by 10%.
There may be instances where historical data is not available
or does not apply. In the absence of historical data (for
example, no prior history of work similar to current work)
external sources like industry data may be used.
Models can also be based on other characteristics such as
service level, connectivity, complexity, availability,
reusability, and structure. Other examples of characteristics
include:
• Critical competencies and roles needed to perform the
work
• Needed knowledge, skills, experience, and training
• Selected lifecycle model and processes
• Travel
119

• Team productivity
• Geographic dispersal of work group members
• Proximity of customers, end users, and suppliers
• Amount of risk
• How agreeable or difficult the customer is
• Direct labor rates and overhead
• Penalties for warranty work
• Regulatory requirements or environment
• Level of security required for tasks, work products,
hardware, software, personnel, and work environment
Describe and record the rationale for Recording the rationale provides the context for using
the estimates of effort, duration, and historical data for estimating future work.
cost for the solution.
Include estimates of supporting The supporting infrastructure includes resources needed to
infrastructure needs. support the project but are not necessarily included in the
project itself. Consider the infrastructure resources needed
for the work, including:
• Contracts
• Facilities
• Tools
• Consumables
• Licenses
• Travel

Effort estimate Typically includes:
• Effort
• Unit of measure (typically hours or days)
• Productivity
• Context for the effort estimate
Duration estimate Typically includes:
• Duration
• Unit of measure (typically hours or days)
• Rationale for the duration estimate
Cost estimate Typically includes:
• Cost
• Unit of measure, e.g., local currency, contract currency
• Rationale for the cost estimate
Estimating rationale Typically includes:
• Description of what is being estimated
• Scope
• Assumptions and constraints
• Comparisons to similar work
• Team experience with the technology and domain
• Risks
• Use of historical data
120

• Tools, techniques, or methods used:
o Off the shelf tools
o Internally developed tools
o Formulas and calculations
o Models
Context Specific
Services
Service estimates should consider the effort and cost associated with delivering the service.
Individual services can have associated workflows or detailed steps that involve points of
communication, evaluation, and decision. Consider these lifecycles when estimating the
requirements to support the delivery of individual services.
Parameters to consider include:
• Service characteristics
• Service system and service system components
• Delivery environment
When estimating effort and cost, include infrastructure resources that support services. For
example:
• Computer workstations
• Power, space, and cooling requirements
• Tools for use by service teams
• Facilities
• Network and communications requirements
• Machinery and equipment
• Support for shift work
Inputs used for estimating effort and cost include:
• Availability of services, by service level, e.g., turnaround time, operational availability
ratio, number of calls the help desk should be able to handle per hour
• Level of security required for tasks, work products, hardware, software, personnel, and
the work environment
• Service and service system requirements
• Service approach
• Size estimates of work products, tasks, and anticipated changes
• Cost of externally acquired products
121
• Capability of tools provided

• Capability of manufacturing processes
• Experience of service participants
• Proximity of customers, end users, and suppliers
• Technical approach
• Consumables (resources that the service provider will need to replenish or replace
before, during, or after providing a service)
Supplier Management
The amount of supplier work largely determines the amount of acquirer work required to
manage the project and the supplier. Effort for the acquirer includes effort associated with:
• Defining the project and scope
• Developing the solicitation and supplier agreement
• Managing the agreement and technical activities
• Planning, monitoring, and controlling the project and supplier
• Developing and updating acquisition requirements
The project derives detailed estimates for activities performed by the acquirer and its
stakeholders. The acquirer should include stakeholder representatives to ensure they have
accounted for all technical or service considerations in the estimates. As the work evolves,
revise estimates based on changing conditions or requirements.
Additionally, the acquirer needs to estimate the cost and effort for the acquired solutions.
Estimates should address effort and cost for supplier management and reporting requirements.
The acquirer should review its supplier effort and cost estimates with external individuals to
ensure reasonable estimates.
122
Level 3
EST 3.1
Practice Statement
Develop and keep updated a recorded estimation method.
Value
Maximizes consistency and efficiency for developing accurate estimates and increases the
likelihood of meeting objectives.
A defined estimation method is a standard approach using established processes and the best
available valid data to estimate the current or future size, effort, cost, and duration of a project
based on what is known. Valid estimating data is applicable to the context of the work being
estimated. Organizations may have more than one estimation method.
Methods using historical data provide a data driven approach to estimation. Calibrate methods
based on actual results vs. historical data and recalibrate methods when conditions,
assumptions, processes, or performance change. Use an analysis of estimation accuracy to
improve the method.
Some standard methods are described in the following table:
Table EST-4: Example Estimation Methods

Method Brief Description
Delphi method Estimates are developed by a group of subject matter
experts where each independently gives their estimates and
assumptions to the designated facilitator. The team discusses
the differences and re-estimates. This is repeated until the
estimates converge. The facilitator then records the final
estimate.
Comparative or analogous estimation Estimates are based directly on past results for similar
projects. The estimate is then adjusted for differences in
size, complexity, or other factors to reflect current
knowledge.
Parametric estimation Parametric estimates are based on historical data and project
parameters and typically use a tool. Note that there are
various forms of estimation tools, including:
• Mathematical
• Scenario-based
• Simulation
123
Method Brief Description

• Calibrating the estimation tool as it is used can provide
additional estimation accuracy.
3-point estimation Each estimator (note that there may be only one estimator)
provides high, low, and most-likely estimates. The facilitator
combines them and calculates the resulting value by using
the formula:
(high + (4 * most likely) + low) / 6.
Example Activities
Determine the acceptable estimation Estimation methods are most accurate when based on
methods. historical data and validated before use. The estimation
methods should be used consistently for similar activities,
projects, domains, etc. Involve subject matter experts in
developing and approving the method.
The estimation tools can be built or acquired, but should be
calibrated with organizational data.
Calibrate and adjust method based on One approach to calibrate is to refresh the data periodically
actual results. or recalibrate data after the most recent use. For example,
compare the actuals from the most recent calendar quarter
of data to an estimate of that same quarter using the
average of the previous three calendar quarters. Based on
differences, adjust the method.
Validate method. The method should be validated by subject matter experts
who have used and understand when to apply the method.

Recorded estimation methods The process, tools, and data used for the selected estimation
methods.
EST 3.2
Practice Statement
Use the organizational measurement repository and process assets for estimating work.
Value
Increases estimation precision, accuracy, and consistency enabling better decision making, a
higher likelihood of meeting objectives, and reduced risk.
124

Using organizational assets as a basis for estimating leverages the data and experience from
previous projects to improve the reliability of estimates for similar work. Select the most
appropriate estimation method and use it to produce the estimates.
When using organizational assets consider:
• Historical and validated data from this work or similar work and its context
• Similarities and differences between the current work and work from which historical
data will be used
• Rationale used to select the historical data
• Type of work
• Tailoring performed
• Geographic-specific information
• Domain and technology
Examples of data contained in the organization’s measurement repository that could be used in
estimation may include:
• Size
• Effort
• Cost
• Duration
• Personnel
• Experience
• Response time
• Capacity
• Performance
• Quality
• Context specific information
Example Activities
Use organizational assets and Include selection criteria and rationale for the chosen
measures for estimation. estimation technique.
Use estimation methods.
Contribute results and measures to the Include actual results, contextual information, and identified
organization in order to improve the improvements.
estimation methods and update
organizational assets.
Analyze organizational data. Analyze data to better understand:
125

• Variability
• Data quality
• Mean, median, mode

Work estimates Include historical data, context, and approved use from the
organization.
Updated organizational process assets Updated organizational process assets may include:
• Templates
• Best practice examples
• Approved methods for use
• Guidelines
Updates to the organizational measurement repository may
include:
• Historical estimation data, e.g., actual effort expended,
number of function points
• Rationale for the estimate, e.g., team skill levels, amount
of code reused
• Contextual information, e.g., domain, type of work,
customer
• Updated estimation results
Context Specific
Supplier Management
Parameters to consider include:

• Acquisition types
• Supplier types
• Supplier on-time performance record
• Supplier performance ratings
• Domain-specific characteristics of the solution
126
Governance (GOV)
Intent
Provides guidance to senior management on their role in the sponsorship and governance of
process activities.
Value
Minimizes the cost of process implementation, increases the likelihood of meeting objectives,
and ensures that the implemented processes support and contribute to the success of the
business.
Practice Summary
Level 1
GOV 1.1 Senior management identifies what is important for doing the work and
defines the approach needed to accomplish the objectives of the
organization.
Level 2
GOV 2.1 Senior management defines, keeps updated, and communicates
organizational directives for process implementation and improvement
based on organization needs and objectives.
GOV 2.2 Senior management ensures resources and training are provided for
developing, supporting, performing, improving, and evaluating adherence
to expected processes.
GOV 2.3 Senior management identifies their information needs and uses the
collected information to provide governance and oversight of effective
process implementation and improvement.
GOV 2.4 Senior management holds people accountable for adhering to
organization directives and achieving process implementation and
improvement objectives.
Level 3
GOV 3.1 Senior management ensures that measures supporting objectives
throughout the organization are collected, analyzed, and used.
GOV 3.2 Senior management ensures that competencies and processes are
aligned with the objectives of the organization.
127
Level 4
GOV 4.1 Senior management ensures that selected decisions are driven by
statistical and quantitative analysis related to performance and
achievement of quality and process performance objectives.
Senior management involvement is critical to the success of process implementation in an
organization.
Senior management:
• Sets the strategy, direction, and expectations for process efforts
• Ensures that processes are aligned with business objectives and needs
• Reinforces and rewards the development and use of processes to ensure their
improvement and sustainment
• Monitors the performance and achievements of the processes
• Provides adequate resources for process and performance improvement
Implement processes to meet the intent of these practices to improve process sustainment and
integration throughout the organization. The practices in this PA are intended to apply to the
set of organizational or project processes by identifying process roles for senior management to
perform.
Implementation Infrastructure (II)
128
Level 1
GOV 1.1
Practice Statement
Senior management identifies what is important for doing the work and defines the approach
needed to accomplish the objectives of the organization.
Value
Increases the likelihood that the organization implements and improves processes efficiently
and effectively to meet business objectives.
Senior management is responsible for understanding the marketplace, developing business
strategies, and defining business objectives. Senior management must set and communicate
organizational direction that:
• Governs organizational activities, including process implementation and improvement
efforts
• Includes objectives, business strategy, and the approaches intended to address both
• Sets expectations for ensuring that the organization’s process efforts support business
and performance needs and objectives
• Provides input to improvement plans
Organizational direction is typically provided as statements of policy, strategy, mission, vision,
values, and objectives.
Senior managers review, update, and communicate organizational direction periodically or as
performance, business needs, and objectives change.
Example Activities
Senior management decides what is important for improvement,
sets the approach, and communicates the results.

Identification of importance of and approach to improvement
Records of reviews and communications
129
Level 2
GOV 2.1
Practice Statement
Senior management defines, keeps updated, and communicates organizational directives for
process implementation and improvement based on organization needs and objectives.
Value
Increases likelihood of meeting organizational needs and objectives because work is performed
in accordance with senior management’s expectations and priorities.
Guiding principles, which are essential to a viable business culture, are often recorded in
organizational strategies, mission, and vision statements.
A mission statement provides a simple statement of what the organization does, the reason for
its existence, and the value it provides to customers, investors, stakeholders, and other
interested parties.
A vision statement provides a high-level statement of what the organization wants to achieve
strategically in the coming years.
Organizational strategy provides guidance related to the:
• Decisions made to achieve long-term objectives
• Actions an organization intends to take to achieve long-term objectives
• Identification of resources needed to accomplish long-term objectives
Guiding principles form the basis for directives. Over time, the directives become ingrained in
how the organization implements and improves processes and provide the basis for how the
organization does business.
Senior management:
• Defines directives that influence and help focus process implementation and improvement
efforts on achieving organizational objectives and addressing needs.
• Communicates these directives across the organization to ensure that priorities and
expectations are understood.
Directives:
• Record what is important to senior management
• Clearly specify which parts of the organization are affected by and held accountable for
compliance
130
• Develop expectations and specify requirements for following organizational standards,

implementing and improving the processes, and sharing information
Review organizational directives on a periodic and as-needed basis to confirm they accurately
reflect and support organizational improvement objectives.
Example Activities
Senior management defines Although senior managers are responsible and accountable
organizational directives based on for defining policies, other members of the organization,
guiding principles. such as process improvement team members, often
participate in developing directives.
Senior management reviews and Other members of the organization may provide input on
refines process implementation and process implementation and improvement objectives. These
improvement objectives to ensure people may include:
alignment with the guiding principles. • Executive managers
• Functional managers
• Members of a steering committee
• Subject matter experts
To ensure that processes remain aligned with the
organizational strategy, senior management must be
involved in prioritizing improvement objectives.
Senior management communicates Communication should take place through different channels
improvement directives. and may include:
• In-person discussions and meetings
• All hands meeting content and minutes
• Videos
• Websites and blogs
• Corporate newsletters and boards
• Annual report
• Marketing material
• Emails
• Orientation package
• Training materials
• Social media
Senior management reviews and This activity may involve input from other members of the
updates improvement directives on a organization such as functional managers, a steering
periodic or event-driven basis. committee, and subject matter experts.
After internal or external changes, the organization may
need to review the relevance of directives.

Organizational improvement directives
Records of communication
131
GOV 2.2
Practice Statement
Senior management ensures resources and training are provided for developing, supporting,
performing, improving, and evaluating adherence to expected processes.
Value
Providing sufficient resources increases the likelihood that senior management’s priorities for
improvement will be met.
Resources must be of sufficient quality and quantity to perform these activities.
Senior management prioritizes resource allocation across the organization. This supports the
capabilities necessary to achieve the desired performance results by balancing resource needs
against availability. For processes to be performed as defined and expected, senior
management must provide adequate resources to develop, perform, improve, support, and
evaluate adherence to those processes. Resources may include people, funding, tools,
equipment, facilities, environment, and consumables. Resources also include senior
management’s time and attention.
Senior management should focus on prioritizing resources to meet both short- and long-term
objectives and encourage repeatable and consistent process performance.
The adequacy of resources depends on availability, capacity, and capability and can change
over time. Sufficient resources must be provided to ensure that needed expertise, facilities, or
tools are available. Senior management should consider increasing available resources or
removing requirements, constraints, or commitments to address needs. Information that can be
used to determine if resources are sufficient includes:
• Roles and responsibilities definition
• Needed and available skills, knowledge, and experience
• Cost
• Description of facilities
• Tool availability and appropriateness
• List of equipment
• Environment description
• List of consumables, including amounts
• Timeframe of availability
• Dependencies
Senior management’s most valuable resource is their time. For improvement efforts to be
successful, senior management must provide ongoing, visible, and active support.
132
Example Activities
Senior management approves and
provides the funding and resources
needed to develop, perform, improve,
and monitor the process.
Senior management reviews, revises,
and communicates assignment of
needed funding, personnel, and
resources to develop, perform,
improve, and monitor the process.
Senior management reviews and
refines the allocation of budget and
resources.

Recorded allocation of needed funding
and resources approved by senior
management
Records of reviews and
communications
GOV 2.3
Practice Statement
Senior management identifies their information needs and uses the collected information to
provide governance and oversight of effective process implementation and improvement.
Value
Aligns the information senior management receives with their business needs to increase the
likelihood of meeting business objectives.
Senior management must identify the information necessary for them to:
• Make timely and informed decisions
• Understand status and when to act on it
• Reinforce the importance of performance improvement
133
• Align organizational process improvement efforts to meet objectives

Process effectiveness indicates the organization’s capability to achieve performance objectives.
Senior management can determine how efficient and effective processes are by comparing
process implementation and improvement results to process improvement and performance
objectives.
Senior management identifies and prioritizes the information they need about process capability
and performance improvement. Senior management provides guidance and direction to align
measures and activities with identified information needs and objectives. Senior management
reviews information to understand:
• Current process improvement status and its effectiveness
• Organizational performance
• If business objectives are being met
• Capability of current processes to meet current and future objectives
• When and where to take corrective action
Senior management uses periodic and event-driven reviews to obtain insight into organizational
process improvement activities. These reviews are for senior managers who provide the policy
and overall guidance for the process and not for those who perform the day-to-day monitoring
and controlling of the process.
During the reviews, senior management:
• Reviews measurement results and addresses issues
• Reviews status against process improvement plans and addresses issues
• Reviews results of process implementation and addresses issues
• Reviews progress against tactical and operational objectives
The scope, length, content, level of abstraction, and frequency of these reviews depend on the
needs of senior management. Reviews enable senior management to understand and take
action on the planning, deployment, implementation, use, performance, and improvement of
processes.
Information reported to senior managers improves their insight into the process to ensure the
organization manages work, achieves objectives, and improves performance. Measures provide
objective information that is used to make informed decisions and take appropriate corrective
action. The information reported to senior management may be provided in summary form.
Example Activities
Senior management identifies and This includes approval of how the needed information will be
keeps up to date their information reported.
needs related to process capability,
improvement, and performance
objectives.
Senior management ensures that Measures:
measures supporting the organization’s • Align to organizational objectives
objectives are defined.
134

• Support the organization’s ability to manage its
performance results
Senior management reviews activities, Reviews of the process, performance, work products, and
accomplishments, status, and results of solutions include:
the process implementation and • Reviewing against the plan for implementing and
improvement activities. improving process capability and resulting performance
• Reviewing with the immediate level of management
responsible for process implementation and improvement
activities
• Reviewing measurement data and qualitative information
• Identifying issues by:
o Reviewing performance
o Collecting and using measures
o Deploying, implementing, using, performing, and
improving the process
• Determining if corrective action is needed
Senior management oversees updates
to the process implementation and
improvement plans.
Senior management oversees the Use of measurements supports:
appropriate integration of • Objective planning and estimating
measurement and analysis activities • Tracking actual progress and performance against plans
into all organization processes. and objectives
• Identifying and resolving process-related issues
• Providing a basis for incorporating measurement into
additional processes in the future

Senior management information needs The people collecting and reporting the information must
understand its importance and use.
Senior management may not share sensitive or private
information with the organization.
Standard reporting format or agenda Includes discussion items and expected content identified by
for review with senior management senior management for the review.
Report templates and tools provide an understandable, easily
interpreted format for communicating the information
identified for review by senior management.
Reports may be produced periodically or as needed.
Reports focus on the information needs identified by senior
management using defined reporting formats and may
include:
• Measures
• Data
135

• Analysis of data, e.g., trend analysis, objective
achievement analysis
List of measures Includes base and derived measures related to senior
management improvement information needs and objectives.
Review results May include:
• Topics reviewed
• Measures reported
• Decisions made
• Proposed process changes
• Proposed policy revisions
• Results from objective evaluations
• Action items with assignments and due dates
May be provided as:
• Meeting minutes provided to all participants
• Direction from senior management
• Other communication from senior management

GOV 2.4
Practice Statement
Senior management holds people accountable for adhering to organization directives and
achieving process implementation and improvement objectives.
Value
Accountability ensures that directives drive the implementation and improvement of processes
to meet business objectives.
Senior management holds people accountable by:
• Verifying and enforcing compliance with organizational directives
• Reviewing commitments that have an organizational impact and ensuring they are met
Periodically and on an event-driven basis, senior management reviews and addresses issues
related to:
• Adherence to organizational directives, practices, and procedures
136
• Process and performance improvement

• Adherence to relevant laws and regulations
• Resolution of noncompliance issues
• Organization performance and improvement trends
• Fulfilling commitments that have an organizational impact
Example Activities
Senior management reviews issues and May include:
trends related to deploying, • Verifying information is accurate and complete
implementing, performing, and • Ensuring that the results of reviews are communicated
improving the organization’s processes. • Ensuring directives are consistently followed
Senior management directs corrective Corrective action includes assigning resources,
actions when: responsibilities, and planned completion dates.
• The organization’s objectives are May include:
not being met • Taking remedial action to repair defective solutions
• Issues are identified • Changing the plan
• Implementation and improvement • Adjusting resources, e.g., people, tools
progress differs from the plans • Negotiating changes to commitments
• Reviewing the objectives and making changes
• Terminating the effort
Senior management provides This may include recognizing or rewarding:
incentives for improvement. • Individuals or teams that meet or exceed improvement
objectives.
• When objectives are met without difficulties rather than
only rewarding when big problems are resolved.
• When implementation progress differs from the plan in a
positive way, e.g., early delivery, under budget, exceeds
quality objectives
This may also include taking remedial or disciplinary actions
when:
• Individuals or teams are not meeting improvement
objectives
• Implementation progress differs from the plan in a
negative way, e.g., late delivery, over budget, poor quality

Action items related to accountability May include:
• Definition of issue
• Assignment of responsibility
• Due date
• Status
Rewards, recognitions, and incentives May include:
• Promotions
137

• Bonuses or increases
• Certificates
• Employee of the Month
• Public recognition
Consequences May include:
• Counseling
• Remediation
• Training
• Reassignment
• Demotion or dismissal

Process Quality Assurance (PQA)
138
Level 3
GOV 3.1
Practice Statement
Senior management ensures that measures supporting objectives throughout the organization
are collected, analyzed, and used.
Value
Decisions based on results of collecting and analyzing data increase the organization’s ability to
successfully deliver its solutions.
Senior management ensures that the:
• Appropriate measures are implemented, collected, analyzed, used, and communicated
• Measures support decisions related to the organization’s and projects’ performance and
capability
• Organizational direction and process improvement strategies are updated based on
measures of performance
Example Activities
Senior management ensures measures are
collected, analyzed, and used.
Senior management directs corrective May include:
actions related to collecting, analyzing, and • Adjusting resources
using measures. • Modifying the plans
• Updating organizational objectives

Updated organizational
measurement repository
Status reports, actions, and These may:
decisions • Result from the collection, analysis, and use of measures.
• Be used for performing work relating to performance and process
improvement, solution delivery, etc.
Updated organizational Based on process performance results, updates will be made to the:
directives and objectives • Organizational strategy
139

• Mission statement
• Vision statement
• Policies
GOV 3.2
Practice Statement
Senior management ensures that competencies and processes are aligned with the objectives
of the organization.
Value
Aligning processes and competencies improves the capability of the organization to meet its
objectives.
Senior management ensures that:
• Objectives are defined
• Processes needed to meet objectives are defined and followed
• Knowledge and skills necessary to perform the processes are identified
• People with the needed knowledge and skills are assigned to perform the processes
Example Activities
Review the status of competencies, Focuses on aligning:
objectives, and processes. • Strategies
• Objectives
• Process reviews
• Competencies
Record and communicate results.

Results of strategy and process May include:
reviews and discussions • Meeting minutes
• Records of decisions and direction
• Action items
140

• Updated objectives
Reviews and comparisons between the May include analyzing:
organization’s competencies and • Personnel profiles
processes to be executed • Skills matrices
• Job descriptions
141
Level 4
GOV 4.1
Practice Statement
Senior management ensures that selected decisions are driven by statistical and quantitative
analysis related to performance and achievement of quality and process performance
objectives.
Value
The use of statistical and quantitative analysis of performance strengthens decision making by
providing an understanding of the probability of achieving objectives.
As an organization becomes more capable, it develops a statistical and quantitative
understanding of the effectiveness of its standard processes. This provides senior management
with visibility into how effectively the processes support achieving business objectives and gives
insight into performance variation which enables:
• Quantifying, understanding, and managing risk
• Ensuring that timely and effective actions are taken to address issues
Example Activities
Review and discuss strategy, process Include related statistical and quantitative analyses and
performance, decisions, and progress. ensure decisions are based on the analyses.
Record and communicate results.

Results of strategy, process Reference the statistical and quantitative analyses that drive
performance, and progress reviews the decisions and related actions.
and decision analyses
Communicated results

142
Implementation Infrastructure (II)
Intent
Ensure that the processes important to an organization are persistently and habitually used and
improved.
Value
Sustains the ability to consistently achieve goals and objectives efficiently and effectively.
Practice Summary
Level 1
II 1.1 Perform processes that address the intent of the Level 1 practices.
Level 2
II 2.1 Provide sufficient resources, funding, and training for developing and
performing processes.
II 2.2 Develop and keep processes updated, and verify they are being followed.
Level 3
II 3.1 Use organizational processes and process assets to plan, manage, and
perform the work.
II 3.2 Evaluate the adherence to and effectiveness of the organizational
processes.
II 3.3 Contribute process-related information or process assets to the
organization.
Establish the necessary infrastructure to ensure that processes are built, followed, sustained,
and improved over time. The term “infrastructure” in this Practice Area refers to everything
needed to implement, perform, and sustain the organization’s set of processes. The
infrastructure includes:
• Recorded processes to reflect how work is done
• Resources, e.g., people, tools, consumables, facilities
• Funding to perform the processes
• Training to perform the processes
143
• Objective evaluations to ensure that work is performed as intended

Implementation Infrastructure addresses an organization’s or project’s set of processes, not the
model Practice Areas or practices. This ensures that processes are persistent and habitual, even
during times of stress or change. Implement processes to meet the intent of these practices to
improve process sustainment and integration throughout the organization.
Governance (GOV)
144
Level 1
II 1.1
Practice Statement
Perform processes that address the intent of the Level 1 practices.
Value
Improves the likelihood that solutions are complete, correct, and timely.
Establish the fundamentals of process discipline needed to efficiently and effectively develop
and deliver solutions to the customer. Solutions can be developed and provided without
following a recorded process or plan. The discipline with which these practices are performed
depends on the individuals managing and performing the work and can vary considerably.
An organization can successfully develop, deliver, and acquire solutions, even if:
• Processes are unrecorded, ad hoc, or chaotic
• Organizational infrastructure to support processes does not exist
• Success is based solely on competence and heroic efforts of people
However:
• Solutions may frequently exceed resource and schedule constraints
• Solutions do not consistently meet the customer’s requirements
• Success may not be repeatable
Example Activities
Perform processes.

Outputs of processes Refer to example work products in the Level 1 practices.
145
Level 2
II 2.1
Practice Statement
Provide sufficient resources, funding, and training for developing and performing processes.
Value
Having sufficient resources increases the likelihood of successful process improvement efforts.
To be sufficient, the right resources need to be available when they are needed. Sufficient
resources for developing processes should include:
• Funding
• Skilled people trained or experienced in:
o Process development
o Domain knowledge
o Quality assurance
• Appropriate tools
• Time to perform the work
Develop a budget to support process activities in addition to work activities. Provide funding for
developing the processes, which may include:
• Recording and updating the process
• Acquiring or building tools
• Developing training materials
• Providing training
• Providing post-deployment support to process users
• Evaluating the processes
Train the people who are responsible for developing processes and performing quality
assurance activities. Training supports successful process deployment by establishing a common
understanding and providing skills and knowledge needed to perform the process.
146
Example Activities
Identify needed resources. Includes identifying and assigning people with the needed
skills and experience.
Determine budget.
Provide funding.
Develop or buy tools.
Develop training materials.
Provide training.

Budget for resources
Training materials
List of needed people, roles, and skills
Tools
Training records

Governance (GOV)
Planning (PLAN)
II 2.2
Practice Statement
Develop and keep processes updated, and verify they are being followed.
Value
Minimizes waste by ensuring affected stakeholders focus on the most valuable activities that are
recorded in processes.
147

Understanding and recording a process is the first step in specifying the way work is to be
performed. A process can be recorded in many ways, but at a minimum includes a purpose,
inputs, a sequence of steps or activities, outputs, roles, and responsibilities. This helps ensure
repeatability and achievement of business and performance objectives. Verify that processes
are being followed and kept up to date.
A common example of a process description is EITVOX, which includes:
• Entry criteria
• Inputs
• Task or activity descriptions
• Verification and validation
• Outputs
• EXit criteria
Recorded processes provide support for consistent execution, repeatability of past successes,
and an approach for learning and improving. A recorded process reduces risks that can impact
quality, time-to-market, and customer satisfaction, including:
• Misunderstandings
• Unknown status
• Inconsistent performance
• Unavailable resources
• Unnecessary activities
• Missed activities
• Uncoordinated efforts
• Unclear roles and responsibilities
• Unachieved objectives
Example Activities
Identify process purpose.
Determine process description format.
Describe and record processes.
Perform processes.
Verify that processes are being Multiple techniques can be used, such as:
followed. • Objective evaluations
• Audits
• Retrospectives
• Process reviews
148

• Peer reviews
Review and update recorded processes
Communicate and make recorded This includes changes to existing processes as well as new
processes available. processes.

Recorded processes
Process verification results

Governance (GOV)
Peer Reviews (PR)
149
Level 3
II 3.1
Practice Statement
Use organizational processes and process assets to plan, manage, and perform the work.
Value
Leverages organizational learning and use of best practices, leading to:
• Reduced rework and cost
• Increased efficiency and effectiveness
Organizational process assets enable consistent process execution across the organization.
The availability and appropriate use of consistent organizational process assets help to:
• Perform planning and work activities based on proven practices
• Facilitate the transfer of personnel to where needs are most critical
• Reduce the likelihood of repeating issues and mistakes
• Apply process assets to provide the most benefit to projects and performance
Organizations typically maintain a set of standard process assets to be used and tailored
depending on the type of work performed. For example, an organization may have different
planning processes for various types of work.
Example Activities
Plan work using organizational process Tailoring of assets typically occurs during planning.
assets.
Manage work using organizational
process assets.
Perform work following organizational
process assets.

Tailored process assets May include:
• Templates specific for projects
• Processes and procedures specific for the project
• Lifecycle models specific for the project
150

• Operational definitions of measures specific for the project
• Checklists specific to a type of work
Work products resulting from using the
process assets
II 3.2
Practice Statement
Evaluate the adherence to and effectiveness of the organizational processes.
Value
Provides insight on potential cost-effective improvements to organizational processes and how
they are used.
Evaluating adherence helps ensure that processes and process assets are understood, relevant,
effective, and used as intended.
Assessing effectiveness of processes and process assets helps keep them relevant to the
business needs and strategy. Analyze processes and process assets periodically. This analysis
helps to understand their strengths and weaknesses and to continually improve them to provide
value to the organization.
Methods for evaluating adherence and effectiveness include:
• Observation
• Evaluations, assessments, or audits
• Interviews
• Analysis of the use of work products and results
Effectiveness includes:
• Ease of use
• Fewer mistakes
• Optimal use of resources
• Timely delivery
• Improved performance
• Increased customer satisfaction
151
• Capability that meets needs

When assessing effectiveness, some questions that may help are:
• Why are we doing this?
• Who is the target audience?
• Can this be done in a simpler way?
• What is working?
• What is not working?
Process performance measurements can also be used to analyze the effectiveness of a process.
The benefits of a process can be demonstrated by performance improvements such as:
• Meeting objectives
• Reducing costs
• Reducing defects
• Increasing productivity
• Reducing cycle time
• Increasing customer satisfaction
• Increasing market share
Example Activities
Evaluate processes for effectiveness and usefulness.
Analyze process performance measurement results.
Examine results of evaluations, appraisals, or audits.
Record and communicate results to affected stakeholders.
Submit improvement proposals.

Evaluation results Include:
• Organizational best practices
• Reusable process assets
• Issues, including:
o Non-compliance
o Effectiveness
o Behavioral
• Recommendations and opportunities for improvement
• List of major risks associated with process implementation
Analysis results Include:
• Process performance
• Trends in customer responses
152

o Satisfaction
o Complaints
• Solution reliability
• Defect insertion rate
• Cycle time
• Solution quality
• Root causes

Governance (GOV)
II 3.3
Practice Statement
Contribute process-related information or process assets to the organization.
Value
Increases return on investment by improving the organizational processes and process assets.
Contributing and using process-related information helps keep processes and process assets
relevant, current, and aligned with organizational needs. Users and implementers of processes
should contribute process use and improvement information to the organization and be involved
in determining what information will be kept and used.
This practice ensures:
• Projects systematically contribute to organizational learning
• Key intellectual capital does not leave the organization when people leave
• Future projects are able to draw from existing process assets to become productive
quickly
Collect process-related experiences such as:
153
• Best practices
• Work products
• Measures
• Lessons learned
• Process improvement proposals
Store measurement data in the organization’s measurement repository and other information in
the organization’s Process Asset Library (PAL). Make these available to those planning and
performing similar processes.
Example Activities
Collect and record best practices,
lessons learned, and information from
tailoring the processes.
Submit assets for potential inclusion in Include the context along with assets to make them more
the organization’s process asset library. useful.
Propose improvements to the
organizational process assets.

Examples, best practices, and lessons Include assets that:
learned • Worked well
• Are ineffective
• Could be improved
Tailoring records, rationale, If multiple projects tailor the same aspects of the process,
worksheets, and other related work this is an indication that the process may need to be updated
products associated with tailoring and
implementing the organization’s set of
standard processes for the work

154
Intent
Resolve and prevent disruptions promptly to sustain service delivery levels.
Value
Minimize the impact of disruptions to meet objectives and customer commitments more
effectively.
Practice Summary
Level 1
IRP 1.1 Record and resolve incidents.
Level 2
IRP 2.1 Develop, keep updated, and follow an approach for incident resolution
and prevention.
IRP 2.2 Monitor and resolve each incident to closure.
IRP 2.3 Communicate incident status.
Level 3
IRP 3.1 Develop, keep updated, and use an incident management system for
processing and tracking incidents and their resolution.
IRP 3.2 Analyze selected incident and resolution data for prevention of future
incidents.
Incident Resolution and Prevention involves:
• Identifying and analyzing incidents and related data
• Initiating specific actions to address incidents
• Monitoring incident status and escalating responses to incidents as necessary
• Identifying breaches of availability, reliability, and maintainability levels
• Identifying threshold breaches
• Identifying and analyzing the underlying causes, i.e. problems, of incidents
155
• Identifying and implementing workarounds or specific actions that enable continuity of

work
• Identifying and implementing preventative actions for future incidents
• Communicating the status and resolution of incidents to affected stakeholders
• Validating the complete resolution of incidents with affected stakeholders
• Leveraging successful workaround solutions for future events
Incidents are actual or potential events that indicate a negative impact on service delivery.
Organizations should address incidents in a timely and effective manner according to the terms
of applicable customer agreements and requirements. Resolving incidents may result in a
change to the service delivery approach.
Incident resolution and prevention includes developing a process to address incidents reported
by customers, end users, and affected stakeholders.
This process should include recording:
• Recurring incidents and their impact
• Underlying causes of incidents
• Workarounds
Examples of incidents include:
• Interruptions to a service or activity, e.g., website crash for an online store, equipment
failures in a factory, a power outage at a grocery store, a restaurant constantly running
out of a menu item, a concert cancelled because of weather, unusually long delays at an
understaffed call center
• Unacceptable performance, e.g., not delivering an order when promised, an elevator
that is stuck, an airline losing baggage
• Customer complaints
Addressing an incident may involve:
• Minimizing the effect of an incident
• Providing a workaround
• Removing the underlying cause or causes
• Monitoring the condition or series of events causing the incident
Any condition or event that contributes to the occurrence of one or more incidents is an
underlying cause. Underlying causes include:
• Root causes within the organization’s control
• Positive or negative conditions
• Conditions that the organization cannot change, e.g., weather conditions, shifts in
markets
It may not make business sense to remove all underlying causes. It may be more effective to
address incidents with workarounds or resolve incidents on a case-by-case basis.
156
Organizations can expect to reduce the reoccurrence of specific incidents by identifying and
resolving the root cause of the incident.
The approach to resolving incidents can be as simple as receiving notification of an incident and
communicating the workaround or resolution or it could be as complex as a multi-component
automated system managing multiple inputs and outputs.
Continuity (CONT)
Service Delivery Management (SDM)
157
Level 1
IRP 1.1
Practice Statement
Record and resolve incidents.
Value
Improves the ability to handle unexpected situations and still meet commitments.
Record incidents and address them. Some incidents could be beyond the project’s ability to
resolve.
Record the resolution of incidents to enable understanding of incident status.
Example Activities
Record incidents.
Address each incident. Examples of actions to address incidents include:
• Providing fixes
• Providing workarounds
Record incident status. Status examples include:
• Open
• Resolution in progress
• Closed

Updated list of incidents and their
status
158
Level 2
IRP 2.1
Practice Statement
Develop, keep updated, and follow an approach for incident resolution and prevention.
Value
Maintain customer satisfaction by addressing incidents in a consistent and efficient manner.
Record descriptive information sufficient for each incident to use during analysis and resolution
activities. Descriptive information about incidents enables more detailed analysis to determine
the best course of action to address incidents. Descriptive information can also help identify the
people best suited to address the incidents.
The approach to incident resolution and prevention may involve a help desk, service desk, or
similar function. This function typically:
• Communicates with the customer
• Accepts incidents
• Applies workarounds
• Addresses incidents
After analysis has identified the underlying causes of incidents, identify any solutions to reuse if
the incident occurs again. Personnel can identify additional solutions to prevent the recurrence
of similar incidents. Ensure that the best course of action is available to those who address the
underlying causes of incidents. Ensure that personnel manage actions to closure.
Use a workaround as a temporary solution for an incident until a better, more permanent
solution is identified, developed, and deployed. Reusable solutions, such as workarounds,
enable work to continue when an incident occurs. It is important to record and confirm the
effectiveness of workarounds and other solutions with customers and end users before reusing
solutions to address future incidents.
Example Activities
Identify incidents. Identified incidents can include those:
• Reported by the customer
• Reported by the end user
• Detected by automated detection systems
• Derived from the analysis of anomalies in collected data
159

• Derived from monitoring and analyzing external sources of
information, e.g., news services, websites
Record and keep updated
information that is useful in
managing, resolving, and
preventing incidents.
Define criteria and categories Facilitate incident resolution with an established set of categories,
for incidents and to determine severity levels, and other criteria for incidents. These predetermined
what is a valid incident. criteria enable prioritization, assignment, and incident escalation
quickly and efficiently.
Identify, record, and keep Examples of workarounds and responses include:
workarounds or agreed-upon • Taking an immediate, short-term action
responses updated. • Retraining personnel
• Updating documentation
• Notifying customers when incidents may not be avoidable, and
how to prepare for them
• Deferring responses until later
• Using closure codes to classify each incident; these codes are
useful when analyzing and categorizing data
Review incident resolutions with
Record lessons learned. Lessons learned by resolving incidents provide opportunities to
prevent similar future incidents by improving processes.

Example Work
Further Explanation
Products
Recorded incidents Examples of information to record about the incident may include:
and associated • Name and contact information of the person who reported the incident
information • Description of the incident
• Categories for classifying the incident
• Date and time incident occurred
• Date and time incident was reported
• Incident identifier, e.g., code, number
• Potential or actual cause of the incident
• Functions or groups involved in incident resolution and prevention
• Severity of the incident
• Priority of the incident
• Procedures employed
• Support tools used
• Conditions and steps to reproduce the incident
Incident criteria and Examples of incident severity typically include:
categories • Likelihood and impact of incidents
o Critical, high, medium, low
o Numerical scales, e.g., 1-5 with 5 being the highest
160
Example Work
Further Explanation
Products
• Escalation protocols
Incident categories vary depending on the context. For example, security
incident categories may include:
• Probes or scans of internal or external systems, e.g., networks, web
applications, mail servers
• Administrative or privileged access to accounts, applications, servers,
networks, etc.
• Distributed denial of service attacks, web defacements, malicious code,
e.g., viruses, malware
• Insider attacks or other misuse of resources, e.g., password sharing
• Loss of personally identifiable information
Incident resolution Typically includes:
and prevention • Incident resolution and closure criteria
approach • Current and new severity and priority levels
• Categories of actions
• Response and escalation procedures
• Customer-identified acceptable minimum or maximum amounts of time to
resolve an incident
• Roles, responsibilities, and authority for:
o Addressing underlying causes of incidents
o Monitoring and tracking the status of incidents
o Communicating the status of incidents
o Tracking the progress of actions related to incidents
• Escalation procedures
• Internal approvals, as required
• Communication mechanisms that customers and end users can use to
report incidents or used to notify affected stakeholders when one occurs
Records of stakeholder
reviews
Recorded workarounds
or responses
Recorded lessons
learned

IRP 2.2
Practice Statement
Monitor and resolve each incident to closure.
161
Value
Maximizes effectiveness of incident resolution to minimize disruptions.
Throughout the life of each incident:
• Track and record status of the incident
• Escalate the incident as necessary
• Record resolution of the incident
• Close the incident
Example Activities
Monitor incidents until they Monitor and record:
meet the terms of the • Communication with those who reported the incident
customer agreement. • Resolution of the incident
• Confirmation that the customer is satisfied
Escalate incidents as Track each incident throughout its life. Escalate incidents, as needed,
necessary. to the appropriate level of management or to affected stakeholders, to
ensure their resolution. For example, escalate incidents when:
• Affected stakeholders are not satisfied with the resolution
• The resolution is urgent or requires non-standard processes or
resources
Affected stakeholders may include:
• Service support tiers
• Management
• Different departments within the service organization
Close incidents that meet the Close incidents only when they meet the terms of the agreement.
criteria for closure.

Updated list of incidents and
their status
Closed incident records Incident records can include workaround information.

Monitor and Control (MC)
162
IRP 2.3
Practice Statement
Communicate incident status.
Value
Minimizes work disruption by ensuring that affected stakeholders have a common
understanding of the status of the incidents.
Communication is critical when incidents occur. Throughout the life of the incident,
communicate with the person who reported the incident and those affected by it.
Well-informed end users and customers may be more:
• Understanding
• Helpful in addressing the incident successfully
• Patient while waiting for a resolution
Manage internal communication and coordination to prevent incident resolution activities from
interfering with ongoing work.
Review the results of actions with the person who reported the incident to verify that the
actions resolved the incident and satisfied the submitter.
Example Activities
Communicate incident status. This can include status of workaround guidance.

Records of communication with
customers and end users
Status reports May include:
• Impact on service levels
• Frequency of incident occurrence
• Resolution status
163
Level 3
IRP 3.1
Practice Statement
Develop, keep updated, and use an incident management system for processing and tracking
incidents and their resolution.
Value
Maximizes reuse of information about past incidents to help resolve future incidents and
minimize cost.
An incident management system includes the storage media, procedures, and tools for
accessing the information about incidents.
Keep updated and available a collection of historical data covering:
• Addressed incidents
• Underlying causes of incidents
• Known approaches to addressing incidents
• Workarounds to support incident management
Example Activities
Establish an incident management This can include developing or purchasing an incident
system. management system. Examples of incident management
systems include:
• Indexed physical files of customer complaints and
resolutions
• Bug or issue tracking software
• Help desk software
An incident management system typically allows for the
storage, updating, retrieval, and reporting of incident
information that is useful to the resolution and prevention of
incidents.
Ensure that the incident management system allows for the
escalation and transfer of incidents among groups.
Maintain the integrity of the incident Examples of maintaining the integrity of the incident
management system and its contents. management system include:
• Backing up and restoring incident files
• Archiving incident files
164

• Recovering from incident errors
• Maintaining security that prevents unauthorized access
Maintain the incident management Maintenance includes removing obsolete information and
system. consolidating redundant information that accumulates over
time.

An incident management system with The storage media, procedures, and tools for incident
controlled work products management may be manual or automated.
Examples of storage media may include:
• Web database
• Cloud-based system
• Component of the service system
Procedures for accessing and using the
incident management system

IRP 3.2
Practice Statement
Analyze selected incident and resolution data for prevention of future incidents.
Value
Increase customer satisfaction by preventing incident recurrence.
This practice includes:
• Analyzing incidents and resolving them to continue delivery of the service, e.g.,
workaround or temporary resolution. The primary focus of this activity is to restore
service delivery to normal levels as quickly as possible. This may include developing
temporary reusable solutions.
• Selecting and analyzing incidents using criteria to develop solutions to prevent
recurrence. This activity involves identifying incidents and determining their causes, then
making changes to prevent them.
165

It is essential to establish a repository of all known incidents, their underlying causes, and the
courses of action taken to address them. Analyze the underlying causes of selected incidents to
help decide the best course of action to address and minimize the effect of similar incidents in
the future. Use this repository to quickly identify possible causes of selected incidents and
potential courses of action to address them, which may include:
• Addressing an incident as a unique case
• Increasing monitoring for additional occurrences of the same incident before action is
taken
• Communicating with or training end users
• Employing a previously established workaround or other known reusable solution for
handling similar incidents
• Doing nothing
If addressing underlying causes is too complex, costly, or results in further interruptions, the
workarounds or reusable solutions may be the best course of action. If the initial course of
action fails to resolve an incident or is only partially successful, conduct additional follow-up
analyses and take actions as needed.
Workarounds and other previously established reusable solutions may reduce the effect of
incidents significantly. Use known solutions to help reduce the time required to resolve incidents
and improve the quality of resolutions, including estimating the amount of time needed to fully
address an incident before the start of work. Record this information and make it available for
future use.
Example Activities
Categorize the incident. Use categories defined in the incident resolution and
prevention processes. Assign the relevant categories to the
incident in the incident management system.
Analyze the business impact of the This helps determine the priority and severity of each
incident. incident.
The business impact helps determine which incidents to
select for detailed analysis.
Decide which group is best suited to The group best suited to address the incident can depend on
address the incident. several different factors, including:
• Type of incident
• Locations involved
• Severity of the incident
The group should be suited to:
• Define the reusable solution
• Describe the steps involved
• Communicate this information
Examples of groups that deal with types of incidents include:
166

• Healthcare team that deals with adverse medical
outcomes
• Network support group that handles network connectivity
incidents
• Help desk that deals with password related incidents
• Building maintenance group that deals with facility issues
• Software engineering group that deals with system defects
Analyze incident data. For major incidents, consider assembling a team involving
people who are responsible for performing related tasks to
conduct analyses to identify underlying causes of incidents.
When identifying underlying causes, consider the impact to
other parts of the system and the severity of the relevant
incidents.
Decide the actions to address the Decide the best course of action for dealing with selected
incident. incidents in the future.
Examples of actions include:
• Replacing a broken component
• Notifying or reminding customers, end users, or service
delivery team members of correct procedures
• Releasing an announcement, e.g., press release, media
response, bulletin, notice to customers or other affected
stakeholders
• Conduct a peer review on software code to identify what
failed and how to fix it
• Perform a causal analysis
When analyzing incidents, record the actions taken to
address them. When an incident occurs, search a historical
collection of addressed incidents and known errors to see if
the incident is related to others. Retaining data allows for this
kind of analysis to save time.
Resolve the incident using the best Manage the actions until the effect of the incident is at an
course of action. acceptable level, and to address the underlying cause.
Managing the actions can include escalating the selected
incidents when the selected incidents have a large effect on
the organization or customer.
Addressing the underlying cause of selected incidents may
take considerable time or effort.
When addressing the underlying causes of incidents, actions
may include changes that:
• Reduce or prevent the occurrence of similar incidents
• Limit the impact of similar incidents
Record the actions and results in the For individual incidents, record the actions taken in the
incident management system. incident management system, including temporary, reusable
solutions.
• Include the time it took to resolve the incidents
167

• Include the solutions used to address the underlying cause
of the selected incidents and the results to support
analyzing similar incidents in the future
Verify and validate solutions to ensure For temporary reusable solutions, validate a reduction to the
that the incident works effectively. impact on service delivery.
For solutions that address underlying causes, validate
prevention of recurrence.
Communicate solutions to affected
stakeholders.

Updated incident management records May include:
• Incident category
• Severity
• Priority
• Analysis results, including best course of action
• Assignment for action
• Action taken
• New or updated reusable solutions accessible in the
incident management system
• Record of results of actions
Record of analysis results
Reports of underlying causes of
incidents
Reusable solution description Include the instructions for using the solution.
Plans for addressing underlying causes
of selected incidents
Verification and validation results for
the chosen courses of action

168
Intent
Manage performance using measurement and analysis to achieve business objectives.
Value
Maximizes business return on investment by focusing management and improvement efforts on
cost, schedule, and quality performance.
Managing performance helps to:
• Ensure that benefits and business performance are the leading factors in driving
performance and improvement
• Change the paradigm from “process improvement leads to performance improvement”
to “performance is the primary driver of process improvement”
• Use the results of measurement and analysis to manage and control performance at
various work and business levels
Performance and measurement management includes:
• Setting objectives for:
o The business
o Measurement and performance
o Quality and process performance
• Allocating and tracing objectives to subordinate levels in the business and processes
• Defining measurements to improve the understanding of progress towards achieving the
objectives
• Analyzing measurement and performance data to:
o Understand the relationship and interactions between performance and process
o Define and take actions to address any observed issues with achieving objectives
o Make the performance results and related benefits clearly visible to all
stakeholders
Measurement and performance objectives are quantitative or qualitative objectives that do not
require the additional rigor of statistical and other quantitative techniques. Quality and process
performance objectives apply to High Maturity activities using statistical and other quantitative
techniques. These objectives include the use of statistical and other quantitative techniques on
the related data.
169
Practice Summary
Level 1
MPM 1.1 Collect measures and record performance.
MPM 1.2 Identify and address performance issues.
Level 2
MPM 2.1 Derive and record measurement and performance objectives from
selected business needs and objectives and keep them updated.
MPM 2.2 Develop, keep updated, and use operational definitions for measures.
MPM 2.3 Obtain specified measurement data according to the operational
definitions.
MPM 2.4 Analyze performance and measurement data according to the operational
definitions.
MPM 2.5 Store measurement data, measurement specifications, and analysis
results according to the operational definitions.
MPM 2.6 Take actions to address identified issues with meeting measurement and
performance objectives.
Level 3
MPM 3.1 Develop, keep updated, and use organizational measurement and
performance objectives traceable to business objectives.
MPM 3.2 Follow organizational processes and standards to develop and use
operational definitions for measures and keep them updated.
MPM 3.3 Develop, keep updated, and follow a data quality process.
MPM 3.4 Develop, keep updated, and use the organization’s measurement
repository.
MPM 3.5 Analyze organizational performance using measurement and performance
data to determine performance improvement needs.
MPM 3.6 Periodically communicate performance results to the organization.
Level 4
MPM 4.1 Use statistical and other quantitative techniques to develop, keep
updated, and communicate quality and process performance objectives
that are traceable to business objectives.
MPM 4.2 Select measures and analytic techniques to quantitatively manage
performance to achieve quality and process performance objectives.
MPM 4.3 Use statistical and other quantitative techniques to develop and analyze
process performance baselines and keep them updated.
MPM 4.4 Use statistical and other quantitative techniques to develop and analyze
process performance models and keep them updated.
170
MPM 4.5 Use statistical and other quantitative techniques to determine or predict
achievement of quality and process performance objectives.
Level 5
MPM 5.1 Use statistical and other quantitative techniques to ensure that business
objectives are aligned with business strategy and performance.
MPM 5.2 Analyze performance data using statistical and other quantitative
techniques to determine the organization’s ability to satisfy selected
business objectives and identify potential areas for performance
improvement.
MPM 5.3 Select and implement improvement proposals, based on the statistical
and quantitative analysis of the expected effect of proposed
improvements on meeting business, quality, and process performance
objectives.
The term "process performance" refers to the "working level" where the solutions are being
developed or delivered, while the term "business performance" refers to the business or
organizational level. "Performance" can refer to either or both levels. For example, collect
measurement and performance data at the "work level" and aggregate data to enable
organizational performance analysis at the business level.
Estimating (EST)
Context Specific
Applying MPM practices, an agile project using Scrum will identify:

• Business objectives
• Measurement and performance objectives
• Analysis to conduct
• Actions to take
The project team will typically allocate these items to releases and sprints. Figure MPM-1
shows where measurement and performance play a role in an agile project using Scrum.
171
Figure MPM-1: Measurement & Performance Role in Scrum
An agile project using Scrum can obtain benefits from practices in this practice area by:
• Defining and employing clear objectives; this typically goes beyond a single iteration and
might include meeting specific deadlines within a financial budget for a given scope.
Objectives might include achieving a certain velocity over successive sprints to be able
to satisfy the business need.
• Clarifying and employing operational measurement definitions
o Defining how velocity is calculated:
 Is it story points per person, or per team?
 Does it include overhead time and significant interruptions?
o Defining a set of reference story points within the team as part of the operational
measurement definition
• Defining how measurements are collected, analyzed, and recorded by agile teams
• Defining to whom the measurement and performance data should be communicated
• Using measurements to track and improve agile team performance based on defined
objectives
A typical agile team using Scrum might have the following measurements, which help assess
performance:
172
Figure MPM-2: Release Burndown Chart & Sprint (Iteration) Burndown Chart
• Release Burndown Chart (refer to Figure MPM-2)

This chart shows the number of story points remaining over time, tracked within each
sprint, and representing all of the work for a release consisting of several sprints. The
performance objective of this work is to burn down a target number of story points
within a release within a given timeframe using a set of resources.
This chart shows:
o the number of story points completed (“Value delivered”)
o those points forecasted across all planned sprints
o all of the work for a release
The performance objective of this work is to understand what value has been delivered,
and to help forecast what might be delivered in future sprints related to the release.
While the Scrum Guide has discontinued the use of the Release Burndown chart, many
companies still find value in its use.
The measurement tracks the remaining story points, and the performance analysis
determines any deviation and the associated reason. For example, overcommitting to
story points, or people unexpectedly on sick leave. Actions may be taken, such as
postponing user stories to later releases, adding more resources, or removing
impediments.
• Sprint (Iteration) Burndown Chart (refer to Figure MPM-2)
173
This chart shows the remaining story points that have been forecasted for the sprint,
which are updated daily. The performance objective (forecast) is to complete the
planned stories within the sprint using a constant set of resources. The measurement
gives the remaining points (value) to be delivered, and the performance analysis
collected through visual information indicators and daily standups informs the team of
any deviation and their reasons, e.g., the code is difficult to modify. Actions may be
taken, such as backlog grooming, refactoring, or removing other impediments. In this
case, the team determined that the best way to get back on plan was to refactor the
code.
Context Specific
Supplier Management
An acquirer establishes measurement objectives for its activities and work products and for
supplier activities and deliverables. Measurement and analysis of solution components provided
by suppliers is important to effectively manage the quality and costs of the project. Careful
management of supplier agreements can provide insight into data that supports supplier
performance analysis. The supplier agreement should include:
• Measures for the supplier to collect and report
• Data collection processes and timing for the supplier to use
• Expected analysis of supplier data
• Required storage of supplier data
Identify additional measures to track and achieve interface or connection interoperability in
projects where multiple acquired solutions deliver a capability to the end user or where there
are relationships with other projects to acquire joint capabilities.
The acquirer specifies measures to:
• Gauge its own progress and output
• Monitor supplier performance and progress per contractual requirements
• Gain insight into the status of the evolving solutions acquired
174
Level 1
MPM 1.1
Practice Statement
Collect measures and record performance.
Value
Enables performance management to increase likelihood of meeting objectives.
Collect available data to provide the team and management with insight into performance.
Identify data that can be used to manage the project. Identifying and using this data leads to
effective performance management.
If limited data are available, senior management should identify the basic set of information
needed to manage the project.
The collection of similar performance measurements at the work level can be aggregated
upwards to form the basis for performance management within an organization. For success,
senior management and other stakeholders should record and communicate current
performance needs and business objectives.
Example Activities
Identify available measures and Collection methods may include:
collection methods. • Surveys
• Observation
• Direct recording
• Statements by customers, clients, or other stakeholders
• Industry comparison
Current business performance data may include:
• Customer satisfaction
• Sales
• Profit and loss
Process performance data may include:
• Adherence to schedule and budget
• Estimates and significant deviations
• Quality data, e.g., defects, warnings, customer
complaints, returns, incidents
Collect and record measures to Determine if collected performance data is relevant and
understand performance. critical to the work and the business.
175

May include:
• Results from measurement and collection
• Discussion and interpretation of results
• Usage of results
Record data from:
• Business performance
• Current and planned process performance
• Performance improvements
Performance data may:
• Include single or smaller efforts addressing performance
and performance improvement
• Originate from plans that have been developed at any
level, e.g., performance initiative, process initiative, team,
organization, product characteristics
Record performance and communicate Results may be stored in available tools and reported
results. periodically or on an event-driven basis.

Measures May include:
• Product measures
• Process measures
• Quality measures
• Customer measures
• Employee measures
Performance analysis results May include:
• Business performance
• Employee satisfaction
• Quality expectations
Context Specific
Supplier Management
Acquiring organizations need to identify the data needed to provide insight into supplier
activities and performance. The supplier agreement must include any data expected from
suppliers.
176
MPM 1.2
Practice Statement
Identify and address performance issues.
Value
Improves the ability to achieve objectives and increases customer satisfaction.
Identify issues by comparing performance with available performance data such as:
• Industry data
• Customer requirements
• Previous performance
• Planned performance
• Objectives
Record performance issues, their causes, and possible solutions. Proposed suggestions can be
used to spread successful performance improvements to other projects.
Example Activities
Collect measurements and derive performance data.
Review performance.
Identify issues associated with performance.
Understand the causes for performance issues.
Make suggestions to improve performance.
Address performance issues based on suggestions.

List of performance issues May include:
• Issues characteristics
• Reasons for issues
• Resolution options
• Actions taken for resolution
List of suggestions May include:
• Description
• Suggestions selected for implementation
177
Level 2
MPM 2.1
Practice Statement
Derive and record measurement and performance objectives from selected business needs and
objectives and keep them updated.
Value
Aligns measurement and performance activities to increase the likelihood of achieving business
results.
Measurement and performance objectives, along with the related data, provide stakeholders
with the information needed to understand performance against business objectives. This
supports realistic planning and helps avoid duplicative and ineffective performance improvement
activities. This practice addresses measurement objectives at the project level. Projects may
determine that they need to establish a project measurement repository to support these
activities.
Measurement objectives provide a common basis for employees and senior managers to
measure progress and improve or remove ineffective practices. Objectives and measures help
to:
• Provide insight into actual size and effort completed compared to the plan
• Provide insight into schedule fluctuations and progress
• Provide insight into actual costs compared to plan
• Identify unplanned work or scope creep
• Determine the cost and schedule impact of rework
• Evaluate the effectiveness of defect detection throughout the solution lifecycle
• Evaluate supplier performance
Analysis of performance information can indicate where modifications to the identified
information needs and objectives are required. Determine whether the value of the result is
aligned with the resources dedicated to doing the work.
Sources of information needs and objectives include:
• Customer and stakeholder expectations
• Established management objectives
178
• Strategic plans
• Business plans
• Formal requirements or contractual obligations
• Work plans
• Work performance monitoring
• Process improvement plans
• Interviews with senior managers and others who have information needs
• Recurring or persistent issues
• Supplier agreements and contractual requirements
• Experiences of other workgroups or organizational entities
• External industry benchmarks
Example Activities
Identify current or planned Collect information about performance improvements, e.g.,
performance improvements. intention, objectives, actions, timeframe.
Record and prioritize business needs Set priorities within the limits of available resources.
and objectives.
Review and keep updated • In the review, include the purpose, value, and intended
measurement and performance uses of objectives
objectives. • Record, keep updated, and have stakeholders review
measurement and performance objectives
• Involve users and providers of measurement,
performance, and analysis results in setting measurement
objectives and deciding on plans of action
Review business needs and objectives Identified business needs and objectives can be refined and
against measurement and performance clarified as a result of setting measurement and performance
objectives, as needed, with affected objectives. Reviewing business needs and objectives against
stakeholders. measurement and performance objectives is an iterative
process. It is possible that:
• Measurement and performance objectives are not aligned
with business needs and objectives
• Initial descriptions of business needs are ambiguous

Measurement and performance Examples of objectives include to:
objectives • Meet commitments for:
o Budget
o Schedule
o Quality
• Increase:
o Customer satisfaction
179

o Employee satisfaction
o Innovation and creativity
• Reduce:
o Customer complaints
o Errors and rework
o Environmental impact
Context Specific
Supplier Management
For objectives defined in supplier agreements, the acquirer defines measures that provide
insight into the performance of suppliers, including the quality of their deliverables.
Measurement objectives focus on acquirer performance, supplier performance, and
understanding the effects on customer, operational, and financial performance. Supplier
measurement objectives help to define and track service level requirements recorded in the
supplier agreement.
Derive measurement objectives needed to:
• Maintain alignment to project objectives and provide results that keep a project on track
to its successful conclusion
• Support the organization’s ability to develop an infrastructure that reinforces and grows
acquirer capabilities, including those related to processes, people, and technologies
• Support the ability to monitor and manage financial results and customer expectations
Review appropriate measurement objectives with potential suppliers throughout the solicitation,
obtaining their feedback and commitment.
Example supplier deliverables include:
• Quality performance data
• Performance against agreed to service levels
• Cost and effort data
Include required supplier deliverables in the supplier agreement.
MPM 2.2
Practice Statement
Develop, keep updated, and use operational definitions for measures.
180
Value
Operational definitions increase the consistency of measures and the likelihood that business
needs and objectives are met efficiently and effectively.
Operational definitions of measures enable consistent collection, analysis, use, and
understanding of measurements, performance, and results.
Use of operational definitions increase the:
• Data quality
• Understanding and use of measurements
• Usefulness of historical information
• Ability to make informed management decisions
State operational definitions in clear and unambiguous terms. Operational definitions help to
establish a consistent understanding of measurements and their use. Operational definitions
address two important criteria:
• Communication: What has been measured, how was it measured, what are the units of
measure, and what has been included or excluded?
• Repeatability: Can the measurement be repeated, given the same definition, and get the
same results?
Define collection and storage methods to help ensure that the right data are collected
consistently and stored in the right place. Storage and retrieval procedures help to ensure that
data are available and accessible by the right people for future use.
Specify the analysis procedures to:
• Ensure that the necessary data will be collected
• Ensure the quality of data
• Help minimize subjective interpretation
• Lower the risk of reaching incorrect conclusions due to inappropriate analysis techniques
or lack of understanding
Refine measurement and performance objectives into precise, quantifiable measures. Ensure
that traceability between the measurement and performance objectives and the related
measures is clear, available, bidirectional, and kept updated.
Measures can be either base or derived. Obtain data for base measures by direct measurement.
Data for derived measures typically come from combining two or more base measures. Derived
measures are often expressed as ratios, composite indices, or other aggregate summary
measures.
181
Table MPM-1: Base and Derived Measurement Examples

Measurement
Examples
Type
Base measures Commonly used base measures include:
• Measures of size, e.g., number or count of items or activities, pages, number of
requirements
• Measures of effort and cost, e.g., number of person hours, headcount
• Quality measures, e.g., number of defects by severity, rework amount before and
after delivery
• Information security measures, e.g., number of system vulnerabilities identified
• Customer satisfaction survey scores
Derived Examples of commonly used derived measures include:
measures • Earned value
• Productivity
• Rework percentage
• Peer review coverage
• Test or verification coverage
• Reliability, e.g., mean time to failure or error
• Maintainability, e.g., system or service down time
• Quality, e.g., number of defects by severity/total number of defects
• Information security, e.g., percentage of system vulnerabilities mitigated
• Customer satisfaction trends
There are direct relationships among information needs, measurement and performance
objectives, types, or categories of measurement, base measures, and derived measures. This
direct relationship is depicted using some common examples in Table MPM-2.
Table MPM-2: Example Measurement Relationships

Information Example
Example Information Example Base
Purpose Type or Derived
Objective Need Measures
Category Measures
Shorten time What is the Provide Schedule and Estimated and Schedule
to delivery. estimated insight into progress actual start and Performance
Be first to delivery time? schedule end dates by Schedule
market the fluctuations task estimation
solution. and progress. accuracy
Increase How accurate Provide Size and Estimated and Productivity
market share are the size insight into effort actual effort
by reducing and cost actual size and size
costs of estimates? and costs
solutions. compared to
plan. Effort and Estimated and Cost
cost actual cost performance
Cost variance
182
Information Example
Category Measures
Deliver Has scope or Provide Size and Requirements Requirements
specified work size insight into stability count volatility
functionality. grown? actual size Size estimation
compared to accuracy
plan, identify
unplanned
growth.
Reduce defects Where are Evaluate the Quality Number of Defect
in solutions defects being effectiveness defects inserted containment
delivered to inserted and of defect and detected Defect
the customer detected prior detection Solution size
by 10% to delivery? throughout density
without the solution
affecting cost. lifecycle.
What is the Determine the Cost Number of Rework costs
cost of cost of defects inserted
rework? correcting and detected by
defects. lifecycle phase
Effort hours to
correct defects
Labor rates
Reduce What is the Evaluate the Information Number of Percentage of
information magnitude of effectiveness assurance system system
system open system of mitigating vulnerabilities vulnerabilities
vulnerabilities. vulnerabilities? system identified, and mitigated
vulnerabilities. number of
system
vulnerabilities
mitigated
Increase How Determine the Organizational Number of new Innovation
innovation in innovative are level of creativity ways to do trends,
solutions. the solutions? innovation of things. percentage of
past, current, Innovation can adjacent,
and future include: disruptive,
solutions. Sustaining or breakthrough
Adjacent and new
Disruptive market
New Market innovations,
Breakthrough processes that
address
innovations,
incentives for
innovation
183
Example Activities
Identify existing measures Specifications for measures, sources, and collection mechanisms may
that address measurement already exist.
objectives and are available
or collected from current
work products, processes, or
transactions.
Select measures that provide Select measures for the selected product and process attributes.
insight into the organization’s Examples of systematic approaches to select measures include:
quality and performance.
• Goal Question Metric (GQM)
• PSM (Practical Software and Systems Measurements)
• AIM (Accelerated Improvement Method)
Examples of criteria used to select measures include:
• Relationship of measures to the organization’s objectives
• Coverage that measures provide over the life of the solution
• Visibility that measures provide into performance
• Frequency at which observations of the measure can be collected
Establish operational May include:
definitions for the selected • Collection steps and rules
measures. • Functions or algorithms used to produce derived measures
• Analysis procedures
• Decision criteria - Numerical thresholds, targets, or limits used to
determine need for action, e.g., 20% variance from plan requires
re-planning
Specify how to collect and Develop data collection mechanisms and process guidance. Data
store data for each required collection mechanisms can include:
measure. • Manual or automated methods
• Forms, templates, and tools
• Mechanisms for ensuring data quality
Select data analysis methods Issues to be considered typically include:
and tools. • Choice of analysis techniques
• Choice of visual display and other presentation techniques, e.g., pie
charts, bar charts, histograms, radar charts, line graphs, scatter
plots, tables
• Decisions about how to handle analysis in the presence of missing
data elements
• Selection of appropriate analysis tools
During data analysis, consider:
• Interrelationships among specified measures
• Changes over time
Review operational definitions
with affected stakeholders
and keep them updated.
184

Operational definitions of Typically includes:
measures • Name
• Description, context, and purpose
• Reason for the measure, e.g., performance, legal, management
• Visual display of measure (indicator)
• Data elements for derived measures
• Definition for each element
• Data collection
• How data are collected
• When data are collected
• Who will collect data
• Forms and templates for collection
• Tools for data collection
• Validation and quality
• Data reporting
• Responsibilities
• To whom data are reported
• Frequency of report
• Algorithm or calculation for derived measures
• Any assumptions
• Interpretation for the measure
• Analytic techniques
• Traceability to objectives and source
• Cross reference to any other measures
Analysis methods and tools
Data collection mechanisms
Context Specific
Services
When selecting measures for managing service capacity and availability, consider supported
activities, reporting requirements, information use. Commitments and agreements should
include the selected measures and analytic techniques. Analysis should include describing the
relationship between identified measures and requirements and deriving objectives that state
specific target measures or ranges to meet for each measured attribute. Capacity and
availability measures should be traced to requirements. Tools needed to support the collection
and analysis of capacity and availability data should be identified, used, and kept updated.
Examples of availability measures include:
• Percentage available within agreed hours (this availability can be overall availability or
component availability)
• Percentage unavailable within agreed hours (this unavailability can be overall
unavailability or component unavailability)
185
• Duration of downtime due to failure, typically minutes, hours, or hours per week
• Failure frequency
• Degree of effect, e.g., number of affected users, number of minutes that users lost
productivity, number of transactions or vital business functions not processed or carried
out, number of applications impeded
• Response time of the system to incidents, transaction response times, and response
times (as a capacity measure or availability measure)
• Reliability, e.g., number of breaks, mean time between failures, mean time between
incidents
Examples of capacity and availability measures include:
• Use of limited resources
• Use of components
• Unused limited resources
• Unused components
• Throughput, e.g., number of concurrent users, number of transactions to process
• Queue length (maximum and average)
• Number of a type of resource or one or more specific resources in use a selected
number of times (this use can be monitored by calendar time)
Table MPM-3 depicts some common examples of measurement relationships in the context of
services.
Table MPM-3: Example Measurement Relationships
Information Example
Category Measures
Provide agreed Can the Provide insight Service • Number of • Service
service continuity. service into whether continuity services with continuity
provider the service recovery test confidence rate
recover provider will failures
services from implement • Total number
disasters or service of services in
major continuity the service
disruptions plans catalog
within agreed successfully to
timeframes? provide agreed
service
continuity.
Provide Are there Provide insight Capacity • Total number • Average service
appropriate enough into resource of service time
capacity to meet resources (or utilization, idle requests • Service provider
business needs. too many) to resources, and • Available resource
inadequate service utilization
provider
186
Information Example
Category Measures
meet demand capacity to personnel
for services? meet demand. hours
• Service time
Provide effective How effective Provide insight Service • Number of • Service rework
services. is the service? into performance service rate
percentage of requests
reworked reworked
service • Total number
requests. of service
requests
Provide Is the service Provide insight Availability • Agreed • Availability
appropriate, provider into the service time
agreed service providing availability of • Downtime
availability. appropriate, the service.
agreed service
availability?
Is the service Provide insight Availability • Available • Reliability as
reliable as into the time (in mean time
agreed? reliability of the hours) between
service. • Total failures (MTBF)
downtime (in
hours)
• Number of
breaks in
service
(interruptions
to normal
service)
Supplier Management
The acquirer uses defined supplier measures and measures of acquirer progress and output to
manage the project. Define measures needed to manage the acquirer’s performance objectives,
some of which need to be provided by suppliers. Incorporate the measures that suppliers collect
and report in the supplier agreement and service level agreements.
Define acceptance criteria to enable the intended use of supplier measures, such as potential
aggregation and analysis. These criteria should include criteria associated with the collection
and transfer mechanisms and procedures that the supplier performs. Consider all supplier
measure characteristics that can affect their use, such as differences in financial calendars used
by different suppliers.
187
The supplier may provide measures as detailed measurement data or measurement reports.
Align measures that come from suppliers with the acquirer’s acceptance criteria for supplier
measures. Record acceptance criteria in measurement specifications or checklists.
MPM 2.3
Practice Statement
Obtain specified measurement data according to the operational definitions.
Value
Quality data improves decisions and increases the likelihood of successfully completing projects.
Measurement results can help to:
• Monitor progress and performance
• Monitor response times
• Fulfill recorded obligations
• Make informed management and technical decisions
• Determine when corrective actions need to be taken
• Build historical data for use in future analysis
Example Activities
Collect data for currently specified base
measures.
Calculate derived measures.
Check data integrity as close to the Data integrity covers three aspects:
source of data as possible. • Accuracy and precision
• Coverage
• Completeness
Checklists are useful for verifying data integrity.

Base and derived measurement data
Results of data integrity checks
188
Context Specific
Supplier Management
Obtain derived measures from the supplier as defined in the supplier agreement. The acquirer
should ensure the supplier agreement specifies supplier data requirements for frequency,
accuracy, and consistency. Follow up with suppliers if data is not available or data integrity
checks indicate potential data errors.
Use acceptance criteria to verify:
• The results of data integrity tests conducted by the supplier
• The integrity of the supplier data
• Base and derived supplier measurement data sets
• Results of data integrity tests of supplier measurement data
• Supplier data collection frequency
• Regulatory and statutory compliance data
MPM 2.4
Practice Statement
Analyze performance and measurement data according to the operational definitions.
Value
Analysis provides insight into performance and actions needed to meet objectives.
Compare measured performance to measurement and performance objectives to help
determine the organization’s ability to meet objectives. Identify potential areas of improvement
by analyzing performance shortfalls. Use this information to develop, evaluate, and prioritize
proposed improvements, and identify additional areas for analysis.
189
This practice also lays the groundwork for understanding performance with a wide range of
stakeholders. It is important to make performance visible within and beyond the project. This
communication includes the benefits obtained from performance improvements and may also
be a trigger for further performance improvements.
Example Activities
Perform analyses, interpret results as Typically, the analyses are specified in the operational
planned, and draw conclusions. definition.
Results of planned analyses can identify the need to:
• Complete additional, unanticipated analyses
• Reevaluate capacity, availability, reliability, and
maintainability trends; it may be advisable to perform a
failure trend analysis
• Refine existing measures
• Calculate additional derived measures
• Collect data for additional base measures to properly
complete the planned analysis
Record analysis results and any
significant deviations.
Review results with affected Reviewing the results with stakeholders can prevent
stakeholders. misunderstandings and lead to improvements in the data
analysis and reporting.
Ensure that results are:
• Understandable
• Easily interpretable
• Clearly tied to identified information needs and objectives
The analysis may not be clear to those who are not
measurement experts.
Communication may include:
• How to interpret results based on the evaluation methods
used
• How results address information needs
• How results may affect the project
Examples of actions taken to help others to understand
results include:
• Providing training on the use and understanding of
measurement results
• Discussing the results with stakeholders
• Modifying the approach for communication
• Providing background and explanation
Refine measurements and analysis Performing data analyses and preparing results can lead to
techniques in the operational improved future efforts based on lessons learned. These
definitions. lessons learned can lead to:
• Improved measurement specifications
• Improved data collection procedures
• Ideas for refining information needs and objectives
190

Performance data analysis results May include:
• Alignment to objectives
• Results and conclusions
• Identified performance shortcomings
• Improvement candidates
• Recommended actions
Updated operational definitions

Context Specific
Supplier Management
The supplier agreement should specify supplier requirements for analyzing measurement data,
including the definition and examples of measures the supplier must provide to the acquirer.
Example measurement analysis activities acquirers can perform with suppliers include:
• Discussing results and preliminary conclusions with suppliers
• Coordinating additional analyses with suppliers
• Reviewing initial results related to supplier progress or output with suppliers and
determining if revisions are appropriate based on their response
• Updating data acceptance criteria for supplier measures
• Reviewing service level performance
Consider validating data collected from a supplier through periodic audits of the supplier for
acquirer required measures. This may be defined in the supplier agreement.
Review specified analyses and reports with suppliers and identify their commitment to support
the analysis. Review recommendations they may provide related to the analysis of
measurement data.
MPM 2.5
Practice Statement
Store measurement data, measurement specifications, and analysis results according to the
operational definitions.
191
Value
Storing measurement data enables analysis of performance which enables repeating successes.
Storing measurement data and information:
• Enables multiple options for analysis now and in the future
• Enables its timely and cost-effective use as historical data and results
• Makes historical data and results readily available to stakeholders
Provide sufficient context for interpretation or application of:
• Measurement data
• Analysis techniques
• Analysis results
Stored information contains or refers to other information needed to understand and interpret
the measures and to assess them for reasonableness and applicability, e.g., measurement
specifications used on different projects when comparing across projects.
Projects can choose to store specific data and results in a project-specific repository. When data
are shared across projects, the data can reside in the organization’s measurement repository.
Example Activities
Review data to ensure their quality.
Store data according to data storage
procedures.
Make stored data available for use.
Prevent stored information from being Control access to data and educate people on the
used inappropriately. appropriate use of data.
Examples of inappropriate data use include:
• Disclosure of information provided in confidence
• Faulty interpretations based on incomplete, out-of-
context, or otherwise misleading information
• Measures used to improperly evaluate the performance of
people
• Questioning the integrity of individuals
Observe legal and regulatory requirements as to who can
store which information and who can access them.
192

Stored data May include:
• Context for data
• Sets of data that were collected
• Analysis reports and presentations
• Retention period for stored data
• Data security
Context Specific
Supplier Management
The acquirer protects measurement data provided by the supplier according to the supplier
agreement. The supplier agreement might specify that the acquirer must restrict access to a
supplier’s measurement data.
Information stored includes data acceptance criteria for supplier data.
The supplier agreement specifies:
• Measurement data the supplier must provide to the acquirer
• The format the supplier should use for providing data to the acquirer
• How the supplier will collect and store measurement data, e.g., retention period of data
• How and how often the supplier will transfer data to the acquirer
• Who has access to data
• Regulatory requirements
• Provisions for handling proprietary data
Develop mechanisms to transfer measurement data and process guidance from the supplier to
the acquirer. The acquirer can integrate data collection from a supplier with periodic monitoring
and review of supplier activities. In the supplier agreement, the acquirer should specify the
applicable standard report formats and tools the supplier will use for reporting.
Review data collection and storage procedures with suppliers throughout the life of the
agreement. Update data collection and storage procedures, as needed, and obtain supplier
commitment to collect and store measurement data and reference procedures in the supplier
agreement.
193
MPM 2.6
Practice Statement
Take actions to address identified issues with meeting measurement and performance
objectives.
Value
Understanding performance status helps to meet objectives.
Obtain performance information and data at the appropriate level, e.g., business, projects,
process. Use analysis results to ensure sustainment and improvement. If the observed
performance deviates from expected results, take appropriate actions to correct the deviation.
Potential actions to correct significant deviations include:
• Performing causal analysis activities to identify and correct the cause of the deviation
• Re-planning
• Initiating improvement activities
• Renegotiating objectives
Example Activities
Record and implement corrective
actions and manage to closure.
Record and submit proposed
improvements and communicate
results.

Revised objectives, plans, and
commitments
Records of performance evaluations May include:
• Comparison of planned vs. actual performance
• Proposed improvements
Records of significant deviations May include:
• Past actions and improvements
• Side effects of actions and improvements
Proposed improvements Include:
• Source of the proposed improvements
194

• What is improved by each proposed improvement

195
Level 3
MPM 3.1
Practice Statement
Develop, keep updated, and use organizational measurement and performance objectives
traceable to business objectives.
Value
Linking measurement and performance objectives to business objectives optimizes resource
usage to achieve and increase business success.
Develop, review, and analyze business objectives. Derive business objectives based on
organizational structure, e.g., divisions, sectors, departments, services, projects, teams. The
scale and variation of the allocation of objectives across sub-levels can depend on the business
strategy and tactics, customer base, size, complexity, and solution lifecycle. Once completed at
the organizational level, allocate organizational measurement and performance objectives to the
project level.
In order to formulate organizational measurement and performance objectives, affected
stakeholders should understand the:
• Organization’s business model
• Business context
• Related critical factors necessary to ensure the future success of the organization
These factors help to align measurement and performance needs and objectives at both the
organizational and project levels.
Allocate organizational measurement and performance objectives to appropriate subordinate
units down to the project level. Review these allocated objectives, for meaning and usefulness
within their context, with the affected stakeholders. Ensure that the measures and performance
data used contribute to understanding performance at both the project and organizational level.
Elevate project measurement and performance objectives as appropriate, to the organizational
level for deployment to other projects. Iterate this process between the organization and
projects.
Example Activities
Develop, review, and analyze the Analysis may include:
business objectives that drive • Business objectives
measurement and performance • Current performance data and baselines
objectives. • Current distribution of objectives to sub-units
196

• Business and organizational models
• Critical success factors
• Customer data
• Competitor data
Develop, record, and use
organizational measurement and
performance objectives and keep them
updated.
Analyze the performance of projects Analyze this information periodically or on an event-driven
within the organization. basis to meet the organization’s needs and to determine how
it contributes to organizational performance and meeting the
objectives.
Work with affected stakeholders to
allocate organizational measurement
and performance objectives to
projects.
Trace new and revised measurement
and performance objectives to
business objectives.
Review and update the allocations of
measurement and performance
objectives and communicate with

Business objectives
Measurement objectives Measurement objectives may address more than just
performance, such as:
• Measurement calibration data (accuracy, precision)
• Measurements for regulatory purposes or customer
demands
• Deployment, progress, and implementation status
Performance objectives
Allocated measurement and Include:
performance objectives • Allocation of organization objectives to projects
• Rationale and context for the allocation
197
MPM 3.2
Practice Statement
Follow organizational processes and standards to develop and use operational definitions for
measures and keep them updated.
Value
Enables consistent collection, understanding, and use of organizational measurement and
performance data to improve performance and increase likelihood of success.
Organizational processes and standards levy requirements for operational definitions that are to
be implemented and used throughout the organization. This promotes consistent:
• Definition
• Collection and storage
• Aggregation
o Across projects
o Up to the organization or business level
• Analysis and understanding
• Reporting and recording
Example Activities
Record, communicate, and use
organizational standard operational
definitions for selected measures and
keep them updated.
Revise the set of operational definitions Periodically evaluate measures for their continued
of measures as needed. usefulness.

Operational definitions following
organizational standards
198
MPM 3.3
Practice Statement
Develop, keep updated, and follow a data quality process.
Value
Ensures that use of the measurement and performance data results in better decision making.
Data quality focuses on integrity in areas such as the completeness and correctness of
performance and measurement information. Data quality ensures:
• Measures adhere to their operational definitions
• Data integrity of the measurement repository enables:
o Efficient and effective operations, decision making, and planning
o Decision error reduction
o Performance improvement
Develop a process to analyze and improve data quality by:
• Minimizing measurement system errors
• Introducing controls to ensure that data inputs are valid
• Ensuring that metrics and measurements support effective decision making
• Understanding the accuracy, completeness, and coverage of the data
• Providing adequate training
Example Activities
Develop criteria for data quality,
accuracy, precision, and validity.
Objectively evaluate the measurement Determine and plan the frequency of evaluations.
repository and data to determine if the
data quality criteria are met.
Identify and communicate data quality
issues and track to closure.
Identify and communicate data
improvement proposals.
199

Data quality criteria
Measurement repository data quality
report
Data quality issues
MPM 3.4
Practice Statement
Develop, keep updated, and use the organization’s measurement repository.
Value
Timely access to measurement and performance data supports informed decisions leading to
more successful projects.
Develop a repository to store and retrieve measurement data that can be used to:
• Understand and improve performance
• Support the evolution of a more efficient and effective data set for use throughout the
business
• Improve and sustain processes
• Support planning
• Support analysis
The measurement repository:
• Contains project, process, and performance measures that are related to the
organization’s set of standard processes.
• Contains or refers to the information needed to understand, interpret, and assess
measures and performance for reasonableness and applicability.
• Contains up-to-date and correct information. Maintaining the repository is important
since objectives and related measures and performance change over time.
200
Example Activities
Determine the organization’s needs for This results in understanding and recording the requirements
storing, retrieving, and analyzing for the measurement repository.
measurements.
Design and implement the Functions of the measurement repository include:
measurement repository. • Supporting effective comparison and interpretation of
measurement and performance data
• Providing sufficient context to quickly identify and access
data in the repository
• Improving the estimation, measurement, and performance
accuracy and precision through use of historical data
• Supporting the understanding of performance
Populate the contents and
communicate the availability and
benefits of the measurement
repository.
Revise the measurement repository as For example, revise when:
needs change. • Measurement and performance objectives change
• New processes are added
• Processes are revised and new measures are needed
• Data with finer granularity is required
• Greater visibility into the process and performance is
required
• Measures are no longer used

Measurement repository design The system design should address:
• Repository structure
• Required content
• Related systems or subsystems
• Collection
• Support environment
• Retrieval mechanisms
• Security
• Retention
• Maintenance
• Data validation
• Standard reporting
Organization’s measurement repository
Organization’s measurement data
201
MPM 3.5
Practice Statement
Analyze organizational performance using measurement and performance data to determine
performance improvement needs.
Value
Analyzing and improving performance contributes to business success.
Identify, record, and use aggregation rules for measurement and performance data and keep
them updated.
Identify potential areas for improvement through analysis at the organizational level. Determine
areas that could address process performance shortfalls. Use analysis to evaluate and prioritize
potential improvements. Identify processes and technologies that will have the largest effect on
achieving those improvements. Ensure that each performance improvement is traceable to
processes and business objectives.
Compare data before and after performance improvements are implemented to ensure the
improvements were effective. Aggregate data from various projects to the organizational level
and then compare the results with business objectives. Communicate the results, achieved
benefits, and the satisfaction of objectives to stakeholders.
Example Activities
Aggregate performance data to the
business level.
Analyze measurement and Should include:
performance objectives against current • Which processes are involved in and contribute to a
performance to evaluate the selected performance improvement
organization’s ability to satisfy business • An estimate of the contribution of the respective
objectives. processes
• Traced contribution of performance improvements to
related objectives
• Any barriers that may hinder meeting objectives or
successful deployment of improvements
Identify shortfalls and potential Performance shortfalls may include not meeting objectives
improvement areas where actual for:
performance is not meeting business • Productivity
objectives. • Cycle time
Examples of areas to consider for improvement include:
• Product technology
202

• Process technology
• Personnel development
• Team and organizational structures
• Infrastructure
• Supplier selection and management
Record performance improvement Use this information and evaluation results when developing
needs. or updating proposed improvements for performance.
Analyze and record anticipated cost Should include:
and benefits associated with • Resources including schedule, effort, people, processes,
addressing performance improvement tools, etc.
needs. • Barriers that may hinder successful deployment
• Detailed organizational changes needed to implement
each improvement
• Verification and validation activities
Communicate results to affected
stakeholders.
Submit performance improvement
suggestions.

Aggregated performance results Elicit performance and improvement results from the project
level.
Sources may include the:
• Organization’s measurement performance objectives
• Results of process and work benchmarking efforts
• Measured effectiveness of work environments
• Analysis of work and organizational performance
compared to quality and productivity objectives, including:
o Aggregation to the business level
o Effect on satisfying business objectives
o Effect on meeting measurement and performance
objectives
Performance analysis results Should include:

• Identified processes or technologies that critically
contribute to performance improvements
• Rationale for why identified processes or technologies are
critical
• Identified shortfalls, e.g., risks, issues, or achievements,
towards meeting measurement and performance
objectives at the project and organizational level
Performance improvement needs Includes traceability of improvements to processes and
Submitted performance improvement
suggestions
203

Context Specific
Services
When determining performance needs for services, develop, keep updated, and use models,
thresholds, and targets for supporting capacity and availability management to keep the work
effort on track to meet objectives.
Capacity and availability management may include developing service system representations
used for delivering the solution and using these representations for:
• Supporting negotiation of appropriate agreements
• Planning
• Making decisions
• Considering corrective actions
• Providing and allocating resources to meet current and future requirements
These representations provide insight into the behavior of a service system given specific work
volumes and varieties. These representations can be built using diagrams; spreadsheets;
commercial off-the-shelf (COTS) tools, e.g., simulation packages; prototypes; or tools
developed in house. For some service delivery systems, the representations are historical
baselines; trend analyses; analytical models; analysis of waiting times in queues; simulation
models; statistical models, e.g., regression models, time series models; causal models, e.g.,
probabilistic networks; or application sizing.
Example Activities
Collect measurements on resource use

for the current agreements.
Develop, use, and keep updated Examples include:

descriptions of the normal use of • General systems flow charts to identify the service system
resources and service system and its processes
performance. • Record of the system’s current capacity and availability,
which can require determining the capacity and availability
of service system components
Develop, use, and keep updated Consider:

service system representations from • Estimating the capacity and availability of the service
collected measurements and analyses. system at peak work volumes as appropriate
• Defining thresholds, typically below the level at which an
exception condition or breach of requirement occurs to
allow time for corrective action, and associated with
demand, workload, use of resources, and performance to
204

define exception conditions in the service system and
breaches or near breaches of requirements
• Developing capacity and availability models and keeping
them updated, such as:
o Demand data
o Capacity and availability data
o Availability data
o Performance data
o Representations of resource use
o Representations of resource needs
o Data on the use of resources
o Capacity and availability targets
o Thresholds that define exception conditions and
breaches
Review and obtain agreement with

relevant stakeholders about
descriptions of the normal resource
use, performance, and representations.
MPM 3.6
Practice Statement
Periodically communicate performance results to the organization.
Value
Enhances coordination and understanding of performance and improvement value to reduce
waste and increase the likelihood of achieving objectives.
Performance results include impact, benefits, and analysis of performance against objectives.
This practice focuses on communicating composite measurement and performance results.
Widespread communication leads to greater understanding across the organization of the
benefits of performance improvement. This understanding is key to developing a sustainable
improvement culture with a positive attitude towards measurement and performance
management and process improvement.
Example Activities
Develop and record performance
improvement reports.
205

Communicate performance
improvement results to affected
stakeholders.

Example Work Product Further Explanation
Performance improvement May include:
and analysis reports • Contextual information or guidance to help interpret analysis results
• Discussion and interpretation of results
• Usage of results
• Performance improvement results from projects
• Effect on satisfying measurement and performance objectives
• Aggregation to the business level
• Effect on satisfying business objectives
206
Level 4
MPM 4.1
Practice Statement
Use statistical and other quantitative techniques to develop, keep updated, and communicate
quality and process performance objectives that are traceable to business objectives.
Value
Establishing realistic quality and process performance objectives enables making better
decisions, which increases the likelihood of meeting business objectives.
Use statistical techniques to determine quality and process performance objectives for the work.
Quality and process performance objectives can be used at the project, organizational level, or
any level. Carefully select performance data for statistical analysis as it can be expensive.
Analyze information periodically and on an event-driven basis. Trace quality and process
performance objectives to business objectives.
Negotiate the quality and process performance objectives for the work with enough detail to
allow for evaluating the objectives and risks. The objectives may be expressed as either a
distribution or discrete number. Update them:
• As the project’s understanding of actual performance and variation becomes known and
more predictable
• To reflect the changing needs and priorities of the business
• When higher level objectives are changed
Quality and process performance objectives may address:
• Planned objectives to be achieved as a result of improvements
• Current objectives to be sustained
Example Activities
Define, record, keep updated, and This involves:
communicate Quality and Process • Incorporating appropriate business and organizational
Performance Objectives (QPPO). objectives
• Recording objectives that reflect the quality and process
performance needs and priorities of affected stakeholders
• Determining how each objective will be achieved
One common technique for recording these objectives is the
SMART approach:
207

• Specific
• Measurable
• Achievable
• Relevant
• Time-bound
Ensure traceability between the performance and business
objectives.
Techniques that aid in defining QPPOs may include:
• Use of control charts
• Analysis of variation
• Regression analysis
• Use of confidence or prediction intervals
• Sensitivity analysis
• Simulations
• Hypothesis tests
Derive interim objectives to monitor Establish interim objectives for characteristics of selected
progress toward achieving the stated phases, milestones, work products, and processes.
objectives.
Determine and record the risk of not
achieving quality and process
Resolve conflicts among the quality To resolve conflicts:
and process performance objectives, • Set relative priorities for objectives
e.g., if one objective cannot be • Consider alternative objectives in light of long-term
achieved without compromising business strategies as well as short-term needs
another. • Involve and negotiate with affected stakeholders in
tradeoff decisions
Additionally, process performance baselines and models can
help identify suboptimized processes or subprocesses that
may conflict with other quality and process performance
objectives.
Revise objectives, as necessary, to reflect results of conflict
resolution.

Quality and process performance Examples of project quality and process performance
objectives objectives include:
• Maintain change request volume below a target value
• Reduce idle time by x% by a target date
• Maintain schedule slippage below a specified percentage
Examples of measurable quality characteristics include:
• Performance
• Defects or issues
• Critical resource utilization
• Severity of customer complaints
208

Examples of measurable process performance characteristics
include:
• Cycle time
• Percentage of rework time
• Defect escape rates
Risks of not achieving the quality and
process performance objectives

MPM 4.2
Practice Statement
Select measures and analytic techniques to quantitatively manage performance to achieve
quality and process performance objectives.
Value
Focuses measurement and management activities on the data that provide the most insight into
achieving the objectives.
Measurement and analytic techniques enable preparation for statistical and quantitative
management of performance, by establishing a traceable relationship of the selected measures,
and their analyses, to the objectives. Use appropriate analytic techniques, including data
visualization, to enable users to recognize significant deviations from performance objectives
and take corrective action.
Example Activities
Identify common measures
from the organizational
measurement repositories.
Identify additional measures
that may be needed to cover
the critical work product and
process attributes of the
selected processes.
209

Select measures to manage Selection should not be limited to solution, progress, or performance
processes using statistical and measures only. Measures can be used to develop analysis, process,
other quantitative techniques. and success indicators which provide better insight into process
performance.
Measures that aggregate data from multiple sources or over time
typically mask underlying problems, making problem identification
and resolution difficult.
For short projects, it may be necessary to aggregate data across
similar instances of a process to enable analysis of its process
performance.
Specify the operational
definitions of new measures.
Identify the statistical and These statistical and other quantitative techniques help to:
other quantitative techniques • Characterize process variation
to be used. • Recognize when variation is excessive, and investigate why
• Identify when statistically unexpected behavior occurs
Examples of statistical techniques to analyze process performance
include:
• Statistical process control
• Regression analysis
• Analysis of variance including central tendency and distribution
• Time series analysis
• Hypothesis testing for statistical significance
Graphical displays can help:
• Visualize process performance
• Understand relationships between two or more sets of data
• Track variation over time
• Identify problems or opportunities
• Evaluate the effects of different factors
Examples of graphical displays include:
• Scatterplots
• Control Charts
• Histograms
• Box and whisker plots
• Run charts
• Ishikawa diagrams
Analyze the relationship of Examples of quality and process performance objectives using
identified measures to the derived targets include:
quality and process • Keep requirements gathering sessions to under three hours
performance objectives to • Maintain rework levels below a specified percent
derive targets. • Maintain productivity in generating a number of work products per
day
Develop the environment to This implementation is based on the:
support collection, derivation, • Description of the organization’s set of standard processes
and analysis of new measures • Description of the defined process in use
and keep it updated.
210

• Capabilities of the support environment
Record, keep updated, and
use measures and statistical
analysis techniques.

List of selected and new Include:
measures • Operational definition of new measures suitable to support
statistical and other quantitative management
• Identified (or linked to) statistical and other quantitative
techniques to analyze the measures
• Representations of data and analysis results
Repository of analytical and Include:
statistical techniques • Definition of analytical and statistical techniques
• Links to measures
• Needed skills for applying the defined techniques
• Identified people who have the needed skills
• Tools to support the techniques
Environment to support
collection, derivation, and
analysis of new measures
Results of analysis and their
derived targets
Traceability to objectives Show the relationship between the measures, the quality and process
performance objectives, and higher-level business objectives.
Context Specific
Development
Examples of quality and process performance objectives using derived targets include:
• Maintain a code review rate between 75 to 100 lines of code per hour
• Keep test rate over a specified number of test cases per day
• Maintain productivity in generating use cases per day
• Keep design complexity (fan-out rate) below a specified threshold
211
MPM 4.3
Practice Statement
Use statistical and other quantitative techniques to develop and analyze process performance
baselines and keep them updated.
Value
Enables quantitative understanding of performance and capability to ensure that objectives can
be met.
A process performance baseline is a recorded, statistical characterization of the actual results
achieved. Derive baselines by analyzing measures to identify central tendency and distribution
or range of results that characterize the expected performance. Use these baselines to
determine the expected results of the process under a given set of circumstances. The
organization’s process performance baselines measure performance for selected processes
within the organization’s set of standard processes.
Baselines provide an understanding of process variation and support informed decision making
through a better understanding of risks to achieving objectives. Baselines enable:
• Determining the stability and capability of the process
• Detecting defects earlier to save resources
• Detecting significant cost or schedule issues earlier to take corrective actions
• Facilitating earlier detection of anomalies with critical processes
A stable process is important to creating reliable process performance baselines. Understanding
the presence (or absence) of variation enables more accurate understanding of the process
capability. In determining stability and capability of the process, two key terms come into play:
• Stable process: The state in which special causes of process variation have been
removed from the process and prevented from recurring. In a stable process, only
common cause variation of the process remains.
• Capable process: A stable process that is able to meet the quality and process
performance objectives set for it, and the variation of the process falls within set
specification limits.
Process performance baselines may be used to:
• Compare to performance objectives to identify if they are being met
• Establish trial bounds when starting a control chart
• Compare actual process performance among multiple projects
• Establish benchmarks
• Enable identification of special cause of variation, triggering potential root cause analysis
212
The work that the process performance baselines address includes:

• Individual process activities within a larger process
• Sequences of connected activities
• Processes whose activities are performed by different workgroups
• Activities that cover the entire lifecycle
• Activities for developing individual work products
• Determining inherent process variation (i.e., common cause of variation) in performance
• Determining assignable process variation (i.e., special cause of variation) in performance
• Understanding the impact of variation on stability and capability on the performance of
the process and achievement of the quality and process performance objectives
• Understanding how capable a process is in meeting its quality and process performance
objectives
There can be several performance baselines to characterize performance for subgroups.
Examples of subgroup categories include:
• Line of business
• Domain or function
• Complexity
• Project size
• Work product size
• Process elements or attributes from the organization’s set of standard processes
Tailoring the organization’s set of standard processes can significantly affect the comparability
of data and how data is included in process performance baselines.
Conditions that may affect the performance of processes and justify the development of
separate process performance baselines include:
• The level of experience or proficiency of the individuals performing the processes
• Organizational or business conditions
• Specific methods or tools used in performing the processes
• The nature of the solution for which the processes are performed
Statistics used to characterize process performance baselines include:
• Expected performance as measured by mean, median, mode, or other measures of
central tendency
• Performance variation as measured by upper and lower control limits, standard
deviation, interquartile range, range, or other measures of variation
• Shape of the distribution as measured by statistics, e.g., skewness, kurtosis
• How performance parameters may vary under different conditions
• Performance trends over time
213
Example Activities
Analyze the collected measures to Include the stability and capability (when specification limits
establish central tendency and are defined).
distribution or range of results that This analysis can help decide the best selection or subset of
characterize the expected performance process performance baselines to maintain.
of selected processes.
Ensure that the baselines are linked to quality and process
performance objectives and business objectives.
Record, keep updated, and use process Examples may include:
performance baselines. • Statistical process control charts
• Box and whisker diagrams
• Confidence intervals
Review process performance baselines Stakeholders can help determine if the baselines are
with affected stakeholders. appropriate.
Make the process performance Workgroups use the organization’s process performance
baselines available in the organization’s baselines to estimate the natural bounds for their process
measurement repository and performance.
communicate to the organization. Some project process performance baselines may not be
included in the organization’s measurement repository.
Revise the process performance For example, when:
baselines as needed. • Processes change
• The organization’s results change
• The organization’s needs change
• Suppliers’ processes change
• Suppliers change

Results of analysis of process
performance data
Process performance baselines Include:
• Central tendency
• Range and distribution
• Description of the context for the data
• Reference to the operational definition of the data to
enable accurate interpretation
• Links to quality and process performance objectives
214
MPM 4.4
Practice Statement
Use statistical and other quantitative techniques to develop and analyze process performance
models and keep them updated.
Value
Reduces cost and increases quality by predicting likelihood of meeting objectives and allowing
for early corrective action.
A process performance model:
• Developed from historical process performance data such as those contained in process
performance baselines
• Describes, models, or depicts variation in measurable attribute values and terms
• Predicts interim or final process performance
• Estimates expected range and variation of predicted results
• Includes at least one measurable attribute representing a controllable input tied to a
subprocess
The condition in the last bullet makes what-if analyses possible: controllable input(s) can be
varied and resulting changes in process performance predicted. Perform analyses during
planning, dynamic re-planning, and problem resolution to make process tailoring choices that
maximize likelihood of meeting quality and process performance objectives.
Process performance models can be:
• Statistical, e.g., regression
• Probabilistic, e.g., Bayesian
• Simulation-based, e.g., Monte Carlo or discrete event simulation
A process performance model can be a collection of models that when combined meet the
criteria of a process performance model.
High Maturity organizations generally develop and maintain a set of process performance
models at various levels of detail to predict process performance. These models cover a range
of activities and work product measures that are common across the organization and address
the likelihood of achieving the organization’s quality and process performance objectives.
Process performance models can help to:
• Predict performance results including confidence limits of selected processes
• Analyze and predict the performance associated with processes and changes to the
organization’s set of standard processes
215
• Assess return on investment for process and performance improvement activities

• Select processes that give the projects the highest probability of success
• Enable “what if” analysis for potential changes and improvements
• Estimate progress toward achieving the quality and process performance objectives
Examples of performance models include:
• Regression
• Complexity
• Discrete event simulation
• Monte Carlo simulation
Example Activities
Establish process performance models. Examples of analyses used to develop performance models
include:
• Visual analysis techniques, e.g., scatter plot
• Regression or multivariate predictive techniques
• Stochastic techniques
• Classification analyses, e.g., defect or problem types
• Monte Carlo analysis
Validate the process performance One typical method of validation is to use historical
model. information, e.g., use the first 9 months of data to predict
the last 3 and then compare to actual results.
Calibrate process performance models
based on the results.
Review process performance models Stakeholders can help determine if the models are
with affected stakeholders. appropriate.
Make the process performance models Some project process performance models may not be
available in the organization’s included in the organization’s measurement repository.
measurement repository and
communicate to the organization.
Support the project’s use of process
performance models.
Revise process performance models as For example, when:
needed. • Processes change
• The organization’s results change
• The organization’s measurement and performance
objectives change
• The organization’s business or business objectives change

Process performance models May include:
• Guidance for use
216

• Description of model:
o Equation or scenario
o Controllable factors
o Uncontrollable factors
o Confidence and prediction limits
Validation results Include results from utilizing the models.

Calibration results
MPM 4.5
Practice Statement
Use statistical and other quantitative techniques to determine or predict achievement of quality
and process performance objectives.
Value
Facilitates a quantitative understanding of risks to achieving objectives which maximizes
likelihood of success.
Use statistical and other quantitative techniques to:
• Analyze variation in process performance
• Monitor the selected processes that drive achieving the objectives
• Review the quality and process performance objectives to determine:
o Their relationship to the business objectives
o The risks associated with not meeting them
o The actions needed to achieve them
Use multiple inputs to predict if the quality and process performance objectives will be satisfied.
Quantitative models of performance can range from simple descriptive statistics concerning
capability to sophisticated Bayesian, stochastic, or multivariate predictive models. These models
may be used to predict project, team, or organizational performance based on the current
capability of processes and the conditions that affect them. An organization may begin with
standard models from related industries and over time refine their algorithms or parameters
with internal data and experience. Quantitative models may differ in:
• Purpose
217
• Sophistication
• Analytic foundation
• Parameters
• Predictability
• Use among the various processes
Examples of quantitative models include:
• Models to predict the likelihood of achieving quality and process performance objectives
from the aggregated performance results of projects
• Predictive models of characteristics most likely to affect capability and performance of
the project and used to select improvements and adjust performance expectations
• Models of the effect of variations in practices and activities on the resulting capability
and performance of processes
• Models for evaluating decisions involving performance tradeoffs
Example Activities
Analyze the variation and This analysis may involve:
stability of the selected • Evaluating measurements in relation to the natural bounds and
processes and address specification limits
deficiencies. • Identifying outliers or other signals of potential non-random
behavior (applying run rules or tests to identify anomalies)
• Determining causes of outliers
• Preventing or mitigating the effects of outlier recurrence, e.g.,
addressing special causes of variation
Consider:
• The sufficiency and accuracy of the data
• Shifts in process performance that can affect the ability to
achieve or maintain process stability
• Deficiencies in process performance such as when there is too
much variation to achieve the objectives
Confirm that the process performance is stable before determining
capability. Addressing stability typically includes an in-depth
understanding of special causes. Addressing capability typically
includes an in-depth understanding of common causes and
addressing them appropriately.
Analytic techniques for identifying outliers or signals include:
• Statistical process control charts
• Prediction, confidence, or tolerance intervals
• Analysis of variation
Implement actions needed to Examples of actions to address deficiencies in achieving objectives
address deficiencies in may include:
achieving quality and process • Improving the implementation of the existing process to reduce
performance objectives. its variation or improve its performance, e.g., addressing common
causes of variation or changing the process
218

• Adopting new processes and technologies
• Identifying risks and risk mitigation strategies for deficiencies
• Renegotiating quality and process performance objectives when
the processes are not capable of achieving them
Some actions involve the use of causal analysis. Corrective actions
may result in changes to attributes or measures related to
controllable factors in process performance models. Process
performance models can then be used to predict the effects of the
actions. When taking critical corrective actions in high risk
situations, a process performance model can be developed to
predict the effects of the change.
Processes not selected for their impact on objectives can still cause
problems or risks. Some level of monitoring for these processes may
be helpful.
Use validated process For example, use process performance models to predict the latent
performance models calibrated defects in work products in future phases or in the delivered
with data to assess progress solution.
toward achieving quality and
process performance
objectives.
Identify and manage risks
associated with achieving
quality and process
Record and communicate the
results of the analysis,
decisions, and actions
identified.

Results of analysis, validation, and May include:
calibration • Graphs, charts, and data tables that support quantitative
management
• The range of process performance for each selected
process attribute
Predictions of results to be achieved
relative to the quality and process
Recorded risks of not achieving the
quality and process performance
objectives
List of actions needed to address
deficiencies in the process stability or
capability of each selected process
219

220
Level 5
MPM 5.1
Practice Statement
Use statistical and other quantitative techniques to ensure that business objectives are aligned
with business strategy and performance.
Value
Minimizes waste and rework through a more accurate understanding of capability which
increases the likelihood of setting and meeting reasonable objectives.
Ensure alignment of quality and process performance objectives, business objectives, and
business strategies.
Use organizational performance data, characterized by process performance baselines and
models, to evaluate whether business objectives are realistic and aligned with business
strategies and to understand variation. There may be multiple baselines and models needed in
an organization to cover different types or aspects of work. After business objectives have been
revised and prioritized, develop, maintain, and communicate resulting quality and process
performance objectives. Use process performance models to understand the processes and
relationships needed to achieve the objectives and to perform what-if analyses to aid in the
alignment process.
Example Activities
Evaluate and update business Business objectives, business strategies, and organizational
objectives periodically and on an event performance may change over time or become obsolete
driven basis to ensure that they align based on the needs of the organization or the strategies.
with business strategies. Understanding performance in this context requires using
statistical and quantitative techniques.
Compare business objectives with Business objectives can set the bar too high to motivate real
baselines and process performance improvement. Using process performance baselines and
predictions to ensure the objectives are models helps balance expectations and reality. If process
realistic. performance baselines and models are not available, use
sampling techniques to quickly develop a quantitative basis
for comparison.
Prioritize business objectives based on Example criteria include the ability to:
recorded criteria. • Win new business
• Retain existing clients
• Respond to changing or disruptive markets
• Innovate
221

• Accomplish other key business strategies
Maintain quality and process Business and quality and process performance objectives
performance objectives to address typically evolve over time. Ensure existing objectives are met
changes in business objectives. while identifying and managing new business objectives and
associated quality and process performance objectives.
Revise measures to align with quality
and process performance objectives.
Communicate changes to business
strategies, business objectives, and
quality and process performance
objectives to stakeholders.

Results of analysis of current This is typically an iterative process that may be done from a
performance against: bottom-up (quality and process performance objectives up to
• Quality and process performance business strategies) or top-down approach, depending on
objectives the need and purpose.
• Business strategies
Revised business objectives and
strategies
Revised quality and process
Revised measures
MPM 5.2
Practice Statement
Analyze performance data using statistical and other quantitative techniques to determine the
organization’s ability to satisfy selected business objectives and identify potential areas for
performance improvement.
Value
Identifies areas that pose the greatest risk to achieving business objectives or greatest
opportunity for increasing business performance.
222

Process performance baselines and models help to understand the current capability of the
organization. Compare process performance baselines or predictions from process performance
models against quality and process performance objectives to determine the organization’s
ability to meet business objectives.
Use analysis to further refine the potential areas for improvement. This can be combined with
Causal Analysis and Resolution practices to help diagnose and resolve root causes of the issues.
Example Activities
Periodically and on an event-driven For example, if cycle time is a critical business need, collect
basis, compare quality and process various measurements that support or influence
performance objectives to current characterizing cycle time. Compare overall cycle time
process performance baselines and performance data to business objectives to understand if the
models to evaluate and predict the expected performance will satisfy business objectives.
organization’s ability to satisfy business
objectives.
Identify shortfalls where performance
is not satisfying business objectives.
Identify potential improvement areas Examples of areas to consider for improvement include:
based on the analysis of performance • Product technology
shortfalls. • Process technology
• Personnel development
• Productivity
• Team structures
• Supplier selection and management
• Other organizational infrastructures
Communicate results and develop a list
of improvement proposals.

Performance analysis results Include an analysis of current performance data versus
List of performance shortfalls Shortfall descriptions may include:
• Context
• Impact (including any interdependencies on other
performance or processes)
• Priority
• Risks
• Potential corrective actions
List of potential improvement
proposals
223

MPM 5.3
Practice Statement
Select and implement improvement proposals, based on the statistical and quantitative analysis
of the expected effect of proposed improvements on meeting business, quality, and process
Value
Increases likelihood that selected improvements will significantly contribute to achieving
business, quality, and process performance objectives.
Proposed improvements selected for implementation should significantly contribute to achieving
business, quality, and process performance objectives. Improvement ideas may come from
either inside or outside the organization. By analyzing the benefits and impacts of
improvements, this practice can also help to prepare the organization for their deployment and
maximize the benefits.
Example Activities
Use process performance models to
predict process performance based on
proposed improvements.
Run pilots to determine preliminary
process performance based on
proposed improvements.
Run tests for statistical significance of
modeled or piloted results.
Analyze the costs and benefits of Estimate the cost, effort, and schedule required for
proposed improvements. implementing, verifying, and deploying each proposed
improvement.
Process performance models provide insight into the effect of
process changes on process capability and performance.
Criteria for evaluating costs and benefits may include:
• Contribution toward meeting the organization’s quality
and process performance objectives
224

• Effect on mitigating identified work and organizational
risks
• Ability to respond quickly to changes in requirements,
market situations, and the business environment
• Impacts to commitments and skills
• Effect on related processes, training, work environment,
and technology
• Cost of defining and collecting data that support the
measurement and analysis of the process and technology
improvement
• Scalability
• Expected life span of the improvement
Identify potential barriers and risks to Examples of barriers include:
deploying each proposed improvement. • Turf guarding and parochial barriers
• Unclear or weak business rationale
• Lack of short-term benefits and visible successes
• Unclear picture of what is expected
• Too many changes at the same time
• Lack of involvement and support from affected
stakeholders
Examples of risks include:
• Compatibility of the improvement with existing processes
• Experience and skills of potential users
• Complexity of the improvement
• Difficulty implementing the improvement
• Ability to demonstrate the value of the improvement
before widespread deployment
• Justification for large, up-front investments in areas such
as tools and training
• Resistance to change
Record the evaluation results and The results should include:
decide to implement in accordance • Problem statement
with evaluation criteria • Description of proposed improvements
• Statistical and quantitative analysis of proposed
improvements including evaluation criteria
• Cost benefit analysis of proposed improvement
• Implementation decision
Determine and record the validation Determining the validation method includes defining the
method that will be used before broad- statistical or quantitative success criteria that will be used to
scale deployment of the change. evaluate results of the validation.
Since innovations typically represent a major change to the
process, most innovative improvements should be piloted.
Other validation methods, including modeling and simulation,
can also be used.
Implement selected proposals
Validate implemented proposals before Follow the validation methods recorded above
broad-scale deployment
225

Deploy validated proposals

Analysis of potential impacts of Analysis options include a:
proposed improvements • Statistically significant prediction of likelihood of achieving
the intended effect, e.g., from process performance
models
• What-if analysis
Piloting report May include:
• Results from piloting performance improvements against
defined success criteria
• Probability that the intended effect will be achieved when
the improvement is deployed
Cost-benefit analysis results May include:
• Cost
• Expected benefits
• Organizational impact
• Effect measured in quantitative and statistical terms
• Relationship to and impact on business and quality and
process performance objectives
• Identification of proposed improvements
List of potential barriers and risks to
implement the improvement
Recorded validation methods
List of submitted proposals for
implementation

226
Intent
Provide an understanding of the project progress so appropriate corrective actions can be taken
when performance deviates significantly from plans.
Value
Increases the probability of meeting objectives by taking early actions to adjust for significant
performance deviations.
Practice Summary
Level 1
MC 1.1 Record task completions.
MC 1.2 Identify and resolve issues.
Level 2
MC 2.1 Track actual results against estimates for size, effort, schedule,
resources, knowledge and skills, and budget.
MC 2.2 Track the involvement of identified stakeholders and commitments.
MC 2.3 Monitor the transition to operations and support.
MC 2.4 Take corrective actions when actual results differ significantly from
planned results and manage to closure.
Level 3
MC 3.1 Manage the project using the project plan and the project process.
MC 3.2 Manage critical dependencies and activities.
MC 3.3 Monitor the work environment to identify issues.
MC 3.4 Manage and resolve issues with affected stakeholders.
The term “project plan” refers to the overall plan for managing the project and includes a
coherent description of who does what and when for developing, updating, or delivering a
solution. The project plan can be a stand-alone document or distributed across multiple
documents and provides a way to track and communicate actual progress and determine if
corrections are needed.
227
Tracking progress typically consists of comparing actual values to planned or estimated values
for:
• Size
• Complexity
• Effort
• Cost
• Schedule
• Quality
• Milestones
• Knowledge and skills
• Resources
• Commitments
• Transition to operations and support
Tracking actuals against estimates supports managing the expectations of customers and
stakeholders. Take corrective actions when actual values deviate significantly from expected
values. These corrective actions may include:
• Revising the strategy for accomplishing the work
• Updating objectives
• Revising the plan
• Revising the estimates
• Establishing or modifying agreements and commitments
• Updating risk management activities and work products
If corrective actions are required to resolve significant deviations from project plans, define and
track these actions to closure.
Planning (PLAN)
Context Specific
228
Figure MC-1: Monitoring in an Agile Framework
Table MC-1: Monitoring Information & Related Model Practices
229
Figure MC-2: Release Burndown Chart
Figure MC-1 states where monitoring is performed in an agile project using Scrum. Table
MC-1 and Figure MC-2 show example tracking information and related model practices.
Typical monitoring practices for agile teams using Scrum, e.g., stand up meetings, visual
information management, scrum of scrums, result in the following information:
• Task (Scrum) board showing the status of work being performed, specifically tasks and
backlog items assigned to the sprint (refer to Table MC-1)
• A release burndown chart (refer to Figure MC-2) showing the number of story points
remaining, tracked within each sprint, and representing all of the work for a release
typically consisting of several sprints
• A sprint (iteration) burndown chart (not shown) that is updated daily indicating the time
needed to complete the work committed for the sprint
• Visual information on walls and/or digital screens indicating the current state of team
performance, culture, and tasks
Supplier Management
230
Develop monitoring and control functions early in the project during planning when defining the
supplier management strategy.
Monitor and control activities are essential throughout the supplier management process to
ensure:
• Application of appropriate resources
• Acquirer activities progress according to plan
After selecting one or more suppliers and establishing agreements, the acquirer continues to
monitor and control its activities and work products. At the same time, the acquirer monitors
and controls supplier progress and performance for effects to the overall effort.
Define supplier progress and performance reporting requirements in the supplier agreement
consistent with the needs of the contract.
231
Level 1
MC 1.1
Practice Statement
Record task completions.
Value
Knowing how much work remains enables the team and senior management to make better
decisions to achieve objectives.
Tracking completed work is part of monitoring progress. Regularly review tasks to determine
status, which may include:
• Completed
• Delayed
• Not completed
Example Activities
Record task completion. Although tasks can be given a percentage completion, this
may lead to inaccurate status reporting such as “90% done
90% of the time.” One way of avoiding this is to only show
100% complete or not complete.
Review updated task list with affected
stakeholders.

Task list Includes:
• Description
• Status
• Date
232
MC 1.2
Practice Statement
Identify and resolve issues.
Value
Resolving issues helps prevent uncontrolled cost and schedule creep.
Identify and resolve issues as they arise. Resolving issues is important to keeping tasks on
schedule. Analyze issues as they are identified to determine the appropriate corrective action
and track to closure.
Issues may generate unplanned work. If issues are not monitored and controlled, work can be
delayed without an understanding of the reason.
Example Activities
Record the issue in the issue and
action item list.
Assign responsibility for resolving the Ensure people are aware that they have been given
issue or action item. responsibility to resolve the action.
Assign a due date. Work with the person assigned responsibility to determine
when the issue or action can be completed.
Track issues and action items to Tracking to closure is critical to knowing if and how the
closure. project plan will be impacted.

Issues and action item list Includes the:
• Description of the issue or action item
• People assigned to the issue or action item
• Due date
• Status
233
Level 2
MC 2.1
Practice Statement
Track actual results against estimates for size, effort, schedule, resources, knowledge and skills,
and budget.
Value
Identifies significant deviations so more effective corrective actions can be taken which
increases the likelihood of meeting objectives.
Record associated contextual information when tracking actual results versus estimates to help
understand what the measurement data represents.
Typical indicators of project progress and performance include characteristics of work products
and tasks that may include:
• Cost
• Budget
• Effort
• Schedule
• Size
• Complexity
• Capacity and availability
• Function
• Resources
• Commitments
• Transition to operations and support
Frequency of monitoring depends on the:
• Collection schedule
• Pace and duration of the work
• Agreed to milestones
234
Example Activities
Track actual results to plans and Track size, effort, schedule, resources, knowledge and skills, and
estimates. budget.
Tracking actual results typically occur through:
• Progress reporting
• Status reviews
• Milestone reviews
Monitor resources provided and Identify what resources are needed to address the corrective
used. actions. This typically includes:
• People
• Processes
• Physical facilities
• Computers, peripherals, and software
• Networks
• Security environment
Monitor the knowledge and skills This typically includes:
of workgroup members. • Periodically measuring the knowledge and skills of people to
assess changes
• Comparing actual training obtained to training recorded in the
project plan
• Identifying significant differences from project plan estimates
Monitor commitments against This includes:
those identified in the project • Regularly reviewing internal and external commitments
plan. • Identifying commitments that have not been satisfied or are at
significant risk of not being satisfied
• Monitoring availability, reliability, and maintainability against
their requirements
• Recording review results
Record significant differences in This includes:
planned vs. actual values. • Defining criteria for what “significant” means for the planned
and actual values
• Keeping a record of significant differences to be used for more
effective future planning
Monitor progress against This typically includes:
schedule. • Periodically measuring the actual completion of activities and
milestones
• Comparing actual completion of activities and milestones to the
project schedule to identify significant deviations
Monitor expended effort and This typically includes:
costs. • Periodically measuring the actual effort and costs expended
• Comparing actual effort and costs, to the planned/estimated
budget and costs
• Identifying significant deviations from the project budget and
estimates
235

Records of actuals versus estimates Typically includes the:
• Budget
• Schedule
• Size
• Effort
• Resources
Records of significant deviations
Records of status reviews
Corrective actions
Cost performance reports Include planned vs. actual results on cost of tasks, activities,
and deliverable dates, their sequence, and resources needed.
Schedule performance reports Include planned vs. actual results on schedule of tasks,
activities, and deliverable dates, their sequence, and
resources needed.
Context Specific
Services
Monitoring and analyzing capacity and availability can help identify the need for corrective
actions to prevent service interruption and service system failure.
Record the use of each resource including the use of each resource by each component, i.e.,
the extent or degree of use by each component for a given resource. Analyze the effect of
failures to align capacity and availability.
Monitor the use of resources during unexpected increases in demand to determine whether
corrective actions are needed. Examples of corrective actions include:
• Adjustments to resources provided
• Adjustments to thresholds
• Adjustments to descriptions of the normal use of service resources and service system
performance
Identify the need for corrective actions:
• Based on monitoring and analyzing capacity and availability
• In response to service incidents, change requests, changes to service requirements
(current and future)
• To improve service system performance or prevent breaches of the service agreement
236
Monitor the service system to detect or prevent the failure of components that affect service
system availability. At a minimum, monitor availability. Monitor other quality attributes if
appropriate based on the type of service, development, or acquisition provided. For many
service systems, it may also be appropriate to monitor other quality attributes such as reliability
and maintainability. Monitor the resilience of the service system to service component failure
and identify the impacts of specific failures on service system availability.
Activities to monitor capacity and availability of service systems may include:
• Monitoring the use of resources against thresholds, descriptions of normal use, and
service system performance
• Estimating future changes, either growth or reduction, in resource use
o Methods and tools for estimating service system behavior include trend analysis,
analytical modeling, simulation modeling, baseline models, and application sizing
o Resource usage growth estimates can be based on collected capacity and
availability data, projected requirements, and service system representations
• Communicating the analysis of results on performance objectives and their impact on
capacity and availability
o Capacity and availability reports can be regular or ad hoc. If helpful, simplify
reporting by using databases with automated reporting features. Follow
organizational reporting standards. When they exist, use standard tools and
techniques to integrate and consolidate information in the reports.
o Information should be appropriate to the audience and understandable, and it
may need to address multiple perspectives. These perspectives can include
business, end user, customer, or provider. Agreements can define the reported
information, to whom it should be delivered, and how it is provided, e.g., format,
detail, distribution, media.
o Availability is typically reported as a percentage. If required, in addition to
reporting availability, report on reliability, e.g., reliability of the service or service
system components, maintainability, and other quality attributes.
Supplier Management
Track resource commitments that result in expenditures, e.g., issued purchase orders and
completed, accepted supplier deliverables, when the organization incurs the expense. Track
resource commitments even before formal payment, to account for financial and legal
obligations. Monitor commitments that do not result in expenditures, e.g., allocation of
resources or skill sets.
• Supplier progress and performance reports
• Records of significant deviations from plans or processes
• Cost performance reports
237
MC 2.2
Practice Statement
Track the involvement of identified stakeholders and commitments.
Value
Managing stakeholder involvement is critical to successful work completion.
Manage stakeholder involvement according to the plan and process. Re-plan stakeholder
involvement when changes to requirements, situation, or status occur.
Example Activities
Periodically review and record the Stakeholder involvement can be tracked in events such as
status of stakeholder involvement. team meetings and cross-functional coordination meetings.
Identify and record significant
stakeholder issues.
Develop recommendations and
coordinate actions to resolve issues.

Records of stakeholder involvement Includes meeting records and reviews with attendee lists.
Agendas and schedules for
collaborative activities
Recommendations for resolving Includes records of decisions.
stakeholder issues
Recorded issues Identifies both resolved and unresolved issues.

Planning (PLAN)
238
Context Specific
Services
Monitoring and tracking stakeholder involvement involves communicating critical information to

stakeholders. Communicating the results of data on capacity and availability management helps
focus on meeting performance objectives.
Example stakeholder communication activities and topics include:
• Reporting the performance and use of resources
• Reporting exception conditions in the service system and requirement breaches
• Reporting data from monitoring against growth estimates in resource use
• Reporting the capacity, availability, reliability, and maintainability of resources, including:
o Performance reports
o Resource use reports
o Resource use projections
o Availability reports
MC 2.3
Practice Statement
Monitor the transition to operations and support.
Value
Solutions are smoothly transitioned and successfully implemented ensuring expected benefits
are obtained.
Monitor and control the actual transition of the accepted solution against the plan for the
transition to operations and support. In some instances, this may be accomplished by delivering
the solution directly to the customer.
239
Example Activities
Monitor the capabilities of • Operations and support organizations should demonstrate
operations and support to readiness to accept the solution and provide uninterrupted
receive, store, use, and support.
maintain new or modified • Use transition readiness criteria and verification and validation
solutions. practices to decide if delivered solutions meet specified
requirements.
• Use verification and validation practices to confirm readiness for
acceptance into operations and support.
Monitor training delivery to This typically includes:
stakeholders involved in • Verifying correct training materials and resources specific to
receiving, storing, using, and stakeholders involved are available and used
maintaining solutions. • Verifying that the right training is given to the right people at the
right time
• Verifying that the delivered training has enabled the recipients to
carry out their work efficiently and effectively
Review and analyze the results Decide whether corrective actions must be completed before
of transition activities. transferring responsibility to operations and support.
Example work products that support transition analyses include:
• Transition activity reports that include quality measures collected
during the pilot and the warranty period
• Problem tracking reports, detailing resolution time, escalation,
and root cause analysis
• Change management reports
• Configuration management records
• Operation logs to decide that sufficient information is stored to
support revisions
• Security reports
• Actual operations and support costs compared to estimates

Status reports of transition Current status of transition activities, including any risks, issues, or
activities corrective actions taken.
Transition readiness report Description of the state of readiness of the solutions prior to
transition to ensure it will happen in accordance with the plan.
Records of transition support May include corrective actions.
reviews
Lessons learned report
240
Context Specific
Supplier Management
Typically, the supplier has a role in integrating and packaging solutions and preparing for the
transition to operations and support, including support for business user acceptance. The
acquirer monitors these supplier activities. The solicitation package and the supplier agreement
set the expectations of the supplier and the acceptance criteria to transition to operations and
support.
• Training materials and supporting work products
• Site readiness reports
• Verification reports
• Training records
• Operational readiness reports
• Test results
• Pilot results
The acquirer makes adequate provisions to operate the acquired solution through the supplier
agreement or in-house operations and support organizations. Typically, the supplier develops
training for the solution.
MC 2.4
Practice Statement
Take corrective actions when actual results differ significantly from planned results and manage
to closure.
Value
Managing corrective actions can increase the probability that objectives will be met.
Collect and analyze issues and decide on corrective actions to address them. Manage the
corrective actions to closure. Actions can be automated, performed manually, or a combination
of the two. Examples of corrective actions may include:
241
• Adjustments to resources to prevent performance problems or improve performance

• Rebalancing workload among resources
• Improving processes to allow for greater productivity, efficiency, and effectiveness
• Improving design such as making use of new technologies to allow for greater
productivity, efficiency, or effectiveness
• Addressing capacity, and adding availability, e.g., adding people, or other resources
• Tuning to optimize and improve capacity or performance
• Adjusting requirements
• Improving the use of resources through demand management techniques
Example Activities
Collect issues for analysis. Collect issues from reviews and the execution of other
processes.
Examples of issues to collect include:
• Issues discovered when performing technical reviews,
verification, and validation
• Significant deviations in project planning parameters from
estimates in the project plan
• Commitments (either internal or external) that have not
been satisfied
• Significant changes in risk status
• Data access, collection, privacy, or security issues
• Stakeholder representation or involvement issues
• Solution, tool, or environment transition assumptions (or
other customer or supplier commitments) that have not
been achieved
Analyze issues to decide if corrective Corrective action is required when the issue, if left
action is needed. unresolved, may prevent the project from meeting its
objectives.
Take corrective action on identified Steps typically include:
issues. • Deciding and recording actions to resolve selected issues.
Examples of potential actions include:
o Modifying the statement of work
o Modifying requirements
o Revising estimates and plans
o Renegotiating commitments
o Adding resources
o Changing processes
o Improving skills and efficiency
o Revising project risks
• Obtaining agreement from affected stakeholders on the
actions
242

• Using the organization’s defined and established methods
to resolve conflicts and disputes
• Negotiating changes to internal and external commitments
Manage corrective actions to closure. This typically includes:
• Tracking corrective actions to completion
• Analyzing results of corrective actions to determine their
effectiveness and if additional corrective actions are
needed
• Recording final resolution of significant deviations when
initial corrective action taken was not effective

List of issues requiring corrective Include the:
action • Status of issue or action item
• Person responsible for the action item
• Corrective action plans
• Corrective action results

Planning (PLAN)
Context Specific
Services
Work group level monitoring and control or measurement and analysis can adequately cover
some monitoring of service system operation. This can include managing and controlling other
operationally-oriented quality attributes associated with service delivery, such as:
• Capacity
• Availability
• Responsiveness
• Service Level Agreement performance
• Usability
• Reliability
• Maintainability
• Safety
243
• Security
o Monitoring for security breaches, correcting vulnerabilities, and controlling access
to services
o Ensuring that the service provider only delivers approved services, as specified in
the service agreement, to authorized personnel
However, some services can require monitoring and data collection at the level of individual
service requests or continuously within the scope of a single service request. Such monitoring
can require its own tools to handle data collection, analysis, and reporting appropriately. These
tools are often automated. Perform low-level monitoring of service system components using
monitoring and data collection tools as appropriate.
Supplier Management
The acquirer has the sole responsibility for taking corrective actions when either the acquirer or
supplier implementation results deviate from plan.
The acquirer determines, e.g., by monitoring measurement data, whether supplier progress is
sufficient to meet a service level defined in the supplier agreement. If the supplier’s progress is
not sufficient, the acquirer initiates and manages corrective action with the supplier. If the
supplier does not comply appropriately with this corrective action, the acquirer escalates the
issue for resolution.
244
Level 3
MC 3.1
Practice Statement
Manage the project using the project plan and the project process.
Value
Helps to ensure necessary activities are performed which reduces rework and improves the
likelihood of achieving objectives.
Managing the project helps to:
• Understand how much time is spent on each activity and decide if it is the most effective
use of time
• Measure the resources used and available to a project
• Provide status to members of the team and stakeholders
Example Activities
Manage the project activities The project process is tailored by the project from the organization’s
using the project process set of standard processes.
and all related plans. This includes:
• Using the defined entry and exit criteria to start and finish tasks
• Monitoring activities that could significantly affect actual values of
the planning parameters, such as size, effort remaining, effort
expended and changes in complexity
• Tracking planning parameters using measurable thresholds to trigger
investigation and corrective action
• Monitoring risks
• Managing external and internal commitments based on plans for
tasks and work products
• Understanding the relationships between the:
o Tasks and work products of the project process, and
o Roles of affected stakeholders
• Using quality control processes, e.g., peer reviews, objective
evaluations, to improve both visibility into performance and control
of the work
• Taking corrective action when progress deviates significantly from
the plan
245

Collect and analyze selected
measurements to manage
the project and support the
organization’s needs.
Periodically review and align Examples of actions that achieve alignment include:
project performance with • Updating the schedule in response to changes in planning
organizational, customer, parameters, project, and risks
and end user requirements • Updating requirements or commitments in response to changes in
and objectives. market opportunities or customer and end user needs
• Terminating the project, iteration, or release
Resolve causes of issues This includes:
affecting project objectives. • Reviewing issues and lessons learned from previous work
• Performing causal analysis of selected issues to identify where
corrective actions need to be taken
• Evaluating process changes needed to prevent recurrence
• Taking the corrective actions and implement process changes
• Ensuring that the corrective actions and process changes have
prevented recurrence of issues and improved performance

Results of monitoring
Collected measures and status records or reports

Context Specific
Services
When managing the project, consider the critical dependencies of service delivery and service
performance, such as:
• Timing of shipments
• Service delivery activities
• Service delivery schedules
• Operating procedures
• Service requests identified in service agreements
• Service delivery performance and measurements
246
• Locations of facilities for service delivery

Supplier Management

• Project progress and performance reports
• Measures
• Risk logs
• Issue logs
• Decision logs
247
MC 3.2
Practice Statement
Manage critical dependencies and activities.
Value
Managing critical dependencies can significantly reduce risk and increase the likelihood of
meeting objectives.
Critical dependencies can also involve on-time availability of resources.
Example Activities
Review and update dependencies. Record agreements for:
• Coordinating dependent work
• Ensuring that resources are available on time
Provide advance communication to all affected stakeholders
when dependencies cannot be met.
Record minutes from reviews and
discussions.
Record issues.

Updated critical dependencies
Recorded agendas and meeting Dependencies are commonly managed and coordinated in:
minutes • Status reviews
• Management reviews
• Affected stakeholder discussions
• Cross-functional team coordination events
Recorded issues This may include:
• Supplier delays
• Stakeholder involvement (or lack thereof)
• Recommendations for resolving issues
248
Context Specific
Supplier Management
The supplier agreement provides the basis for managing supplier involvement in the project.
Supplier agreements, e.g., interagency and intercompany agreements, memoranda of
understanding, memoranda of agreement, that the acquirer makes with stakeholder
organizations provide the basis for stakeholder organization involvement. These stakeholder
organizations can be solution providers or recipients. These agreements are particularly
important when the acquirer’s project produces complex integrated solutions.
MC 3.3
Practice Statement
Monitor the work environment to identify issues.
Value
An effective, safe, and healthy work environment helps ensure objectives are met.
Identify and correct environmental and physical factors that degrade the safety, health,
effectiveness, and productivity of the workforce.
Monitor the environment to ensure that people can focus on achieving objectives and are free
from issues and unwanted distractions. Ensure the entire workforce recognizes that worker
safety and health is central to objective accomplishment.
Example Activities
Monitor work environment Work environment elements may include:
elements that affect safety, • Standard workstation hardware and software
health, effectiveness, and • Standard production and calibration equipment
productivity and identify and • Buildings, facilities, and other physical resources
record any corrections needed. • Security
• Safety
• Management and leadership
• Specific environmental conditions
• Periodic inspections of the work environment
• Health and welfare
249

• Diversity
• Privacy
Monitor physical factors in the Examples of physical factors that could degrade performance include:
work environment that could • Inadequate office or meeting space
degrade performance and • Poor lighting
identify and record any • Inadequate heating, ventilation, or cooling
corrections needed. • Unpleasant odors or fumes
• Vibration
• Excessive noise
• Crowding or isolation
• Environmental hazards
Identify, record, and report Examples of potential work environment issues problems include:
potential work environment • Failure to apply required safety standards
issues and corrections needed. • Inadequate security
• Improper ergonomics
• Exposure to unhealthy substances
• Poor air or water quality
• Excessive stress
Take reasonable steps to
accommodate work
environment issues while
corrections are being made.
Remove or reduce Examples of interruption or distraction include:
interruptions or distractions • Frequent telephone calls
that degrade performance. • Excessive meetings
• Excessive administrative tasks
• Work that could be better performed by others
• Excessive socializing, including social media, texting, etc.
Remove or reduce physical Examples of what could lessen the effects of physical work
factors that degrade environment factors include:
performance. • Providing resources that reduce the effect of the problem, e.g.,
fans or heaters to correct inadequate temperature control
• Communicating intentions that will remove the problem, such as
working from home or planned additional office space
Allow people to make reasonable adjustments that reduce the effect
of problems specific to them.
Monitor progress of work Analyze the results after the initial corrections and decide whether
environment issue resolution. further correction to work environment issues is needed.
If it is not possible to effectively eliminate the effect of a physical
factor, pursue alternative mitigation strategies and solutions.
If the initial correction to physical factors did not address the
problem, review and identify potential reasons and alternative
solutions to address them.
250

Resolve interpersonal Examples of ways to resolve interpersonal problems include:
problems that degrade work • Improving interpersonal communication skills by mentoring or
relationships. formal training
• Advising or counseling one or more individuals
• Using an ombudsman, arbitrator, or facilitator
• Reassigning one or more individuals
• Taking disciplinary action
• Agreeing to disagree

Corrections needed to the work environment
MC 3.4
Practice Statement
Manage and resolve issues with affected stakeholders.
Value
Resolving issues early increases the likelihood of meeting objectives.
The purpose of this practice is to identify, communicate, and resolve issues with affected
stakeholders. When notified and engaged early in the process, stakeholders can more
effectively address their responsibilities to ensure they stay in sync with objectives and plans.
Examples of issues include:
• Incomplete requirements
• Design defects
• Late critical dependencies and commitments
• Solution problems
• Unavailable critical resources
Example Activities
Identify and record issues. Issues are commonly identified in meetings
and cross-functional coordination events.
Communicate issues to affected stakeholders.
251

Resolve issues with affected stakeholders.
Escalate the issues not resolvable with affected
stakeholders to the responsible managers.
Track issues to closure.
Communicate the status and resolution of issues with

Recorded issues Include the:
• Issue statement
• Person responsible
• Due date
• Resolution
• Status
Context Specific
Supplier Management
Monitoring is particularly important in a complex environment. The involvement of owners,

acquirers, and customers of other systems is crucial to the success of complex integrated
solutions.
Monitoring is also important in an environment where a supplier is using an agile methodology
in solution development activities. In such an environment, the sustained involvement of end
users or their proxies can be crucial to developing and validating one or more elements of the
overall provided capability.
252
Intent
Develop the skills and knowledge of personnel so they perform their roles efficiently and
effectively.
Value
Enhances individuals’ skills and knowledge to improve organizational work performance.
Practice Summary
Level 1
OT 1.1 Train people.
Level 2
OT 2.1 Identify training needs.
OT 2.2 Train personnel and keep records.
Level 3
OT 3.1 Develop and keep updated the organization’s strategic and short-term
training needs.
OT 3.2 Coordinate training needs and delivery between the projects and the
organization.
OT 3.3 Develop, keep updated, and follow organizational strategic and short-
term training plans.
OT 3.4 Develop, keep updated, and use a training capability to address
organizational training needs.
OT 3.5 Assess the effectiveness of the organization’s training program.
OT 3.6 Record, keep updated, and use the set of organizational training records.
The training program supports the organization’s business objectives, and training needs that
are common across projects and support groups. The organization coordinates with projects
and support groups to determine responsibility for providing training.
Provide training to enhance skills and knowledge including:
• Technical skills related to:
253
o Using equipment, tools, materials, and data

o Processes required by the work or the organization
• Organizational skills related to:
o Role and responsibilities
o General operating principles and methods
o Behavior within the organization
• Contextual skills related to:
o Self-management
o Communication
o Interpersonal abilities needed to successfully perform work
Deliver training either informally, e.g., brown bags, task/job walk-throughs; or formally, e.g.,
classroom, electronic-based training, workshops, guided self-study, formalized on-the-job
training.
Figure OT-1 shows the primary elements involved in an organizational training program.
Figure OT-1: Elements in an Organizational Training Program
An organizational training program involves:

• Determining and identifying the organizational training needs
254
• Planning for training

• Developing a training capability and keeping it updated to:
o Identify how training will be obtained or developed
o Develop, design, and keep updated training materials, schedules, records, and
related data
o Develop mechanisms for measuring the effectiveness of the training and the
training program
o Identify personnel with training delivery skills and subject matter expertise to
deliver training
• Providing training
• Keeping records of completed training
• Maintaining and using the organizational set of training records
• Assessing training effectiveness (against organizational training needs) and
communicate results
Context Specific
Services
Consider affected stakeholders of the service system for organizational training activities.
Affected stakeholders include customers, end users, provider personnel, senior management,
external suppliers, and anyone else who is engaged with the service system. Develop, keep
updated, and follow training plans that include the appropriate forms of training and
communications to affected stakeholders. Training for affected stakeholders can vary greatly
based on the complexity of the service system, scope of transition changes to the service
system, and the knowledge and skills of the stakeholders.
255
Level 1
OT 1.1
Practice Statement
Train people.
Value
Increases likelihood of meeting objectives by ensuring individuals have needed skills and
knowledge.
Example Activities
Identify people who will receive the
training.
Schedule training.
Deliver the training.

Completed training
256
Level 2
OT 2.1
Practice Statement
Identify training needs.
Value
Reduces costs by providing training needed to perform the work.
Identify the skills and knowledge needed for each role. Compare this to the skills and
knowledge of the individuals in those roles to determine what training is needed.
Example Activities
Identify skills and knowledge for each
role.
Record and keep updated skills and
knowledge of individuals.
Perform a gap analysis to determine
training needs.
Record and communicate training
needs.

List of training needs List of needs should include:
• Skills and knowledge by role
• Skills and knowledge for individuals
• Gaps for needed training

Planning (PLAN)
257
OT 2.2
Practice Statement
Train personnel and keep records.
Value
Avoids training people who already have the needed knowledge and skills and ensures that
people get the training needed to perform their work.
Example Activities
Deliver training based on identified
training needs.
Maintain training records.

Records of delivered training Include:
• Training name
• Description of delivered training
• Date completed
• Student names
• Instructor names
• Pass/fail indicator
258
Level 3
OT 3.1
Practice Statement
Develop and keep updated the organization’s strategic and short-term training needs.
Value
Maximizes the likelihood of meeting objectives by ensuring that the organization has skilled
individuals now and in the future.
Strategic training needs address long-term business objectives to build capability by:
• Filling significant knowledge gaps
• Keeping current with new and emerging technologies
• Adapting to changing business needs
Strategic training considerations typically cover a span of time into the future beyond the short-
term training activities. Strategic training is typically linked to organizational strategic needs and
objectives.
Examples of sources of strategic training needs include:
• The organization’s business plan
• The organization’s standard processes
• The organization’s process improvement plan
• Enterprise-level initiatives
• Skill assessments showing common long-term needs
• Industry trends
The primary difference between strategic and short-term needs is how quickly that competency
is needed.
Short-term training needs address immediate business objectives to build capability by:
• Filling current knowledge gaps
• Responding to an event driven need
• Introducing new, currently needed technologies
When developing strategic and short-term training needs, consider:
• The organization’s business plan
259
• The organization’s standard processes

• The organization’s process improvement plan
• Background of the target population of training participants
• Need for cross-discipline training
• Need for training in organizational processes
• Need for training in disciplines related to support functions
• Need to maintain competencies and qualifications of personnel to continue to perform
current and future projects
Example Activities
Determine the roles and skills needed
to perform the organization’s set of
standard processes and the work to be
performed.
Determine training needs. Analyze and prioritize the strategic and short-term training
needs taking into account the considerations noted in this
practice.
Record and keep updated the For example, training needed to:
prioritized strategic and short-term • Perform roles in the organization’s set of standard
organization training needs. processes
• Maintain the safe, secure, and continued operation of the
business
Review the organization’s training
needs periodically and on an event
driven basis and update the needs if
required.

Training needs
OT 3.2
Practice Statement
Coordinate training needs and delivery between the projects and the organization.
Value
Ensure efficient and effective allocation of training resources.
260

Organizational training addresses training needs and requirements that are common across
projects. The organization’s training personnel may also provide or support the additional
training needs of the projects and organization based on the organization’s priorities and
training resources.
Example Activities
Analyze the training needs identified by Identify common training needs that can be addressed
work and support groups. organization wide. Analysis helps predict future training
needs that are first visible at the work and support group
level.
Coordinate with projects and support
groups to determine how training
needs will be addressed.
Record responsibilities among the
organization, project, and support
groups for delivering training.

Allocated training needs May include:
• Organization common needs
• Project needs
• Support group needs
Training delivery responsibilities Allocated to the:
• Organization
• Projects
• Support groups
OT 3.3
Practice Statement
Develop, keep updated, and follow organizational strategic and short-term training plans.
Value
Ensure personnel are trained to enable them to efficiently and effectively perform their tasks.
261

The strategic training plan describes how the organization will deliver training to meet the
recorded long-term needs. The organizational training short-term plan addresses near-term
training implementation. Adjust the plans periodically in response to changes and evaluations of
effectiveness.
Example Activities
Develop the content of the Plan should address:
organizational training strategic plan. • Strategic training needs
• Approach to delivering training
• Prioritization
• Timeframes
• Methods for ensuring training effectiveness
• Resources
Develop the content of the Organizational training short-term plans typically contain:
organizational training short-term plan. • Training needs
• Training topics
• Schedules and their dependencies
• Methods used for training
• Requirements and quality standards for training materials
• Training tasks, roles, and responsibilities
• Ensuring training effectiveness
• Required resources such as:
o Tools
o Facilities
o Environments
o People
Review plans, determine commitments,

and communicate the review results to
Revise the plans and commitments as
needed.

Organizational training strategic plan
Organizational training short-term plan
Recorded commitments

Planning (PLAN)
262
OT 3.4
Practice Statement
Develop, keep updated, and use a training capability to address organizational training needs.
Value
Ensure personnel have the knowledge, skills, and abilities to perform their work efficiently and
effectively.
Provide the training to meet the needs of the organization, projects, and support groups.
Example Activities
Select approaches to satisfy To select an approach, consider how to provide skills and
organizational training needs. knowledge in the most efficient and effective way.
Factors that can affect the selection of training approaches,
include:
• Learner knowledge
• Constraints
• Costs
• Schedule
• Work environment
Examples of training approaches include:
• Classroom training
• Computer or technology aided instruction, e.g., tutorials,
simulations, webinars
• Guided self-study
• Formal apprenticeship and mentoring programs
• Facilitated videos
• Chalk talks
• Brown bag lunch seminars
• Structured on-the-job training
Decide whether to develop training Decision criteria may include:
internally or to acquire it externally. • Preparation time
• Availability of in-house expertise
• Availability of external training
• Training effectiveness data
Examples of external sources of training may include:
• Customer-provided training
• Commercially available training courses
263

• Academic programs
• Professional conferences
• Seminars
Develop or obtain training materials. Examples of training materials include:
• Curriculum
• Syllabus
• Handouts
• Books
• Exercise instructions
• Videos and interactive media
• Virtual environments
• Simulations or labs
• Mobile applications
Identify, train, or hire qualified For those who develop and deliver internal training,
instructors, instructional designers, or consider:
mentors. • Subject matter expertise
• Relevant training skills and experience
• Experience in instructional design
• Mentoring skills
Describe the training in the Examples of information provided in training descriptions
organization’s training curriculum. include:
• Topics covered in the training
• Intended audience
• Prerequisites and participant preparation
• Training objectives
• Length of the training
• Lesson plans
• Completion criteria for the course
• Criteria for granting training waivers
Review training periodically and on an For example, review for:
event-driven basis. • Compliance with defined standards
o Instructional design standards
o Content standards
• Revisions needed in the standards
• Effectiveness
Revise training materials as needed.
Identify and make available resources
for delivering the training.
Update the training and development
program.
Keep training records updated.
Communicate availability of training.
264

Training materials and supporting
artifacts
List of courses
Training records
List of instructors May include certifications and experience.
Instruction design standards
Training facilities and resources

OT 3.5
Practice Statement
Assess the effectiveness of the organization’s training program.
Value
Keeps the training program relevant and valuable to the business and makes effective use of
training resources.
Develop a process to determine how effectively training:
• Improves the capability of people to perform their work
• Enables achieving performance improvement goals
• Meets the organization’s needs and objectives
Effective assessment of training includes:
• Pre- and post- training assessments to determine before and after levels of competence
• Measurement scales of training effectiveness
To ensure that the information is not used for positive or negative individual incentives,
individuals’ training effectiveness assessments should not be reported to their managers.
265
Example Activities
Assess the effectiveness of each Examples of methods used to assess training course
training course. effectiveness may include:
• Testing in the training context, e.g., meeting learner
objectives
• Assessment mechanisms embedded in courseware
• Evaluations of instructor effectiveness
• Pre- and post-training assessments involving training
participants and their managers to determine if the
training delivered has helped the projects
Assess the effectiveness of the training Examples of methods used to assess training program
programs. effectiveness may include:
• Analysis of the improvement in performance of individuals
to determine effectiveness of the:
o Training provider
o Instructors
o Course materials
o Overall program
• Process non-compliances; these can be considered as an
input and may indicate an issue with the training program
• Surveys on the training program effectiveness
• Industry standards for benchmarking training
effectiveness against behavioral and performance
improvements goals

Training effectiveness surveys May include both individual course surveys and overall
program surveys
Training program assessments Assessments may include instructor observations.
Training program analysis results
Instructor evaluation forms May include trend and pattern analysis across multiple
courses
Training examinations
Training measures May include:
• Pre- and post-training assessment results
• Achievement of benchmarking goals
266
OT 3.6
Practice Statement
Record, keep updated, and use the set of organizational training records.
Value
Records are essential in determining how well the training program supports the achievement
of business and performance goals.
Ensure that training records are kept for individuals, projects, and support groups, and
organizational training.
Example Activities
Keep and use records of all
participants.
Keep and use records of all personnel Record the rationale.
who are waived from training.
Keep and use records of the training May include:
course and program effectiveness. • Course evaluations and other feedback mechanisms and
information
• Improvement of individual performance
• Contextual information of provided training:
o Instructor
o Course name
o Provider
o Date delivered
o Participants
• Course feedback
Make training records available to the Training records may be part of a skills matrix summarizing
appropriate people for consideration in the experience and education of people.
assignments.

Training records
267
Peer Reviews (PR)
Intent
Identify and address work product issues through reviews by the producer’s peers or Subject
Matter Experts (SMEs).
Value
Reduce cost and rework by uncovering issues or defects early.
Practice Summary
Level 1
PR 1.1 Perform reviews of work products and record issues.
Level 2
PR 2.1 Develop and keep updated procedures and supporting materials used to
prepare for and perform peer reviews.
PR 2.2 Select work products to be peer reviewed.
PR 2.3 Prepare and perform peer reviews on selected work products using
established procedures.
PR 2.4 Resolve issues identified in peer reviews.
Level 3
PR 3.1 Analyze results and data from peer reviews.
Performing peer reviews helps to find issues and remove defects from work products early. A
peer review is an important and effective verification, validation, and assurance activity. Peer
reviews may be implemented via inspections, structured walkthroughs, audits, or other review
methods. Peers or relevant SMEs methodically and objectively examine work products to
identify defects for removal.
Teams performing peer reviews can benefit from:
• Defining selection criteria to focus on the most important areas
• Selecting what to peer review
• Performing peer reviews thoroughly with multiple view points
• Analyzing data to identify quality trends and improvements
268
Issues found during peer reviews may include:

• Defects related to work products
• Performance or functional issues
• Process-related issues
• Cost, risk, and schedule issues
Performing a peer review includes:
• Preparing for review
• Selecting methods or techniques
• Reviewing the work products
• Recording the data
Perform peer reviews incrementally as work products are developed. Peer reviews are
structured and are not management or status reviews.
Peer reviews can be applied to any work product regardless of who produced it. The focus of
the peer review should be on the work product, not on the author. When defects are identified
during a peer review, communicate them to the author for correction.
The most effective peer reviews ensure that participants are objective and candid about their
evaluations. Protect peer review data collected to prevent inappropriate use, such as:
• Disciplining or rewarding people
• Publicly criticizing or praising performance
• Violating data security and privacy laws
Context Specific
Figure PR-1 is an example of where peer reviews can be performed in an agile project using
Scrum. Examples may include:
• Performing backlog grooming
• Demonstrating completed stories during the sprint review with product owner
• Using pair, team, or mob programming during each sprint
• Reviewing design, test plans, test cases, and code work products
• Performing peer reviews thoroughly with multiple viewpoints
269
Figure PR-1: PR in an Agile Framework
Agile teams benefit from systematically performing peer reviews of selected work products that
affect quality. Performing backlog grooming and a sprint demo would not consistently be as
thorough.
270
Level 1
PR 1.1
Practice Statement
Perform reviews of work products and record issues.
Value
Improves work product quality and reduces cost and rework by uncovering issues early.
Example Activities
Review work products to identify
issues.
Record results.

List of issues from work product Identifies the:
reviews • Work product reviewed
• Issues
271
Level 2
PR 2.1
Practice Statement
Develop and keep updated procedures and supporting materials used to prepare for and
perform peer reviews.
Value
Maximizes efficiency and effectiveness of finding issues in peer reviews.
Example Activities
Record and keep updated peer review
procedures.
Record and keep updated related
supporting materials.

Procedures for preparing for and Procedures may include:
performing peer reviews • Criteria for selecting and reviewing work products
• Selecting work products
• Deciding peer review type
• Work product evaluation criteria
• Selecting participants and assigning roles
• Preparing and distributing review material
• Peer review steps
Supporting materials May include:
• Work product standards and templates
• Work product functionality and quality attributes
• Common issues or defect types
The above items may be included as part of a checklist.
272
PR 2.2
Practice Statement
Select work products to be peer reviewed.
Value
Targeting critical work products for peer review helps to manage cost.
Example Activities
Evaluate the criticality of the work It may not be possible to review every work product. For
product. large or complex work products, it may not be possible to
review the entire work product. The evaluation should
consider the highest priority work products or elements.
Example criteria include: the most critical section, the most
used by the user, the costliest if defective, the most error-
prone, the least well understood section, or the most
frequently changed section.
Determine and record the review type Different work products may be more effectively reviewed
to use. using different techniques or methods.
Types of peer reviews may include:
• Inspections
• Structured walkthroughs
• Perspective-based reviews, which involve assigning
reviewer perspectives such as:
o Standards
o Domains
o Types of issues
• Objective evaluations

Work product selection criteria
List of selected work products Include the:
• Work product
• Review type
273
PR 2.3
Practice Statement
Prepare and perform peer reviews on selected work products using established procedures.
Value
Thorough and consistent review with early detection of work product issues leads to reduced
cost.
Example Activities
Develop schedule. This should be integrated with the work schedule.
Follow procedures.
Record results from the peer reviews May include:
and the data from the process. • List of issues found in the peer reviews
• Data related to process aspects, e.g., prep time, number of
work products, time spent in peer reviews
Communicate results to affected Results include the peer review process data and the issues.
stakeholders.

List of work products
Schedule May include:
• Planned date, time, and duration
• Reviewers
Peer review results May include:
• Completed supporting materials
• Issues
• Action items
• Data which may include:
o Time spent in preparing for and performing the review
o Role and number of reviewers
o Number and type of issues, defects, or actions
o The size of the work product examined
o Type of peer review
o Resolution of issues or defects
o Estimated rework time
o Defect origin
274

o Number of issues or defects expected
o Causes of defects
o Affected stakeholders

PR 2.4
Practice Statement
Resolve issues identified in peer reviews.
Value
Reduces rework, costs, and increases quality.
Example Activities
Resolve issues.
Record resolutions and results and Include expectations for when actions will be closed by
communicate to affected stakeholders. affected stakeholders.

Resolution of issues
Results May include data resulting from the review.
275
Level 3
PR 3.1
Practice Statement
Analyze results and data from peer reviews.
Value
Increases the efficiency and effectiveness of the process for performing peer reviews.
One of the primary objectives of peer reviews is to identify and remove defects early in the
project. Analysis of results can help identify trends in defect injection and sources and types of
defects.
In addition, it is important to analyze data about the preparation and conduct of peer reviews in
order to determine the efficiency and effectiveness of the peer review process.
Example Activities
Analyze peer review process data and
the results from the peer review.
Record and communicate analysis This typically includes:
results. • When defect was injected
• Preparation time or rate versus expected time or rate
• Number of issues versus number expected
• Types of issues detected
• Causes of issues
• Issue resolution impact
• Stakeholders associated with issues

Analysis results Analysis of peer review data can aid in avoiding, minimizing, or
preventing future issues or defects. Types of analysis may include:
• Causal analysis
• Trend analysis
• Common issue resolution analysis

276
Planning (PLAN)
Intent
Develop plans to describe what is needed to accomplish the work within the standards and
constraints of the organization, including the:
• Budget
• Schedule
• Resource demand, capacity and availability
• Quality
• Functionality requirements
• Risks and opportunities
Plans also describe:
• The work to be performed
• Applicable organizational set of standard processes, assets, and tailoring guidelines
• Dependencies
• Who performs the work
• Relationships with other plans
• Stakeholders and their role
Value
Optimizes cost, functionality, and quality to increase the likelihood of meeting objectives.
Planning includes developing budgets and schedules based on estimates; identifying the
appropriate set of stakeholders and tasks; managing risks; determining the necessary
resources; and developing and keeping the project plan updated to reflect how to perform the
work. An important aspect of planning is capacity and availability management.
Capacity and availability management activities can be performed at different levels of the
organization and applied to any type of work. Capacity and availability management activities
typically involve:
• Developing a capacity and availability management approach and keeping it updated
• Providing and allocating resources
• Monitoring, analyzing, understanding, forecasting, adjusting, and reporting on current
demand for:
o Work activities
277
o Services
o Solutions and Deliverables
o Resources
o Capacity and availability
o Service or service system performance
o Availability
• Determining corrective actions to ensure appropriate capacity and availability while
balancing costs against resources needed and supply against demand
Practice Summary
Level 1
PLAN 1.1 Develop a list of tasks.
PLAN 1.2 Assign people to tasks.
Level 2
PLAN 2.1 Develop and keep updated the approach for accomplishing the work.
PLAN 2.2 Plan for the knowledge and skills needed to perform the work.
PLAN 2.3 Based on recorded estimates, develop and keep the budget and schedule
updated.
PLAN 2.4 Plan the involvement of identified stakeholders.
PLAN 2.5 Plan transition to operations and support.
PLAN 2.6 Ensure plans are feasible by reconciling available and estimated
resources.
PLAN 2.7 Develop the project plan, ensure consistency among its elements, and
keep it updated.
PLAN 2.8 Review plans and obtain commitments from affected stakeholders.
Level 3
PLAN 3.1 Use the organization’s set of standard processes and tailoring guidelines
to develop, keep updated, and follow the project process.
PLAN 3.2 Develop a plan and keep it updated, using the project process, the
organization’s process assets, and the measurement repository.
PLAN 3.3 Identify and negotiate critical dependencies.
PLAN 3.4 Plan for the project environment and keep it updated based on the
organization’s standards.
Level 4
PLAN 4.1 Use statistical and other quantitative techniques to develop and keep the
project processes updated to enable achievement of the quality and
process performance objectives.
278

The term project plan refers to the overall plan for managing the project and includes a
coherent picture of who does what and when they do it. The project plan can be a stand-alone
document or distributed across multiple documents and provides a way to track and
communicate actual progress and to determine and take corrective action. As the project
progresses, revise the project plan to address changes in requirements, commitments,
inaccurate estimates, corrective actions, and methods of performing activities.
When planning resources, always consider capacity and availability. Capacity is the degree to
which resources can support the work, while availability is the degree to which the resources
are accessible when needed. Management of capacity and availability provides the sustained
resources to meet requirements in a cost-effective manner.
Examples of capacity include:
• Number of people resources with specified skills
• Number and types of workstations
• Server capacity
• Network bandwidth
• Office space
• Tools
Examples of availability include:
• Business operating hours
• Service or system uptime
• Consumables, e.g., forms, pens
• Staffing calendars
• Number of parking spaces
Estimating (EST)
Context Specific
Figure PLAN-1 states where planning is typically performed in an agile project using Scrum.
Table PLAN-1 shows example planning information and related model practices.
279
Figure PLAN-1: Planning in an Agile Framework
280
Table PLAN-1: Planning Information & Related Model Practices
Typical agile planning practices result in the following plan information:

• Product Backlog: A prioritized collection of user stories or epics that represent the
entire set of known stories. Stories in the product backlog are often not yet estimated
and are typically developed by the product owner, with assistance from business
analysts and other team members.
• Sprint Backlog: The collection of user stories or epics selected for the sprint that will
be estimated and further broken down into tasks by the agile team. The sprint backlog
is a forecast of what the team believes can be accomplished during the sprint.
• Story Responsibility: Team members “self-subscribe” to user stories and commit to
completing them during the sprint. Responsibility for each story is usually recorded on a
task board and can be redistributed as needed to manage the workload of the team (see
Table PLAN-1).
• Schedule: Each sprint has a fixed duration (usually 2-4 weeks) and the collection of
sprints defines the total anticipated release schedule.
• Budget: Agile teams typically adhere to a fixed team, fixed time-box model that, when
examined in aggregate, helps to identify key drivers of the project’s budget.
281
Context Specific
Development
Most engineering disciplines can benefit from project planning practices and include examples
such as:
• Software development
• Hardware development
• Systems development
• Manufacturing or product lines, such as in:
o Developing and maintaining core assets, e.g., components, tools, architectures,
operating procedures, software
o Supporting the use of core assets
o Developing each individual system from core assets
o Coordinating the overall effort of developing, using, and improving the core
assets
• Construction and maintenance
Services
Responding to service requests may require detailed, frequently revised plans for allocating
resources to tasks and managing the task queue, e.g., assigning repair jobs in a maintenance
shop. Consider these low-level operating plans as an extension of the overall service plan.
When planning for transitions in services or service system components, e.g., archival of a
service, upgrade technology and account for all operational and support activities affected by
the transition. Typically, organizations record this information in a transition plan. When
planning for services, consider plans for service continuity.
Supplier Management
Planning for supplier management is based on the acquisition strategy. The acquisition strategy
is a guide for directing and controlling the work, and a framework for integrating activities
essential to acquiring an operational solution. When needed, a supplier management approach
should be developed and included as part of the planning activities and should include such
items as:
282
• Availability of assets and technologies

• Supplier management objectives and constraints
• Consideration of supplier selection and management methods
• Potential supplier agreement types and terms
• Accommodation of end user considerations
• Consideration of supplier risk
• Support for the project supplier management activities throughout the project lifecycle
This involves the development and maintenance of plans for all supplier management
processes, including plans required for effective acquirer-supplier interaction. Once the supplier
agreement is signed and schedules, costs, and resources from the supplier are established, the
acquirer takes the supplier estimations for the project into account, at an appropriate level of
detail, in its project plan.
Planning for supplier management also includes establishing and maintaining a plan for the
orderly, smooth transition of the acquired product from a supplier to its use by the acquirer or
the acquirer’s customers. In addition, if an existing product is to be replaced as part of the
acquired solution, the acquirer may be required to consider the disposal of the existing solution
as part of the planning for acquiring the new solution. All transition activities are included in the
project plan and provisions for accommodating such specialized requirements are also included.
283
Level 1
PLAN 1.1
Practice Statement
Develop a list of tasks.
Value
Ensure that the work needed to meet customer requirements is identified to increase customer
satisfaction.
Example Activities
Develop a task list. The level of detail of the task descriptions will vary based on
the size and complexity of the tasks.
Review the task list with affected
stakeholders.
Revise the list as needed.

Task list Includes:
• Tasks to be performed and their timeline
• Description of activities to assist in:
o Assigning team members
o Understanding what is expected
Context Specific
Services
284
When providing a service, it is important to know and list what resources are available for
performing the tasks needed to deliver the service. Identify needed and available resources to
understand where the service may use resources. This can also help identify where shortages
may occur. Unrecognized shortages may cause the organization to miss business objectives.
Activities can include:
• Developing the task list
• Developing a list of needed resources by task
• Developing a list of the available resources
The task list may include a high-level description of the tasks that need to be performed to
meet requirements or agreements. Include:
• Resource identifiers, i.e., a labor category for a human resource
• Descriptions of needed skills for the personnel resources, i.e., human resources,
training, professional certifications
• Descriptions of needed equipment, tools, or facilities
PLAN 1.2
Practice Statement
Assign people to tasks.
Value
Ensure that tasks will be performed to meet requirements and satisfy the customer.
Ensure all tasks are assigned to specific members of the project, and ensure that they know
which tasks they are responsible for completing. Identify the needed skills, experience, abilities,
and responsibilities needed to accomplish each task.
Example Activities
Assign an individual who is responsible Identify an individual with the skill and experience needed to
for each task. accomplish the task.
Assign any additional people to the Determine the project load and the abilities of the individuals
task. as a part of assigning them to the task.
Review assignments with the assigned Ensure that the assigned individuals understand what is
individuals. needed to complete the task assignment.
285

Record assignments in task list. Include feedback from assigned individuals on what is
needed to accomplish the project.

Task list with assignments Includes:
• Tasks
• Description of each task
• Name of the person or people assigned to work on that
task
286
Level 2
PLAN 2.1
Practice Statement
Develop and keep updated the approach for accomplishing the work.
Value
Maximize project success by keeping the affected stakeholders focused on accomplishing their
specific objectives.
The approach is particularly valuable for making decisions when requirements and work
changes. Identify the approach, and the priority of objectives for addressing requirements and
accomplishing the work. Strategy and approach typically include:
• Business considerations
• Objectives and constraints
• Possible approaches to meeting those objectives and constraints
• Requirements
• Project lifecycle description
• Needed resources, e.g., skills, environment, tools, new technologies
• Risks associated with the above and how they will be mitigated
Example Activities
Identify the objectives of the project. Describe what the project is trying to accomplish in terms of
expected outcomes.
Identify the approach to be used to Describe the why and how:
achieve objectives. • Tasks and how they are performed
• The work is going to be done
• Methods or techniques will be used
• How resources will be provided to support and accomplish
the work
Identify requirements. Record how requirements will be addressed in the approach.
Record business considerations. Business considerations may include:
• Potential costs and benefits
• Intellectual property
• Competitive climate
287

• Long-term needs and profit margins
• Core competencies to be enhanced
• Core competencies needed from other parties
• Future trends
Define and record the project lifecycle. The project lifecycle describes the major phases and
activities needed to accomplish the work.
The determination of a project’s lifecycle phases provides for
planned periods of evaluation and decision making. These
periods normally define logical points in the project plan,
strategy, and approach to identify when decisions are
needed to:
• Stay on course
• Change course including:
o re-estimating cost and scope
o re-renegotiating commitments
o re-planning resource usage
o adjusting budget and schedule
• Stop work
Understanding the project lifecycle is crucial in determining
the scope of the planning effort and the timing of initial
planning, as well as the timing and criteria (critical
milestones) for re-planning.
Define the project lifecycle phases based on the
requirements, the estimates for project resources, and the
nature of the work.
Identify major resource needs and Identify resource needs and the suppliers of these resources.
constraints. For example:
• Capacity and availability
• Other groups in the organization
• External suppliers
Identify stakeholders.
Record agreements with stakeholders. Decide the nature of these agreements by considering each
party’s needs, objectives, expectations, constraints, and
risks.
Identify risks.
Identify safety and security Consider safety and security in all major planning activities.
approaches.
Review the project approach with Review the approach from the following key business
affected stakeholders and obtain perspectives:
agreement. • Are these the right objectives?
• Is the approach feasible?
• Will the project be subjected to excessive risk?
• What safety and security issues are addressed and how
well are they handled?
288

Revise the approach as necessary. It may be necessary to refine the approach to reflect
changes in the objectives, approach, availability of resources,
market conditions, customer needs, technologies, etc.

Recorded approach for accomplishing
the objectives
Recorded project lifecycle

Context Specific
Development
Larger development projects can contain multiple phases, such as concept exploration,
development, production, operations, and disposal. A development phase can include
subphases such as requirements analysis, design, fabrication, integration, and verification. The
determination of project phases typically includes selection and refinement of one or more
development models to address interdependencies and appropriate sequencing of the activities
in the phases.
Depending on the strategy for development, there can be intermediate phases for the
development of prototypes, increments of capability, or spiral model cycles. In addition, include
explicit phases for startup and close-out as needed.
Services
The service approach can play various roles, but initially, it serves as the basis for senior
management to approve and commit resources. Revise the service approach through planning
when identifying the solution, processes, resources, and risks.
A service approach can be developed by the organization, by prospective service personnel,
e.g., in collaboration with potential customers and suppliers, or by some other combination of
parties with a strategic business view of the service.
The service approach can include a high-level description of the service, the development
approach, and the delivery approach and approached for automated service delivery, as
appropriate.
289
Supplier Management
The acquisition strategy defines the approach for formulating solicitation packages, supplier
agreements, and plans. The strategy evolves over time and should continuously reflect the
status and desired end of the work. The acquisition strategy establishes the acquisition phases,
milestone decision points, and accomplishments for each acquisition phase. Develop the
acquisition strategy from an understanding of the acquisition work and environment. The
acquirer considers the:
• Potential value or benefit of the acquisition
• Risks or opportunities
• Constraints
• Experiences with different types of suppliers and agreements
The acquisition strategy includes:
• Acquisition objectives and constraints
• Asset and technology availability
• Consideration of acquisition methods
• Potential supplier agreement types
• Terms and conditions
• End user considerations
• Risk and opportunity considerations
• Core asset development and maintenance considerations
• Operational support processes
A well-developed acquisition strategy minimizes the time and cost required to satisfy approved
capability needs and maximizes affordability throughout the lifecycle.
When an acquisition uses an evolutionary lifecycle, the strategy may describe the function, and
how the acquirer and supplier will fund, develop, test, produce, and support the increasing
functionality of the solution.
Business considerations for the acquisition strategy may include:
• Type of competition planned for all phases of the acquisition or an explanation of why
competition is not practical or not in the best interests of the acquirer
• Developing or keeping updated access to competitive suppliers for critical solutions or
solution components
• Availability and suitability of commercial items and the extent to which interfaces or
connections for these items have broad market acceptance, standards, organization
support, and stability
290
• Both international and domestic sources that can meet the required need consistent with
organizational policies and regulations
• Critical technologies
• Data rights
• Product line considerations
• Socio-economic constraints
• Safety and health issues
• Security issues, including physical and information technology
• Other business-oriented solution quality characteristics that can be market
differentiators or mission critical, e.g., solution responsiveness, platform openness,
availability, sustainability
The acquisition strategy explains the planned acquisition incentive structure. This may include
providing incentives for delivering the solution at or below the established cost targets, while
satisfying requirements. Consider using incentives to manage risks.
If operations and maintenance support is going to be performed by an organization different
from the supplier, define a sufficient overlap period to ensure a smooth transition. The
acquirer’s sustainment organization or supplier typically participates in the development of the
solution support strategy.
PLAN 2.2
Practice Statement
Plan for the knowledge and skills needed to perform the work.
Value
Enables efficient and effective use of personnel resources.
Assess each individual’s knowledge and skills against the critical skills required for work
assignments to decide if training in these skills is needed. Examples of critical skills include the
ability to:
• Execute specific processes
• Perform tasks within specific time limits
• Perform tasks to defined accuracy
• Use equipment safely and effectively
291
• Follow instructions
• Interpret information
• Organize actions, material, or people
• Communicate to perform assigned tasks. Examples of communication skills include:
o Literacy in one or more of the languages used in the organization
o Knowledge of local jargon or technical terms
o Knowledge of communication protocols
o Oral presentation skills
o Negotiating skills
o Writing skills
o Ability to use communication media
Examples of items to be considered when evaluating knowledge and skills may include:
• Individual’s personal assessment
• Individual’s previous experience
• Performance feedback sessions and reviews
• Tests
• Training records
Example Activities
Identify the knowledge and skills
needed to perform the work.
Determine the gaps between the
knowledge and skills needed versus
those held by the currently assigned
people.
Select methods for providing needed Training may be either in-house (both organizational and
knowledge and skills. project) or external.
Methods may include:
• Staffing and new hires
• Classroom instruction
• Online or computer-aided training
• Apprenticeship or mentoring programs
• Job rotation or cross-training
• Conferences, seminars, workshops, and tutorials
• College and university courses
• Videos
• Directed self-study courses
Incorporate selected methods into the
project plan.
292

Inventory of skill needs Results may include the following needs:
• Skills
• Experience
• Training

Context Specific
Services
For long-duration and continuous-operation services, the knowledge and skills needed change
as:
• Personnel rotate in and out of the projects (or from one service type to another)
• Technology used in the service system or for an individual service changes
• Processes and technology used in the development or customer environments change
For example, a personnel change triggers the need to reevaluate the knowledge and skills
required for new team members. The types of knowledge and skills needed may change during
different phases of the service lifecycle, when adding new services, or changing service levels.
Plan for needed knowledge and skills to better address these sources of change.
Supplier Management
The acquirer plans for knowledge and skills required by the acquisition team to perform their
tasks.
For example, if the acquirer is purchasing a software-intensive solution, ensure that the
assigned acquisition personnel have expertise in systems and software engineering or the
acquirer will train personnel in these areas. The acquirer requires that personnel have
orientation and training in acquirer processes and domain knowledge. Personnel involved in
receiving, storing, using, and supporting the acquired solution also may need appropriate
training.
The acquirer also plans for knowledge and skills needed from the supplier. For example, the
acquirer can provide role descriptions and skill profiles to the supplier as part of the solicitation
package.
293
PLAN 2.3
Practice Statement
Based on recorded estimates, develop and keep the budget and schedule updated.
Value
Early detection of significant deviations from the budget and schedule enables timely
management and corrective actions needed to achieve objectives.
Record and maintain the budget, effort, and duration needed to accomplish the work.
Example Activities
Identify major milestones. Milestones can be event-based or time-based.
Identify schedule assumptions. Assumptions are frequently made on items with little, if any,
available estimation data. Identifying assumptions about
activity duration provides insight into the confidence level
(i.e., uncertainties) in the overall schedule.
Identify constraints. Identify factors that limit planning flexibility as early as
possible. Examining solution and task characteristics
identifies these issues. Constraints may include:
• Resources
• Defining dependencies among activities (predecessor or
successor relationships)
• Supplier availability
Identify task dependencies. A critical part of ordering tasks for a project is identifying
task dependencies.
Tools and inputs that can help determine the optimal
ordering of task activities may include:
• Critical Path Method (CPM)
• Program Evaluation and Review Technique (PERT)
• Resource limited scheduling
• Customer priorities
• User or end user value
• Work packages
Identify resources. Project resources may include:
• Staffing needs and costs
294

o Base staffing decisions on projects, tasks, roles and
responsibilities, and the knowledge and skills required
for each position
• Equipment
• Environment
• Materials
• Facilities
• Consumables
• Access to intellectual property
• Transportation, e.g., people and materials
Identify and analyze risks. Review and analyze identified constraints and record them as
risks if they potentially impact the budget or schedule.
Based on estimates, develop the Often includes:
budget and schedule, and keep them • Estimating size, complexity, effort, duration, and cost
updated. • Defining the committed or expected availability of
resources
• Determining the time phasing of activities
• Determining a breakout of subordinate schedules
• Defining schedule activities of appropriate duration
• Identifying releases or increments for the delivery of
solutions
• Using appropriate historical data to verify the schedule
• Defining incremental funding requirements
• Updating project assumptions and rationale
• Updating risks
• Defining a management reserve based on the risks to the
schedule and budget
Establish corrective action criteria. Establish criteria to determine what constitutes a significant
deviation from the project plan. A basis for gauging issues
and problems is necessary to decide when to take corrective
action.

Budget The budget should be based on tasks and resources.
Schedule The schedule should be based on tasks, resource availability,
and dependencies. The schedule and Work Breakdown
Structure (WBS) should be aligned to the project lifecycle.
May include a:
• WBS or list of tasks and activities
• Task dictionary
Resource plan May include:
• Personnel requirements based on work size and scope
• Critical facilities and equipment list
Budget and schedule risks
295

Estimating (EST)
Context Specific
Services
Individual service requests, e.g., to repair a piece of equipment in a remote facility, transport a
package to a destination, can have individual milestones, task dependencies, resource
allocations, and scheduling constraints. Consider these milestones together and coordinate with
larger budgeting and scheduling activities.
Develop communication methods during service system development. Review, tailor, and
possibly supplement communication methods regularly to meet ongoing service delivery needs.
Budget development for service-related activities may include:
• Service components consumed during the lifecycle of a service request or for multiple
service requests that span multiple customers
• Type of resources required, e.g. 24-hour available resources for VIP services
• Expected number of service requests considered in a service agreement
• New resources that need to be added, purchased or modified to comply with current or
future demand
Supplier Management
For the duration of the work, define, track, and keep updated:
• Budget and schedule, including both acquirer and supplier activities
• Critical dependencies of supporting organizations, including any suppliers that support
the acquirer
PLAN 2.4
Practice Statement
Plan the involvement of identified stakeholders.
296
Value
Ensures that stakeholder needs are addressed when they arise, reducing the amount and cost
of rework.
Stakeholder involvement allows the project to focus on:
• Developing the right solutions
• Delivering adequate services
• Acquiring compatible solutions that provide the required functionality
Identify personnel who must be included in the project for it to be accomplished in accordance
with requirements. Affected stakeholders may include:
• People and functions that should be represented
o Those affected by the activity
o Those who have the needed expertise to perform the activity
Affected stakeholders are those who will participate in the project’s activities. The list of
affected stakeholders may change as work progresses. It is important to ensure that affected
stakeholders have early input to the planning of the project.
Some stakeholders, such as higher levels of management and customers, may have no formal
role in the project, but are invested in the outcome. Consult these stakeholders for advice and
consent when the scope may change.
Example Activities
Develop a list of stakeholders.
Identify the involvement of each Describe how and why each stakeholder is involved and what
stakeholder. is required of them.
Record when the involvement is Address the timing and sequencing for stakeholder input and
required. involvement.

Stakeholder involvement plan May include:
• List of affected stakeholders
• Rationale for involvement
• Relationships, roles, and responsibilities
• Schedule of interaction
Responsible, Accountable, Support, Defines the RASCI for activities and work products.
Consulted, Informed (RASCI) table
297
Context Specific
Services
Plan for the involvement of stakeholders with service system transition activities, e.g., inclusion
of a new product, update of technology for service system components. Affected stakeholders
include customers, end users, provider personnel, senior management, external suppliers, and
anyone else who should be aware of expected changes. Consider the magnitude of the change
in planning for the appropriate level of detail and involvement during the transition.
Example mechanisms for involving stakeholders of service system transitions include:
• Automatic notifications from the service system
• Posted information within the service system
• Progress reviews, discussions, or approaches
• Communications through newsletters
• Updates of user guides and user procedures
• Updates of user training
Supplier Management
Stakeholders can include acquirers, supplier team members, end users, and other involved
parties. When acquiring complex integrated solutions involving multiple suppliers, the acquirer
needs to ensure coordination between all stakeholders. This planning typically includes steps for
developing and keeping updated supplier agreements with these stakeholders, e.g., interagency
and intercompany agreements, memoranda of understanding, memoranda of agreement.
PLAN 2.5
Practice Statement
Plan transition to operations and support.
Value
Minimizes surprises and rework during adoption and deployment.
298

Planning for transition should be considered part of the initial planning for the project. Even in
the case of small projects, transition and delivery of the solution must be addressed.
Plans for the transition to operations and support include the:
• Approach for introducing and maintaining readiness
• Sustainment
• Operational capability of the solutions
• Assignment of responsibility for the transition, delivery, and support
• Activities needed to manage the transition
• Support for the solution in its intended environment, including:
o Definition of transition readiness criteria
o Reviews with affected stakeholders
• Handling of potential risks
• Changes to the solution over time
• Eventual removal of the solution from operational use
Example Activities
Determine transition scope and objectives.
Determine transition requirements and Includes timing, dependencies, and other high-level
criteria. elements of moving the solution into operations.
Determine approach to transition.
Develop schedule for transition.
Determine transition responsibilities and If the project team is not responsible for transition,
resources including post-transition support. described who is responsible.
Includes:
• Transition infrastructure
• Future enhancements
Determine operations and support training Identifies any additional skills, experience, or knowledge
needs. needed for successful and smooth operation.

Plans for transition to May include:
operations and support • Scope and objectives
• Assignment of responsibility
• Transition processes and procedures
299

• Activities needed to manage the transition and support the solution
in its intended environment
• Risks
• Evaluation methods and acceptance criteria to ensure the transition
of the solution to operations and support
• Readiness criteria for the operations organization and environment
• Transition of intellectual property or other assets to the designated
repository
• Resolution steps if problems are encountered
• Readiness criteria for the solutions
• Readiness criteria for the solution support organization
• Identification of the maintenance organization
PLAN 2.6
Practice Statement
Ensure plans are feasible by reconciling available and estimated resources.
Value
Increases likelihood that the objectives will be achieved by ensuring that needed resources are
available and committed to throughout the project.
Overcommitted resources can be reconciled by:
• Resource leveling the schedule
• Modifying or deferring requirements
• Negotiating more resources
• Finding ways to increase productivity
• Modifying or negotiating the scope of work involved, such as phased delivery
• Outsourcing
• Adjusting the personnel skill mix
• Revising all plans that affect the project or its schedules
• Identifying tools, techniques, and methods that could reduce time or cost
• Implementing incremental delivery
• Renegotiating stakeholder commitments
300
Manage individual project assignments to balance committed work among individuals and
projects:
• Evaluate individual workloads periodically to ensure they are balanced. Adjust individual
commitments as needed to improve balance and avoid over commitment.
• When individuals’ work is nearing completion, seek opportunities to apply their effort to
other business activities.
• Ensure the manager of an individual committed to work on several projects:
o Ensures the combined commitments do not result in over commitment
o Coordinates expectations for timing of work and results
o Resolves conflicts among project commitments
Example Activities
Perform resource leveling to adjust scheduling of Resource leveling balances the demand for
tasks and resources. resources with their availability.
Ensure commitments are supported by adequate
personnel or other required resources.
Negotiate commitments with affected stakeholders.

Revised plan and commitments
Context Specific
Supplier Management
While selecting a supplier and negotiating the supplier agreement, the acquirer reconciles
overall work and resource levels based on supplier proposals. After completing the supplier
agreement, the acquirer incorporates the supplier’s plans at an appropriate level of detail to
support plan alignment. For example, an acquirer can incorporate major supplier milestones,
deliverables, and reviews.
The resource plan should plan for personnel with the appropriate training and experience to
evaluate supplier proposals and participate in negotiations with suppliers. The resource plan
identifies the work resources expected from the supplier, including critical facilities or
equipment needed. Revise the resource plan based on the supplier agreement or changes in
environment conditions.
301
PLAN 2.7
Practice Statement
Develop the project plan, ensure consistency among its elements, and keep it updated.
Value
A consistent project plan helps to ensure efficient and effective communication and
achievement of objectives.
A plan addresses the planning and management of work activities collectively. A plan is more
than just a list of scheduled activities and tasks. It includes an approach for how the work is to
be performed and managed. Developing and using a project plan includes these iterative
activities:
• Identifying required tasks, including the activities and their interdependencies to be
used for tracking and managing the project
• Using estimates to:
o Develop a budget and schedule
o Determine the resources required
• Determining the tasks and their interrelationships
• Assigning roles and responsibilities for performing the tasks
• Identifying realistic performance data and objectives:
o Determining if objectives can be achieved as the project progresses
o Evaluating alternative objectives when the objectives cannot be met
• Identifying and analyzing risks or opportunities
• Determining information and data management needs and how they will be addressed
• Identifying and interacting with affected stakeholders to adequately address technical
and support activities in project plans
• Negotiating and obtaining commitment to the project plan
The project plan can include multiple plans. The plan generated for the project defines all
aspects of the effort, tying together the following in a logical manner:
• Tasks
• Budgets and schedules
• Milestones
• Information management and governance
• Risks
302
• Resources and skills

• Stakeholder roles and involvement
• Infrastructure
• Improvement and sustainment activities
• Other plans, such as:
o Configuration management or release plan
o Individual work plans
o Quality plan
o Measurement and data management plan
o Risk or opportunity management plan
o Supplier management plan
A plan provides the basis for:
• Monitoring and managing project performance
• Taking timely corrective actions to ensure the objectives will be met
• Re-planning when needed
Example Activities
Record the project plan.
Review the project plan with affected Ensure that the project plan describes a realistic approach for
stakeholders. meeting the needs, expectations, and constraints of affected
stakeholders and helps ensure that these affected
stakeholders will fulfill their roles.
Revise the project plan as necessary. Planning is an iterative activity.

Overall project plan A project plan may be composed of multiple plans (which may be
separate or combined into one or more documents) such as:
• Staffing plans
• Stakeholder involvement plans
• Performance improvement and sustainment plans
• Measurement and analysis plans
• Monitoring and control plans
• Solicitation plans
• Risk and opportunity management plans
• Transition plans
• Quality assurance plans
• Configuration management plans
303
PLAN 2.8
Practice Statement
Review plans and obtain commitments from affected stakeholders.
Value
Rework is reduced and the likelihood of achieving objectives is increased through a consistent
understanding and commitment to the plan.
This section left blank for future content
All plans that affect the project should be reviewed to obtain a common understanding of the
scope, objectives, roles, responsibilities, and relationships. Ensure that individuals or groups
making a commitment are confident that the project can be performed within cost, schedule,
and performance constraints.
Example Activities
Ensure individuals are involved in Review the decisions, agreements, and related information
reviewing the work they are responsible needed to understand requirements and plans necessary for
for and the inputs that initiate the work. accomplishing the work.
Record commitments. • A commitment is a pact that is freely assumed, visible,
and expected to be kept by all involved
• Ensure individuals and workgroups make commitments
for work they will be accountable for performing
• Commitments can be internal and external
• Record commitments to ensure a consistent mutual
understanding and for project tracking and maintenance.
Provisional commitments should include a description of
risks associated with the relationship.
Review and approve project • Work with the appropriate levels of management as
commitments. defined by the process
• The plan for stakeholder interaction should identify all
parties from whom commitment should be obtained

Example Work
Further Explanation
Products
Results of plan Reviews will help identify issues that lead to misunderstandings or may prevent
reviews objectives from being met. Review results may include:
• List of issues discovered during review
• List of changes that will be made
• Reason for plan changes
304
Example Work
Further Explanation
Products
Recorded Includes decisions and agreement to requirements, project plans, and their
commitments related elements.
Context Specific
Development
Development activities in preparation for production can be included in the hardware

development plan or defined in a separate production plan.
Examples of plans that have been used by large organizations include:
• Integrated Master Plan – an event driven plan that records significant accomplishments
with pass/fail criteria for both business and technical elements of the project and that
ties each accomplishment to a key project event.
• Integrated Master Schedule – an integrated and networked multi-layered schedule of
project tasks required to complete the work recorded in a related Integrated Master
Plan.
• Systems Engineering Management Plan – a plan that details the integrated technical
effort across the project.
• Systems Engineering Master Schedule – an event-based schedule that contains a
compilation of key technical accomplishments, each with measurable criteria, requiring
successful completion to pass identified events.
• Systems Engineering Detailed Schedule – a detailed, time dependent, task-oriented
schedule that associates dates and milestones with the Systems Engineering Master
Schedule.
305
Level 3
PLAN 3.1
Practice Statement
Use the organization’s set of standard processes and tailoring guidelines to develop, keep
updated, and follow the project process.
Value
Establishing the project process ensures the efficient and effective achievement of the
objectives.
Select and tailor or modify processes from the organization’s standard set of processes to build
a process to fit the specific needs of the project. The project process is tailored from the
organizational set of standard processes in accordance with organizational tailoring guidelines,
and:
• Includes a process description that is kept up-to-date
• Contributes to organizational assets
A project’s process is based on:
• Stakeholder requirements
• Goals and objectives
• Work product and task characteristics
• Impacts or requirements of the lifecycle
• Support activities
• Commitments
• Organizational process needs and objectives
• The organization’s set of standard processes and tailoring guidelines
• Domain
• The operational environment
• The business environment
• Stakeholder availability
• Experience of the people
• Project constraints
306
When the organization's standard set of processes change, there may be changes in the
project’s processes.
Example Activities
Select standard processes from the Collectively, these comprise the project process
organization’s set of standard
processes that best fit the needs of the
project.
Modify the organization’s set of
standard processes and other
organizational process assets according
to tailoring guidelines to produce the
project’s process.
Use other artifacts from the Other artifacts can include:
organization’s process asset library as • Estimating models
appropriate. • Lessons learned documents
• Templates
• Example documents
Record the project process. The project process covers the activities for the work and
interfaces or connections to affected stakeholders.
Review the project process. Record and use review results, inputs, and issues of the
project processes to identify potential impacts.
Revise the project process as As the project progresses, revise the description of the
necessary. project process to better meet project requirements and the
organization’s process needs and objectives.

The project process Describe how the organizational processes are implemented
for this specific project, including any unique, more detailed,
or additional processes or procedures that are needed and
allowed by the organizational tailoring guidelines.

Context Specific
Services
The description of the defined process should be based on services that the project delivers,
including both tailored standard services and unique services, and the service delivery
environment.
307
Organizations that define standard services may have individual systems that enable the
delivery of those standard services. Any processes that are components of service system(s)
within an organization are good candidates to consider when defining the standard processes
for delivering services.
Supplier Management
The supplier agreement should identify the key activities to deliver a solution that meets
requirements. The acquirer may require the supplier to align selected supplier processes with
the acquirer’s defined process to achieve the project goals.
The acquirer should align its defined process with the acquisition strategy. For example,
whether the acquisition strategy is to introduce new technology or to consolidate existing
solutions affects the acquirer’s defined process.
Supplier deliverables may include:
• Common defined processes
• Requirements tools shared by both acquirer and supplier
• Test tools and facilities shared by both acquirer and supplier
PLAN 3.2
Practice Statement
Develop a plan and keep it updated, using the project process, the organization’s process
assets, and the measurement repository.
Value
Using proven organizational assets for planning the project increases the likelihood that the
objectives will be met.
This section left blank for future content
Addresses organizational learning and enhances performance improvement by providing proven
assets to projects, which gives them the best chance for success.
Developing a project plan and keeping it updated should address additional planning activities
such as:
• Incorporating the project process
308
• Coordinating with affected stakeholders

• Using organizational process assets
• Incorporating plans for peer reviews
• Establishing objective entry and exit criteria for tasks
Examples of data contained in the organization’s measurement repository which can be used for
planning include:
• Size
• Effort
• Cost
• Schedule
• Staffing
• Response time
• Supplier performance
• Defects or issues
Example Activities
Use the tasks and work products of the
project process as a basis for
estimating and planning project
activities.
Use the organization’s measurement Estimates and supporting information typically include:
repository to estimate the work. • Validated historical data from this project or similar
projects
• Similarities and differences between the current project
and the work represented by the historical data
• Reasoning, assumptions, and rationale used to select
historical data
Integrate or develop plans. Other plans that affect the project plan can include:
• Staffing plans
• Training plans
• Stakeholder involvement plans
• Performance improvement and sustainment plans
• Measurement and analysis plans
• Monitoring and control plans
• Solicitation plans
• Agreement management plans
• Risk mitigation plans
• Transition plans
• Quality assurance plans
• Configuration management plans
• Verification and validation plans
• Peer review plans
309

Incorporate the definitions of measures Measures may include the:
and measurement activities. • Organization’s common set of measures
• Additional project and product specific measures
Establish objective entry and exit Entry and exit criteria make it clear when people are needed
criteria for tasks and activities. and when they are to start and complete their tasks.
Identify how conflicts will be resolved Identify resolution approaches and mechanisms for
that arise among affected addressing and resolving conflicts, including any agreed to
stakeholders. escalation procedures.

Revised project estimates Estimates that are based upon organizational experience
with other similar projects help to more accurately and
effectively accomplish work.
Project plans
Integrated plans Describe how plans interact and are integrated with each
other, including the dependencies, sequences, inputs and
outputs of the plans and tasks and how they relate to each
other.

Estimating (EST)
Context Specific
Development
Examples of development-specific parameters that are considered for similarities and

differences include:
• Design and development approaches
Examples of development-specific product and project interface risks include:
• Incomplete interface descriptions
• Unavailability of commercial off-the-shelf (COTS) components
An additional development-specific example of scheduling factors includes:
• Integration and test issues
310
Development activities in preparation for production can be included:

• in a software or hardware development plan
• in a system engineering management plan
• in a separate production plan
Services
The work plan should include service delivery and, when needed, service system development
and service system transition.
Examples of the types of service data contained in the organization’s measurement repository
include:
• Service capacity
• Number of service requests received, closed, cancelled, or in progress
• Number of service requests that missed their service level agreement
• Standard services from the catalog that are in high demand
• Average service request completion time
• Average cost consumed by service request
Plans that affect the work plan include:
• Capacity and availability management strategy
• Service continuity plan
• Incident management approach
• Risk and opportunity management approach
When developing a plan for the project, it is important to develop, keep updated, and follow a
strategy for capacity and availability management for critical services. This will help ensure the
right resources will be available to meet the requirements when needed and that the
organization can meet commitments to customers within agreed limits.
A capacity and availability management strategy is based on requirements, failure and incident
trend analysis, current resource use, and service system performance. Strategy should consider
the minimum, maximum, and average use of resources over the short, medium, and long term.
It may be appropriate for some projects to identify, plan for, and manage the availability of
resources to respond to sudden, unexpected increases in demand. Sometimes, the
management of the obsolescence of certain resources and offerings factor into the strategy for
capacity and availability management.
311
Service representations can help to determine resources and aspects to measure, monitor,
analyze, and manage. However, solution design documents may not be available or may not
accurately and completely reflect all aspects of the live environment that affect capacity and
availability. It is important to monitor and analyze actual capacity and availability data.
Requirements strategies, monitoring, and information from day-to-day service delivery, product
development, or acquisition can assist with these determinations.
The capacity and availability management strategy can reflect limits and constraints, e.g.,
limited customer funding, the customer’s acceptance of certain risks related to capacity and
availability.
The provider must formulate a strategy that best meets requirements, even if they cannot
influence or control demand and resource adjustments. This strategy can be more sophisticated
in situations where the provider can influence or control demand and resource adjustments.
Example activities for developing a capacity and availability management strategy include:
• Recording actual resource use, performance, and availability data
• Estimating future resource and capacity and availability requirements
• Developing a capacity and availability strategy that meets requirements, meets the
demand for resources and services, products, or acquisitions, and addresses how the
organization provides, uses, and allocates resources
• If appropriate, including an availability testing schedule, a maintenance strategy, and an
outage schedule
• Recording costs and benefits of the strategy and any assumptions
• As necessary, revising the strategy on an event-driven basis
PLAN 3.3
Practice Statement
Identify and negotiate critical dependencies.
Value
Paying close attention to critical dependencies reduces risk and increases the likelihood the
project will be completed on time, within budget, and meeting quality objectives.
312

Example Activities
Identify each critical dependency. Record dependencies, relationships, and how they affect the
plan.
Integrate schedules An integrated master schedule (IMS) can be used to identify
critical dependencies between work groups and functions.
Review and negotiate dependencies Communicate new or existing dependencies and changes with
with affected stakeholders. affected stakeholders to ensure that they can perform their
work.
Record commitments to address
each critical dependency.

Critical dependencies May include:
• Description of the critical dependencies
• Commitments made during negotiations
• Risks associated with the dependency
PLAN 3.4
Practice Statement
Plan for the project environment and keep it updated based on the organization’s standards.
Value
Ensures that the resources needed to complete the work are readily available to maximize
productivity.
Describe the project environment to address any unique or critical aspects that may affect the
project being performed.
An appropriate project environment is comprised of an infrastructure of facilities, tools, and
equipment that people need to perform their jobs effectively in support of business and project
objectives. Keep the project environment updated at a level required by the organizational
project environment standards. Develop or acquire the project environment or its components.
313
Example Activities
Analyze project and plan for The critical aspects of the project environment are requirements
resources, facilities, and driven. Explore project environment functionality and quality
environment characteristics with the same rigor as any other project planning
activity. Examples of the resources to be considered include:
• Considerations for the project environment
o Cultural issues
o Visibility
o Voice communication
o Comfortable furniture
o Airborne particulates
o Light for performing work
o Isolation and noise protection
o Space to perform group work activities
o Meeting space
o Support areas
o Laboratories
• Specialized characteristics of workspaces
o Safety
o Security
o Air conditioning
o Tools
o Training
o Remote locations
o Telecommuting
• Storage
• Project equipment
o Computers or work stations
o Communications technologies, e.g., telephones, fax
machines, e-mail, and networks
o Office equipment
o Printing and reproduction equipment
• Supplies
• Application software
• Documentation
Assign a responsible individual to Examples of actions include:
plan to acquire resources, • Preparing budget requests
facilities, and the environment • Developing cost-benefit justifications
needed to perform assigned • Consulting with subject matter experts
work. • Submitting purchase orders
• Negotiating with those responsible for managing building or
computing facilities, distributing equipment or supplies, or other
project environment-related resources
Develop a contingency plan if the
resources, facilities, and
environment cannot be obtained.
314

Plan for support personnel needs. May include:
• Business or administrative
• Computer support personnel
• Technical writing and documentation
• Laboratory technicians
Ensure individuals and groups May include:
participate in decisions • Arrangement of project facilities
concerning resources, facilities, • Alterations or improvements to the project environment
and environment. • Resources needed to perform their project

Project resources, facilities, and May be included as part of the overall project plan or may be
environment plan separate, e.g., for large or complex projects or environments.
Equipment and tools for the
project
Health and safety considerations,
including any regulatory or legal
requirements
Installation, operation, and
maintenance manuals for the
project environment
User surveys and results
Facilities, resources, and
maintenance records for the
project
Support services needed for the
project environment
Context Specific
Development
The project environment might encompass environments for product development, integration,
verification, and validation, or they might be separate environments.
Development-specific examples of equipment and tools include:
• Design tools
• Configuration management tools
• Evaluation tools
315
• Integration tools
• Automated test tools
Components in the development environment include software, databases, hardware, tools, test
equipment, and appropriate documentation. Qualification of software includes appropriate
certifications. Hardware and test equipment qualification includes calibration and adjustment
records and traceability to calibration standards.
Examples of actions to improve the development environment include:
• Adding new tools
• Acquiring additional networks, equipment, training, and support
Services
Verification and validation of the service system can include both initial and ongoing evaluation
of the environment in which the service provider delivers the service.
Components in the services work environment include those necessary to support service
delivery, software, databases, hardware, tools, test equipment, and appropriate documentation.
Qualification of a service delivery environment includes audits of the environment and its
components for compliance with safety requirements and regulations. Software qualification
includes appropriate certifications. Hardware and test equipment qualification includes
calibration, records and traceability to calibration standards.
Examples of actions to take to improve the services work environment include:
• Adding new equipment and tools
• Acquiring additional networks, equipment, training, and support
Examples of equipment and tools include:
• Resource management tools for service delivery
• Incident and request management tools
Supplier Management
Ensure that the supplier’s and acquirer’s projects are compatible to enable the efficient and
effective transfer of work products and solutions.
Define the project environment in the plan, and include any environments required throughout
the project lifecycle.
Example environment types include:
• Acquirer or supplier facilities
• Independent Verification and Validation (IV&V)
316
• Configuration Management
• Testing
• Infrastructure hosting
• Information repositories
• Field sites
• Classified facilities
317
Level 4
PLAN 4.1
Practice Statement
Use statistical and other quantitative techniques to develop and keep the project processes
updated to enable achievement of the quality and process performance objectives.
Value
Increases the likelihood that the processes of the project will enable achievement of consistent
performance and quality.
Managing the progress towards achieving quality and process performance objectives should be
an integral part of how the project is planned and managed.
Ensure that projects:
• Identify the processes required to accomplish business activities.
• Identify conditions that may affect performance of the processes.
• Identify relevant process performance baselines and models for the selected processes.
Projects may have historical process performance baselines and models that are more
accurate or relevant than organizational baselines.
• Evaluate the planned performance of the selected processes to determine if they are
capable of achieving the measurable performance objectives.
• When planned performance is not being achieved, negotiate adjustments in measurable
performance objectives and the associated processes. This may involve identifying and
developing new processes or subprocesses.
Example Activities
Develop the criteria to use in Criteria can be based on:
evaluating process alternatives for the • Quality and process performance objectives
project. • Availability of process performance data and the relevance
of the data to evaluating an alternative
• Previously recorded process performance baselines and
models that can be used in evaluating an alternative
• Lifecycle models
• Stakeholder requirements
• Laws and regulations
Identify or develop alternative May include:
processes for doing the work and • Analyzing organizational process performance baselines
meeting objectives. and models to identify candidate processes
318

• Identifying processes from the organization’s set of
standard processes as well as tailored processes in the
process asset library
• Identifying processes from external sources, e.g., other
organizations, professional conferences, academic
research
• Adjusting the level or depth of intensity with which the
processes are applied and can involve the:
o Number, type, and date of peer reviews to be held
o Amount of effort or calendar time devoted to particular
tasks
o Number and selection of people involved
o Skill level requirements for performing specific tasks
o Selective application of specialized construction or
verification techniques
o Reuse decisions and associated risk mitigation strategies
o Sample size for peer reviews
Analyze and evaluate alternative Analyze the relative strengths and weaknesses of
processes against recorded evaluation alternatives. This analysis can be supported by aligning the
criteria. organization’s process performance models with process
performance data.
Perform additional modeling activities if existing process
performance models cannot address significant relationships
among the alternative processes under consideration and
there is high risk of not achieving objectives.
Use historical data and process performance baselines and
models to assist in evaluating alternatives against the
criteria. These evaluations can include a sensitivity analysis,
particularly in high risk situations.
Select the alternative process that best If needed, repeat these activities several times until
meets the criteria. confident that the best available alternative has been
identified.
Evaluate the risk of not achieving the If the risk cannot be avoided or mitigated, it may be
project’s quality and process necessary to revise the project’s quality and process
performance objectives. performance objectives.

Criteria used to evaluate alternatives
for the project
Alternative processes It may be possible to develop more than one candidate
defined process for the project. In this case, select the one
that best meets the evaluations criteria.
Selected defined project process
319

Risk assessment of not achieving the Risk handling plan and action to be identified. Decision
project’s quality and process analysis may be used to identify alternate risk mitigation
performance objectives practices.

320
Intent
Develop and keep updated the process assets necessary to perform the work.
Value
Provides a capability to understand and repeat successful performance.
Practice Summary
Level 1
PAD 1.1 Develop process assets to perform the work.
Level 2
PAD 2.1 Determine what process assets will be needed to perform the work.
PAD 2.2 Develop, buy, or reuse process assets.
PAD 2.3 Make processes and assets available.
Level 3
PAD 3.1 Develop, keep updated, and follow a strategy for building and updating
process assets.
PAD 3.2 Develop, record, and keep updated a process architecture that describes
the structure of the organization’s processes and process assets.
PAD 3.3 Develop, keep updated, and make processes and assets available for use.
PAD 3.4 Develop, keep updated, and use tailoring criteria and guidelines for the
set of standard processes and assets.
PAD 3.5 Develop, keep updated, and make the organization’s process asset library
available for use.
PAD 3.6 Develop, keep updated, and make work environment standards available
for use.
PAD 3.7 Develop, keep updated, and make organizational measurement and
analysis standards available for use.
Organizational process assets enable:
321
• Consistent process execution across the organization

• Tailoring using the organizational guidelines
• Organizational learning and process improvement
• A basis for cumulative, long-term benefits to the organization
• Sharing best practices and lessons learned across the organization
Context Specific
Agile teams use process assets to perform their work. Figure PAD-1 shows where a team
might develop these assets in sprint 0 to prepare for the first development sprint. Collect
refinement suggestions in the sprint retrospective. Figure PAD-2 shows some example assets
in their template form.
The assets referenced in Process Asset Development extend beyond the typical ones of an agile
project. They include a measurement repository, tailoring guidelines, and work environment
standards.
Figure PAD-1: PAD in an Agile Cycle
322
Figure PAD-2: Typical Agile Assets
323
Level 1
PAD 1.1
Practice Statement
Develop process assets to perform the work.
Value
Improves consistency to increase likelihood of meeting objectives.
Recording work steps helps to avoid rework and ensure that team members know what needs
to be done.
Example Activities
Record work instructions.

Work instructions
Process descriptions
Templates
324
Level 2
PAD 2.1
Practice Statement
Determine what process assets will be needed to perform the work.
Value
Avoids waste by focusing resources only on the process assets needed to perform the work.
The context and scope of the work will help determine which process assets are needed.
Consider when process assets will be needed, especially for large projects. Review and revise
those needs if the context or scope changes.
Example Activities
Identify process assets needed for the
project.

Templates For example, templates may be provided for:
• Plans
• Estimates
• Technical documentation
• Meeting minutes
• Service level agreements
• Requests for proposals
• Contracts or agreements
Work Instructions Work instructions can include:
• Sequential checklists
• Standard Operating Procedures (SOPs)
• Processes
Tools
325
PAD 2.2
Practice Statement
Develop, buy, or reuse process assets.
Value
Helps to minimize costs, effort, and time needed for developing the assets.
Example Activities
Select which assets will be subject to a
build, buy, or reuse analysis.
Perform build, buy, or reuse analyses
to determine the best option of various
selected assets.
Record results of analyses.
Build, buy, or reuse the indicated
assets.

Build, buy, reuse analyses results
Process assets

PAD 2.3
Practice Statement
Make processes and assets available.
Value
Using existing process assets reduces cost and time needed for performing the work.
326

Ensure that team members know what assets are available and how to access them.
Identify and make assets available for use by other projects.
Example Activities
Make assets available for use by
projects.
Communicate the availability of assets
for use.

Process assets
327
Level 3
PAD 3.1
Practice Statement
Develop, keep updated, and follow a strategy for building and updating process assets.
Value
Provides a structure and direction for asset building that minimizes cost.
Example Activities
Develop a strategy for building and For example, include:
updating process assets. • Identification of the business objectives addressed and
their priority
• Methods for developing and updating assets
• Identification of roles and responsibilities for carrying out
the strategy
• Criteria for implementing action plans
• Reference to process architecture

Strategy for building and updating
process assets
PAD 3.2
Practice Statement
Develop, record, and keep updated a process architecture that describes the structure of the
organization’s processes and process assets.
Value
A robust process architecture ensures that processes add value.
328

The structure needs to accommodate:
• Processes
• Critical attributes of the process
o Inputs and outputs
o Sequence links
o Dependency links
o Connections
The process architecture defines the structures necessary to contain the processes, process
assets, and connections. The process architecture needs to be considered from two different
aspects:
• Structural Architecture
• Content Architecture
Both need to be addressed. Figure PAD-3 describes the differences between the two types.
329
Figure PAD-3: Structure and Content
The content architecture may independently vary over time because of changes to
organizational needs. Structural architectural will typically only change when there is a major
change to the organization, the process needs, or process approach.
Clearly specified processes interact efficiently resulting in less redundancy and fewer gaps,
therefore ensuring that every process adds value. A process architecture:
• Reduces risks
• Increases quality
• Improves time-to-market
• Increases customer satisfaction
• Facilitates achievement of business objectives
• Promotes understandings between work groups
• Helps clarify roles and responsibilities
330
• Improves coordination of efforts

• Reduces unnecessary activities
• Reduces missed activities
• Improves process flow by ensuring that all necessary inputs and outputs are defined
Example Activities
Identify process requirements. Process requirements describe the business needs that
processes will address.
Identify process architecture Process architecture objectives describe how and why the
objectives. process architecture will be used and the information that
the representation will provide.
Develop and record the format of the Process architecture is like solution architecture, except that
process architecture. the components are processes. Many of the same tools and
techniques used to design and record solution architectures
can be used to design and record the process architecture.
Different formats can be used at different levels and may
include:
• EITVOX
• IDEF
• Flow charts
• Workflow diagrams
• Process modeling tools
• Context models
• Value chain models
Develop, record, and keep updated the Ensure the process architecture can address all process
process architecture. types.
Review and update process Include representatives of each process type represented in
architecture with affected stakeholders. the process architecture to ensure:
• Necessary inputs, outputs, entry criteria, and exit criteria
are understood and complete
• Redundancies and missing processes are identified and
addressed
• Processes that do not add value are identified for revision
or elimination
Communicate and make process
architecture available.

Process requirements
Process architecture format
Process architecture
331

PAD 3.3
Practice Statement
Develop, keep updated, and make processes and assets available for use.
Value
Enables work to be done more efficiently and effectively, which leads to reduced cost and
waste.
Plan and implement actions that address improvements to the organization’s processes and
assets. Process action plans are detailed implementation plans that target improvements.
For effective implementation of improvements, ensure that support organizations and the
people who perform the process participate in process development, deployment, and
implementation.
Developing and updating processes may involve:
• Management steering committees that set strategies and oversee process improvement
activities
• Process groups that facilitate and manage process improvement activities
• Process action teams that define and implement process actions
• Process owners that manage deployment
Standard processes and assets can be:
• Defined at multiple levels in an organization
• Tailored for each of the organization’s business areas or functions
Each process covers a closely related set of activities. A fully defined process or asset has
enough detail that it can be consistently performed by trained and skilled people.
Tailoring can be done at the organizational, divisional, site, or functional level. Each level or
function of the organization can have a set of standard processes or assets which were tailored
from the organizational set of processes and assets. Some organizations may have only one
level of standard processes.
332
The organization’s set of standard processes contains process elements that may be
interconnected according to one or more process architectures that describe relationships
among process elements. The organization’s set of standard processes may include:
• Technical, management, administrative, support, and organizational processes
• Sequence, order, and interrelationships of the processes and their elements
• Proven and effective processes and assets
• Lessons learned
Affected stakeholders should also periodically update their defined processes and assets to
incorporate changes made to the organization’s set of standard processes. Update processes
and assets to reflect periodic revisions in the knowledge, skills, and process abilities.
Example Activities
Verify that the organization’s set of
standard processes and assets are
aligned with strategic process needs
and objectives.
Assign responsibilities for acquiring,
developing, and maintaining processes
and assets.
Review and decide if recommendations
resulting from process improvements
should be incorporated into the
organization’s processes and assets.
Develop organizational standards for May include:
processes and assets. • Standards for terminology and use
• Requirements for completeness, correctness, and other
quality attributes
• Semantic structure and organization
• Representation of content
• Format for storage and presentation
• Archiving and access methods
Record process action plans. Action planning may include:
• Recording the action plan
• Reviewing with affected stakeholders
• Revising as necessary
• Negotiating and recording commitments
Process action plans may include:
• Process improvement infrastructure
• Process improvement objectives
• Process improvements to be addressed
• Procedures for planning and tracking process actions
• Responsibility and authority for implementing process
actions
• Resources, schedules, and assignments for implementing
process actions
333

• Risks
Track progress and commitments Perform joint reviews with process action teams and
against process action plans. stakeholders to monitor the progress and results of process
actions.
Identify, record, and track to closure issues encountered
when implementing process action plans.
Establish process action teams to Process action teams typically include process owners and
implement actions. those who perform the process.
Build and record processes and assets. Building and recording processes and assets may include:
• Specifying the attributes of each process or asset
• Specifying relationships among processes or assets
Process attributes may include:
• Roles and responsibilities
• Applicable standards
• Process performance objectives
• Entry criteria
• Inputs
• Tasks
• Verification and Validation
• Outputs
• Exit criteria
• Connections
• Measures
Perform reviews on the organization’s
set of standard processes or assets.
Revise the organization’s set of These may need to be revised when:
standard processes and assets as • Improvements to the processes and assets are identified
necessary. • Causal analysis and resolution data indicate a process
change is needed
• Process improvement proposals are selected for
deployment across the organization
• The organization’s process needs and objectives are
updated
Make processes and assets available. These may be made available through a variety of media,
including:
• Documents and records
• Apps
• Websites
• Videos and training materials
• Scripts in automated tools
• Intranets and other electronic media

Action plans
334

Status and results of implementing
action plans
Organization’s set of standard
processes and assets
New processes or assets Examples may include:
• Decision aids
• Templates for solutions
• Guides and manuals

Peer Reviews (PR)
PAD 3.4
Practice Statement
Develop, keep updated, and use tailoring criteria and guidelines for the set of standard
processes and assets.
Value
Adapting a standard process to accommodate the unique needs of each project avoids
unnecessary work.
Consistency across the organization ensures that organizational standards, objectives, and
strategies are addressed, and process data and lessons learned can be shared.
Tailoring is a critical activity that allows controlled changes to the processes due to the specific
needs of a project or a part of the organization. Tailoring of processes should be constrained
and take into account business objectives or technical requirements. Tailoring guidelines may
allow additional flexibility when dealing with less critical processes or those that only indirectly
affect business objectives.
Balance tailoring flexibility with consistency of processes across the organization. Flexibility
helps address contextual variables such as:
• Domain
• Nature of the customer
• Cost, schedule, and quality tradeoffs
• Risks
335
• Technical difficulty of the work

• Experience of the people implementing the process
The amount of tailoring could also depend on the project’s lifecycle model, the use of suppliers,
and other factors.
Tailoring criteria and guidelines can allow for using a standard process “as is,” without tailoring.
Examples of reasons for tailoring include:
• Accommodating the process to a new solution
• Adapting the process to a new work environment
• Modifying the process description, so that it can be used within a given project
• Adding more detail to the process to address a unique solution or constraint
• Modifying or combining elements of a lifecycle model
• Modifying, replacing, or reordering process elements
Example Activities
Specify selection criteria and Examples of criteria and procedures include:
procedures for tailoring the • Criteria for selecting and tailoring lifecycle models from
organization’s set of standard the ones approved by the organization
processes. • Criteria for selecting process elements from the
• Procedures for adapting the organization’s common
measures to address information needs
Specify the standards used to record
defined processes.
Specify the procedures used to submit
and obtain approval of waivers from
the organization’s set of standard
processes.
Record, approve, and communicate Reviews of the tailoring guidelines may be used as a part of
tailoring guidelines for the the approval process.
processes.
Revise tailoring guidelines as
necessary.

Tailoring guidelines for the May include:
organization’s set of standard • Requirements that must be satisfied by defined processes,
processes e.g., the subset of organizational process assets that are
essential for any tailored process
• Options that can be exercised and criteria for selecting
among options
336

• Procedures that must be followed in performing and
recording process tailoring
Waivers or requests for process Waivers are not intended to be a means to opt out of
waivers following a process. A waiver may be used when:
• The standard process cannot be tailored to meet the
needs of the project
• A customer, legal, or regulatory constraint prevents the
process from being followed
• There is a new requirement that the standard process
currently cannot address

Peer Reviews (PR)
Context Specific
Services
Example Activities
Develop tailoring criteria as Record the fixed elements of standard services that will not
appropriate. change. Fixed elements may have allowable variation within
specified limits.
Examples of allowable variation:
• Pricing
• Hours of operation
• Geographical coverage
The service provider uses knowledge of variability in
customer needs to develop tailoring options.
The tailoring guidelines describe how to:
• Use standard services to guide the development of
individual services
• Use criteria to determine and select tailoring options
• Follow procedures in performing and recording tailoring
Tailoring criteria and procedures include:
• Selecting standard services from the services approved by
the organization
• Selecting service components from the service provider’s
service catalog
• Tailoring the selected services and service components to
satisfy requirements for delivery
All tailoring actions should be subject to required approvals.
Tailoring actions may include:
• Modifying a service level
337

• Combining components of different services
• Modifying, replacing, or reordering service components
Identify needs and expectations for If the service provider needs to develop and keep updated
service systems that deliver standard
multiple service systems to deliver its standard services, it
services.
can be helpful to develop core assets. The service provider
develops these at the organizational and project level for
developing and customizing such service systems, e.g., a
project may be for a specific customer-related service.
PAD 3.5
Practice Statement
Develop, keep updated, and make the organization’s process asset library available for use.
Value
Reduces the time and effort needed to organize, access, and update process assets.
The repository contains both process assets and related work products that are part of the
organization’s set of standard processes.
Example Activities
Design and implement the This includes the library structure and support environment.
organization’s process asset library.
Specify criteria for including assets in Assets are selected based primarily on their relationship to
the library. the organization’s set of standard processes.
Specify procedures for storing,
updating, and retrieving assets.
Enter selected assets into the library Assets include:
and catalog them for easy reference • Organizational policies
and retrieval. • Process descriptions
• Procedures, e.g., estimating procedure
• Plans
• Process aids, e.g., templates and checklists
• Work products resulting from performing the processes
• Lessons learned
338

Make assets available for use by
projects.
Periodically review the usefulness of Consider removing assets that are no longer used or viable.
the assets.

Design of the organization’s process
asset library
Organization’s process asset library
Process-related work products in the
process asset library
PAD 3.6
Practice Statement
Develop, keep updated, and make work environment standards available for use.
Value
Increases productivity and consistency across projects through a specified and established work
environment.
Work environment standards allow the organization and projects to benefit from common tools,
training, maintenance, and cost savings. Work environment standards address the needs of all
stakeholders and consider productivity, availability, security, and workplace health, safety, and
ergonomic factors.
Work environment standards help to ensure that the:
• Improvements made to the work environment improve work performance
• Organization’s work environment supports the development and performance of
empowered workgroups
• Work environment supports individuals or projects using the standard processes
Examples of work environment standards include:
• Requirements for the operation, safety, and security of the work environment
• Workstation hardware and software requirements
339
• Standard application software and tailoring guidelines

• Standard production and calibration equipment
• Licenses, security passwords, and IDs
• Criteria for the use and approval of waivers
• Criteria for tailoring the work environment to meet needs
Example Activities
Evaluate commercially available work Choose standards to evaluate based on the organization’s
environment standards. needs.
Adopt, develop, or tailor work
environment standards to fill gaps
based on the organization’s process
needs and objectives.
Periodically analyze the work
environment to identify changes or
resources that could improve work
performance.
Prioritize potential improvements to the Complying with laws and regulations may cause a higher
work environment. priority to be placed on some improvements. Seek guidance
from human resources, facilities, legal, or other appropriate
professionals in complying with such laws and regulations.
Identify resources that could improve Examples of work environment resources that may enhance
performance. performance include:
• Facilities or public spaces, such as work areas and
conference rooms
• Offices and spaces close that allow co-location and that
foster collaboration
• Collaborative tools, applications, or other resources
• Enhanced communication capabilities
Ensure projects have the authority to
organize and tailor their work
environments to best support their
business activities.
Review work environments with
projects.

Work environment standards
Waivers or requests for work Waivers are not intended to be a means to opt out of
environment waivers adhering to a work environment standard. A waiver may be
used when:
• The standard work environment cannot be tailored to
meet the needs of the project
340

standard work environment from being applied
• There is a new requirement that the standard work
environment currently cannot or does not address
PAD 3.7
Practice Statement
Develop, keep updated, and make organizational measurement and analysis standards available
for use.
Value
Supports consistent use of measurements and related analysis for better decision making.
Evaluate objectives and requirements to define the organization’s measurement and analysis
standards. The organization may have multiple measurement and analysis standards if work is
diverse and requires different approaches. Tailoring decisions may affect how measurement and
analysis standards are developed and used. Align these measurement and analysis standards
with how measurements will be used and how they meet business objectives.
Example Activities
Specify organizational standards for Different standards may be needed for different types of
measurement and analysis. data or analysis techniques.
Specify tailoring guidelines for applying Includes criteria for when a waiver is allowed or approved.
measurement standards to individual
projects.

Organizational measurement and
analysis standards
Waivers or requests for measurement Waivers are not intended to be a means to opt out of
and analysis waivers adhering to a measurement and analysis standard. A waiver
may be used when:
• The standard cannot be tailored to meet the needs of the
project
341

standard from being applied
• There is a new requirement that the standard currently
cannot or does not address
342
Intent
Manages and implements the continuous improvement of processes and infrastructure to:
• Support accomplishing business objectives
• Identify and implement the most beneficial process improvements
• Make the results of process improvement visible, accessible, and sustainable
Value
Ensures that processes, infrastructure, and their improvement contribute to successfully
meeting business objectives.
Practice Summary
Level 1
PCM 1.1 Develop a support structure to provide process guidance, identify and fix
process problems, and continuously improve processes.
PCM 1.2 Appraise the current process implementation and identify strengths and
weaknesses.
PCM 1.3 Address improvement opportunities or process issues.
Level 2
PCM 2.1 Identify improvements to the processes and process assets.
PCM 2.2 Develop, keep updated, and follow plans for implementing selected
process improvements.
Level 3
PCM 3.1 Develop, keep updated, and use process improvement objectives
traceable to the business objectives.
PCM 3.2 Identify processes that are the largest contributors to meeting business
objectives.
PCM 3.3 Explore and evaluate potential new processes, techniques, methods, and
tools to identify improvement opportunities.
343
PCM 3.4 Provide support for implementing, deploying, and sustaining process
improvements.
PCM 3.5 Deploy organizational standard processes and process assets.
PCM 3.6 Evaluate the effectiveness of deployed improvements in achieving
process improvement objectives.
Level 4
PCM 4.1 Use statistical and other quantitative techniques to validate selected
performance improvements against proposed improvement expectations,
business objectives, or quality and process performance objectives.
Process improvement focuses on the needs of the business to:
• Increase value for customers
• Align with business objectives
• Make business activities more efficient and effective
• Make the business more profitable
• Stay ahead of competition
• Increase employee satisfaction
Improvements to a process will often improve performance, but that is not the only reason to
improve processes. For example, a strategic or regulatory change may drive an improvement or
change to the process. It is also important to refine the improvement approach so that the
processes are more useful to the organization.
Process management activities address the improvement of specific processes based on
proposals from various sources which may include:
• Process evaluations including appraisals and quality assurance activities
• Feedback from users
• Measurement analysis results
• Performance results
Improvements that show demonstrable benefits help develop and support a culture that strives
for ongoing improvement. A continuous improvement culture is essential to sustaining best
practices and avoiding falling back into bad habits. Improving processes also increases
employee satisfaction and retention rates by building an environment where people can be
productive.
344
Context Specific
Agile teams collect retrospective data at the end of each sprint that provides a rich source of
improvement ideas. Some agile teams form a community of practice where individuals with a
need for similar improvements can share experiences. Typically, retrospective sessions are
focused on ad-hoc topics and improvements at a team level. Process management adds the
systematic collection, analysis, and coordination of these improvements across the organization.
The organization will benefit by learning from each agile team.
Figure PCM-1: PCM in an Agile Cycle
345
Table PCM-1: Retrospective Information
Figure PCM-1 shows where process management activities are performed in an agile project.
Table PCM-1 shows typical retrospective data.
Process management activities can supplement the typical agile team to aid organizational
learning. For example, agile teams collect data, but there is not necessarily a support structure
to manage and use that data. The retrospective session does not typically or systematically
assess each process. The adoption of process management practices will produce more robust
and sustainable organizational improvements.
346
Level 1
PCM 1.1
Practice Statement
Develop a support structure to provide process guidance, identify and fix process problems, and
continuously improve processes.
Value
A process improvement support structure helps to reduce effort, cycle time, costs, defects, and
waste, and increase performance.
The support structure enables consistent process implementation across the organization and
provides a basis for cumulative, long-term benefits to the organization. It typically:
• Helps establish processes that make the work easier, more efficient, and less defect-
prone
• Provides process guidance, such as process policies or other organizational directives
• Establishes responsibility for facilitating and managing the organization’s process
improvement activities, including coordinating the participation of others
• Provides the long-term commitment and resources required for improvement
• Enables effective and timely deployment of improvements
Senior management is responsible for establishing, communicating, and enforcing guiding
principles, direction, and expectations. Senior management must:
• Actively support these efforts
• Set the tone for improvement
• Motivate continuous improvement
• Hold people accountable for improving the process
Example Activities
Identify and apply a structure for May include:
supporting process related activities • Organizational expectations and direction
and keep it updated. • Guidance for the process improvement
Assign responsibilities and keep them Typically includes:
updated for coordinating process • Defined roles and responsibilities
related activities. • Following the support structure
347

Process support structure A process support structure typically involves:
• How the structure will be set up and updated
• Funding and support
• Training
• Resources needed to sustain the structure
• Roles and responsibilities that may include:
o Management steering committee that sets strategies
and oversees process improvement activities
o Process group that facilitates and manages process
improvement activities
o Process action teams that define and implement process
actions
o Process owners that manage deployment
o Practitioners that perform the process and provide
feedback
Related Process Areas

Governance (GOV)
PCM 1.2
Practice Statement
Appraise the current process implementation and identify strengths and weaknesses.
Value
Provides a systematic and realistic way to identify the most important opportunities for
improvements.
Clearly define and communicate the reasons for performing an appraisal. These reasons can
include:
• Identifying strengths and weaknesses
• Providing a realistic and objective insight into improvement opportunities
• Determining progress towards achieving improvement objectives
• Benchmarking
The appraisal can be performed against:
348
• A reference model, e.g., CMMI, ISO, or other standards relevant to the organization or
industry
• The organization’s processes
The purpose of an appraisal is to identify:
• Well performed activities
• Missing or gaps in processes
• Other business reasons and issues that could stimulate and guide successful
improvement efforts, such as:
o Regulatory requirements
o Recurring problems
The primary focus of an appraisal is to compare the recorded and performed processes against
the reference model. It is a quality assurance function to focus on the practiced processes
versus the recorded processes.
Appraisal results should include enough detail so that they can be used for improvements. The
acceptance gained with an appraisal can be significantly reduced if improvement actions are not
implemented.
Appraisals follow a process, are performed by qualified personnel, and may include:
• A formal assessment or evaluation
• A gap analysis
• A review
• A benchmarking activity
• Other methods
Example Activities
Obtain sponsorship and support for the
appraisal from senior management.
Define the scope of the appraisal. Scope includes:
• Organizational scope
• Process scope
• Model scope
Select or define the criteria and Criteria may include:
method for the appraisal. • Rigor
• Sampling
• Ratings
• Re-appraisal triggers
The appraisal method may include:
• Gap analysis
• Benchmarking
• Review
349

Plan and schedule the appraisal.
Perform the appraisal.
Record and communicate the appraisal
findings.

Appraisal plan and schedule May include the:
• Objectives
• Scope
• Method
• Criteria
• Resources
Appraisal findings Typically includes:
• Goals of the appraisal
• Results including strengths and weaknesses
PCM 1.3
Practice Statement
Address improvement opportunities or process issues.
Value
Reduces costs by increasing efficiency and effectiveness of projects.
Assign responsibility to address improvement opportunities and process issues. Process issues
may be addressed by improvement actions at various organizational levels.
Resolving issues is key to developing process acceptance and leads to further improvements.
Example Activities
Assign relevant personnel to address
the improvement opportunities and
process issues.
350

Identify and record the action items to
address improvement opportunities
and process issues.
Address the opportunities and issues
and communicate the results.

Action items Include:
• Actions to address identified improvement opportunities
and process issues
• Responsible people
• Resources needed to complete actions
351
Level 2
PCM 2.1
Practice Statement
Identify improvements to the processes and process assets.
Value
Maximizes return on investment by focusing resources on the most critical business needs and
objectives.
During process implementation and execution, identify opportunities and issues for
improvement. These can come from:
• Individuals
• Improvement proposals
• Lessons learned
• Results from a process appraisal
• Value stream analyses
• Causal analysis
• Measurements
• Quality evaluations
Systematically analyze, prioritize, and record improvement suggestions. This analysis includes:
• Circumstances
• Sources
• Side effects
• Validity
• Benefits
• Effort
• Time to implement
352
Ensure that the analysis and evaluation are performed in a timely manner and that
improvements are selected based on their expected value and impact. Objectively decide which
improvements to select. It is generally not possible to implement all suggested improvements
as it may be either too expensive or take too long. On the other hand, just addressing “low
hanging fruit” may lead to minor changes or no changes at all. The better way is to determine
criteria that helps select and deploy improvements with the highest business impact.
Example Activities
Identify issues and opportunities.
Group and analyze proposed May include:
improvements. • Cost benefit
• Return on investment
• Expected performance improvement
• Prioritization
• Barriers or risks
Record and keep updated criteria for May include:
selecting improvements. • Those required by law, regulations, or standards (now or
in the future)
• Supporting process improvement objectives
• Avoiding waste
• Ability to implement and execute
Select proposed improvements for
implementation, deployment, and
execution.
Review selections with affected
stakeholders.
Record proposed improvements and May include the:
communicate results. • Value and rationale of each action
• Improvement based on the evaluation of criteria
• Objectives
• Constraints
• Target users
• Risks
• Estimated cost and schedule to implement
• Expected results

Proposed improvement list May include:
• Proposed improvements
• Reference to source
• Assignment to processes
• Risks and probability to resolve
• Priority and business impact
• Rationale as to why the proposals or a group of proposals
is listed
• Category of improvement
353

• How to implement the proposed improvement
Recorded selection criteria
List of selected improvements for Refer to above proposed improvement list.
implementation, deployment, and
execution
PCM 2.2
Practice Statement
Develop, keep updated, and follow plans for implementing selected process improvements.
Value
Plans enable more efficient and effective improvement efforts to meet business objectives.
Ensure the support structure for process improvement is addressed.
Manage the implementation of process improvements like a project.
Plans may include the full lifecycle of an improvement effort including:
• Estimating and planning
• Implementing or updating processes
• Piloting
• Analyzing expected and actual results
• Identifying risks or issues
• Identifying and involving stakeholders
• Deploying
• Conducting post-deployment evaluation
• Collecting feedback and lessons learned
• Monitoring progress
For larger efforts, consider an iterative or incremental approach instead of a one-time effort.
For example, ensure deployable results are available as soon as possible to receive rapid
feedback.
354
Example Activities
Select performance improvements to Select improvements to be deployed based on their priority,
be deployed. resource availability, and improvement proposal evaluation
and validation activity results.
Selection process results can include the:
• Selection criteria for proposed improvements
• Characteristics of the target work
• Disposition of each improvement proposal
• Rationale for the disposition of each improvement
proposal
Develop the plan based on the This should include identifying:
identified process improvements and • Tasks
review with stakeholders. • Risks or opportunities
• Performance criteria
Ensure that the deployment is
announced, well-coordinated, and
supported.
Manage progress, review with This should include monitoring:
stakeholders, and update plans as • Tasks
needed. • Risks or opportunities
• Performance criteria
Develop or update process assets.
Pilot the identified process
improvements.
Deploy the improvements. Use results from pilots to update the deployment plans as
needed.
Analyze and communicate the results Make process improvement accomplishments and benefits
of the deployed improvements. visible and understandable to all stakeholders.
Record improvement results. May include:
• Accomplishments
• Timeframe
• Effort and cost
• Results, e.g., improved performance, processes
• Benefits
Record achieved effect to the business and compare to the
prior state.

Process improvement plan May include:
• Approach, including deployment
• Process improvement objectives
• Roles, responsibilities, and authorities
• Commitments
355

• Tasks or items to work on
• Stakeholders
• Infrastructure
• Effort
• Resource plan
• Budget and schedule
• Expected overall value and performance results
• Risks and success criteria
• Pilot plan
• Progress reporting
Action plan May include:
• Actions to be taken to implement the selected
improvements
• Responsibilities
• Due dates
Developed or updated process assets
Status report
Recorded results May include:
• Results from process improvement activities
• Benefit and value obtained from the improvements
• Performance results
• Nature and root cause of failures
• Effect on other processes and improvements

Estimating (EST)
Planning (PLAN)
356
Level 3
PCM 3.1
Practice Statement
Develop, keep updated, and use process improvement objectives traceable to the business
objectives.
Value
Ensure that process improvements focus on achieving business objectives.
Example Activities
Identify and record improvement
objectives.
Review improvement objectives with Review improvement objectives to ensure traceability to
affected stakeholders. business objectives. Traceability enables verification that the
improvement objectives contribute to meeting business
objectives.
Monitor and update improvement
objectives as needed.

Process improvement objectives that
are traced to business objectives
PCM 3.2
Practice Statement
Identify processes that are the largest contributors to meeting business objectives.
Value
Maximizes impact of improvement activities by focusing on and meeting the most important
business needs.
357

Analyze process improvement objectives to determine which are the major contributors to
achieving the business objectives. This may include analyzing:
• Business objectives and how well they are being achieved
• Business models
• Business environment
• Challenges
• Opportunities
• Planned changes
Process improvement objectives may be based on the results of a process appraisal, root cause
analysis, quality evaluation, or other input. These activities will help determine which
improvement objectives have the highest priority.
Example Activities
Review the current business model,
business objectives, and business
environment.
Review potential internal or external
business changes.
Identify and record the relationships Includes the tracing and mapping of processes and
between the objectives and processes. objectives.
Estimate the value of each process’s
contribution to achieving objectives.
Record, keep updated, and Results include identification of the processes that are the
communicate the results to affected major contributors to meeting objectives.
stakeholders.

Description of the relationships Includes:
between business objectives, • Priority of business objectives
processes, and process objectives and • Measure of contribution of each process to meeting the
their value objective
• Interrelationships of processes and objectives to each
other
One way to illustrate these relationships is the Six Sigma “Big
Y to little x” technique.
358
PCM 3.3
Practice Statement
Explore and evaluate potential new processes, techniques, methods, and tools to identify
improvement opportunities.
Value
Maximizes process innovation to more efficiently and effectively achieve objectives.
Process needs and processes are not static. Many new technologies, tools, and methods can
significantly improve the performance of the organization. An organization should continuously
search (both internally and externally) for these potential improvements, evaluate their
effectiveness on performance, and adopt the ones that prove beneficial.
Proposed improvements can be incremental, innovative, or both:
• Incremental improvements generally originate with those who do the work, e.g., users
of the process or technology. Incremental improvements can be simple and inexpensive
to implement and deployed without the need for rigorous validation or piloting.
• Innovative improvements typically involve more radical change to the processes or
technologies which can disrupt the normal work flow. Such changes typically require
more effort and resources for validation, piloting, implementation, training, and
sustainment.
When piloting, define and use criteria for selecting improvements. Criteria such as the risk,
transformational nature of change, number of functional areas affected, or cost may indicate
the need to pilot the improvement.
Example Activities
Identify, research, and record Research can be internally or externally focused, and may
improvements. include:
• Techniques
• Methods
• Process frameworks
• Objective evaluations
Use established criteria to decide what Update these criteria as organizational needs change.
documents and measures are critical Monitoring the evolution of new technology can help identify
enough to include in the organization’s new criteria for improvement.
Process Asset Library (PAL) for use
with other or future projects.
359

Analyze and evaluate potential process
improvement opportunities.
communicate the results to affected
stakeholders.

Potential improvement opportunities May include:
• New ideas and innovations
• Explanation of the ideas
• Potential impact on business objectives
• Initial cost vs. benefit analysis

PCM 3.4
Practice Statement
Provide support for implementing, deploying, and sustaining process improvements.
Value
Ensures process improvements provide value to the organization over time.
Ensure the improved processes and assets are well communicated, trained, internalized, and
perceived as useful.
Continuously support deployed processes and process assets. This support can come in the
form of coaching, providing a help desk, training, etc.
Obtain approval and commitment from senior management and involve them in visibly and
actively supporting the improvement.
Align improvement activities to avoid contradictory directions and wasted effort due to
initiatives:
• Started in different parts of the organization
• Based on different standards
360
Senior management typically delegates the day-to-day process and improvement work to a
team or a dedicated part of the organization.
Example Activities
Identify the mechanisms needed to support May include:
process implementation and deployment. • User groups, e.g., communities of practice
• Management communication, such as:
o All-hands meetings
o Newsletters
o Webinars
• Feedback to proposers of process changes
Ensure that implementation and deployment
activities are planned and coordinated.
Align multiple improvement activities. Helps to avoid:
• Conflicting goals
• Cancelled efforts
• Waste
Obtain senior management commitment to
visibly and actively support implementation,
deployment, and sustainment of the process.
Provide a migration approach from current to Approaches may vary depending on the criticality
newly deployed processes. and impact of the process. Approaches may include:
• Full implementation across the organization
• Incremental changes via pilots
• Iterative implementation by selected projects
Review the deployment results with the Include the people who perform the process. They
affected stakeholders are often the source of knowledge about the
processes and constraints.
Provide records about the success, issues,
obstacles, and progress of the supporting
activities.

Plan for implementing, deploying, and Typically includes:
sustaining improvement • Improvement requirements
• Deployment strategy
• Estimated budget, schedule, risks, etc.
• Updated vs. new processes
• Communication methods
• List of affected stakeholders
• Implementation expectations
• Migration from current to newly deployed processes
Implementation records
361

Governance (GOV)
Planning (PLAN)
PCM 3.5
Practice Statement
Deploy organizational standard processes and process assets.
Value
Ensures efficient, effective, and coordinated process deployment to reduce potential waste from
overlapping improvements.
Coordinate the deployment of selected process improvements and assets in the organization.
Deploy processes and other process assets according to the plan. Involve personnel who are
implementing and executing the process and related functions, e.g., training, quality assurance,
in deployment. Training enables attendees to apply the processes in a consistent and
sustainable way.
Provide ongoing support to prevent frustration when the something goes wrong, or the user
does not understand the process. A very effective supporting element is coaching. Mechanisms
range from question-and-answer support at defined intervals or events to mentoring by guiding
the users in applying processes, techniques, methods, and templates.
Monitoring implementation ensures that the organization’s set of standard processes and other
process assets are effectively deployed. It also helps to understand:
• What assets are being used
• Why they are being used
• Where they are being used
• How they are being used
Update defined processes to incorporate changes to the organization’s set of standard
processes and process assets. Updates help to ensure that activities benefit from what has been
learned. If standard processes and process assets change or are newly developed, work may
not need to change immediately. It may be better to delay deployment until the project can
more effectively adopt the change.
362
Ensure dependencies among active and planned performance improvement efforts are
understood and managed to ensure efficient and effective implementation and execution. There
may be multiple improvement initiatives, concurrent improvements, and deployments in an
organization. Coordinate the deployment of processes to avoid confusion, waste, contradictory
results, and adverse effect.
To avoid overwhelming any part of the organization with too much change, it may be necessary
to select and deploy different improvements to different parts of the organization. The selection
of improvements to deploy should be sensitive to the needs of the respective parts of the
organization.
Example Activities
Ensure that sufficient support is
available for the deployment.
Identify projects for deployment of Provide criteria for which work is subject to the deployment,
processes and assets. to what extent and which timeframe, e.g., new work, all
work, staggered approach.
Coordinate the deployment of Coordinating deployment includes:
improved processes with other • Coordinating activities of work groups, support groups,
improvement efforts. and organizational groups for each improvement
• Coordinating activities for deploying related improvements
Deploy the organizational set of Examples of methods for deploying improvements include:
standard processes and the • Deploying improvements incrementally rather than as a
organizational process assets to single deployment
identified projects. • Providing comprehensive consulting to early adopters of
improvements in lieu of revised formal training
Monitor the deployment of Confirm that deployment was completed in accordance with
improvements using deployment plans. the deployment plan.
Review results of objective evaluations. This helps determine how well the organization’s set of
standard processes has been deployed and how well they
are working.
Identify, record, and track to closure
issues related to implementing the
processes.
Review the deployment results with
stakeholders.

List of where improvements of new or Should include organizational processes and related process
revised processes or assets will be assets.
deployed
Deployment status report May include:
• Description of the improvement and deployments
• Where, what, and how improvements are deployed
363

• Issues with the deployment
• Results of objective evaluations
• Responsibility for implementation
• Stakeholders
• Deployment progress
• Cost expended
• Corrective actions to take
• Benefits attained
PCM 3.6
Practice Statement
Evaluate the effectiveness of deployed improvements in achieving process improvement
objectives.
Value
Ensures deployed processes are contributing to meeting process and performance improvement
objectives.
Determine effectiveness of process improvements against stated objectives and communicate
results to stakeholders. To be effective, the deployed process must make a significant positive
change in performance of the work.
Compare process improvement results against stated process improvement objectives, to
determine success and accomplishments, and take corrective action as appropriate.
Example Activities
Analyze current improvement results
against business, process, and
performance improvement objectives
and determine effectiveness of
improvements.
Record the results and communicate
Initiate and track to closure necessary
corrective actions.
364

Process improvement evaluation report May include:
• Benefit and value obtained from the improvements
• Comparison of business and process improvement
objectives against the results and accomplishments
• Need for further improvements
• Causal analysis if needed
Level 4
PCM 4.1
Practice Statement
Use statistical and other quantitative techniques to validate selected performance improvements
against proposed improvement expectations, business objectives, or quality and process
Value
Increases the success rate for performance improvement implementation.
Validate selected improvements in line with their improvement proposals by using statistical or
other quantitative techniques. Methods for collecting validation data include:
• Discussions with stakeholders, e.g., in the context of a formal review
• Prototype demonstrations
• Pilots of suggested improvements
Statistical or other quantitative techniques for validating improvements include:
• Analysis of the statistical significance of the change, e.g., using a hypothesis test
• Process variation and stability analysis
• Process capability analysis
• Modeling and simulation
Validation activities can include simulations and modeling when the performance of the changed
process and original process are statistically understood.
365
Example Activities
Plan the validation. Quantitative success criteria recorded in the improvement
proposal can be useful when planning validation. Plans to
validate selected improvements, may include:
• Target work and its characteristics
• Use of pilots, if selected
• Schedule for reporting results
• Measurement and analysis activities
• Success criteria
Review validation plans with affected
stakeholders.
Perform each validation in accordance
with the plan and record results.
Use statistical or other quantitative Validation should include determining if objectives are being
methods to analyze the results of the met.
validation.
Review, record and communicate the Reviewing and recording results of analysis typically involves:
results of validation analysis. • Reviewing results with stakeholders
• Deciding whether to:
o Proceed with deployment
o Re-plan and continue the pilot
o Rework implementation of the improvement
o Terminate the deployment
• Updating the disposition of improvement proposals
associated with the deployment
• Identifying and recording new improvement proposals
• Identifying and recording lessons learned and problems
encountered during the deployment including feedback to
the improvement team and changes to the improvement
• Evaluating validation results using statistical or
quantitative criteria defined in the improvement proposal

Validation plans
Validation reports May include:
• Validation results of suggested improvements
• Pilot results of suggested improvements
• Quantitative and statistical analysis of the effects of the
change
• Description of the validation approach
• Recommendations on the roll-out for a wider adoption,
including success criteria
366
Intent
Verify and enable improvement of the quality of the performed processes and resulting work
products.
Value
Increases the consistent use and improvement of the processes to maximize business benefit
and customer satisfaction.
Practice Summary
Level 1
PQA 1.1 Identify and address process and work product issues.
Level 2
PQA 2.1 Develop, keep updated, and follow a quality assurance approach and plan
based on historical quality data.
PQA 2.2 Throughout the project, objectively evaluate selected performed
processes and work products against the recorded process and applicable
standards.
PQA 2.3 Communicate quality and non-compliance issues and ensure their
resolution.
PQA 2.4 Record and use results of quality assurance activities.
Level 3
PQA 3.1 Identify and record opportunities for improvement during quality
assurance activities.
Objectivity in process quality assurance evaluations is critical to the success of the project.
Evaluators should not evaluate their own work. Personnel independent from the project typically
perform objective evaluations using defined criteria and a set of methods. These evaluations
are a check of the performed processes and resulting work products against applicable process
descriptions, standards, and procedures. Senior management takes an active role in process
quality assurance by regularly reviewing results and taking action as needed.
A typical project applying quality assurance will:
367
• Demonstrate more consistent process implementation

• Have better insight into the project’s results and issues
• Have better visibility into the project performance
Quality assurance verifies and ensures compliance with implementation to address issues such
as:
• Incorrect and incomplete requirements
• Insufficient release planning
• Unresolved defects
Often, the verification and validation processes evaluate the same work products as quality
assurance. Quality assurance focuses on determining that the verification and validation
activities are done by following their recorded processes. Verification focuses on satisfaction of
requirements. Validation ensures that the product works as intended in its target environment.
Promote an environment that encourages personnel to participate in identifying and reporting
quality issues.
Context Specific
An agile project using Scrum has many opportunities to objectively evaluate processes and work
products, such as when:
• Requirements are examined in the backlog review
• The Scrum Master facilitates the Scrum process
• Feedback on what was built is obtained in the sprint review
• The retrospective event allows the team to collect and organize lessons learned
Ensure that objective evaluations are integrated into the team’s techniques or rhythms, e.g., as
part of daily scrums, story point estimation, code reviews, use of tools, continuous integration,
and retrospectives.
An agile project using Scrum has many opportunities to objectively evaluate ceremonies and
work products, such as when:
• User stories are examined in the backlog grooming ceremony
• The Scrum Master coaches the team during scrum ceremonies
• Feedback on what was built is obtained in the sprint review
• The retrospective ceremony explores team behaviors and performers
368
• Management or peers observe Scrum ceremonies being performed using techniques

such as a gemba walk
Figure PQA-1 states where quality assurance activities would be performed in an agile project
using Scrum. Table PQA-1 shows example quality assurance results. Table-PQA 2 shows
example retrospective data that can be augmented by quality assurance activities.
Figure PQA-1: PQA in an Agile Framework
Table PQA-1: Example PQA Information
369
Table PQA-2: PQA Retrospective Information
370
Level 1
PQA 1.1
Practice Statement
Identify and address process and work product issues.
Value
Increases customer satisfaction through improved quality and performance.
Identify issues that impede the project. Address these issues by either changing what is done or
planning to make the changes the next time the process is performed. Identify work product
defects and issues such as missing or incorrect information, formats that make it difficult to use
the work product, or inconsistent use of terminology.
Example Activities
Identify issues.
Record issues.
Resolve issues.

Recorded issues
Addressed issues Can be immediately addressed or changed in the future.
371
Level 2
PQA 2.1
Practice Statement
Develop, keep updated, and follow a quality assurance approach and plan based on historical
quality data.
Value
Reduces cost and increases quality by focusing on recurring problem areas.
Organizations may not have enough quality assurance resources to review everything in a
project. Planning helps to optimize resource use and focus on the areas where the project is
most likely to have process or work product issues. Using historical data helps to identify areas
where applying resources will be most effective. Consider:
• Where issues have occurred in the past
• Quality trends
o May be positive or negative. Instances where there have been few issues may
not need quality resources applied to them, but areas where issues occur
repeatedly may need increased quality activities.
• Sources of best practices
• Common or recurring problems across projects
• Recent changes in processes
Plan activities and determine the type and resources needed for objective evaluations:
• Ensure qualified personnel who perform quality assurance activities participate in
developing plans, processes, standards, and procedures
• Identify and select processes and associated work products to be evaluated during the
project
• Determine how and when quality assurance activities, findings, and results will be
communicated and resolved within the organization
Example Activities
Develop, record, and keep updated the
quality approach and plan.
Identify areas for evaluation.
372

Review, update, and approve the
approach with affected stakeholders.

Quality assurance approach and plan Identify areas where the project lead would like objective
feedback.
May include:
• Scope
• Focus for objective evaluations including:
o New processes
o Processes with historical problems
o Randomly selected processes
• Work products to be objectively evaluated
• Depth and coverage of the evaluation. For example:
o In-depth evaluation
o Observation
o Quick review
• Schedule
o Date for the evaluation
o Evaluation leader
o Evaluation participants
• Description of the quality assurance process, the reporting
chain, and how objectivity will be ensured.

Planning (PLAN)
PQA 2.2
Practice Statement
Throughout the project, objectively evaluate selected performed processes and work products
against the recorded process and applicable standards.
Value
Delivers high-quality solutions by identifying and addressing issues throughout the process
execution.
373

Identifying and addressing quality issues should be done throughout the project, and not just at
the end. Catching and addressing issues early reduces the amount of rework. This also provides
timely visibility into the quality of the processes and the resulting products. Objectivity is critical
to the success of quality assurance evaluations. Critical processes or work products may require
independence from the work performed as a way of achieving objectivity.
Objectivity can be achieved by using:
• Independent quality assurance organizations or groups
• Independent reviewers who:
o Are not involved in development or maintenance of the solution
o Work in a separate management reporting chain
• Criteria such as standards, guidelines, etc.
• Checklists based on process descriptions, standards, and procedures
Examples of objective evaluation methods include:
• Formal audits
• Peer reviews with objective reviewers, which can be performed at various levels of
formality
• In-depth review of work at the place it is performed, e.g., desk audits
• Distributed review and comment regarding work products
• Built-in or automated process checks to identify incorrectly performed processes, e.g.,
Poka-yoke
Example Activities
Develop and keep updated clearly
stated criteria for evaluations.
Develop and keep updated checklists
based on process descriptions,
standards, and procedures.
Use the defined criteria and checklists
to evaluate if selected performed
processes follow process descriptions,
standards, and procedures.
Identify and record each
noncompliance found during the
evaluation.
Leverage recorded best practices in Submit improvement proposals for the best practices.
other parts of the organization.
374

Criteria
Checklists
Evaluation reports
Noncompliance reports
PQA 2.3
Practice Statement
Communicate quality and non-compliance issues and ensure their resolution.
Value
Ensures quality processes, avoids the cost of rework, and improves customer satisfaction.
Noncompliance issues are problems identified when team members do not follow applicable
standards, recorded processes, or procedures. The status of noncompliance issues tracked over
time provides an indication of quality trends. Address and resolve noncompliance issues in the
project. Take actions to resolve non-compliance issues at the level closest to the occurrence of
the non-compliance whenever possible. Escalate noncompliance issues through the
management chain for resolution when needed.
Example Activities
Communicate and resolve each Consider reporting a compliance percentage rather than the
noncompliance issue. number of noncompliance issues for a project. Report quality
assurance activities, results, and issues to senior
management on a regular basis so they can take timely and
appropriate action.
Ways to resolve noncompliance issues include:
• Fixing the noncompliance
• Changing the applicable recorded processes, standards, or
procedures
• Obtaining a waiver to cover the noncompliance issue and
accept the associated risk
Track noncompliance issues to resolution.
375

Escalate noncompliance issues when Escalation may continue through multiple layers of
they cannot be resolved. management levels until the issue is resolved.
Analyze noncompliance issues to These trends can then be used to focus future quality
identify quality trends. activities.
Ensure affected stakeholders are
aware of evaluation results and quality
trends.

Quality trend analysis reports
Noncompliance resolutions
PQA 2.4
Practice Statement
Record and use results of quality assurance activities.
Value
Using quality assurance results optimizes future quality assurance activities and reduces the
cost of future work.
Example Activities
Record and keep updated information Record information about quality assurance activities with
about quality assurance activities. enough detail to clarify status and results.
Noncompliance issues recorded as part of the peer review
report are tracked and escalated outside the project when
necessary.

Evaluation records
Quality assurance reports
376

Status reports of non-compliance
issues and corrective actions
Reports of quality trends
377
Level 3
PQA 3.1
Practice Statement
Identify and record opportunities for improvement during quality assurance activities.
Value
Identifying more efficient and effective ways to perform work improves the organization’s
capability to meet its goals and objectives.
Quality assurance includes:
• Evaluating the process as performed
• Identifying ways that the process can be improved
• Submitting improvement proposals
Quality assurance personnel should work closely with process management to ensure an
efficient and effective process is deployed, followed, and maintained. Through this relationship,
the process is continuously maintained and improved.
Example Activities
Record potential improvements Includes:
observed during quality assurance • Suggested process changes
activities. • Observations about effectiveness
• Related activities which may or may not be a part of the
current organizational process
Submit improvement proposals.

378
Product Integration (PI)
Intent
Integrate and deliver the solution that addresses functionality and quality requirements.
Value
Increases customers’ satisfaction by giving them a solution that meets or exceeds their
functionality and quality requirements.
Practice Summary
Level 1
PI 1.1 Assemble solutions and deliver to the customer.
Level 2
PI 2.1 Develop, keep updated, and follow an integration strategy.
PI 2.2 Develop, keep updated, and use the integration environment.
PI 2.3 Develop, keep updated, and follow procedures and criteria for integrating
solutions and components.
PI 2.4 Confirm, prior to integration, that each component has been properly
identified and operates according to its requirements and design.
PI 2.5 Evaluate integrated components to ensure conformance to the solution’s
requirements and design.
PI 2.6 Integrate solutions and components according to the integration strategy.
Level 3
PI 3.1 Review and keep updated interface or connection descriptions for
coverage, completeness, and consistency throughout the solution’s life.
PI 3.2 Confirm, prior to integration, that component interfaces or connections
comply with interface or connection descriptions.
PI 3.3 Evaluate integrated components for interface or connection compatibility.
Product integration activities include:
• Using recorded integration strategies and procedures
379
• Using a single build or an iterative build of solution components

• Verifying and validating each build
Note that in these practices, the terms solution and solution component include products,
services, service systems, and their components.
Preparing for integration is part of early planning and work activities. It involves developing and
recording the:
• Integration strategy
• Integration environment
• Integration procedures and criteria
When integrating products, it is critical to manage and ensure compatibility among the
interfaces or connections of product components. Component interfaces or connections can be
both internal and external.
Verify and validate each successive build according to the integration strategy, in the target
environment, and according to procedures and criteria.
Use automated builds and continuous integration for completed product components to achieve
highest quality. Some products can be integrated using automated builds and continuous
integration of the completed product components. The last integration phase may occur when
they are deployed at the intended operational environment.
Technical Solution (TS)
Context Specific
Agile teams using Scrum typically employ automation and DevOps processes for unit testing,
regression testing, system testing, and continuous builds, to reduce human effort as much as
possible. These techniques increase productivity and help to detect defects early in the product
development lifecycle. An agile team using Scrum following processes that meet the intent of
Product Integration practices also ensure that the necessary tools and environment are
planned, and that component functionality and interfaces or connections are checked for errors
before integration
Services
380
When service systems are complex and comprised of multiple components, e.g., a combination
of system components and services, the organization may need to sequence or integrate the
services to provide a single customer facing service. In this context, the Product Integration
practices provide an approach to managing and integrating multiple system and service
components or service providers. Applying Product Integration practices to processes enables
an organization to seamlessly integrate interdependent services from various internal and
external service providers into end-to-end services to meet business requirements.
381
Level 1
PI 1.1
Practice Statement
Assemble solutions and deliver to the customer.
Value
Enables customer satisfaction by delivering a usable solution.
Requirements for assembly and delivery determine how the product will be delivered to the
customer. For example, requirements will be different if the product is delivered as a download,
as a package shipped to the customer, or delivered and installed at an operational site.
Example Activities
Assemble solution.
Record all necessary information to Necessary information may include:
install and use the solution. • Configuration
• Solution component types and serial numbers
• Physical and functional layout
• Installation and tracking information
• Contact information
Use applicable methods to package Documentation packaging and delivery methods may
and deliver the solution. include:
• Hardcopy documents
• CDs or DVDs
• Online help
• Cloud-based repository
• EBooks
• Mobile applications
• Website links for downloads
Deliver the solution and related
documentation; confirm receipt.

Assembled solutions and related
documentation
382
Level 2
PI 2.1
Practice Statement
Develop, keep updated, and follow an integration strategy.
Value
Ensures that the product will meet customer requirements given available resources.
The product integration strategy includes how the:
• Solutions and components will be integrated and evaluated, i.e., as a single build or a
series of builds
• Interfaces or connections will be managed
• Integration environment will be developed
• Evaluation results will be recorded
Record the product integration strategy. When developing the integration strategy, follow the
technical approach developed during planning, addressing the solutions chosen and designs
developed during the design effort.
Developing an integration strategy can involve identifying and evaluating several alternative
integration strategies or sequences.
Review the strategy with affected stakeholders to promote commitment and understanding.
Example Activities
Identify and record product
components to be integrated.
Identify how solutions and components This includes verifications and validations to be performed on
will be verified and validated during interfaces or connections.
integration.
Identify alternative integration Possible strategies include:
strategies. • Big bang
• Incremental
• Top-down
• Bottom-up
Select the best integration strategy. Align the integration strategy to availability of:
• Product components
• The integration environment
• Test tools and equipment
383

• Procedures and criteria
• People with the appropriate skills
Periodically review the product Ensure that changes in production and delivery schedules
integration strategy and revise it as have not adversely impacted the integration sequence.
needed.
Record and communicate decision
rationale and status.

Product integration strategy Typically includes how the:
• Solutions and components will be integrated and
evaluated
• Interfaces or connections will be managed
• Integration environment will be established
• Evaluation results will be recorded
The product integration strategy may also include:
• The sequence in which components will be available
• Whether components will be integrated and evaluated as
a single build or a series of builds
• The frequency of the builds, e.g., continuous using a tool,
nightly, or event-driven
• Features to be included and evaluated in each build when
using a series of builds
• How models, prototypes, and simulations will be used to
assist in evaluating a component, including its interfaces
or connections
• How procedures and criteria will be defined
• How test tools and equipment will be made available
• How the solution hierarchy will be managed
• How evaluation exceptions will be handled
Recorded rationale for selecting or
rejecting alternative product
integration strategies
Selected integration strategy

384
PI 2.2
Practice Statement
Develop, keep updated, and use the integration environment.
Value
Provides an effective risk mitigation technique to ensure that the solution and components are
integrated correctly.
Verify and validate the integration environment before use.
The integration environment can either be acquired or developed. When developing the
integration environment, consider reusing existing organizational resources and perform make,
buy, or reuse analyses. Environment requirements can include equipment, software, or other
resources.
The environment required at each step of the integration process can include test equipment,
simulators (taking the place of unavailable product components), product components, and
recording devices.
The product integration environment can be a major development for first-time or complex
projects. For small development efforts, the integration environment may be as simple as a
directory structure.
Example Activities
Develop requirements for the
integration environment.
Develop verification and validation This is for validating the integration environment and not for
procedures and criteria for the integrating the product.
integration environment. Verify and validate the integration environment to ensure it
satisfies the requirements in accordance with the integration
strategy.
Decide whether to build, buy, or reuse This can be the whole environment or just parts of it.
the integration environment.
Develop or acquire an integration Examples of activities in developing or acquiring an
environment. integration environment include:
• Planning
• Requirements development
• Technical solutions
• Verification
• Validation
• Risk management
385

Verify and validate the integration
environment.
Use the integration environment. The integration environment may be used for testing and
other preparation work prior to solution and component
integration.
Revise the integration environment as Dispose of integration environment parts that are no longer
needed. useful.
Communicate with affected
stakeholders.

Verified and validated environment for
product integration
Build, buy, or reuse analyses
Support documentation for the
integration environment

PI 2.3
Practice Statement
Develop, keep updated, and follow procedures and criteria for integrating solutions and
components.
Value
Improves the likelihood of producing a solution that works correctly and meets the customer’s
requirements.
Procedures and criteria for product integration (manual or automated) may address:
• The number of incremental iterations to be performed
386
• How product components will be verified and validated

• Functionality and quality attributes
• Verification and validation of interfaces or connections
• Thresholds of performance deviation
• The environment to be used for the integration test
• Environmental parameters
• Availability of resources
• Derived requirements for the integration and its external interfaces or connections
• Allowable substitutions of components
• Quality or cost tradeoffs for integration operations
• Delivery rate and variation
• Lead time from order to delivery
Communicate schedule and integration status with affected stakeholders to reduce the risk of
delays and failures.
Example Activities
Develop, use, and keep updated
product integration procedures for the
product components.
criteria for product component
integration and evaluation.
communicate the product integration
procedures and criteria.

Product integration procedures
Product integration criteria
PI 2.4
Practice Statement
Confirm, prior to integration, that each component has been properly identified and operates
according to its requirements and design.
387
Value
Helps reduce total development cost, integration cycle time, and rework.
Ensure that each component meets its requirements and design and can be integrated
according to the product integration strategy and procedures. Components are checked for
consistency with interface or connection descriptions. Verification and validation can provide
confirmation of integration readiness.
Example Activities
Track the integration readiness status
of the components.
Ensure components are delivered to
the product integration environment as
described in the product integration
strategy and procedures.
Confirm each component is correctly
identified and received.
Verify and validate that each received
component meets its requirements and
design.
Check the status of the current
configuration against the expected
configuration.
Check all the physical interfaces or For example, check by a visual inspection or using basic
connections before integrating product counts of interfaces or connections.
components.
Communicate results with affected
stakeholders.

Acceptance documents or test criteria
for each product component
Exception reports Include handling instructions for what to do with exceptions
and nonconforming work products.

388
PI 2.5
Practice Statement
Evaluate integrated components to ensure conformance to the solution’s requirements and
design.
Value
Helps to ensure customer requirements are correctly implemented.
The product integration strategy and procedures define when and how to evaluate solutions
and components. For example, each incremental integration can be evaluated to ensure that
the components work together. Alternatively, the solution can be evaluated once after all the
components are integrated. In either case, the resulting solution should meet its specification
which may be defined in requirements, solution architecture, design, or test acceptance criteria.
Evaluate integrated components at different stages of integration as identified in the product
integration strategy and procedures. Examine, integrate, and test components for performance,
suitability, and readiness using the product integration procedures, criteria, and environment.
Verification and validation of the integration testing may be a part of the integration strategy
and procedures. Waivers may be used when defects or other results are accepted without
resolution.
Example Activities
Evaluate integrated components,
interfaces or connections, and testing
using the integration strategy,
procedures, and criteria.
Record and communicate evaluation Example results include:
results. • Integration procedure or criteria changes
• Product configuration changes (spare parts, new release)
• Deviations from evaluation procedures or criteria
• Defects and exceptions

Integration evaluation reports
Interface or connection evaluation reports
Test reports
Exception reports
389

PI 2.6
Practice Statement
Integrate solutions and components according to the integration strategy.
Value
Ensures that the customer receives a solution that meets requirements and design.
Integration and evaluation activities can be performed iteratively. Evaluate integrated
components before proceeding to the next integration iteration.
Example Activities
Confirm readiness of the product
integration environment.
Integrate components according to the Record all appropriate component information.
product integration strategy,
procedures, and criteria.
Update the product integration
strategy, procedures, and criteria as
needed.
Integrate and deliver the product and Integration and delivery should address requirements for:
communicate results. • Safety
• Environment protection
• Security
• Transportability
• Disposal
Examples of requirements and standards for packaging and
delivering include:
• Type of storage and delivery media
• Required documentation
• Copyrights
• License provisions
• Preparation of the operational site for product installation
390

Install the product at the operational site and confirm correct
operation and communicate results.
Final product verification and validation may occur at the
operational site.

Integrated solution or components
Exception or test reports
391
Level 3
PI 3.1
Practice Statement
Review and keep updated interface or connection descriptions for coverage, completeness, and
consistency throughout the solution’s life.
Value
Reduces rework and missed project objectives caused by incompatible or inconsistent interfaces
or connections.
Start managing component interfaces or connections early in the development of the project.
Interfaces or connections include:
• Product component interfaces or connections
• Interfaces or connections with other solutions, systems, or components
• Interfaces or connections with specific environments which may include:
o Verification
o Validation
o Operations
o Support
Interface or connection definitions and designs can affect verification and validation
environments in addition to the components and external systems. Ensure that interface or
connection changes are recorded, maintained, and readily accessible.
Managing interfaces or connections includes maintaining their consistency throughout the life of
the solution, complying with architectural decisions and constraints, and resolving conflicts or
changes. Managing interfaces or connections between solutions acquired from suppliers and
other products or product components is critical for the success of the work.
Example Activities
Review with affected stakeholders and Interfaces or connections are usually classified in three main
keep updated interface or connection classes:
descriptions for coverage, • Environmental
completeness, and consistency • Physical
throughout the product’s life. • Functional
392

Typical categories for these classes may include:
• Mechanical
• Fluid
• Sound
• Electrical
• Climatic
• Electromagnetic
• Thermal
• Message
• Operators or users
Resolve interface or connection issues.
Update interface or connection
descriptions and make accessible to

Interface or connection review results
List of action items for updating
interfaces or connections
Updated interface or connection
descriptions

Context Specific
Services
In the context of service systems, interfaces or connections can fit into one of four major
groups: person-to-person, person-to-component, component-to-component, and compound
interfaces:
• Person-to-person interfaces are interfaces or connections that represent direct or
indirect communication between two or more people
o These people can include service provider personnel or end users
o For example, a call script (which defines how a help desk operator should
interact with an end user) defines a direct person-to-person interface
o Log books and instructional signage are examples of indirect person-to-person
interfaces
393
• Person-to-component interfaces are interfaces or connections that encompass

interactions between a person and one or more service system components
o These interfaces or connections can include both graphical user interfaces for
automated components, e.g., software applications; and operator control
mechanisms for automated; partially automated; and non-automated
components, e.g., equipment, vehicles
• Component-to-component interfaces are interfaces or connections that do not include
direct human interaction
o This includes the interfaces of interactions between automated components and
other possibilities, such as specifications limiting the physical interaction of two
components, e.g., a delivery truck and a loading dock
• Compound interfaces are interfaces or connections that merge or layer together
interfaces from more than one of the other three groups
o For example, an online help system with live chat support might have a
compound interface built on an integrated combination of person-to-person,
person-to-component, and component-to-component interfaces
Interfaces can be external or internal:
• External interfaces are interactions among components of the service system and any
other entity external to the service system, including people, organizations, and systems
• Internal interfaces can include interactions among personnel, teams, and functions of the
service provider organization; internal interfaces can also include interaction between
personnel or end users and service system components
Examples of user interface work products include:
• Customer interaction scripts
• Reporting types and frequency
• Application program interfaces
PI 3.2
Practice Statement
Confirm, prior to integration, that component interfaces or connections comply with interface or
connection descriptions.
Value
Reduces the amount of rework due to interface or connection incompatibility.
394

Example Activities
Compare interface or connection This comparison may include:
descriptions with component interfaces • Performing a pre-check of all the physical interfaces or
or connections and identify non- connections before integrating components
compliances. • Performing a functional review of external component
interfaces or connections
• Confirming that verification and validation activities were
completed
Address interface or connection non-
compliances and communicate results.

Results of comparison of component
interfaces or connections to their
descriptions
List of component interface or
connection non-compliances
List of action items for updating
interface or connection descriptions or
component interfaces or connections
descriptions or component interfaces
or connections
Context Specific
Services
Integrate the service system as defined in the planned integration strategy and procedures.
Before integration, verify each service system component for compliance with its interface or
connection requirements, including any service system components that are manual processes.
395
PI 3.3
Practice Statement
Evaluate integrated components for interface or connection compatibility.
Value
Reduces the risk of interface or connection failure within integrated components.
Evaluate and test integrated components to ensure that the interfaces or connections within
components are functioning correctly.
As identified in the product integration strategy and procedures, evaluate integrated
components and their interfaces or connections, as appropriate, at different stages of
integration.
Example Activities
Evaluate the integrated components Compatibility may include:
for compatibility. • Alignment with specifications
• Functionality
• Reliability
Record and communicate the Example results include:
evaluation results. • Integration procedure or criteria changes
• Product configuration changes (spare parts, new release)
• Interface or connection and interface or connection
description changes
• Deviations from evaluation procedures or criteria
• Interface or connection defects

Interface or connection issues reports
Context Specific
Services
396
Some service systems can require assembly with customer or end user resources to complete
full integration. When these resources are available under the terms of a service agreement,
incorporate them, as appropriate, in integration activities. When such resources are not
available from customers and end users, temporarily employ substitute equivalent resources to
enable full service system integration.
397
Intent
Elicit requirements, ensure common understanding by stakeholders, and align requirements,
plans, and work products.
Value
Ensures that customers’ needs and expectations are satisfied.
Practice Summary
Level 1
RDM 1.1 Record requirements.
Level 2
RDM 2.1 Elicit stakeholder needs, expectations, constraints, and interfaces or
connections.
RDM 2.2 Transform stakeholder needs, expectations, constraints, and interfaces or
connections into prioritized customer requirements.
RDM 2.3 Develop an understanding with the requirements providers on the
meaning of the requirements.
RDM 2.4 Obtain commitment from project participants that they can implement
the requirements.
RDM 2.5 Develop, record, and maintain bidirectional traceability among
requirements and activities or work products.
RDM 2.6 Ensure that plans and activities or work products remain consistent with
requirements.
Level 3
RDM 3.1 Develop and keep requirements updated for the solution and its
components.
RDM 3.2 Develop operational concepts and scenarios.
RDM 3.3 Allocate the requirements to be implemented.
RDM 3.4 Identify, develop, and keep updated interface or connection
requirements.
398
RDM 3.5 Ensure that requirements are necessary and sufficient.

RDM 3.6 Balance stakeholder needs and constraints.
RDM 3.7 Validate requirements to ensure the resulting solution will perform as
intended in the target environment.
Three typical types of requirements:
1. Customer or business requirements
2. Solution requirements
3. Interface or connection requirements
Taken together, these requirements address the needs of stakeholders, including needs
pertinent to various lifecycle phases and attributes, e.g., responsiveness, security, quality.
Requirements can also include constraints.
All projects have requirements. Requirements are the basis for developing the right solutions.
Requirements development activities include:
• Eliciting, analyzing, validating, and communicating customer needs, expectations, and
constraints
• Prioritizing customer requirements to understand what will satisfy stakeholders given
resource constraints
• Developing the lifecycle requirements of the solution
• Developing operational concepts and scenarios
• Developing the customer functional and quality attribute requirements, including
descriptions, decompositions, and allocating requirements to functions
• Developing initial solution requirements consistent with customer requirements
Customer requirements are further refined into solution and interface or connection
requirements. In addition to customer requirements, solution and interface or connection
requirements are derived from the selected design solutions.
Identify and refine requirements throughout the project. Involve stakeholders in requirements
development and analysis activities to give them visibility into the evolution of requirements.
Analyze design decisions, subsequent corrective actions, and feedback for impact on
requirements. Analyses can be used to understand, define, and select the requirements.
In addition, the definition may specify design constraints. Some quality attributes will emerge as
architecturally significant and drive the development of the solution architecture. Quality
attributes may address:
• Solution availability
• Ability to sustain and maintain
• Timeliness, throughput, and responsiveness
• Consistency
• Security
399
• Scalability
Analyses are iterated until there is enough detail to develop the solution or a portion of the
solution. Analysis of requirements and the operational concepts and scenarios may result in
identifying more requirements, including:
• Constraints of various types
• Technological limitations
• Costs
• Time constraints
• Risks
• Functionality, support, and maintenance concerns
• Issues implied but not explicitly stated by the customer
• Business considerations, regulations, and laws
Develop a functional design through iteration with the evolving operational concept and
scenarios. During design, refine, derive, and allocate requirements to the functional solution
and solution components.
Peer Reviews (PR)
Context Specific
Figure RDM-1 states where requirements activities are performed in an agile project using
Scrum. Figure RDM-2 shows a top-level summary of requirements information and in which
sprint those requirements are addressed.
400
Figure RDM-1: RDM in an Agile Framework
Figure RDM-2: Requirements Information
Requirements Development and Management practices can strengthen the typical agile project
by adding greater requirements understanding, clarity, and discovery of issues. Requirements
Development and Management practices add early consideration of other requirement types
beyond the user stories typically used by an agile project using Scrum. Practices in this PA also
add performing analyses to find errors and risks while conducting the requirements definition
activities. For example, agile expects user needs to be elicited as a backlog of user stories, but
a backlog does not typically include constraints, interfaces or connections, and quality
attributes. RDM practices provide a means for capturing and addressing these attributes during
the sprints. Requirements Development and Management practices provide a robust
infrastructure to support requirements development for complex solutions.
These practices can be added iteratively to improve any agile project using Scrum during
backlog creation, grooming, and sprint execution.
Table RDM-1 shows where Requirements Development and Management practices can
augment a typical agile project using Scrum.
401
Table RDM-1
Agile Projects using Scrum Requirements Development and Management
Release planning Earlier and more complete understanding of the solution and
risks.
Backlog grooming/review Broader and deeper analysis of user stories or epics to
discover potential issues or constraints. Additionally, these
analyses will identify risks.
Sprint planning Presentation of stories by the product owner, review
acceptance by the team, and estimate of the user stories to
be delivered during the upcoming sprint.
Sprint execution More of the project is spent developing a working solution
vs. refactoring.
Sprint review/demo Enables a more thorough understanding of what has been
accomplished during the sprint.
Sprint retrospective Collaborative sessions where the agile team’s culture,
process, and performance is reviewed
Agile projects using Scrum typically will implement traceability from business need through
epics, user stories, tasks, tests, and the definition of done. Designs and code are often traced
directly to user stories. Traceability enables more efficient and accurate consistency checks
between requirements (user stories or epics) and work products. Traceability also improves the
ability to understand and addresses what is impacted by a requirement (user story or epic)
change.
Development
For product lines, engineering processes (including requirements development) may be applied
at multiple levels. At the product line level, perform a “commonality and variation analysis” to
help elicit, analyze, and develop core assets for use by projects within the product line. At the
project level, use these core assets per the product line plan as part of the project’s engineering
activities.
Supplier Management
The acquirer has overall responsibility for ensuring that requirements meet the objectives for
the solution. The acquirer should clearly define requirements that can be incorporated into
supplier agreements and solutions. In some acquisitions, the acquirer assumes the overall role
of engineer, architect, or integrator for the solution.
402
Level 1
RDM 1.1
Practice Statement
Record requirements.
Value
Recorded requirements are the basis for successfully addressing customer needs and
expectations.
Typically, customers cannot describe all aspects of what they want and need. Recorded
requirements provide a basis for mutual discussion, understanding, and agreement between the
customer and the project. Requirements include what the delivered solution will do.
Example Activities
Record the requirements.

Recorded requirements Examples include:
• List of requirements
• Statement of work
• Use cases
403
Level 2
RDM 2.1
Practice Statement
Elicit stakeholder needs, expectations, constraints, and interfaces or connections.
Value
Active elicitation of requirements ensures a deeper mutual understanding of the requirements
and increases the likelihood that the customer will be satisfied.
Ensure stakeholder needs, expectations, constraints, limitations, and interfaces or connections
are clearly identified, understood, and do not conflict. Determine additional requirements to
address lifecycle activities and their effect on the solutions. Use an iterative process throughout
the life of the project to continuously refine the requirements. Consider environmental, legal,
and other constraints when developing customer requirements. Requirements record externally
observable behavior. Recorded internal behavior is a design constraint. Requirements represent
what the customer needs and expects, not how the requirements will be addressed.
Example Activities
Elicit stakeholder needs, Identify additional requirements not explicitly provided by stakeholders.
expectations, Techniques to elicit needs include:
constraints, and
interfaces or • Technology demonstrations
connections. • Interim project reviews
• Questionnaires
• Interviews
• Scenarios (operational, sustainment, and development)
• Walkthroughs
• Quality attribute elicitation workshops with stakeholders
• Prototypes and models
• Brainstorming
• Quality function deployment
• Market surveys
• Beta testing
• Extraction from sources such as documents, standards, or specifications
• Observation of existing solutions, environments, and workflow patterns
• Use cases
• Business case analysis
• Reverse engineering (for legacy solutions)
• Customer satisfaction surveys
• Viewpoint analysis
404

List of stakeholder needs,
expectations, constraints
List of interfaces or connections Interfaces or connections may include:
• Links
• System
• Human
• Relationships
• Interactions
• Interdependencies
RDM 2.2
Practice Statement
Transform stakeholder needs, expectations, constraints, and interfaces or connections into
prioritized customer requirements.
Value
Ensure customer priorities are addressed to minimize the cost of rework during acceptance and
maximize customer satisfaction.
Consolidate and prioritize various inputs from customers and stakeholders, obtain missing
information, and resolve conflicts as customer requirements are developed, prioritized, and
recorded.
The customers’ functional and quality attribute requirements can be expressed in the
customer’s terms and can contain nontechnical descriptions. Solution and contractual
requirements are the expression of these requirements in more explicit technical terms that can
be used for design decisions.
Sources for requirements include:
• Customer provided input
• Stakeholder provided input
• Previous efforts
• Existing solution systems
• Domain literature
• Laws and regulations
405
• Standards
• Business policies
• Previous architectural design decisions and principles
• Business environmental requirements, e.g., laboratories, testing and other facilities,
information technology infrastructure
• Technology
These stakeholder needs, expectations, constraint, and interface or connection requirements
may include:
• Technical requirements, such as:
o External interface or connection
o Internal interface or connection (developed during design)
o Functional
o Quality
o Operational
o Performance
o Verification
o Validation
o Acceptance criteria
o Safety
o Security
• Nontechnical requirements, including:
o Price and cost
o Delivery constraints
o Resource constraints
o Training
o Customer interactions, e.g., status reporting, meetings
Ensure technical and non-technical requirements address the satisfaction of customer, business,
and project objectives and associated attributes, such as effectiveness and affordability.
Analyze stakeholder requirements to lay the foundation for the operational concept. To avoid
scope creep, develop criteria to designate appropriate channels or official sources from which to
receive requirements changes.
This results in more detailed and precise sets of requirements called “derived requirements”.
These requirements address all aspects of the deliverables including:
• Work products
• Services
• Processes
406
• Consumables
• Customer-provided resources and other resources
• Functionality and quality attribute needs of affected stakeholders
Derived requirements arise from:
• Constraints
• Consideration of issues implied but not explicitly stated in the stakeholder requirements
• Factors introduced by the selected:
o Unique business considerations
o Strategic priorities
o Industry market and technology trends
o Architecture
o Design
Example Activities
Translate stakeholder needs, Factors to consider when expressing customer requirements
expectations, constraints, and include:
interfaces or connections into • Key characteristics of the desired capability
recorded customer • Obstacles to overcome to achieve the capability
requirements. • Competitive gap between the existing and the desired capability
• Supportability of the desired capability
Requirements should not specify or constrain design decisions
without careful consideration.
Develop, record, and keep Prioritized customer requirements help to determine project,
updated a prioritization of iteration, or increment scope. This prioritization ensures that
customer requirements. functional and quality attribute requirements critical to the
customer and other stakeholders are given the highest visibility and
attention.

Work Products Further Explanation
Prioritized customer requirements
Customer constraints May include constraints related to:
• Design
• Verification
• Validation
407
RDM 2.3
Practice Statement
Develop an understanding with the requirements providers on the meaning of the
requirements.
Value
Helps to ensure the correct solution is delivered which increases customer satisfaction.
Ensure people who implement and test solutions against the requirements analyze them with
the provider to reach a shared understanding of the meaning of the requirements. The result of
these analyses and interactions is a set of approved requirements. It is important to identify
and eliminate as much ambiguity as possible from the set of requirements.
Example Activities
Develop criteria for identifying
appropriate requirements providers.
Develop criteria for the evaluation and Evaluation and acceptance criteria can prevent:
acceptance of requirements. • Inadequate verification
• Costly rework
• Customer rejection
For example, evaluation and acceptance criteria may include:
• Unambiguous
• Clearly and properly stated
• Complete
• Consistent with one another
• Uniquely identified
• Consistent with the architectural approach and quality
attribute priorities
• Appropriate to implement
• Testable
• Traceable to source
• Achievable
• Tied to business value
• Identified as a priority by the customer
Analyze requirements to ensure that
established criteria are met.
Reach an understanding of and obtain
commitments to requirements with the
408

requirements providers and the project
participants.
Record needed changes to
requirements.

Lists of appropriate requirements
providers
Criteria for evaluation and acceptance
of requirements
Results of analyses against criteria
Recorded changes to requirements
Set of approved requirements Reflects the shared understanding between the project and
the customers.
RDM 2.4
Practice Statement
Obtain commitment from project participants that they can implement the requirements.
Value
Ensures commitments are well understood to minimize delays and rework.
As requirements are developed or evolved, ensure project participants commit to the approved
requirements and the resulting changes in project plans, activities, and work products. Their
commitment increases the likelihood of success in meeting project objectives.
Example Activities
Assess the impact of requirements on
existing commitments.
Negotiate and record commitments. Negotiate commitments before work starts
409

Impact assessment Estimate the cost, and the impact to quality, risk, and
schedule.
Recorded commitments that Recorded commitments may be in the form of:
requirements can be met • Meeting minutes
• Sign-off documents
• Email acknowledgements
• May address resources and schedule.
Context Specific
Supplier Management
The acquirer negotiates with the customer and supplier before committing to a requirement
change. A requirements change can lead to modifications to supplier agreements. Ensure the
acquirer, supplier, and customer agree on these changes after appropriate negotiations. In
some acquisitions, the acquirer may represent, and act on behalf of the customer. Deliverables
may include impact assessments when a requirement change occurs.
RDM 2.5
Practice Statement
Develop, record, and maintain bidirectional traceability among requirements and activities or
work products.
Value
Ensures consistency between requirements and the solution which increases the likelihood of
customer satisfaction.
Traceability from source requirements to the solution ensures that:
• Requirements have been completely addressed in customer deliverables
• Lower level requirements can be traced to a valid source
• Requirements are implemented
• Selected requirements are verified and validated
410
• Relationships to other entities such as intermediate and final work products may:
o Include dependencies in which a change in one requirement can impact other
requirements
o Aid in design and in evaluating the impact of changes
o Affect evaluating the impact of requirements changes
o Support anticipated scope changes
• Design and other documentation reflect requirements
• Test plans and test cases address the requirements
Traceability is particularly helpful when assessing the impact of requirements changes on work
activities and projects. Bidirectional traceability is not always automated. It can be done
manually using spreadsheets, databases, and other common tools. Bidirectional traceability
needs to be implemented in concert with lifecycle activities. If it is left to the end of the project,
it will be a costly and error prone effort.
Example Activities
Develop, record, and keep updated Trace requirements from their source through intervening
bidirectional requirements traceability. work products to the customer deliverable

Records of bidirectional requirements
traceability
Context Specific
Services
In a service environment, trace stakeholder requirements to:

• Elements of the delivered service and supporting service system developed from those
requirements
• Service levels
• Other requirements derived from stakeholder requirements
Elements of the delivered service and supporting service system should be traceable back to the
stakeholder requirements they meet.
Maintain traceability for work products and components, such as the service system
architecture, service system components, development iterations, or increments, functions,
interfaces or connections, objects, people, processes, and other work products.
411
A traceability matrix might have the list of stakeholder requirements and derived requirements
on one axis. The other axis might list components of the service system, including people and
consumables. The intersections of the rows and columns would indicate where a requirement
applies to the parts of the service system.
Supplier Management
The acquirer maintains overall bidirectional traceability between customer requirements and the
solution. The supplier maintains bidirectional traceability between the solution, the solution
components, and the requirements defined in the supplier agreement. The acquirer verifies that
traceability. The supplier also maintains traceability from contractual requirements to derived or
additional requirements.
RDM 2.6
Practice Statement
Ensure that plans and activities or work products remain consistent with requirements.
Value
Minimizes rework by eliminating inconsistencies between requirements and related artifacts.
Example Activities
Review plans, activities, and projects Maintaining bidirectional traceability is critical to maintaining
for consistency with requirements and consistency between requirements, work products, and
changes made to them. plans.
Record inconsistencies and their Identify any changes that should be made to plans and
sources. projects resulting from changes to the requirements.
Initiate and record any necessary
corrective actions and communicate
results to affected stakeholders.
412

Records of inconsistencies between
requirements, plans, and work
products
Corrective actions
413
Level 3
RDM 3.1
Practice Statement
Develop and keep requirements updated for the solution and its components.
Value
Ensures the built solutions meet the customers’ needs and expectations in a consistent way
across the organization.
Example Activities
Develop, record, and keep updated
requirements in technical terms
necessary for solution and solution
component design.
Derive, record, and keep updated
requirements that result from solution
selections and design decisions.
Record and keep updated bidirectional
traceability.
Review requirements for potential
impact to architecture and design.
Record and keep updated prioritization
of requirements.
Record and keep updated nontechnical
requirements.
Identify, record, and keep updated
requirements for external and internal
interfaces or connections.

Requirements May include:
• Solution requirements
414

• Architectural requirements – specify or constrain the
relationships among components
• Solution component requirements
• Derived requirements – with bidirectional traceability to
source requirements
• Requirement allocations – for bidirectional traceability
• Internal and external interface or connection requirements
Context Specific
Development
Selection of a technology brings with it additional requirements. For instance, use of electronics
requires additional technology-specific requirements such as electromagnetic interference limits.
Services
Analyze stakeholder requirements while developing the operational concept to derive more
detailed and precise sets of requirements called derived requirements. These requirements
address all aspects of the service system associated with service delivery, including work
products, services, processes, consumables, customer resources, other resources, warranty
costs, service incentives, and the functionality and quality attribute needs of affected
stakeholders.
In some service contexts, derived requirements can be as simple as identifying and quantifying
required resources. For complex service systems with many types of components and
interfaces, iteratively refine the initial requirements into lower level sets of more detailed
requirements that can be allocated to service system components as the preferred solution is
refined.
Develop the functionality and quality attribute requirements for the service system through this
analysis and through refinement, derivation, and allocation activities.
RDM 3.2
Practice Statement
Develop operational concepts and scenarios.
415
Value
Enables customers to understand, confirm, and commit to how their requirements will be met.
A scenario describes a sequence of events that:
• Includes user and product interactions
• May occur in the development, use, or sustainment of the product
An operational concept provides:
• A view of the system or product from the user perspective
• A context for developing or evaluating a set of scenarios
Operational concepts and scenarios together demonstrate what the requirements are trying to
accomplish. For example, the operational concept for a satellite-based communications product
is quite different from one based on landlines. The scenario would cover the steps in the
communication process.
Example Activities
Develop, record, and keep updated Identify and develop scenarios, consistent with the level of
operational concepts and scenarios. detail in the stakeholder needs, expectations, and
constraints.
Ensure scenarios address quality attribute, functions, or
other factors.
Iteratively refine operational concept and scenarios to
include more detail as decisions are made and as lower level
requirements are developed; for example, describe
interactions among the:
• Solution
• End users
• Environment
• Boundaries and constraints
Review operational concepts and
scenarios with affected stakeholders to
refine and discover requirements.

Operational concepts and scenarios
416
RDM 3.3
Practice Statement
Allocate the requirements to be implemented.
Value
Increases customer satisfaction by delivering a complete solution that meets requirements.
The architecture provides the basis for allocating requirements to components. A higher-level
requirement can be allocated to more than one component.
Example Activities
Allocate, record, and keep updated Requirements are typically allocated to:
requirements. • Logical design – As the operational concept evolves,
allocate requirements to logical entities, e.g., functions,
processes, that help relate the requirements to the
operational concept. These logical entities serve to
organize the requirements and assist in the synthesis of
the technical solution.
• Physical design – As the technical solution is selected or
developed, allocate requirements to solution components.
• Components
• Interfaces or connections
• Delivery increments
Record and keep updated relationships Relationships include dependencies in which a change in one
among allocated requirements. requirement can affect other requirements.
Review requirements allocations and
relationships with affected
stakeholders.

Requirement allocations
417
Context Specific
Supplier Management
Allocate contractual requirements, as appropriate, to supplier deliverables. Record the

requirements for each supplier deliverable. In some cases, technical requirements are allocated
to third-party solutions that the supplier uses, e.g., COTS products.
Example acquirer activities include:
• Allocating requirements to suppliers
• Allocating requirements to supplier deliverables
• Allocating design constraints and record relationships among allocated requirements and
design constraints
• Developing an approach to address requirements shared among multiple stakeholders,
e.g., the acquirer, multiple suppliers, customers, end users
RDM 3.4
Practice Statement
Identify, develop, and keep updated interface or connection requirements.
Value
Reduces rework and risk due to incompatible internal and external interfaces or connections.
Identify interfaces or connections between functions, objects, or other logical entities.
Interfaces or connections can be internal or external to a solution. Define interface or
connection requirements between solutions or solution components identified in the
architecture. Interfaces or connections are controlled as part of solution integration. Ensure
interface or connection requirements are reviewed by affected stakeholders. This is typically
done within the context of a control group of stakeholders.
Example Activities
Identify, record, and keep updated As the design progresses, the architecture will be altered by
internal and external interface or technical solution processes, developing new interfaces or
connection requirements.
418

connections between internal components and components
external to the solution.
Management of the interfaces or connections may include:
• Maintaining consistency of the interface or connection
• Complying with architectural decisions and constraints
• Resolving conflict, non-compliances, and change issues
Review interface or connection Review the interface or connection descriptions with affected
requirements for coverage and stakeholders to:
completeness with affected • Avoid misinterpretations
stakeholders, and record results. • Reduce delays
• Prevent the development of interfaces or connections that
do not work properly

Interface or connection requirements May include:
• Categories with lists of interfaces or connections
• Requirements defined for each set of solution components
Interface or connection requirements
review results
Action items for updating interface or
connection requirements
requirements

Context Specific
Development
Define requirements for interfaces in terms such as:

• Software
o Origination
o Destination
o Stimulus
o Data characteristics
419
o Communication interfaces, e.g., protocols such as HTTP, FTP

o User interfaces, e.g., screen layout, font, buttons
• Hardware
o Electrical
o Mechanical
o Hydraulic
o Physical connections
o Power characteristics
o Radiation
o Thermal
o Safety
o Security
RDM 3.5
Practice Statement
Ensure that requirements are necessary and sufficient.
Value
Avoids rework by only delivering necessary solutions.
A necessary requirement is one that must be met for the solution to function as intended.
Sufficiency typically deals with the set of requirements being complete enough for the solution
to function as intended.
Requirements analysis helps determine if requirements:
• Are all necessary
• Are missing
• Are consistent with each other
• Can be implemented as defined
• Can be verified and validated
• Conflicts are removed
420
Example Activities
Perform a requirements analysis to Analyze requirements to ensure they are:
determine if requirements are • Relevant
necessary and sufficient. • Complete
• Feasible
• Maintainable
• Not in conflict
Analyze operational concepts and scenarios to refine
customer needs, constraints, and interfaces or connections,
and to discover new requirements. This analysis can result in
more detailed operational concepts and scenarios and
supports deriving new requirements.
Review analysis results with
stakeholders.
Update requirements based on review
results.

Requirements analysis results May include reviews of:
• Requirements defects
• Activity diagrams and use cases
• Logical or functional designs with allocated requirements
• Proposed requirements changes
Updated requirements
RDM 3.6
Practice Statement
Balance stakeholder needs and constraints.
Value
Increases stakeholder satisfaction while addressing conflicting requirements and constraints.
421

The intent of this practice is to ensure an understanding and agreement between the project
and the customer about what is delivered given resource constraints. This typically involves
negotiating benefits and tradeoffs with customers and other stakeholders. When costs and
issues outweigh the benefits, consult affected stakeholders to determine what changes may be
needed.
Stakeholder needs and constraints can address:
• Cost
• Schedule
• Performance
• Functionality
• Quality
• Priorities
• Resources
• Reusable components
• Maintainability
• Risk
Analyze requirements to determine whether they reflect an appropriate balance among cost,
schedule, performance, quality, customer needs, and other factors of interest to affected
stakeholders. Models and simulations can be used to estimate the impact that requirements will
have on these factors. Involve stakeholders in the analysis of impacts and issues from different
phases of the solution’s lifecycle. If the issues are considered unacceptable, revise or reprioritize
the requirements to improve the balance of cost, schedule, performance, and quality.
Example Activities
Analyze requirements to ensure that Analysis includes use of:
they balance stakeholder needs and • Models
constraints. • Simulations
• Prototypes
• A risk assessment on the requirements and definition of
required functionality, performance, and quality attributes
• Assessment of the requirements on cost, schedule,
functionality, and quality
Review, analyze and negotiate
requirements tradeoffs with customers
and stakeholders.
Record and keep updated proposed
requirements changes and
communicate with affected
stakeholders.
422

Analysis results Includes:
• Identification of where costs, schedule, performance,
quality, and other factors exceed constraints
• Assessment of risks related to requirements
Proposed requirements changes

Context Specific
Services
Analyze requirements and define required service system functionality and quality attributes to
balance the stakeholders’ needs, expectations, constraints, and interfaces or connections.
Depending on the service delivery context, consider factors such as feasibility, business
objectives and needs, cost constraints, end user types, potential market size, and procurement
strategy. Determine the parameters used to evaluate the effectiveness of service delivery based
on customer and end user input and the preliminary service delivery concept.
Example Activities
Develop and keep updated a definition This definition can include descriptions, breakdowns, and
of required functionality and quality
categorizations of the service’s functions.
attributes.
In addition, the definition specifies design considerations or
constraints on how to achieve the required functionality in
the service system. Some quality attributes will emerge as
architecturally significant and drive subsequent service
system high-level design activities. A clear understanding of
the quality attributes and their importance based on business
objectives or needs is essential to the design process.
Validate requirements to ensure the
resulting service system will perform as
intended in the end user’s
environment.
Operational concepts and scenarios,
use cases, activity diagrams, and user
stories
Service system and service system
component installation, training,
423

operational, maintenance, support, and
disposal concepts
Definition of required functionality and
quality attributes
Architecturally significant quality
attribute requirements
New requirements
Requirement defect reports and
proposed changes to resolve
Assessments of risks related to
requirements
Records of analysis methods and
results
Supplier Management
Perform a cost benefit analysis to assess trade-offs between requirements and the effect on the
overall acquisition strategy.
This analysis often focuses on evaluating requirements that address architecturally significant
quality attributes. For example, a combination of tight response time requirements and high
reliability requirements could be expensive to implement. Impact analysis provides the insight
for the acquirer to select a more cost effective solution to balance cost, schedule, and
performance against risk and opportunity.
RDM 3.7
Practice Statement
Validate requirements to ensure the resulting solution will perform as intended in the target
environment.
Value
Avoids rework cost and increases satisfaction by delivering a solution that meets customer
expectations and needs.
424

Perform requirements validation with affected stakeholders throughout the solution lifecycle to
confirm that the requirements are necessary and sufficient in the target environment.
Example Activities
Identify and select validation To broaden and deepen understanding of requirements, use
techniques. multiple validation techniques such as:
• Functional analysis
• Simulation
• Prototypes
• Demonstrations
• Tests
• Reviews or walk-throughs
Validate the requirements using
selected techniques and record results.
Review and communicate validation
results with stakeholders.
Update requirements.

Selected validation techniques
Record of validation results
Updated requirements

425
Intent
Identify, record, analyze, and manage potential risks or opportunities.
Value
Mitigate adverse impacts or capitalize on positive impacts to increase the likelihood of meeting
objectives.
The term risk refers to uncertainties that may have a negative impact on achieving objectives.
The term opportunity refers to uncertainties that may have a positive impact on achieving
objectives.
Practice Summary
Level 1
RSK 1.1 Identify and record risks or opportunities and keep them updated.
Level 2
RSK 2.1 Analyze identified risks or opportunities.
RSK 2.2 Monitor identified risks or opportunities and communicate status to
Level 3
RSK 3.1 Identify and use risk or opportunity categories.
RSK 3.2 Define and use parameters for risk or opportunity analysis and handling.
RSK 3.3 Develop and keep updated a risk or opportunity management strategy.
RSK 3.4 Develop and keep updated risk or opportunity management plans.
RSK 3.5 Manage risks or opportunities by implementing planned risk or
opportunity management activities.
Risk and opportunity management is a continuous, forward-looking process and includes:
• Identifying and mitigating potential negative impacts that may make it difficult to meet
objectives
• Identifying and leveraging potential positive impacts for improving performance or
progress towards achieving objectives
• All levels of an organization
426
Identify risks or opportunities early by working with affected stakeholders. Before dedicating
resources to address risks or opportunities, determine which are worth pursuing. During risk
and opportunity management, consider:
• Timeliness of the needed response
• Significance or consequences of the situation
• Regularity or chances of the situation occurring
• Internal, external, technical, and non-technical sources
• Early implementation of handling activities that may be less disruptive and costly
• Uncertainties that could most affect the ability to perform
• Industry standards and best practices that can help to identify and manage uncertainty
Risk and opportunity management involves:
• Defining a strategy
• Identifying and analyzing risks or opportunities
• Handling identified risks or opportunities includes:
o Developing mitigation and contingency plans for risks
o Developing plans to leverage opportunities
• Implementing risk or opportunity handling plans
Risk and opportunity management practices help organizations evolve from reactively
identifying uncertainties to systematically planning, anticipating, and handling them.
Planning (PLAN)
Context Specific
Figure RSK-1 states where risk and opportunity management activities can be performed in
an agile project using Scrum. Table RSK-1 shows a simple example of a risk and opportunity
log. Figure RSK-2 shows a risk burndown chart showing total risks decreasing and
opportunities increasing over time.
427
Figure RSK-1: RSK in an Agile Framework
Table RSK-1: Example Risk and Opportunity Log
428
Figure RSK-2: Example Risk Burndown Chart
As an empirical framework, agile with Scrum, does not define specific practices and processes
for risk and opportunity management. Risk and opportunity management is performed using of
visual information indicators, daily standups, short sprints (iterations) with frequent feedback,
and close collaboration within teams and customers. Some agile teams reduce technical risk by
using “spikes,” or rapid prototypes performed early in the project. Risk and opportunity
management can be easily added to the planning, execution, and retrospective activities of
each sprint, or selected sprints. During each activity, spend a few minutes updating the risk and
opportunity information like that shown in Table RSK-1 and Figure RSK-2.
429
Level 1
RSK 1.1
Practice Statement
Identify and record risks or opportunities and keep them updated.
Value
Enables organizations to avoid or minimize the impact of risks and leverage potential
opportunities related to achieving objectives.
Identify and describe risks or opportunities clearly.
Example Activities
Identify the risks associated with the Identify and clearly describe risks that could negatively affect
work. work and plans. Risk identification should consider:
• Cost
• Schedule
• Work tasks
• Performance
• Achievement of business objectives
• Environmental concerns, e.g., weather or natural
disasters, political changes, or telecommunications failures
• Requirements
• Technology
• Staffing
• Funding
• Suppliers
• Regulatory constraints
Perform risk identification and management during planning
and review activities.
Record the risks. State the risk and the impact of its occurrence.
Identify opportunities. Identify and clearly describe opportunities that could
positively affect work and plans. For example:
• Cost
• Schedule
• Work tasks
• Performance
• Achievement of business objectives
• Requirements
• Technology
430

• Staffing
• Funding
• Suppliers
Perform opportunity identification and management during
review and planning activities.
Record opportunities. State the opportunity and its potential benefits.
Identify the affected stakeholders
associated with each risk or
opportunity.

List of identified risks or opportunities Include context, conditions, and consequences of risks or
benefits of opportunities.
431
Level 2
RSK 2.1
Practice Statement
Analyze identified risks or opportunities.
Value
Increases the likelihood of achieving objectives by reducing the impact of risks or leveraging
opportunities.
Analysis of the risks includes potential impact, likelihood of occurrence, and the timeframe in
which they are likely to occur.
Analysis of opportunities includes potential benefits, potential costs, and the timeframe for
action.
The analysis of risks or opportunities should consider:
• Assigning mitigation or contingency to the highest priority or the most critical risks
• Leveraging opportunities by assigning the highest priority to those with the greatest
benefit
Example Activities
Analyze the identified risks. Analyze risks to understand their effect on achieving the
work’s objectives.
Examples of risk identification and analysis techniques
include:
• Assessments
• Checklists
• Structured interviews
• Brainstorming
• Failure Mode and Effects Analysis (FMEA)
• Failure Mode, Effects and Criticality Analysis (FMECA)
• Strength, Weakness, Opportunity, and Threat (SWOT)
analysis
• Poka-yoke analysis
Review the work breakdown structure,
plan, and schedule for risks.
Identify the impact of each risk.
Identify the probability of occurrence
for each risk.
432

Assign priorities to each risk based on
the impact and probability of
occurrence.
Analyze the identified opportunities. Examples of opportunity identification and analysis
techniques include:
• Assessments
• Checklists
Review the work breakdown structure,
plan, and schedule for opportunities.
Identify the benefits and costs of each
opportunity.
Assign priorities to each opportunity
based on the benefit and cost.
Rank opportunity according to
priorities.
Review assigned opportunity priorities
with affected stakeholders and get
agreement.
Develop the risk and opportunity Include a list of prioritized risks or opportunities.
analysis report.

Identified risks or opportunities These include:
• Risk impact and probability of occurrence
• Opportunity benefit and cost
Risk or opportunity priorities
Risk and opportunity analysis reports
RSK 2.2
Practice Statement
Monitor identified risks or opportunities and communicate status to affected stakeholders.
Value
Enables timely corrective or leveraging actions to maximize the likelihood of achieving
objectives.
433

Review risks or opportunities periodically, including changing conditions. Reexamination may
uncover risks or opportunities that were previously overlooked or that did not exist when the
identification and priorities were last updated.
Example Activities
Periodically review risks or Review risks or opportunities in the context of status,
opportunities. circumstance, and past or planned activities.
Update risks or opportunities as Risks or opportunities may be revised when:
additional information becomes • New risks or opportunities are identified
available. • Corrective or leveraging actions are taken
• Risks are retired
• Opportunities are accepted
• Circumstances change significantly
Communicate the risk or opportunity Examples of risk or opportunity status include a change in
status to affected stakeholders. the:
• Probability of occurrence
• Costs or benefits
• Priority
• Impact on objectives

Records of risk or opportunity
monitoring
Updated risks or opportunities
434
Level 3
RSK 3.1
Practice Statement
Identify and use risk or opportunity categories.
Value
Organizes risks or opportunities to focus attention on uncertainties that will impact the
achievement of objectives.
Include the name and a brief description for each category.
The use of categories helps provide structure and efficiency for risk or opportunity identification
and analysis.
Identify categories over time to uncover changing circumstances that affect the ability to meet
objectives. As the work progresses, identify additional categories of risks or opportunities.
Categorization organizes related risks or opportunities to support the efficient and effective use
of resources.
Example Activities
Identify risk or opportunity categories. Consider internal and external categories, such as:
• Work activities
• Types of processes used
• Types of resources used
• Types of solutions produced
• Regulations and laws
• Work management uncertainties, e.g., related to
contracts, budget, schedule, quality, resources
• Technical performance uncertainties, e.g., related to
quality characteristics, reliability
Organize risks or opportunities Related or equivalent risks or opportunities can be organized
according to defined categories. for efficient handling.

Categories list
Categorized risks or opportunities
435
RSK 3.2
Practice Statement
Define and use parameters for risk or opportunity analysis and handling.
Value
Identifying high priority risks or opportunities maximizes the likelihood of cost-effectively
achieving objectives.
Parameters include:
• Probability of occurrence
• Impact
• Expected outcomes
Use defined parameters to:
• Determine the severity of the risk
• Estimate the benefit of the opportunity
• Prioritize the actions required for planning
• Select the opportunities to pursue
Parameters for evaluating, categorizing, and prioritizing include:
• Probability, e.g., likelihood of occurrence
• Impact, e.g., consequence and severity of occurrence
• Thresholds to trigger actions
• Expected benefit from opportunity
• Expected cost of opportunity
Parameters are often used in combination when prioritizing risks or opportunities. For example:
• Set priorities by multiplying probability times impact
• Calculate an opportunity value by subtracting the expected cost from the expected
return.
Example Activities
Identify a relative priority for each risk
or opportunity based on assigned
parameters.
436

Define thresholds to trigger actions for Identify which thresholds require a:
selected risks or opportunities. • Mitigation activity
• Contingency plan
• Opportunity action plan
Prepare and perform assessments for Risk assessments focus the components of the risk strategy
selected risks. on analyzing a specific situation and risk. Examples of risk
assessments include:
• Exploitation
• Malicious uses
• Safety
• Regulations and laws
• Cyber security
Prepare and perform opportunity Examples of opportunity assessments include:
assessments. • Cost benefit analyses
• Future needs analyses

Risk or opportunity evaluation, categorization, and
prioritization parameters
List of risks or opportunities and their assigned priority
Risk or opportunity assessment results
RSK 3.3
Practice Statement
Develop and keep updated a risk or opportunity management strategy.
Value
A systematic approach for risk or opportunity management avoids problems and leverages
opportunities to increase the likelihood of achieving objectives.
A risk or opportunity management strategy includes:
• A description of how risk or opportunity management will be performed
• Scope
• Methods and tools
• Risk or opportunity categories
• Risk or opportunity parameters
437
• Thresholds
• Risk mitigation techniques
• Opportunity leveraging techniques
• Risk measures
• Opportunity measures, including:
o Costs
o Benefits
• Frequency of risk monitoring or reassessment
Develop the strategy early and record it in the organization’s or project’s risk or opportunity
management plan, and maintained throughout the project. The strategy is used to guide risk
and opportunity management activities. The strategy may be included as part of the project
plan.
The risk or opportunity management strategy may also include:
• The domain of interest
• Boundaries, inclusions, and exclusions
• Interactions, dependencies, and relationships between the solution or work and external
factors
• Methods to be used to derive:
o Risk or opportunity categories
o Impact and likelihood of occurrence
o Benefit and cost of the opportunity
o Acceptance criteria
• Conditions that initiate a review and potential update to the risk management strategy
Example Activities
Develop, record, and keep updated a risk
or opportunity management strategy.
Review the risk or opportunity Use the review to gather input to:
management strategy with affected • Improve the strategy
stakeholders. • Generate acceptance

Risk or opportunity management strategy
438
RSK 3.4
Practice Statement
Develop and keep updated risk or opportunity management plans.
Value
Minimizes the impact of risks and maximizes the benefits of opportunities for achieving
objectives.
Generate mitigation or contingency plans for selected risks. Mitigation plans describe how to
reduce the likelihood or impact of risks. Contingency plans deal with the impact of problems
that can occur despite mitigation attempts.
Options for mitigating risks include:
• Avoiding
• Controlling
• Transferring
• Monitoring
• Accepting
Options for leveraging opportunities include:
• Creating
• Exploiting
• Transferring
• Monitoring
• Enhancing
• Accepting
More than one approach to managing a risk or opportunity can be used.
Mitigation and contingency plans can include:
• Rationale
• Risk acceptance criteria
• Schedule or period of performance for each risk management activity
• Resource reserves to respond to disruptive events
439
• Lists of available backup equipment

• Backups to key staff
• Plans for testing emergency response systems
• Posted procedures for emergencies
• Distributed lists of key contacts and information resources for emergencies
• Actions to be taken
Generate leverage plans for selected high-priority opportunities. These plans describe how to
maximize the benefit of an opportunity.
Leveraging involves performing actions that maximize the benefits of an opportunity without
increasing the cost beyond the benefit. Typically, leveraging adds a relatively small amount of
cost while yielding a relatively high level of benefit.
Leveraging plans include:
• Cost benefit analyses
• Potential for success analyses
• Preparation activities
• Actions required to leverage opportunity
This activity can result in the discovery of new opportunities that can require re-planning and
reassessment.
Example Activities
Develop mitigation plans for selected risks and
contingency plans in the event their impacts are realized.
Develop leverage plans for selected opportunities to
increase the likelihood that their impacts are realized.
Review plans with affected stakeholders. Use the review to gather input to:
• Improve the plan
• Generate acceptance

Risk management plans Includes:
• Mitigation
• Contingencies
Opportunity leveraging plans
Updated plans and status

Planning (PLAN)
440
Context Specific
Supplier Management
Consider all risks in planning activities. Identify risks from multiple perspectives, e.g.,
acquisition, technical, management, operational, supplier agreement, industry, support, end
user. Consider applicable regulatory and statutory requirements, e.g., safety and security, while
identifying risks. As the work evolves, revise risks based on changed conditions.
There are many risks associated with acquiring solutions through suppliers, e.g., the stability of
the supplier, the ability to maintain sufficient insight into the progress of their work, the
supplier’s capability to meet solution requirements, and the skills and availability of supplier
resources to meet commitments.
Analyze the process and solution level measures and associated thresholds to identify where the
organization is at risk of not meeting thresholds. These measures are key indicators of risk.
RSK 3.5
Practice Statement
Manage risks or opportunities by implementing planned risk or opportunity management
activities.
Value
Effective risk management reduces unforeseen occurrences that impair ability to achieve
objectives and increases business value by leveraging opportunities.
This activity is more than simply monitoring risks and opportunities. It uses analyses, plans,
triggers, and thresholds to anticipate actions needed to minimize risk impact or leverage
opportunities to improve project functioning.
Example Activities
Manage risks or opportunities using the Continue to manage risks or opportunities after mitigation,
risk or opportunity management plans. contingency, or leveraging activities have started.
Measurement can provide valuable insight into the risk or
opportunity management activities.
441

Updated status Includes status of mitigation, contingency, and leveraging plans.
442
Intent
Deliver services and manage the service delivery system.
Value
Increase customer satisfaction by delivering services that meet or exceed customer
expectations.
This includes:
• Delivering services in accordance with service delivery approaches and agreements
• Managing changes to the service delivery system
• Receiving and processing service requests
• Maintaining service delivery performance when changes occur
Practice Summary
Level 1
SDM 1.1 Use the service system to deliver services.
Level 2
SDM 2.1 Develop, record, keep updated, and follow service agreements.
SDM 2.2 Receive and process service requests in accordance with service
agreements.
SDM 2.3 Deliver services in accordance with service agreements.
SDM 2.4 Analyze existing service agreements and service data to prepare for
updated or new agreements.
SDM 2.5 Develop, record, keep updated, and follow the approach for operating
and changing the service system.
SDM 2.6 Confirm the readiness of the service system to support the delivery of
services.
Level 3
SDM 3.1 Develop, record, keep updated, and use organizational standard service
systems and agreements.
443

Service delivery management includes defining and establishing the relationship between the
service provider and customers, including end users. This typically takes the form of a service
agreement, which describes the services provided.
A service agreement describes what a service provider will deliver to the customer, and
includes:
• Service level and availability targets
• Responsibilities of the service provider, customer, and end user based on their process
role
• Communications channels and feedback mechanisms
The delivery of services typically includes:
• Preparation
• Operation and monitoring
• Maintenance
• Enhancements
Deliver services using a service system. A service system can be as simple as receiving a
request and delivery of the service or it could be as complex as a multi-component automated
system managing multiple inputs and outputs.
Planning (PLAN)
Strategic Service Management (STSM)
444
Level 1
SDM 1.1
Practice Statement
Use the service system to deliver services.
Value
Improves customer satisfaction by delivering expected services.
Example Activities
Use a service system.
Deliver services.

Service system Components can include:
• List or menu of services with prices
• Customer requests
• Steps to fulfill requests
Records of delivered services
445
Level 2
SDM 2.1
Practice Statement
Develop, record, keep updated, and follow service agreements.
Value
Enhances customer satisfaction by aligning service delivery with their expectations.
The service agreement is a recorded arrangement and can be a contract or part of a contract or
a memorandum of agreement or understanding. For simple cases, it may be a printed menu of
services and prices.
Depending on the service type, market, and the nature of the service provider’s business,
develop the content in the agreement. The service agreement typically covers:
• Descriptions of services
• Commitments necessary for ongoing successful service delivery
• Warranty or guarantee information
• Communication channels
A service agreement can cover multiple services or multiple customers. Examples may include:
• Service Level Agreement (SLA)
• Performance Work Statement (PWS)
• Statement of Objectives (SOO)
• Statement of Work (SOW)
• Other types of agreements
Example Activities
Develop, record, and keep the Examples of structures to consider include:
structure and format of the • Service based: Organize the service agreement around a
service agreement updated. service, e.g., providing corporate email; this can cover several
different customers
• Customer based: Organize the service agreement around a
customer; this can cover several services for that customer
Define, negotiate, obtain
commitment to, and
446

communicate status of the
service agreement.
Provide the service agreement to Affected stakeholders may include:
affected stakeholders. • Service providers
• Customers
• End users
Review and revise the service Perform reviews on a periodic and event-driven basis.
agreement.

Service agreement Examples of additional items in a service agreement:
• Service types, levels, and measures
• Service availability
• Service acceptance and quality criteria
• Risk and contingency identification
• Service resources and constraints
• Intellectual property considerations
• Customer and end user roles and responsibilities
• Customer complaint procedures
• Customer-supplied resources
• Expected cost, payment, and funding schedules
• Security and safety considerations
• Legal and regulatory requirements
• Record of agreement with affected stakeholders and
customers
Records of service agreement reviews

SDM 2.2
Practice Statement
Receive and process service requests in accordance with service agreements.
Value
Enhances service delivery to better meet customer expectations.
Coordinate the receipt and processing of service requests through a request management
approach.
447

Customers can submit service requests through various methods, e.g., web forms, phone calls.
Service agreements may identify requests for continuous or repeatedly scheduled services.
When customers or end users identify a need for a service, they submit a service request.
Either the customer or the service provider can determine the initial type of service request.
Types may include:
• Simple service level-based requests
• Continuous or scheduled requests typically specified in service agreements
• Ad-hoc requests identified over time by customers or end users as their needs change
Record, track, and resolve service request through a request management system. This ensures
the fulfillment of all service requests to meet service agreements.
Examples of simple service requests include:
• A menu or catalog with prices and delivery options
• A phone call with automated options
Examples of continuous service requests include:
• Weekly scheduled services, e.g., lawn, laundry, cleaning, maintenance
• A call center with continuous operations and support requirements
Examples of ad-hoc requests include:
• Requesting a custom-made query on a database as part of a service system
• Calling for a package pick up as part of a package delivery service
• Identifying a broken component of a maintained system as part of a maintenance
service
• Requesting a health check as part of a health program
Example Activities
Receive service requests and ensure
each request is within the scope of the
service agreement.
Record information about the service Sources of service request information may include:
request. • Standard changes
• Service system operations
• Queries
• Complaints
• Feedback
Determine resources required to Which individuals, groups, and other resources are best
address the service request. suited can depend on the type of service request, locations
involved, and effect on the organization or customer.
448

Determine the actions to satisfy the Using the categories developed in the approach to service
service request. delivery, determine the appropriate actions to perform. In
some cases, the categories themselves can have pre-
determined actions associated with them.
Examples of actions include:
• Answering a customer inquiry
• Addressing a service defect
• Repairing items (as part of a maintenance service)
• Training an end user
• Providing new consumables or tools
Monitor the status of service requests Record, track, transfer as necessary, and close the request
until personnel fulfill requests status.
described in the service agreement.
Review service request status and In organizations that use a help desk function, the help desk
confirm results with affected communicates the status of service requests.
stakeholders.
Close the service request and record Record actions to support satisfying similar service requests
the actions taken and results. in the future.
Collect customer satisfaction
information after delivery of services.

Service requests Examples of service request information include:
• Name and contact information of the person submitting
the service request
• Description of the service request, including changes
• Service request categories
• Date and time of the service request
• Affected services and components
• Priority
Action proposal
Customer satisfaction data
End user receipts confirming request
fulfillment
Customer satisfaction data
Records of affected stakeholder
reviews

449
SDM 2.3
Practice Statement
Deliver services in accordance with service agreements.
Value
Increases customer satisfaction by establishing a common understanding of the types and
levels of service delivery.
Using service agreements to delivery services encompasses the activities necessary to deliver
services based on the agreed-upon service delivery approach. Use a request management
system to meet service agreements, and to track and resolve service requests more effectively.
Example Activities
Operate service system components
according to service system
procedures.
Perform operations support activities. These activities can include providing customer and end user
training or orientation as needed.
Perform the activities needed to fulfill
service requests.
Use a request management system to The service provider records and tracks status until they
record service requests. close the request.
Escalate service delivery issues when necessary.

List of services provided Often takes the form of a service log.
Performance reports and dashboards
Log of corrective actions
Request management system This may a be a database, web-based, or application-based
system, or a simple list or set of paper records.
Request management system records

450
SDM 2.4
Practice Statement
Analyze existing service agreements and service data to prepare for updated or new
agreements.
Value
Aligns service delivery capability and customer expectations as they change over time.
Perform analysis on a recurring or as-needed basis throughout the life of a service agreement.
Analysis can cover many aspects of the service system, requests, and service agreements.
Analysis may include reviews of:
• Customer needs
• Customer complaints
• Service provider concerns
• Service definitions
• Capacity and availability data
• Performance data
• Service levels
• Supplier constraints
• Service agreements
• Service request records
• Resource usage
Example Activities
Collect customer and end user needs Sources include:
and service provider concerns. • Customer and end user feedback
• Service provider inputs
• Historical data
• Market analysis and demand
• SOW and related solicitation materials
• Support process information
• Service system
451

Analyze service requests. For more complex service requests, it may be necessary to
assemble a special team to analyze the request.
Examples of complex service requests include:
• The request has a high and broad effect on the
organization or customer
• The cost of addressing the service requests exceeds pre-
defined limits
• Addressing a service request will take considerable time or
effort
Review and analyze existing service This typically includes reviewing:
agreements, request management • Requested service requirements against standard service
data, supplier agreements, and related definitions
service data. • Existing service level agreements and supplier agreements
for their ability to meet identified service requirements
• Historical service data including:
o Capacity and availability
o Available resources
o Performance data
o Request data
o Delivered service levels
o Incidents and resolutions
• Available industry benchmarks or other published data for
new service requirements

Service data analysis results May include:
• Recommendations of whether to update or provide new
services
• Assessment results determining provider capability to
meet customer needs
Information for updating or developing
new service agreements or request
management approaches

Supplier Agreement Management (SAM)
452
SDM 2.5
Practice Statement
Develop, record, keep updated, and follow the approach for operating and changing the service
system.
Value
Increases the likelihood that services and changes to them will meet customer expectations.
For each specific change of the service system, develop an approach that encompasses
activities from developing and accepting service system components to operating the system
and resolving impacts on end users and the delivery environment. This approach should identify
activities and resources required for operating and changing the system.
As needed, include:
• Identification of service system components ready for operations
• Identification of changes to service system components, including the request
management system
• Deployment type, e.g., new, replacement, retirement
• Acquisition approach
• Request management system components
• Installation and integration of service system components
• Identification and resolution of warranty considerations
• Phasing of deployment over time that satisfies operational dependencies between
service system components
• Deployment acceptance criteria
• Resource constraints and restrictions
• Initial provisioning of consumables
• Rollback (or backout) procedures to “undo” the change and restore the delivery
environment to its former stable operating status
• Training of service delivery and support personnel
• Communication of status and service changes to affected stakeholders
The depth of the approach should be appropriate for the type of change and the criticality of
the components going through transition. For example, the transition of new business critical
components can require detailed plans and schedules, risk assessment, deployment backout
procedures, and a formal review of planning materials by affected stakeholders. Less significant
453
transitions, such as retirement of an outdated service, may require less detailed planning.
Consider the results of their post-deployment reviews during transition planning for changes
made in the past. This information can speed up the planning process and help identify and
avoid recurring issues.
Example Activities
Define the approach for Consider the type of change, e.g., new installation, replacement,
service system operation retirement, or a combination of types, when defining an approach.
and each change. Consider priorities and constraints of affected stakeholders.
Define a rollback or backout strategy to restore the service system to its
former state if a deployment is unsuccessful. Include criteria for what
constitutes a successful deployment versus when to back out changes.
If a service system is being retired, address topics such as end user
notification, error handling, archival methods, demolition, and recycling.
Determine the cost, Schedule service system change activities in a way that balances work
resources, and schedule and available resources against customer and end user needs, including
required for operation of the need to have time to prepare for and conduct the change. When
the service system and for appropriate, use actual data from similar changes to estimate cost,
a new change. resources, and schedule.
Identify affected When identifying affected stakeholders and defining their roles and
stakeholders and review responsibilities, consider outsourced stakeholders.
operations and change
activities.
Develop a plan for service Based on the operations, change, and deployment approach and
system operations and for estimates for a transition, record a plan for operations and changes to
changes to operations. the service system.
Update the service
continuity plan, if a change
affects an essential
function.

Service system operations and change approach
Plans for service system operations and changes
Records of reviews with affected stakeholders

Continuity (CONT)
Planning (PLAN)
454
SDM 2.6
Practice Statement
Confirm the readiness of the service system to support the delivery of services.
Value
Improves customer satisfaction by ensuring the readiness of the service system for operation.
Confirming the readiness for service delivery is not a one-time event. Perform these activities
repeatedly, even when the service system is not changing. Consider implications of service
system changes on readiness. For example, changes of the service system may require
additional resources, procedures, user guide updates, or training.
Example Activities
Confirm that service system Service system components may include:
components and tools are operational. • Tools
• Consumables
• People
• Processes and procedures
Examples of service system tools that support operations
may include:
• Monitoring tools
• System management tools
• Tracking systems
• Presentation tools
• Log files
• Analysis tools
• Online knowledge management tools
• Virus scanning tools
• Database management tools
Evaluate the results of confirming The service provider may treat deficiencies or issues as
service system component readiness service incidents and address them through the incident
and determine how to address handling process.
deficiencies or issues.
Review the service level requirements
in the service agreements and set
thresholds in service system
monitoring tools.
Develop, review, or refine service The service provider should regularly review, tailor, and
delivery procedures. possibly supplement procedures to meet ongoing service
455

delivery needs. Changes of service system components, e.g.,
archival, incorporation of new components, often require
updates to procedures.
Ensure that the necessary resources Service delivery activities and tasks can include:
are available for performing service • Operating, monitoring, and repairing service system
delivery activities and tasks. components
• Supporting users of the service system
• Acquiring and replacing service system components
Prepare and update plans and These plans and schedules typically include:
schedules for delivering services as • Detailed job execution tasks for service delivery personnel
requested. • Due dates and time frames for delivery
• Service delivery monitoring tasks
• Tasks specific to transition activities, e.g., backing up data
Review the service system approach,
plan, and procedures as appropriate
with affect stakeholders.
Provide orientation or training to Orient incoming personnel, e.g., new hires, at a shift change,
incoming service delivery and support on the current state of operations and pending transition
personnel. activities to ensure uninterrupted service.

Readiness reports These reports may include:
• Monitoring thresholds
• Operating procedures
• Personnel
• Consumables
Logs of consumable acquisition and use
Plans and schedules for delivering services
Service delivery logs and receipts
Service system orientation or training records
Stakeholder review records
Results from demonstrated service system operation

456
Level 3
SDM 3.1
Practice Statement
Develop, record, keep updated, and use organizational standard service systems and
agreements.
Value
Maximizes the availability and consistency of the service system to meet customer needs
efficiently and effectively.
To provide broader and more scalable services, organizations use standardized approaches to
service systems, service agreements, and their maintenance. Maintenance types include:
• Corrective maintenance, e.g., correcting and repairing components that degrade the
operational capability of the service system
• Preventive maintenance, e.g., preventing service incidents and defects from occurring
through pre-planned activities
• Adaptive maintenance, e.g., adapting the service system to a changing or different
service delivery environment
• Perfective maintenance, e.g., developing or acquiring additional or improved operational
capability of the service system
Apply standardization and the resulting maintenance to any portion of a service system, on
service agreements, request management systems, and their components, including
consumables, processes, software, hardware, infrastructure, and people.
For service system components where maintenance and availability depends on a third party
vendor, include such items as:
• Cloud-based databases
• Customer relationship management components
• Ticket management components
Additionally, maintenance activities may include renewing service contracts, identifying and
dealing with maintenance windows, and identifying and notifying affected stakeholders about
vendor disruptions.
457
Example Activities
Review and prioritize standardization
and maintenance needs and requests.
Analyze effect of standardization and
maintenance on service delivery.
Develop an approach or process to
standardize or maintain service
agreements, service systems, or their
components.
Communicate changes and
notifications to affected stakeholders.
Update and retain service system
documentation as appropriate.

Approach or process for standardized
service agreements and service
systems
Corrective or preventive maintenance
change requests
Maintenance notifications
Preventive maintenance schedules
Installation records
Deployment artifacts
Records of stakeholders
Updated service system and service
agreement documentation

458
Intent
Develop and deploy standard services that are compatible with strategic business needs and
plans.
Value
Increases likelihood of meeting business objectives by aligning standard services with customer
needs.
Practice Summary
Level 1
STSM 1.1 Develop a list of current services.
Level 2
STSM 2.1 Develop, keep updated, and use descriptions of current services.
STSM 2.2 Collect, record, and analyze data about strategic needs and capabilities
for service delivery.
STSM 2.3 Develop, keep updated, and follow an approach for providing new or
changed services derived from strategic needs and capabilities.
Level 3
STSM 3.1 Develop, keep updated, and use the set of organizational standard
services and service levels.
The management of strategic services involves:
• Analyzing capabilities and needs for services that can span multiple customers and
agreements
• Developing and keeping updated standard services, service levels, and descriptions
that reflect these capabilities and needs
Strategic service management processes improve alignment between the set of standard
services offered by an organization and its strategic business objectives.
Develop standard services through:
• Active analysis of customer and competitor data
459
• Analysis of market trends and opportunities

• Understanding service provider capabilities, strengths, and weaknesses
The objective is to get the information needed to make effective strategic decisions about the
set of standard services that the organization offers and maintains. Standard services provide a
basis for ensuring that a service provider’s capabilities meet their business objectives. Standard
services improve service quality, opportunity development, and customer and end user
satisfaction. Standard service levels are a key component of standard services. Service levels
make expectations and responsibilities clear, specific, and measurable between the service
provider and the customer while reducing costs, errors, and time to develop and deliver
services.
Service providers typically describe standard services in a service catalog oriented to the
information needs of customers. Service providers should also maintain standard service
descriptions oriented to their needs.
While customer and end user needs may differ, both are critical when collecting and analyzing
data to develop standard services and understand strategic needs and plans. Focusing on these
needs and the use of current services, service providers identify requirements to improve
existing services and plan for future services.
460
Level 1
STSM 1.1
Practice Statement
Develop a list of current services.
Value
Aligns offered services with customer and stakeholder needs and expectations.
Example Activities
Identify current services.

List of current services
461
Level 2
STSM 2.1
Practice Statement
Develop, keep updated, and use descriptions of current services.
Value
Enables consistent service delivery that aligns with customer needs.
List service descriptions in a catalog or menu accessible to users. Descriptions can be a simple
list or part of a complex online repository, depending on the characteristics of the services and
project.
Develop additional materials related to the services as needed. These materials associated with
the service catalog and descriptions may include:
• Delivery instructions
• Marketing and sales materials
• Pricing options
• Delivery methods
Example Activities
Develop, record, and keep individual These are based on the current list of available services.
service descriptions updated.
Develop, record, and keep the service The service catalog contains all the individual service
catalog updated. descriptions and related material.

Individual service descriptions
Service catalog or menu

462
STSM 2.2
Practice Statement
Collect, record, and analyze data about strategic needs and capabilities for service delivery.
Value
Identifies which needs and objectives have the greatest effect on increasing customer
satisfaction.
Strategic needs are driven by internal and external business and related factors. For example:
• Customers may need different or new services
• Competitive offerings may change customers’ expectations
• Current services may become obsolete based on customer needs
• The organization may need to attract new customers
Consider the full range of needs and select which ones will be used to develop strategic
business objectives. Collect, analyze, and use data related to these objectives to help plan for
the services to develop and update. This data may vary for different services, market segments,
and individual customers. Examples of relevant data sources include:
• Business plans
• Market research
• Surveys
• Business intelligence
• Data from service reviews and account management
• Service use trends and patterns
• Customer complaints and compliments
• Service incident and request patterns
• Breaches of service levels
• Competitor data
• Trade studies
• Plans
• Strategic planning techniques, e.g., Strengths, Weaknesses, Opportunities, and Threats
(SWOT) analysis
• Core competence analysis
463
• Scenario planning
Example Activities
Collect and analyze data on Include capabilities of:
capabilities. • The projects or organizations offering the services
• Customers and end users
• Systems and processes used to provide services
• Competitors
Collect and analyze data on strategic Include external and internal factors.
needs.
Communicate the capabilities and
strategic needs to affected
stakeholders.

Analysis results Include:
• Capabilities
• Strategic needs
Descriptions of the capabilities Detail capabilities in terms of characteristics such as:
• Skills
• Abilities
• People
• Resources
• Tools needed
Descriptions of strategic needs
STSM 2.3
Practice Statement
Develop, keep updated, and follow an approach for providing new or changed services derived
from strategic needs and capabilities.
Value
Focuses resources on identifying services that best anticipate and meet market needs.
The approach includes plans for new or changed services. These plans typically include:
• How customer and end user needs and requirements will be met
• Actions needed to balance capabilities and resources
• External service supplier requirements
464

Example Activities
Develop, record, and confirm Senior management should articulate, review, and approve
strategic business objectives. strategic objectives.
Identify requirements for services
based on strategic business needs,
objectives, and capabilities.
Record descriptions of services This may include details about:
provided or changed. • Components
• Resources
• Service level ranges
Identify changes to services These changes can include:
offered. • Developing new services
• Revising or improving current services to fit evolving or future
needs
• Retiring services that no longer fit the needs of customers or
current capabilities
Set priorities and decide which actions to take.
New or changed services may require new or changed service
systems.
Develop, keep updated, and follow
plans for new or changed services.
Verify that planned services are Analyze the provided services and ensure that they address the
available when needed. following factors:
• Availability of personnel needed to provide the service
• Required skills and experience of personnel
• Capacity of available personnel to produce the expected
quality of work
• Ability of personnel to meet deadlines

Descriptions of strategic business objectives
Service descriptions
Analysis of service system needs
Plans for services
Plan verification results

Governance (GOV)
465
Planning (PLAN)
466
Level 3
STSM 3.1
Practice Statement
Develop, keep updated, and use the set of organizational standard services and service levels.
Value
Minimizes cost and achieves faster time to market for new or changed services.
Develop process descriptions for the standard services and include the needs of service
providers and customers. These descriptions become part of the organization’s standard service
catalog. Standard service descriptions typically include service levels.
The organization develops standard services and associated processes to ensure standard
delivery across projects, customers, service lines, and domains.
If needed, use multiple standard services and service levels to address the needs of:
• Different customers
• Organizational groups
• Markets
• Application domains
Example Activities
Develop, record, and keep updated Follow organizational policies, standards, and models.
standard service descriptions. Organize services into service lines as needed to ensure
appropriate integration among services.
Specify the characteristics of each service. These may include definitions of standard service levels.

Descriptions of services and their Critical characteristics typically include:
characteristics • Features and benefits
• Available service levels and categories
• Capacity and availability requirements
• Costs
• Descriptions of current and intended users
• Service components
• Service delivery systems
• Related services
• List of needed service delivery materials
467

Standard service catalog or menu The catalog typically contains tailoring guidelines for
standard services and descriptions of services lines if
needed.

468
Intent
Establish an agreement with selected suppliers, ensure that the supplier and the acquirer
perform according to the terms over the course of the agreement, and evaluate the supplier’s
deliverables.
Value
Provides an explicit understanding between the acquirer and supplier to maximize the success
of agreed-on efforts to deliver a supplier deliverable.
The term “supplier deliverable” is an item to be provided to an acquirer or other recipient as
specified in an agreement. The item can be a document, hardware or software item, a service,
or any type of solution or work product.
Practice Summary
Level 1
SAM 1.1 Develop and record the supplier agreement.
SAM 1.2 Accept or reject the supplier deliverables.
SAM 1.3 Process supplier invoices.
Level 2
SAM 2.1 Monitor supplier as specified in the supplier agreement and keep
agreement updated.
SAM 2.2 Perform activities as specified in the supplier agreement.
SAM 2.3 Verify that the supplier agreement is satisfied before accepting the
acquired supplier deliverable.
SAM 2.4 Manage invoices submitted by the supplier according to the supplier
agreements.
Level 3
SAM 3.1 Select technical supplier deliverables for analysis and conduct technical
reviews.
SAM 3.2 Select and monitor supplier processes and deliverables based on criteria
in the supplier agreement.
Level 4
469
SAM 4.1 Select measures and apply analytical techniques to quantitatively manage
supplier performance to achieve quality and process performance
objectives.
Supplier management activities involve:
• Establishing the supplier agreement
• Implementing the supplier agreement
• Monitoring supplier technical activities
• Monitoring supplier processes
• Accepting the delivery of acquired products
• Managing supplier invoices
The supplier agreement provides a mutual understanding between the acquirer and supplier
and serves as the basis for managing their relationship. The agreement defines the processes,
roles, and responsibilities that allow the acquirer to:
• Oversee the supplier’s activities
• Monitor evolving supplier deliverables
• Verify compliance with supplier agreement requirements
• Resolve issues as necessary
When the supplier’s performance, processes, or supplier deliverables fail to satisfy established
criteria as outlined in the supplier agreement, the acquirer takes corrective action. The
acquirer’s management team must be aware of the legal implications of actions when managing
the acquisition of supplier deliverables.
When monitoring supplier technical activities, the acquirer:
• Performs technical reviews of the supplier’s technical supplier deliverable
• Analyzes the development and implementation of the supplier’s technical supplier
deliverable to confirm technical progress and satisfaction of contractual requirements
Typically, these activities interactively support one another to gauge technical progress and
allow effective management of technical risks. Perform different levels of detailed analysis for
technical reviews to meet the acquirer’s requirements. Technical reviews with the supplier
involve measuring technical progress and the effectiveness of plans and requirements.
Technical reviews of the supplier should be performed with other processes, such as
requirements management, risk management, configuration management, and data
management.
In some acquisitions, the acquirer assumes the role of overall architect or integrator for the
supplier deliverable.
The acquirer also needs to be involved to ensure that needed changes to requirements and
supplier agreements are acceptable given the constraints of the acquisition, and to incorporate
the changes into the supplier agreements.
470

Supplier Source Selection (SSS)
471
Level 1
SAM 1.1
Practice Statement
Develop and record the supplier agreement.
Value
Increases likelihood of meeting requirements when using suppliers.
A supplier agreement is any recorded agreement between the acquirer and the supplier.
Agreements can take a variety of forms, and may include:
• Contracts (or subcontract)
• Licenses
• Service agreements
• Service level agreements
• Memoranda of agreement
• Memoranda of understanding
• Letters of understanding
• Electronic acknowledgements of terms and conditions
• A combination of any of the above or other similar forms
The agreement can be either a stand-alone agreement or part of a master agreement. When
part of a master agreement, the work agreement can be an addendum, work order, or service
request to the master agreement.
Example Activities
Develop and record a supplier
agreement.
Negotiate the terms of the candidate Negotiation may require updates to the supplier agreement.
agreement with the supplier.
Reach agreement with supplier.

Supplier Agreement May include:
472

• Affected stakeholders and communication involved
• Statement Of Work
• Specifications
• List of deliverables
• Schedule
• Budget
• Legal or regulatory information
SAM 1.2
Practice Statement
Accept or reject the supplier deliverables.
Value
Increases the likelihood the supplier provides the agreed-on supplier deliverable.
The acquirer should ensure that the acquired supplier deliverable meets all agreed-on
contractual requirements. The acquirer then decides whether to accept or reject the supplier
deliverable.
Example Activities
Accept or reject the supplier
deliverable based on the extent that
the agreed-on supplier deliverable
meets contractual requirements.

Deliverables per the supplier
agreement
473
SAM 1.3
Practice Statement
Process supplier invoices.
Value
Maintains a good working relationship with suppliers while meeting agreements.
Processing supplier invoices may include:
• Paying the invoice, e.g., check, money order, credit card, electronic transfer of funds to
supplier
• Trading goods or services
• Rejecting the invoice for revision
• Acknowledging the agreement has been met
A specific function, e.g., contracting office, accounts payable, or purchasing department, may
process invoices.
Example Activities
Process supplier invoices in accordance
with agreements.

Records of supplier invoices
474
Level 2
SAM 2.1
Practice Statement
Monitor supplier as specified in the supplier agreement and keep agreement updated.
Value
Improves the likelihood that the supplier provides the right supplier deliverable.
Monitor and update the supplier agreement based on the supplier selection decision and based
on actual results.
The acquirer, supplier, and affected stakeholders should review agreement requirements to
ensure that a common understanding is kept up-to-date through the life of the agreement.
After establishing the supplier agreement, requirements may change, based on factors such as:
• Applicability of requirements
• Availability of new technology
• Reduction of overly burdensome reporting
• Organization changes, e.g., merger or acquisition
• Legal or regulatory changes
The supplier agreement and work documents should be revised to reflect changes in conditions.
This includes updating cost, schedule, and budget as needed. Legal or contract advisors often
are responsible for reviewing supplier agreements among independent legal entities prior to
approval.
The content of the supplier agreement should specify how the agreement will be monitored and
revised as required. This should be done in a way that is appropriate to the acquisition or
supplier deliverable being acquired.
Example Activities
Record the supplier agreement and This typically includes:
keep it updated. • Recording all changes formally approved by both the
acquirer and supplier
• Developing, recording, and keeping the requirements
updated, e.g., supplier deliverable requirements, service
level agreements
475

• Periodically reviewing the supplier agreement to ensure it
accurately reflects current plans, processes, risks, and
market conditions
• Ensuring that the agreement, and data related to it, are
stored and managed for future use
• Performing impact assessments across technical and
commercial aspects of the agreement
• Assessing all alternatives associated with the change
Verify that the acquirer and supplier Approval may take different forms, such as:
understand and agree to all • Signature
requirements by approving the • Electronic approval or acknowledgement
supplier agreement. • Stamp or record of corporate/company approval
• Other legally-binding acceptance
Communicate the supplier Ensure that all affected stakeholders are aware of the
agreement within the acquiring agreement.
organization as required.

Supplier agreement May include:
• A description of required reporting data to allow the acquirer
to evaluate and analyze acquired supplier deliverables
• The acquirer and supplier representatives who are
responsible and authorized to make changes to the supplier
agreement
• Planned reviews and interactions between the acquirer and
supplier
• The mechanism for how changes to the requirements and
the supplier agreement are determined, communicated, and
addressed
• Applicable standards, procedures, tools, and methods
• Critical dependencies between the acquirer and supplier
• A list of what the acquirer provides to the supplier,
e.g., facilities, access, tools, software, documentation,
services
• Analysis methods and acceptance criteria for designated
supplier deliverables
• The types of reviews to be conducted with the supplier
• Payment or compensation terms and conditions
• Non-hire and non-compete clauses
• Confidentiality, non-disclosure, and intellectual capital
clauses
• The supplier’s responsibilities for preparing the site and
providing training
• The supplier’s responsibilities for ongoing maintenance and
support of acquired supplier deliverables
476

Records of communication and May include:
interactions between the acquirer • Issue and action item list
and supplier • Meeting minutes
• People assigned corrective actions
• Due date for actions

SAM 2.2
Practice Statement
Perform activities as specified in the supplier agreement.
Value
Improves the acquirer’s confidence in the ability of the supplier to deliver the right supplier
deliverable with the right quality.
The acquirer monitors the supplier’s progress against the agreement to identify and resolve
issues. Monitoring includes internal and external communication as well as the use of
information by the acquirer and supplier regarding the relationship, performance, results, and
impact to the business. Agreement, management, technical, and other reviews may be
conducted together or separately.
Example Activities
Monitor supplier progress and Monitoring can be conducted during agreement, technical,
performance, e.g., schedule, effort, and management reviews. Reviews can include both planned
cost, technical, as defined in the and as-needed interactions.
supplier agreement. Reviews cover both formal and informal reviews and include
the following steps:
• Preparing for the review
• Ensuring that affected stakeholders participate
• Conducting the review
• Preparing, distributing, or making a summary report
available to the affected stakeholders
477

• Identifying issues and determining corrective actions
necessary to resolve and track the issues to closure
• Monitoring risks involving the supplier and mitigating them
as necessary
Conduct agreement reviews with the May include:
supplier as specified in the supplier • Agreement changes or updates
agreement. • Stakeholder reassignment
• Interpretation and clarification of terms, conditions, and
deliverables
• Positive or negative feedback on contractual requirements
Conduct technical reviews with the Technical reviews typically include:
supplier as defined in the supplier • Providing the supplier with visibility into the needs and
agreement. preferences of the customers and end users as
appropriate
• Reviewing the supplier’s technical activities and verifying
that the supplier’s interpretation and implementation of
the requirements are consistent with the acquirer’s
interpretation
• Ensuring that technical commitments are being met and
that technical issues are communicated and resolved in a
timely manner
• Obtaining technical information about the supplier’s
deliverables
• Providing appropriate technical information and support to
the supplier
Conduct management reviews with the This typically includes reviewing:
supplier as specified in the supplier • Critical dependencies
agreement. • Risks involving the supplier
• Schedule and budget
• The supplier’s compliance with legal and regulatory
requirements
Unresolved issues escalate through the appropriate
management chain according to a project’s or organization’s
issue resolution process.
Record results of the reviews and Use the results of reviews to improve the supplier’s
interactions. performance and to establish and nurture long-term
relationships with preferred suppliers.

Agreement updates, progress reports May include:
• Issue and action item list
• Meeting minutes
478

Supplier progress and performance
reports
Issue, risk, and action item lists May include:
• Description of risk, issues, or action items
Records of the submission and
acceptance of the supplier deliverable
and other deliverables

Planning (PLAN)
SAM 2.3
Practice Statement
Verify that the supplier agreement is satisfied before accepting the acquired supplier
deliverable.
Value
Decreases risk of accepting an unsatisfactory supplier deliverable and ensures the supplier
agreement is satisfied before acceptance.
The acquirer ensures that all recorded acceptance criteria have been satisfied and all issues
affecting satisfaction of the agreement have been addressed. Requirements for deliverable
acceptance and how to address non-conforming deliverables are usually defined in the supplier
agreement. The acquirer should be prepared to take appropriate action as per the agreement if
the supplier fails to perform. This may include invoking any contractual penalties or conditions.
The acquirer provides the supplier with notice that supplier deliverables have been accepted or
rejected.
Typically, an authorized representative of the acquirer assumes ownership of identified supplier
deliverables as partial or complete satisfaction of the supplier agreement.
479
Acceptance reviews should be completed before accepting the supplier deliverables as defined
in the supplier agreement. Once accepted, the acquirer monitors the transition of the supplier
deliverables to the project or operations.
Example Activities
Refine, update or add, and use This activity is typically performed by the acquirer on the
acceptance criteria and procedures to supplier deliverables.
verify that the supplier agreement is
satisfied.
Review and obtain agreement from
affected stakeholders on the
acceptance procedures before the
acceptance review.
Following acceptance criteria and From the supplier, this may include review of supplier
procedures, verify that the acquired deliverable verification results, including:
supplier deliverable satisfies the • Reports, logs, and issues
supplier agreement. • Testing results
• Known errors or defects
For the acquirer, this may include reviewing results of
supplier-performed acceptance reviews and tests.
Confirm that all agreed-on contractual May include the following items that demonstrate that the
requirements for the acquired supplier agreed-on requirements have been met:
deliverable are satisfied. • License
• Warranty
• Ownership
• Usage
• Support, service, or maintenance agreements
• Other supporting materials, e.g., end-use, operations or
support, and maintenance documentation
Communicate to affected stakeholders The acquirer provides the supplier with notice that the
that the supplier agreement has been supplier agreement has been satisfied, including readiness
satisfied. for transition to operations and support, so the supplier can
be paid, and the supplier agreement closed.

Acceptance procedures
Discrepancy reports or corrective
action plans
Acceptance review report with
recorded approval
Formal acceptance notifications Notifications should be communicated to the supplier and
A record that all agreement Approval may take different forms, such as through:
requirements have been met • Signature
480

• Electronic approval or acknowledgement
• Stamp or record of corporate/company approval
• Other legally-binding acceptance

Planning (PLAN)
SAM 2.4
Practice Statement
Manage invoices submitted by the supplier according to the supplier agreements.
Value
Maintains a good business relationship between the acquirer and supplier.
Ensure that payment terms defined in the supplier agreement are met and that processing of
supplier compensation is linked to supplier progress and results, as defined in the supplier
agreement. This practice covers invoices for any type of charge, e.g., one-time, monthly,
deliverable-based, pass-through. It covers invoice errors or issues, changes to invoices, and
withholding disputed charges consistent with the terms and conditions of the supplier
agreement. The acquirer should also ensure that appropriate financial and invoice management
controls are in place.
When accepting supplier deliverables, the acquirer should not process final payment to the
supplier until all supplier deliverables meet contractual requirements and all acceptance criteria
have been satisfied.
Example Activities
Receive invoices.
Review invoices and related supporting Examples of areas of review for invoices and related support
material with authorized material include:
representatives for accuracy. • Variable charges
• Applicable taxes
• Purchases made by the supplier on behalf of the acquirer
481

• Formal acceptance signoff from receiving project team or
authorized representative
Resolve errors and manage issues with
the supplier as required.
Approve and pay invoices.
Archive and store invoices and
payment records.

Invoices approved for payment
Record or receipt of payment Payment per the supplier agreement, e.g., check, money
order, credit card, electronic transfer of funds to supplier
Archived invoice and payment records
482
Level 3
SAM 3.1
Practice Statement
Select technical supplier deliverables for analysis and conduct technical reviews.
Value
Improves the acquirer’s confidence in the ability of the supplier to provide the right supplier
deliverable at the right time with the right quality.
This requires that organizational standards and processes are in place and followed.
Technical reviews are used by the acquirer to confirm that supplier deliverables being
developed or produced by suppliers meet requirements.
Technical reviews are conducted:
• When the technical supplier deliverable under development meets the criteria specified
in the supplier agreement
• At the transition from one acquisition phase to the next and at major transition points
of technical effort
The supplier is responsible for managing the requirements and interfaces or connections of the
supplier deliverable it is developing. However, the acquirer identifies interfaces or connections
that it manages as well, particularly external interfaces or connections.
The interfaces or connections being considered for selection should include other supplier
deliverables in the operations, support, verification, and validation environments. The acquirer
should review all supplier interface or connection data for completeness.
In addition to interfaces or connections, the acquirer should consider the following criteria when
selecting supplier deliverables for analysis and review:
• Performance
• Recovery
• Safety
• Security
• Mean Time to Failure (MTTF)
• Mean Time Between Failure (MTBF)
• Maintainability
• Serviceability
• Updateability
483
• Modularity
Example Activities
Develop criteria for determining which
technical supplier deliverable to
analyze.
Identify technical supplier deliverables Technical supplier deliverables that are typically analyzed by
for analysis. the acquirer may include:
• Supplier derived deliverable and component requirements,
architectures, and designs
• Deliverable interface or connection descriptions
• Deliverables and deliverable components
Identify the functional and quality A traceability matrix is a useful tool for identifying
attribute requirements to be satisfied requirements for each selected technical solution, as it
by each selected technical supplier typically includes information that relates requirements to
deliverable. work products. When identifying requirements for each
selected technical supplier deliverable, consult the
appropriate traceability matrix.
Identify the analysis methods to be Examples of techniques used for analysis include:
used for each selected technical • Simulations
supplier deliverable. • Prototyping
• Architecture evaluation
• Demonstrations
• Peer Reviews
Include analysis methods and review
activities in the work plan.
Confirm that the selected technical
supplier deliverable adheres to
applicable standards and criteria.
Confirm that the selected technical
supplier deliverable adheres to
allocated functional and quality
attribute requirements.
Use analysis results to compare actual
performance measurements to
specified thresholds of technical
performance measures.
Review critical verification results and
data from verifications performed by
the supplier.
Identify interfaces or connections that Example criteria for interfaces or connections include:
are candidates for acquirer • Spans organizational boundaries
management. • Mission critical
• Difficult or complex to manage
• Key quality attributes
• Multiple acquisition projects
484

Review identified interfaces or
connections against the selection
criteria and include in the work plan.
Confirm the compatibility of selected Confirm that interface or connection descriptions adhere to
interfaces or connections throughout applicable standards, criteria, and connection requirements
the life of the solution. between the supplier’s supplier deliverable and acquirer’s
intended environment.
Verify that interfaces or connections
have been sufficiently tested by the
supplier.
Verify that issues identified during
testing have been resolved
appropriately, with deliverable
revisions, if necessary.
Resolve conflict, noncompliance, and
change issues for the selected
interfaces or connections.

Activity reports
Discrepancy reports
Criteria used to select technical
supplier deliverables for analysis
Lists of supplier requirements and
technical supplier deliverables selected
for analysis
Analysis methods for each selected
supplier deliverable
Record of analysis results May include:
• Issue and action item list
• Meeting minutes
Criteria to be used in selecting acquirer
managed interfaces or connections

Planning (PLAN)
485

Context Specific
Development
Perform technical reviews throughout the work lifecycle to gain confidence that the
requirements, architecture, and technical supplier deliverables provide the required capability.
These reviews should be integrated with risk management activities.
Types of technical reviews that can be conducted include:
• Integrated Baseline Review (IBR)
• Technology Readiness Assessment (TRA)
• System Requirements Review (SRR)
• Preliminary Design Review (PDR)
• Critical Design Review (CDR)
• Test Readiness Review (TRR)
• Production Readiness Review (PRR)
• Operational Test Readiness Review (OTRR)
Depending on where in the acquisition lifecycle the highest risks occur, the acquirer selects
technical supplier deliverables for analysis to reduce those risks. Select analysis methods based
on the type of technical solution being analyzed and the nature of the risk. For example:
• In the design phases of the solution, quality attribute models, simulations, prototypes,
or pilots can be used to provide additional information about the properties of the
potential design solutions to aid in their evaluation and selection. Simulations can be
particularly useful for complex systems.
• In the implementation phase, the acquirer can examine a supplier deliverable to
determine if it is ready for production and if the supplier has accomplished adequate
production planning. The analysis determines if production or production preparations
pose unacceptable risks that might compromise cost, schedule, performance, or other
established objectives. The acquirer might evaluate the full production configured
supplier deliverable to determine if it correctly and completely implements all contractual
requirements. The acquirer could also determine whether the traceability of the final
contractual requirements to the final production configured solution has been
maintained.
The acquirer should select a supplier’s design to analyze the adequacy and completeness of
that design. The acquirer may also confirm that:
• The selected design adheres to applicable design standards and criteria
486
• The design adheres to allocated functional and quality attribute requirements

• The resulting supplier deliverable will perform appropriately in its target environment
• The solution baseline enables hardware fabrication and software coding to proceed with
proper configuration management
• Adequate production processes and measures are in place for the work to succeed
• The design can be implemented within the production budget
During implementation, the supplier implements the design reviewed and analyzed by the
acquirer by developing supplier deliverable components, integrating those components,
performing unit and integration testing of the solution, and developing operational and end user
documentation.
The acquirer can require delivery of verification results from the supplier of the technical
solution, as applicable. The suppliers can perform verifications in an iterative fashion,
concurrently with the acquirer’s technical analyses, or the supplier can be required to perform
follow-on verifications of technical solutions.
Typical expectations for verification addressed by the supplier agreement may include:
• List of deliverables and other work products that must be verified by the supplier
• Applicable standards, procedures, methods, and tools
• Criteria for verification of supplier work products
• Measurements to be collected and provided by the supplier with regard to verification
activities
• Reviews of supplier verification results and corrective actions with the acquirer
Examples of considerations for follow up verifications of technical solutions include if:
• During the production stage of the work, there are changes in either materials or
manufacturing processes
• Production re-starts after a significant shutdown period
• Production starts up with a new supplier
• A manufacturing site has relocated
The acquirer can determine if the supplier’s implementation is successful by analyzing if the:
• Supplier deliverable is ready to be brought into the acquirer environment for further
integration and acceptance testing
• Production capability is satisfactory enough to perform pilot studies or move to full-rate
production
• Requirements are fully met in the final production configuration
The acquirer should also confirm that sufficient end user documentation has been developed
and is aligned with the tested implementation. The supplier can develop preliminary versions of
the installation, operations, and maintenance documentation in early phases of the work
lifecycle for review by the acquirer and affected stakeholders.
487
SAM 3.2
Practice Statement
Select and monitor supplier processes and deliverables based on criteria in the supplier
agreement.
Value
Provides better visibility into supplier capability and performance to minimize risk.
This requires that organizational standards and processes are in place and followed.
When close alignment between supplier and acquirer processes is critical to the success of the
project, the acquirer should monitor these processes to help prevent problems.
Selecting processes for monitoring involves considering the impact of the supplier’s processes
on the project. On larger projects with significant subcontracts with critical supplier deliverables
or solution components, monitoring key processes may be needed.
The acquirer decides on the necessary level of monitoring depending on the level of risk
incurred when the supplier’s process is not performed correctly. Monitoring processes can range
from reviewing supplier-produced process data to conducting on-site appraisals of the supplier’s
processes. Analyzing selected processes involves compiling and analyzing supplier process data
to determine whether there are serious risks or issues.
Example Activities
Select and monitor processes used by Supplier processes that are critical to the success of the
the supplier as defined in the supplier project should be monitored. When selecting processes to
agreement. monitor, consider the impact on the supplier.
Analyze processes used by the supplier Analyze results of monitoring selected processes to detect
as defined in the supplier agreement issues as early as possible that may affect the supplier’s
and communicate with affected ability to satisfy requirements of the supplier agreement.
stakeholders. Trend analysis may be performed and can rely on internal
and external data.

List of processes selected for
monitoring and rationale for selection
Reports from monitoring May include:
• Process performance reports
• Discrepancy reports
• Action items and risks
488

Record results of analysis

Planning (PLAN)
489
Level 4
SAM 4.1
Practice Statement
Select measures and apply analytical techniques to quantitatively manage supplier performance
to achieve quality and process performance objectives.
Value
Focuses measurement and management attention and activities to more effectively meet
The acquirer establishes and assigns performance measurement objectives and specifications
for suppliers. Accordingly, the acquirer must quantitatively manage the supplier against those
measurement objectives and specifications. In situations where the acquirer’s quality and
process performance objectives are impacted by the supplier processes or product
performance, the acquirer must statistically manage the relevant supplier processes and
products.
Appropriate analytical techniques can enable the acquirer to recognize significant deviations
from performance objectives as specified in the supplier agreement, in order to take corrective
action. This enables the acquirer to identify areas for potential corrective action with suppliers.
Example Activities
Identify key acquirer quality and
process performance objectives.
Establish a performance measurement This should be included in the supplier agreement and be
specification to monitor supplier traceable to the acquirer’s quality and process performance
progress and performance using objectives.
quantitative or statistical techniques. Trace key measures to the performance measurement
specifications and the quality and process performance
objectives.
Selection should not be limited to supplier deliverable,
progress, or performance measures only. Measures can be
used to develop analysis, process, and success indicators
which provide better insight into supplier performance.
Identify any data quality requirements.
Collect data from the supplier and
perform the analysis.
Record results of analysis and
communicate with stakeholders.
490

Identify corrective action with the
supplier.
Monitor corrective action to closure.

Performance measurement
specifications
List of selected measures Measures may include:
• Operational definitions suitable to support statistical and
other quantitative management
• Identified statistical and other quantitative techniques to
analyze the measures
• Representations of data and analysis results
• Identified key performance objectives
• Supplier process data
Results of the analyses against their Trace to objectives as defined in the supplier agreement.
targets
Action item list Include corrective actions and status.
491
Supplier Source Selection (SSS)
Intent
Develop and keep updated a package of materials used to seek proposals from potential
suppliers and select one or more suppliers to deliver the solution.
Value
Improves the ability to select the most qualified suppliers to deliver solutions.
Practice Summary
Level 1
SSS 1.1 Determine the type of acquisition.
SSS 1.2 Identify potential suppliers and distribute requests for proposals.
SSS 1.3 Evaluate proposals and select suppliers.
Level 2
SSS 2.1 Develop a solicitation package and keep it updated.
SSS 2.2 Identify qualified potential suppliers and distribute the solicitation
package for their response.
SSS 2.3 Evaluate proposed solutions according to recorded evaluation criteria and
select suppliers.
Level 3
SSS 3.1 Develop, keep updated, and follow negotiation approaches for soliciting,
evaluating, and selecting suppliers.
The purpose of Supplier Source Selection is to prepare a solicitation package and select one or
more suppliers to deliver the solution.
The acquirer is responsible for defining and keeping updated ground rules for initial
communication and interaction with potential suppliers. Define and use the roles and
responsibilities of affected stakeholders and potential suppliers.
Supplier Source Selection involves:
• Identifying potential suppliers
• Developing and distributing the solicitation package
492
• Developing supplier qualification criteria

• Developing proposal evaluation criteria
• Evaluating potential suppliers’ proposals
• Negotiating with potential suppliers
• Selecting suppliers that best meet the evaluation criteria
Develop the solicitation package using:
• Technical and contractual requirements
• Performance specifications
• Acceptance criteria
Level 1
SSS 1.1
Practice Statement
Determine the type of acquisition.
Value
Aligns the acquisition type to satisfy the project needs, requirements, and constraints.
The acquirer may use different types of acquisitions to acquire solutions based on technical,
regulatory, or customer requirements.
The acquirer may use a competitive bid process for selecting suppliers or they may choose to
pursue a sole source acquisition.
Example Activities
Review possible acquisition types. Examples of acquisition types include:
493

• Purchasing Commercial Off-The-Shelf (COTS) solutions
• Obtaining solutions from an external supplier
• Obtaining solutions from an in-house supplier, e.g., from
within the same organization, but from outside the project
• Obtaining solutions from the customer
• Obtaining solutions from a preferred supplier
• Purchasing supplier labor hours
• Combining some of the above, e.g., a COTS solution that
an external supplier must customize to fully meet
requirements
Select the type of acquisition to use. Different parts of a single solution may require selecting
multiple acquisition types.

List of possible acquisition types
Acquisition type selected for the
solution

SSS 1.2
Practice Statement
Identify potential suppliers and distribute requests for proposals.
Value
Maximizes the opportunity to receive responses from potential suppliers.
The acquirer identifies potential suppliers to receive the request for proposal (RFP). Acquirers
may request proposals from a limited number of suppliers to reduce the cost and effort for the
solicitation. Acquirers should ensure they include suppliers who can meet the requirements and
enough suppliers to provide a competitive environment.
494
Example Activities
Identify a list of potential suppliers.
Develop an RFP. May include:
• Requirements
o Technical
o Non-technical
o Contractual
• List of deliverables
Distribute the RFP to potential Consider local regulatory requirements.
suppliers.

List of potential suppliers
Request for proposals
SSS 1.3
Practice Statement
Evaluate proposals and select suppliers.
Value
Increases likelihood of project success.
Consider the advantages and disadvantages of each proposed solution prior to making a
supplier selection. Use proposal evaluation results to select suppliers. Retain notes related to
the supplier selection for future reference.
Example Activities
Evaluate supplier proposals. The acquirer typically evaluates proposals against:
• Requirements
o Technical
o Non-technical
o Contractual
495

o Regulatory
• Cost estimates
• Other identified proposal criteria
Select suppliers.

Results of proposal evaluation
Official selection notice
496
Level 2
SSS 2.1
Practice Statement
Develop a solicitation package and keep it updated.
Value
Maintains the integrity of the solicitation package for the objective comparison and evaluation of
proposals.

Use solicitation packages to seek proposals from potential suppliers. Solicitation packages
typically include:
• Technical requirements to be satisfied by the solution
• The Statement of Work (SOW) for the supplier
• A description of the process and criteria to evaluate proposals
• Required proposal contents
• Terms and conditions to include in the supplier agreement
• Guidance on how potential suppliers are to respond to the solicitation package
• The schedule for completing the solicitation process for both the supplier and the
acquirer
• Procedures for addressing questions and points of contact
The acquirer structures the solicitation package to facilitate a consistent, accurate, and
complete response from each potential supplier. This enables the acquirer to effectively and
objectively compare and evaluate submitted proposals.
The complexity and level of detail of the solicitation package should be consistent with the
value of, and risk associated with, the planned acquisition.
Example Activities
Develop the SOW for the supplier. The SOW typically includes:
• Project objectives
• An overview of the project with sufficient information for
the supplier to understand the project environment and
risks
• Requirements (including period of performance;
milestones; work location; legal, statutory, and regulatory
497

requirements; delivery format; quantities; content
requirements)
• Design constraints
• Deliverables, e.g., work breakdown structure (WBS) or list
of tasks and activities for the supplier’s work, detailed
design, test results
• Ownership, intellectual property, data, and proprietary
rights
• Specifications for the supplier’s transition of the product to
operations and support
• Requirements for performance including measures of
quality, process, product, and service level
• Required reports that provide the acquirer visibility into
supplier progress and performance
• Additional services required related to the acquired
solution, e.g., study reports, development of training
materials, delivery of training to end users
• Acquirer specified processes for the project, e.g.,
configuration management, quality assurance, issue
escalation and resolution, corrective action for
noncompliance, change management
• Reviews conducted with the supplier and their frequency
• Communication mechanisms
• Solution acceptance criteria and required supplier
involvement in the acquirer’s validation and acceptance
activities
• Post-project support
The acquirer can revise and refine the SOW for the supplier
as it moves through the solicitation, negotiation, and supplier
agreement development processes until finally incorporating
it into a signed supplier agreement.
Develop and record the required Required proposal content requirements typically include:
proposal contents. • Company overview, experience, and references
• Evidence of the supplier’s processes, including
commitment to execute processes to provide the solution
• Description of the solution the supplier will provide to
meet customer requirements
• Plan describing how the supplier will provide the required
solution
• Risk management plan describing how the supplier will
manage risks
• Supplier pricing methodology including:
o Calculation of charges, taxes, and credits
o Foreign currency exchange rates
o License fees
o Pass-through costs
o Travel reimbursements
498

• Acquirer invoicing requirements including frequency, term,
and pricing type, e.g., fixed price, lump sum, time and
materials
• Compliance with legal, regulatory, certification or other
requirements
• Supplier’s approach to assuring the quality of the solution
• Approach for the escalation and resolution of issues
• Information about ownership, intellectual property, data,
and proprietary rights
• Plan for retention of critical team members during the
project
• Identification of work subcontractors will perform
Develop proposal evaluation criteria. Develop and use evaluation criteria to rate or score suppliers
and their proposals.
The evaluation criteria used should be consistent with the
requirements and complexity of the acquired solution.
Examples of criteria used to evaluate a potential supplier’s
ability and proposal include:
• Response to all stated requirements contained in the
solicitation package
• Experience with similar solutions or services
• Technical capability, including:
o Technical methodologies and techniques
o Solutions
o Services
• Familiarity with acquirer processes, the technical
environment, and the core business
• Total ownership and lifecycle costs
• Management, development, and delivery processes and
procedures
• Financial capability
• Resource capacity, e.g., personnel available, facilities
available
• Business size and type
• Intellectual property and proprietary rights
• Compliance with regulatory requirements
Include evaluation processes and associated criteria in the
solicitation package.
Develop terms and conditions and Terms and conditions may include:
additional information. • Recitals or demonstrations of proposals
• Deliverables and rights
• Compensation and payments
• Confidentiality
• Privacy or non-disclosure statements
• Legal, regulatory, certification or other requirements
• Exclusive services, key personnel, supplier personnel at
acquirer sites
499

• Ownership, intellectual property, data, and proprietary
rights
• Force majeure
• Termination for insolvency, breach, non-performance,
convenience, etc.
• Termination assistance
• Term (length of the agreement)
• Renewal period
• Indemnification
• Insurance
• Right to audit
• Notices
Additional information to help the supplier when responding
to the solicitation package may include:
• Submission of intent to submit proposal
• Submission due date, time, and destination
• Number of proposal response copies the supplier must
submit
• Proposal format
• Non-complying proposals
• Proposal ownership
• Bidder inquiries
• Key dates and activities
• Discretionary selection and potential modifications of the
solicitation process
• Statements that:
o The solicitation itself is not an implied contract
o The response is not an obligation to do the work
• Confidentiality of information
• Publicity
• Use of subcontractors
• Due diligence
• Incurred costs
• Language requirements
• Statutory units
• Warranty provisions
• Licensing provisions
Review the solicitation package with Affected stakeholders may include potential suppliers and
affected stakeholders prior to other industry representatives.
distribution.
Obtain stakeholder commitment to the Commitment to the solicitation package reflects that
solicitation package. stakeholders understand and support the contents.

Record of reviews of the solicitation
package
500

Records of stakeholder commitment to
the solicitation package
Supplier and proposal evaluation
criteria
Finalized solicitation package

Peer Reviews (PR)
SSS 2.2
Practice Statement
Identify qualified potential suppliers and distribute the solicitation package for their response.
Value
Increases the likelihood that the most qualified suppliers respond.
The acquirer identifies qualified suppliers to receive the solicitation based on:
• Project scope and requirements
• Acquisition strategy
• Internal organizational policy
• Regulatory requirements
The acquirer can identify suppliers from a variety of sources, e.g., trade studies, market
analysis, existing lists of preferred suppliers.
For competitive bids, acquirers should identify a sufficient number of suppliers to guarantee
competition. In some cases, the organization can prequalify suppliers from a preferred list
based on characteristics such as experience, expertise, past performance, etc. Choosing from
preferred suppliers can greatly reduce the effort and time required for solicitation.
Depending on applicable regulations and work characteristics, the acquirer can decide to pursue
a sole source acquisition rather than a competitive bid. Acquirers should record the rationale for
determining potential suppliers, particularly in the case of a sole source selection.
501
Example Activities
Develop a list of qualified suppliers. The acquirer may consider:
• Suppliers who have experience with similar systems or
projects
• Performance of suppliers on previous projects
• Suppliers who are likely to provide the capabilities needed
for the work
• Availability of critical resources to staff and support the
work
• Suppliers’ financial capabilities, e.g., credit worthiness,
financial stability, and access to capital
Communicate with qualified suppliers Typical communication to suppliers includes:
concerning the solicitation. • Anticipated scope of the solicitation
• Schedule for release of the solicitation package
• Overall project schedule
• Approach and procedures to use throughout the
solicitation process
• High-level criteria for evaluating proposals
• Required supplier qualifications
• Schedule for the return of proposals
• Date when the supplier must indicate if they plan to
respond to the solicitation
Finalize a list of qualified suppliers.
Distribute the solicitation package to Distribute the package in accordance with approved acquirer
qualified suppliers. solicitation policies and procedures.
Record and respond to supplier Verify that all potential suppliers have equal access and
questions. opportunity to provide feedback on the solicitation package.
Provide the opportunity for selected potential suppliers and
stakeholders to clarify ambiguity and address concerns with
requirements.
Acknowledge the receipt of supplier
proposals.
Keep the package updated throughout
the solicitation.
Communicate changes to the Include all affected stakeholders and potential suppliers.
solicitation package.

List of qualified suppliers
Notice to potential suppliers about the
solicitation or any changes to the
solicitation
502

Supplier questions and requests for
clarification
Responses to supplier questions and
requests for clarification
Changes to the solicitation package
SSS 2.3
Practice Statement
Evaluate proposed solutions according to recorded evaluation criteria and select suppliers.
Value
Matches selection of the best solution and supplier for meeting contractual requirements.
Evaluate proposals submitted in response to solicitation packages in accordance with a defined
timeline. Use proposal evaluation criteria to evaluate potential supplier responses to the
solicitation. Record evaluation results and decision-making notes, e.g., advantages and
disadvantages of potential suppliers, scoring against criteria; and keep current.
Select suppliers based on an evaluation of their ability to meet specified requirements against
defined criteria. Criteria should address factors that are important to the work.
Factors that can be important to the work include:
• Supplier’s geographical location
• Engineering capabilities
• People and facilities available to perform the work
• Prior experience in similar situations
• Supplier’s past performance on similar work
• Customer satisfaction with similar solutions delivered by the supplier
Use proposal evaluation results to finalize the supplier selection. Negotiations enable the
acquirer to select the best supplier for the work. In some cases, the acquirer can take the top
proposals and use negotiations to make the final selection decision.
Evaluation results and negotiation results support the selection decision or may cause the
acquirer to take other actions as appropriate. If the return on investment (ROI) is not sufficient,
the acquirer can decide to defer or cancel the solicitation.
503
Example Activities
Verify conformance to requirements Contact the suppliers for corrective action if the response is
and completeness of supplier non-conforming or incomplete.
responses.
Distribute supplier proposals to
individuals performing the evaluation.
Conduct initial review of supplier Use this review to consolidate questions, concerns, and
proposals. issues with the supplier proposals.
Schedule and hold supplier Use presentations to ensure a mutual understanding of the
presentations. SOW.
Perform due diligence. Due diligence provides an opportunity for the acquirer to
further clarify requirements, particularly those related to the
acquirer’s existing environment and solutions in use.
Potential suppliers ask questions and gain understanding,
which enables them to make realistic proposals. It also
enables the acquirer to gain insight into the capability of the
potential suppliers’ proposed solutions to meet requirements.
Due diligence helps to:
• Eliminate assumptions and replace them with facts
• Identify and record risks and their mitigation plans
• List issues and dependencies between the acquirer and
supplier to include in the agreement
Examples of typical due diligence activities include:
• Reviews of requirements with the current supplier or
acquirer resources responsible for maintaining the
solutions or providing the services
• Reviews of solution interfaces or connections with existing
systems maintained by the acquirer
• Reviews and validation of supplier references
• Reviews of the operating environment’s facilities and
capabilities
• Reviews of regulatory and security requirements
• Reviews of supplier’s capabilities
• Reviews of cost and schedule estimates for the supplier’s
work
• Share clarification communications with all competitors
Evaluate supplier proposals according This includes an evaluation of past performance based on a
to evaluation criteria. review of:
• Supplier’s references
• Any previous experience with the supplier
• Prior performance on similar work
• Supplier management capabilities
• Personnel available to perform the work
• Available facilities and resources
• The project’s ability to work with the proposed supplier
504

This also includes evaluating the risks associated with each
proposed supplier.
Negotiate with suppliers. Negotiate with the selected supplier or candidate suppliers to
resolve issues identified during due diligence and to address
remaining issues with requirements. As appropriate, revise
requirements that the supplier must fulfill.
Select a supplier.
Record the selection and rationale.

Supplier proposals
List of candidate suppliers
Clarification correspondence between
the acquirer and potential suppliers
Evaluation results and rationale May include:
• Evaluation reports
• Market studies
• Trade studies
• Evaluation criteria
• Advantages and disadvantages of candidate suppliers
Revisions due to negotiations
Supplier selection decision
Supplier deliverables Examples include:
• Supplier documentation of their approach, their
capabilities, and a preliminary technical solution
• Proposal revisions based on clarifications

Level 3
SSS 3.1
Practice Statement
Develop, keep updated, and follow negotiation approaches for soliciting, evaluating, and
selecting suppliers.
505
Value
Improves the ability to select the best qualified suppliers while meeting business objectives.
The acquirer develops and refines a negotiation plan for each of the candidate suppliers based
on the evaluation of the suppliers and their proposals.
The negotiation team size depends on the size and complexity of the work. Typically, the team
lead is an acquisition professional and the team includes individuals with detailed knowledge of
the SOW included in the solicitation package. People that support the negotiation team typically
include a legal professional, a financial analyst, a purchasing or contracting agent, and a project
manager.
Regulations can restrict negotiations between acquirers and suppliers. Review all regulations
before entering negotiations with a supplier.
Example Activities
Identify participants in supplier
negotiations.
Develop and keep updated negotiation
plans and approaches.

Negotiation plan for each candidate Examples of items included in a negotiation plan include:
supplier • Negotiation personnel roles and responsibilities
• Key issues to negotiate from supplier responses
• Negotiation “levers,” and where and when to use them
• The sequence of events to negotiate issues
• Fall-back or compromise positions as necessary on given
issues (includes possible concessions and tradeoffs)
• List of non-negotiable items
• External factors that could influence negotiations, e.g.,
other pending deals and strategic plans
• Prior experiences with negotiation to leverage previous
positions and issues
• Supplier negotiation meeting schedule
• Objectives for each negotiating session
• Risks, consequences, and mitigation alternatives

506
Intent
Design and build solutions that meet customer requirements.
Value
Provides a cost-effective design and solution that meets customer requirements and reduces
rework.
Practice Summary
Level 1
TS 1.1 Build a solution to meet requirements.
Level 2
TS 2.1 Design and build a solution to meet requirements.
TS 2.2 Evaluate the design and address identified issues.
TS 2.3 Provide guidance on use of the solution.
Level 3
TS 3.1 Develop criteria for design decisions.
TS 3.2 Develop alternative solutions for selected components.
TS 3.3 Perform a build, buy, or reuse analysis.
TS 3.4 Select solutions based on design criteria.
TS 3.5 Develop, keep updated, and use information needed to implement the
design.
TS 3.6 Design solution interfaces or connections using established criteria.
Activities for designing and building solutions can be applied:
• To products or product components
• To services, service systems, and service components
• At any level of the product or service architecture
Design and build solutions that meet customer, functional, and quality requirements by:
507
• Developing, evaluating, and selecting cost-effective design solutions. These selected

design solutions can be called design approaches, design concepts, or preliminary
designs.
• Developing designs detailed enough to support implementation of the selected design
solutions.
• Implementing the designs as a product, service, or component.
Context Specific
Agile teams using Scrum typically build design incrementally, “emergent design” after building
functionality during each sprint. Some teams record the design as it emerges, some teams do
not. Emergent design can introduce risk when developing critical, complex, or large systems
since design defects introduced early can be expensive to correct later. Shorter, more focused
sprints are often used to help mitigate these risks.
It is typical for agile teams using Scrum to demonstrate less definition, clarity, and recording of
designs as compared to more traditional software development teams. Extensive use of white
boards, cameras, and other temporary mediums are common among agile teams. Example
design components include architecture, interfaces or data connections, data, and algorithms.
Technical Solution activities provide a foundation to ensure that the design is performed, usually
incrementally, prior to implementation, and the results are recorded to:
• Efficiently share technical information with stakeholders
• Mitigate technical risks
• Peer review to find defects early
• Support maintenance
Table TS-1 shows where Technical Solution activities can augment a typical agile project using
Scrum.
Table TS-1: Technical Solution Activities in an Agile Project Using Scrum

Agile with Scrum Technical Solution
Release planning Earlier and more complete understanding of the end solution and
completion risks.
Backlog grooming/review Allocation of requirements to design components to be developed for
known user stories during this sprint. This helps to identify additional
requirements that may have been missed.
508
Agile with Scrum Technical Solution

Sprint planning Broader understanding for context of designs and interfaces or
connections for the upcoming sprint
Sprint execution More of the execution is spent developing a working solution vs.
refactoring.
Sprint review Enables a more thorough understanding of what has been accomplished
during the sprint.
Sprint retrospective Provides a comprehensive understanding of what design components
remain.
Technical Solution activities can be performed iteratively to improve any agile project during
sprint execution. Time can be allocated to each sprint to perform design practices. Design
documentation can be in the form of a picture and bulleted design notes stored in the same
tools used to store user stories or epics and other project data.
Services
It is important to remember that in some simple service systems the components are just the
people and the processes they perform.
Service system development focuses on the following activities:
• Collecting, coordinating, analyzing, validating, and allocating stakeholder requirements
for service systems
• Evaluating and selecting from alternative service system solutions that meet
requirements
• Designing, building or composing (as needed), integrating, and recording service
systems that meet requirements
• Verifying and validating service systems to confirm satisfaction with intended
requirements and satisfaction with customer and end user expectations during actual
service delivery
The service organization chooses to develop the service system from a wide range of options,
from internal development to outsourcing to commercial product integration. Most service
organizations engage a development team to build a service system. Choose the development
method(s) based on the requirements to fulfill and the service system components to develop.
When service system components comprise product components, develop requirements, as well
as operational concepts and scenarios for the system, that consider the objectives of the service
system, business needs, customer needs, user needs, and the needs of other affected
stakeholders.
509
Level 1
TS 1.1
Practice Statement
Build a solution to meet requirements.
Value
Provides the customer with a solution that implements the requirements and reduces the cost
of rework.
Example Activities
Build a solution. Examples of building a solution include:
• Software is coded
• Data are recorded
• Services are provided
• Parts are fabricated
• Manufacturing processes are put into operation
• Facilities are constructed
• Materials are produced

Product or service
510
Level 2
TS 2.1
Practice Statement
Design and build a solution to meet requirements.
Value
Provides a structure to guide the implementation of a cost-effective solution that meets
requirements and avoids rework.
The design describes solution structure, interfaces or connections, and functionality.
The two main types of design are preliminary design and detailed design.
The preliminary design defines the solution and the architecture.
The detailed design describes solution component structure and functionality. The design is
detailed enough to allow the solution component to be implemented, fabricated, or acquired.
The level of detail required is typically set in the architecture’s standards and design rules.
The activities involved in these two designs may be iterative and overlap.
Example Activities
Define the architecture. May include:
• Developing the structural relationships and interface or
connection rules between elements
• Developing the structure that will support and integrate
the solution components needed to meet the
requirements
• Identifying major internal and external interfaces or
connections
• Defining component behavior and interaction
• Recording definitions using an architecture description
language
• Developing infrastructure capabilities and services
• Developing solution component templates, classes, or
frameworks
• Developing design rules and authority for making
decisions
• Defining a process or thread model
• Identifying major reuse approaches and sources
• Ensuring traceability to requirements
511

Identify, develop, or acquire effective Examples of effective design techniques and methods
design methods or tools for the include:
solution. • Prototypes and associated design lessons
• Structural models
• Object-oriented design
• Essential systems analysis
• Entity relationship models
• Design reuse
• Design patterns
Evaluate commercial off-the-shelf Care in evaluating and selecting COTS products and the
(COTS) products. supplier can be critical to the project if the COTS product:
• Is a significant part of the project or solution
• Represents significant risk
Aspects to consider in the selection decision include
proprietary issues and the availability of the products.
Develop a preliminary design. The preliminary design is the foundation for the solution and
the architecture, and may include:
• Architectural styles and patterns
• Component identification
• System states and modes
• Major component interfaces or connections
• External product interfaces or connections
• Algorithms to be employed
• Data definition
Develop a detailed design. May include:
• Finalizing the architecture
• Completing component and interfaces or connection
descriptions
• Optimizing design
• Selecting legacy or commercial components
• Verifying and validating requirements
Track requirements against design to As the design matures, track the requirements assigned to
ensure they are satisfied. lower level solution components and verify that those
requirements are satisfied.
Build the solution. Includes the allocation, refinement, and verification of each
product component. It also involves the coordination
between the various product component development
efforts. Steps to build the solution may include:
• Using effective methods to build the solution. For
example:
o Structured programming
o Automatic code generation
o Software code reuse
o Fabrication methods
o Computer aided design drawing
o Simulation
512

• Adhering to applicable standards. For example:
o Language standards
o Drawing requirements
o Manufactured parts
o Process and quality standards
o Construction regulations
o Legal regulations
• Adhering to applicable criteria. For example:
o Modularity
o Clarity
o Scalability
o Reliability
o Safety
o Maintainability

Architecture The architecture defines the design structure needed to meet
the requirements. Architectures should:
• Adhere to design standards and best practices
• Provide a foundation for developing solution components
and interfaces or connections
• Include input from operational concepts and scenarios
• Be traceable to requirements
Component design The design provides a specification of the solution, defining
how functional interface or connection quality requirements
will be met, and includes traceability to requirements.
Completed solution

TS 2.2
Practice Statement
Evaluate the design and address identified issues.
Value
Reduces cost by minimizing defects and ensuring that the solution meets requirements.
513

Verify that the design meets requirements.
Operational concepts and scenarios can be used during design reviews to evaluate how well the
design meets its intended purpose.
Example Activities
Determine what types of reviews to To evaluate the design, complete a technical review of the
perform. solution and identify deficiencies or potential improvements.
Types of evaluations include:
• Structured design walkthroughs
• Inspections
Identify review participants. Participants can include:
• Authors
• Technical team members
• Project managers
• Subject matter experts (SMEs)
Send draft designs to reviewers. Send these in advance so participants have enough time to
review them.
Conduct a technical review. Develop a review checklist to be available during the review.
Use technical reviews to:
• Present the design to affected stakeholders to develop a
common understanding and gather input regarding the
solution being considered
• Decide the validity of the solution
• Identify issues and concerns with the solution
• Verify that the technical concepts are:
o Correct
o Consistently and correctly used and represented
o Providing value to the solution
Record decisions, issues, and concerns.

Identify potential fixes.
Communicate issues and decisions to Include the role of stakeholders.
Update the design to address identified Assign corrective action to the appropriate stakeholders.
issues.
Review the solution. May include:
• Conducting peer reviews of selected components
• Performing verification of the components as appropriate
514

Revise the component as necessary.

Design evaluation issues Identified deficiency or improvement with the design.
Design review meeting minutes
Updated design
Updated solution

Peer Reviews (PR)
TS 2.3
Practice Statement
Provide guidance on use of the solution.
Value
Helps to ensure that the solution is usable and maintainable.
Example Activities
Develop and provide guidance
materials.

Guidance material Guidance material may include:
• User manual
• Maintenance manual
515

• Installation manual
• Operations manual
• Online help
516
Level 3
TS 3.1
Practice Statement
Develop criteria for design decisions.
Value
Increases the likelihood of producing a robust design that meets customer requirements and
constraints.
Record the name and detailed description for each criterion.
The criteria used to select solutions should provide a balanced approach to cost, requirements,
benefits, and risks. Note that identified criteria may lead to the conclusion that no alternative
solutions are necessary. Developing design criteria is often an iterative process. Design criteria
may be different based on the domain and design activities.
Example Activities
Analyze, develop, evaluate, use, and
keep updated design criteria.
Review and revise the design criteria Revise criteria when requirements, budget, technology, or
with affected stakeholders as needed. resources change or when a defect is discovered.

Design criteria Examples of criteria include:
• Complexity
• Cost of:
o Development
o Manufacturing
o Procurement
o Maintenance
o Support
• Time to implement
• Technology availability and limitations
• Resources needed
• Performance
• Robustness
• Requirements and technology evolution
• End use and operator capabilities
• Rationale why alternative solutions are not required
517

• Whether the solution needs to be:
o Modular
o Clear
o Simple
o Maintainable
o Verifiable
o Portable
o Reliable
o Accurate
o Secure
o Scalable
o Usable
TS 3.2
Practice Statement
Develop alternative solutions for selected components.
Value
Ensures that the most beneficial solution is identified and selected.
Any feasible solution that aligns with the customer’s requirements can be an alternative
solution.
Alternative solutions can include developing new technologies or identifying and applying
current technologies in different ways.
Solutions can be based on past designs. Consider alternatives that address and perform the
same necessary functions in different ways.
Example Activities
Develop, identify, and record May include:
alternative solutions. • New and currently in use product technologies
• Reusable solutions or solution components
• Externally-provided solutions
o Commercially available
o Customer provided
o Publicly or community available
518

• Functionality and quality attributes
• Terms and conditions of warranties for the products
Record the requirements allocation for
each alternative.
Communicate results.

Alternative solutions
TS 3.3
Practice Statement
Perform a build, buy, or reuse analysis.
Value
Ensures that the most effective way to implement the design has been chosen.
A “build, buy, or reuse analysis” or a “trade study” is typically used to ensure that the most
beneficial, technically viable option is selected to implement the solution. It is based on an
analysis of the needs of the project. Start the analysis early in the project, continue it during
the design process, and complete it with a decision on how to proceed.
Example Activities
Perform a build, buy, or reuse analysis. A decision analysis and resolution method or approach may
be used to address the design criteria and provide the
rationale for making the decision.
Record analysis and communicate
results.

Build, buy, or reuse analysis Factors affecting a build, buy, or reuse analysis can include:
• Functions the solutions will provide
• Available project resources and skills
519

• Costs of acquiring versus developing internally
• Critical delivery and integration dates
• Market research of available products
• Functionality and quality of available solutions
• Skills and capabilities of potential suppliers
• Licenses, warranties, responsibilities, and limitations
associated with solutions being acquired
• Availability
• Proprietary issues
• Regulatory or legal issues
• Risk reduction

TS 3.4
Practice Statement
Select solutions based on design criteria.
Value
Ensures the most efficient and effective solution is selected to meet the customer’s
requirements within cost, schedule, and performance constraints.
Include the rationale for selecting the solution.
Record solution descriptions and rationale for selection or rejection. Update the record
throughout development as solutions and detailed designs are developed and implemented.
Maintain a record of rationale to aid future decision making. Records prevent rework, rehashing
decisions, and provide insights for applying new technology as it becomes available.
Example Activities
Evaluate each alternative solution Identify and resolve issues with the alternative solutions and
against the selection criteria. requirements.
High-risk situations may use simulations, prototypes, or
pilots to assist in the evaluation.
Select the solutions that satisfy the
established criteria.
520

Based on evaluation of alternatives, Update criteria if additional derived requirements or criteria
reassess and update selection criteria are discovered.
when necessary.
records of solutions, evaluations, and
rationale.

Recorded solutions, evaluations, and Includes rationale for selection or rejection.
rationale

TS 3.5
Practice Statement
Develop, keep updated, and use information needed to implement the design.
Value
Avoids rework by ensuring that solution implementers have the information they need to
develop a solution that meets the customer’s requirements.
Example Activities
Record the information needed to The technical description defines the required design
implement the solution. configuration and procedures to ensure the performance of
the item is adequate. Provide a technical description of the
solution that addresses such aspects as:
• Development
• Production
• Logistics
• Maintenance
• Operations and support
• Solution lifecycle states and changes
521

Revise the information needed to Revise information as scope, requirements, or criteria
implement the solution, as needed. change.

Technical data package Commonly used to implement the design when the
implementation is complex or broken into multiple parts,
e.g., subsystems, internal or external team or supplier.
Package information to implement the design may include:
• Product definition data
• Engineering drawings
• Specifications
• Standards
• Performance requirements
• Reliability data
• Packaging details
• Modeling data
• Version control information
• Verification and validation criteria
• Any other information needed by the solution
implementers
Requirements, design, test, and
traceability information
TS 3.6
Practice Statement
Design solution interfaces or connections using established criteria.
Value
Reduces the likelihood of failures and rework during testing and operations and maximizes
performance.
Example Activities
Define interface or connection criteria. When defining criteria for interfaces or connections, define or
investigate critical parameters to determine if they are
522

applicable. These parameters are often specific to a given
type of system and are often associated with quality attribute
requirements, e.g., safety, security, durability, and mission
critical characteristics.
Develop interface or connection design
alternatives using established criteria.
Identify interfaces or connections, both
internal and external.
Identify interfaces or connections For example:
between components and related • Interfaces or connections between fabricated components
processes. and the fixtures used during the manufacturing process
• Interfaces or connections to test beds for software testing
Identify user interfaces or connections. Examples of users include:
• Developers
• Testers
• Operators
• Users
Each may have their own needs, norms, and perspectives
that may influence how they interact with the solution.
Record, keep updated, use, and
communicate selected interface or
connection criteria, design, and
selection rationale.

Interface or connection specification May include:
criteria • Safety
• Security
• Performance
• Standards
• Capacity
Interface or connection design Consistently and correctly designed interfaces or
specification connections, can include:
• Origin
• Destination
• Sequencing constraints or protocols
• Resources needed or consumed
• Exception or error handling behavior for inputs that are
erroneous or out of specified limits
• Electrical, mechanical, and functional characteristics
• Interfaces or connections between solutions
• Interfaces or connections with users, operators, and
maintainers of the solution
523

Interface or connection control
documents
Rationale for selected interface or
connection design
524
Intent
Verification and validation includes activities that:
• Confirm selected solutions and components meet their requirements
• Demonstrate selected solutions and components fulfill their intended use in their target
environment
Value
Verification and validation of selected solutions and components throughout the project
increases the likelihood that the solution will satisfy the customer.
Practice Summary
Level 1
VV 1.1 Perform verification to ensure the requirements are implemented and
record and communicate results.
VV 1.2 Perform validation to ensure the solution will function as intended in its
target environment and record and communicate results.
Level 2
VV 2.1 Select components and methods for verification and validation.
VV 2.2 Develop, keep updated, and use the environment needed to support
verification and validation.
VV 2.3 Develop, keep updated, and follow procedures for verification and
validation.
Level 3
VV 3.1 Develop, keep updated, and use criteria for verification and validation.
VV 3.2 Analyze and communicate verification and validation results.
Verification and validation activities include identifying corrective actions from verification and
validation activities and tracking them to closure.
Verification and validation address different perspectives:
525
• Verification addresses whether the work product and solution properly reflect the
specified requirements, i.e., “you are building it right.”
• Validation demonstrates that the solution will fulfill its intended use in its target
environment, i.e., “you are building the right thing.”
Verification and validation activities typically include incremental, iterative, or concurrent
processes that:
• Begin with requirements
• Continue through developing work products and the completed solution
• End with transitions to operations and sustainment
Validation activities can be applied to all aspects of the solution in any of its target
environments, including:
• Development
• Testing
• Operations
• Training
• Manufacturing
• Maintenance
• Support
Validation activities use approaches like verification, e.g., test, analysis, inspection,
demonstration, simulation. Typically, end users and other affected stakeholders are involved in
the project’s validation activities.
Context Specific
Figure VV-1 states where verification and validation activities are performed in an agile project
using Scrum project. Table VV-1 shows example criteria and results.
Agile teams using Scrum typically define a definition of done for each user story or requirement.
Work is performed until the definition of done is met for each User Story. Acceptance from the
product owner is obtained during the sprint review.
The differences between a typical agile project using Scrum and one using verification and
validation practices are the:
• Degree of clarity regarding the procedures used
• Definition of the expected operating environment
526
• Recording and analyzing of the results

For example, an agile team using Scrum would need to ensure that testing and demonstrations
consider and address how the user will use the solution in the intended environment. Recorded
results show the status of verification and validation activities and provide an opportunity for
analysis.
Figure VV-1: VV in an Agile Framework
Table VV-1: VV Information
527
Level 1
VV 1.1
Practice Statement
Perform verification to ensure the requirements are implemented and record and communicate
results.
Value
Early detection of requirements issues reduces the cost of addressing them and increases
customer satisfaction.
Verification throughout the lifecycle helps to ensure that requirements are implemented
correctly and issues are identified early.
Example Activities
Perform the verification of selected
work products and solutions against
their requirements.
Record and communicate the results of
verification activities.
Identify action items resulting from
verification.

Verification results
Action items
VV 1.2
Practice Statement
Perform validation to ensure the solution will function as intended in its target environment and
record and communicate results.
528
Value
Validation activities increase the likelihood that the result will provide the right solution to meet
customer expectations.
Example Activities
Validate selected work products and
solutions with stakeholders throughout
the lifecycle to ensure they function as
intended in their target environment.
Analyze and communicate the results
of validation activities.

Validation results
Analysis results
529
Level 2
VV 2.1
Practice Statement
Select components and methods for verification and validation.
Value
Produces solutions that meet or exceed customer expectations and needs.
Selecting work products for verification and validation enables early:
• Identification and resolution of defects
• Requirements refinement
• Indication of whether the proposed solution will work in the target environment
• Assessment of the proposed solution’s fitness for use
• Confidence that the proposed solution will meet customers’ needs and expectations
• Understanding of the solution among stakeholders
Verification and validation activities may result in derived requirements. Ensure the derived
requirements are included in the requirements set.
Example Activities
Select solution components for Select solution components based on their contribution to
verification and validation. meeting objectives for the solution. For each solution
component, determine the:
• Scope of the verification and validation activities
• Requirements to be satisfied
• Methods or tools to be used
Solution components that can be verified and validated
include:
• Requirements, designs, and constraints
• Acquired and developed solutions and related components
• User interfaces or connections
• User and operational manuals
• Process documentation
Identify requirements to be satisfied by When identifying requirements for each selected work
each selected work product. product, consult the traceability matrix (or other
530

requirements traceability information) maintained as part of
managing requirements for the work.
Determine which customer Target environments may include:
requirements and end user needs will • Testing
be validated. • Operations
• Maintenance
• Training
• Support services
Define, record, and keep updated Examples of verification methods include:
verification and validation methods to • Requirements inspection
be used for each selected solution. • Demonstration
• Load, stress, and performance testing
• Functional, interface or connection, and integration testing
• Prototyping, modeling, and simulation
Examples of validation methods include:
• Reviews with end users
• Prototype demonstrations
• Functional demonstrations
• Pilots
• Tests of solution components by end users and other
Attributes to consider for verification and validation may
include:
• Quality
• Functionality
• Maintainability
• Reliability
Review the validation selection, roles,
responsibilities, constraints, and
methods with affected stakeholders.

Lists of solution components selected
for verification and validation
Verification and validation methods for
each selected solution component
List of requirements to be verified and
validated

531
Context Specific
Development
Verification and validation for hardware engineering typically considers:

• Environmental conditions, e.g., pressure, temperature, vibration, humidity
• Input ranges, e.g., input power could be rated at 20V to 32V for a planned nominal of
28V
• Variations induced from part to part tolerance issues
Hardware verification normally tests most variables separately except when problematic
interactions are suspected. Hardware verification and validation methods include:
• Modeling to validate form, fit, and function of mechanical designs
• Thermal modeling
• Maintainability and reliability analysis
• Timeline demonstrations
• Simulations
Verification and validation for software engineering typically includes:
• Simulation
• Traceability studies
• Functional reviews or audits
• Physical reviews or audits
• Peer reviews
• Demonstrations
• Prototypes
• Formal reviews
• Module, regression, and system integration testing
VV 2.2
Practice Statement
Develop, keep updated, and use the environment needed to support verification and validation.
532
Value
Project delays are minimized by ensuring that verification and validation environments are
ready when needed.
The requirements for verification and validation environments are driven by the:
• Selected solution or solution components
• Type of work products, e.g., design, prototype, final version
• Methods or tools used for verification and validation
• Physical constraints, e.g., temperature, pressure, humidity
Elements in a verification or validation environment include:
• Test tools that work with the solution or solution components being verified or validated
• Embedded test equipment or software
• Simulated subsystems or components and their interfaces or connections
• Interfaces or connections to the operational environment
• Facilities and customer supplied products
• End users and operators
• Scenarios
• Actual or targeted physical environments, e.g., weather conditions, space, vacuum
Using these requirements and elements, the verification and validation environments can be
acquired, developed, reused, modified, or obtained depending on the needs of the solution.
Example Activities
Identify requirements for the
verification and validation environment.
Identify customer-supplied solutions This is typically done in the validation environment if the
and components. customer has existing facilities or components that will be
part of the intended environment.
Identify verification and validation Identify verification and validation resources that are
resources, equipment, and tools. available for reuse and modification.
Develop or acquire and keep the
environments updated.
533

Verification environment
Validation environment
VV 2.3
Practice Statement
Develop, keep updated, and follow procedures for verification and validation.
Value
Following verification and validation procedures reduces costs for performing the activities and
ensures more predictable performance.
Verification procedures ensure that work products meet their requirements. Validation
procedures ensure that the solution or solution component will fulfill its intended use when
placed in its target environment.
Example Activities
Identify criteria for selecting work
products and activities for verification
and validation.
Develop and keep updated procedures Procedures may cover:
for verification and validation. • Maintenance
• Set up and support of test and evaluation facilities
• Training
Perform verification and validation in
accordance with the procedures.

Verification procedures
Validation procedures
Verification and validation results
534
Level 3
VV 3.1
Practice Statement
Develop, keep updated, and use criteria for verification and validation.
Value
Using criteria minimizes waste by ensuring the verification and validation activities focus on
critical needs.
Examples of sources for verification and validation criteria include:
• Solution or solution component requirements
• Business process descriptions
• Standards, regulatory and legal requirements
• Customer acceptance criteria
• Solution performance
• Contracts and agreements
Example Activities
Develop verification and validation Criteria may include:
criteria and refine them as work • Specification of test inputs and outputs
progresses. • Description of expected results
• Description of acceptable results

Verification criteria
Validation criteria
535
VV 3.2
Practice Statement
Analyze and communicate verification and validation results.
Value
Analysis and communication of results helps to improve verification and validation effectiveness
over time.
Analysis and communication of verification and validation results ensure that issues receive the
appropriate attention from stakeholders and management.
Example Activities
Compare actual results to expected results.
Identify the results that do not meet
established criteria for verification.
Identify the results that do not meet
established criteria for validation.
Analyze verification and validation results Results may include defect, error, or issue analysis.
that do not meet established criteria and
determine corrective actions.
Submit improvement proposals where
improvements to verification and validation
process are identified.
Record and communicate analysis results
and corrective actions to affected
stakeholders.

Results of actual to expected comparisons
for verification and validation
Analysis results
Corrective actions
536
Appendices
Part Six: Appendices
Appendix A: Core Practice Areas, Categories, and Capability Areas

The following section is a high-level description of the current predefined core Practice Areas,
Categories, and Capability Areas (CAs) with their associated Practice Areas. In addition to aiding
in training, adoption, and understanding, these views are also intended for use in appraisals.
Figure 22 shows the core Practices Areas, and Figure 23 shows the Practice Areas aligned by
domain. Figure 24 shows the full list of current predefined Categories and their CAs. The
breakdown of each Category by CA and then by current and future PAs follows Figure 24.
Planned future CAs and PAs are marked as (FUTURE).
537
Figure 22. Core Practice Areas
538
Figure 23. Practice Areas by Domain
539
Figure 24. Categories and Capability Areas
540
Category: Doing
This Category includes CAs for producing, buying, and delivering quality solutions.
Capability Area:
Ensuring Quality
This CA area includes PAs important to both quality assurance and quality control. The Ensuring
Quality CA includes the following PAs:
Requirements Development and Management enables developing and

keeping updated a common understanding of needs and expectations for the
solution.
Process Quality Assurance ensures the process is followed, and quality

solutions are produced.
Verification and Validation ensures requirements are met and the solution
functions as intended in the target environment.
Peer Reviews identify solution defects or issues.
Capability Area:
Engineering and Developing Products
This CA focuses on engineering, developing, and delivering products and product components.
541
Technical Solution focuses on designing and building products and product

components.
Product Integration covers the assembly of the products and product

components and their delivery to the customer and ensures inclusion of
required functionality and quality characteristics.
Capability Area:
Delivering and Managing Services
This CA focuses on developing the capability to deliver agreed upon services, deploying new or
modified services, and establishing a portfolio of services.
Service Delivery Management includes delivering services in accordance

with the established service level agreements.
Strategic Service Management includes developing and keeping a portfolio

of updated standard services that are compatible with strategic needs and
plans.
542
Capability Area:
Selecting and Managing Suppliers
This CA establishes the buyer and supplier partnership to ensure that quality solutions are
delivered to the customer and end user.
Supplier Source Selection involves:

• Selecting one or more suppliers to deliver the solution
• Preparing a solicitation package
• Evaluating the supplier’s solution and managing selected connections of
that solution
Supplier Agreement Management involves:

• Developing and keeping updated the supplier agreement
• Ensuring that the supplier and the buyer perform according to the terms
of the supplier agreement
Category: Managing
This category includes CAs for planning and managing work and the workforce.
Capability Area:
Planning and Managing Work
This CA involves determining the amount of work that needs to be done, planning and
scheduling the work, and then ensuring the work is being done in accordance with the plans
and schedules. It also ensures that resources are adequate to meet the plan and schedule.
Estimating includes forecasting the size, effort, and cost for the work
required to develop, acquire, or deliver the solution.
543
Planning involves:
• Using the estimates to develop a work plan, schedule, and budget
• Determining the necessary resources to accomplish the plan, within
schedule and budget
• Obtaining commitment to the work plan from stakeholders
Monitor and Control provides an understanding of progress so

appropriate corrective actions can be taken when performance deviates
significantly from the plan, schedule, and budget.
Capability Area:
Managing Business Resilience
This CA addresses the ability to anticipate, prepare for, and respond to interruptions in order to
continue operations. It involves identifying, evaluating, prioritizing, and handling risks. It
ensures timely and effective resolution and prevention of interruptions to minimize the impact
on business operations and ensures the best possible level of service quality. It addresses
defining a minimum set of critical functions that must continue in the event of significant
interruption of normal operations.
Risk and Opportunity Management includes:

• Identifying threats and opportunities
• Evaluating their likelihood of occurrence and impact
• Mitigating potential threats
• Leveraging potential opportunities
Incident Resolution and Prevention includes:

• Identifying actual and potential incidents that may impact delivery
• Establishing the approach for addressing incidents as they occur
• Analyzing incidents to prevent recurrence
Continuity plans and validates the critical set of functions and resources
needed to continue operations when a significant or catastrophic event occurs.
544
Capability Area:
Managing the Workforce
This CA addresses the way an organization develops and retains the human resources needed
to perform current and future work.
(FUTURE) Compensation and Rewards involves providing individuals with

wages and benefits based on their contribution and value to the organization.
(FUTURE) Staffing and Workforce Management develops a formal

process to align work with resources and to recruit, select, and transition
qualified individuals to assignments.
(FUTURE) Career and Competency Development enhances the

knowledge, skills, and performance of individuals in the workforce through
mentoring and other professional development techniques.
Organizational Training provides a strategy and capability for training to

support the organization’s strategic business objectives, meet common tactical
needs, and deliver training across the organization.
(FUTURE) Empowered Workgroups builds teams with the skills and

experience needed to accomplish a set of objectives that have clear goals and
well-defined tasks.
545
Category: Enabling
This category focuses on analyzing causes, making decisions, maintaining integrity of work
products, and communicating to stakeholders.
Capability Area:
Supporting Implementation
This CA involves identifying and addressing the causes of selected outcomes, creating a
decision-making approach and structure, maintaining the integrity of work products, and
fostering communication and coordination among stakeholders.
Causal Analysis and Resolution identifies causes of selected outcomes and

acts to either prevent reoccurrence of undesirable outcomes or ensure
reoccurrence of positive outcomes.
Decision Analysis and Resolution aids in making decisions using criteria-

based evaluation of alternatives and recording the results.
Configuration Management establishes and maintains the integrity of work

products using configuration identification, control, and audits.
(FUTURE) Communication and Coordination promotes timely

communication and ensures the workforce has the skills to share information
and coordinate activities efficiently.
546
(FUTURE) Capability Area:

Managing Safety
This CA ensures that safety business objectives and expectations translate into safety policies
that define clear, tangible directives to the organization. Managing safety involves ensuring that
safety is adequately addressed throughout all stages of the solution lifecycle.
(FUTURE) Managing and Planning Safety addresses approaches useful in

the management of environmental, safety, and health mishap risks
encountered in the development, test, production, use, and disposal of
solutions, systems, subsystems, equipment, and facilities.
(FUTURE) Ensuring Safety includes identifying criteria and techniques for

avoiding accidents, minimizing and mitigating safety mishap risks; within the
constraints of operational effectiveness, time, and cost throughout all phases of
the solution lifecycle.
547
(FUTURE) Capability Area:

Managing Security
This CA ensures security related policies define clear expectations from translating business
objectives into tangible security directives.
(FUTURE) Managing and Planning Security identifies security business

objectives, processes, and assets for secure solution development that satisfy
the needs and objectives of the organization.
(FUTURE) Developing Secure Solutions includes performing security

activities that produce secure solutions.
(FUTURE) Managing Security Threats and Vulnerabilities helps identify

the security threats that could compromise the security objectives of the
solution, analyze the resulting level of risk, and define adequate security
measures and risk handling.
(FUTURE) Managing Supplier Security describes the selection and

management of suppliers to identify threats and vulnerabilities before final
solution integration.
(FUTURE) Planning and Supporting Security in Work includes

information to systematically develop planning and support activities to
achieve security objectives.
548
Category: Improving
This category involves developing, managing, and improving processes and their related assets
with a primary focus on improving organizational performance.
Capability Area:
Improving Performance
This CA focuses on measuring, analyzing and understanding an organization’s or project’s

capability and performance along with their process improvement priorities and infrastructure
needs. Once this is understood, the organization or project can identify performance and
process improvement actions and assets needed to continually improve capability and
performance.
Process Management develops capabilities and improves performance

though planning, implementing, and deploying improvements based on a
thorough understanding of the current strengths and weaknesses of the
organization’s processes and process assets.
Process Asset Development develops and keeps updated a usable set of

organizational processes and process assets for performing the work.
Managing Performance and Measurement involves:

• Ensuring that benefits and business objectives are the leading factors
driving performance and improvement
• Changing the paradigm:
o From: process improvement leads to performance improvement
o To: performance needs are the primary drivers of process
improvements
• Using the results of measurement and analysis to manage and control
performance at various work and business levels
549
Capability Area:
Sustaining Habit and Persistence
This CA ensures that processes are persistent and habitually performed and sustained
throughout the organization and effectively contribute to meeting business performance
objectives.
Governance provides guidance to senior management on their role in

ensuring that work is performed in a way that is relevant and important to the
business and organization.
Implementation Infrastructure provides a framework that ensures the

processes of an organization are persistently used and improved.
550
Appendix B: Predefined Model Views – Maturity and Capability Levels
Required and Explanatory Information

As noted in the Overview, both Practice Areas (PAs) and Practices contain required and
explanatory information. In both cases, Required Information is used for verifying that either
the PA or practice intent is being achieved during appraisals. For PA, in order to correctly
interpret and verify that the intent of the PA is met, the following must be looked at collectively:
• Intent statement
• Value statement
• Additional Required Information
For practices, in order to correctly interpret and verify that the intent of the practice is met, the
following must be looked at collectively:
• Practice statement
• Value statement
• Additional Required Information
Everything other than the required information is informative material. The informative material
of the model cannot be ignored; it is needed to understand the meaning of the required
information of the model. The terms “required” and “informative” in the model are specifically
relevant in the context of appraisals. When adopting CMMI, all model content is critical to
achieving performance and process improvement. For more information on appraisals,
reference the appropriate appraisal requirements, such as the Method Definition Document
(MDD). Figure 25 shows the similarities and differences between PAs and Practices.
551
Figure 25. Practice Area vs. Practice Structure
552
Capability Levels
Capability levels apply to an organization’s performance and process improvement
achievements in individual practice areas. Within PAs, the practices are organized into a set of
evolutionary levels labeled Level 0 to Level 5 which provide a path to performance
improvement. Each evolutionary level builds on the previous levels by adding new functionality
or sophistication resulting in increased capability. Capability levels are represented graphically
by a two-axis bar chart, where one axis is the PA and the other axis is the capability level (i.e.,
0-3) achieved for that PA. Figure 26 shows the evolutional characteristics of the capability
level for practices.
553
Figure 26. Evolutionary View of Practice Group Levels in Practices
All capability level ratings must include II and GOV. The maximum level a PA can achieve is
Capability Level 3. Capability levels can be benchmarked to a single PA, if II and GOV are
554
included. For example, an organization could achieve a Capability Level 3 for the PLAN PA if the
capability levels for the practices in the PLAN, II, and GOV PAs up to Capability Level 3 are
achieved. Figure 27 shows the required Practice Groups (PG) needed for the CM PA to achieve
Capability Level 3. For more information on determining capability levels and ratings, refer to
the MDD.
Figure 27. Capability Level Rating Progression – CM Example
Maturity Levels
Maturity levels apply to an organization’s performance and process improvement achievements
in a predefined set of PAs. Within each maturity level, the predefined set of PAs also provide a
path to performance improvement. Figure 28 shows the names of each maturity level, along
with their characteristics and their evolutionary performance path.
555
Figure 28. Maturity Levels Summary
Within each maturity level, performance has been built in to allow organizations to easily
identify performance improvement needs, and then use the model practices to improve. Like
capability levels, maturity levels build on each other and cannot be skipped. The following list
contains a brief description on how maturity levels build on each other.
• Maturity Level 0: the intent of all predefined PAs is not achieved
• Maturity Level 1: the intent of all predefined PAs up to and including Level 1 practices is
achieved at Practice Group Level 1
achieved at Practice Group Level 2
achieved at Practice Group 3
556
The CMMI is an integrated set of best practices that improve performance and key capabilities
for the following current and potential CMMI Institute predefined model views:
• CMMI Development (CMMI-DEV), based in part, on the CMMI for Development v1.3 model,
for improving processes and performance for developing better products and services.
• CMMI Services (CMMI-SVC), based in part, on the CMMI for Services v1.3 model, for
improving capabilities and processes for providing better service performance
• CMMI Supplier Management (CMMI-SPM), based in part, on the CMMI for Acquisition v1.3
model, for improving processes and performance for optimizing the supply chain
• (FUTURE) CMMI People Management (CMMI-PPL), based in part, on the People CMM v2
model for Improving processes and performance for managing people
The following tables in Figure 29 through Figure 32 show the organization of the PAs in
Maturity Levels 2-5 for each of the CMMI Institute predefined model views.
557
Figure 29. CMMI Development, Maturity Levels 2-5
558
559
560
561
Figure 30. CMMI Services, Maturity Levels 2-5
562
563
564
565
Figure 31. CMMI Supplier Management, Maturity Levels 2-5
566
567
Creating Customized Views

In the future, customized views can also be created and used to address any given challenge,
issue or improvement opportunity. Below are two customized view examples:
Example 1: For a very small development organization just starting out on their performance
and process improvement journey, the following PAs could address their critical problems:
• Estimating (EST)
• Planning (PLAN)
• Monitor and Control (MC)
• Technical Solution (TS)
• Product Integration (PI)
Example 2: For a technical division in an organization that manages development, services, and
suppliers, the following PAs could address their performance improvement needs:
• Incident Resolution and Prevention (IRP)
• Continuity (CONT)
• Strategic Service Management (STSM)
• Technical Solution (TS)
• Product Integration (PI)
• Managing Performance and Measurement (MPM)
• Service Delivery Management (SDM)
• Supplier Source Selection (SSS)
• Supplier Agreement Management (SAM)
• Requirements Development and Management (RDM)
• Governance (GOV)
• Implementation Infrastructure (II)
A key aspect of creating customized views is to:
• Identify the problems
• Determine root causes
• Identify potential process focal points
568
Figure 32. Development and Multi-Model Capability Area View Examples
569
Appendix C: CMMI Adoption and Transition Resources
570
571
Appendix D: Common CMMI Misperceptions

The following list contains some of the most common misperceptions of the CMMI, as compared
to reality.
572
573
574
Appendix E: Glossary
Glossary Terminology Context

Certain words in the CMMI product suite have special meaning. When applicable, that term is
included in the glossary. Otherwise the common English meaning of words, e.g. Webster or
Oxford dictionary, applies.
Terms appearing in the CMMI glossary take on the characteristics of the content where they
appear in the model or Method Definition Document (MDD). For example, if a term is used in
required information, it is required in that context, or if it appears in the explanatory
information, it is an explanatory term in that context.
5-Whys
A technique used to determine an issue's root causes. This technique involves asking the
question "Why?" repeatedly until the root cause is identified.
acceptance criteria
Criteria that a solution must satisfy to be accepted by customers.
acceptance testing
Testing performed to determine whether a customer, acquirer, user, or their designee should
accept a solution.
acquirer
The stakeholder who obtains a solution from a supplier. (Refer to “affected stakeholder.”)
acquisition
Obtaining solutions by establishing and executing supplier agreements. (Refer to “supplier
agreement.”)
People impacted by a process, activity, work product, or decision.
agile
An approach to project management or delivery methodology in which the customer is
intimately involved in the project, tasks are divided into short phases of work, and there is
frequent reassessment and adaptation of plans.
agile with Scrum

This is a CMMI context-specific tag reserved for identifying unique information for agile projects
using Scrum. It is a framework for managing work with an emphasis on software development.
It is designed for small teams of developers who break their work into actions that can be
completed within time-boxed iterations, called sprints, e.g., two-weeks; and track progress and
re-plan in 15-minute stand-up meetings, called daily scrums. (Refer to “agile.”)
575
allocated requirement
Requirement that results from levying all or part of a higher-level requirement on a solution's
lower-level design component. Requirements can be assigned to logical or physical components
including people, consumables, delivery increments, or the architecture.
appraisal
An examination of one or more processes by a trained team using a reference model as the
basis for determining, at a minimum, strengths and weaknesses.
architecture
The set of structures that need to be considered to establish a solution. These structures are
comprised of smaller components or elements, relationships among those structures and
elements, and the properties of both. (Refer to "functional architecture.”)
assignable cause of process variation

An extraordinary event outside the bounds of the usual steps following the process.
base measure
A base measure is functionally independent of other measures, and cannot be expressed in
other terms. A base measure is defined in terms of an attribute and the method for quantifying
it. (Refer to “derived measure.”)
baseline
A set of specifications or work products that:
• has been formally reviewed and agreed on,

• serves as the basis for further work or change, and
• can be changed only through change control procedures.
(Refer to “configuration baseline” and “product baseline.”)
Benchmark Model View

A logical grouping of CMMI Institute predefined CMMI model components used to define the
appraisal model view scope.
• For maturity levels, the Benchmark Model View is a set of Practice Areas, and their levels,
predefined by CMMI Institute for the purposes of conducting Benchmark appraisals or
Sustainment appraisals.
• For capability levels, the Benchmark Model View may either be a predefined view, or a
selection of Practice Areas or Capability Areas and their levels that meet the organization’s
business needs and performance objectives.
bidirectional traceability
An association that enables the ability to trace in either direction between logical entities, e.g.,
from requirements to design to code to test to the end solution, or from customer requirements
to product component requirements. (Refer to “requirements traceability” and “traceability.”)
576
business performance
The accomplishment of a given capability or task measured against preset known objectives,
including, but not limited to, quality, cost, speed, accuracy, and completeness for delivery of a
solution to a customer. In the CMMI, the term "business performance" refers to performance at
the business or organizational level; it can be both organizational-specific or aggregated from
the project level. For example, collect measurement and performance data at the project level
and aggregate data to enable organizational performance analysis at the business level. (Refer
to “process performance.”)
capability
Capabilities are typically organizational level skills, abilities, and knowledge embedded in people,
processes, infrastructure, and technology. Capabilities are what an organization needs to
implement its business model or fulfill its mission and achieve measurable business results.
Capability Area (CA)

A group of related Practice Areas that can provide improved performance in the skills and
activities of an organization or project. Capability Areas are a type of view.
capability level
The highest practice group level for a given Practice Area at which the intent of all practices is
met. Capability levels are cumulative and for each practice group level met, all lower level
practice groups must also be met.
Capability Maturity Model Integration (CMMI)

An integrated model of best practices that enable businesses to improve performance by
improving their processes. Product teams developed the model with global members from
across industry and from CMMI Institute. The CMMI provides a best-practice framework for
building, improving, and sustaining process capability. (Refer to “CMMI product suite.”)
capable process
A stable process able to meet the quality and process performance objectives set for it. The
process variation is within set specification limits. (Refer to “stable process.”)
category
Categories are logical groups or types of views of related capability areas that address common
problems encountered by businesses when producing or delivering solutions.
causal analysis
A method of searching for the origination of certain effects. (Refer to “root cause.”)
change management
A methodical approach for controlling and implementing changes in a planned and structured
manner.
CMMI product suite

The integrated set of components that comprise CMMI. The product suite components include
the model, appraisal method, training and certification, adoption guidance, and systems and
tools.
577
Commercial Off-The-Shelf (COTS)

Describes items that can be purchased from a commercial supplier and used without tailoring.
common cause of variation

The variation of a process that exists because of normal and expected interactions among
components of a process. Also referred to as “inherent cause” of variation. (Refer to “special
cause of variation.”)
configuration audit
An audit conducted to verify that a configuration item or a collection of configuration items in a
baseline conforms to a baseline description. (Refer to “audit” and “configuration item.”)
configuration baseline
The configuration information formally designated at a specific time during a solution or solution
component’s life. Configuration baselines plus approved changes from those baselines constitute
the current configuration information. (Refer to “product lifecycle.”)
configuration control
The process of managing changes to a formal configuration baseline. The process consists of
evaluating the change, coordinating any effects, approving or disapproving the change, and
implementing the changes to configuration items in the baseline. (Refer to, "configuration
identification”, "configuration item”, and "configuration management.”)
configuration control board

A group of people responsible for evaluating and approving or disapproving proposed changes
to configuration items and for ensuring implementation of approved changes. Configuration
control boards are also known as “change control boards”. (Refer to “configuration item.”)
configuration identification
A configuration management activity that involves selecting a product’s configuration items,
assigning them unique identifiers, and recording their functional and physical characteristics in
technical documentation. (Refer to “configuration item” and “configuration management.”)
configuration item
Work products designated for configuration management and treated as a single entity in the
configuration management process. (Refer to “configuration management.”)
configuration management
The process of managing the integrity of work products using configuration identification,
version control, change control, and audits. (Refer to “configuration identification”,
“configuration item”, “configuration audit”, and “version control.”)
contractual requirements
Result of analysis and refinement of customer requirements into a set of requirements suitable
for inclusion in solicitation packages or supplier agreements.
Contractual requirements include technical and nontechnical requirements necessary to acquire

a solution.
578
(Refer to “acquirer”, “customer requirement”, and “supplier agreement.”)
core assets
Assets essential to a solution and may include:
• Components
• Domain models
• Requirements
• Performance models
• Estimates and plans
• Test plans and test descriptions
customer
The party responsible for buying or accepting a solution or for authorizing payment for a
solution. Customers may also be end users.
customer requirement
The result of eliciting and consolidating needs, and resolving conflicts among those needs,
expectations, constraints, and interfaces to clarify and define the solutions with affected
stakeholders in a way that is acceptable to them. (Refer to “customer.”)
data
Qualitative or quantitative-based information that can be recorded, communicated, and
analyzed.
defect density
Number of defects per unit of solution size. An example is the number of bugs per thousand
lines of code.
defined process
The subset of organizational process assets that are essential for any tailored and managed
process. A fully defined process has enough detail that it can be consistently performed by
trained and skilled people and is both persistent and habitual. A defined process is necessary at
the practice group evolutionary level 3 in the CMMI practice areas (Refer to “managed
process.”)
deliverable
An item to be provided to an acquirer or other designated recipient as specified in an
agreement. This item can be a document, hardware item, software item, service, or any type of
work product. (Refer to “acquirer.”)
derived measure
Measure defined as a function of two or more base measures. Derived measures are often
expressed as ratios, composite indices, or other aggregate summary measures. (Refer to “base
measure.”)
579
derived requirements
Requirements that are not explicitly stated in customer requirements, but are inferred and
developed from:
• contextual requirements, e.g., applicable standards, laws, policies, common practices,

management decisions; or
• requirements needed to specify a solution component.
Derived requirements can also arise during analysis and design of solution components. (Refer
to “product component requirements.”)
design review
A formal, recorded, comprehensive, and systematic examination of a solution or component
design to determine if the design meets applicable requirements, identify problems, and
propose solutions.
develop, use, and keep updated

This phrase is a fundamental principle in CMMI: work products resulting from projects’ and
organizational processes must be used and useful to the work and enable performance. The
work products should be kept current to reflect how work is performed or improved.
development
To create a solution by deliberate effort. In some contexts, development can include
maintenance of the developed product or service system. In the CMMI product suite, when this
term is used with the phrase “Development context specific”, it is referring to this definition.
DevOps
A combination of the terms: “development” and “operations”. This is an enterprise software
development phrase used to mean a type of agile relationship between development and
Information Technology (IT) operations. The goal of DevOps is to change and improve the
relationship between development and operations by advocating better communication and
collaboration between these two business units.
document
A collection of information and data, regardless of the medium, that generally has permanence
and can be read by humans or machines. Documents can be work products reflecting the
implementation of processes that meet the intent of one or more model practices. Documents
may be embedded within an automated, robotic, or online system. Documents can be
hardcopies, softcopies, or accessible via hyperlinks in a web-based environment or application.
Documents are used and kept updated. (Refer to “artifact” and “record.”)
entry criteria
Conditions that must be met before an effort can begin successfully. (Refer to “exit criteria.”)
example activities
Possible actions that may be taken when implementing processes that meet the intent of a
practice. The intent of "Example Activities" is to serve as guidance and suggestions, not as
required activities. It is not intended to be a comprehensive list.
580
example work products

Possible outputs of implementing processes that meet the intent of a practice. The intent of
"Example Work Products" is to serve as guidance and suggestions, not as required work
products. It is not intended to be a comprehensive list.
exit criteria
Conditions that must be met before successful completion of an effort. (Refer to “entry
criteria.”)
functional analysis
An examination of functions of the solution or solution components to broaden and deepen
understanding.
functional architecture
The conceptual structure and logical arrangement of functions. This may include internal and
external interface functions. (Refer to “architecture” and “functional analysis.”)
gemba walk
The term used to describe personal observation of work – where the work is happening. The
original Japanese term comes from gembutsu, which means “real thing”. (Also known as “genba
walk.”)
hardware engineering
The application of a systematic, disciplined, and measurable approach to transforming a set of
requirements, using documented techniques and technology to design, implement, and
maintain a tangible solution. In CMMI, hardware engineering represents all technical fields, e.g.,
electrical, mechanical; that transform requirements and ideas into tangible solutions. (Refer to
“software engineering” and “systems engineering.”)
High Maturity
CMMI Model practice group levels (and their associated practices) of 4 or 5 are considered High
Maturity practices and levels. High Maturity organizations and projects use quantitative and
statistical analysis to determine, identify, and manage central tendency and dispersion and
understand and address process stability and capability and how these impact the achievement
quality and process performance objectives.
informative material
Includes everything other than the required information. Explanatory information in practices
are part of the informative material. Informative material also includes the overview and
appendices, e.g. glossary, index. Informative material must not be ignored, it is needed to
correctly understand and adopt the model.
External links can be added to the informative material. These are links to external assets such
as:
• Additional informative material

• Adoption examples
581
• Transition and adoption guidance from one model or standard to others

• Templates
integration environment
The configuration of processes, systems, tools, people, and associated infrastructure used when
combining components to develop a solution.
interface data
Information describing interfaces or connections.
interface or connection
A shared boundary across components, humans, services, hardware, or software that needs or
exchanges information or data. Either term “interface” or “connection” may be used to describe
this boundary.
interface or connection description

A description of the functional and physical characteristics of a component and its boundaries,
e.g. user, system, that describes its interaction with another component.
lifecycle model
A representation or description of the steps and activities for the development and updating of
a solution communicated to stakeholders and followed by a project or organization. This
description may include:
• Phases
• Sequence
• Interrelationships
• Inputs
• Outputs
• Decisions points
• Roles and responsibilities
managed process
A performed process that is recorded, followed, updated, and made persistent and habitual in
its use. A managed process is necessary at the Practice Group evolutionary level 2 in the CMMI
Practice Areas (Refer to “performed process.”)
maturity level
A rating that describes the degree to which processes in an Organizational Unit meet the intents
of a predefined set of Practice Areas. The rating is based on the achievement of a specified set
of practice group levels within the predefined set of Practice Areas.
582
measurement and performance objectives

Used to describe quantitative or qualitative objectives that do not require the additional rigor of
statistical or quantitative analysis.
measurement-based
Numerical data obtained by performing measurements, but not based on statistical and
quantitative management.
memorandum of agreement
A record of expectations and arrangements between two or more parties also known as a
“memorandum of understanding”. (Refer to “Statement Of Work.”)
model component
Any of the five main architectural elements or parts that compose the CMMI model. These
include the view, practice area, practice group, practice, and informative material. (Refer to
“informative material”, “practice”, “practice area”, “practice group”, and “view.”)
natural bounds
The inherent range of variation in a process, as determined by process performance measures.
Natural bounds are sometimes referred to as “control limits” or the “voice of the process”.
objectively evaluate
To review activities and work products against criteria that minimize subjectivity and bias by the
reviewer.
operational concept
A general description of the way in which a component or solution is used or operates. An
operational concept may also be referred to a “concept of operations.”
operational scenario
A description of a potential sequence of events that includes the interaction of a component or
solution with its environment and users, and with other solution components. Operational
scenarios are used to evaluate the requirements and design of the system and to verify and
validate the system.
opportunity
An uncertain event that may positively impact meeting objectives.
optimizing process
A quantitatively managed process that is continually improved to increase its capability. These
continuous improvements can be made through both incremental and innovative improvements.
An optimizing process is necessary at the practice group evolutionary level 5 in the CMMI
Practice Areas. (Refer to “quantitatively managed process” and “defined process” for contrast.)
or
The use of “or” in the CMMI model means either “and” or “or.”
583
organization’s business objectives

Developed by senior management to improve performance, build and improve capability, and
enhance profitability, market share, and other factors that influence the organization’s success.
organization’s measurement repository

A specific location or locations where measurement-based information is stored. The purpose is
to collect and make measurement results available throughout the organization. This repository
contains or references actual measurement results and related information needed to
understand and analyze measurement results typically described as part of the organizational
process assets. (Refer to “organization’s process assets” and “organization’s set of standard
processes.”)
organization’s process assets

Process-related documentation, records, and information such as policies, an organization’s set
of standard processes, tailoring guidelines, checklists, lessons learned, templates, standards,
procedures, plans, training materials, etc. (Refer to “process description” and “organization’s
process asset library.”)
organization’s process asset library

A specific location or locations where information is stored to make process assets available that
are useful to those who are defining, implementing, managing, and following processes in the
organization. (Refer to “organization’s process assets.”)

A collection of process descriptions that guide consistent process implementation across an
organization. These process descriptions cover the fundamental process elements and their
relationships to each other such as ordering and interfaces that should be incorporated into the
defined processes that are implemented in work groups across the organization. A standard
process is essential for long-term stability and improvement. (Refer to “process description” and
“process element.”)
organizational directives
Expectations established by senior management that are adopted by an organization to
influence and determine decisions, may also be referred to as “organizational policies.”
peer reviews
The examination of work products performed by similarly skilled personnel during the
development of work products to identify defects for removal. Peer reviews are sometimes
called work product inspections. (Refer to “work product.”)
performance parameters
Measurable criteria used to monitor progress towards quantitative objectives. Collectively,
performance parameters provide a metric for determining success for the business or project.
584
Performance Work Statement (PWS)

A Statement of Work (SOW) for performance-based acquisitions that clearly describes the
performance objectives and standards that are expected of the contractor. When a contract is
awarded, the PWS is a legally binding document upon the contractor. (Refer to “SOW.”)
performed process
A simple approach or set of steps that produces solutions or work products. A performed
process is characteristic of practice group evolutionary level 1 in the CMMI Practice Areas.
persistent and habitual

The routine way of doing business and following and improving process that an organization
follows as part of its culture.
practice
A practice consists of two parts:
• Required practice information: Information required to understand the full intent and value
of the practice, which includes the practice statement, the value statement, and the
additional required information
• Explanatory practice information: Remaining parts of the practice, including example
activities and work products, which are important and useful to better understand the
meaning and intent of the required information, including the practice statement, value, and
additional required information
Practice Area (PA)
A collection of similar practices that together achieve the defined intent, value, and required
information described in that Practice Area.
Practice Area (PA) Required Information

The intent, value, and any additional required information for a Practice Area.
practice group
The organizing structure for practices within a Practice Area to aid understanding and adoption
and provides a path for performance improvement. Currently, the practice groups defined for
CMMI are evolutionary levels.
process
A set of interrelated activities, which transform inputs into outputs to achieve a given purpose.
(Refer to “process element.”)
process action team

A team with responsibility for developing and implementing process improvement activities for
an organization. (Refer to “process group.”)
process architecture
The ordering, interfaces, interdependencies, and other relationships among the process
elements in a standard process, or standard processes.
585
process capability
A recorded range of expected results that can be achieved by following a process.
process description
A record for a specific process. Process descriptions may be documents, embedded or
automated steps or instructions in a robot, component, system or tool, or graphical
representations, etc.
process element
The fundamental unit of a process that cannot be further broken down.
process group
The people or team who hold a process role and are responsible for developing, deploying, and
updating the organization's process assets. (Refer to “process role.”)
process improvement
Tasks and activities planned, performed and used to improve an organization's process
capability and performance to achieve business objectives more effectively. (Refer to
“organization’s business objectives.”)
process improvement objectives

A set of measurement objectives established to focus process improvement in a specific,
measurable way that improves performance to achieve an organization’s business objectives
and build or improve capability. (Refer to “measurement and performance objective”,
“organization’s business objectives”, and “quantitative objective.”)
process improvement plan

A process improvement plan records the objectives, activities, resources, oversight, schedules,
and associated risks to improve processes.
process measurement
Activities performed to collect information and assign numeric values related to the activities,
steps, and outputs of following a process. This information is analyzed to determine the
effectiveness and efficiency of a process. (Refer to “measurement” and "process performance.”)
process owner
The person or team responsible for developing, updating or following a process. An organization
or project can have multiple owners at different levels of responsibility for:
• organization’s set of standard processes

• project-specific and project-defined processes
process performance
A measure of results achieved by following a process. Process performance may be
characterized by both process measures, e.g., effort, cycle time, defect removal efficiency, and
solution measures, e.g., reliability, defect density, response time. (Refer to “business
performance.”)
586
process performance baseline

A record and description of historical process performance resulting from following a defined
process, which can include central tendency, e.g., mean, medium, mode, variation, and reflects
how the process is being performed. Process performance baselines can be used as
benchmarks for comparing actual process performance to expected process performance and
can be used in process performance models to predict future process performance. (Refer to
“process performance” and “process performance model.”)
process performance model

A predictive analytical tool that identifies the controllable factors and describes the relationships
between measurable attributes of one or more processes, subprocesses, process elements, or
work products. (Refer to “process performance baseline” and “quality and process performance
objectives.”)
process role
A description of the roles of people who develop, use, or follow a process in an organization.
This role is typically recorded in a process description or related artifact, e.g., a roles and
responsibility table or matrix. People in these roles provide objective evidence OE showing and
explaining their roles and responsibilities and how they participate in the processes.
product component
A work product that is a building block of the product, or solution. Integrate product
components to produce the final product, or solution. There can be multiple levels of
components.
product lifecycle
A representation of the set of steps or activities, consisting of phases, that begins at conception
of a product or service and ends when the product or service is no longer available for use. For
example, a product lifecycle could consist of the following phases:
• concept and vision

• feasibility
• design/development
• production
• delivery
• phase out, retire, or sunset
Organizations can produce multiple products or services for multiple customers, and so may
define multiple product lifecycles. These lifecycles may be adapted from published literature for
use in an organization.
product line
A group of products:
• sharing a common, managed set of features

• satisfying specific needs of a selected market or mission
587
• developed from a common set of core assets in a prescribed way

project
A managed set of interrelated activities and resources, including people, that delivers one or
more solutions to a customer or end user. A project typically has an intended beginning (i.e.,
project startup) and end, but also may be continuous. Projects typically operate according to a
plan and set of requirements. The term “project” includes where and how the work gets done,
whether developing a product, providing a service, performing an organizational function, or
acquiring and managing suppliers, etc. (Refer to “process role” and “organizational and in-scope
projects.”)
project plan
A plan that provides the basis for performing and controlling project activities, and addresses
commitments to the customer. A project plan is based on estimating the attributes of work
products and tasks, determining the resources needed, negotiating commitments, producing a
schedule, and identifying and analyzing risks. Iterating through these activities can be
necessary to establish the project plan.
project startup
Initial time period when a project begins. (Refer to “project.”)
quality and process performance objectives

Quantitative objectives and performance requirements for solution quality and process
performance. These objectives include the use of statistical and quantitative analysis on the
related data. (Refer to “measurement and performance objectives.”)
quality attribute
Property of a solution by which affected stakeholders will judge its quality. Quality attributes
are:
• "Non-functional”
• Significantly influence architecture
• Characterized by one or more measures
Quality attribute examples:
• Availability
• Maintainability
• Modifiability
• Reliability
• Responsiveness
• Scalability
• Security
• Timeliness
• Throughput
588
• Usability
quantitative management
Managing a project using quantitative techniques to understand actual or predicted process
performance relative to quality and process performance objectives, variation, and identifying
corrective action needed to meet the objectives.
quantitative objective
Desired target value expressed using measures. (Refer to “measure”, “process improvement
objectives”, and “quality and process performance objectives.”)
quantitatively managed process

A defined process evaluated and controlled using statistical and other quantitative techniques. A
quantitatively managed process is necessary at the practice group evolutionary level 4 in the
CMMI Practice Areas.
reference model
A defined model describing practices and activities that is used for improving performance or as
a benchmark for measuring capability or maturity.
requirement
A recorded description of an aspect, performance, or capability required by a user or customer.
requirements analysis
Tasks that determine the needs or conditions to meet a new or altered solution, accounting for
multiple perspectives, e.g., balancing stakeholder needs and constraints, allocation of
requirements to components, breaking down complex requirements to lower level requirements.
requirements elicitation
A technique used to gather knowledge or information to proactively identify and record
customer and end user needs.
requirements management
The process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and
then controlling change and communicating to relevant stakeholders. It is a continuous process
throughout a project.
requirements traceability
A record of the relationships between requirements and related requirements, implementations,
and verifications. (Refer to “bidirectional traceability.”)
Return On Investment (ROI)

The ratio of benefit of a process or solution improvement to implementation costs to determine
the value.
risk
A potential uncertain event that may be harmful or may negatively impact achieving objectives.
589
risk mitigation
A set of planned activities, which if performed, may minimize the probability or impact of the
risk.
root cause
The underlying source of a defect or problem.
senior management
The person or persons who provide the policy and overall guidance for the process, but do not
typically provide the direct day-to-day monitoring and controlling of the process. A senior
manager has authority to direct the allocation or reallocation of resources in support of
organizational process improvement effectiveness. A senior manager can be any manager who
satisfies this description, including the head of the organization.
Service Level Agreement (SLA)

A contract between a service provider, either internal or external, and the customer or end user
that defines the level of service expected from the service provider. SLAs are output-based in
that their purpose is specifically to define what the customer will receive. SLAs do not define
how the service itself is provided or delivered.
service system
An integrated and interdependent combination of components that satisfies stakeholder
requirements.
service system component

A process, work product, person, consumable, customer, or other resource required for a
service system to deliver value. Service system components can include components owned by
the customer or a third party.
service system consumable
An item used by the service system that ceases to be available or becomes permanently
changed by its use during the delivery of a service.
shared vision
A common understanding of guiding principles, including mission, objectives, expected behavior,
values, and final outcomes, developed and used by a project or work group.
size
Number of items, or volume of work effort or work products being produced, such as activities,
pages, requirements, number of components, solutions. Use size as a basis for scoping when
producing estimates and plans.
solution
A product, product component, service, service system, service system component, or delivered
or acquired product or service.
590
solution component
A work product that is a building block of the solution. Solution components are integrated to
produce the solution. There can be multiple levels of solution components. (Refer to “product
component.”)
special cause of variation

A cause of process variation that is a result of a known factor that results in a non-random
distribution of output. Also referred to as “exceptional” or “assignable” cause variation and is
temporary in nature and not an inherent part of the process. (Refer to “common cause of
variation.”)
stable process
The state in which special causes of process variation have been removed from the process and
prevented from recurring. In a stable process, only common cause variation of the process
remains. (Refer to “capable process”, “common cause of variation”, and “special cause of
variation.”)
Statement Of Objectives (SOO)

The recorded top-level objectives of an acquisition or procurement, used to guide discussions
and negotiations between the acquirer and the supplier.
Statement Of Work (SOW)

A description of work to be performed and their respective groupings of tasks or activities.
(Refer to “memorandum of agreement.”)
statistical and other quantitative techniques

The term “statistical and other quantitative techniques” is used to acknowledge that while
statistical techniques are required, other quantitative techniques can also be used effectively.
Analytic techniques that allow parameters describing a task or work product to be quantified.
Use statistical and other quantitative techniques to:
• Analyze variation in process performance
• Monitor the selected processes that drive achieving quality and process performance
objectives
This term is used at levels 4 and 5 where practices describe how statistical and other
quantitative techniques are used to improve understanding of work group and organizational
processes and performance. (Refer to “statistical techniques” and “quantitative management.”)
statistical process control

Statistical analysis that identifies common and special causes of process variation and seeks to
maintain process performance within limits. (Refer to “common cause of variation”, “special
cause of variation”, and “statistical techniques.”)
statistical techniques
Mathematical techniques used with the collection, analysis, interpretation, and presentation of
masses of numerical data to understand process variation and predict process performance.
591
Examples include sampling techniques, analysis of variance, chi-squared tests, regression

analysis, and process control charts.
subprocess
A process that is part of a larger process. Subprocesses can be further decomposed into
subprocesses and/or process elements. (Refer to "process”, "process description”, and "process
element.”)
supplier
An entity having an agreement with an acquirer to design, develop, manufacture, maintain,
modify, deliver, or supply solutions under terms of an agreement. Examples include individuals,
partnerships, companies, corporations, and associations. (Refer to “acquirer.”)
supplier deliverable
An item to be provided to an acquirer or other recipient as specified in an agreement. The item
can be a document, hardware or software item, a service, a solution, or any type of work
product.
systems engineering
Interdisciplinary approach governing technical and managerial effort required to transform a set
of customer needs, expectations, and constraints into solutions and to support solutions
throughout their lifecycle.
tailoring
Developing or adapting a process description or work product according to organizational
defined standard guidelines to achieve a result. For example, a project develops its tailored
process from the organization’s set of standard processes to meet objectives, constraints within
the project environment. (Refer to “organization’s set of standard processes” and “process
description.”)
tailoring guidelines
Organizational guidelines that enable individuals, projects, and organizational functions to
appropriately adapt standard processes for their use. Tailoring guidelines may allow additional
flexibility when dealing with less critical processes or those that only indirectly affect business
objectives. (Refer to “organization’s set of standard processes” and “tailoring.”)
technical data package

A set of work products and information used to implement the design, e.g., coding standards,
version control information, and engineering drawings.
technical performance
Characteristic of a process or solution generally defined by a functional or technical requirement
that is often recorded in a contract or Statement Of Work.
trade study
An evaluation of alternatives, based on criteria and systematic analysis, to select the best
alternative for attaining determined objectives.
592
unit testing
Testing of individual hardware or software units.
version control
Identifies the correct versions of work products and ensures the right versions are available for
use or for restoring to a previous version. Also includes the establishment and maintenance of
baselines and the identification of changes to baselines to obtain previous baselines.
Work Breakdown Structure (WBS)

A list of tasks and activities, related work elements and their relationship to each other and to
the end product or service.
work product
An output from a process, activity, or task and may be a stand-alone output, or part of a
solution.
work product and task attributes

Characteristics of solutions and tasks used to estimate work. These characteristics often include
size, complexity, weight, form, fit, and function. Characteristics are typically used as one input
to deriving other resource estimates, e.g., effort, cost, schedule. (Refer to “work product.”)
593
Appendix F: Abbreviations
Abbreviation Term
CA Capability Area
CAR Causal Analysis and Resolution
CCB Change or Configuration Control Board
CCD Career and Competency Development
CDR Critical Design Review
CL Capability Level
CM Configuration Management
CMM Capability Maturity Model
CMMI Capability Maturity Model Integration
CMMI-DEV CMMI for Development
CMMI-PPL CMMI for People Management
CMMI-SPM CMMI for Supplier Management
CMMI-SVC CMMI for Services
COCO Communication and Coordination
COMP Compensation and Rewards
CONT Continuity
COOP Continuity Of Operations
COTS Commercial Off-The-Shelf
CPM Critical Path Method
DAR Decision Analysis and Resolution
DEV Development
DSS Develop Secure Solutions
ES Ensuring Safety
EST Estimating
EVMS Earned Value Management System
EWG Empowered Workgroups
FMEA Failure Mode and Effects Analysis
FMECA Failure Mode, Effects, and Criticality Analysis
GOV Governance
GQM Goal Question Metric
IBR Integrated Baseline Review
594
Abbreviation Term
II Implementation Infrastructure
IMS Integrated Master Schedule
IRP Incident Resolution and Prevention
IT Information Technology
IV&V Independent Verification and Validation
MC Monitor and Control
MDD Method Definition Document
ML Maturity Level
MPM Managing Performance and Measurement
MPS Managing and Planning Security
MPSF Managing and Planning Safety
MSS Managing Secure Suppliers
MST Managing Security Threats and Vulnerabilities
MTBF Mean Time Between Failures
MTTF Mean Time to Failure
OT Organizational Training
OTRR Operational Test Readiness Review
PA Practice Area
PAD Process Asset Development
PAL Process Asset Library
PCM Process Management
P-CMM People-CMM
PDR Preliminary Design Review
PERT Program Evaluation and Review Technique
PG Practice Groups
PI Product Integration
PLAN Planning
PPL People Management
PQA Process Quality Assurance
PR Peer Reviews
PRR Production Readiness Review
PSSW Planning and Supporting Security in Work
PWS Performance Work Statement
595
Abbreviation Term
QPPO Quality and Process Performance Objectives
RASCI Responsible, Accountable, Support, Consulted, Informed
RDM Requirements Development and Management
RFP Request For Proposal
ROI Return on Investment
RSK Risk and Opportunity Management
SAM Supplier Agreement Management
SCAMPI Standard CMMI Appraisal Method for Process Improvement
SDM Service Delivery Management
SEI Software Engineering Institute
SHP Sustaining Habit and Persistence
SLA Service Level Agreement
SME Subject Matter Experts
SOO Statement Of Objectives
SOP Standard Operating Procedure
SOW Statement Of Work
SPM Supplier Management
SRR System Requirements Review
SSS Supplier Source Selection
STSM Strategic Service Management
SVC Services
SW-CMM Software CMM
SWM Staffing and Workforce Management
SWOT Strength, Weakness, Opportunity, and Threat
TRA Technology Readiness Assessment
TRR Test Readiness Review
TS Technical Solution
VV Verification and Validation
WBS Work Breakdown Structure
596
Appendix G: CMMI Development History

The Capability Maturity Model (CMM) was developed in the late 1980s/early1990s and version
1.0 was released in 1991. CMMI originally was a combination of software and systems
engineering CMMs along with product line and supplier sourcing models first released in 2000.
The release timeline is listed below:
• 1984 Carnegie Mellon University awarded funding to establish the Software Engineering
Institute (SEI)
• 1987 SEI releases a software process maturity framework and maturity questionnaire to
support organizations in improving their software process.
• 1991 Software CMMI (SW-CMM) V1.0
• 1993 SW-CMM V1.1
• 1995 People CMM (P-CMM) V1.0
• 1997 SW-CMM work on CMM V1.2 stopped
• 1999 Undersecretary of Defense (J. Gansler) Memo – SW-CMM ML3 Required for ACAT 1
programs
• 2000 CMMI V1.02
• 2002 CMMI V1.1
• 2004 CMMI-ACQ V1.0
• 2006 CMMI V1.2 (Included CMMI-DEV)
• 2009 CMMI-SVC V1.2 (First release to stay in sync with CMM-DEV version numbering)
• 2009 P-CMM V2.0 Second Edition
• 2010 CMMI V1.3 (Included CMMI-DEV, -SVC and –ACQ)
• 2018 CMMI V2.0 Product Suite, including views for Development, Services, Supplier
Management
597
Appendix H: References
CMMI Institute. CMMI for Acquisition, Version 1.3, Pittsburgh, PA: November 2010.
http://cmmiinstitute.com/cmmi-models
CMMI Institute. CMMI for Development, Version 1.3. Pittsburgh, PA, August 2006.
CMMI Institute. CMMI for Services, Version 1.3. Pittsburgh, PA: November 2010.
CMMI Institute. Data Management Maturity Model, Version 1.3. Pittsburgh, PA: 2011.
CMMI Institute. People CMM, Version 2.0. Pittsburgh, PA: November 2010.
CMMI Institute. Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A,
Version 1.3, Pittsburgh, PA: 2011. http://cmmiinstitute.com/cmmi-models
Crosby, Philip B. Quality Is Free: The Art of Making Quality Certain. New York: McGraw-Hill,
1979.
Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT Center for Advanced Engineering,
1986.
Humphrey, Watts S. Managing the Software Process. Reading, MA: Addison-Wesley, 1989.
Institute of Electrical and Electronics Engineers. Multiple Standards. New York: IEEE, 2017.
https://www.ieee.org/standards/index.html
International Organization for Standardization. ISO 9001:2015 Quality management systems -

Requirements. ISO, 2015. http://www.iso.org/iso/iso_catalogue/.
ISACA, COBIT 5.0. Rolling Meadows, IL: ISACA,

2012.http://www.isaca.org/COBIT/Pages/COBIT-5-Framework-product-page.aspx
Juran, Joseph M. Juran on Planning for Quality. New York: Macmillan, 1988.
SAE International/Electronic Industries Alliance standard ANSI/EIA-748, Earned Value

Management Systems (EVMS), Version C, Warrendale, PA, April 2014.
Shewhart, Walter A. Economic Control of Quality of Manufactured Product. New York: Van
Nostrand, 1931.
Wheeler, Donald J. Understanding Variation The Key to Managing Chaos. SPC Press, Knoxville,
TN: 2000.
598
Appendix I: Acknowledgements
Corporate Sponsors
CMMI Institute is grateful to the organizations who sponsored the development of the CMMI
V2.0 Product Suite. These organizations provided crucial input, direction, and resources that
made the leap to the CMMI V2.0 Product Suite possible.
“CMMI V2.0’s benchmark appraisal method has improved our confidence in the results and
lowered the overall lifecycle cost of our appraisals. In addition, using the sustainment appraisal
approach with brief mid-cycle evaluations has increased our focus on both process
implementation and improvement.”
-Allan McQuarrie, Deputy Vice President/General Manager, Technology Solutions, BAE Systems
“We are very proud that Siemens as a thought leader contributed to the CMMI V2.0. Topics
such as Agile, Lean, Security, and Performance Management are essential for our business. We
are welcoming very much that these are now strengthened in the new CMMI.”
-Jürgen Kirsch, Vice President CD C PLM Consulting, Siemens
599
CMMI V2.0 Product Suite Leadership Team

The CMMI V2.0 Project was led by a committed team made up of individuals from sponsor
organizations and the CMMI Institute. This team used the insights from market research to
build a product suite and strategy to meet the needs of industry today, while creating a
platform that will grow and change for the needs of the future. Thank you to the CMMI V2.0
Leadership Team!
• Kirk Botula, CEO, CMMI Institute
• Joe Callahan, Director of Marketing, CMMI Institute
• Timothy Crumbley, NASA Software Engineering Program Executive, NASA
• Ryan Fulmer, Project Manager, CMMI Institute
• Sally Godfrey, Emeritus, NASA
• Craig Hollenbach, Technical Fellow; Manager of Performance and Governance,
Engineering Center of Excellence, Northrop Grumman Corporation
• Michael LaBarge, Consultant, Performance and Methods Consulting
• Ron Lear, Architect of CMMI Institute Products, CMMI Institute
• Lisa McConihe, Senior Principal Engineer, BAE Systems
• Darlene Moore, Quality Manager, CMMI Institute
• Sheela Nath, Business Writer, CMMI Institute
• Lynn Penn, President, Performance and Methods Consulting
• Winfried Russwurm, Principal Consultant, Siemens AG
• Prabhakar Sundar, Director - Global, Honeywell International
• Reewa Saluja, Director, CMMI Product Solutions, CMMI Institute
• Kevin Schaaff, CMMI Practice Leader, CMMI Institute
• Alexander Stall, CMMI Practice Leader, CMMI Institute
• Katie Tarara, Manager of Partner and Client Services, CMMI Institute
• Kathryn Tate, Training Development Manager, CMMI Institute
• Dan Torrens, COO, CMMI Institute
• Sean Ways, IT Manager, CMMI Institute
• Rusty Young, CMMI Architect - Emeritus, CMMI Institute
600
CMMI V2.0 Product Suite Developers

These Product Developers worked together with the Leadership Team to build the content,
materials, and systems for CMMI V2.0. Thank you to the Development team of Product
Developers!
• Madison Borgmann, UX Designer, CMMI Institute
• Tony Destro, Senior Web Developer, CMMI Institute
• Kieran Doyle, President, Excellence in Measurement Technology
• Adrian Gill, Founder, Gillpage Associates
• Jason Godesky, UI/UX Engineer, CMMI Institute
• Fred Haigh, VP, COO, Haigh Group
• Mary Anne Herndon, Consultant, Transdyne Corporation
• Paul Kimmerly, Consultant, Double Play Process Diagnostics
• Michele Lamptey-Uhrich, Manager, Process Initiatives, Northrop Grumman Corporation
• Brian Mack, Senior QA Analyst, CMMI Institute
• Winifred Menezes, Consultant, Freya Consulting
• Rajesh Naik, Founder Partner, QAI India
• Heather Oppenheimer, Senior Partner, Oppenheimer Partners
• Guido Paolano, Principal Engineer, CMMI Institute
• Madhumita Poddar Sen, Madhumita
• Neil Potter, Consultant, The Process Group
• Enrique Roman, Consultant, Innevo
• Thomas Seckel, Principal Engineer, Northrop Grumman Corporation
• Agapi Svolou, Owner, Alexanna
• Richard Waina, Principal Consultant, Multi-Dimensional Maturity
601
Contributors to CMMI V2.0 Product Suite

Many individual contributors volunteered their time and expertise to make CMMI V2.0 possible.
They provided insight from their years of experience and helped the developers create better
products. Thank you to these CMMI V2.0 contributors!
• Peter Barletto, Global Process Solutions
• Richard Bechtold, Abridge Technology
• Scott Bender, Aetna
• William Bettesworth, Honeywell International
• Bradley Bittorf, Raytheon
• Daniel Blazer, Leidos
• Petr Bohacek, Honeywell International
• Antonio Braga, Crest Consulting
• Glyn Davies, BAE Systems
• Juliet Davis, Boeing
• Jeff Dotseth, General Dynamics
• John Ekas, CMMI Institute
• Valeria Franzitta, Robert Bosch GmbH
• Maggie Glover, Excellence in Measurement Technology
• Luciano Guerrero, Procesix
• Jean-Yves Guilbaud, Inspearit
• Satinder Kaur, CMMI Institute
• Ravindra Khetan, RH Process Consulting
• Randy Kitano, ESPN
• Gary Lunsford, Gary Lunsford Consulting
• Monika Maidl, Siemens AG
• Diane McDonald, StepUp Solutions
• Amanda Parrotte, CMMI Institute
• Dan Payne, ABI Consultants LLC
• David Quinn, MOSAIC Technologies Group
• Siva Ravuri, Wabtec
• John Ryskowski, John F Ryskowski Consulting
• Mary Segnit, Harris Corporation
• Anandkumar K. Shelat, KPMG
• Marian Tadros, TRI EXL
602
• Geoff Terrell, CMMI Institute

• Kerry Trujillo, Raytheon
• Dean Venable, Lockheed Martin Corporation
• David Walker, David Walker SPCS
• Beth Wise, Boeing
• Sreeramamurthy Yellayi, SPA Business Services
• Christian Zion, Thales
603
Reviewers for CMMI V2.0 Product Suite

Over 100 people with years of experience using CMMI reviewed the various pieces of the CMMI
V2.0 Product Suite and provided their input and feedback. Their comments—thousands of
them—greatly strengthened the final product. Thank you to the CMMI V2.0 reviewers!
• Ahmed Abd El Aziz • Inigo Garro • Fei Li
• Drew Allison • Yasser Ghanim • Binshan Liao
• Délio Almeida • Aditya Goel • Mirko Lovo
• Lemis Altan • Sharonlyne Graves • Mukul Madan
• Naoya Anada • David Greer • Gururaj Managuli
• Shane Atkinson • César Pablo Gutiérrez • Kaliappan Marappa
Martinez
• Joachim Bauchrowitz • Don Marohl
• Michael Hallinan
• Yan Bello • Larry McCarthy
• Kileen Harrison
• Bonnie Bollinger • Eugene McGuire
• Zhou Heng
• Eileen Bozzolo • Karen McKeown
• Casimiro Hernandez Parro
• Paul Byrnes • Takeshige Miyoshi
• Yanjun (Jim) Hu
• Maria Eugenia Caetano • Deke Moellerd
• Shu-Min Hwang
• Arnaud Chivard • Jyoti Mohile
• Nevine Iskandar
• Po-Ching (Antoine) Chuang • Cecilia Montero
• Seongkyu Jeong
• PJ Corum • Enrique Morey
• Kent Johnson
• Claudio Costa • Manpreet Mudahar
• Ho-Won Jung
• Mira Culley • Boris Mutafelija
• Himanshu Karkhanis
• Jeff Dalton • Raghavan Nandyal
• Mangesh Katalkar
• Sundar Gopal Das • Hasan Syed Niaz
• Muhammad Furqan Khan
• David Dayton • Gary Norausky
• Takami Kihara
• Christophe Debou • Yoetsu Otaki
• Sungil Kim
• Huey Der Chu • Pat O'Toole
• Denise Kirkham
• Sankararaman Dhandapani • Francois Ouellette
• Ralf Kneuper
• Yasser Dakroury • Dilek Ozdemirci
• Galina Knopman
• Saswata Dutta • Geetha Parthasarathy
• Alexander Kondakov
• Emily Finnegan • Malcom Patrick
• Krishnamurthy
• Livia Franzitta • Rich Pavlik
Kothandaraman
• Kathy Gallucci • Mariana Perez-Vargas
• Moustanir Lamnabhi
• Roger Gamage • Erwin Petry
• Beth Layman
• Sam Gao • Marilyn Phillips
• Peter Leeson
604
• William Pierce • Hitesh Sanghavi • Valter Tozzetti

• Louis Poulin • Giuseppe Satriani • Michael Trombley
• Shawn Presson • Vladimir Savin • Srinivasa Rao Tumu
• Teenu Puri • Henry Schneider • Pieter van Zyl
• Kris Puthucode • Joe Schofield • Sankaran Venkataramani
• Pascal Rabbath • Pamela Schoppert • Seshadri Venkatesan
• Parthasarathy • Balaji Selvaraju • Richard Waina
Ramachandran
• Prabhuu Sinha • Melvyn Wahlberg
• Puthucode Ratnagiri Ganesh
• Samiya Slim • Edward Weller
• Aihua Ren
• Kathy Smith • Mingqing Xu
• Jialin (Dylan) Ren
• Daniele Sorrentino • Atsushi Yamada
• Leigh Riley
• Srijith Sreenivasan • Xuefeng (James) Yin
• Paul Riviere
• Sanjay Srinivasan • Vincent Yip
• Viviana Rubinstein
• Kimberly Stewart • Bo (Brian) Yu
• Jesús Sánchez
• Beril Tasdemir • Wei (Clark) Zhou

V20FullModel PDF

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

V20FullModel PDF

Încărcat de

Drepturi de autor:

Formate disponibile

2019-08-06 17:35:49 This copy is licensed solely to Solangel Rico, who agrees not to reproduce, duplicate, copy, sell,

resell, assign, transfer or exploit any portion of this

Copyright © 2018 CMMI Institute

THIS CMMI INSTITUTE MATERIAL IS FURNISHED ON AN “AS-IS” BASIS.

Document Change History

Version Date Description

2.1 4 December 2018 Updates include:

CMMI V2.1 Model

Part One: About CMMI and Executive Summary ............................................................ 9

Part Two: Successfully Adopting CMMI ......................................................................... 35

Part Three: Process Persistence and Habit .................................................................. 40

Part Four: Achieving High Maturity ................................................................................ 43

Practice Areas ............................................................................................................. 48

Part Five: Practice Areas ............................................................................................... 48

Configuration Management (CM) .................................................................................. 66

Continuity (CONT) ......................................................................................................... 80

Decision Analysis and Resolution (DAR)....................................................................... 94

Estimating (EST) ......................................................................................................... 108

Governance (GOV) ..................................................................................................... 126

Implementation Infrastructure (II) ................................................................................ 142

Incident Resolution and Prevention (IRP) ................................................................... 154

Managing Performance and Measurement (MPM) ..................................................... 168

Monitor and Control (MC) ............................................................................................ 226

Organizational Training (OT) ....................................................................................... 252

Peer Reviews (PR) ...................................................................................................... 267

Planning (PLAN) ......................................................................................................... 276

Level 2 ................................................................................................................................................ 286

Process Asset Development (PAD) ............................................................................. 320

Process Management (PCM) ...................................................................................... 342

Process Quality Assurance (PQA)............................................................................... 366

Product Integration (PI) ............................................................................................... 378

Requirements Development and Management (RDM)................................................ 397

Risk and Opportunity Management (RSK) .................................................................. 425

Service Delivery Management (SDM) ......................................................................... 442

Strategic Service Management (STSM) ...................................................................... 458

Supplier Agreement Management (SAM) .................................................................... 468

Level 4 ................................................................................................................................................ 489

Supplier Source Selection (SSS) ............................................................................... 491

Technical Solution (TS) ............................................................................................... 506

Verification and Validation (VV) ................................................................................... 524

Appendices ................................................................................................................ 536

Part Six: Appendices ................................................................................................... 536

Figure 1. Why Build Capability?

Why use the CMMI?

Figure 2. Why use CMMI?

Improve Your Performance

Figure 3. Driving Performance through Capability

Model Structure and Content

Model Content Organization

Figure 4. Model Content Organization

CMMI V2.0 Product Suite

Figure 5. CMMI V2.0 Product Suite

Figure 6. Integrated CMMI Product Suite

Figure 7. Structural vs. Content Architecture

Figure 8. CMMI Model Structure

Figure 9. CMMI Model Component Structure

Figure 10. CMMI Model Component Structure - Views

Figure 11. Planning and Managing Work Capability Area View

Categories for Capability Areas

Figure 12. Categories and Associated Capability Areas

• Organizations typically have challenges in addressing complexity and managing change.

Practice Area (PA)

Figure 13. Practice Area Organization