CMMIModelV3 0

2023-11-20 21:41:42 This copy is licensed solely to Jean Franco Cespedes Pasion, who agrees not to reproduce, duplicate,
copy, sell, resell, assign, transfer or exploit

any portion of this document without express written permission by ISACA. Usage by others is prohibited.
2
Copyright © 2023 ISACA
THIS ISACA® MATERIAL IS FURNISHED ON AN “AS-IS” BASIS.
TO THE MAXIMUM EXTENT ALLOWED BY LAW, ISACA 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 PEFORMANCE SOLUTIONS ECOSYSTEM, CMMI METHOD DEFINITION
DOCUMENT, CMMI ADOPTION GUIDANCE, CMMI MODEL, CMMI TRAINING, CMMI MODEL
VIEWER (“CMMI CONTENT”), CMMI APPRAISAL SYSTEM, CMMI COURSE MANAGEMENT
SYSTEM, AND CMMI WEBSITE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE, NONINFRINGEMENT, USAGE OF TRADE, AND COURSE
OF DEALING OR PERFORMANCE.
ISACA 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 ISACA. You are solely responsible for your use
of the CMMI Content, and agree to defend, indemnify and hold ISACA harmless from any
claims, liability, damages, costs or expenses incurred by ISACA arising from your use of the
CMMI Content.
Document Change History

Version Date Description
3.0 6 April 2023 Refer to Release Notes,
https://cmmiinstitute.com/resource-files/public/cmmi-
model-materials/cmmi-model-release-notes, for change
information.
2023-11-20 21:41:42 This copy is licensed solely to Jean Franco Cespedes Pasion, who agrees not to reproduce, duplicate, copy, sell, resell, assign, transfer or exploit
3
CMMI V3.0 - Overview

Table of Contents
Part One: About CMMI and Executive Summary ........................................................ 5
Why use the CMMI? ........................................................................................................ 7

CMMI Performance Results and Benefits ....................................................................... 8
Improve Your Performance.............................................................................................. 9
Purpose ......................................................................................................................... 10
Audience ....................................................................................................................... 10
Model Structure and Content ........................................................................................ 10
Model Content Organization...........................................................................................11
CMMI Performance Solutions Overview.........................................................................11
View .................................................................................................................................... 17
Domains .............................................................................................................................. 18
Capability Area .................................................................................................................... 18
Categories for Capability Areas ........................................................................................... 19
Practice Area (PA) ............................................................................................................... 21
Practice Group .................................................................................................................... 22
Practices ............................................................................................................................. 25
Additional Content Characteristics....................................................................................... 26
Explanatory Versus Context Specific ................................................................................... 28
Part Two: Successfully Adopting CMMI .................................................................... 30
Elevating Performance through Process Improvement ................................................. 30
Part Three: Process Habit and Persistence .............................................................. 34
Sustaining Habit and Persistence ................................................................................. 35

Governance ........................................................................................................................ 35
Implementation Infrastructure .............................................................................................. 35
Part Four: Achieving High Maturity ........................................................................... 37
4
List of Figures
Figure 1. Why Build Capability? ........................................................................................... 5
Figure 2. Why use CMMI? ................................................................................................... 7
Figure 3. Driving Performance through Capability ................................................................. 9
Figure 4. Model Content Organization .................................................................................11
Figure 5. CMMI Performance Solutions Ecosystem ...............................................................12
Figure 6. Integrated CMMI Products ...................................................................................13
Figure 7. CMMI Model Structure .........................................................................................14
Figure 8. CMMI Component Structure .................................................................................15
Figure 9. CMMI Component Structure - Views......................................................................17
Figure 10. Domain Descriptions ..........................................................................................18
Figure 11. Planning and Managing Work Capability Area View ...............................................18
Figure 12. Categories and Associated Capability Areas..........................................................20
Figure 13. Practice Area Organization .................................................................................22
Figure 14. Practice Group Level Characteristics ....................................................................23
Figure 15. Practice Area Versus Practice Structure ...............................................................25
Figure 16. Example Icon, DAR ............................................................................................26
Figure 17. Model Content Relationships...............................................................................27
Figure 18. Four Stages of Process Discipline ........................................................................30
Figure 19. Four Characteristics of Process Habit and Persistence ...........................................34
Figure 20. High Maturity Foundational Building Blocks ..........................................................38
Figure 21. High Maturity QPPO Funnel ................................................................................39
Figure 22. High Maturity Capability Area and Practice Area Relationships ...............................40
Figure 23. Maturity Levels 2 & 3 Versus 4 & 5 .....................................................................41
Figure 24. Using High Maturity to Determine if Work Should be Accepted ..............................43
Figure 25. Two Approaches to Improvement .......................................................................44
5
Part One: About CMMI and Executive Summary

Capability Maturity Model® Integration (CMMI®) 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, now part of
ISACA®. At its heart, the CMMI provides a clear roadmap for building, improving, and sustaining
capability. Figure 1. Why Build Capability? provides some key reasons to build capability.
Figure 1. Why Build Capability?
The architecture and design of CMMI Performance Solutions ecosystem, formerly 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 using recorded processes for a
disciplined and consistent approach for achieving performance against business objectives
related to:
• Cost Management
• Customer Satisfaction
• Functionality
• Organization Finance
• Process
• Productivity
• Quality
• Safety
6
• Schedule
• Security
• Staff Development
• Supplier
7
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 performance improvement program needs to be in place
• The focus of improvement needs to be on process performance and resulting outcomes
and work products
• Executive management must visibly and actively support improvement efforts
Figure 2. Why use CMMI? summarizes the results of an assessment of capabilities and
processes that CMMI directly addresses.
Figure 2. Why use CMMI?
8
CMMI Performance Results and Benefits

CMMI Performance Solutions is a proven, outcome-based performance improvement ecosystem
providing faster, better, and cheaper results. CMMI is the globally accepted model that
improves and enhances organizational capability and performance. CMMI provides a prioritized
pathway to build and implement new capabilities that deliver consistently measurable results
and outcomes.
For 25+ years, high-performing organizations have achieved clear, sustainable business results
with ISACA’s CMMI. The CMMI has evolved over time from software engineering to multiple
domains, helping organizations around the world, in any industry, understand their current level
of capability and performance and offer a guide to optimize business results.
Recent performance results from organizations adopting CMMI show consistent, effective,
capability and performance improvements in multiple industries and geographies. The most
recent analysis of the CMMI performance improvement results is available from the CMMI
Performance Report Summary, located on the CMMI Resource Center at
https://cmmiinstitute.com/resources.
In the last several years, over 5000 appraised organizations reported their “before and after”
improvement objectives in the required CMMI Performance Report with an astounding 81.3%
achievement success rate for their targeted improvement objectives and another 3.5% soon to
be achieved for a total of almost 85% across key areas such as quality, cost management,
schedule performance, productivity and more. Each of these results was identified and achieved
by the organizations being appraised against CMMI, with the resulting performance
improvements independently corroborated by independent CMMI appraisal teams.
9
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. Performance should be managed at
all levels in the business. If performance does not meet business needs and objectives, then
process improvement is the key driver for raising performance to the needed level. Figure 3.
Driving Performance through Capability provides a summary of how CMMI addresses
performance and capability improvement.
Figure 3. Driving Performance through Capability
10
Purpose
The CMMI 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 requires consideration of the
organization’s specific context and associated domains. 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, projects, and domains
• 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 Performance Solutions ecosystem, ISACA has published
guidance to help you begin or continue your performance improvement journey by adopting
CMMI. Refer to Appendix C: CMMI Adoption Resources, for the CMMI adoption 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
supports providing content to users in different formats, different levels of detail, and with
example best practice activities and work products depending on the applicable domains. This
allows for a robust set of information that is relevant to specific uses and needs.
11
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
(PAs), and Appendices. Refer to Figure 4. Model Content Organization.
Figure 4. Model Content Organization

Part
Title Description
Number
Section: Overview
Part 1 About CMMI Provides an overview of the CMMI Performance Solutions
ecosystem, including an Executive Summary of the model.
Part 2 Successfully Provides the context for understanding and using CMMI in
Adopting CMMI a manner that achieves tangible business results.
Part 3 Process Habit and Describes how to build and sustain business performance
Persistence improvement and capability throughout an organization.
Part 4 Achieving High Builds on initial performance success from adopting the
Maturity model 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 associated levels,
as well as the glossary, acronym list, index, and
acknowledgements.
CMMI Performance Solutions Overview

At its core, CMMI is a set of predefined and customizable views applicable to different domains
that are relevant to different businesses. The CMMI Performance Solutions ecosystem contains
five components as shown in Figure 5. CMMI Performance Solutions Ecosystem.
12
Figure 5. CMMI Performance Solutions Ecosystem
13
Figure 6. Integrated CMMI Products illustrates the relationship across the CMMI products and
systems. This integrated approach was designed to reduce the “stove piping” of CMMI
Performance Solution components.
Figure 6. Integrated CMMI Products
A CMMI architecture provides a flexible performance improvement model and structure that can
adapt to meet short- and long-term needs. The architecture and substructures can
accommodate existing and future models and content.
The CMMI architecture is designed to minimize 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 is accomplished by providing 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 design a view of the model to meet their
organization’s performance improvement needs. This enables the CMMI 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 suppliers. However, businesses rarely focus on only one domain, for example, besides
developing a product, a development organization may also provide help desk services to end
users. CMMI provides a platform to integrate all applicable domains and views and is
14
extendable based on organizational and market needs. This integrated and holistic approach to
performance improvement allows organizations to focus on the areas of improvement that they
find most relevant.
The format of the PA content follows a common modular structure. Figure 7. CMMI Model
Structure shows the high-level overview of the modular structure of the CMMI.
Figure 7. CMMI Model Structure
15
At the highest level, the CMMI is a container of PAs and composed of five components,
described in Figure 8. CMMI Component Structure.
Figure 8. CMMI Component Structure
16
17
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 development, security, safety, 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 9. CMMI
Component Structure - Views. For example:
• An organization may be operating under two application domains, software development
and help desk services. The organization could then choose the predefined views of CMMI
Development (CMMI-DEV) and CMMI Services (CMMI-SVC). And, if security was important
to the organization, CMMI Security (CMMI-SEC) could be easily included with the other
two model domains.
• An organization wanting to improve their work planning and management capability could
choose a view for the Planning and Managing Work Capability Area (refer to Figure 11.
Planning and Managing Work Capability Area View) to help them manage and improve
their work management performance
For more information regarding model views, refer to Appendix B: Predefined Model Views
– Maturity and Capability Levels.
Figure 9. CMMI Component Structure - Views
18
Constructing a view consists of selecting what CMMI components to include in the view.
Domains
A domain is an organizing principle in the CMMI, including both the model and appraisal
method. Domains are functionally similar groupings of PAs that are applicable or tailored to an
organization's primary capabilities, e.g., development for systems engineering or product
development. A domain is a type of view within CMMI. The list of current domains in CMMI are
defined in Figure 10. Domain Descriptions.
Figure 10. Domain Descriptions

Domain Capability Description
Data Governing and managing data and data quality
Development (DEV) Creating products or solutions, including hardware and software,
and their related components
People (PPL) Developing, retaining, and enabling the workforce to accomplish
objectives
Safety (SAF) Providing and maintaining safe products, services, and other
solutions
Security (SEC) Identifying and strengthening critical defenses and increasing
resilience against threats
Services (SVC) Building and delivering an intangible solution comprised of
activities or work
Suppliers (SPM) Managing a company, organization, or person that supplies or
provides products, services, or other solutions
Virtual (VRT) Delivering products, services, or other solutions from remote
locations
Capability Area
A Capability Area is a group of related PAs 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 that
describes a predefined set of PAs that make up a specific Capability Area. Capability Areas are a
type of a view. Figure 11. Planning and Managing Work Capability Area View illustrates a view
of the Planning and Managing Work Capability Area.
Figure 11. Planning and Managing Work Capability Area View
19
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
Performance Solutions ecosystem 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
20
Figure 12. Categories and Associated Capability Areas shows how the Capability Areas are
organized into the categories.
Figure 12. Categories and Associated Capability Areas
These category views 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.
21
• 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 PA is a set of practices that collectively describe the critical activities needed to achieve a
defined intent and value. PAs 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 PA which is important
and useful to better understand the meaning of the PA intent and required information
and may not be present for every PA. In some cases, this section includes required
information specific to a selected view when applicable.
• Explanatory PA Information
o Practice Summary
o Additional Information
o Related Practice Areas - The PAs 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 PA to support understanding and
implementation
o Practice groups allow for different ways of organizing similar information and
practices. For example, practice group 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.
22
Figure 13. Practice Area Organization shows a summary view of how CMMI PAs are organized.
Figure 13. Practice Area Organization
Practice Group
Within PAs, the practices are organized into a set of practice group levels labeled Level 1, Level
2, etc. which provide a path for performance improvement.
Each practice group level builds on the previous levels by adding
new functionality or sophistication resulting in increased capability.
23
Figure 14. Practice Group Level Characteristics provides a brief definition of the practice group
levels.
Figure 14. Practice Group Level Characteristics
Each practice group level:

• Builds on the practices at lower levels
• Represents an increase in functionality and capability
• May add new functionality
Practice group levels include the following characteristics:
• Practice Group Level 1
o Processes are performed, but may not be recorded in a process description
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
24
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
o Processes are performed in accordance with a recorded project or work level process
description
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
o Processes are performed and managed in accordance with a recorded organizational
level process description
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
o Processes are performed, managed, and analyzed statistically and quantitatively in
accordance with a recorded organizational level process description
o Use of statistical and other quantitative techniques to predict if quality and process
performance objectives will be achieved
o Understands special cause of variation statistically and manages progress against
quality and process performance objectives
o Processes are optimized statistically and quantitatively in accordance with a recorded
organizational level process description
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
o Understands common cause of variation, statistically and manages improvement
against quality and process performance objectives
The order of the practices in each PA and group does not imply or require a sequential order as
performed in a process. Processes that meet the intent of the PAs and practices may be
performed iteratively, in parallel, or in any other order that best meets the needs of an
organization’s business.
25
Practices
Similar to the structure of the PAs, the practices in the CMMI consists of:
1. Required Practice Information:
• Practice statement
• Value statement: Business value of using this component
• 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
• 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
Figure 15. Practice Area Versus Practice Structure provides a summary of required and
explanatory information for Practice Areas and practices.
Figure 15. Practice Area Versus Practice Structure
Language Conventions: In the CMMI Performance Solutions ecosystem, 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
26
• “or” as in “manage risks or opportunities” can mean managing either risks OR

opportunities OR both
Certain words in the CMMI Performance Solutions ecosystem 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

For more effective identification, recall and learning, each PA 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 PA
• Within the shape, a unique pictorial icon representing the intent of the PA
• The acronym for the PA
For example, Figure 16. Example Icon, DAR 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: Core Practice Areas, Categories, and Capability
Areas.
Figure 16. Example Icon, DAR
Figure 17. Model Content Relationships shows the complete set of relationships between the
categories, Capability Areas, and PAs.
27
Figure 17. Model Content Relationships
28
Explanatory Versus Context Specific

The CMMI 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
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 there are two types of informative material: “explanatory” and “context
specific”.
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. 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 explanatory information may include six areas of
information:
• Additional Explanatory Information
• Example Activities
• Example Work Products
• Related Practice Areas
• External links or information, e.g., training, templates, example assets
• Context Specific – refer to additional details below
The “Context Specific” section contains information that is relevant for a specific industry,
methodology, or discipline. The Context Specific information includes:
• Context Tag; provides identifier
• Context; provides explanation of industry methodology or discipline
• Explanatory information
Examples of contexts include:
• Agile Development
• Data
• Development
• DevSecOps
• People
• Safety
• Security
• Services
• Suppliers
29
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 and supports other methodologies, standards, or models such
as:
• AS9100
• Automotive SPICE
• COBIT
• ISO
• ITIL
• Kanban
• Lean
• NIST
30
Part Two: Successfully Adopting CMMI

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. For more information, refer to Appendix C: CMMI Adoption Resources.
Elevating Performance through Process Improvement

It is important to understand the linkage between an organization’s business performance and
process improvement. Because of this, an effective and sustainable improvement program
needs to be in place, focused on performance, and actively supported. Process improvement
instills discipline in the organization’s culture. This includes the way work is perceived, done,
and improved. Figure 18. Four Stages of Process Discipline 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.
Figure 18. 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 might be recognized, the ability to improve is
limited and is only achieved unintentionally.
31
Stage two, there is conscious realization that processes are ad hoc and unrecorded. The need
for performance improvement is recognized, and basic mechanisms for improvement are
initiated.
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, processes and performance are clearly understood and habitually and persistently
followed. Refer to section 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, 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.
• 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 fades.
• Communicate, communicate, communicate
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
32
by a majority of the people. Lack of communication is typically the number one issue in
employee satisfaction surveys,
Items that communication should cover include:
o What is 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 performance 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.
• Target the right level of detail
Focus on performance and process improvement, not implementing and deploying the
perfect process. “Do not let perfect be the enemy of good enough.” Process documents
need to be at the right level of detail. Know when you have reached the “good enough”
and then start improving as it is used. When recording processes:
o Record the process at an appropriate and understandable level of detail
o Understand that if the process is too prescriptive, it impacts adoption, and if it is
written too high level, the processes have little value
o Recognize that not every eventuality can be anticipated
o Determine the appropriate level of process control
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
33
o Brown bag lunches

o Virtual, hybrid, 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:
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.
• Plan for differences
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.
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. 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 and persistent. Since it takes time to adopt
new behaviors, process discipline can be fragile, especially in times of stress.
34
Part Three: Process Habit and Persistence

In the CMMI, the phrase “habit and persistence” describes the way of routinely doing business
and following and improving processes that an organization uses as part of its corporate
culture:
• Habit: A tendency or practice, especially one that is hard to give up
• Persistence: Firm or stubborn continuance in a course of action despite difficulty or
opposition
If a process is ignored, abandoned under pressure, or if disciplined execution of the process
erodes over time, then it is neither habitual nor persistent.
The CMMI is also not intended to be adopted only for purposes of passing an appraisal. An
organization adopting the CMMI to improve its performance and processes should consider this
an investment in the organization, with clear performance objectives and improved business
outcomes as the primary end-result. If an organization or team is going to invest their budget,
time, effort, and people into taking steps to improve their capabilities and performance, the
improvements should persist and continue to help the business.
When an organization begins a performance improvement initiative, the goal is for the
improvements to become the “way we do business”. In other words, the organization is forming
new habits. Figure 19. Four Characteristics of Process Habit and Persistence describes the four
key characteristics to understanding and creating habitual and persistent practices within an
organization.
Figure 19. Four Characteristics of Process Habit and Persistence
35
Note that the words “CMMI Practices” or “practices” do not appear in Figure 19. Four
Characteristics of Process Habit and Persistence. This is because the focus is on the business
process enduring and continually improving, not on a CMMI practice. This is an important
distinction in the CMMI Performance Solutions.
Sustaining Habit and Persistence

In the CMMI, the PAs in the Sustaining Habit and Persistence (SHP) Capability Area enable a
consistent and enduring 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
Governance (GOV) specifies practices for senior management in support of ways of working
that are relevant and important 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
• Providing adequate resources for process and performance improvement
• Ensuring that processes are aligned with business needs and objectives
• Monitoring the performance and achievements of the processes
• 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 practices.
Implementation Infrastructure
Implementation Infrastructure (II) describes the necessary infrastructure to build, follow,
sustain, and improve processes over time. The term “infrastructure” in this PA 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
36
• 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
• 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 practices.
37
Part Four: Achieving High Maturity

In the CMMI Performance Solution ecosystem, the term “High Maturity” involves the application
of statistical and other quantitative techniques to 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
• Implement the capability to predict and achieve consistent performance
• Increase schedule and cost performance
• Reduce rework
• Focus on innovation and being more competitive
• Have greater confidence in measurement indicators
38
Figure 20. High Maturity Foundational Building Blocks provides a summary of all Practice Group
Level 2 and 3 practices that are prerequisites to achieving High Maturity.
Figure 20. High Maturity Foundational Building Blocks
39
Figure 21. High Maturity QPPO Funnel shows the starting place of the pathway for achieving
High Maturity. All organizations have business objectives from which the organization measures
what is most meaningful to building their capabilities and achieving their performance
improvement objectives. Quality and Process Performance Objectives (QPPOs) are traceable to
those business and performance objectives and are the start of the “funnel” for narrowing down
the targets for applying High Maturity.
Figure 21. High Maturity QPPO Funnel
40
Figure 22. High Maturity Capability Area and Practice Area Relationships depicts the
relationships of all practice level 4 and 5 practices within the CMMI. While the relationships are
interrelated, it is a one-to-many relationship, all revolving around the organizational processes.
Figure 22. High Maturity Capability Area and Practice Area Relationships
Figure 23. Maturity Levels 2 & 3 Versus 4 & 5 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.
41
Figure 23. Maturity Levels 2 & 3 Versus 4 & 5
42
Data quality is an important attribute which enables High Maturity activities. Examples of the
impacts of poor data quality include:
• Inability to conduct hypothesis tests and predictive modeling
• Inability to manage quality and performance
• Inability to meet budget and schedule
• Ineffective process changes
• Improper architecture and design decisions
• 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 (PPBs) to manage work
o Target areas for improvement
o Evaluate the impact of proposed improvement on achieving Quality and Process
Performance Objectives (QPPOs)
43
o Develop PPBs and Process Performance Models (PPMs) to understand the relationships
among processes and sub-processes and their performance
• 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 typically 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 24.
Using High Maturity to Determine if Work Should be Accepted:
o If the distribution is represented by the left chart, most of the time the feature will be
delivered in ten weeks or more
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 24. Using High Maturity to Determine if Work Should be Accepted
In High Maturity, a statistical measure of variation 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 the ROI of the change
44
• Measure and determine effects of the change

Figure 25. Two Approaches to Improvement below illustrates that improvements can shift the
mean, reduce variation, or both. Understanding the average and the amount of variation
provide two different insights into process performance.
Figure 25. Two Approaches to Improvement
2
Copyright © 2023 ISACA-CMMI
THIS ISACA MATERIAL IS FURNISHED ON AN “AS-IS” BASIS.

WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY, REGARDING OR RELATING
TO THE CAPABILITY MATURITY MODEL INTEGRATION (CMMI), AND ALL MODEL CONTENT,
INCLUDING THE CMMI PERFORMANCE SOLUTIONS ECOSYSTEM, CMMI METHOD DEFINITION
CMMI Content.

information.
3
CMMI V3.0 Model – Practice Areas (PAs)

Table of Contents
Causal Analysis and Resolution (CAR) 18
CAR Overview ............................................................................................................... 18

Level 1........................................................................................................................... 21
CAR 1.1 .............................................................................................................................. 21
Level 2........................................................................................................................... 22
CAR 2.1 .............................................................................................................................. 22
CAR 2.2 .............................................................................................................................. 24
Level 3........................................................................................................................... 26
CAR 3.1 .............................................................................................................................. 26
CAR 3.2 .............................................................................................................................. 27
CAR 3.3 .............................................................................................................................. 29
CAR 3.4 .............................................................................................................................. 30
CAR 3.5 .............................................................................................................................. 31
Level 4........................................................................................................................... 33
CAR 4.1 .............................................................................................................................. 33
CAR 4.2 .............................................................................................................................. 34
Level 5........................................................................................................................... 36
CAR 5.1 .............................................................................................................................. 36
Configuration Management (CM) 37
CM Overview ................................................................................................................. 37
Level 1........................................................................................................................... 42
CM 1.1 ................................................................................................................................ 42
Level 2........................................................................................................................... 43
CM 2.1 ................................................................................................................................ 43
CM 2.2 ................................................................................................................................ 45
CM 2.3 ................................................................................................................................ 48
4
CM 2.4 ................................................................................................................................ 50
CM 2.5 ................................................................................................................................ 52
CM 2.6 ................................................................................................................................ 54
Continuity (CONT) 56
CONT Overview ............................................................................................................ 56

Level 1........................................................................................................................... 59
CONT 1.1 ............................................................................................................................ 59
Level 2........................................................................................................................... 60
CONT 2.1 ............................................................................................................................ 60
CONT 2.2 ............................................................................................................................ 61
CONT 2.3 ............................................................................................................................ 63
Level 3........................................................................................................................... 66
CONT 3.1 ............................................................................................................................ 66
CONT 3.2 ............................................................................................................................ 67
CONT 3.3 ............................................................................................................................ 69
Data Management (DM) 72
DM Overview ................................................................................................................. 72
Level 1........................................................................................................................... 74
DM 1.1 ................................................................................................................................ 74
DM 1.2 ................................................................................................................................ 74
Level 2........................................................................................................................... 77
DM 2.1 ................................................................................................................................ 77
DM 2.2 ................................................................................................................................ 79
Level 3........................................................................................................................... 82
DM 3.1 ................................................................................................................................ 82
DM 3.2 ................................................................................................................................ 84
5
Data Quality (DQ) 86
DQ Overview ................................................................................................................. 86
Level 1........................................................................................................................... 88
DQ 1.1................................................................................................................................. 88
DQ 1.2................................................................................................................................. 89
Level 2........................................................................................................................... 90
DQ 2.1................................................................................................................................. 90
DQ 2.2................................................................................................................................. 91
DQ 2.3................................................................................................................................. 92
Level 3........................................................................................................................... 94
DQ 3.1................................................................................................................................. 94
DQ 3.2................................................................................................................................. 96
Decision Analysis and Resolution (DAR) 98
DAR Overview ............................................................................................................... 98

Level 1......................................................................................................................... 102
DAR 1.1 ............................................................................................................................ 102
DAR 1.2 ............................................................................................................................ 103
Level 2......................................................................................................................... 104

DAR 2.1 ............................................................................................................................ 104
DAR 2.2 ............................................................................................................................ 106
DAR 2.3 ............................................................................................................................ 107
DAR 2.4 ............................................................................................................................ 108
DAR 2.5 ............................................................................................................................ 109
Level 3.......................................................................................................................... 111

DAR 3.1 ............................................................................................................................ 111
Enabling Safety (ESAF) 113
ESAF Overview ............................................................................................................113

Level 1..........................................................................................................................115
6
ESAF 1.1........................................................................................................................... 115

ESAF 1.2........................................................................................................................... 116
Level 2..........................................................................................................................117
ESAF 2.1........................................................................................................................... 117
ESAF 2.2........................................................................................................................... 119
ESAF 2.3........................................................................................................................... 121
Level 3......................................................................................................................... 125

ESAF 3.1........................................................................................................................... 125
ESAF 3.2........................................................................................................................... 127
ESAF 3.3........................................................................................................................... 129
Enabling Security (ESEC) 132
ESEC Overview .......................................................................................................... 132

Level 1......................................................................................................................... 136
ESEC 1.1 .......................................................................................................................... 136
ESEC 1.2 .......................................................................................................................... 137
Level 2......................................................................................................................... 138

ESEC 2.1 .......................................................................................................................... 138
ESEC 2.2 .......................................................................................................................... 140
ESEC 2.3 .......................................................................................................................... 142
ESEC 2.4 .......................................................................................................................... 145
Level 3......................................................................................................................... 149

ESEC 3.1 .......................................................................................................................... 149
ESEC 3.2 .......................................................................................................................... 154
ESEC 3.3 .......................................................................................................................... 159
Enabling Virtual Work (EVW) 162
EVW Overview ............................................................................................................ 162

Level 1......................................................................................................................... 164
EVW 1.1 ............................................................................................................................ 164
EVW 1.2 ............................................................................................................................ 165
Level 2......................................................................................................................... 166

EVW 2.1 ............................................................................................................................ 166
7
EVW 2.2 ............................................................................................................................ 170
Level 3......................................................................................................................... 172

EVW 3.1 ............................................................................................................................ 172
EVW 3.2 ............................................................................................................................ 174
Estimating (EST) 176
EST Overview ............................................................................................................. 176

Level 1......................................................................................................................... 180
EST 1.1 ............................................................................................................................. 180
Level 2......................................................................................................................... 181

EST 2.1 ............................................................................................................................. 181
EST 2.2 ............................................................................................................................. 182
EST 2.3 ............................................................................................................................. 185
Level 3......................................................................................................................... 190

EST 3.1 ............................................................................................................................. 190
EST 3.2 ............................................................................................................................. 191
Governance (GOV) 194
GOV Overview ............................................................................................................ 194

Level 1......................................................................................................................... 197
GOV 1.1 ............................................................................................................................ 197
Level 2......................................................................................................................... 199

GOV 2.1 ............................................................................................................................ 199
GOV 2.2 ............................................................................................................................ 203
GOV 2.3 ............................................................................................................................ 205
GOV 2.4 ............................................................................................................................ 209
Level 3......................................................................................................................... 212

GOV 3.1 ............................................................................................................................ 212
GOV 3.2 ............................................................................................................................ 213
Level 4......................................................................................................................... 215

GOV 4.1 ............................................................................................................................ 215
8
Implementation Infrastructure (II) 217
II Overview .................................................................................................................. 217

Level 1......................................................................................................................... 221
II 1.1 .................................................................................................................................. 221
Level 2......................................................................................................................... 222

II 2.1 .................................................................................................................................. 222
II 2.2 .................................................................................................................................. 224
Level 3......................................................................................................................... 227

II 3.1 .................................................................................................................................. 227
II 3.2 .................................................................................................................................. 228
II 3.3 .................................................................................................................................. 231
Level 4......................................................................................................................... 234

II 4.1 .................................................................................................................................. 234
Incident Resolution and Prevention (IRP) 236
IRP Overview .............................................................................................................. 236

Level 1......................................................................................................................... 239
IRP 1.1 .............................................................................................................................. 239
Level 2......................................................................................................................... 240

IRP 2.1 .............................................................................................................................. 240
IRP 2.2 .............................................................................................................................. 244
IRP 2.3 .............................................................................................................................. 245
Level 3......................................................................................................................... 247

IRP 3.1 .............................................................................................................................. 247
IRP 3.2 .............................................................................................................................. 248
Managing Performance and Measurement (MPM) 253
MPM Overview ............................................................................................................ 253

Level 1......................................................................................................................... 261
9
MPM 1.1............................................................................................................................ 261

MPM 1.2............................................................................................................................ 263
Level 2......................................................................................................................... 265

MPM 2.1............................................................................................................................ 265
MPM 2.2............................................................................................................................ 269
MPM 2.3............................................................................................................................ 279
MPM 2.4............................................................................................................................ 280
MPM 2.5............................................................................................................................ 283
MPM 2.6............................................................................................................................ 285
Level 3......................................................................................................................... 287

MPM 3.1............................................................................................................................ 287
MPM 3.2............................................................................................................................ 289
MPM 3.3............................................................................................................................ 290
MPM 3.4............................................................................................................................ 291
MPM 3.5............................................................................................................................ 293
MPM 3.6............................................................................................................................ 297
Level 4......................................................................................................................... 298

MPM 4.1............................................................................................................................ 298
MPM 4.2............................................................................................................................ 301
MPM 4.3............................................................................................................................ 303
MPM 4.4............................................................................................................................ 306
MPM 4.5............................................................................................................................ 309
Level 5......................................................................................................................... 313

MPM 5.1............................................................................................................................ 313
MPM 5.2............................................................................................................................ 314
MPM 5.3............................................................................................................................ 316
Managing Security Threats & Vulnerabilities (MST) 320
MST Overview ............................................................................................................. 320

Level 1 ......................................................................................................................... 324
MST 1.1 ............................................................................................................................ 324
MST 1.2 ............................................................................................................................ 325
Level 2......................................................................................................................... 326

MST 2.1 ............................................................................................................................ 326
MST 2.2 ............................................................................................................................ 329
MST 2.3 ............................................................................................................................ 331
MST 2.4 ............................................................................................................................ 332
10
Level 3......................................................................................................................... 334

MST 3.1 ............................................................................................................................ 334
MST 3.2 ............................................................................................................................ 337
MST 3.3 ............................................................................................................................ 338
Level 4......................................................................................................................... 340

MST 4.1 ............................................................................................................................ 340
Monitor and Control (MC) 343
MC Overview ............................................................................................................... 343

Level 1......................................................................................................................... 348
MC 1.1 .............................................................................................................................. 348
MC 1.2 .............................................................................................................................. 349
Level 2......................................................................................................................... 350

MC 2.1 .............................................................................................................................. 350
MC 2.2 .............................................................................................................................. 354
MC 2.3 .............................................................................................................................. 355
MC 2.4 .............................................................................................................................. 357
Level 3......................................................................................................................... 361

MC 3.1 .............................................................................................................................. 361
MC 3.2 .............................................................................................................................. 363
MC 3.3 .............................................................................................................................. 365
MC 3.4 .............................................................................................................................. 367
Organizational Training (OT) 369
OT Overview ............................................................................................................... 369

Level 1......................................................................................................................... 373
OT 1.1 ............................................................................................................................... 373
Level 2......................................................................................................................... 374

OT 2.1 ............................................................................................................................... 374
OT 2.2 ............................................................................................................................... 376
Level 3......................................................................................................................... 377

OT 3.1 ............................................................................................................................... 377
11
OT 3.2 ............................................................................................................................... 379

OT 3.3 ............................................................................................................................... 380
OT 3.4 ............................................................................................................................... 382
OT 3.5 ............................................................................................................................... 386
OT 3.6 ............................................................................................................................... 388
Peer Reviews (PR) 390
PR Overview ............................................................................................................... 390

Level 1......................................................................................................................... 393
PR 1.1 ............................................................................................................................... 393
Level 2......................................................................................................................... 394

PR 2.1 ............................................................................................................................... 394
PR 2.2 ............................................................................................................................... 395
PR 2.3 ............................................................................................................................... 397
PR 2.4 ............................................................................................................................... 399
Level 3......................................................................................................................... 400

PR 3.1 ............................................................................................................................... 400
Planning (PLAN) 402
PLAN Overview ........................................................................................................... 402

Level 1......................................................................................................................... 410
PLAN 1.1........................................................................................................................... 410
PLAN 1.2........................................................................................................................... 411
Level 2......................................................................................................................... 413

PLAN 2.1........................................................................................................................... 413
PLAN 2.2........................................................................................................................... 419
PLAN 2.3........................................................................................................................... 422
PLAN 2.4........................................................................................................................... 425
PLAN 2.5........................................................................................................................... 428
PLAN 2.6........................................................................................................................... 431
PLAN 2.7........................................................................................................................... 433
PLAN 2.8........................................................................................................................... 435
Level 3......................................................................................................................... 438

PLAN 3.1........................................................................................................................... 438
12
PLAN 3.2........................................................................................................................... 440

PLAN 3.3........................................................................................................................... 444
PLAN 3.4........................................................................................................................... 445
Level 4......................................................................................................................... 451

PLAN 4.1........................................................................................................................... 451
Process Asset Development (PAD) 454
PAD Overview ............................................................................................................. 454

Level 1......................................................................................................................... 458
PAD 1.1 ............................................................................................................................. 458
Level 2......................................................................................................................... 459

PAD 2.1 ............................................................................................................................. 459
PAD 2.2 ............................................................................................................................. 460
PAD 2.3 ............................................................................................................................. 461
Level 3......................................................................................................................... 462

PAD 3.1 ............................................................................................................................. 462
PAD 3.2 ............................................................................................................................. 463
PAD 3.3 ............................................................................................................................. 466
PAD 3.4 ............................................................................................................................. 472
PAD 3.5 ............................................................................................................................. 474
PAD 3.6 ............................................................................................................................. 476
Process Management (PCM) 478
PCM Overview ............................................................................................................ 478

Level 1......................................................................................................................... 481
PCM 1.1 ............................................................................................................................ 481
PCM 1.2 ............................................................................................................................ 482
PCM 1.3 ............................................................................................................................ 484
Level 2......................................................................................................................... 486

PCM 2.1 ............................................................................................................................ 486
PCM 2.2 ............................................................................................................................ 488
Level 3......................................................................................................................... 491

PCM 3.1 ............................................................................................................................ 491
13
PCM 3.2 ............................................................................................................................ 492

PCM 3.3 ............................................................................................................................ 493
PCM 3.4 ............................................................................................................................ 495
PCM 3.5 ............................................................................................................................ 497
PCM 3.6 ............................................................................................................................ 499
Level 4......................................................................................................................... 501

PCM 4.1 ............................................................................................................................ 501
Process Quality Assurance (PQA) 503
PQA Overview ............................................................................................................. 503

Level 1......................................................................................................................... 505
PQA 1.1............................................................................................................................. 505
Level 2......................................................................................................................... 506

PQA 2.1............................................................................................................................. 506
PQA 2.2............................................................................................................................. 508
PQA 2.3............................................................................................................................. 510
PQA 2.4............................................................................................................................. 511
Level 3......................................................................................................................... 513

PQA 3.1............................................................................................................................. 513
Product Integration (PI) 514
PI Overview ................................................................................................................. 514

Level 1......................................................................................................................... 518
PI 1.1 ................................................................................................................................ 518
Level 2......................................................................................................................... 520

PI 2.1 ................................................................................................................................ 520
PI 2.2 ................................................................................................................................ 523
PI 2.3 ................................................................................................................................ 526
PI 2.4 ................................................................................................................................ 528
PI 2.5 ................................................................................................................................ 529
PI 2.6 ................................................................................................................................ 531
Level 3......................................................................................................................... 533

PI 3.1 ................................................................................................................................ 533
14
PI 3.2 ................................................................................................................................ 536

PI 3.3 ................................................................................................................................ 538
Requirements Development & Management (RDM) 540
RDM Overview ............................................................................................................ 540

Level 1......................................................................................................................... 546
RDM 1.1 ............................................................................................................................ 546
Level 2......................................................................................................................... 547

RDM 2.1 ............................................................................................................................ 547
RDM 2.2 ............................................................................................................................ 550
RDM 2.3 ............................................................................................................................ 553
RDM 2.4 ............................................................................................................................ 555
RDM 2.5 ............................................................................................................................ 557
Level 3......................................................................................................................... 559

RDM 3.1 ............................................................................................................................ 559
RDM 3.2 ............................................................................................................................ 560
RDM 3.3 ............................................................................................................................ 561
RDM 3.4 ............................................................................................................................ 563
RDM 3.5 ............................................................................................................................ 565
RDM 3.6 ............................................................................................................................ 566
RDM 3.7 ............................................................................................................................ 569
Risk and Opportunity Management (RSK) 571
RSK Overview ............................................................................................................. 571

Level 1......................................................................................................................... 573
RSK 1.1............................................................................................................................. 573
Level 2......................................................................................................................... 575

RSK 2.1............................................................................................................................. 575
RSK 2.2............................................................................................................................. 577
Level 3......................................................................................................................... 578

RSK 3.1............................................................................................................................. 578
RSK 3.2............................................................................................................................. 579
RSK 3.3............................................................................................................................. 581
RSK 3.4............................................................................................................................. 582
15
RSK 3.5............................................................................................................................. 587
Service Delivery Management (SDM) 588
SDM Overview ............................................................................................................ 588

Level 1......................................................................................................................... 590
SDM 1.1 ............................................................................................................................ 590
Level 2......................................................................................................................... 591

SDM 2.1 ............................................................................................................................ 591
SDM 2.2 ............................................................................................................................ 593
SDM 2.3 ............................................................................................................................ 595
SDM 2.4 ............................................................................................................................ 596
SDM 2.5 ............................................................................................................................ 598
SDM 2.6 ............................................................................................................................ 601
Level 3......................................................................................................................... 604

SDM 3.1 ............................................................................................................................ 604
Strategic Service Management (STSM) 606
STSM Overview .......................................................................................................... 606

Level 1......................................................................................................................... 608
STSM 1.1 .......................................................................................................................... 608
Level 2......................................................................................................................... 609

STSM 2.1 .......................................................................................................................... 609
STSM 2.2 .......................................................................................................................... 610
STSM 2.3 .......................................................................................................................... 611
Level 3......................................................................................................................... 614

STSM 3.1 .......................................................................................................................... 614
Supplier Agreement Management (SAM) 616
SAM Overview ............................................................................................................ 616
16
Level 1......................................................................................................................... 619

SAM 1.1 ............................................................................................................................ 619
SAM 1.2 ........................................................................................................................... 620
SAM 1.3 ............................................................................................................................ 621
SAM 1.4 ............................................................................................................................ 622
Level 2......................................................................................................................... 623

SAM 2.1 ............................................................................................................................ 623
SAM 2.2 ............................................................................................................................ 627
SAM 2.3 ............................................................................................................................ 631
SAM 2.4 ............................................................................................................................ 635
SAM 2.5 ............................................................................................................................ 638
Level 3......................................................................................................................... 640

SAM 3.1 ............................................................................................................................ 640
SAM 3.2 ............................................................................................................................ 645
Level 4......................................................................................................................... 647

SAM 4.1 ............................................................................................................................ 647
Technical Solution (TS) 649
TS Overview ................................................................................................................ 649

Level 1......................................................................................................................... 654
TS 1.1 ............................................................................................................................... 654
Level 2......................................................................................................................... 655

TS 2.1 ............................................................................................................................... 655
TS 2.2 ............................................................................................................................... 659
TS 2.3 ............................................................................................................................... 660
Level 3......................................................................................................................... 662

TS 3.1 ............................................................................................................................... 662
TS 3.2 ............................................................................................................................... 664
TS 3.3 ............................................................................................................................... 665
TS 3.4 ............................................................................................................................... 666
TS 3.5 ............................................................................................................................... 667
TS 3.6 ............................................................................................................................... 668
17
Verification and Validation (VV) 671
VV Overview ............................................................................................................... 671

Level 1......................................................................................................................... 676
VV 1.1 ............................................................................................................................... 676
VV 1.2 ............................................................................................................................... 677
Level 2......................................................................................................................... 678

VV 2.1 ............................................................................................................................... 678
VV 2.2 ............................................................................................................................... 681
VV 2.3 ............................................................................................................................... 683
Level 3......................................................................................................................... 684

VV 3.1 ............................................................................................................................... 684
VV 3.2 ............................................................................................................................... 685
Workforce Empowerment (WE) 687
WE Overview .............................................................................................................. 687

Level 1......................................................................................................................... 689
WE 1.1 .............................................................................................................................. 689
Level 2......................................................................................................................... 690

WE 2.1 .............................................................................................................................. 690
WE 2.2 .............................................................................................................................. 691
WE 2.3 .............................................................................................................................. 693
Level 3......................................................................................................................... 696

WE 3.1 .............................................................................................................................. 696
WE 3.2 .............................................................................................................................. 698
WE 3.3 .............................................................................................................................. 699
18
Causal Analysis and Resolution (CAR)

CAR Overview
Required PA Information
Intent
Identifies causes of selected outcomes and takes action to either prevent recurrence of
undesirable outcomes or ensure recurrence of positive outcomes.
Value
Addresses causes of issues, eliminating rework and directly improving 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 causes of selected outcomes by following an organizational
process.
CAR 3.2 Propose actions to address identified causes.
CAR 3.3 Implement selected action proposals.
CAR 3.4 Record causal 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.
19
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
to optimize performance across the organization.
Additional PA Explanatory Information

Causal analysis and resolution activities include:
• Determining causes of selected outcomes
• Proposing actions to address identified 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 Development
Context Tag: Agile Development
Context: Integrate agile techniques and ceremonies with other processes.
Agile teams identify and address blockers and collect Sprint data during the iteration and review
it in the retrospective. A typical agile retrospective reviews what went wrong, what worked well,
and selects improvements for the next Sprint.
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. These
underlying causes would be identified, analyzed, ranked, and addressed.
DevSecOps
Context Tag: DevSecOps
Context: DevSecOps is a mindset, a culture, and set of practices that fosters close
cooperation between development, operations, and security to plan, develop, test,
deploy, release, and keep updated a secure solution.
20
DevSecOps teams typically conduct reviews at the end of each iteration based on the
framework or methodology chosen, such as Scrum, Kanban, SaFe, etc. For example, in Scrum,
retrospectives occur at the end of each Sprint. During these retrospectives, teams identify
progress and work impediments or blockers to resolve these during the next Sprint. The
challenge that DevSecOps teams face when performing causal analysis is the perception that
when during a retrospective someone says, “Let’s get to the root of the problem.” This often
means: Who is to blame? This “blame game” is counter to a positive DevSecOps culture. The
target of root cause analysis should be focused on the process and not the people.
The challenge with root cause analysis in modern software development is it may not
consistently address complexity of the software and so often does not provide solutions quickly
enough. In a DevSecOps environment where iterations are short, and Continuous Integration /
Continuous Delivery (CI/CD) pipelines, micro services, containers, etc., are in constant flux,
getting to the root cause is more challenging due to the limitations of data at specific points in
time, and due to the complex interactions between all system components, interfaces or
connections, applications, and environments.
DevSecOps teams typically address causal analysis incrementally, focusing on what is actionable
and can be corrected in the next Sprint. For example, failures in gate-check points in the CI/CD
pipeline could be potential outcomes to initiate analysis, and simple techniques like Five Whys
can be used. Some issues may require multiple Sprints to correct or require collaboration across
multiple DevSecOps teams. For example: the inability to identify errors in the early stages; lack
of team member collaboration, lack of ability to identify vulnerabilities, etc.
Suppliers
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:
• Supplier improving its processes to conduct the project more effectively
• Acquirer improving its supplier interfaces or connections
• Changes in jointly used tools or technologies
21
Level 1
CAR 1.1
Required Practice Information
Practice Statement
Identify and address causes of selected outcomes.
Value
Increases likelihood of achieving 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
22
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 (QPPOs)
Example Activities

Define the scope of the analysis. The scope may include:
• Definition of issue or success
• Affected stakeholders
• Affected target
Collect relevant data.
Determine which outcomes to When determining which outcomes to analyze further,
analyze further. consider their:
• Source
• Impact
• Frequency of occurrence
• Similarity
• Cost of analysis
• Time and resources needed
23

• Safety considerations
• Security considerations
• Performance
Examples of methods for selecting outcomes include:
• 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
Context Specific
DevSecOps
Retrospectives are time-boxed activities and because of this, once all issues from the previous
Sprint have been identified, teams typically need to use previously defined criteria to prioritize
and pick their top two to three items for further analysis. Use of criteria is beneficial in helping
uncover and address root causes that can develop into a larger issue in upcoming Sprints and
to prioritize corrective action in upcoming Sprints. It may be several Sprints before the team
addresses all key issues. It also may take several Sprints before the team can determine if their
corrective actions are effective.
24
CAR 2.2
Practice Statement
Analyze and address causes of outcomes.
Value
Reduces cost and time to meet objectives more efficiently.


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
Example Activities

Identify the affected stakeholders Causal analysis is typically performed by those who
and involve them. have the 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.
25

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
26
Level 3
CAR 3.1
Practice Statement
Determine causes of selected outcomes by following an organizational process.
Value
Increases likelihood of meeting objectives by promoting successes and avoiding problems.


A cause is a fundamental reason for the occurrence of a problem or success. Causal 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
perform causal analysis. grouping 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
27

• Pilots
• Process improvements
• Performance improvements
Examples of methods to determine causes include:
• Cause-and-effect (fishbone) diagrams
• Check sheets
• 5 Whys
If possible, based on the scope, look at the outcomes
in several ways to ensure all potential causes are
investigated. Where appropriate, look for patterns of
causes across functions.
Record causes.

List of causes Include selected outcomes and analysis results.
List of affected stakeholders
CAR 3.2
Practice Statement
Propose actions to address identified 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
causes so that they do not recur.
28
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
• 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 May include:
• Originator of the action proposal
• Description of necessary tasks
• Description of the outcome to be addressed
• Description of the cause
• 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
29
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.
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 Action plans may include:
implementing the selected action • People responsible for implementation
proposals. • Detailed description of the action
• Description of necessary tasks
• Description of the affected areas
• Schedule
• Cost expected
• Estimated cost of not addressing the cause
• Description of implementation actions
• Expected impact on performance
• Identified needed pilots
Implement action plans. To implement action plans:
• Update the processes
• Review the results
30

• 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 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)
CAR 3.4
Practice Statement
Record causal analysis and resolution data.
Value
Records and communicates improvement efforts across the organization, leveraging savings
and increasing productivity.


Collect data to know that you are:
• Improving project performance
• Preventing selected problems from recurring
31
• Leveraging superior performance

• Providing sufficient context for future use
Example Activities

Record causal analysis data and Involve the use of qualitative and basic measurement
make the data available for use. data analysis with the causal analysis.

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.
Value
Reduces disruptions and rework and allows projects to learn from each other and increase
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
32

• 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)
33
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.

Perform root cause analysis using data and results from statistical and quantitative analysis
techniques to evaluate, select, and implement action plans and measure results. This should be
done in addition to basic measurement and qualitative analysis activities. Address outcomes
including deficiencies in process stability and capability, deficiencies in performance relative to
objectives, and unexpected 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.
34

Implement selected actions. Update solutions or processes.

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 May include:
effectiveness • Impact on performance
• Impact on meeting Quality and Process Performance
Objectives (QPPOs)
• 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.
35
Example Activities

Measure and analyze the change in Determines if the selected change has positively
process performance of the influenced process performance.
project’s 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.
Determine the impacts of the Determines whether the selected change has positively
change on achieving the project’s influenced the ability of the project to meet its QPPOs.
Quality and Process Performance Process performance models can aid in the evaluation
Objectives (QPPOs). 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

36
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 to optimize performance across the organization.
Value
Leverages improvements across the organization to minimize cost and risk.


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
37
Configuration Management (CM)

CM Overview
Intent
Manages 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
38
• Work products provided by the customer

• Designated internal work products, including:
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
External References
External Reference Item Link

U.S. Department of Commerce, National https://www.nist.gov/itl/executive-order-14028-
Institute of Standards and Technology improving-nations-cybersecurity/software-
(NIST), Software Security in Supply Chains security-supply-chains-software-1
U.S. Department of Commerce, National https://www.ntia.gov/sbom
Telecommunications and Information
Administration (NTIA), Software Bill of
Materials (SBOM)
U.S. Department of Commerce, NTIA, https://www.ntia.gov/files/ntia/publications/ntia
Survey of Existing SBOM Formats and _sbom_formats_and_standards_whitepaper_-
Standards _version_20191025.pdf

Verification and Validation (VV)
Context Specific
Agile Development
Configuration management is performed throughout an agile development project. Figure CM-1:

Example Agile Configuration Control Items shows example configuration items for agile
development that are placed under selected levels of configuration control. Configuration
management processes are used to track the various backlog versions and the ripple effects to
design information, code, test cases, and test results.
39
Configuration management processes are used with agile development efforts to maintain the
integrity of work products and deliverables. In an agile development project, the definition of
“done” is also a term that the team typically discusses and decides 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.
Figure CM-1: Example Agile Configuration Control Items
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
40
• Code and libraries

• Compilers
• Test tools and test scripts
• Installation logs
• Product data files
• Product technical publications
• Plans
• User stories
• Iteration backlogs
• Process descriptions
• 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. (Refer to the definition of “product line” in
the glossary.)
DevSecOps
DevSecOps Configuration Management is highly tool-dependent due to the driving principle to

automate routine tasks and the need to integrate development and operations activities to
reduce time to market. Many tools and environments used in DevSecOps are not owned,
inhouse developed, or on-premises. Configuration management practices can vary dependent
on whether the tools and environment are on-premises, cloud, or hybrid, and should be
included in their Configuration Management Plan. DevSecOps teams typically use a source
repository where the software code is stored. A repository containing code, binaries, and other
artifacts is used in conjunction with a configuration management database to track the status of
all configuration items. Configuration items may include:
• Requirements documents
• Operational concepts
• Design documents
• Interface descriptions
• Data model descriptions
• System descriptions
41
• Security Technical Implementation Guide (STIG)

• Workflow diagrams
Configuration audits typically need to be conducted more frequently and iteratively given the
nature of the DevSecOps deployment processes and associated changes. Baseline audit reviews
should include both the software source code and repository, and also the project
documentation, DevSecOps systems, processes, automation steps, and environment as needed.
42
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,
under version control and keep it e.g., location, ownership.
updated.
Control versions.

List of work products and their
versions
43
Level 2
CM 2.1
Practice Statement
Identify items to be placed under configuration management.
Value
Reduces risk of rework and verifies that the right version is delivered to the customer.

If Data is included in the selected view: Identify data items, or elements, critical to the delivery
of the solution to be placed under configuration management such as personally identifiable
information, customer data, operational data, business and financial data, and analytical data.
If People is included in the selected view: Identify people-related work products to be placed
under configuration management such as a compensation strategy, workforce competency
descriptions, and personnel transition checklists.
If Safety is included in the selected view: Identify hazard and safety-related work products to
be placed under configuration management such as hazard analysis, safety improvement plans,
safety training materials, and safety related software and hardware.
If Security is included in the selected view: Identify security-related work products to be placed
under configuration management such as configurations of network devices, systems,
applications, and documentation.

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
44
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
under configuration management. and 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
• Key features
• Purpose of the item
• Relationships to other items and solutions
• Retention
• Version
• Security
Context Specific
Safety
Context Tag: CMMI-SAF
Context: Use processes to incorporate safety considerations as an integral part of the

solution, work, project, and organization.
Log, track, and manage safety management work products throughout the solution lifecycle.
Develop and keep updated a hazard tracking system with data for each hazard as appropriate
for the solution. Examples of applicable data to include in the hazard status log include:
• Type of hazard
• Solution lifecycle phases affected by the hazard
• Causal factor, e.g., hardware, software, and human
• Effects of the hazard
• Initial risk type and associated risk category
• Risk event and associated risk category
• Hazard mitigation measures
• Action person(s) and organizational element
• Hazard status, e.g., open or closed
45
• Hazard traceability, or running history of actions taken or planned, with rationale to

mitigate risks
• Record of risk acceptance(s); risk acceptance authority and user concurrence authority, as
applicable, by title and organization, date of acceptance, and location of the signed risk
acceptance document(s)
• Reasonably anticipated hazardous materials that are used or generated during the
lifecycle of the system, e.g., installation, test and evaluation, normal use, maintenance or
repair, and disposal of the system
• Reasonably anticipated hazardous materials to be used or generated in emergency
situations, e.g., exhaust, fibers from composite materials released during accidents, and
combustion byproducts
Security
Context Tag: CMMI-SEC
Context: Use processes to incorporate security considerations as an integral part of the

Management of open source components and their security requirements and vulnerabilities is
critical since frequently open source components are abandoned or not updated. This can be
addressed using a Software or Sales Bill of Materials (SBOM), also known as a Software Bill of
Sales (SBOS).
An SBOM enables organizations to effectively track all components in their codebases. Given
that open source components are frequently essential components of application development,
software development teams can use an effective Software Composition Analysis (SCA) tool to
inventory the open source and third-party components in their code.
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.

46

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.
Establish methods to manage The level of control is typically selected based on work
multiple 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 Typically, storage and retrieval functions in a
items in the configuration configuration management system include a check-in
management system. and check-out 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, database schema, physical artifacts
47

• Archive of configuration management files, consider
business, legal, and regulatory requirements for
retention and archival
• 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
Context Specific
DevSecOps
DevSecOps teams use their configuration tools to incrementally build an automated Continuous
Integration / Continuous Delivery (CI/CD) pipeline for the software that spans initial build
through automated releases. A primary benefit of CI is that it saves time during the
development cycle by identifying and addressing issues early. It also reduces the time spent on
bug fixes and regression by providing continuous feedback to the development team, allowing
them to take corrective or preventative action. Automated and built-in configuration audits
during CI help uncover issues in a timely manner. The binary code from the various builds is
stored in their artifact repository along with supporting artifacts and the configuration
management database is used to track the high-level status of all configuration items used.
DevSecOps teams typically use agile project management tools which support agile
methodology and CI/CD configuration management, e.g., JIRA, Confluence, Azure Boards, to
manage change requests through automated workflows and change states. Tools of this type
allow for all information relevant to the change to be captured and used to support decision
making, impact analysis, and communicating with stakeholders on the status of their changes
as it moves through the change process from request to implementation. Configuration of these
tools also needs to be controlled with appropriate change and approval mechanisms. Otherwise,
a poor configuration of an automated test tool, analysis tool, build tool, or security scanner may
identify false errors or allow defects or security vulnerabilities to go undetected.
48
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.

If Data is included in the selected view: Record and keep updated baseline configurations of
data management artifacts, e.g., models and representations, data architecture, data
management approach, data quality reports.
If Safety is included in the selected view: Record and keep updated baseline configurations and
inventories of safety controls for solution components and related documentation throughout
the solution lifecycle.
If Security is included in the selected view: Record and keep updated baseline configurations
and inventories of security controls for software, hardware, firmware, systems, and related
documentation throughout the solution lifecycle.

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, and it is important to be able to reproduce any of these multiple baselines.
Example Activities

Obtain authorization or approval An approval group will typically assess the impact and
before developing or releasing necessity of changes to configuration items.
baselines of configuration items.
Develop or release baselines only
from configuration items in the
configuration management system.
49

Record the set of configuration
items contained in a baseline, so
that the baseline is reproducible.
Make the current set of baselines Only stakeholders with approved access should be able
available. to 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.

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.
50
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.

If Safety is included in the selected view: Identify, record, and keep updated changes to safety
related items placed under configuration management controls, e.g., configurations of network
tools, systems, applications, and documentation.
If Security is included in the selected view: Identify, record, and keep updated changes to
security configurations of networks, tools, systems, applications, and documentation.

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
51
Example Activities

Initiate and record change Typically includes:
requests. • 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 Analysis should consider impacts to:
requests. • 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 An approval board typically:
change requests to be addressed in • Reviews changes
the next baseline with affected • Records the disposition of each change request and
stakeholders. the rationale for each decision
• Reports results to stakeholders
Track the status of change requests
to closure.
Incorporate changes in a manner Examples of check-in and check-out include:
that maintains integrity. • Confirming the revisions are authorized
• Updating the configuration items
• Maintaining versions of work products
• 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 Examples:
ensure changes have not caused • Automated unit test
unintended impacts. • Regression testing
• Performance testing
Record changes to configuration
items and rationale.
52

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
Reduces rework through accurate descriptions of the configuration items and status of changes.


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
53

configuration item is known and
previous versions can be recovered.
Ensure that affected stakeholders Examples of activities for communicating configuration
have access to and knowledge of status include:
the configuration status of • Providing access permissions to authorized users
configuration 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
items that constitute a specific baseline.
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
Context Specific
Data
Context Tag: CMMI-DATA
Context: Use processes to incorporate data management best practices as an integral part
of the solution.
Record, manage, and keep updated key information for data items, e.g., authoritative source,
ownership and governance data parameters, metadata, access and distribution parameters,
privacy classification, security classification, retention parameters.
54
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.

If Safety is included in the selected view: During configuration audits, include verification of
integrity and correctness of safety aspects of the solution components.
If Security is included in the selected view: During configuration audits, include verification of
integrity and correctness of security aspects of the solution components.

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 Examples include:
and generate action items to • Physical work product reviews verifying changes
address 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.
55

Configuration audit or review Contains the objectives for and outcomes of audits in
results 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.
56
Continuity (CONT)
CONT Overview
Intent
Anticipates and addresses disruptions to critical business operations so work can continue or
resume as soon as possible.
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 activities can be considered another form of risk and opportunity 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.
57
Continuity applies when an event or series of events, is so disruptive that it is impossible to

conduct business as usual.
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 keeping updated 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)
58
Context Specific
Safety

Safety hazards and events have the potential to significantly impact or disrupt normal
operations. Monitor safety hazards and events like any other significant disruption when
identifying disaster recovery or other continuity plans, and address safety needs in those plans.
59
Level 1
CONT 1.1
Practice Statement
Develop contingency approaches for managing significant disruptions to operations.
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
60
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-
which operations rely. demand:
• Manual processes
• Automated processes
• End user activities
• Operational activities
• Solution delivery activities
• Safety and security activities
61

Analyze the criticality and the In situations where a limited number of functions are
impact to operations if the project essential, action planning may be simplistic. If none of
cannot perform the essential the functions are essential, the course of action might
functions. be to resume operations when the emergency ends.
Prioritize the list of essential Consider the impact of the duration for the disruption,
functions. e.g., long versus short disruption, safety
considerations, physical and functional security.

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
Maintains customer satisfaction and continues 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.
62
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
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 For some critical resources, it may be necessary to
based on the impact of their loss or identify succession orders.
lack of access.
Develop safety provisions for
operations personnel.
Ensure needed records and
databases are protected,
63

accessible, and usable in an
emergency.

Records of critical resources May include:
required 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 Includes agreements for alternate locations for
contracts operations during recovery.
Backup and recovery records of These records typically identify the organization as a
legal operation charters legal entity and are stored offsite. May include legal
copies of:
• Articles of incorporation
• 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.
64


Example Activities

Identify and record threats and Use information on threats and vulnerabilities to
vulnerabilities to ongoing develop and keep updated the continuity plan. In the
operations. 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 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 Record the acceptable levels for various outage
for shifting from the normal scenarios, e.g., site, city, country.
operations environment to a
Continuity of Operations (COOP)
environment.
Revise continuity plans as Examples of when to revise continuity plans include:
necessary. • 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
65

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)
66
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
67
Example Activities

Develop a strategy for conducting
continuity training.
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.

68

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.
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 Training feedback from attendees can provide
record suggested improvements to suggested improvements to continuity plans based on
continuity plans and continuity their experience.
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)
69
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.
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 demonstrates 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.
70
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
Prepare checklists to verify and May include:
validate the continuity plan. • Readiness preparedness checklists
• Emergency preparedness materials checklist
• Business continuity self-assessment checklist
Review the verification and Affected stakeholders should understand and agree to
validation plan with affected the verification and validation strategy, methods,
stakeholders. activities, environments, and resources.
Decide on the procedures and Procedures and criteria ensure that the elements of
criteria to verify and validate the continuity plans are correct, effective, and current
continuity plan. relative to 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.
71

Provide information on defect Information includes verification methods, criteria, and
resolution and initiate corrective the verification environment.
action.
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 Include changes to continuity plans identified:
improving 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
verification and validation
List of personnel and affected stakeholders
involved in continuity verification and
validation activities
Verification and validation analysis reports
Recommendations for improvement These include improvement recommendations
for:
• Continuity plans
• Continuity plan verification and validation
activities

72
Data Management (DM)

DM Overview
Intent
Identifies, implements, and controls the approach and activities for managing data.
Value
Maximizes operational efficiency by prioritizing critical data activities to meet performance
needs.

Practice Summary
Level 1
DM 1.1 Identify data management objectives.
DM 1.2 Use metadata to manage data.
Level 2
DM 2.1 Develop, keep updated, and follow a data management approach that is
aligned to objectives.
DM 2.2 Establish a data management architecture to support the data
management approach.
Level 3
DM 3.1 Establish and deploy an organizational data management capability.
DM 3.2 Perform reviews periodically on the effectiveness of the organization’s
data management capability and take action on results.

Sound data management involves significant stakeholder engagement, irrespective of the
current level of data management maturity. This stakeholder involvement is needed to develop
the long-term commitments required to achieve organization-wide cohesion and demonstrate
value to the business, according to shared and approved objectives and priorities. Effective data
management requires awareness of metadata attributes, and the purpose of data items, and is
often just as critical as controlling data values.
73
The data management function emphasizes the need to:

• Effectively scope, plan, and resource data management activities as a sustained function
• Engage leadership in demonstrating the importance of data management
• Promote a multiple stakeholder approach
• Define data management roles and responsibilities
Data management activities strengthen the form and structure of the data management
program, build ongoing advocacy, and support from stakeholders, and help the organization to
achieve its strategic objectives with the confidence that results from a comprehensive
implementation.
Data management may often be dependent on and affect the development of critical
infrastructure. There are many potential ways of addressing this challenge ranging from fixed
physical systems through to highly distributed cloud computing services. The organization’s
approach to addressing these infrastructure considerations is thus significantly impacted by
business strategy, as well as considerations of security, suppliers, etc.
External References

Data Protection in the European Union (EU) https://ec.europa.eu/info/law/law-topic/data-
protection/data-protection-eu_en
Department of Defense (DoD) Data Strategy https://media.defense.gov/2020/Oct/08/2002

514180/-1/-1/0/DOD-DATA-STRATEGY.PDF
Federal Enterprise Data Resources repository https://resources.data.gov
General Personal Data Protection Act (LGPD), Brazil https://lgpd-brazil.info
NIST Special Publication (SP) 500-291, The NIST https://www.nist.gov/system/files/documents

Cloud Computing Standards Roadmap /itl/cloud/NIST_SP-500-291_Version-
2_2013_June18_FINAL.pdf
NIST SP 800-144, Guidelines on Security and Privacy https://nvlpubs.nist.gov/nistpubs/Legacy/SP/n

in Public Cloud Computing istspecialpublication800-144.pdf
NIST SP 800-145, The NIST Definition of Cloud https://csrc.nist.gov/publications/detail/sp/80

Computing 0-145/final
NIST SP 800-210, General Access Control Guidance https://csrc.nist.gov/News/2020/nist-

for Cloud Systems publishes-sp-800-210-ac-guidance-for-cloud

Data Quality (DQ)
Enabling Security (ESEC)
74
Level 1
DM 1.1
Practice Statement
Identify data management objectives.
Value
Increases probability that data supports achievement of objectives.


Example Activities

Identify data management objectives and priorities. Data management objectives may be
at the work level, project level, or
organizational.

Recorded data management objectives
Recorded data management priorities
DM 1.2
Practice Statement
Use metadata to manage data.
Value
Increases accessibility, objectiveness, and usability of critical data.
75


Metadata is a category of information that identifies, describes, explains, categorizes, and
provides content, context, structure, and classifications pertaining to relevant data assets; and
it enables effective retrieval, usage, and management of these assets.
The metadata developed is the mechanism allowing data asset knowledge to be established and
enhanced over time. Effective metadata management and the creation of a metadata catalog
facilitates, supports, and contributes to achievement of critical data management activities and
objectives.
Metadata typically contains three categories:
• Business Metadata: Descriptive information used to understand, search, locate, and
control content that can include elements such as terms, definitions, values, authors,
keywords, and publishers. Business metadata may also include domains, related subject
areas, business rules, and data quality rules, all of which should be developed for the data
glossary. Business metadata is the foundation for mapping to related metadata artifacts
such as taxonomies, ontologies, data glossaries, and standards.
• Technical Metadata: Describes data assets instantiated in the physical data layer as well
as their transformations through automated processes. It describes the content and
location of data stores and interfaces or connections, including information about tables,
field structures, data types, columns, links to related files, indexes, etc. Technical
metadata consists of the following subcategories: 1) run-time or dynamic metadata, e.g.,
configuration information, messaging, and eXtensible Markup Language (XML), and 2)
design-time or static metadata, e.g., physical data models, Data Definition Language
(DDL), data dictionary, and Extract, Transform, Load (ETL) scripts.
• Operational Metadata: Provides administrative information to manage a data asset and
includes information such as when it was developed or acquired; the file type; source of
that data; purpose of the data; information needed for archival, integration, and schedule
updates; access rights; and entitlement restrictions. Operational metadata is typically
broken into two main categories:
o The administrative metadata related to governance and stewardship is included under
operational metadata. This is descriptive information used to understand the roles of
the individuals involved in governing the data. This administrative data identifies
governance bodies and their scope, process, participants, structure, and
responsibilities; and is used to manage change to all types of metadata. In addition,
operational metadata is used for performance improvements and to improve data
quality to enhance productivity.
76
o Process metadata, a subcategory of operational metadata, addresses process steps for

production and maintenance, as well as for data quality measurement and analysis.
Business rules; names of relevant systems, jobs, and programs; as well as governance
and regulatory roles and other control requirements are examples of process
metadata.
Example Activities
Example
Further Explanation
Activities
Define, record, and Metadata may be captured and stored in data models, systems,
use metadata. networks, project documentation, operational documentation, or in lists
of key business terms. Identify sources of existing metadata; evaluate
their completeness, categorization, and properties; and plan to
consolidate and enhance them into a cohesive meta-model reflecting
their needs.
As an example of existing metadata assets which may be leveraged,
sources based on data models typically include the following items:
• Entity type name
• Attribute name
• Table name
• Column name
• Data type
• Length
• Allowed values
• Default values
• Mandatory/Optional indicator
Data definitions should be defined for entity types, attributes, tables,
and columns, and should reflect logical relationships and dependencies
between data elements.

Metadata repositories
Metadata definitions and documentation Specify guideline information and requirements
for applicability and usage.
77
Level 2
DM 2.1
Practice Statement
Develop, keep updated, and follow a data management approach that is aligned to objectives.
Value
Improves the usability and accessibility of the data to the work.


An effective data management approach defines the rationale for implementing a data
management program, explains what the overall program aims to achieve against relevant
objectives, and identifies how the various program components are connected. It should
accurately reflect stakeholders’ objectives to provide confidence that the data management
program is meeting their needs. A functional data management approach should be developed
collaboratively and approved by all stakeholders. The data management approach is reviewed
against the configuration management activities, plans, and processes to eliminate conflict and
synchronize for consistency and alignment.
An assessment of the current state, including capability gap analyses and identifying key
dependencies, fosters alignment and provides a foundation for buy-in to the approach and the
corresponding plan for implementation. This assessment should consider the domain, overall
strategy, and the regulatory and competitive environment. Where data management solutions
depend on cloud computing services, there is also an increased need to consider potential
security and privacy issues.
Upon completion of assessing the current state, develop, or revise, and implement a data
management approach, leveraging participant momentum from the assessment results. The
data management approach needs to reinforce the use of standards and outline the overall
governance framework employed to make decisions about implementation and must evolve as
needs change. It should also consider major implementation considerations, such as
architectural initiatives and technology transformation initiatives underway or planned; and it
needs to define a sequence of activities to guide implementation.
The data management approach needs to identify the resource requirements for the data
management program, and the criteria that will be employed to evaluate program effectiveness.
Engaging stakeholders in the development, or refinement, of the data management approach
provides an unparalleled collaboration opportunity, which is leveraged for the cultural and
systemic change that is required for continued success.
78
Example Activities

Periodically review and Consider the following sources when reviewing and updating data
update data management objectives:
management • Customer base
objectives. • Geographic regions
• Market trends
• Use of real-time or near real-time analytics
• Prevention of cyber-attacks and data breaches
• Industry regulatory requirements
• Reduction of operational complexities and costs
• Monetizing the value of the company's data
• Data quality issues
Record the data The data management approach defines the overall framework of
management the program. Evaluate and prioritize the approach against business
approach. drivers and goals to ensure alignment with the relevant strategy.
A data management approach usually consists of, at a minimum:
• A vision statement, which includes core operating principles,
goals and objectives, and priorities that are based on a synthesis
of important factors such as dependencies, perceived value,
alignment to strategic initiatives, and resources required
• Scope, e.g., customer accounts, data management priorities,
data quality, critical data elements such as customer master data
• Business benefits
• The selected data management framework and how it will be
used
• Consideration of the major gaps identified in the assessment of
the current state
• Data management roles and responsibilities, including list of key
stakeholders, e.g., Chief Data Officer, governing body, data
owners, data providers
• Governing principles and guidelines
• Metadata definitions and processes
• Sensitivity classifications of data, e.g., public, internal use,
restricted or confidential
• Overview of data management approach, which may include
considerations of data lifecycles, data integration, data
dictionary, data migration, architectural standards, data
representations, data flows, data security, data privacy, data
sufficiency, data substitution or de-identification, data storage,
and change management for data elements
• Extent and scope of data compliance approach
• Testing criteria and approach
• Success measures
• Data quality requirements
• Error and exception handling standards
79

• Quality control checks
• Verification and validation
Review the data
management approach
with stakeholders.
Review the data
management approach
periodically for
potential updates.

Data management objectives Data management objectives and priorities are aligned and
traceable to relevant objectives, e.g., strategic, business,
project.
Data management approach
Meeting notes or review
feedback from stakeholders

Planning (PLAN)
DM 2.2
Practice Statement
Establish a data management architecture to support the data management approach.
Value
Provides an efficient and effective structure for consistently performing data management
activities.


A data architecture is essential for design of a well-structured technology infrastructure.
80
Emphasis should be on critical data sharing needs for the work performed. This may require
streamlining the data layer, for example:
• Redesign and consolidation of data stores
• Reducing data redundancy
• Improving data integration through common interface or connection specifications and
data services
• Defining and enhancing a data technology stack
• Reconciling redundant, incomplete, inaccurate, or missing data
The target data layer should support the data management and data quality objectives and
incorporate data profiling and validation results. This verifies that high-quality, trusted data can
be used to meet critical objectives.
The approach should ensure that the architecture reflects identified legal and regulatory
requirements appropriately. Performance requirements may also impact how the architecture is
designed and realized. For example, complex and distributed cloud architectures may be more
cost effective but may result in degraded performance results.
The architectural approach must be flexible and consider evolving needs, technology
obsolescence, and resulting data migrations. It is important to validate that operations adopt
any architectural transition plans to minimize negative impact. Major impacts to key operational
systems need to be analyzed, and appropriate mitigation strategies must be recorded to ensure
uninterrupted delivery of operational data.
The architectural approach must be reviewed for consistency with relevant needs and
architectural standards and approved before proceeding with design and implementation.
Because the architectural approach requires long-term guidance, it should be kept updated in
response to changing work and environmental conditions.
Example Activities

Design the data Consider and incorporate the following objectives:
architecture consistent • Scalability: to ensure that resources made available by the
with requirements. architecture in the form of components, services, and code
libraries achieve acceptable performance and throughput with
increasing data loads
• Resiliency: principles guiding establishment of system
robustness, fault tolerance, and data recovery from abnormal
usages or disruptions in accordance with requirements
• Security: requirements governing the protection, confidentiality,
integrity, and availability of data and personal information
• Metadata: definitions
• Data representation: business terms, logical, physical, XML,
modeling standards, model management, etc.
• Data dependency mapping: includes identification of consumers
and producers of the data, and authoritative sources
81

• Data access: common data services, applicable information
exchange standards, standard methods for point-to-point data
transit and bulk data movement, data integration standards, e.g.,
safety standards, emergency standards
• Critical data: elements for which the platform is an authoritative
source, trusted source, or system of record
• Justification: for data set duplication across systems, when
appropriate
• Data distribution:
o Internal and external data provisioning
o Requesting and approving access
o Access restrictions
o Distribution models, e.g., push and pull, publish and subscribe
o Ownership and authority
o Regulatory authority and audit
Review the design for
the data architecture
with stakeholders.
Implement the data
architecture.
Update the data
architecture over time
as the work and
environment changes.

Meeting notes or review feedback May include records of technical decisions.
from stakeholders
Approved architecture design A data architecture approach typically includes tools or
platforms, and related processes.
Architecture implementation plan Align to technology implementation and address any
transition activities.

Technical Solution (TS)
82
Level 3
DM 3.1
Practice Statement
Establish and deploy an organizational data management capability.
Value
Increases effective communication, common understanding, and use of data across the
business.

An organizational data capability includes:
• Data management approach
• Data architecture
• Data management function
• Data glossary

Establish a data management function to oversee all data management activities. This includes
preparation, planning, and execution for the following:
• Data analytics
• Data quality
• Target data architecture and shared data repositories
• Enterprise data warehousing
• Content management
• Consolidation of data stores
• Data audit
• Data migrations
• Data management process development and implementation
• Process automation
• Data risk or opportunity analysis
83
The data glossary is the core of the organization’s data infrastructure. Although it is simple in
concept, it can be a significant challenge to define, reconcile, harmonize, qualify, approve, and
keep updated all shared data terminology. Distinctions between terms employed across the
organization are often not well-defined or recorded, and terms used by work groups often have
assumed or implied meanings that must be resolved.
The data glossary is an approved, governed collection of data term names, definitions,
metadata, and their relationships. This provides a stable foundation for understanding and
integrating data across the organization without ambiguity or duplication.
An approved standard data glossary supports the data architecture. Without it, re-architecting,
consolidation, and effective sharing of corporate data assets are slower, more complex, and
more costly. Development of data stores, consolidations, and designs are often driven by
events, and frequently result in ad hoc naming and definitions of data terms.
Data glossary standards should be developed, followed, and kept updated through data
governance, and corresponding approval and change processes. A proper communication or
feedback loop should be established to ensure that changes and recommendations within the
data terms remain consistent and accurate within the data glossary.
Example Activities

Identify approach, roles, responsibilities, and
tasks required for operating the data
management function and keep updated.
Establish a data glossary and requirements Incorporate standards for business terms,
for its use. including naming conventions, abbreviations,
standard definition representations, and
standard metadata. Leverage standard
industry business terms and definitions as
appropriate.
Review the data glossary with stakeholders.
Update the data glossary periodically. Incorporate updates based on changes to the
products or the business.
Use the data glossary for internal and Consider using the terms in the development
external work. of shared repositories, and data transfer
standards, e.g., XML, semantic models.

Organizational data management approach
Data glossary
Update log for data glossary
Data terms exception report
84

Planning (PLAN)
DM 3.2
Practice Statement
Perform reviews periodically on the effectiveness of the organization’s data management
program and take action on results.
Value
Enables more reliable, current, and consistent data-based decisions and results.


Evaluate the effectiveness and efficiency of the data management capability using:
• Industry standards and trends
• Data management approach and objectives
• Data management function
• Data architecture
• Data glossary
Prioritize identified improvements based on an analysis of impacts and business needs.
Example Activities

Review industry standards, trends,
and emerging technologies in data
management.
Conduct periodic assessments of Verify compliance with recorded data management
the data management approach and objectives, including but not limited to:
implementation. • Metadata implementations
• Data glossary usage and consistency
• Data management architecture
85

Evaluate the data management approach in
consideration of the following:
• Impact of data throughout the organization
• Condition of the current data sets
• Accuracy and completeness of data models
• Data management processes, including data
verification and validation activities

Industry research report related to data
management
Assessment results This may include evaluation of achievement
toward data management objectives using
related metrics.
List of identified and prioritized
improvements for the data management
capability

Managing Performance Measurement (MPM)
Process Quality Assurance (PQA)
86
Data Quality (DQ)

DQ Overview
Intent
Develops, follows, and keeps updated an approach for implementing data quality standards.
Value
Maximizes the value and accuracy of data for effective business operations and consistent
decision-making.

Data quality standards may be from various sources, e.g., external regulations, internal
requirements. The approach needs to consider all sources of standards and the data quality
requirements throughout the entire data lifecycle and should include consistency of data across
systems.
Practice Summary
Level 1
DQ 1.1 Identify data quality parameters.
DQ 1.2 Perform data cleansing activities.
Level 2
DQ 2.1 Define criteria for data cleansing.
DQ 2.2 Develop, keep updated, and follow a data quality approach.
DQ 2.3 Perform data cleansing based on criteria and data quality approach.
Level 3
DQ 3.1 Conduct data quality assessments.
DQ 3.2 Perform reviews periodically on the effectiveness of the organization’s
data quality activities and take action on results.

An organization leverages a data quality approach to:
• Fully understand the nature and quality of the data under management
• Evaluate, prevent, and remediate defects
87
• Ensure that the quality of data meets business purposes and the organization’s strategic
objectives
The data quality approach provides the basis for cleansing data defects to ensure fitness for
intended uses in business operations, decision-making, and planning. A comprehensive data
quality program typically involves:
• Data quality profiling and data quality assessment including activities to assess the data
under management against a set of defined quality objectives
• Implementing repeatable processes for data quality cleansing that reduce effort and
lower costs, enabling the organization to ensure “fit for purpose” data assets

88
Level 1
DQ 1.1
Practice Statement
Identify data quality parameters.
Value
Increases the consistency and effectiveness of data quality activities.


Example Activities

Define data quality parameters important to the business. Parameters may include:
• Accuracy
• Objectivity
• Accessibility
• Timeliness
• Completeness
• Industry standards
• Data sources
• Error rates
• Expected data value ranges
• Control processing
• Quality thresholds
Review data quality parameters with stakeholders.

Defined data quality parameters
Meeting notes or reviews from stakeholders
89
DQ 1.2
Practice Statement
Perform data cleansing activities.
Value
Increases the value and consistency of data across the business.


Example Activities

Review and cleanse data. Consider business needs and data quality parameters.

Results of data cleansing
90
Level 2
DQ 2.1
Practice Statement
Define criteria for data cleansing.
Value
Increases data accuracy to improve consistency and effectiveness of decisions.


Identify the quality dimensions that are most important when considering business objectives to
leverage for data cleansing activities. Consider criteria based on the following examples of data
quality dimensions:
• Accuracy: alignment with original intent, validity as compared to an authoritative
source, and measurement precision
• Completeness: the comprehensive availability of data attributes based on requirements
• Coverage: the comprehensive availability of data records based on defined scope
• Conformity: alignment and compliance with required standards, including legal
requirements
• Consistency: compliance with required patterns and uniformity rules based on the data
lifecycle
• De-duplication: removal of redundant records or attributes
• Referential Integrity: the accuracy of data relationships, e.g., parent and child linkage
• Timeliness: the currency of content and availability when needed
Example Activities

Identify criteria for data cleansing. Consider business needs, business rules, and the
impact on resources.
Periodically review data cleansing criteria Adjust criteria for data cleansing based on
against business objectives and priorities. business objectives.

List of data cleansing criteria
91

Meeting notes or review materials

DQ 2.2
Practice Statement
Develop, keep updated, and follow a data quality approach.
Value
Increases confidence in and reliability of data, enabling more accurate business operations and
enhanced decision-making capability.


The data quality approach defines and translates the business goals and priorities into data
management activities across all applicable dimensions of data quality. This enables maximum
value from data assets and the ability to capitalize on opportunities that require accurate,
trusted data.
Example Activities

Develop a data quality A data quality approach typically addresses the following items:
approach. • Alignment to business objectives, priorities, and strategies
• Current and target state
• Expected benefits
• Estimated costs
• Business rules for data quality, including data targets, thresholds,
and prioritization
• Executive management sponsorship and support
• Roles and responsibilities
• Stakeholders
• Communication and awareness training
• Known major data quality issues
• Data quality, validation, and remediation processes
92

• Data quality requirements, including data security and data quality
assessment criteria
• Approved data quality tools
• Data profiling methodology and parameters, e.g., standard criteria
for selection and identification of data set(s) to profile, tools, and
techniques
• Data store design, e.g., referential integrity, synchronization,
normalization, cardinality, hierarchy management, optionality
constraints
• Data cleansing requirements, e.g., conformity, accuracy,
uniqueness
• Alignment to target data architecture
• Reduction of Redundant, Obsolete, and Trivial (ROT) information
• Error handling criteria and requirements
Review the data
quality approach with
stakeholders.

Data quality approach
Status updates against the approach
Meeting minutes from stakeholder meetings and reviews

Planning (PLAN)
DQ 2.3
Practice Statement
Perform data cleansing based on criteria and data quality approach.
Value
Increases consistency of data across the organization to improve reliability of decision-making.

93

Data cleansing focuses on data correction to meet criteria as determined by data quality
business rules. Business rules provide a standard baseline for identifying data defects or
anomalies that can affect business operations.
Data cleansing activities reduce efforts and lower costs, enabling “fit for purpose” assets across
its data sets and physical data stores. Conduct data cleansing at the data source or as close as
possible to the original creation point.
Example Activities

Perform data cleansing.
Verify cleansed data with data providers.

Log of data corrections
Updated data
Data cleansing activity report May include lessons learned for future data cleansing
requirements.

94
Level 3
DQ 3.1
Practice Statement
Conduct data quality assessments.
Value
Increases the consistency, completeness, and accuracy of data used across the organization.


Data quality assessments provide verification that quality expectations and data attributes are
kept consistent with requirements. Establish criteria for conducting the data quality assessments
based on business priorities and drivers. For example, financial data may undergo more
rigorous data quality assessment activity than data from other business processes.
Data quality assessments should be performed against data elements that are deemed critical
to the organization, such as:
• Information that contributes directly to the achievement of the organizational objectives
• Information used as part of regulatory or internal compliance reporting
• Security or safety related data
• Employee data, which typically includes privacy data
• Information needed for operational decision-making
Data quality assessments should verify that policies and their related processes are being
enforced and followed. When planning data quality assessments, consider the following:
• Targets for the level of quality desired
• Thresholds for the level of quality tolerated
• Measurements needed to determine the achieved quality level
• Prior assessment results used to facilitate root cause analysis
• Categorization of data quality impacts, including cost, risk, compliance, security,
productivity, etc.
• Key data stores that develop or update customer information
95
Example Activities

Establish, review, and Review data profiles periodically and on an event-driven basis,
update data profiles. e.g., when finalizing a data warehouse design, performing data
migration, planning for a data store consolidation.
Evaluate the accuracy of business rules and analysis of known
issues. Examine values, ranges, frequency distributions,
divergent metadata, nonstandard record formats, traceability
from data requirements to physical data and metadata, etc., in
accordance with standard review criteria, e.g., what, when,
how performed.
Conduct data quality Define criteria for when, e.g., periodically or event-driven, and
assessments. how the assessments are conducted. Consider historical data
profiling, lessons learned, and data quality assessment results.
Report and analyze Consider business objectives, targets, and thresholds.
assessment results.

Data profiling reports
Data quality assessment Consider using dashboards and scorecards. Identify issues that
results warrant further investigation or root cause analysis. Organize
result information based on the established quality dimensions
and thresholds.
Remediation Plan Identify remediation actions determining severity
characterization, business impacts, and supporting rationale
information.
List of identified Improvements may include remediation activities such as data
improvements fixes, updating metadata descriptions, enhancing scripts,
changes to data structures, or updates to business rules or
processes.

Monitor and Control (MC)
96
DQ 3.2
Practice Statement
Perform reviews periodically on the effectiveness of the organization’s data quality activities and
take action on results.
Value
Increases efficient use of data across business operations, systems, and processes.


Conducting assessments of the effectiveness of the organization’s data quality activities
provides a systematic approach to measure and evaluate data quality according to processes,
techniques, and against data quality business rules.
Example Activities

Review industry standards, trends, and
emerging technologies in data quality.
Conduct periodic evaluations of the Analyze data quality activities and verify an
data quality activities. appropriate Return on Investment (ROI), or balance
of cost to value added from data quality activities.
Conduct data quality confidence surveys and use
the results to quantify the level of user trust for
given data sets.
Identify data quality improvements.
Record effectiveness of data quality
activities.

Analysis results
Survey results
List of improvements Consider associating priorities, impacts, and
expected benefits with the improvements identified.
97

98

DAR Overview
Intent
Makes and records 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
99
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.
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
• Iteration or release planning
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
100

Planning (PLAN)
Context Specific
Agile Development
The decisions made by agile teams can include:

• Agile tools to use
• Features to include for each Sprint, story, or epic
• Code refactoring
• Customer acceptance criteria
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 build, buy, or reuse software code
• Whether to invest in automated testing, and to what degree, given the upfront investment
needed
Suppliers
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
101
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.
102
Level 1
DAR 1.1
Practice Statement
Define and record the alternatives.
Value
Reduces potential rework with a clear definition and understanding of the alternatives.


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.
103
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
104
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
stakeholders. criteria-based decision-making process will
be used.
105

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

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
106
Suppliers
Examples of when to use a criteria-based decision-making process include:

• 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
criteria. evaluation criteria
• Identifying risks and impacts
• Ranking criteria according to the defined range and
weighting to reflect the needs, objectives, and
priorities of affected stakeholders
107

Recorded evaluation criteria May include:
• Rationale for the criteria
• Criteria ranking and weighting
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
consider. identifying 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.
108

• Solicit alternative solutions from affected
stakeholders, e.g., through brainstorming sessions,
interviews, and working groups.
Record selected alternatives.

Recorded alternatives
Context Specific
Suppliers
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
109

• Testing
• Modeling and simulation
• Studies or benchmarking
• Surveys
• Prototypes
• Demonstrations
• Focus groups
• Expert judgment

Selected evaluation methods
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 Record the rationale for adding new alternatives,
evaluation. adding new methods, changing criteria, and the interim
evaluation results.
110

Assess the risks associated with There can be substantial risk when decisions are made
implementing the recommended with incomplete information.
solution.
Record and communicate the It is important to record both why a solution is selected
results for the recommended and why other solutions were rejected.
solution to affected stakeholders.

Evaluation results
Assessed risks
Recommended solutions

111
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.
Periodically, or on an event-driven basis, e.g., organizational re-structuring; review the decision-
making processes to confirm its continued appropriateness, in terms of:
• Speed and timeliness
• Effectiveness
• Availability and accuracy of information
• Responsibility for results
• Breadth of decision impact
• Buy-in for the decision
• Competency
• Decision dependencies
• Coordination of work processes
• Legal responsibilities
• Statutory requirements
112
Identify and evaluate decisions to modify the decision-making process, roles, or techniques.
Example Activities

Identify, record, keep updated, and This activity may include:
communicate the roles and levels of • Periodic review of authority and role definitions
decision-making authority. • Orientation or training people on organizational
decision authority

List of roles and decision- Decision-making authority may involve roles in areas such as:
making authority and • Legal or regulatory
responsibilities • Contractual
• Financial
• Personnel management
• Security
• Safety
• Technical
Decision-making information is often captured in a matrix.
List of decision authority Elements of the list may include:
levels • Description of the level
• Roles involved include reviewer and approver
• Escalation procedures
• Communication requirements
113
Enabling Safety (ESAF)

ESAF Overview
Intent
Minimizes and mitigates safety risks within the tolerance parameters and constraints of
operational effectiveness, time, and cost.
Value
Reduces the residual safety hazard risk to an acceptable tolerance level.

Consider and address safety in all aspects of the solution, including products, processes,
services, or environments. This encompasses both facilitating and managing safety activities.
Practice Summary
Level 1
ESAF 1.1 Identify and record safety needs and hazards.
ESAF 1.2 Address prioritized safety needs and hazards.
Level 2
ESAF 2.1 Identify critical safety needs and constraints, keep them updated, and
use to develop and keep safety objectives current.
ESAF 2.2 Develop, keep updated, and follow an approach to address workplace
environment safety.
ESAF 2.3 Develop, keep updated, and follow an approach to address functional
safety for the solution.
Level 3
ESAF 3.1 Establish and deploy an organizational safety capability.
ESAF 3.2 Perform safety evaluations periodically and take action on results.
ESAF 3.3 Develop, keep updated, and follow organizational safety control
strategies.
114

Safety activities help to achieve an acceptable level of risk through a systematic approach of
identifying safety objectives and developing and keeping updated an approach to address the
types of safety considerations. The most effective safety techniques are embedded within
processes, plans, equipment, systems, and the work environment, and are not built as an add-
on. Critical to establishing an effective safety approach within the organization are an
organizational safety capability, ongoing evaluations of potential safety hazards, periodic
evaluations of safety approaches and outcomes, and established safety controls.
Many organizations follow the concept of As Safe As Reasonably Practicable (ASARP). This is a
fundamental principle of adequate safety. An ASARP determination evaluates current safety
performance parameters against costs and other issues to optimize the safety environment. The
solution is ASARP if an incremental improvement in safety would require a disproportionate
deterioration of performance in other areas.
When a major or catastrophic safety related event, e.g., active shooter, bomb threat, or
earthquake occurs, normal operations is likely to be disrupted and therefore, continuity and
disaster recovery plans should be established and used to restart and continue operations.
External References

British Standards 10754-1:2018 https://www.en-standard.eu/bs-10754-1-2018-
(Information technology - System information-technology-systems-trustworthiness-
trustworthiness) governance-and-management-specification
International Electrotechnical https://www.iec.ch/functionalsafety/?ref=extfooter#:~
Commission (IEC) 61508: Functional :text=It%20is%20fundamental%20to%20the,achieve
Safety - IEC 61508 Explained %20safety%20for%20the%20equipment.
International Organization for https://webstore.ansi.org
Standardization (ISO) 26262 Road
Vehicles – Functional Safety

Continuity (CONT)
Planning (PLAN)
Requirements Development Management (RDM)
115
Level 1
ESAF 1.1
Practice Statement
Identify and record safety needs and hazards.
Value
Minimizes the occurrences and impacts from safety hazards.


Identify safety hazards through analysis of the:
• System hardware and software
• Infrastructure and environment
• Intended use or application
• Service delivery and operations
• Supply chain
Example Activities

Identify and record current and potential Record identified hazards and improvements in a
safety hazards and improvements. hazard list.
Identify safety needs.

List of identified hazards and Record all known context information, e.g., conditions
improvements and consequences of hazard occurrence.
List of safety needs
116
ESAF 1.2
Practice Statement
Address prioritized safety needs and hazards.
Value
Identifies and mitigates safety hazards to an acceptable level, raising the level of operational
confidence and sustainability.


Example Activities

Assess and determine the potential
consequences of hazards and improvements.
Prioritize hazards and improvements based
on potential impact and expected results.
Create action plans to address prioritized
hazards and improvements.

Hazard logs
Analysis reports
117
Level 2
ESAF 2.1
Practice Statement
Identify critical safety needs and constraints, keep them updated, and use to develop and keep
safety objectives current.
Value
Verifies that safety needs are effectively aligned with business priorities for performing the
work.


Enable safety attributes to be a key consideration through established guidelines, standards,
and expectations. Continuously review the expectations and safety objectives and processes;
keep them updated for alignment with changing technologies, relevant industry safety
standards, guidelines, environmental laws and standards, and emerging issues. Consider and
evaluate threats to the personal health and safety of personnel, customers, and the public.
Maintain ongoing visibility of safety sponsorship, commitment, and constraints, e.g., in the
definition of process needs and objectives, workplace and functional standards, organizational
objectives, reviews, management meetings, and stakeholder reviews.
Example Activities

Define safety objectives. Establish and keep updated safety objectives that have
linkages to customer requirements, as well as the business
mission, vision, and goals. Consider mandates from local and
government officials, e.g., stay at home orders, regulatory
standards, and guidelines. Additional examples may include:
• Safety cost to be below specified amount
• Safety events, hazards, and accidents
Consider the impact of constraints when defining safety
objectives.
Identify, record, and prioritize Conduct safety evaluations to identify sources of potential
potential hazards and harm or damage. Consider prioritization based on impact,
improvements. cost, and life safety implications of the hazards experienced.
It is not feasible to address all hazards and improvements
118

with limited resources. Align the highest priority or most
critical identified hazards and improvements to be addressed
based on the safety objectives.
Define and implement action
plans and track to closure.
Conduct safety reviews and • For example, share safety information in All Hands
communicate safety results, meetings, management meetings, town hall meetings, and
progress, and related emergency or ad hoc safety meetings
information with affected • Discuss safety related goals and objectives, and outline
stakeholders. management’s position on following safety processes
• Communicate and reinforce safety vision, objectives, and
expectations, and the corresponding safety processes and
procedures
Example Work
Further Explanation
Products
Safety vision A safety vision or mission sets expectations, culture, goals, and
commitments for how the operations and work products address safety
needs and hazards.
Safety objectives
Internal Reinforce safety messages and issues through consistent
communications communication channels. Examples include:
• Internal newsletters
• Quarterly reports
• Emails
Safety strategy Include alignment to goals, objectives, as well as alignment to any
mandates from government officials.
Safety roles and Include identification and management of specific hazard related tasks
responsibilities and role alignment in work.

Managing Security Threats and Vulnerabilities (MST)
Planning (PLAN)
119
ESAF 2.2
Practice Statement
Develop, keep updated, and follow an approach to address workplace environment safety.
Value
Maximizes safety consistency and efficiency for the workplace and operations.

The workplace environment safety approach is communicated to affected stakeholders.

Consider and use historical safety hazard and related mishap data, including lessons learned.
The identification of hazards is a responsibility of all personnel. Consider hazards that can occur
within any aspect of safety and over the full lifecycle of the solution or mission.
Example Activities

Identify workplace Consider:
environment safety • Physical environment
requirements. • Safety equipment
• Personnel workspace, including social distancing requirements
• Physical workspace layout and placement requirements
• HVAC and environmental cleaning
• Building operations and physical layout, e.g., badge access,
entry/exit parameters, sign-in procedures, fire exits
• Impacts of contact tracing
• Relevant industry safety standards and guidelines
Identify business
considerations and
trade-offs.
Establish reporting
mechanisms.
Define workplace Consider safety verification and validation techniques. Ensure the
environment safety defined approach is consistent with the operational minimum
approach. acceptable safety tolerance limits, and that it is documented in a
plan, e.g., safety plan.
Adjust workplace Consider:
environment based on • Work site
requirements. • Workstations
120

• Social distancing requirements, if applicable
• Physical building, e.g., entry/exit parameters, fire exits

Workplace environment This should include all applicable regulatory guidelines and
safety requirements requirements for safety, e.g., local, national, and international.
Safety Plan For example, the United States Occupational Safety and Health
Administration (U.S. OSHA) recommends the following basic
elements:
• Policy or goals statement
• List of responsible persons
• Hazard identification
• Hazard controls and safe practices
• Emergency and accident response
• Employee training and communication
• Recordkeeping
In addition, many national or international regulatory bodies like
OSHA have requirements for:
• Hazard Communication Plan for facilities where workers could
be exposed to hazardous chemicals. Failure to have a written
hazard communication plan is a very frequently cited OSHA
violation.
• Emergency Action Plan and Fire Prevention Plan
• Bloodborne Pathogens Exposure Control Plan
• Respiratory protection for workplaces where employees are
required to use respirators
• Hazardous energy control (lockout/tagout) program to
prevent injuries during equipment service and maintenance
• Permit-required confined space plan for any facility that
allows entry to permit-required confined spaces
Safety analysis reports Consider:
• Event tree analysis
• Fault tree analysis
• Failure Mode and Effects Analysis (FMEA)
• Risk assessment
Safety equipment Examples include:
• Protective eye ware
• Eye wash stations
• Face masks
• Hand sanitizer
• Disinfectant
• Defibrillator
121

• First aid kits
• Medicine kits
• Personal Protective Equipment (PPE)
• Rubber gloves
• Badge readers
• Anti-static wrist straps or grounding bracelets
• Ultraviolet protection
• Overhead lighting
• Automated bathroom or foot-pull doors
• Respirators
• Safe rooms or shelters
• Backup power generators
• Surge protectors
• Battery-powered emergency lighting
• Painted walk lanes
• Warning signs and labels
Safety scenarios and case Consider emergency scenarios and workaround options.
studies for common Consider scenarios for unique circumstances, e.g., pandemic,
activities and issues power outages, evacuation, and fire drills.
Safety operational Examples include:
reference materials • Posters
• Information reference cards, e.g., employee assistance
hotline contact information
• Emergency escalation and contact information
• Emergency exit information
• Building evacuation protocols, e.g., fire drills, active shooter
drills, rally points, and designated check-in personnel

Continuity (CONT)
Planning (PLAN)
ESAF 2.3
Practice Statement
Develop, keep updated, and follow an approach to address functional safety for the solution.
Value
Maximizes consistency and efficiency to ensure safe operations.
122


A robust approach to addressing safety should include both a strategic and tactical view.
Functional safety is fundamental to enabling the management of correct operations and
associated risk reductions within the solution. It involves the detection of a potentially
dangerous condition resulting in the activation of a protective or corrective device, mechanism,
or process to prevent hazardous events arising or providing mitigation to reduce the
consequence of the hazardous event.
Example Activities

Identify functional Consider:
safety requirements. • Architecture
• Hardware
• Software
• Third-party hardware or software
• Interfaces and connections
• Operational environment
• Service system
• Relevant industry safety standards and guidelines
• Potential safety liabilities, e.g., falls or accidents on property
• Emergency shut-offs
Identify business and Consider potential points of operational hazard, failure, and
mission considerations outcome use cases.
and trade-offs.
Establish reporting Consider safety incident reports, safety hazard logs, escalation
mechanisms. mechanisms, and safety compliance reports.
Define functional safety Consider the following when establishing an approach:
approach. • System hardware and software
• Service system components and tools
• Environment in which the solution will exist
• Intended use or application of solution
• Prioritization of methods and criteria, aligned to hazard severity
categories, to consider for minimizing potential hazard impacts,
e.g., remove through design, implement control devices,
procedures, and training
Consider safety verification and validation techniques for hardware
and software components of the solution. Typical techniques
incorporate independence from development activities and
123

functions. Safety activities may be performed by an individual(s)
other than the developer of the product or service.
Ensure the approach defined is consistent with the operational
minimum acceptable safety tolerance limits, and documented in a
plan, e.g., safety plan.
Adjust functional safety
operations based on
requirements.

Functional safety requirements Include operational definitions of technical safety
terminology, e.g., incidents, faults, errors, and failures.
Operational safety guidelines Consider equipment operating and control procedures.
Safety hazard identification form
Safety standards for product Consider:
lifecycle • Concept
• Development
• Change management
• Testing or prototype
• Production
• Operations and maintenance
• Services
• Disposal
Software and hardware Include considerations of:
standards and best practices • Detection and handling of incidents, faults, errors, and
failures
• Fail-safe modes
• Redundancy management, e.g., detection redundancy
and mitigation redundancy
• Trusted kernels and services
• Safe subset of a high-level programming language
• Multiple language implementations
• Voting systems
• Cross training of personnel, e.g., promote awareness,
reduce accidents
Operational minimum acceptable Consider:
safety tolerance limits • Acceptable levels of maturity for technology and
equipment
• Safety verification and validation issues
124

Continuity (CONT)
Product Integration (PI)
125
Level 3
ESAF 3.1
Practice Statement
Establish and deploy an organizational safety capability.
Value
Improves efficiency in operational environments to minimize safety hazards and issues.


Establish a safety operations function to oversee all safety operational activities. This includes
preparation, planning, and execution for the following:
• Direction, control, and coordination
• Communications infrastructure
• Continuity of operations
• Transportation
• Emergency public information
• Evacuation, shelter-in-place, and lockdown
• Health and medical
• Resource management
• Damage assessment
• Disaster management
• Critical incident stress management
• Manufacturing, laboratory, and test facilities and environments
• Safety evaluations, impact analysis, scenarios, and drills
• Temporary backup or alternate site facilities and environments
• Safety training
Coordination with safety-related agencies and regulatory bodies, e.g., United States Federal
Emergency Management Agency (U.S. FEMA), U.S. OSHA, United Kingdom Health and Safety
Executive (UK HSE), and European Union OSHA (EU-OSHA). The safety operations function
could be performed by an individual, group, or team.
126
Example Activities

Define safety awareness, Identify and determine:
knowledge, roles, and skills. • Appropriate roles and skills required, e.g., quick
response team (QRT)
• Roles that are responsible for ensuring safety
• Roles specific to safety assurance
• Industry safety resources
Provide safety requirements and Consider:
content input to the • Specific safety scenarios
organizational training program. • Case studies aligned to areas of responsibility and
accountability
• Common industry safety hazards and results of safety
incidents
• Applicable local, national, and international regulations
and mandates
Provide support for safety Consider availability and accessibility of standard forms
inquiries. and reports.
Conduct research on safety
trends and regulations.
Develop decision or fault trees. Demonstrate the conditions that trigger specific
circumstances.
Monitor safety tolerance limits. Analyze information from periodic safety assessment
activities.
Establish safety action plans. Consider appropriate adoption mechanisms in response to
regulations and mandates from government officials.

Safety roles, skills, and training Consider:
matrix • Training on safety standards
• Organization specific activities
• Organization requirements
• Organization process assets
• Industry reports on safety experience, etc.
Technical bulletins and reports Reports can include:
• Notification of safety trends
• Incident reports and resolution
• Operational and occupational safety guidance
127

Safety action plans Consider:
• Priority alignment, e.g., high, medium, and low
• Short-term, immediate actions versus long-term actions

Monitoring and Control (MC)
Planning (PLAN)
ESAF 3.2
Practice Statement
Perform safety evaluations periodically and take action on results.
Value
Ensures the approach to managing safety remains current, effective, and efficient.

Establish objectives, criteria, and mechanisms for conducting organizational safety evaluations
and verification and validation activities. Evaluation activities includes analysis of all relevant
safety events, occurrences, actions, and outcomes.
If an unacceptable increase in hazard safety risk is identified, then identify short-term and long-
term actions to reduce the risk to an acceptable level. Depending on the product and hazard
scenario, this may take the form of operational limitations, usage restrictions, in-service
tests/inspections, or design/manufacturing changes.

When evaluating in-service failures, evaluate and analyze the performance against the minimum
safety tolerance limits. Review the effects of the failure for impact, e.g., if there were
unexpected or unintended consequences, and if the design controls and mitigations are
adequate and functioning correctly.
Example Activities

Collect information and Consider relevant historical data and lessons learned, in
conduct analysis from addition to current operational environment. Evaluate the
identified potential or probability of occurrence and consequence for identified
current hazards. hazards. Record traceability and cross-reference each hazard
with analysis.
128

Examples of hazard identification and analysis techniques
include:
• Hazard and Operability Analysis (HAZOP)
• Functional Failure Analysis (FFA)
• Failure Modes and Effects Analysis (FMEA)
• Structured interviews
• Incident reporting
• Brainstorming
Evaluate production non- Evaluate against operational minimum acceptable safety
conformances and in- tolerance limits, and any available baseline hazard assessment
service failures for safety information. For example, when evaluating in-service failures,
impact. consider:
• Performance against the established probability of in-service
failure
• If planned mitigations and design controls functioned as
expected
• Any unintended consequences and their impacts
• Impact and requirements for restarting operations and
continuity
Conduct surveys.
Conduct safety field
investigations.
Conduct safety reviews and
inspections.
Conduct safety drills.
Plan, coordinate, and Examples of contractual safety certifications:
participate in contractual • Federal Aviation Agency airworthiness certification of
safety certification activities. designs and modifications
• Department of Defense airworthiness determination
• Nuclear and non-nuclear munitions certification
• Flight readiness reviews
• Flight test safety review board reviews
• Nuclear Regulatory Commission licensing
• Department of Energy certification
• Occupational Safety and Health Administration (OSHA)
outreach training
• Control of Substances Hazardous to Health (COSHH)
Conduct objective Consider leveraging external safety industry experts, when
evaluations of safety possible, to promote objectivity.
program. Include consideration of the following concepts, to the extent
the concept is applicable:
• Hazardous components
129

• System interfaces or connections
• Operating environment constraints
• Testing
• Operations and maintenance
• Emergency procedures
• Diagnostics
• Built and natural infrastructure
• Environment
• Malfunctions
• Conformance to government mandates and regulations

List of in-service failures
List of production non-conformances
Analysis reports
Survey results
Assessment results Internal and external assessment results.
Evaluation report
Data from operational activities

Continuity (CONT)
Peer Reviews (PR)
ESAF 3.3
Practice Statement
Develop, keep updated, and follow organizational safety control strategies.
Value
Provides common organizational understanding and responsiveness to address and minimize
safety issues.
130


Example Activities

Establish hierarchy of safety controls Consider:
• Elimination
• Substitution
• Engineering Controls
• Administrative Controls
• Personnel Protective Equipment
Establish confidential reporting mechanisms. Establish mechanisms to protect
those who report issues, e.g.,
whistleblowers.
Define safety triggers and thresholds.
Define safety scorecards.
Execute safety control strategies and record results.
Review and revise safety control strategies.

Safety control strategies Consider:
• User interfaces or connections
• Safety by design parameters
• Equipment usage
• Solution requirements
• Operational needs for different teams
• Safety regulations
Safety triggers and thresholds
Safety dashboards Example dashboard information includes:
• Number of days since last safety incident
• Number of safety incidents
• Additional safety measurements
Safety measurements Example measurements include:
• Number of safety observations per week or quarter
131

• Site inspections per week
• Near or almost miss situations
• Safety observations
• Costs for training
Safety reports and records

132

ESEC Overview
Intent
Develops and keeps updated the security approach that includes anticipating, identifying, and
taking actions to avoid or minimize the impacts of security issues on an organization or solution.
Value
Reduces the impact of security threats and vulnerabilities on business performance.

Identifying security needs and constraints is an ongoing, 24/7, 365 days a year activity. It can
never stop and cannot be an after-thought or a tradeoff item like schedule, cost, and quality.
Enabling security includes systematically identifying, assessing, and addressing security needs
across a project or organization. There are three primary groups of needs covered by the
security approach:
• Physical security and environmental needs
• Mission, personnel, and process security needs
• Cybersecurity, technology, and related information security needs
More mature organizations typically have a security program or capability, which can be
centralized or spread across multiple functions or groups who identify, evaluate, and continually
analyze security threats and security posture improvement opportunities.
Practice Summary
Level 1
ESEC 1.1 Identify and record security needs and issues.
ESEC 1.2 Address prioritized security needs and issues.
Level 2
ESEC 2.1 Identify and record security needs, keep them updated, and use to
develop a security approach and objectives.
ESEC 2.2 Develop, keep updated, and follow an approach to address physical
security needs.
ESEC 2.3 Develop, keep updated, and follow an approach to address mission,
personnel, and process-related security needs.
133
ESEC 2.4 Develop, keep updated, and follow an approach to address cybersecurity
needs.
Level 3
ESEC 3.1 Establish and deploy an organizational security operations capability.
ESEC 3.2 Develop, follow, and implement an organizational security strategy,
approach, and architecture and keep them updated.
ESEC 3.3 Periodically perform security reviews and evaluations throughout the
organization and take action on results.

Enabling and managing security typically covers the following three areas and is referred to as
the “CIA triad”:
• Confidentiality: This is protecting sensitive, private information from unauthorized access
so that only authorized users and processes can access or modify data. Protecting
confidentiality is dependent on being able to define and enforce access levels for
information. In some cases, doing this involves separating information into various
collections that are organized by who needs access to the information and how sensitive
that information is, e.g., the amount of damage suffered if the confidentiality was
breached. Examples of the most common means used to manage confidentiality include
access control lists, volume and file encryption, and file permissions.
• Integrity: Data should be kept updated in a correct state, and nobody should be able to
improperly modify it, either accidentally or maliciously. Integrity or data integrity is
designed to protect data from deletion or modification from any unauthorized party, and it
allows actions to be reversed when an authorized person makes a change that should not
have been made.
• Availability: This refers to the actual availability of the correct and appropriate data so
that authorized users can access data whenever they need to do so. Authentication
mechanisms, access channels, and systems all need to work properly for the information
they protect and ensure it is available when it is needed. High availability systems are the
computing resources that have architectures that are specifically designed to improve
availability. Based on the specific system design, this may target hardware failures,
upgrades, or power outages to help improve availability, or it may manage several
network connections to route around various network outages.
There are many elements of security that may apply to an organization, depending on business
needs, objectives, and potential threats. These elements tend to be applicable across different
organizational types, contexts, and environments and can include:
• Access control, authorization, and identity management and monitoring
• Physical access
• Logical access
• Network and system access
134
• Removable media protection and access

• Physical protection
• Recovery
• Personnel security
• Identification and authentication
• Mission and solution security
• Systems, communications, and network protections
• Systems and data integrity, including backup and restoration fidelity
• Assurance, audit, accountability, and related data management
• Security reviews and evaluations
• Security countermeasures
• Training and awareness (including situational awareness)
• Exploitation
• Security incident response, recovery, and resilience
• Risks, threats, and vulnerabilities management
• Processes and tools to support the above
Defense in depth is an approach to cybersecurity in which a series of defensive mechanisms are
layered to protect valuable data and information. If one mechanism fails, other mechanisms are
in place to thwart an attack. This multi-layered approach with intentional redundancies
increases the security of a system as a whole and addresses many different attack vectors.
Defense in depth is commonly referred to as the "castle approach" because it mirrors the
layered defenses of a medieval castle. Before a castle can be penetrated, the intruder is faced
with the moat, ramparts, drawbridge, towers, battlements, and so on.
External References

British Standards 10754-1:2018 (Information technology - System https://shop.bsigroup.co
trustworthiness) m/ProductDetail?pid=00
0000000030351844
ISO/IEC TR 24028:2020 Information Technology – Artificial https://www.iso.org/stan
Intelligence Overview of Trustworthiness in Artificial Intelligence dard/77608.html
NIST Special Publication 800-53, Security and Privacy Controls for https://www.nist.gov
Federal Information Systems and Organizations
NIST Special Publication 800-171, Physical Protection, section 3.10 https://www.nist.gov
NIST Special Publication 800-218, Secure Software Development https://www.nist.gov
Framework

135
Context Specific
DevSecOps
cooperation between development, operations, and security to plan, develop,
test, deploy, release, and keep updated a secure solution.
A fundamental premise of DevSecOps is that teams incorporate security practices and personnel
into the application development process from the start and throughout all subsequent
development efforts with the goal of delivering a secure product. Security is not an
afterthought, a bolt-on at the end of the development lifecycle, or a separate set of unrelated
events. Security is a shared responsibility by everyone on the team. As a result, DevSecOps
teams should include security as a critical element during Design, Development, Delivery, and
Operations. For example, the team should also automate security testing gates where practical
and cover development, test, and production environments. Automating security, like any other
recurring task, is critical to the success of DevSecOps teams.
136
Level 1
ESEC 1.1
Practice Statement
Identify and record security needs and issues.
Value
Minimizes disruption to the work and business operations resulting from security issues.


Sources of security needs and issues can include:
• Software
• Hardware
• Firmware
• Physical security
• Hardcopy or softcopy data
• Availability of records in a secured environment
• Access and entry restriction
• Equipment usage and password protection
• Data security
Example Activities

Identify security needs and issues associated with the work

List of security issues and Typically prioritized and organized by assessing factors
potential impacts such as potential impact, likelihood, etc.

137
ESEC 1.2
Practice Statement
Address prioritized security needs and issues.
Value
Enables organizations to respond and address the most critical security needs rapidly and
effectively.


Example Activities

Review, prioritize, and record Security issues and their impact on the work can vary based
security issues and keep them on the type of work and multiple internal and external
updated. factors. Review impacts on business objectives, costs,
schedule, quality, functionality, risk appetite, environmental
factors, and other aspects of the work; and then prioritize
based on both impact and likelihood of occurrence.
Record security actions and
track them to closure.

Security action plans

138
Level 2
ESEC 2.1
Practice Statement
Identify and record security needs, keep them updated, and use to develop a security approach
and objectives.
Value
Improves an organization’s capability to address ongoing security needs rapidly and
consistently.

Identifying security objectives helps provide a clear focus for priorities and work without under
or over allocating security resources, preventing overspending and protection gaps. The
approach and objectives should integrate with, refer to, or include the approaches for aspects
of security, depending on the project, solution, or organizational needs and constraints.
Explicitly specify and record security objectives operationally and keep them updated. This helps
steer the approach away from common pitfalls:
• Focusing on technical security actions or steps, without a clear understanding of the
results of the actions, typically results in ineffective and costly security measures
• Focusing on a specific goal of security, e.g., confidentiality; and specific data, while
overlooking other goals, data, or functionalities, results in protection gaps
Use security objectives to direct the selection of security approaches, actions, and
implementation. Specifically:
• Rate the relevance of security threats by analyzing whether a threat leads to a violation of
a security objective with significant business impact
• Review the selection of security actions from the perspective and likelihood of reasonably
achieving the security objectives, given other constraints
Security measurements may have various levels of severity that can vary depending on need,
source, and potential impact. Security measurements should be clearly traceable to security
objectives, operationally defined, analyzed, and continually reviewed and updated as security
risks and impacts change to enable timely and relevant insight into the progress towards
achieving those objectives.
139

There are no completely secure solutions. Typically, applying every possible security step or
action is not feasible given the cost and effort of implementation. Instead, plan and design a
solution, application, or service to meet its security objectives at the outset. A comprehensive
approach to address security needs can include the rigor of a defense in depth approach.
Classify security objectives into protection goals for the confidentiality, integrity, and availability
of data and functionality. For example, the integrity of operational data could be a security
objective if there is an expected impact to the business when violations of data integrity occur,
such as an attacker manipulating operational data that is used in making business decisions.
Other examples of impacts are damage to machines and the environment. Ensure that the
security objectives and their related measurements are aligned to the security strategy and
approach.
Example Activities

Define, record, and keep Include statements of relevance of confidentiality, integrity, and
security objectives updated availability for the data and functionality, based on impact levels
for the work. for loss of confidentiality, integrity, and availability.
Identify and sort security Sort and categorize security issues by severity levels, including
issues into manageable impacts, cost, etc. to align to security objectives.
categories and keep
updated.
Identify, record, and keep Security is a crucial element of solution planning, operations,
the security approach and delivery; and this information is typically contained in a
updated. plan, e.g., security plan. The security approach includes the
following elements:
• Identifying the appropriate set of stakeholders and tasks
• Managing security threats and vulnerabilities
• Identifying and implementing appropriate controls
• Determining the necessary resources
• Enabling project, systems, and organizational resiliency
• Developing and keeping the security approach current with
business needs and evolving threats and vulnerabilities
• Continually evaluating the organizational security approaches
and posture, and identifying strengths, weaknesses,
improvement opportunities, and security innovations
• Considering defense in depth implementations, e.g.,
concentric rings, overlapping redundancy, or
compartmentalization
Identify and protect data Consider the critical components of confidentiality, integrity,
and functionality in the availability, and privacy regarding management of the data and
solution to achieve the functionality:
overall business objectives. • Primary use cases
140

• Solution implementation requirements
• Organizational consistency and requirements
• Personal information and privacy regulations
Rate potential and realized • Use severity levels with impact categories, likelihood, and
issues and impacts quantifiable impact levels for consistent measurement of the
resulting from violation of impact rating
data management
principles.

Documentation of security objectives for data and
functionality, and associated levels of impacts
Documentation of security approach

ESEC 2.2
Practice Statement
Develop, keep updated, and follow an approach to address physical security needs.
Value
Enables organizations to address and resolve physical security needs and issues consistently
and effectively.

Consider the information and outputs from identifying, assessing, and addressing physical
security risks, issues, and needs; and apply additional rigor of systematic methods and
techniques to establish an approach for addressing physical security.

A physical security approach includes, but is not limited to:
141
• Establishing and maintaining physical facilities and infrastructure, e.g., physical access,
physical access devices, entry and exit including supplier loading and offloading access
points, establishment, and management of Sensitive Compartmented Information
Facilities (SCIFs)
• Limiting physical access to organizational information systems, equipment, and the
respective operating environments to authorized individuals. This may often include using
background checks or ensuring individuals have the appropriate clearance level.
• Enforcing policies regarding safe keeping of Controlled Unclassified Information (CUI) or
other sensitive information. A common occurrence an organization can experience with
physical security is intruders who tailgate their way into a facility for the purpose of
obtaining information. To prevent this from happening, always require employees to wear
badges, provide them with physical security entry and exit tokens or fobs, and train them
to be aware of who is entering the building with them. Report unidentified personnel
within the facility to a security officer on site immediately. In the case that an intruder
does enter your facility, lock down sensitive or CUI data through locking computer and
systems workstations and verifying that it is not out in the open. For example,
implementing a “clean desk” policy requires placement and storage of sensitive data in
locked and fire-proof file cabinets and/or drawers. Another key aspect of physical security
is implementing security surveillance for facilities, especially by the entrances and exits.
• Protecting and monitoring the physical facility and support infrastructure for those
information systems, and the information they control, including verifying and physically
securing networks and the data that resides on and is transported by them
• Defining and improving processes to escort visitors and monitor visitor activity
• Provide security mechanisms, training, and protocols to address protection and security of
human life, such as active shooter drills, fire drills, shelter in place protocols, and actions
needed to address potential impacts of social or civil unrest, e.g., protests, rallies
• Maintaining and reviewing audit logs of physical access
• Controlling and managing physical access devices
• Enforcing safeguarding measures for sensitive information such as CUI at alternate work
sites, e.g., telework sites, including personnel home physical security when personnel
work from their homes
• Communicating and training personnel on physical security policies and approaches
• Establishing visual, audio, and signal perimeters or barriers
• Establishing and maintaining a trained and armed security force
• Establishing aerial or space surveillance
142
Example Activities

Identify, record, and keep an approach Review and keep the approach updated, based on
to address physical security needs the frequency of changes in physical security needs.
updated. Consider defense in depth implementations, e.g.,
concentric rings, overlapping redundancy,
compartmentalization.
Record physical security needs in a
defense in depth approach.

Recorded physical security approach
Recorded and current defense in depth
approach that includes physical security needs

Requirements Management and Development (RDM)
ESEC 2.3
Practice Statement
Develop, keep updated, and follow an approach to address mission, personnel, and process-
related security needs.
Value
Minimizes the impact of security issues on mission and personnel.


Mission security needs are typically addressed through an organizational mission security
function. Mission security may involve:
143
• Protecting the assets of the mission through secure design, operations, and management
governance
• Aligning work and work products within mission-relevant laws, regulations, and
requirements
• Applying a risk-based approach to mission security design, guidance, and decisions
• Continuously safeguarding against current and potential threats to the mission
One aspect of personnel security is privacy. Privacy frameworks, such as the U.S. National
Institute of Standards and Technology (NIST) Privacy Framework, can help organizations
manage privacy risks by:
• Taking privacy into account as solutions, systems, products, and services are designed
and deployed that affect employees, customers, and stakeholders
• Communicating with and training personnel in privacy policies and practices
• Encouraging cross-organizational workforce collaboration—for example, among executives,
legal, and Information Technology (IT) through the development of profiles, selection of
tiers, and achievement of outcomes
• Identifying a core set of privacy protection activities and outcomes that allows for
communicating prioritized privacy protection activities and outcomes across an organization
from the executive level to the implementation/operations level. The core includes an
increasingly granular set of activities and outcomes that enable an organizational dialogue
about managing privacy risk.
• Using a profile approach representing an organization’s current privacy activities or desired
outcomes. To develop a profile, an organization reviews all the outcomes and activities in
the core to determine which are most important to focus on, based on business or mission
drivers, data processing ecosystem role(s), types of data processing, and individuals’ privacy
needs. An organization can develop or add functions, categories, and subcategories as
needed. Use profiles to:
o Identify opportunities for improving privacy posture by comparing a current profile
(the “as is” state) with a target profile (the “to be” state)
o Conduct self-assessments and communicate within an organization or between
organizations about how to manage privacy risks
144
• Implementing tiers to provide a point of reference on how an organization views privacy

risk and whether it has enough processes and resources in place to manage that risk.
Tiers reflect a progression from informal, reactive responses to approaches that are agile
and risk informed. When selecting tiers, an organization should consider its target
profile(s) and how achievement may be supported or hampered by its current risk and
opportunity management practices, the degree of integration of privacy risk into its
enterprise risk and opportunity management portfolio, its data processing ecosystem
relationships, and its workforce composition and training program. Process security is
an approach that allows for a systematic security evaluation of business processes. The
approach is based on clearly understanding process flows. It is frequently implemented by
conducting what-if analysis of potential threats.
Security processes and policies are established for how personnel and contractors are kept safe
and secure, e.g., evacuation routes posted in hallways, distributed, and communicated
Emergency Response Procedures, and disaster preparedness training and kits. In addition,
personnel security processes and policies should state when background investigations are
required. Projects and organizations should identify responses to threats to personnel arising
from manipulation by offensive operators, e.g., extortion or bribery.
Process Security includes organizational and behavioral activities focused on preventing
undesired accidents and unexpected events that may have a negative impact to a given
process. These activities aim to develop and promote a safe and secure operating environment
in which processes are performed with no risk of injury or damage to people or the security of
the organization.
There are four core areas an organization needs to consider when managing process security:
• Confidentiality: ensuring that process data is kept safely and not accessed by
unauthorized persons
• Monitor and control: providing process screening and oversight to ensure early detection
of possible issues and defects
• Risk mitigation: developing and implementing a strategy for identifying and mitigating
process-related risks and their negative consequences
• Integrity: ensuring that every single process is an integral part of the entire operational
environment, so all processes are performed under certain relationships with each other
Example Activities

Identify, record, and keep an approach Review and keep the approach updated, based on
to address mission, personnel, and the frequency of changes in mission, personnel, and
process needs updated. process security needs and assurance requirements.
Record mission, personnel, and
process needs in a defense in depth
approach.
145

Recorded mission, personnel, and process
security approach
Recorded and current defense in depth
approach that includes mission, personnel,
and process needs

Planning (PLAN)
ESEC 2.4
Practice Statement
Develop, keep updated, and follow an approach to address cybersecurity needs.
Value
Enables an organization to anticipate and more effectively manage and respond to cybersecurity
needs.

The terms “cybersecurity” and “information security” are frequently used interchangeably, but
in the CMMI Performance Solutions ecosystem, cybersecurity is a part of information security.
Cybersecurity includes the protection of information assets by addressing threats to information
processes, stored, and transported by internetworked information systems, solutions, and their
related support services and supply chain. Unlike information security, cybersecurity does not
include natural hazards or disasters, personnel mistakes, physical security and mission,
personnel, and process security. If the introduction of offensive and human adversary threats is
removed through interconnected systems, cybersecurity would not be an issue, and information
security alone would be sufficient.
Cybersecurity involves setting an approach and objectives for:
• Confidentiality: protection from unauthorized access or disclosure
• Integrity: protection from unauthorized modification
• Availability: protection from disruptions in access
• Situational awareness: staying informed and flexible to identify and effectively manage
potential new threats, such as new cybercrime methods and Advanced Persistent Threats
(APTs)
146

Refer to graphic Figure ESEC-1: Relationship among Cybersecurity and Other Security Domains
below for the relationship between cybersecurity, information security, and other security
domains. Information security refers to the processes and methodologies which are designed
and implemented to protect print, electronic, or any other form of confidential, private, and
sensitive information or data from unauthorized access, use, misuse, disclosure, destruction,
modification, or disruption. Information security includes natural hazards, personal mistakes,
and physical security. Cybersecurity and information security are parts of an overall security
approach. Cybersecurity incorporates aspects of network, internet, and application security in
an integrated fashion. Other aspects of information security include: supplier security, solution
component security, service delivery, and operations security.
Figure ESEC-1: Relationship among Cybersecurity and Other Security Domains
Example Activities

Identify, record, and Review and keep the approach updated, based on the frequency of
keep an approach changes in cybersecurity needs. The approach should cover
updated to address cybersecurity concepts and requirements, including technology,
cybersecurity and information, solutions, systems, and telecommunications. Typically,
security needs and cybersecurity includes five basic domains:
issues. • Understanding and addressing cybersecurity concepts
o Basic risk and opportunity management
147

o Common attack vectors and threat agents
o Patterns and types of attacks
o Types of security policies and procedures
o Cybersecurity control processes, procedures, and protocols
• Security Architecture Principles
o Common security architectures and frameworks
o Perimeter security concepts and requirements
o System topology concepts and requirements
o Firewalls and encryption
o Isolation and segmentation
o Methods for monitoring, verifying, validating, detection, and
login
• Security of networks, systems, applications, and data
o Process controls for: Security risk evaluations, threat and
vulnerability management, and penetration testing
o System, application, and network threats and vulnerabilities
o Effective controls for managing vulnerabilities
• Incident response
o Criteria for identifying and understanding the distinction
between an event and an incident, and steps needed when
responding to a cybersecurity incident
o Incident categories
o Disaster recovery and business continuity plans
o Activities and steps for incident response
o Forensics and preservation of evidence
o Criteria, processes, and protocols for addressing APT
• Security implications and adoption of evolving technology
o Mobile devices, e.g., Bring Your Own Device (BYOD)
o Internet of Things (IoT)
o Cloud computing and storage
o Digital collaboration, e.g., social media
o Autonomous operations, e.g., transportation, utilities, and
manufacturing
o Robotic Process Automation (RPA)
o Artificial Intelligence (AI)
o Cryptocurrency, e.g., bitcoin
Record cybersecurity
needs in a defense in
depth approach.
148

Recorded and updated cybersecurity approach
Recorded and current defense in depth approach
that includes cybersecurity needs

149
Level 3
ESEC 3.1
Practice Statement
Establish and deploy an organizational security operations capability.
Value
Increases organizational agility to address security issues more rapidly and effectively.

With an organizational perspective of security, including interfaces/interchanges with other
groups, an organization implements advanced security and cybersecurity activities such as:
• Establishing an organizational security operations capability or response center
• Conducting intelligence analysis on targeted data
• Monitoring, anticipating, acting, and reporting on security and emerging cybersecurity
risks
• Establishing an organizational security awareness program
• Coordinating and communicating with external law enforcement, security services, or
intelligence services, as required
• Monitoring and addressing solution and solution component security
• Monitoring and addressing service delivery and operations security needs
• Monitoring and addressing supplier management security needs

Security operations functions are most often centralized in a Security Operation Center (SOC),
although the responsibilities and activities may be distributed across an organization including
multiple SOCs. A SOC is typically an organizational function employing people, processes,
infrastructure, and technology to continuously monitor and improve an organization's security
posture while preventing, detecting, analyzing, and responding to cybersecurity and other
security-related incidents.
150
A SOC acts like the hub or central command post, taking in measurements and data from
across an organization's infrastructure, including its networks, devices, solutions, applications,
and information stores, wherever these assets reside. The complexity of advanced threats
places a premium on collecting context from diverse sources. Essentially, the SOC provides
coordination for all logged events monitored within the organization. The SOC decides how to
manage and address security events. A SOC may consist of multiple security operations teams,
each responsible for monitoring and protecting allocated assets, such as intellectual property,
personnel data, business systems, and brand integrity. Additional security operations activities
may include:
• Policy management and distribution systems
• Compliance monitoring and management tools
• Access management workflow systems
• Vulnerability scanning tools
• Security configuration monitoring tools
Example Activities
Example
Further Explanation
Activities
Identify The security operations function should:
approach, • Gain a complete view of the business threat landscape, including not only
roles, the distinct types of endpoints, servers, devices, and software on
responsibilities, premises, but also third-party services and traffic flowing between these
and tasks assets
required for • Enable a complete understanding of all security tools on hand, and all
operating the workflows in use for operations across the organization
security • Develop and implement an organizational approach to security
function and architecture and operations that addresses the organization’s physical,
keep updated. mission, personnel, process security, and cybersecurity needs
Identify, The security operations function is responsible for:
deploy, • Safeguarding designated devices, processes, and applications
monitor, and • Managing defensive tools to help ensure protection
keep updated Resources may include systems and tools such as:
security • Vulnerability assessment solutions
resources. • Governance, Risk, and Compliance (GRC) systems
• Application and database scanners
• Security information and event management (SIEM) systems
• Intrusion prevention systems (IPS)
• User and entity behavior analytics (UEBA)
• Endpoint detection and remediation (EDR)
• Threat intelligence platforms (TIP)
151
Example
Further Explanation
Activities
Conduct • Preparation includes security operations team members staying informed
preparation on the newest security innovations, the latest trends in cybercrime, and
and the development of new threats on the horizon. This research can help
preventative inform the creation of a security roadmap that provides direction for the
maintenance. company’s security and cybersecurity efforts going forward, and a
disaster recovery plan that serves as ready guidance in a worst-case
scenario.
• Preventative maintenance includes all actions taken to make successful
attacks more difficult, including regularly maintaining and updating
existing systems; updating firewall policies; patching vulnerabilities; and
whitelisting, blacklisting, and securing applications
Perform Tools used by the security operations function scan the network 24/7 to flag
continuous any abnormalities or suspicious activities. Monitoring the network around
security the clock allows the team to be notified immediately of emerging threats,
monitoring. giving them the best chance to prevent or mitigate harm. Monitoring tools
can include an SIEM or an EDR, the most advanced of which can use
behavioral analysis to “teach” systems the difference between regular day-
to-day operations and actual threat behavior, minimizing the amount of
triage and analysis that must be performed by personnel.
Conduct alert When monitoring alerts from tools, it is the responsibility of the security
ranking and operations function to look closely at each one, discard any false positives,
management. determine how aggressive any actual threats are, and what they could be
targeting. This allows them to triage emerging threats appropriately,
handling the most urgent issues first.
Respond to As soon as an incident is confirmed, the security operations function acts as
threats. first responder, performing actions like shutting down or isolating endpoints,
terminating harmful processes (or preventing them from executing),
deleting files, etc. The goal is to respond to the extent necessary while
minimizing the impact on business continuity.
Conduct After an incident occurs, the security operations team works to identify the
recovery and problem, restore systems, and recover any lost or compromised data. These
remediation activities may include removing and restarting endpoints, reconfiguring
activities. systems and access, or, in the case of ransomware attacks, testing and
deploying backups to avoid the impact of the ransomware. When
successful, this step returns the network to the state it was in prior to the
incident.
152
Example
Further Explanation
Activities
Manage The security operations function is responsible for collecting, keeping
security updated, and regularly reviewing the log of all network activity and
operations communications for the entire organization. This data helps define a
logs. baseline for “normal” network activity. It can help to reveal the existence of
threats and is used for remediation and forensics in the aftermath of an
incident. Many security operations teams use a SIEM to aggregate and
correlate the data feeds from applications, firewalls, operating systems, and
endpoints - all of which produce their own internal logs.
Conduct In the aftermath of an incident, the security operations team is responsible
security for figuring out exactly what happened including when, how, and why.
incident During this investigation, the security operations team uses log data and
investigation. other information to trace the problem to its source, which helps prevent
similar problems from occurring in the future.
Refine and Cybercriminals are constantly refining their tools and tactics to stay ahead
improve of the industry. The security operations team implements improvements on
security a continuous basis following plans outlined in the security roadmap. This
operations. refinement can also include hands-on practices such as:
• Red-teaming: A red team is a group of offensive security professionals
tasked with using real-life adversarial techniques to help organizations
identify and address vulnerabilities across infrastructure, systems, and
applications, as well as weaknesses in processes and human behavior.
• Blue-teaming: A blue team, typically based in a SOC, is a group of
analysts and engineers responsible for defending organizations from
cyber-attacks through a combination of threat prevention, deception,
detection, and response.
• Purple-teaming: Purple teaming is a security methodology whereby red
and blue teams work closely together to maximize cyber capabilities
through continuous feedback and knowledge transfer. Purple teaming
can help security teams to improve the effectiveness of vulnerability
detection, threat hunting, and network monitoring by accurately
simulating common threat scenarios and facilitating the creation of new
techniques designed to prevent and detect new types of threats.
153
Example
Further Explanation
Activities
Manage Many of the security operations processes are guided by established best
security practices, but some are governed by compliance requirements. The security
compliance operations team is responsible for regularly auditing their systems to ensure
activities, compliance with such regulations, which may be issued by their
plans, and organization, by their industry, or by governing bodies. Examples of these
processes. regulations include:
• Cybersecurity Maturity Model Certification (CMMC)
• National Institute of Standards and Technology (NIST)
• General Data Protection Regulation (GDPR)
• U.S. Health Insurance Portability and Accountability Act (HIPAA)
• Payment Card Industry Data Security Standard (PCI DSS)
• International Standards Organization (ISO) 27000 series
• International Traffic and Arms Regulations (ITAR)
• Information privacy acts
Acting in accordance with these regulations not only helps safeguard the
sensitive data that the company has been entrusted with, it can also shield
the organization from reputational damage and legal challenges resulting
from a breach.
Develop and The security awareness program may include the following activities:
implement a • Security awareness newsletters
security • Web postings
awareness • Mock phishing emails
program and • Security awareness training
keep it current.

Security operations approach and plan(s) The approaches and plans must be
continually monitored and reviewed
for effectiveness, and improved to
keep pace with technology trends,
recorded incidents, and new threats.
Security operations results, logs, and outputs
Security incident analysis results
Security compliance records and results
Organizational security awareness program materials

Continuity (CONT)
Planning (PLAN)
154
ESEC 3.2
Practice Statement
Develop, follow, and implement an organizational security strategy, approach, and architecture
and keep them updated.
Value
Enables an organization to address organizational security needs and issues more rapidly,
consistently, and effectively.

Individual projects or work groups may have different security needs, but some of these needs
may be common to many projects or work groups across an organization. Integrating these
various security elements into a consolidated and aligned organizational approach, including a
business impact analysis, and then clearly and consistently communicating them throughout the
organization is paramount to the effectiveness of the security strategy and approach for the
organization and project or work group.

An organizational security strategy and approach may contain multiple sub-strategies,
approaches, methods, and supporting tools.
Example Activities

Identify organizational The basic initial steps for developing an organization’s security
security architecture architecture include identifying:
needs. • Business, solution, and security objectives, goals, and strategy
attributes
• Risks associated with the attributes that can prevent a solution
from achieving its goals
• Required controls to manage the risk
• Architecture and design support components, such as policies,
user awareness, network, applications, and servers
Record the The organizational security architecture and controls typically
organizational security include:
architecture and • Conceptual architecture:
controls.
o Governance, policy, and domain
o Operational risk and opportunity management
155

o Information
o Certificate management
o Access control
o Incident response
o Application security
o Web services
o Communication security
o Data and information classification needs
• Physical architecture mapped with conceptual architecture:
o Platform security
o Hardware security
o Network security
o Operating system security
o File security
o Database security, practices, and procedures
o Data management and security
o Facility, perimeter, and spatial physical security
o Physical room and asset security
o Inventory of devices and software
• Component architecture mapped with physical architecture:
o Security standards, e.g., CMMC, NIST, and ISO
o Security products and tools, e.g., antivirus (AV), virtual private
network (VPN), firewall, wireless security, and vulnerability
scanner
o Web services security, e.g., HTTP/HTTPS protocol, application
program interface (API), and web application firewall (WAF)
• Operational architecture:
o Implementation guides
o Administrations
o Coding standards
o Patch management
o Configuration and release management
o Monitoring
o Logging
o Penetration testing
o Access management
o Threat and vulnerability identification and management,
including forensics, etc.
Architectural controls include, but are not limited to:
• Procedural controls
o Risk management framework
o User awareness
o Security governance
156

o Security policies and standards
• Operational controls
o Asset management
o Incident management
o Vulnerability management
o Change management
o Access controls
o Event management and monitoring
• Application controls
o Application security platform, e.g., web application firewall
(WAF), SIEM, and APT security
o Data security platform, e.g., encryption, email, database activity
monitoring (DAM), and data loss prevention (DLP)
o Access management, e.g., identity management (IDM) and
single sign-on (SSO)
• Endpoint controls
o Host security, e.g., antivirus (AV), host intrusion prevention
system (HIPS), patch management, and configuration and
vulnerability management
o Mobile security, e.g., BYOD, mobile device management (MDM),
and network access control (NAC)
o Authentication, e.g., access control, authorization, and
accounting (AAA), two factor, and privileged identity
management (PIM)
• Infrastructure controls
o Distributed Denial of Service (DDoS) monitoring and prevention
systems
o Firewall
o Intrusion prevention system (IPS)
o VPN
o Email
o Wireless
o Data Loss Prevention (DLP)
o Facility surveillance
o Facility access
Identify, keep There are many methods and frameworks to address security
updated, follow, and strategies and approaches. Risk-based approaches to security allow
communicate an organizations to adopt strategies that are tailored to their unique
organizational security operating environment, threat landscape, and business objectives.
strategy and The use of a risk-based security approach fits neatly within the
approach. enterprise risk management (ERM) strategies being adopted by
many organizations. Some organizations are subject to strict
regulatory requirements that govern one or more areas of their
157

operations and drive the organization’s security strategy. This often
leaves significant control gaps, as programs designed to satisfy
compliance often neglect areas not specifically addressed in the
regulation. Risk-based approaches allow organizations to carefully
consider the policies, technology solutions, and services that offer a
well-rounded, defense in depth approach to security issues.
It is important to take a holistic perspective and review all angles of
security across governance, people, process, and technology for the
security strategy and approach:
• Governance: This depends on many factors including company
size, industry, geography, ownership structure, etc. The level of
data governance at a company can vary greatly. It is worth
evaluating what is in place and consider adding new structures for
data protection for the long term.
• People: This is an organization’s greatest vulnerability, but also its
strongest line of defense. Review education and training for
security best practices across all levels and departments.
• Processes: This should extend beyond just security-specific
processes to broader business-level processes. Review data
collection, flows, processing, storage, and handling to understand
the scope of securing that data. But also evaluate processes for
solution design and development, new hire onboarding, security
skill assessment and training, and other departmental workflows
to identify areas to add new security actions.
• Technology: This is the backbone of a digital organization, so
ensuring technology is secure is critical. It is important to also
assess how the systems are used by personnel and consider
changes if people tend to bypass standard procedures to avoid
any inconvenient steps required.
Identify and monitor
clear security
measurement
objectives and their
related measures to
verify and validate
that the security
strategy and approach
is working effectively
and efficiently.

Recorded security strategy and approach
158

Security measurement objectives and their
related measures

Planning (PLAN)
Context Specific
DevSecOps
DevSecOps teams, in addition to the technical security architecture, must place particular
emphasis on emerging global cybersecurity and data privacy laws and regulations and
incorporate them into their requirements, solutions, tests, etc. Security should be part of the
criteria considerations for gate-checks in CI/CD pipelines. The organizational security strategy
and approach should either describe or reference all the security needs and policies for solution
architecture that DevSecOps teams should know and follow. For example:
• The U.S. National Institute of Standards and Technology (NIST) Cybersecurity
Framework (CSF) integrates industry standards and best practices to help organizations
manage their cybersecurity risks. It provides a common language that allows personnel at
all levels within an organization, and at all points in a supply chain, to develop a shared
understanding of their cybersecurity risks.
• Cybersecurity Maturity Model Certification (CMMC) is designed to address NIST 800-171
requirements to protect sensitive unclassified information shared by the Department of
Defense (DoD) with its contractors and subcontractors and provide assurance that Federal
Contract Information (FCI) and Controlled Unclassified Information (CUI) is protected at a
level commensurate with the risk from cybersecurity threats, including Advanced
Persistent Threats.
Currently, some of the most prominent data privacy laws and regulations that DevSecOps
teams need to be familiar and comply with are:
• General Data Protection Regulation (GDPR) was developed and passed by the European
Union (EU) in 2018. GDPR identifies requirements for any organization that targets or
collects information related to people in the EU and imposes significant fines for violations.
• Personal Information Protection Law (PIPL) went into effect in 2021 in China,
establishing personal information processing rules, data subject rights, etc.
In the United States, individual states are also starting to develop their own privacy laws that
are modeled after the GDPR. Examples include:
159
• California Consumer Privacy Act (CCPA) requires businesses to provide information about
their privacy practices and gives California consumers privacy rights specific to the
personal information collected.
• Virginia Consumer Data Protection Act (CDPA) applies to organizations that conduct
business in Virginia or produce products or services that are targeted to Virginia residents.
• Colorado Privacy Act (CPA) grants Colorado residents the right to access, correct, and
delete the personal data held by organizations subject to the law. It also gives Colorado
residents the right to opt-out of the processing of their personal data.
ESEC 3.3
Practice Statement
Periodically perform security reviews and evaluations throughout the organization and take
action on results.
Value
Enables an organization to confirm that the security approach and strategy are working
effectively.

Security reviews and evaluations must cover or include security needs, constraints, efforts, and
activities in a continuous manner over time, throughout the lifecycle of a solution, or when
triggered by a security event. The purpose of these reviews and evaluations is to determine
consistency and effectiveness in the security strategy approach. They focus on identifying and
addressing, and when possible, preventing the most critical and urgent security issues first.
Security events, trends, potential threats, and disruptions can also trigger reviews or
evaluations.

Security reviews and evaluations include thorough review of the security approach, process,
strategy, and architecture implementation, events, and disruptions across the organization and
workgroups/project level activities, including any applicable customer specific or regulatory
security requirements, needs, and constraints.
Example Activities

Conduct periodic or as needed Reviews and evaluations that cover all security needs,
security reviews and evaluations. constraints, efforts, and activities in a continuous
manner over time, throughout the lifecycle of a
solution, or when triggered by a security event. They
focus on identifying and addressing the most critical
160

and urgent issues first. Security events, trends,
potential threats, and disruptions can also trigger
reviews or evaluations.
Assess the outcomes and Consider the effectiveness of the reviews as part of the
effectiveness of security reviews, review process. Vary the review approach depending
evaluations, and efforts across the on the context and organizational priorities.
organization.
Use the effectiveness results to
modify the strategy and approach
periodically and as needed.

Security review results
Security evaluation results
Actions addressing security review
and evaluation findings
Updated security strategy and
approach
Security response simulation plans
and results

Measurement and Performance Management (MPM)
Context Specific
DevSecOps
161
DevSecOps teams incorporate security reviews and testing throughout each of their
development lifecycle phases and steps. These activities typically include static code analysis
and routine penetration testing in addition to other automated and manual testing processes.
Evaluations should include use of open source in the code repository with clear, objective, and
unambiguous criteria. Teams should consistently follow-through to bring all identified actions to
closure, and verify the actions achieve expected results regarding all security requirements,
vulnerabilities, and constraints.
162
Enabling Virtual Work (EVW)

EVW Overview
Intent
Defines and manages an approach for effective virtual work and operations.
Value
Maximizes delivery effectiveness and efficiency while reducing the impact and expense from
travel and in-person activities.

Enabling virtual work and operations includes identifying, assessing, managing, and addressing
virtual needs and constraints in a consistent and effective manner, including coordination of
virtual work, teams, projects, and communication channels.
Practice Summary
Level 1
EVW 1.1 Identify and record virtual work needs and constraints.
EVW 1.2 Perform virtual work.
Level 2
EVW 2.1 Develop, keep updated, and use an approach to perform virtual work.
EVW 2.2 Monitor the virtual work approach and take corrective action when
needed.
Level 3
EVW 3.1 Develop, keep updated, and use an organizational strategy, approach,
and functional capability for performing virtual work.
EVW 3.2 Perform reviews periodically on the effectiveness of the organization’s
virtual work approach and take action on results.

Virtual or remote work includes personnel, process, technical, and other considerations, such as
security. A comprehensive virtual work approach includes:
• Identifying the appropriate set of stakeholders and tasks, needs, and constraints
• Identifying security, privacy, competitive, confidentiality, and similar data protection needs
and constraints
163
• Identifying and implementing appropriate communications controls and protocols

• Determining and providing the necessary resources to meet needs and address
constraints
• Enabling personnel, project, systems, and organizational resiliency
• Providing tools, techniques, and measures necessary to enable effective management of
virtual work
• Developing and keeping the virtual approach current with evolving customer and business
needs and constraints
• Continually assessing the organizational approaches to virtual work to identify
improvements and innovations to the current approach
Virtual needs and constraints typically include:
• Criteria for virtual delivery options versus in-person or hybrid delivery
• Delivery effectiveness and efficiency
• Delivery quality and fidelity
• Security, privacy, confidentiality, and nondisclosure
• Workarounds and mitigations for when delivery gets interrupted
• People, process, infrastructure, and tools/systems
• Various communication channels, e.g., standardized collaboration platform(s), protocols,
processes, and systems to support, when applicable, organization-wide communication
and collaboration, such as teleworking or hybrid delivery where face-to-face interaction is
combined with online activities
Context Specific
DevSecOps
It is common for software teams, including DevSecOps teams, to operate remotely and to be
geographically dispersed. This is especially true of global corporations and organizations that
have outsourced their Information Technology (IT) to third parties or that use a follow-the-sun
method to ensure that work is performed during normal work hours anywhere in the world, no
matter the time zone. For these teams, virtual and remote is the standard way work is
performed and usually is supported by an organizationally supported tool suite with automated
workflows.
164
Level 1
EVW 1.1
Practice Statement
Identify and record virtual work needs and constraints.
Value
Minimizes disruptions to virtual work.


Example Activities

Identify virtual work needs and Virtual work needs and constraints and their
constraints. impact on the work or solution can vary
based on the type of work and multiple
internal and external factors.
Record virtual work needs and
constraints and their potential impact
on the work.
Communicate virtual work needs with
customers and affected stakeholders.

List of virtual work needs and Typically prioritized by objectives for the
constraints virtual work and operations, and constraints
or risk criteria such as likelihood, potential
impact, etc.
Communication records with
customers and affected stakeholders
165
EVW 1.2
Practice Statement
Perform virtual work.
Value
Reduces costs and increases collaboration effectiveness.


Example Activities

Perform virtual work. Identify criteria for when and how virtual
approaches are leveraged.
Communicate virtual work results with
affected stakeholders and customers.

Outputs from virtual work
List of criteria for virtual work approaches For example, under what conditions is hybrid
or remote work acceptable.
166
Level 2
EVW 2.1
Practice Statement
Develop, keep updated, and use an approach to perform virtual work.
Value
Increases the ability, flexibility, and consistency for virtual work.

The approach must identify and address needs and constraints for virtual work including:
• People
• Processes
• Platforms and tools, and their features and use
• Infrastructure
• Security, privacy, confidentiality
• Solution delivery

Example Activities

Develop and record an The approach should include and address virtual work and
approach for virtual work and operations for people, processes, tools, and infrastructure,
keep it updated. as well as impacts on costs, schedule, quality, fidelity, and
other aspects of the work. Prioritize these factors based on
risk considerations of impact and likelihood of occurrence.
A detailed approach must be created that addresses how
the virtual work needs and constraints are met, including
roles, responsibilities, unique situations, timing, logistics,
etc. and how and when the approach is communicated with
participants, customers, and affected stakeholders. The
approach includes, but is not limited to:
• A clear understanding of the audience, including their
needs and constraints
• A clear understanding of the objectives for virtual work
and solution delivery and how they are met
167

• Clear description of why, what, when, and how to
address the virtual techniques, needs, and constraints for
the specific delivered solution
• How individual participant needs, and constraints get
addressed, e.g., learning, communication, work,
personality styles, mental and physical capacity and
constraints, such as a hearing or visually impaired
participant, or language barriers
• Detailed risks, constraints, and clear, detailed mitigation
and workaround plans when disruption, interruption or
loss of connectivity occurs, e.g., instructions for
reconnecting through primary and secondary means
(video versus call-in only) and when each is appropriate
• Operational work instructions, procedures, and protocols
for using virtual tools and platforms such as:
o Facilitator or instructor should speak slowly and pause
regularly to confirm understanding from participants
o Setting expectations to not “multitask”, e.g., not
checking email, responding to texts
o Granting access to participants, login information,
verification of participants’ identities
o Set up activities or sessions, spread them out over time,
e.g., conducting multiple 3-hour sessions spread over
more days versus routine 8-hour sessions
o Conducting practice sessions or “dry runs”
o Having a platform coordinator online for the beginning
of large meetings to take attendance, and address
logistical needs
o Displaying attendee list on screen to monitor who
entered the meeting, helping to maintain confidentiality
o Capturing metrics on attendance to monitor
engagement
o Each person using video and noise-cancelling earbuds
or headphones
o When the team is on break, lunch/break/etc., use of a
“minutes remaining” timer that lets attendees know
when the session will resume
o Handling of smaller group breakout sessions, when
appropriate, versus full group
o Use of variety of techniques, e.g., emailing questions in
advance, or platform features like hand-raising, polling,
and chat to ensure and maximize participation and
interactivity
• Preferred or required virtual platform(s), typical platform
requirements include:
168

o Ability to group participants into breakout rooms, or
group chats
o Application/desktop share, including from participants or
facilitator
o Chat feature which allows participants to chat with each
other or the facilitator
o Polls or quizzing feature
o Whiteboard or document collaboration capability
o Webcam for identity verification, confirmation of
maintaining confidentiality etc.
• Configuration and data management needs and
constraints:
o Ensure all participants are on the same platform
versions, installations, and browser versions to interact
o Procedures/controls for managing, protecting, archiving,
and deleting organization data, including proprietary,
classified, privacy and similar information
o Identify and implement controls to manage work
products, e.g., controlling versions of appraisal tools
when merging data across virtual teams
• Verification and validation activities:
o Conduct operational dry runs or tests
o Test approach prior to live virtual delivery, including
providing participants with test information and
instructions
o Provide examples to support instructions, e.g., student
exercises, participant platform execution scripts
• Monitor chat rooms or course breakout sessions:
o Participant identity verification
o Verification that session data remains secure, private,
and confidential, and is not being recorded by
participants
o Participant capability for understanding and using the
virtual methods and tools identified
• Backup and workaround protocols and procedures,
including alternative methods for virtual work when
interruptions occur, and the decision criteria and authority
for when those protocols and procedures are invoked
• Risks, mitigation, and contingency plans for virtual work
including makeup or catch-up activities for participants
who lose connection during critical solution delivery
activities
• Virtual work performance measurement and quality:
169

o Information needs with corresponding measurement
objectives and their analysis and reporting of progress
towards achievement of objectives
o Delivery evaluations, e.g., before, during, after, on how
the virtual methods are working and how activities are
changed during delivery and operation, when needed
o Monitoring techniques
Coordinate with customer and Focus on the prioritized needs and constraints that are
affected stakeholders to critical for each customer or stakeholder group, including
determine and then the needs and constraints for both recipients of virtual work
communicate virtual work and deliverers of the virtual solution. Other aspects include,
needs and constraints. but are not limited to:
• Language
• Need for translation
• Need for identity verification while protecting privacy
information
• Time zone/geographic location of participants
• Duration of virtual sessions
• Cultural
• Physical
• Personnel, staff, e.g., physical and mental endurance and
attention, hearing/visual constraints, use of cameras
• Functional, e.g., breakout rooms, whiteboards
• Logistical, e.g., equipment, headphones, microphones
• Regulatory
• Security, privacy, confidentiality, non-attribution, and
nondisclosure data
• Technical (for platforms/tools), e.g., minimum computing
and operating system requirements for participants and
use cases, functional capabilities needed
• Technical capability of the people performing virtual work
or delivering virtual solutions (recipients and deliverers)
and their administration and access privileges
• Process inputs, activities, and outputs
• Performance, e.g., minimum bandwidth requirements,
interactivity
Identify mitigations, Include statements of relevance of quality, fidelity,
workarounds, and confidentiality, integrity, nondisclosure, and availability for
contingencies for virtual work. the primary approach and functionality, based on
anticipated impact levels for loss.
Identify, evaluate, and rate Evaluate and consistently rate performance, e.g., customer
performance impacts resulting satisfaction, productivity, cost, time to delivery, based on
from use of virtual work leveraging defined scales against impact categories and
technologies. impact levels.
170

Approach for virtual work
and solution delivery
Records of communication
about approach with
customers and affected
stakeholders
List of needs and
constraints and their
mitigation, workarounds,
and contingencies
Virtual work verification,
validation, and
effectiveness evaluation
and results

Planning (PLAN)
EVW 2.2
Practice Statement
Monitor the virtual work approach and take corrective action when needed.
Value
Increases ability to resolve virtual work issues in a consistent manner.


171
Example Activities

Review virtual work according to the virtual Review and keep the approach updated,
work approach. based on the frequency of changes in virtual
work needs.
Review risks associated with virtual work.

Identify corrective actions.
Track corrective actions to closure.

Revisions to the virtual work approach
Report from monitoring of virtual work Include the following types of information:
activities • Progress of virtual work activities
• Risk status
List of corrective actions
Status report of corrective actions

172
Level 3
EVW 3.1
Practice Statement
Develop, keep updated, and use an organizational strategy, approach, and functional capability
for performing virtual work.
Value
Reduces cost of virtual activities and improves operational efficiencies.

The organization establishes and implements a strategy and function for how it manages virtual
work, including interfaces or connections with other groups in the organization. This includes:
• Conducting organizational-level analysis on targeted virtual work results data
• Monitoring, anticipating, and acting on emerging needs, customer needs, constraints, and
innovations for virtual work
• Training projects and personnel on the virtual work approach, processes, tools, etc.

Functions for monitoring virtual operations are most often supported by a centralized function,
but it can also be implemented by tailored approaches for individual divisions, departments, or
projects. This centralized function within an organization includes employing people, processes,
infrastructure, and technology to continuously monitor, improve, and innovate an organization's
virtual work capability.
Example Activities

Identify organizational strategy, roles The objective of this organizational function is to
and responsibilities and tasks required gain a complete view of the business landscape.
for virtual work and operations, and The organization’s virtual work strategy should
keep updated. include:
• People
• Organizational structures
• Operational processes
• Workflows
• Procedures
• Infrastructure and tools
173

The strategy should clarify what activities may be
conducted virtually and the associated mechanisms.
Identify, deploy, monitor, and keep Resources may include:
updated virtual work resources. • Guidelines and checklists
• Preferred or required virtual platform(s)
• Platform requirements
• Technical troubleshooting and problem-solving
guidelines
• Organizational best practices and guidelines for
virtual work
Manage virtual work activities, plans,
tools, infrastructure, and processes.
Pilot, refine, and improve virtual work
operations.
Train and communicate virtual work
methods, tools, processes, etc. with

Organizational virtual work strategy and approach The strategy and approach must be
continuously monitored, reviewed for
effectiveness, and improved to keep
pace with the environmental landscape,
e.g., technology, incidents, threats.
Recorded virtual work performance results Include best practices, lessons learned,
pilot results, and enough information to
be able to re-evaluate results when
needed.
Organizational virtual work process assets and
training materials
Organizational virtual work communications,
training results, and records

Planning (PLAN)
174
EVW 3.2
Practice Statement
Perform reviews periodically on the effectiveness of the organization’s virtual work approach
and take action on results.
Value
Increases efficient use of organizational virtual work approaches.


The organization should take steps to ensure objectivity and accuracy of virtual work reviews
using criteria, checklists, independent peer reviews, etc. Evaluate the results of the reviews for
improvements.
When the potential impact of improvements and changes could detract from future virtual work,
use pilots to verify that the improvements work, consider measures and results before, after,
and during the pilots and organizational deployment.
Example Activities

Conduct periodic and as needed virtual work Reviews should cover all virtual work efforts
reviews across the organization. and activities over time, focusing on the
most critical and urgent issues first.
Additionally, conduct virtual work reviews
when significant disruptions occur.
Evaluate, analyze, and verify the outcomes
and effectiveness of virtual work.
Identify best practices, lessons learned, and
potential improvements, and innovations
needed for virtual work efforts.
Select, deploy, and communicate Use pilots as necessary, to verify expected
improvements and innovations to improve results against clearly defined criteria, and
virtual work activities. assess deployment impacts.

Virtual work review results
175

Causal analysis results of disruptions to virtual
work
List of potential actions needed to address
review findings
List of potential improvements and innovations
Virtual work evaluation and causal analysis
actions selected for improvement and
deployment
Verified results from actions and deployed
improvements

176
Estimating (EST)
EST Overview
Intent
Estimates the size, effort, duration, and cost of the work and resources needed to develop,
acquire, or deliver the solution.
Value
Provides a basis for making commitments, planning, and reducing uncertainty, which allows for
early corrective actions and increases the likelihood of meeting objectives.

If Safety is included in the selected view: Include safety-related requirements, activities, tasks,
risks, and assumptions when formulating estimates, e.g., regulations, physical safety
constraints, required safety training, accommodations for Personal Protective Equipment (PPE)
and physical distancing, safety audits and certifications, and schedule and cost buffers for
safety incident handling.
If Security is included in the selected view: Include security-related requirements, activities,
tasks, risks, and assumptions when formulating estimates, e.g., security clearance paperwork,
background checks, regulations, system access, required security training, and schedule and
cost buffers for security incident handling.
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.
177

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
• 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: Example Tracking Information, how complete is the work?
Table EST-1: Example Tracking Information

Aspect Percent Completed
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 work status may only be 10%
complete because the project front loaded the highly complex activities or components.
Understanding the aspects and their relationships provides a more comprehensive estimate.
The rationale of the estimate should be based on historical data, rather than solely on the
experience and knowledge of the estimator.

Planning (PLAN)
178
Context Specific
Agile Development
Agile development teams estimate the work during backlog grooming and Sprint planning
sessions:
• Estimates for backlog items are typically a rough order of magnitude
• Some agile development teams develop a comprehensive estimate of work during release
planning for a set of stories or epics
• Estimates for Sprints are typically more refined, allowing the team to understand
commitments
Agile estimation typically includes:
• Size: During backlog review, assign backlog items, such as requirements and user stories,
a relative size using story points. The transformation of user stories into story points
considers the size and complexity of the solution. In addition to story points, agile
development teams may use t-shirt size estimation (small, medium, large, or extra-large).
Often requirements are converted into user stories before estimating 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.
• Tasks and Effort: During Sprint estimating and Sprint planning, agile development teams
and the product owner collaborate to select user stories off the backlog based on the
priority of the product owner. The team then estimates these user stories using relative
sizing techniques such as story points or t-shirt sizing. 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.
179
Examples of agile activities with corresponding estimating descriptions are reflected in Table
EST-2: Example Agile Estimating Activities.
Table EST-2: Example Agile Estimating Activities

Agile Activities Description
Release Planning Identifies sequencing and high-level estimates for all planned epics
and stories
Backlog Grooming Refines stories and acceptance criteria to verify and understand the
work to be performed. Sprint velocity is used to estimate time to
complete remaining story points.
Sprint Planning Allocates story points across Sprints
Sprint Review/Demo Reviews actual results for each Sprint and velocity for the just
completed Sprint, and realign sequencing of remaining epics and
stories across future Sprints
Retrospective Identifies consistencies in hitting target Sprint velocity and estimates
any unplanned work and improvement opportunities
People
Context Tag: CMMI-PPL
Context: Use processes to align workforce performance and business objectives.
A defined method to forecast workforce requirements including estimates of different resource

categories, types, and amounts is key to ensuring adequate resources and skills are available
when needed to fulfill relevant business needs.
Examples of historical actuals and related estimates to consider include:
• Internal personnel transitions
• Voluntary and involuntary attrition
• Recruitment and outsourcing targets
• Budget and timing for promotions
• Workforce reduction trends and expectations
180
Level 1
EST 1.1
Practice Statement
Develop high-level estimates to perform the work.
Value
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
181
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 should:
• Define the solution to be developed, delivered, or acquired
• Specify the information needed to estimate the size, effort, cost, and duration
• Identify any resources needed, acquired or consumed during the project
• Identify resource capacity and availability needs and constraints
• Establish the work constraints, e.g., what is included and what is not included such as
acceptance or test criteria

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 or opportunities, 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 Define the solution to be developed, delivered, or
objectives with stakeholders to acquired.
determine scope.
Gather information to estimate the Includes both resource capacity and availability.
size, effort, cost, resources, and
duration.
Identify constraints, boundaries
and limits of scope.
182

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

Context Specific
Suppliers
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
Enables work tracking and timely corrective actions to deliver the solution on time and within
budget.

183

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.
• 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 Methods for determining size include:
the size and complexity of solutions • Analogy
and 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
184

• 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 consider
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
• Updating equipment and supplies
• Logistical support
• Facilities maintenance
• Transition activities
• Monitoring for and addressing obsolescence
• System disposal
Suppliers
Examples of characteristics used to estimate include:

• Number of tasks and effort needed to manage the supplier
• Number and complexity of work products
• Size of work products, e.g., pages, screens, inputs/outputs, tickets, lines of code, number
of story points, or number and size of deliverables
• Number and complexity of requirements in the supplier request package
185
• Number and complexity of clauses in the supplier agreement

• Amount and complexity of the work suppliers will address
• Number of potential suppliers
• Prioritized solution features
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.


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 replanning 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.
186
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,
models or methods to transform based on the most important set of tasks and activities.
size and complexity into effort, Historical data should include:
duration, and cost estimates.
• Size, cost, effort, and schedule (duration) data from
previous completed projects
• Appropriate scaling data to account for differing sizes
and complexity
• Information on factors that influenced the performance
and other contextual information, when available, 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
• 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 Recording the rationale provides the context for using
for the estimates of effort, historical data for estimating future work.
duration, and cost for the
solution.
187

Include estimates of supporting The supporting infrastructure includes resources needed
infrastructure needs. to 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
• Tools, techniques, or methods used:
o Off the shelf tools
o Internally developed tools
o Formulas and calculations
o Models
188
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
• 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 needs to replenish or replace before,
during, or after providing a service)
189
Suppliers
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.
190
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 Table EST-4: Example Estimation Methods.
Table EST-4: Example Estimation Methods

Method Brief Description
Delphi method Estimates are developed by a group of Subject Matter Experts (SMEs)
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 Estimates are based directly on past results for similar projects. The
analogous estimate is then adjusted for differences in size, complexity, or other
estimation factors to reflect current knowledge.
Parametric Parametric estimates are based on historical data and project parameters
estimation and typically use a tool. Note that there are various forms of estimation
tools, including:
• Mathematical
191
Method Brief Description

• Scenario-based
• Simulation
Calibrating the estimation tool as it is used can provide additional
estimation accuracy.
3-point Each estimator (note that there may be only one estimator) provides high,
estimation 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 Estimation methods are most accurate when based on historical data
acceptable estimation and validated before use. The estimation methods should be used
methods. consistently for similar activities, projects, domains, etc. Involve
SMEs in developing and approving the method.
The estimation tools can be built or acquired but should be
calibrated with organizational data.
Calibrate and adjust One approach to calibrate is to refresh the data periodically or
method based on recalibrate data after the most recent use. For example, compare
actual results. 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 SMEs 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.
192


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 Include actual results, contextual information, and
the organization to improve the identified improvements.
193

estimation methods and update
organizational assets.
Analyze organizational data. Analyze data to better understand:
• Variability
• Data quality
• Mean, median, mode

Work estimates Include historical data, context, and approved use from the
organization.
Updated organizational Updated organizational process assets may include:
process assets • 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
Suppliers
Parameters to consider include:

• Acquisition types
• Supplier types
• Supplier on-time performance record
• Supplier performance ratings
• Domain-specific characteristics of the solution
194
Governance (GOV)
GOV Overview
Intent
Provides guidance to senior management on their role in the sponsorship and governance of
performance, processes, and related activities.
Value
Minimizes the cost of process implementation, increases the likelihood of meeting objectives,
and verifies that the implemented processes support and contribute to the success of the
business.

Senior management must actively participate in identifying business and performance needs
and objectives that address all domains and contexts representing the full extent of the
organization, e.g., agile, DevSecOps, data management, security, development, services. They
must provide necessary budget and resources to develop, implement, and follow process, and
to continually improve performance of the projects and organization.
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 performance
improvement based on organization needs and objectives.
GOV 2.2 Senior management provides funding, resources, and training for
developing, supporting, performing, improving, and evaluating adherence
to 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 performance improvement.
GOV 2.4 Senior management assigns authority and holds people accountable for
adhering to organization directives and achieving process implementation
and performance improvement objectives.
195
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.
Level 4
GOV 4.1 Senior management verifies 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
Governance process activities are intended to apply to the set of organizational or project
processes by identifying process roles for senior management to perform. The purpose of these
processes is to improve process sustainment and integration throughout the organization.

Implementation Infrastructure (II)
Context Specific
Data
of the solution.
Senior Management sponsorship and commitment for managing data must be visible, e.g., in
the definition of process needs, organizational objectives and directives, roles and
responsibilities, resources, participation, involvement, leadership.
Data objectives cannot be met solely by technologies and techniques alone. High quality is the
result of continued scrutiny, shared and communicated across the organization by all
stakeholders. An implementable approach for managing data may require a cultural shift,
obtained by strong support from executive management and sustained through promoting,
educating, and mandating attention to the data assets.
196
The most effective approach to managing data is visibly and actively endorsed by executive
management and supported by mandatory organizational policy.
People
Develop competency and work empowerment related objectives that support the overall
business objectives. Align workforce competency descriptions with strategic and organizational
directives to achieve a balanced approach for continuous performance improvement.
Safety

Senior Management sponsorship and commitment for safety must be visible, e.g., in the
definition of process needs and objectives, organizational objectives, resources, extraordinary
attention, participation, involvement, and leadership. When commitment for any process starts
at the top, business objectives and goals flow down through the organization. It is important
that Senior Management listens to and acts upon safety issues and concerns raised throughout
the organization. Review safety management objectives and policies periodically with affected
stakeholders and update as necessary.
Security

Senior Management sponsorship and commitment for the security strategy and approach must
be visible, e.g., in the definition of process needs and objectives, organizational objectives,
resources, level of attention, participation, involvement, and leadership. When commitment for
any process starts at the top, business objectives and goals flow down through the
organization. It is important that Senior Management listens to and acts upon security issues
and concerns raised throughout the organization. Review security management objectives and
policies periodically with affected stakeholders and update as necessary.
197
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.

Organizational culture and values are reflected in policies, practices, and programs that support
success of organizational directives.

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
• Defines the operational parameters for conducting work, including empowerment
mechanisms
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 accomplishing
the work, including improvements; sets the approach; and
communicates to the organization.
198

Identification of importance of and approach to improvement
Records of reviews and communications
199
Level 2
GOV 2.1
Practice Statement
Senior management defines, keeps updated, and communicates organizational directives for
process implementation and performance 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:
• 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 performance
improvement efforts on achieving organizational objectives and addressing needs
• Communicates these directives across the organization to ensure that priorities and
expectations are understood
200
• Ensures operational parameters and empowerment mechanisms are established to

provide support for successful achievement of directives such as Environmental, Social,
and Governance (ESG) and Diversity, Equity, and Inclusion (DEI) initiatives and activities
Directives:
• Record what is important to senior management
• Clearly specify which parts of the organization are affected by and held accountable for
compliance
• 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.
The handling of individual concerns is an important component of operational parameters, so
that concerns do not escalate to large-scale risks and damages to the organization. A concern is
an issue, situation, condition, or grievance that an individual or workgroup wants the
organization to address and resolve. Concerns may include, but are not limited to complaints of
harassment, bullying, discrimination, or abusive behavior.
Senior management verifies individuals, workgroups, and units of the workforce are informed of
related practices, policies, and programs that affect them. For example:
• Hiring policies
• Training and development policies
• Compensation policies
• Career growth policies
• Promotion and transfer procedures
• Retraining practices
• Procedures for raising a concern
• Performance management practices
Example Activities

Senior management defines and Although senior managers are responsible and
communicates organizational accountable for defining policies, other members of the
directives based on guiding organization, such as process improvement team
principles. members, often participate in developing directives.
Senior management communicates policies, practices, and
programs to the workforce on a periodic basis. This
includes clarification about updates and changes to the
policies, practices, and programs.
Senior management confirms awareness of the policies,
practices, and programs are periodically evaluated for
effectiveness, and takes corrective action when
misunderstandings are identified.
201

Senior management defines The procedure typically specifies:
procedures for individuals to • How a concern may be raised
raise concerns through multiple • Requirements for tracking and resolving concerns that
channels, confirms those have been raised
procedures are followed, and • Degree of confidentiality to be maintained
confirms that the raised • How responses should be provided regarding a concern
concerns are addressed. • How to conduct and record a meeting, if needed, to
discuss possible resolutions of a concern
• Follow up activities after problem-solving meetings
• Consequences for attribution or confidentiality breaches
Senior management reviews and Other members of the organization may provide input on
refines process implementation process implementation and performance improvement
and performance improvement objectives. These people may include:
objectives to ensure alignment • Executive managers
with the guiding principles. • Functional managers
• Members of a steering committee
• Subject Matter Experts (SMEs)
To ensure that processes remain aligned with the
organizational strategy, senior management must be
involved in prioritizing improvement objectives, based on
periodic and event driven review.
Senior management Summarize information about organizational and unit
communicates organizational performance at an appropriate level of detail for use by
and unit performance individuals, workgroups, or units. Communicate this
information and results. information using methods that make the information
readily accessible and useful for decision-making or other
business activities. Examples of information to
communicate include:
• Performance objectives aligned to specific units or
divisions of the organization
• Financial results and projections
• Information about costs and expenses
• Production data and results
• Quality objectives and results
• Customer satisfaction and related information
• Marketing, sales, and related information
Make the workforce aware of the extent to which different
forms of performance information must be treated as
confidential.
Senior management Communication should take place through different
communicates performance channels and may include:
improvement directives. • In-person discussions and meetings
• All-hands meeting content and minutes
202

• Videos
• Websites and blogs
• Corporate newsletters and boards
• Annual report
• Marketing material
• Emails
• Orientation package
• Training materials
• Social media
Senior management leverages Governance, management and assurance of performance,
best practice frameworks and risk and compliance integration require common
models as appropriate to define capabilities and methods. This is frequently referred to as
and integrate a performance, a Governance, Risk, and Compliance (GRC) approach.
risk, and compliance approach.
Senior management reviews and This activity may involve input from other members of the
updates performance organization such as functional managers, a steering
improvement directives on a committee, and SMEs.
periodic or event-driven basis. After internal or external changes, the organization may
need to review the relevance of directives.

Organizational improvement
directives
Material containing workforce Must be accessible to all affected stakeholders.
related policies, practices, and For example:
programs
• Orientation material for new hires
• Organizational websites
• Notice boards
• Employee handbooks
Examples of information to communicate to the
workforce:
• Mission, vision, and strategic objectives
• Business ethics
• Values
• Business plans and objectives
• Financial results and conditions
• Business performance
• Quality, productivity, cost, or time-to-market results
• Structure or processes changes
• Leadership team changes
• External business conditions and impacts
• New products, services, and markets
203

• Updates to workforce related policies, practices, and
programs
Recorded, updated, and integrated This may be captured within a GRC program.
performance, risk, and compliance
approach
Assessment reports on the
awareness of workforce related
policies, practices, and programs
Records of corrective actions and
solutions for improving awareness
Records of reported concerns
Records of communication Multiple vehicles may be used to reinforce the
message, as different people are better tuned to
different vehicles. Examples of communication
mechanisms include:
• Orientation material
• Posters
• Town hall meetings
• Intranet or internal web pages
• Organization-wide meetings
• Staff meetings
• One-on-one meetings
• Bulletin boards
• Email announcements
• Internal publications
• Newsletters
• Memos, emails, and blog posts from leadership
GOV 2.2
Practice Statement
Senior management provides funding, resources, and training for developing, supporting,
performing, improving, and evaluating adherence to processes.
Value
Increases the likelihood that senior management’s priorities for improvement will be met.
204

Resources must be of sufficient quality and quantity, based on resource capacity and
availability, to perform these activities. Senior management identifies and provides adequate
funding and resources to individuals who own processes and to those who are identified to
perform a process role in recorded project or organizational processes.

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.
Example Activities

Senior management approves and The scope of the funding and resources aligns to all
provides the funding and resources domains and contexts that represent the full extent of
needed to develop, perform, the organization, e.g., agile, data management,
improve, and monitor the process. security, development, services, suppliers.
205

Senior management reviews,
revises, and communicates
assignment of needed funding,
personnel, and resources to
develop, perform, improve, and
monitor the process.
Senior management provides Training addresses all aspects of learning, including
directives for training. required content and delivery mechanisms, e.g., in-
person, traditional classroom, mentoring, elearning, on-
the-job training.
Senior management reviews and
refines the allocation of budget and
resources.

Recorded allocation of needed
funding, training, 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 performance
improvement.
Value
Aligns the information senior management receives with their business needs to increase the
likelihood of meeting business objectives.

206

Senior management must identify the information necessary to:
• Make timely and informed decisions
• Understand status and when to act on it
• Reinforce the importance of performance improvement
• 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.
207
Example Activities

Senior management identifies This includes approval of how the needed information is
and keeps up to date their obtained, analyzed, and reported in alignment with
information needs related to established criteria for managing data.
process capability, improvement,
and performance objectives.
Senior management verifies Measures:
that measures supporting the • Align to organizational objectives
organization’s objectives are • Support the organization’s ability to manage its
defined. performance results
Senior management reviews Reviews of the process, performance, work products, and
activities, accomplishments, solutions include:
status, and results of the • Reviewing against the plan for implementing and
process implementation and improving process capability and resulting performance
improvement activities. • 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 Use of measurements supports:
the appropriate integration of • Objective planning and estimating
measurement and analysis • Tracking actual progress and performance against plans
activities into all organization and objectives
processes. • Identifying and resolving process-related issues
• Providing a basis for incorporating measurement into
additional processes in the future
208
Example Work
Further Explanation
Products
Senior management The people collecting and reporting the information must
information needs understand its importance and use.
Senior management may not share sensitive or private
information with the organization.
Standard reporting Includes discussion items and expected content identified by
format or agenda for senior management for the review.
review with senior Report templates and tools provide an understandable, easily
management 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
• 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

209
GOV 2.4
Practice Statement
Senior management assigns authority and holds people accountable for adhering to
organization directives and achieving process implementation and performance improvement
objectives.
Value
Ensures that directives drive the implementation and improvement of processes to meet
business objectives.

Senior Management identifies, analyzes, and records authority and the alignment to roles,
responsibilities, and decision-making. This includes identification of individuals who own
processes and individuals who perform process roles in recorded project or organizational
processes.

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
• Process and performance improvement
• Adherence to relevant laws and regulations
• Resolution of noncompliance issues
• Organization performance and improvement trends
• Workforce competency improvements
• Fulfilling commitments that have an organizational impact
Example Activities

Senior management reviews issues This may include:
and trends related to deploying, • Verifying information is accurate and complete
implementing, performing, and • Ensuring that the results of reviews are
improving the organization’s communicated
processes. • Ensuring directives are consistently followed
210

Senior management directs Corrective action includes assigning resources,
corrective actions when: responsibilities, and planned completion dates.
• The organization’s objectives are This may include:
not being met • Taking remedial action to repair defective solutions
• Issues are identified • Changing the plan
• Implementation and • Adjusting resources, e.g., people and tools
improvement progress differs • Negotiating changes to commitments
from the plans • Reviewing the objectives and making changes
• Terminating the effort
Senior management directs the Maintain the roles, responsibilities, and authority
recording and updating of roles, information to keep it consistent and current. Ensure
responsibilities, and authority. changes are recorded and communicated.
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,
and 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, and
poor quality

Action items related to This may include:
accountability • Definition of issue
• Assignment of responsibility
• Due date
• Status
Rewards, recognitions, and This may include:
incentives • Promotions
• Bonuses or salary increases
• Certificates
• Employee of the Month
• Public recognition
211

List of consequences and potential This may include:
impacts • Counseling
• Remediation
• Training
• Reassignment
• Demotion or dismissal
Organizational roles and
responsibilities document

212
Level 3
GOV 3.1
Practice Statement
Senior management ensures that measures supporting objectives throughout the organization
are collected, analyzed, and used.
Value
Increases the organization’s ability to successfully deliver its solutions.


Senior management verifies:
• 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 verifies measures
are collected, analyzed, and used.
Senior management directs corrective May include:
actions related to collecting, analyzing, • Adjusting resources
and using measures. • Modifying the plans
• Updating organizational objectives
Example Work
Further Explanation
Products
Updated organizational
measurement repository
213
Example Work
Further Explanation
Products
Status reports, actions, These may:
and 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, consider updates to the
directives and objectives following items:
• Organizational strategy
• 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
Improves the capability of the organization to meet its objectives.

Senior management provides funding and resources to:
• Define performance objectives
• Define and follow processes needed to meet performance objectives
• Identify and assign personnel with the knowledge and skills necessary to perform the
processes

Example Activities

Review the status of competencies, Focuses on aligning:
objectives, and processes. • Strategies
• Objectives
• Process reviews
214

• Competencies
Record and communicate results.

Results of strategy and process May include:
reviews and discussions • Meeting minutes
• Records of decisions and direction
• Action items
• Updated objectives
Reviews and comparisons between May include analyzing:
the organization’s competencies • Personnel profiles
and processes to be executed • Skills matrices
• Job descriptions

Workforce Empowerment (WE)
215
Level 4
GOV 4.1
Practice Statement
Senior management verifies that selected decisions are driven by statistical and quantitative
analysis related to performance and achievement of quality and process performance
objectives.
Value
Strengthens decision-making by using statistical and quantitative analysis to optimize
organizational performance.

Senior management identifies and provides funding and resources to establish a capability for
analyzing and using quantitative and statistical techniques and data to manage and improve
organizational performance.

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 Strategy includes senior management setting
performance, decisions, and progress. expectations for continuous data-driven
improvement and optimization.
Include related statistical and quantitative analyses
and ensure decisions are based on the analyses.
Record and communicate results. Identify and review results of performance
improvement efforts to promote performance
improvement across the organization.
216

Results of strategy, process Reference the statistical and quantitative analyses
performance, and progress reviews and that drive the decisions and related actions.
decision analyses
Communicated results Results can be communicated through email,
corporate newsletters, town halls, team meetings,
etc.

217
Implementation Infrastructure (II)

II Overview
Intent
Ensures that the processes and assets important to an organization’s performance are
habitually and persistently followed, 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.
Level 4
II 4.1 Develop the organizational capability to understand and apply statistical
and other quantitative techniques to accomplish the work.
218

Establish the necessary infrastructure to ensure that processes are built, followed, sustained,
and improved over time. The term “infrastructure” 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
• 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 verifies that processes are habitual and persistent, 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)
Context Specific
Data
of the solution.
The approach for managing data is supported by processes that define standards and
guidelines for conducting activities necessary to achieve the relevant goals. Resources for
managing data must be provided, and include personnel with defined roles and responsibilities,
tools, and repositories for data and metadata. Processes and policies should cover the data
lifecycle activities including data profiling, data minimization, data cleansing, data quality
assessment, data retirement, and monitoring activities. These activities can be applied to areas
such as data store consolidations, data warehousing, source to target transformation, data
conversion, etc.
DevSecOps
219
Robust infrastructure and processes are foundational to any DevSecOps implementation and
necessary to enable continuous deployment. A properly configured infrastructure provides
DevSecOps teams with speed, automation, efficiency, quality, and enhanced cybersecurity.
Invest early in a properly designed DevSecOps infrastructure, and periodically evaluate the
effectiveness and efficiency of the infrastructure and processes to make implementation more
successful and sustainable. Infrastructure as Code (IaC) is an approach used to manage
infrastructure and shift security and test left on the timeline.
Safety

Consider and implement safety requirements within the infrastructure.

Examples of items to consider for processes, process assets, training, protocols, and resources:
• Eye wash stations
• First aid kits
• Physically disabled accessibility
• Staircase safety parameters
• Hazmat containers
• Defibrillators
• Training for safety equipment
• Evacuation and fire drills
• Active shooter drills
• Safety reports
• Hazard logs
Security

Develop a security strategy and related objectives, consistent with security policies, security
guidelines, procedures, technical security measures, and tools; to protect the infrastructure
where the work products are developed, stored, or delivered. Examples of work products that
require protection include plans, source code, design documents, and solutions. When defining
security objectives, consider confidentiality, integrity, and availability of the work products.
Areas to define include:
• Technical security measures like encryption or network protection
• Physical access control, e.g., locked rooms and physical badge access
220
• Procedures for account management, password handling, access control, handling of

backups, etc.
• Policy for handling proprietary or confidential data
Ensure proper review and audit mechanisms are included within the security procedures to
confirm the security controls are being appropriately and consistently applied.
221
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 develop and deliver solutions
efficiently and effectively 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.
222
Level 2
II 2.1
Practice Statement
Provide sufficient resources, funding, and training for developing and performing processes.
Value
Increases the likelihood of successful process improvement efforts by having sufficient
resources.

Identify and provide adequate resources, funding, and training to individuals who own
processes and to those who are identified to perform a process role in recorded project or
organizational processes. Consider resource capacity and availability when allocating resources.

Sufficient resources for developing processes should consider:
• Leveraging provided 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. Allocate 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.
223
Example Activities

Identify and provide needed resources, Assign people with the needed skills and
as per capacity and availability needs. experience.
Determine budget.
Develop or buy tools.
Create or acquire training materials.
Provide training.

Budget for resources Verify the budget supports resource capacity and
availability.
Training materials
List of needed people, roles, and skills
Tools
Training records

Governance (GOV)
Planning (PLAN)
Context Specific
DevSecOps
224
DevSecOps teams require funding for tools and training to enable process automation from
code commit through deployment. These tools enable the team to perform automated code
builds; unit integration, security, and system testing; and establish a continuous integration and
deployment environment. This environment is foundational to enabling the team to perform
Continuous Delivery (CD) or Continuous Deployment. Continuous Development is often
referenced together with Continuous Integration / Continuous Delivery (CI/CD). CI is the
unification of individual components which occurs on a regular basis. Another basic
infrastructure is Continuous Deployment, the automated transfer of software directly into a
production environment. CD relies on rigorous static testing of source code and dynamic testing
of deployable artifacts. DevSecOps teams receive training to gain an understanding of basic
security practices, automated tools, continuous integration, environment configuration, and
operations; and adopt and integrate these practices into their build and deployment processes.
Infrastructure as Code (IaC) is growing in application where code is written to build
infrastructure such as networks and virtual machines. IaC is the managing and provisioning of
infrastructure through code instead of through manual processes. Configuration files are
developed that contain machine readable infrastructure specifications, making IaC the process
of managing and provisioning computer data centers through machine-readable definition files,
rather than physical hardware configuration or interactive configuration tools. It is easier to edit
and distribute IaC configurations rather than physical hardware configuration or manually using
configuration tools.
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.

Include clear identification of process ownership and process roles within recorded processes.
Monitor and verify how well processes are working and address any shortcomings or
improvements.

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.
225
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
• Peer reviews
Review and update recorded
processes with affected
stakeholders.
Communicate and make recorded This includes changes to existing processes as well as
processes available. new processes.
226

Recorded processes
Process verification results

Governance (GOV)
Peer Reviews (PR)
Context Specific
DevSecOps
DevSecOps teams make extensive use of measures and use tools to develop dashboards that
enable the teams to monitor their performance, verify processes are being followed, and to
evaluate and improve the overall health of their environments and pipelines. Review impacted
processes when new tools are adopted and periodically for consistency. Analyzing verification
results, process adherence, and corresponding measurements enable the organization to target
what process improvements should be made. Retrospectives are an example of where teams
review their processes for their effectiveness.
227
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 reductions in rework and
cost, and increases in efficiency and effectiveness.

Organizational processes and process assets must include clear ownership and identification of
processes and process roles.

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 keep updated 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 Tailoring of assets typically occurs during planning.
process assets.
Manage work using organizational
process assets.
Perform work following
organizational process assets.
228

Tailored process assets May include:
• Templates specific for projects
• Processes and procedures specific for the project
• Lifecycle models specific for the project
• Operational definitions of measures specific for the
project
• Checklists specific to a type of work
Work products resulting from using
the process assets
Context Specific
People
Develop processes consistent with workforce competency descriptions. Workforce competencies

are strong influencers on process performance and should be considered for the most critical
processes.
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.
229
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
• 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.
230

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
o Satisfaction
o Complaints
• Solution reliability
• Defect insertion rate
• Cycle time
• Solution quality
• Root causes

231
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.
Ensure:
• Projects systematically contribute to organizational learning
• Key intellectual capital does not leave the organization when people leave
• Future projects can draw from existing process assets to become productive quickly
Collect process-related experiences such as:
• 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 Include the context along with assets to make them
inclusion in the organization’s more useful.
process asset library.
232

Propose improvements to the
organizational process assets.

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

Context Specific
Safety

Consider the following sources of information for contributing safety process-related information
or process assets to the organization:
• Safety logs
• Safety compliance reports
• Results of applying new safety methods, tools, and controls
• Stakeholder requests and information
• Experiences from performing safety training
• Test results from safety drills
Security

233
Consider the following sources of information for contributing security process-related

information or process assets to the organization:
• Discovered threats
• Reusable security solution risk mitigations
• Security project data, e.g., security lessons learned, security-related effort and cost, and
measurements
• Results of applying new security methods, tools, and controls
• Security architecture and design standards
• Security technology evaluation criteria
• Security design analysis results
• Security configuration standards
• Security solution verification and validation results and reports
• Experiences from performing security training
• Identified vulnerabilities
• Incident resolution approaches
• Results from threat intelligence analysis
• Stakeholder requests and information
234
Level 4
II 4.1
Practice Statement
Develop the organizational capability to understand and apply statistical and other quantitative
techniques to accomplish the work.
Value
Empowers the workforce to use information to make effective changes and meet or exceed

As business objectives and Quality and Process Performance Objectives (QPPOs) evolve, the
organizational capability to process and use information must keep pace to ensure effective
support from the workforce. This in turn requires deliberate strategic updates to the training,
skills and ability needs of the organization in the use of statistical and other quantitative
techniques.
The development of the organizational capability to understand statistical and other quantitative
techniques incorporates the following aspects:
• Training individuals to obtain relevant knowledge and skills for statistical and other
quantitative techniques
• Providing the trained individuals with the opportunity to develop their skills by applying
the techniques
• Ensuring the trained and skilled individuals have the infrastructure to perform the
techniques according to defined processes
Example Activities

Define infrastructure required to Typically include:
support the use of statistical and • Trained resources and funding for establishing an
quantitative techniques. organizational function for conducting statistical
and quantitative management activities
• Statistical tools, e.g., Minitab, QI Macros
235

Develop training materials and job aids
for using statistical and quantitative
techniques.
Monitor effectiveness of the
organizational capability.
Make improvements to the Review and consider improvements to ensure that
organizational capability. updates to statistical and other quantitative
techniques reflect:
• Changes in business objectives
• Changes in QPPOs
• Skill maturity of the workforce
• Latest industry advances and trends

Requirements of organizational
capability for using statistical and
quantitative techniques
Statistical and quantitative training
materials
List of improvements Prioritize improvements based on business
objectives, considerations for competitive
advantage, and workforce skills and knowledge.

236

IRP Overview
Intent
Resolves and prevents disruptions promptly to sustain service delivery levels.
Value
Minimizes 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
237
• Identifying and analyzing the underlying causes, e.g., reviewing problems that led to
incidents
• 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
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.
Organizations can expect to reduce the reoccurrence of specific incidents by identifying and
resolving the cause(s) of the incident(s).
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.
238

Continuity (CONT)
Context Specific
Safety

Safety hazards and events have the potential to negatively impact normal operations or service
delivery. Monitor safety hazards and events like any other interruption when identifying their
resolutions or workarounds, and address safety needs within the resolution.
239
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
240
Level 2
IRP 2.1
Practice Statement
Develop, keep updated, and follow an approach for incident resolution and prevention.
Value
Maintains 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
241

• Detected by automated detection systems
• Derived from the analysis of anomalies in collected data
• 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 Facilitate incident resolution with an established set of
categories for incidents and categories, severity levels, and other criteria for incidents.
to determine what is a valid These predetermined criteria enable prioritization,
incident. 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
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
information incident
• 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
242
Example Work
Further Explanation
Products
• 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
• 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
243

Service Delivery Management (SDM)
Context Specific
Security

Consider the following common six-phase model when developing an approach to address
security incidents:
• Preparation
o How incidents are handled
o Policies
o Warning banners and information within information systems
o Communication plan
o Reporting
o Security incident handling process
o Physical location and equipment
• Identification
o Assigning ownership to an incident
o Verifying the incident
o Establishing chain of custody for evidence
o Determining severity and escalation, as needed
• Containment
o Activating response team
o Notifying stakeholders
o Obtaining agreement on actions impacting availability of services or systems
o Involving the stakeholders
o Obtaining and preserving evidence
o Executing and monitoring action plan
o Managing communications to stakeholders and public, as needed
• Eradication
o Determining signs and causes of incidents
o Identifying location of backups and alternative solutions
o Removing cause(s)
o Improving defenses through implementing protection techniques
o Analyzing vulnerabilities
244
• Recovery
o Restoring operations
o Validating action plan tasks
o Testing the solutions impacted
o Confirming normal operations
• Lessons learned
o Preparing incident report
o Analyzing issues throughout the incident response effort
o Analyzing threat intelligence
o Identifying improvements
o Communicating report to stakeholders
IRP 2.2
Practice Statement
Monitor and resolve each incident to closure.
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
245

Escalate incidents as Track each incident throughout its life. Escalate incidents, as
necessary. needed, 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 Close incidents only when they meet the terms of the
the criteria for closure. agreement.

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

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.

246

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
247
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.
248

Ensure that the incident management system allows for
the escalation and transfer of incidents among groups.
Maintain the integrity of the Examples of maintaining the integrity of the incident
incident management system and management system include:
its contents. • Backing up and restoring incident files
• Archiving incident files
• Recovering from incident errors
• Maintaining security that prevents unauthorized
access
Maintain the incident management Maintenance includes removing obsolete information
system. and consolidating redundant information that
accumulates over time.

An incident management system The storage media, procedures, and tools for incident
with 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
Increases customer satisfaction by preventing incident recurrence.

Analyze incidents and resolve 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.
249
Select and analyze incidents using criteria to develop solutions to prevent recurrence. This
activity involves identifying incidents and determining their causes, then making changes to
prevent them.

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 The group best suited to address the incident can
to address the incident. depend on several different factors, including:
• Type of incident
• Locations involved
250

• 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:
• 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
incident. selected 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.
251

Resolve the incident using the best Manage the actions until the effect of the incident is at
course of action. an 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 For individual incidents, record the actions taken in the
the incident management system. incident management system, including temporary,
reusable solutions.
• Include the time it took to resolve the incidents
• 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 the For temporary reusable solutions, validate a reduction
effectiveness of the incident to the impact on service delivery.
remediation. For solutions that address underlying causes, validate
prevention of recurrence.
Communicate solutions to affected
stakeholders.

Updated incident management May include:
records • 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
252

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

253

MPM Overview
Intent
Manages 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 and optimizing 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
o Continually target and optimize performance
Measurement and performance objectives are quantitative objectives that do not require the
additional rigor of statistical techniques.
254
Quality and Process Performance Objectives (QPPOs) 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.
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 the organization’s 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 and address 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.
255
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.
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 to optimize 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 optimizing
performance.
MPM 5.3 Select and implement improvement proposals based on the statistical and
quantitative analysis of the expected effect of proposed improvements on
meeting and optimizing 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.
A robust measurement program includes and addresses the following types of objectives. Table
MPM-1: Progression and Relationship of Objectives shows the progression and differences of
the types of objectives. In each case, these objectives should be traceable to each other.
Table MPM-1: Progression and Relationship of Objectives

Objective Explanation
Business Objective: Organization realizes that to increase their
Achieve 33% faster delivery per competitive position, they need to deliver releases at
release. a faster rate. Results from objective evaluations
indicate there is a significant amount of time
resulting from ineffective manual testing, which is
contributing to the current release velocity.
Measurement and Performance The amount of time spent developing and executing
Objective: manual test scripts is a key contributor to the length
Increase automated testing to 30% of the testing process. An improvement proposal has
code coverage per release. been identified to convert some of the manual
testing to automated testing.
Quality and Process Performance The organization has implemented a performance
Objective (QPPO): improvement by converting some of the manual
256
Objective Explanation
Achieve average initial pass rate of testing to automatic testing. By applying statistical
86%, +/- 10% for automated testing process control to the automated testing, the
per Sprint. organization has been able to significantly reduce
the length of the testing process. Achieving this
QPPO on a per Sprint basis enables the organization
to maintain this level of performance for releases.
In the above examples, the business objectives and measurement and performance objectives
are indicative of processes that meet the intent and value of practices in Practice Groups 1, 2,
and 3. The QPPO example shows the evolution to achieving Practice Groups 4 and 5.

Estimating (EST)
Context Specific
Agile Development
Table MPM-2: Example Agile Measurement Activities provides examples of where measurement
and performance play a role in an agile project.
Table MPM-2: Example Agile Measurement Activities

Agile Activity
Example Measurements
or Ceremony
Release Planning Assignment of backlog items to future Sprints
Backlog Grooming Epics and story points remaining
Sprint Planning Planned versus actual Sprint velocity
Sprint Review/Demo Sprint velocity (story points completed per Sprint), burn down chart
Retrospective Average Sprint velocity versus actual Sprint velocity
An agile development project can improve performance by:

• Defining objectives that go beyond a single iteration. Objectives might include achieving a
certain velocity over successive Sprints to be able to satisfy the business need.
• Recording clear and usable operational definitions of measures
• Defining how velocity is calculated:
o Identified the canonical value of 1, i.e., team agrees on the operational definition of
what one story point is
257
o Agreed to scale to be used for story points, most commonly using the Fibonacci
sequence
o Identifying and assigning story points to Sprints
o Application of average team Sprint velocity to future Sprints
Typically, agile teams use burndown charts for releases and Sprints to monitor progress and
help assess performance.
Figure MPM-1: Release Burndown Chart & Sprint (Iteration) Burndown Chart
The Release Burndown Chart in Figure MPM-1: Release Burndown Chart & Sprint (Iteration)
Burndown 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:
• The number of story points completed (“Value delivered”)
• Those points forecasted across all planned Sprints
• All of the planned work for a release
The performance objective of this work is related to the value delivered, and used to help
forecast what might be delivered in future Sprints related to the release.
Measurements are used to track 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.
258
The Sprint (Iteration) Burndown Chart in Figure MPM-1: Release Burndown Chart & Sprint
(Iteration) Burndown Chart shows the remaining story points that have been forecasted for the
Sprint, which are updated continuously. The performance objective is to complete the planned
stories within the Sprint using a consistent set of resources. The measurement gives the
remaining points 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. Appropriate actions are taken to remove impediments.
Data
of the solution.
Identify and leverage measurements to assess the achievement of the objectives for managing
data. Consider a comprehensive approach, across all business units, business processes,
projects, and applications, for measuring and reporting on data quality dimensions that are
important to the project or organization. Analyze the measurement data, including consideration
of error rates and quality thresholds, to assess the effectiveness of the approach for managing
data and take appropriate corrective action when measures indicate data is outside of tolerance
levels, or when there is misalignment with business objectives.
Examples of data measures to consider include:
• Value of metadata management, e.g., link to cost containment, operating efficiency,
process effectiveness
• Performance of key processes and procedures, e.g., frequency of use per attribute,
number of data stores per attribute, quantity of applications per attribute
• Criticality of data attributes to applications, e.g., which are core, for what process, used in
which application, included in which calculation processes
• Costs associated with the movement of data across the lifecycle, e.g., how much is at risk,
especially if the lineage is fragmented
• Tracking progress toward a single authoritative source
• Quality of metadata breadth, depth, scope, availability, timeliness, accuracy, duplication,
conformity, linkages, and clarity
• Metadata metrics, e.g., adoption, percent complete
• Satisfaction of Service Level Agreements (SLAs) regarding platform or technical
performance and capabilities
• Number of data management breaches in comparison to the defined approach
• Percent of roles and responsibilities supporting the governance of data management
259
DevSecOps
DevSecOps teams leverage automated tools and processes to perform their work. This enables
the team to identify process objectives and to collect and analyze a variety of measures to
determine progress against them. Measures are selected and used to achieve a balance
between business needs, process adherence, and effectiveness. Measures are also used by the
team to effectively manage their work and contribute to achievement of business objectives. It
is important to consider the full context of the overall process and activities when analyzing
measurement results. DevSecOps teams use a variety of automated tools to capture significant
amounts of data about the software process from development through deployment and
operations. When determining measures, a DevSecOps team typically considers:
• Reliability
• Security
• Stability
• Performance
• Cost
• Process Lead Time
• Ease of Use
• Continuity
• Deployment Queue Rate
• Consistency
Safety

Every solution is likely to have some level of safety requirements included as part of its design
and operation. These requirements typically include safety objectives and related
measurements that are used to verify that the safety requirements have been addressed.
Security

260
Every solution is likely to have some level of security requirements included as part of its design
and operation. These requirements typically include security objectives and related
measurements that are used to verify that the security requirements have been addressed.
Suppliers
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
261
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
262

• 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.
May include:
• Results from measurement and collection
• Discussion and interpretation of results
• Usage of results
Record data from:
• 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 Results may be stored in available tools and reported
communicate 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:
• Customer satisfaction
• Employee satisfaction
• Quality expectations
263
Context Specific
Suppliers
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.
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.
264

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
265
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 includes addressing 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
266
• 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,
performance improvements. e.g., intention, objectives, actions, timeframe.
Record and prioritize business Set priorities within the limits of available resources.
needs and objectives.
Review and keep updated • In the review, include the purpose, value, and
measurement and performance intended 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 Identified business needs and objectives can be refined
objectives against measurement and clarified as a result of setting measurement and
and performance objectives, as performance objectives. Reviewing business needs and
needed, with affected stakeholders. objectives against 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
267

o Quality
• Increase:
o Customer satisfaction
o Employee satisfaction
o Innovation and creativity
• Reduce:
o Customer complaints
o Errors and rework
o Environmental impact
Context Specific
People
Incorporate workforce management needs and constraints within measurement and

Safety

Incorporate safety-related aspects within measurement and performance objectives.

Security

Identifying and categorizing security measurements help to quantify the potential impact and
severity of the security issues, enabling more timely responsiveness for meeting security
objectives. Examples of security measurement categorization may include:
Information Technology
• Number of systems, servers, and users with known or discovered security issues and
vulnerabilities
• Number of expected or potential issues, threats, and vulnerabilities
• Number and frequency of access issues
• Number of Secure Sockets Layer (SSL) Certificates configured incorrectly
• Frequency of access to critical enterprise systems and solutions by third parties
268
• Number of days to deactivate former employee credentials

• Volume of data or transactions requiring encrypted transmission
• Volume or number of documents, records, or drawings requiring Classified, Secret, or Top
Secret protection
• Frequency or periodicity of data and information back-ups
• Remote workforce security constraints, e.g., providing a secure network or Virtual Private
Network (VPN)
Solution Development
• Number of solution components, subsystems, and systems with known or discovered
issues and vulnerabilities
• Type of threats and vulnerabilities discovered with the solutions or solution components
• Number of security issues related to the security architecture
• Number of externally-made parts, components, or materials in the solution
• Number of external suppliers or vendors providing to the solution
• Number of third-party developers, integrators, or testers of the solution
• Number of operations, process steps, or items of equipment requiring signal suppression
or shielding
Service Delivery
• Number and frequency of internal versus external service delivery security issues, threats,
and vulnerabilities
• Number of service system processes, subsystems, and components with known issues and
vulnerabilities
• Number and type of threats and vulnerabilities identified and discovered with the service
delivery
Organizational
• Number of security evaluations planned versus conducted
• Number of security weaknesses discovered per security evaluation
• Number of threats and vulnerabilities related to security policy violations
• Effort and cost for security actions and steps, e.g., per issue, objective, or evaluation
• Number of employees who cannot receive a security clearance due to issues discovered in
background checks
Supplier Management
• Number of security issues, threats, and vulnerabilities identified with the supplier’s
solutions or solution components
• Number of supplier work product security evaluations completed (planned versus actual)
• Number of supplier security process evaluations completed (planned versus actual)
• Service levels or timeframes for suppliers to address known security issues and for the
recipient to verify resolution
269
Suppliers
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.
Value
Increases the consistency of measures and the likelihood that business needs and objectives
are met efficiently and effectively.

270

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.
Refer to Table MPM-3: Base and Derived Measurement Examples.
271
Table MPM-3: 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-4: Example
Measurement Relationships.
Table MPM-4: Example Measurement Relationships

Example Information Example Example
Information
Business Purpose Type or Base Derived
Need
Objective Category Measures Measures
Shorten time What is the Provide insight Schedule and Estimated and Schedule
to delivery. estimated into schedule progress actual start and Performance
Be first to delivery time? fluctuations end dates by Schedule
market the and progress. task estimation
solution. accuracy
Increase How accurate Provide insight Size and Estimated and Productivity
market share are the size into actual effort actual effort
by reducing and cost size and costs and size
costs of estimates? compared to
Effort and Estimated and Cost
solutions. plan.
cost actual cost performance
Cost variance
272

Information
Need
Deliver Has scope or Provide insight Size and Requirements Requirements
specified work size into actual stability count volatility
functionality. grown? size compared Size
to plan, estimation
identify accuracy
unplanned
growth.
Reduce Where are Evaluate the Quality Number of Defect
defects in defects being effectiveness defects inserted containment
solutions inserted and of defect and detected Defect
delivered to detected prior detection Solution size
the customer to delivery? throughout density
by 10% the solution
without lifecycle.
affecting cost. Rework costs
What is the Determine the Cost Number of
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,
273

Information
Need
incentives for
innovation
Example Activities

Identify existing measures Specifications for measures, sources, and collection mechanisms
that address measurement may already exist.
objectives and are
available or collected from
current work products,
processes, or transactions.
Select measures that Select measures for the selected product and process
provide insight into the attributes.
organization’s quality and Examples of systematic approaches to select measures include:
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 replanning
Specify how to collect and Develop data collection mechanisms and process guidance.
store data for each Data collection mechanisms can include:
required measure. • Manual or automated methods
• Forms, templates, and tools
• Mechanisms for ensuring data quality
Select data analysis Issues to be considered typically include:
methods 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
274

• 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.

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
275
Context Specific
DevSecOps
The business objectives should drive the measurement selection and use. Business,
organization, and project leaders must decide which measures are operationally meaningful to
the organization, as well as how to implement and use them. Standard operationally defined
measures used by DevSecOps teams typically include:
• Application Change Time: Time between code commit and production deployment. This
measure includes time to build, test, and release an update. When application change
times are shorter, this implies improved development efficiencies.
• Application Deployment Frequency: Number of deployments to production in each
iteration. Lower deployment frequency might be acceptable for a mature product, while
high deployment frequency is common for new or less mature products.
• Availability: Application uptime or downtime in a period. This is an important metric
usually linked to the Service Level Agreement (SLA).
• Change Failure Rate: Number or percentage of failed production deployments that result
in an aborted deployment or rollback. A high change failure rate could indicate a problem
with team skills, deployment process, or understanding and management of the
deployment infrastructure.
• Change Volume: Number of new features or functions deployed in a period. A high
change volume with a low failure rate suggests a high tempo of successful development.
A high change volume with a high failure rate might indicate issues with the DevSecOps.
• Issue Resolution Time: Average time needed to resolve a reported issue. This measures
the time it takes to identify and fix a reported defect or issue.
• Issue Volume: Number of issues reported in a given period, e.g., help desk ticket creation
rate. A high issue volume might indicate customer dissatisfaction or production issues.
• Mean Time To Recovery (MTTR): Time between a failed deployment and full restoration of
production operations. Short MTTR indicates a capable DevSecOps process; longer MTTR
suggests problems.
• Time to Patch: Time between identifying a vulnerability in the application and successful
production patch deployment. This is an indication of the ability of DevSecOps teams to
find and fix defects.
• Time to Value: Time between a feature or function request and the realization of business
value. Most businesses want to minimize time to value.
276
People
Identify and define measures in support of workforce management measurement and

performance objectives. Consider the following types of measures:
• Cost per hire
• Number of initial candidates that transition beyond the probation period
• Demographics of candidates and hires, including factors such as source, age, diversity,
equity, and inclusion
• Success rate and time spent on recruiting, selection, onboarding, and transitioning
• Time from opening a position to filling it
• Percent of unit members involved in personnel activities
• Rate of transitioning individuals into new positions
• Number of people undergoing outplacement
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)
• 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)
277
• 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-5: Example Service Measurement Relationships depicts some common examples of
measurement relationships in the context of services.
Table MPM-5: Example Service Measurement Relationships

Example Information Example
Information Example Base
Business Purpose Type or Derived
Need Measures
Objective Category Measures
Provide Can the Provide Service • Number of • Service
agreed service insight into continuity services with continuity
service provider whether recovery test confidence
continuity. recover the service failures rate
services from provider • Total number
disasters or will of services in
major implement the service
disruptions service catalog
within agreed continuity
timeframes? plans
successfully
to provide
agreed
service
continuity.
Provide Are there Provide Capacity • Total number • Average
appropriate enough insight into of service service
capacity to resources (or resource requests time
meet too many) to utilization, • Available • Service
business meet idle service provider
needs. demand for resources, provider resource
services? and personnel utilization
inadequate hours
capacity to • Service time
278
Example Information Example

Information Example Base
Business Purpose Type or Derived
Need Measures
Objective Category Measures
meet
demand.
Provide How effective Provide Service • Number of • Service
effective is the insight into performance service rework rate
services. service? percentage requests
of reworked
reworked • Total number
service of service
requests. requests
Provide Is the service Provide Availability • Agreed • Availability
appropriate, provider insight into service time
agreed providing the • Downtime
service appropriate, availability
availability. agreed of the
service service.
availability?
Is the service Provide Availability • Available • Reliability
reliable as insight into time (in as mean
agreed? the hours) time
reliability of • Total between
the service. downtime (in failures
hours) (MTBF)
• Number of
breaks in
service
(interruptions
to normal
service)
Suppliers
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.
279
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
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.
280

Base and derived measurement
data
Results of data integrity checks
Context Specific
Suppliers
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
Provides insight into performance and actions needed to meet objectives.

281

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.
These activities provide the foundation 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 Typically, the analyses are specified in the operational
as 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
282

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
techniques in the operational lead to improved future efforts based on lessons
definitions. learned. These lessons learned can lead to:
• Improved measurement specifications
• Improved data collection procedures
• Ideas for refining information needs and objectives

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

Context Specific
Suppliers
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
283
• 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.
Value
Enables analysis of performance to improve the likelihood of 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.
284
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 Control access to data and educate people on the
being 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.

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
Suppliers
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
285
• 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.
MPM 2.6
Practice Statement
Take actions to address identified issues with meeting measurement and performance
objectives.
Value
Enables the ability to meet performance 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
• Replanning
• Initiating improvement activities
• Renegotiating objectives
286
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
• What is improved by each proposed improvement

287
Level 3
MPM 3.1
Practice Statement
Develop, keep updated, and use the organization’s measurement and performance objectives
traceable to business objectives.
Value
Optimizes resource usage to improve 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 the organization’s measurement and performance objectives to
the project level.

In order to define the organization’s measurement and performance objectives, affected
stakeholders should understand the:
• Organization’s business model
• Business context
• Business objectives
• 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 the organization’s 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.
288
Example Activities

Develop, review, and analyze the business Analysis may include:
objectives that drive measurement and • Business objectives
performance objectives. • Current performance data and baselines
• Current distribution of objectives to sub-units
• Business and organizational models
• Critical success factors
• Customer data
• Competitor data
Develop, record, and use the
organization’s measurement and
performance objectives and keep them
updated.
Analyze the performance of projects within Analyze this information periodically or on an
the organization. event-driven 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 the organization’s measurement
and performance objectives to projects.
Trace new and revised measurement and
performance objectives to business
objectives.
Review and update the allocations of
and communicate with affected
stakeholders.

Business objectives
Measurement objectives Measurement objectives may address more than just
performance, such as:
• Measurement calibration data, e.g., accuracy, precision
• Measurements for regulatory purposes or customer demands
• Deployment, progress, and implementation status
Performance objectives
289

Allocated measurement Include:
and performance • Allocation of organization objectives to projects
objectives • Rationale and context for the allocation
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 of Periodically evaluate measures for their
measures as needed. continued usefulness.
290

Operational definitions following
organizational standards
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 provides a foundation to verify:
• 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.
291

Objectively evaluate the Determine and plan the frequency of evaluations.
measurement 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.

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
Supports informed decisions leading to more successful projects through timely access to
measurement and performance data.


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
292
• 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.
Example Activities

Determine the organization’s needs This results in understanding and recording the
for storing, retrieving, and requirements for the measurement repository.
analyzing 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 For example, revise when:
as 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
293

• Collection
• Support environment
• Retrieval mechanisms
• Security
• Retention
• Maintenance
• Data validation
• Standard reporting
Organization’s measurement
repository
Organization’s measurement data
MPM 3.5
Practice Statement
Analyze organizational performance using measurement and performance data to determine
and address performance improvement needs.
Value
Contributes to business success through the analysis and improvement of performance.

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.
294
Example Activities

Aggregate performance data
to the organizational level.
Analyze measurement and May include:
performance objectives • Which processes are involved in and contribute to a
against current performance selected performance improvement
to evaluate the organization’s • An estimate of the contribution of the respective processes
ability to satisfy business • Resources consumed during operations, delivery, and use
objectives. • Traced contribution of performance improvements to
related objectives
• Any barriers that may hinder meeting objectives or
successful deployment of improvements
Review and obtain agreement with affected stakeholders for
service level targets.
Develop, use, and keep Examples include:
updated descriptions of the • Identify flow charts for the service system and its
resources consumed, as well processes
as planned and current • Record of the system’s current capacity and availability,
service system performance. which can require determining the capacity and availability
of service system components
• Consider service system graphical representations from
collected measurements and analyses
o Estimate the capacity and availability of the service
system at peak work volumes
o Develop capacity and availability models and keep them
updated. Common models depict demand data, capacity
and availability data, availability data, performance data,
representations of resource use, representations of
resource needs, data on the use of resources
o Define 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 define exception conditions in the service system and
breaches or near breaches of requirements
o Identify thresholds that define exception conditions and
breaches
Identify shortfalls and Performance shortfalls may include not meeting objectives
potential improvement areas for:
where actual performance is • Productivity
not meeting business • Cycle time
objectives. • Customer satisfaction
295

Examples of areas to consider for improvement include:
• Product technology
• Process technology
• Personnel development
• Team and organizational structures
• Infrastructure
• Supplier selection and management
• Personnel development, including individual, workgroup,
and organizational competency improvements
Develop, use, and keep
updated service system
representations from
collected measurements and
analyses.
Record performance Use this information and evaluation results when developing
improvement needs. or updating proposed improvements for performance.
Analyze and record May include:
anticipated cost and benefits • Resources including schedule, effort, people, processes,
associated with addressing tools, etc.
performance improvement • Barriers that may hinder successful deployment
needs. • Detailed organizational changes needed to implement each
improvement
• Verification and validation activities
Communicate results to
Submit performance
improvement suggestions.

Aggregated performance results Elicit performance and improvement results from the
project level.
Results may include:
• Organization’s measurement and 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
296

o Effect on meeting measurement and performance
objectives
Performance analysis results May 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

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
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.
297
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.

Communicate 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.
Communicate performance
improvement results to affected
stakeholders.
Example Work
Further Explanation
Product
Performance May include:
improvement and • Contextual information or guidance to help interpret analysis results
analysis reports • 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
298
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
Establishes realistic quality and process performance objectives enabling better decision-
making, increasing the likelihood of meeting business objectives.


Use statistical techniques to determine Quality and Process Performance Objectives (QPPOs) for
the work. QPPOs 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 QPPOs to business objectives.
Negotiate the QPPOs 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
QPPOs may address:
• Planned objectives to be achieved resulting from improvements
• Current objectives to be sustained
Example Activities

Define, record, keep updated, and This involves:
communicate Quality and Process • Incorporating appropriate business and
Performance Objectives QPPOs. organizational objectives
299

• 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:
• Specific
• Measurable
• Achievable
• Relevant
• Time-bound
Ensure traceability between the performance and
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
progress toward achieving the selected phases, milestones, work products, and
stated objectives. processes.
Determine and record the risk of
not achieving QPPOs.
Resolve conflicts among the To resolve conflicts:
QPPOs, e.g., if one objective • Set relative priorities for objectives
cannot be achieved without • Consider alternative objectives in light of long-term
compromising another. business strategies as well as short-term needs
• 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 QPPOs.
Revise objectives, as necessary, to reflect results of
conflict resolution.

QPPOs Examples of project QPPOs include:
300

• 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
Examples of measurable process performance
characteristics include:
• Cycle time
• Percentage of rework time
• Defect escape rates
Risks of not achieving the QPPOs

Context Specific
Data
of the solution.
Examples of Quality and Process Performance Objectives (QPPOs) in consideration of managing

data include:
• Data completeness, e.g., 98% of expected data values are captured
• Data accuracy, e.g., less than 5% data defect rate found during data verification
• Data coverage, e.g., 100% coverage across all mission critical datasets
• Data processing time, e.g., 90% of data requests processed within 24 hours
Development
Examples of Quality and Process Performance Objectives (QPPOs) using derived targets include:
• Maintain a code review rate between 75 to 100 lines of code per hour
301
• 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
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.
Select measures to manage Selection should not be limited to solution, progress, or
processes using statistical performance measures only. Measures can be used to develop
and other quantitative analysis, process, and success indicators which provide better
techniques. insight into process performance.
302

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 QPPOs using derived targets include:
identified measures to the • Keep requirements gathering sessions to under three hours
Quality and Process • Maintain rework levels below a specified percent
Performance Objectives • Maintain productivity in generating a number of work
(QPPOs) to derive targets. products per day
Develop the environment to This implementation is based on the:
support collection, • Description of the organization’s set of standard processes
derivation, and analysis of • Description of the defined process in use
• Capabilities of the support environment
303

new measures and keep it
updated.
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 QPPOs, and
higher-level business objectives.
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.
304

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 can meet the Quality and Process Performance
Objectives (QPPOs) 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
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
305
• Understanding the impact of variation on stability and capability on the performance of

the process and achievement of the QPPOs
• Understanding how capable a process is in meeting its QPPOs
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
Example Activities

Analyze the collected measures to Include the stability and capability (when specification
establish central tendency and limits are defined).
distribution or range of results that This analysis can help decide the best selection or
characterize the expected subset of process performance baselines to maintain.
performance of selected processes.
Ensure that the baselines are linked to QPPOs and
Record, keep updated, and use Examples may include:
process performance baselines. • Statistical process control charts
• Box and whisker diagrams
306

• Confidence intervals
Review process performance Stakeholders can help determine if the baselines are
baselines with affected appropriate.
stakeholders.
Make the process performance Workgroups use the organization’s process
baselines available in the performance baselines to estimate the natural bounds
organization’s measurement for their process performance.
repository and communicate to the Some project process performance baselines may not
organization. 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 QPPOs
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.
307

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 replanning, and problem resolution to make process tailoring choices that
maximize likelihood of meeting Quality and Process Performance Objectives (QPPOs).
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 keep updated 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 QPPOs.
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
• 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 QPPOs
Examples of performance models include:
• Regression
• Complexity
• Discrete event simulation
• Monte Carlo simulation
308
Example Activities

Establish process performance Examples of analyses used to develop performance
models. 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 Stakeholders can help determine if the models are
models with affected stakeholders. appropriate.
Make the process performance Some project process performance models may not be
models available in the included in the organization’s measurement repository.
organization’s measurement
repository and communicate to the
organization.
Support the project’s use of
process performance models.
Revise process performance models For example, when:
as 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
• 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.
309

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 (QPPOs) 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 QPPOs 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
• Sophistication
• Analytic foundation
• Parameters
• Predictability
• Use among the various processes
310
Examples of quantitative models include:

• Models to predict the likelihood of achieving QPPOs 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
processes and address and 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 Examples of actions to address deficiencies in achieving
to address deficiencies in objectives may include:
achieving QPPOs. • Improving the implementation of the existing process to
reduce its variation or improve its performance, e.g.,
addressing common causes of variation or changing the
process
• Adopting new processes and technologies
• Identifying risks and risk mitigation strategies for
deficiencies
311

• Renegotiating QPPOs 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
performance models latent defects in work products in future phases or in the
calibrated with data to delivered solution.
assess progress toward
achieving QPPOs.
Identify and manage risks
associated with achieving
QPPOs.
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 QPPOs
Recorded risks of not achieving the
QPPOs
List of actions needed to address
deficiencies in the process stability
or capability of each selected
process
312

313
Level 5
MPM 5.1
Practice Statement
Use statistical and other quantitative techniques to ensure that business objectives are aligned
with business strategy to optimize 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 (QPPOs), 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, keep updated, and communicate resulting QPPOs. 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
objectives periodically and on an organizational performance may change over time or
event driven basis to ensure that become obsolete based on the needs of the
they align with business strategies. organization or the 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
baselines and process performance motivate real improvement. Using process performance
predictions to ensure the objectives baselines and models helps balance expectations and
are realistic. reality. If process performance baselines and models
are not available, use sampling techniques to quickly
develop a quantitative basis for comparison.
314

Prioritize business objectives based Example criteria include the ability to:
on recorded criteria. • Win new business
• Retain existing clients
• Respond to changing or disruptive markets
• Innovate
• Accomplish other key business strategies
Maintain QPPOs to address changes Business and QPPOs typically evolve over time. Ensure
in business objectives. existing objectives are met while identifying and
managing new business objectives and associated
QPPOs.
Revise measures to align with
QPPOs.
Communicate changes to business
strategies, business objectives, and
QPPOs to stakeholders.

Results of analysis of current This is typically an iterative process that may be done
performance against: from a bottom-up (QPPOs up to business strategies) or
• QPPOs top-down approach, depending on the need and
• Business objectives purpose.
• Business strategies
Revised business objectives and
strategies
Revised QPPOs
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
optimizing performance.
315
Value
Identifies areas that pose the greatest risk to achieving business objectives or greatest
opportunity for increasing business performance.


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 (QPPOs) 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,
basis, compare QPPOs to current collect various measurements that support or influence
process performance baselines and characterizing cycle time. Compare overall cycle time
models to evaluate and predict the performance data to business objectives to understand
organization’s ability to satisfy if the expected performance will satisfy business
business objectives. objectives.
Identify shortfalls where
performance is not satisfying
Identify potential improvement Examples of areas to consider for improvement include:
areas based on the analysis of • Product technology
performance 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
316

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

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 and optimizing business, quality,
and process performance objectives.
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, the organization can prepare for their deployment and maximize the benefits.
Example Activities

Use process performance models to
predict process performance based
on proposed improvements.
317

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.
Identify and use statistical and other quantitative data
and techniques.
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 (QPPOs)
• 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 Examples of barriers include:
to deploying each proposed • Turf guarding and parochial barriers
improvement. • 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
318

• 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 may 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 Determining the validation method includes defining
validation method that will be used the statistical or quantitative success criteria that will
before broad-scale deployment of be used to evaluate results of the validation.
the change. 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 Follow the validation methods recorded above
before broad-scale deployment
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
319

• Relationship to and impact on business and QPPOs
• Identification of proposed improvements
List of potential barriers and risks
to implement the improvement
Recorded validation methods
List of submitted proposals for
implementation

320
Managing Security Threats & Vulnerabilities (MST)

MST Overview
Intent
Identifies the security threats and vulnerabilities that could compromise the organization or
solution, analyzes the potential impacts, and defines and takes actions to address and mitigate
them.
Value
Increases an organization’s capability and resilience to identify, mitigate, and recover from
threats and vulnerabilities.

Managing security threats and vulnerabilities is an ongoing, 24/7, 365 days a year activity. It
can never stop and cannot be an after-thought or a tradeoff item like schedule, cost, and
quality. However, not every threat or vulnerability has the same impact. An organization, or
project doing this needs a holistic and systematic approach, based on recorded criteria, to
continually sort through, evaluate, and select which threats and vulnerabilities are the most
critical to address, given the potential risk and impact to the business, mission, or solution.
Practice Summary
Level 1
MST 1.1 Identify and record security threats and vulnerabilities.
MST 1.2 Take actions to address security threats and vulnerabilities.
Level 2
MST 2.1 Develop, keep updated, and follow an approach for handling security
threats and vulnerabilities.
MST 2.2 Develop and keep updated criteria to evaluate security threats and
vulnerabilities.
MST 2.3 Use recorded criteria to prioritize, monitor, and address the most critical
security threats and vulnerabilities that arise during operations.
MST 2.4 Evaluate and report the effectiveness of the approach and actions taken
to address critical security threats and vulnerabilities to the solution.
321
Level 3
MST 3.1 Develop, keep updated, and follow an organizational security strategy,
approach, and architecture to evaluate, manage, and verify threats and
vulnerabilities.
MST 3.2 Analyze security verification and validation results to ensure accuracy,
comparability, consistency, and validity across the organization.
MST 3.3 Evaluate effectiveness of the organizational security strategy, approach,
and architecture for addressing security threats and vulnerabilities.
Level 4
MST 4.1 Employ threat intelligence analysis to develop and improve the solution
security approach and architecture, and to select security solutions to
address threats and vulnerabilities, using statistical and other quantitative
techniques.

Develop a continuous threat and vulnerability strategy, approach, and architecture to identify,
monitor, analyze, and take actions systematically to effectively anticipate and mitigate threats
and vulnerabilities of a solution or solution component during development, deployment or
delivery, operation, or decommission.
Program or project management and risk and opportunity management plans typically include
security strategies, objectives, approaches, and architectures. The information in these plans
often includes identifying sources of risks and security vulnerabilities, and their potential impact
on the organization or solution. Analyze risks by considering relevant threats and vulnerabilities
and take adequate security actions; these may also be defined or treated as risk handling
actions.
The goal is to address operational solution objectives, e.g., minimizing risks to the
confidentiality, integrity, or availability of data or solution components when operating the
solution in a defined environment.
Periodically perform security risk assessments to identify mitigations that may add to solution
requirements and to security activities defined in the work’s processes. There are many
dimensions to risk, including consideration of inherent and residual security risks. The major
elements of security risk and opportunity management are developing the security risk and
opportunity management plan for the solution, conducting solution security risk evaluations,
and taking actions on resulting mitigation plans.
Vulnerability handling goes beyond the scope of a solution development or execution process
and is conducted throughout the lifecycle of the project and solution.
Efforts to identify and remove security weaknesses and vulnerabilities early can prevent:
• Exploitation of security weaknesses and vulnerabilities by attackers, giving rise to
incidents
• External detection and reporting of security vulnerabilities
• Excessive effort, e.g., cost, resources, schedule, for handling incidents and vulnerabilities,
possibly affecting customer trust
322
External References

Data Security Council of India (DSCI): An industry body on data https://www.dsci.in
protection in India, set up by NASSCOM®, committed to making
cyberspace safe, secure, and trusted by establishing best
practices, standards, and initiatives in cybersecurity and privacy.
It engages with governments and their agencies, regulators,
industry sectors, industry associations, and think tanks.
IEC 31010:2009 Risk management: Risk assessment techniques https://www.iso.org/stand
ard/51073.html
ISO 27001:2013 Information technology: Security techniques, https://www.iso.org/stand
Information security management systems, Requirements ard/54534.html
ISO/IEC 27005:2018 Information technology: Security https://www.iso.org/stand
techniques, Information security risk management ard/75281.html
ISO 31000:2018 Risk management: Guidelines https://www.iso.org/stand
ard/65694.html
MAGERIT (English version): Methodology of Analysis and Risk https://administracionelect
Management Information Systems ronica.gob.es/pae_Home/p
ae_Documentacion/pae_M
etodolog/pae_Magerit.html
?idio=&idioma=en
National Critical Information Infrastructure Protection Centre: https://nciipc.gov.in
Part of the government of India, whose mission is to facilitate
protection of Critical Information Infrastructure from
unauthorized access, modification, use, disclosure, disruption,
incapacitation, or distraction—through coherent coordination,
synergy, and raising information security awareness.
NIST Computer Security Resource Center glossary: "system https://csrc.nist.gov/glossa
security plan" ry/term/system_security_pl
an#:~:text=Definition(s)%
3A,planned%20for%20me
eting%20those%20require
ments
NIST Special Publication 800-30 Rev. 1 Guide for Conducting https://csrc.nist.gov/public
Risk Assessments ations/detail/sp/800-
30/rev-1/final
NIST Special Publication 800-39 Managing Information Security https://csrc.nist.gov/public
Risk: Organization, Mission, and Information System View ations/detail/sp/800-
39/final
NIST Special Publication 800-171A: Assessing Security https://csrc.nist.gov/public
Requirements for Controlled Unclassified Information ations/detail/sp/800-
171a/final
323

Continuity (CONT)
Incident and Resolution Prevention (IRP)
Context Specific
Services
Managing threats and vulnerabilities in a service context includes:

• Identifying potential threat and vulnerabilities in the organization’s service operations,
including any service systems or service system components
• Protecting the organization’s, customers’, and users’ data and information
• Ensuring that threat and vulnerabilities are not introduced in a service system or service
system component that could potentially impact the broader solution or service
Suppliers
As with other phases within a solution lifecycle, ensure acquisition and supplier management
activities also address security risk assessments. During any phase of acquiring solutions,
security concerns including threats and vulnerabilities must be considered and addressed. This
includes performing risk assessments to identify mitigations, which may impact already elicited
solution requirements or security activities defined in the processes. Ensure that the security
risk and opportunity management plan for the supplier’s solution or solution components, the
security risk assessment, and mitigation plans address vulnerability and threat impacts when
performing supplier management activities.
324
Level 1
MST 1.1
Practice Statement
Identify and record security threats and vulnerabilities.
Value
Minimizes the potential negative impact on the project or solution.

Develop awareness of security threats and vulnerabilities and identify those that could
compromise the security objectives of the solution, mission, or project.

Identify potential security issues, hazards, threats, and vulnerabilities that could negatively
affect the solution, project, or mission in the intended operational environment.
Security threats to a solution, project, or mission vary depending on the operational
environment, e.g., public use, internal use, interfaces, or connections. Affected stakeholders
typically play an essential role in identifying security risks, since their vision and experience
provide valuable input.
Example Activities

Identify security threats and vulnerabilities.

List of identified security threats and May include the context, conditions, and
vulnerabilities consequences of occurrence

325
MST 1.2
Practice Statement
Take actions to address security threats and vulnerabilities.
Value
Mitigates the potential negative security impact on the solution and work.


For each identified security threat or vulnerability, define, plan, implement, track, and record
security steps needed, and actions to either mitigate or prevent recurrence.
Refer to the Glossary for the definition of “security steps” or “security actions.”
Example Activities

Take steps or actions to address It may not be possible to act on or avoid all threats
identified security threats and and vulnerabilities, so prioritize the most critical
vulnerabilities. actions and mitigations.

Recorded steps or actions for
addressing threats and vulnerabilities

326
Level 2
MST 2.1
Practice Statement
Develop, keep updated, and follow an approach for handling security threats and vulnerabilities.
Value
Enables an organization to rapidly prioritize and address security issues in a consistent manner.


Similar to an approach for handling and managing risks, define the criteria used to:
• Rate threats, vulnerabilities, and incidents
• Evaluate internal and external contexts of the threats and vulnerabilities throughout the
lifecycle of the solution or mission
• Implement mitigation strategies and plans
Analyzing the resulting level of threat or vulnerability risk is key to defining adequate security
actions. Without analyzing and understanding the potential and actual impacts from threats and
vulnerabilities, identified security actions may be insufficient to address the highest risks.
For security risks, the approach typically consists of the following types of risk responses:
• Risk identification: identifying threats and vulnerabilities
• Risk mitigation: implementing security actions to address the threats and vulnerabilities
• Risk avoidance: removing conditions that give rise to the threats and vulnerabilities
• Risk acceptance: tolerating the level of threats and vulnerabilities without further actions
• Risk transfer: shifting the risk to another party, e.g., insurance
Efficient handling of security incidents requires a specific infrastructure. The handling of security
incidents involves additional stakeholders, e.g., regulatory authorities. Specific points of contact
may need to be determined. Security incidents may warrant a unique set of criteria, different
from handling of non-security risks or incidents.
Security attributes include employing various methods to organize or classify risks into similar
groups such as people, processes, and solutions. This enables a common evaluation approach
to be used for risks with similar attributes.
Additional security risk identification and classification standards and frameworks can be found
in the following table.
327
Example Activities

Identify techniques for Identification techniques include:
handling threats and • Security reviews
vulnerabilities and • Threat modeling
include within the • Security code analysis, both static and dynamic
approach. • Penetration testing
• Security vulnerability monitoring for third-party components
Identify and record a A risk-based approach for handling security threats and
risk-based approach for vulnerabilities typically includes:
handling security threats • Framing the threat and vulnerability risk by identifying,
and vulnerabilities. recording, and keeping the context of the risks from threats
and vulnerabilities updated; describe the environment where
threats and vulnerabilities are present
• Assessing the threat and vulnerability risk within the broader
organizational risk context
• Responding to threat and vulnerability risk once it is identified
and assessed
• Monitoring threat and vulnerability risks
• Addressing current regulatory environment, controls, and
countermeasures
Review the approach for For example, work with product development or service operation
handling security threats teams to identify additional security requirements and
and vulnerabilities with architectural needs. Within an information security domain,
affected stakeholders. controls from ISO 27001 Annex A can be used as best practice
inputs for security risk handling. Extend the approach to
managing the supply chain, as appropriate.
Develop a security threat Establish mechanisms for reporting security threats and
and vulnerability vulnerabilities, e.g., through email, a hotline, a website.
reporting infrastructure.
Develop patch Patches correct security and functionality problems in software,
management processes firmware, and hardware, and are frequently the most effective
and infrastructure. way to mitigate solution vulnerabilities. Sometimes there are
alternatives to patches, such as temporary workarounds involving
software or security control reconfiguration, but these
workarounds often negatively impact functionality.
Consider:
• Frequency of updates
• Criteria for test and acceptance
• Communication of changes to stakeholders
Refer to NIST Special Publication 800-40 for guidance and
information about patch management.
328

Identify processes and Examples of threats include:
approaches for • Advanced Persistent Threats (APTs)
addressing security • Backdoor
threats. • Brute force attack
• Buffer overflow
• Distributed Denial of Service (DDOS)
• Phishing
• Social engineering
• Spoofing
Align and resolve Mitigating security risks may introduce additional risk to other
security threat and work objectives, e.g., cost and schedule.
vulnerability risks with
other risks that may
have consequences for
the work objectives.
Monitor and address For example:
security threats and • Identification of new vulnerability types
vulnerabilities that arise • Rising attacker attention
during operations in a • Responses to the solution or risk handling efforts
timely manner to prevent
or reduce impacts.

Recorded risk-based approach for handling security
threats and vulnerabilities
Results from threat and vulnerability handling
approach reviews and evaluations
Records of stakeholder reviews, reports, and
communications
Infrastructure and procedures for threat and
vulnerability handling
Threat and vulnerability records
Patches

Incident Response and Prevention (IRP)
329
MST 2.2
Practice Statement
Develop and keep updated criteria to evaluate security threats and vulnerabilities.
Value
Enables the impact of threats and vulnerabilities to be evaluated in a consistent and efficient
manner.


Example Activities

Define and record criteria for Criteria may include:
consistently evaluating and • Actors
assessing the magnitude and
impact of security threats, o Internal, e.g., personnel, contractors
vulnerabilities, and incidents. o External personnel
• Threat Types
o Malicious
o Accidental
o Error
o Failure
o Nature
o External requirement
o Internal, e.g., personnel
• Events
o Disclosure
o Interruption
o Modification
o Theft
o Destruction
o Ineffective design
o Ineffective execution
o Ineffective management
o Rules and regulations
330

o Inappropriate use
• Asset/Resource
o People and skills
o Organizational structures
o Processes
o Physical infrastructure/facilities
o IT infrastructure
o Data
o Applications
o Devices
• Time
o Duration
o Occurrence, critical or non-critical
o Detection
o Lag or delay
o Unrealistic schedule deadlines
• Abnormal activity triggers
o Drastic change in number of emails received or sent
o Sudden rise in number of quarantined emails
o Change in the internet access sites
o Online service disruption
o Unexplained errors within customer records
Review the criteria with Consider:
affected stakeholders. • Effects on customer data
• Impacts on confidential information
• Impacts of the delivery timeline, supplier data, etc.
Identify any potential changes
to criteria based on security
incident information and update
as needed.

Criteria for evaluation of security threats and vulnerabilities

331
MST 2.3
Practice Statement
Use recorded criteria to prioritize, monitor, and address the most critical security threats and
vulnerabilities that arise during operations.
Value
Ensures that limited resources are applied to the most critical threats and reduces the security
vulnerabilities of the solution.


All stakeholders, e.g., engineers, end users, and customers, can report identified operational
threats and vulnerabilities using the established infrastructure. The organization assesses the
threat and vulnerability data against established criteria and implements fixes of the most
critical items in a timely manner to prevent further negative impact to the organization and its
customers. The security risk list and the security risk mitigation plan are updated as appropriate
to ensure coverage of similar vulnerabilities in the future.
Example Activities

Use recorded criteria to prioritize
security threats and vulnerabilities.
Monitor critical threats and
vulnerabilities.
Monitor non-critical threats and
vulnerabilities as needed.

Recorded list of prioritized critical
Reports on solutions to address

332

MST 2.4
Practice Statement
Evaluate and report the effectiveness of the approach and actions taken to address critical
security threats and vulnerabilities to the solution.
Value
Verifies the approach remains effective to meet current business needs and prevent further
negative impact.

Monitor the impact of the security-related actions taken to achieve customer objectives, to
address risk, and to achieve project or work group objectives. Explore additional techniques, as
needed, based on the progress.

The security landscape is constantly evolving, and the organization must continually monitor
and adapt to new threats and vulnerabilities.
Example Activities

Identify and develop comprehensive Evaluation techniques may be incorporated with
evaluation techniques to determine the other review activities or conducted as
effectiveness of the security threat and standalone activities. Techniques may include:
vulnerability approach. • Process and quality audits
• Reviews with Senior Management
• Analysis of measurement data
• Technical and functional reviews
• Supplier reviews
• Test effectiveness analysis
• Peer reviews
• Threat and vulnerability simulations
• Technology threat and vulnerability tests
Use evaluation techniques to analyze and Consider inherent security risks and residual
evaluate the actions taken to address security risks.
critical security threats and vulnerabilities
and determine their effectiveness.
333

Review and report evaluation results with

Recorded evaluation approach and techniques
Records of review meetings, evaluations, simulations, audits, and
test results with affected stakeholders
Issues and actions from review meetings with affected stakeholders

Peer Reviews (PR)
334
Level 3
MST 3.1
Practice Statement
Develop, keep updated, and follow an organizational security strategy, approach, and
architecture to evaluate, manage, and verify threats and vulnerabilities.
Value
Minimizes the impact of threats and vulnerabilities to the organization.


An organizational strategy should cover all aspects of the threat and vulnerability landscape
across:
• Organizational functional teams
• Internal and external environments
• Networks and systems
• Platforms and tools
• Processes, work instructions, and templates
• Personnel
• Supply chain
• Data
• Integration points and connections
• Legal and regulatory requirements
Monitoring and identifying security threats and vulnerabilities requires special security tools and
methods, which may be similar in nature to those used by attackers. Specialized security tools
require specific knowledge and a dedicated security testing environment for installation,
configuration, and usage. This frequently requires establishing a Security Operations Center
(SOC).
A security architecture describes the structure, components, connections, and layout of security
controls within the organizational infrastructure and solutions. Organizations have different
needs and types of security and architectural aspects that determine the particulars of various
components, subsystems, products, networks, systems, services, and applications. These can
influence and impact other approaches like defense in depth where layers of defenses are in
place.
335
Verify and validate the security architecture to ensure that the organizational security strategy,
approach, and structure fulfill the needs of the organization.
Analyze and evaluate the results of these verification and validation activities to resolve issues
and determine additional relevant corrective actions.
Example Activities

Define the organizational Consider the following principles in the design of an
security strategy, organizational security strategy:
approach, and • Determine the organization’s risk appetite and strategic
architecture. outlook for inherent and residual security risk
• Establish the context: determine all the elements which
comprise the system to verify that defensive measures have
no blind spots
• Make penetration difficult: An attacker can only target the
parts of a system they can identify and reach; make your
system as difficult to penetrate as possible
• Make disruption difficult: Design a system that is resilient and
minimizes susceptibility to system or network overloading
caused by a Distributed Denial of Service (DDOS) attack
• Make compromise detection easier: Design the system to spot
suspicious activity as it happens and take necessary action
• Reduce the impact of compromise: If an attacker succeeds in
gaining a foothold, they will then move to further exploit the
system; make this as difficult as possible
Define procedures and Examples of sources for criteria include:
criteria for security • Security requirements
verification and validation. • Customer acceptance criteria
• Threat and risk or opportunity analysis
• Threat and vulnerability databases,
e.g., Common Weakness Enumeration (CWE) List
• Standards for secure coding
• Organizational security implementation guidance
Identify security Identify security verification and validation techniques based on
verification and validation known security threats and vulnerabilities. In general, these
techniques. techniques may be manual, automated, or a combination of
both.
Examples of techniques include:
• Simulations and modeling
• Penetration testing
• Friendly hacking
• Fuzzy testing
• Re-play testing
336

Identify and acquire Not all security verification and validation tests can be addressed
security verification and or implemented automatically. In some cases, a manual
validation tools and implementation with the optional usage of supportive tools is
equipment. required—or new testing tools suitable for the particular purpose
might need to be developed.
Examples of types of security testing tools include:
• Data or network fuzzers
• Blackbox scanners
• Port scanners
• Vulnerability scanners
• Dynamic application security testing tools
• Network scanners
• Protocol analyzers
• Spoofing tools
Prepare environment for The verification and validation environment reflects the intended
security verification and operational environment. If operational data is used during
validation. verification and validation, then remove, pseudonymize, or
anonymize sensitive information, e.g., personal identifiable
information or user specific passwords. As a side effect, security
verification and validation might adversely affect components or
systems not in scope. Thus, it may be important to define a
unique environment for security verification and validation
activities.
Perform security
of solutions and solution
components.
Implement corrective
actions.
Provide verification and
validation results as
inputs to design updates.

System Security Plan (SSP) A typical SSP includes:
• Executive summary
• System identification
• System operational status
• System description
• System environment
• System interfaces or connections
• Security controls
337

• Security testing techniques and tools
• Control implementation summary
• Revision history
Network diagrams
Security verification and validation report
Security verification and validation issues
List of security threats and vulnerabilities
Security verification and validation environment

MST 3.2
Practice Statement
Analyze security verification and validation results to ensure accuracy, comparability,
consistency, and validity across the organization.
Value
Provides unbiased security risk information and verifies the quality and consistency of a robust
approach.


Conduct the analysis of the verification and validation results in consideration of the following:
• Accuracy: Exactness and correctness of the verification and validation approach,
environment, and results
• Consistency: Provides same expected outcome through the alignment and cohesion of the
verification and validation environments and components
• Validity: Authenticity of verification and validation approach, environment, and results that
are reflective of the operational environment
• Comparability: Similar internal and external environmental components and behaviors
338
Example Activities

Consolidate the results of security Consider threats and vulnerabilities that arise during
verification and validation operations when consolidating the security threat and risk
activities. or opportunity analysis.
Analyze the consolidated results.
Implement corrective actions.
Report analysis and corrective
actions to affected stakeholders.

Consolidated security verification
and validation results
Analysis results and reports
List of corrective actions This may include the resolutions of the corrective actions.

MST 3.3
Practice Statement
Evaluate effectiveness of the organizational security strategy, approach, and architecture for
addressing security threats and vulnerabilities.
Value
Enables alignment between the security strategy, approach, and architecture; and facilitates a
comprehensive perspective across all organizational security elements.

339

Determine if implemented actions to address security threats and vulnerabilities have been
effective in reducing identified risk to the desired level. If needed, i.e., in case of lack of
effectiveness, define and implement new security mitigation actions. It is unlikely that 100% of
all threats and vulnerabilities can be avoided. This evaluation should cover the threats and
vulnerabilities that are the most likely to occur and have the highest impact on the
organization’s security posture.
Example Activities

Define evaluation criteria.
Evaluate if the implemented Determining the effectiveness of security handling actions is
actions are effective. generally more challenging than just determining compliance
with standard security procedures. Security actions for threats
and vulnerabilities implemented correctly and operating as
intended do not always guarantee an effective reduction of risk
or impact.
Identify, record, implement, Depending on the reason for the lack of effectiveness,
and keep updated security organizations may revisit some or all portions of the security
handling actions when strategy, approach, and architecture. These activities may
actions are found to be result in developing and implementing new or amended
ineffective. security handling actions.

Results of strategy, approach, and architecture
evaluation effectiveness
Evaluation of the security handling actions

340
Level 4
MST 4.1
Practice Statement
Employ threat intelligence analysis to develop and improve the solution security approach and
architecture, and to select security solutions to address threats and vulnerabilities, using
statistical and other quantitative techniques.
Value
Enables advanced understanding and capability to predict and prevent security threats and
vulnerabilities more rapidly and effectively.

A threat intelligence analysis approach usually includes three forms of analysis:
• All-source analysis
• Single discipline analysis, which may include geospatial intelligence (GEOINT)
• Technical processing as a form of analysis
When information is not accurate, it contains intelligence errors. This includes:
• Intelligence errors such as factual inaccuracies in analysis resulting from poor or missing
data
• Intelligence failure that is systemic
• Organizational surprise resulting from incorrect, missing, discarded, or inadequate
hypotheses
• Intelligence analyst misunderstanding the intention of the hostile force, due to missing or
inaccurate information
Threat intelligence analysis (also known as cyber threat intelligence analysis) is the advanced
knowledge and quantifiable discipline and approach to identify, predict, and
quantifiably understand adversaries and their motivations and intentions in ways that help both
the security and all levels of organizational personnel continuously and systematically protect
the critical assets of the enterprise.
Advanced threat intelligence analysis qualifies as a High Maturity approach. It involves:
• Establishing Quality and Process Performance Objectives (QPPOs) specific to identifying,
predicting, and preventing security threats and vulnerabilities
• Identifying related security processes, subprocesses, and measures needed to develop
stable security Process Performance Baselines (PPBs) and predictive Process Performance
Models (PPMs)
341
• Understanding both special cause and common cause of variation for security processes
and solutions
• Identifying and removing special cause of variation to address security stability and to
address and improve common cause of variation to meet the QPPO
The security organization may rely on intelligence analysis as one form of collecting information.
However, simply reviewing collected security threat and vulnerability information alone does not
qualify as threat intelligence analysis. Effective threat intelligence analysis enables the
organization to predict and prevent potential security threats and vulnerabilities. To help
conduct effective intelligence analysis, organizations engage an intelligence analyst or team of
analysts who are primarily responsible for the analysis, processing, and distribution of strategic,
tactical, and predictive intelligence, and take preventive action. These analysts are integral to
providing the organization with comprehensive and actionable threat intelligence information
about hostile forces and potential threat areas. They collect information from a wide range of
individuals and sources to connect the similarities of their knowledge, creating a shared truth
for the organization.

Example Activities

Identify, record, and keep Requirements involve defining questions that identify what data
threat intelligence analysis are expected to be gathered and can entail assembling
requirements updated. information from different sources of intelligence, e.g., threat
analysis, system outputs and data, artificial intelligence,
machine learning, and process automation.
Collect threat intelligence Threat intelligence analysis must look at all requirements and
analysis data. their related data to ensure comprehensive coverage.
Process, verify, and exploit After the collection is completed, the information must go
raw threat intelligence through processing, data integrity verification, and exploitation
data. before it can be considered intelligence information. Conversion
is an important part of this step and can include translations,
decryption, and interpretation.
Analyze, refine, integrate, Analysis and production are a crucial step in the intelligence
produce, and record threat analysis process. This step includes the evaluation, integration,
intelligence data and keep and analysis of all the intelligence data, which can consist of
it updated. detailed reports as well as single-source and multi-source
studies. The outcome of this step is to develop the data and
metadata used for continual threat intelligence analysis.
Report, distribute, and
take action on threat
intelligence data and
342

provide to affected
stakeholders.
Collect, review, and act on Feedback is the dialog that takes place between the intelligence
feedback from reported producers and consumers and continues perpetually as the
intelligence data. information becomes available.

Current threat intelligence analysis This includes security QPPOs, processes, subprocesses,
requirements and measures needed to conduct threat intelligence
analysis.
Raw and refined threat intelligence This includes historical, current, and anticipated future
data and analysis results threat intelligence analysis results and data.
Historical and current feedback An intelligence analyst should have an idea of how his
data and resulting analysis results or her intelligence requirements are met and be ready
and actions to make any adjustments based on feedback.

343

MC Overview
Intent
Provides 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.
344

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.
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 and opportunity 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)
345
Context Specific
Agile Development
In Figure MC-1: Monitoring Agile Development, each of the activities in the development flow
provide opportunities for monitoring progress and are reviewed during the retrospective. For
example, during the daily stand-up, individuals report on progress and blockers, providing
overall status information. During the Sprint retrospective, the team reviews progress made
from the last Sprint and adjusts future Sprints and epics to account for actual versus planned
velocity.
Figure MC-1: Monitoring Agile Development
Typical monitoring practices for agile teams, e.g., stand-up meetings, visual information
management, is reported using:
• A burndown chart (refer to Figure MC-2: Burndown Chart) 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 burndown chart is updated daily indicating the
time needed to complete the work committed for the Sprint.
• Visual information in Kanban boards or other tracking tools indicate the current state of
team performance, and related factors that can impact performance or progress
346
Figure MC-2: Burndown Chart
Data
of the solution.
The production of approaches for managing data to meet relevant needs of the organization is
not a once-and-done activity. Once developed, the execution of the approach and the changing
needs of the business must be closely monitored and regularly evaluated to ensure the
approach meets the business needs for quality. As shortfalls are identified or gaps are
discovered, the approaches must evolve, which may involve changes of focus or adjustments to
ongoing projects.
DevSecOps
347
DevSecOps teams use automated tools to monitor their DevSecOps pipelines and collect and
assess key information about application use to discover trends and identify problem areas.
DevSecOps teams monitor their infrastructure resources, network transport, applications and
microservices, containers, interfaces or connections, gate-check points, endpoint behavior, and
security event logs to take actions when needed. This approach allows teams to “shift left” to
earlier stages in development and minimize broken production changes.
Suppliers
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.
348
Level 1
MC 1.1
Practice Statement
Record task completions.
Value
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

Task list Includes:
• Description
• Status
• Date
349
MC 1.2
Practice Statement
Identify and resolve issues.
Value
Supports prevention of 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 Ensure people are aware that they have been given
the 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
350
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.

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

Record associated contextual information when tracking actual results versus estimates to help
understand what the measurement data represents.
Frequency of monitoring depends on the:
• Collection schedule
• Pace and duration of the work
• Agreed to milestones
351
Example Activities

Track actual results to plans Track size, effort, schedule, resources, knowledge and skills,
and estimates. and budget.
Tracking actual results typically occur through:
• Progress reporting
• Status reviews
• Milestone reviews
Monitor resource capacity, Identify what resources are needed to address the corrective
and availability. actions. This typically includes:
• People
• Processes
• Physical facilities
• Computers, peripherals, and software
• Networks
• Security environment
Monitor the knowledge and This typically includes:
skills 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 This includes:
in 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.
352

• 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

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, e.g.,
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
353
• 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
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.
Suppliers
354
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
MC 2.2
Practice Statement
Track the involvement of identified stakeholders and commitments.
Value
Manages stakeholder involvement 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
status of stakeholder involvement. as team meetings and cross-functional coordination
meetings.
Identify and record significant
stakeholder issues.
Develop recommendations and
coordinate actions to resolve
issues.
355

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.

Estimating (EST)
Planning (PLAN)
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.
356
Value
Ensures expected benefits are obtained by smooth solution transitions and successful
implementations.


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.
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 keep support
updated new or modified • Use transition readiness criteria and verification and
solutions. validation 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
updating 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 Decide whether corrective actions must be completed before
results of transition transferring responsibility to operations and support.
activities. 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 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
357

Status reports of transition Current status of transition activities, including any risks,
activities issues, or 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
Context Specific
Suppliers
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 supplier request 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.
358
Value
Manages corrective actions to 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:
• 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 action is required when the issue, if left
corrective action is needed. unresolved, may prevent the project from meeting its
objectives.
359

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 (SOW)
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
• Using the organization’s defined and established
methods to resolve conflicts and disputes
• Negotiating changes to internal and external
commitments
Manage corrective actions to This typically includes:
closure. • 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)
360
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
• 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.
Suppliers
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.
361
Level 3
MC 3.1
Practice Statement
Manage the project using the project plan and the project process.
Value
Ensures 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 The project process is tailored by the project from the
activities using the project organization’s set of standard processes.
process and all related This includes:
plans.
• 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
362

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
Collect and analyze
selected measurements to
manage the project and
support the organization’s
needs.
Periodically review and Examples of actions that achieve alignment include:
align project performance • Updating the schedule in response to changes in planning
with organizational, parameters, project, and risks
customer, and end user • Updating requirements or commitments in response to
requirements and changes in market opportunities or customer and end user
objectives. needs
• Terminating the project, iteration, or release
Resolve causes of issues This includes:
affecting project • Reviewing issues and lessons learned from previous work
objectives. • 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
363
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
• Locations of facilities for service delivery
Suppliers

• Project progress and performance reports
• Measures
• Risk logs
• Issue logs
• Decision logs
MC 3.2
Practice Statement
Manage critical dependencies and activities.
Value
Manages critical dependencies to significantly reduce risk and increase the likelihood of meeting
objectives.


Critical dependencies can also involve on-time availability of resources.
364
Example Activities

Review and update Record agreements for:
dependencies. • 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
Context Specific
Suppliers
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.
365
MC 3.3
Practice Statement
Monitor the work environment to identify issues.
Value
Ensures objectives are met by providing an effective, safe, and healthy work environment.


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 Work environment elements may include:
environment • Standard workstation hardware and software
elements that affect • Standard production and calibration equipment
safety, health, • Buildings, facilities, and other physical resources
effectiveness, and • Security
productivity and • Safety
identify and record • Management and leadership
any corrections • Specific environmental conditions
needed. • Periodic inspections of the work environment
• Health and welfare
• Diversity
• Privacy
Monitor physical Examples of physical factors that could degrade performance include:
factors in the work • Inadequate office or meeting space
environment that • Poor lighting
could degrade • Inadequate heating, ventilation, or cooling
performance and • Unpleasant odors or fumes
identify and record • Vibration
any corrections • Excessive noise
needed. • Crowding or isolation
• Environmental hazards
366

Identify, record, and Examples of potential work environment issues problems include:
report potential work • Failure to apply required safety standards
environment issues • Inadequate security
and corrections • Improper ergonomics
needed. • 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 • Frequent telephone calls
distractions that • Excessive meetings
degrade • Excessive administrative tasks
performance. • Work that could be better performed by others
• Excessive socializing, including social media, texting, etc.
Remove or reduce Examples of what could lessen the effects of physical work
physical factors that environment factors include:
degrade • Providing resources that reduce the effect of the problem, e.g.,
performance. 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 Analyze the results after the initial corrections and decide whether
work environment further correction to work environment issues is needed.
issue resolution. 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.
Resolve interpersonal Examples of ways to resolve interpersonal problems include:
problems that • Improving interpersonal communication skills by mentoring or
degrade work formal training
relationships. • Advising or counseling one or more individuals
• Using an ombudsman, arbitrator, or facilitator
• Reassigning one or more individuals
• Taking disciplinary action
• Agreeing to disagree
367

Corrections needed to the work environment
MC 3.4
Practice Statement
Manage and resolve issues with affected stakeholders.
Value
Resolves issues early, increasing the likelihood of meeting objectives.


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.
Resolve issues with affected stakeholders.
Escalate the issues not resolvable with affected
stakeholders to the responsible managers.
Track issues to closure.
368

Communicate the status and resolution of issues

Recorded issues Include the:
• Issue statement
• Person responsible
• Due date
• Resolution
• Status
Context Specific
Suppliers
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.
369

OT Overview
Intent
Develops 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 and report the effectiveness of the organization’s training
program.
OT 3.6 Record, keep updated, and use the set of organizational training records.
370

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:
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: Elements in an Organizational Training Program shows the primary elements
involved in an organizational training program.
371
Figure OT-1: Elements in an Organizational Training Program
An organizational training program involves:

• Determining and identifying the organizational training needs
• 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
372

Context Specific
Data
of the solution.
Consider requirements, processes, and risks when identifying training needs relevant to
managing data. Ensure training needs are aligned to roles and responsibilities involved in
managing data.
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.
373
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
374
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
• Technical skills
• Soft skills
o Communication
o Emotional intelligence
o Teamwork
o Problem solving
375

o Active listening
o Time management
o Meeting management
o Interpersonal communication and
dynamics
o Multicultural sensitivity, diversity, inclusion,
equity, and other related skills
• Managerial skills
o Coaching
o Mentorship
o Decision making
o Problem resolution
o Conflict resolution
o Negotiation
o Stress management
• Team building

Planning (PLAN)
Context Specific
Safety

Consider safety requirements, awareness, and risks when identifying training needs. Ensure
safety-related roles and responsibilities are aligned to training needs.
Security

Consider security requirements, awareness, and risks when identifying training needs. Ensure
security-related roles and responsibilities are aligned to training needs.
376
OT 2.2
Practice Statement
Train personnel and keep records.
Value
Avoids training people who already have the needed knowledge and skills. and verifies 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
377
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
378
When developing strategic and short-term training needs, consider:

• The organization’s business plan
• 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
• Needs arising from competency development plans
• Need to keep personnel competencies and qualifications of personnel updated for
performing current and future work
Example Activities

Determine the roles and skills
needed to perform the
processes and the work to be
performed.
Determine training needs. Analyze and prioritize the strategic and short-term
training needs.
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

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


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.
When scheduling training, courses should consider opportunities for personnel to use the new
skills in a timely manner.
Example Activities

Analyze the training needs Identify common training needs that can be addressed
identified by work and support across the entire organization. Consider:
groups. • technical training
• soft skills training
• competency gap identification
• competency analysis and development
• grievance redressal
• cultural awareness
Use analysis results to predict future training needs 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.
Coordinate opportunities to This is necessary to establish new skills and knowledge
reinforce new skills and as habitual and persistent.
knowledge from training activities.
380

Allocated training needs May include:
• Organization common needs
• Project needs
• Support group needs
Training delivery responsibilities Allocated to the:
• Organization
• Projects
• Support groups
Context Specific
People
Conduct personal development discussions, e.g., experience, competencies, career

development, with each individual. Create personalized individual development plans, based on
training needs and an assessment of individual skills as compared to the organization’s
workforce competency descriptions or the needs of the project. Include monitoring parameters
within the development plan.
OT 3.3
Practice Statement
Develop, keep updated, and follow organizational strategic and short-term training plans.
Value
Increases effectiveness and efficiency of task performance.

Incorporate competency development opportunities within training plans.
If Safety is included in the selected view: Ensure safety and safety awareness training is
incorporated within the organizational strategic and short-term training plans. Ensure content
includes roles and responsibilities involved with safety, schedule of activities, and approach to
training delivery.
If Security is included in the selected view: Ensure security and security awareness training is
incorporated within the organizational strategic and short-term training plans. Ensure content
includes roles and responsibilities involved with security, schedule of activities, and approach to
training delivery.
381

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 • Strategic training needs
plan. • Approach to delivering training
• Approach to competency development
• Prioritization
• Timeframes
• Training effectiveness evaluations
• Resources
• Mentorship programs
• Coaching options and parameters
Develop the content of the Organizational training short-term plans typically
organizational training short-term contain:
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 affected
stakeholders.
Revise the plans and commitments
as needed.
382

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

Planning (PLAN)
OT 3.4
Practice Statement
Develop, keep updated, and use a training capability to address organizational training needs.
Value
Ensures 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
organizational training needs. and 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:
383

• Classroom training
• Computer or technology aided instruction, e.g.,
tutorials, simulations, webinars
• Guided self-study
• Formal apprenticeship
• Mentorship
• Coaching
• 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
• Academic programs
• Professional conferences
• Seminars
Develop or obtain training Examples of training materials include:
materials. • 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, consider:
or 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
organization’s training curriculum. descriptions include:
• Topics covered in the training
• Intended audience
384

• 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 For example, review for:
an 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.

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

385
Context Specific
Data
of the solution.
Consider training needs for individuals relative to managing data. Establish mechanisms to
ensure all individuals are aware of the principles, processes, regulations, and guidelines, e.g.,
how to access and use the data glossary for managing data.
Strong data practices often require Subject Matter Experts (SMEs) for execution. These experts
are trained and, where appropriate, certified in their specific discipline. Career paths and
professional growth plans should be established to ensure that personnel have the means to
improve and sharpen their skills for the benefit of the organization. Skilled personnel resources
are valuable assets of the organization, and their skills and competencies should be identified,
formally recognized, and leveraged across the organization. This helps to guide others with less
training, supports consistency of practices across the organization, strengthens legal and
regulatory compliance regarding an organization’s data, and facilitates persistent and habitual
performance of sound activities for managing data.
DevSecOps
Context: DevSecOps is a mindset, a culture, and set practices that fosters close
Leveraging the DevSecOps concepts, there is a focus to automate as much of the process as
possible. Organizations with DevSecOps teams need to tightly couple their development process
and technical training to ensure the teams have adequate skills needed to build and maintain an
automated Continuous Integration / Continuous Delivery (CI/CD) process using the tools
provided by the organization efficiently and effectively. Technical training on the organization’s
tool suite needs to be scheduled on a recurring basis to account for personnel turnover and to
stay current with updates to tools and environments. Tool guidelines may be kept updated at
the team level to support operational tool use. Mentoring within the team is also an effective
training approach. The organization should also focus on improving soft skills to improve
collaboration between the operations and development teams.
Safety

386
Identify topics that require safety awareness training for a broader audience versus more
technical, in-depth safety training. Determine the most effective delivery approach for each type
of training, e.g., internal versus external and classroom versus computer-based training (CBT).
Establish mechanisms to ensure safety training and related materials remain consistent with
industry, e.g., consistent with laws, considerate of technology changes, and organization
information. Ensure content of safety training materials incorporates safety topics and
attributes, recognizing and addressing issues, emergency safety procedures, and scenarios.
Security

Identify topics that require security awareness training for a broader audience, versus more
technical, in-depth security training. Determine the most effective delivery approach for each
type of training, e.g., internal versus external and classroom versus computer-based training
(CBT). Establish mechanisms to ensure security training and related materials remain consistent
with industry, e.g., consistent with industry trends, considerate of technology changes, and
organization information. Ensure content of security training materials incorporates all aspects
of security relevant to the organization, e.g., physical security, standards and processes, access
control, customer data, solution functionality, and security considerations of third-party
systems.
OT 3.5
Practice Statement
Assess and report the effectiveness of the organization’s training program.
Value
Keeps the training program relevant and valuable to the business.


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
• Meets the organization’s standards for the quality of the training
387
Effective assessment of training includes:

• 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.
The impact and results of completed training activities are analyzed to determine if adjustments
are needed. The results of personnel development activities are recorded, monitored, and used
as inputs into future training needs analyses.
Example Activities

Assess the effectiveness of Examples of methods used to assess training course
each training course. effectiveness may include:
• Testing in the training context, e.g., meeting learner
objectives
• Assessment mechanisms embedded in courseware
• Evaluations of instructor effectiveness
• Training assessments involving training participants and
their managers to determine if the training delivered has
helped the projects
Assess the effectiveness of Examples of methods used to assess training program
the training 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 noncompliances; 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
Report the assessment results
to stakeholders.

Training effectiveness surveys May include both individual course surveys and overall
program surveys
Training program assessments Assessments may include instructor observations.
388

Training program analysis results
Instructor evaluation forms May include trend and pattern analysis across multiple
courses
Training examinations
Training measures May include:
• Training assessment results
• Achievement of benchmarking goals
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 who Record the rationale.
are waived from training.
Keep and use records of the training course May include:
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
389

o Provider
o Date delivered
o Students
• Course feedback
Make training records available to the Training records may be part of a skills matrix
appropriate people for consideration in summarizing the experience and education of
assignments. people.

Training records and reports
390
Peer Reviews (PR)

PR Overview
Intent
Identifies and addresses process performance and work product issues through reviews by the
producer’s peers or Subject Matter Experts (SMEs).
Value
Reduces 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
391
• Performing peer reviews thoroughly with multiple viewpoints

• Analyzing data to identify quality trends and improvements
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
Agile Development
Examples of where peer reviews can be performed in an agile project typically include:
• Backlog grooming
• Reviewing completed stories during each iteration with product owner
• Use of paired, team, or mob programming during each iteration
• Pull requests
• Design, test plans, test cases, and code work products reviews
Results from peer reviews are often captured in automated tools.
392
DevSecOps
DevSecOps teams typically use a mix of automated and manual code reviews to maintain
software quality. Often static code analysis tools are used to detect and correct common coding
mistakes and vulnerabilities based on criterion setting in the tool. The team can adjust these
settings over time as they learn more about their code and understand trends or false positives.
Another critical review required in DevSecOps is the configurations of the tools itself. The
choices on customization can easily leak defects and vulnerabilities. Hence Peer Reviews on the
pipeline setup configurations, automation scripts, etc. are important for DevSecOps. Several
popular tools are available to perform this type of analysis. DevSecOps teams also incorporate
static application security testing to identify security vulnerabilities and hotspots into their
Continuous Integration / Continuous Delivery (CI/CD) pipeline. Security vulnerabilities typically
involve an immediate threat or risk to operations and hence require continuous focus on
security hotspots where presence of security sensitive code may require a manual peer review
to take immediate action. These manual peer reviews are typically accomplished as part of a
design or code review request and use a set of coding standards and secure coding practices to
evaluate the code for defects or vulnerabilities.
393
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. Consider the processes that contribute to the
creation and enhancements of the work products.
Record results.

List of issues from work product reviews Identifies the:
• Work product reviewed
• Issues
394
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 creation processes
• Work product functionality and quality attributes
395

• Common issues or defect types
The above items may be included as part of a checklist.
Context Specific
DevSecOps
DevSecOps teams establish their automated code review criteria through the tool setting they
are using for their static code analysis. These settings are often part of the procedure/process
embedded in the Continuous Integration / Continuous Delivery (CI/CD) systems and pipeline;
those automated procedures should include defining a periodic frequency for re-evaluating the
review criteria in the tool, which code and items are subject to manual code review, and the
types of tests the tools perform. Periodic reviews and verifications of the criteria and procedures
in the tool are performed on a periodic and as needed basis. Additional manual code reviews
serve as a manual gate-check for code changes before merging them to the trunk branch. This
helps ensure quality and security by preventing developers from working in a vacuum and
makes the team aware of project status and progress. Once the code review is completed, the
issues addressed, and the code is merged into the trunk branch, a build is initiated as part of
the CI/CD pipeline where additional unit tests are run, and issues resolved. DevSecOps teams
leverage lean development practices with the goal of making small commits and frequent
merges. This typically results in multiple daily code pull requests. Incorporating peer reviews
with pull requests addresses issue resolution in a more timely and effective manner in line with
a shift left approach.
PR 2.2
Practice Statement
Select work products to be peer reviewed.
Value
Manages costs by targeting critical work products for peer review.

396

Example Activities

Evaluate the criticality of the work It may not be possible to review every work product or
product. process. For 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 Different work products or processes may be more
type to use. effectively reviewed 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 or process selection
criteria
List of selected work products or Include the:
processes • Work product
• Process descriptions and steps
• Review type
397
Context Specific
DevSecOps
DevSecOps teams perform design reviews prior to development and then code review on all
their code as part of the code pull request process and Continuous Integration / Continuous
Delivery (CI/CD) pipeline as they are sequenced in the planned agile epics and Sprints. The
CI/CD pipeline and tool setup are in the plan and should include clear criteria for which code is
subject to automated reviews and tests, which is covered by a manual review, and how peer
review comments and actions are captured and resolved.
PR 2.3
Practice Statement
Prepare and perform peer reviews on selected work products using established procedures.
Value
Reduces cost by thorough and consistent review to detect work product issues.


Example Activities

Develop schedule. This should be integrated with the work schedule.
Follow procedures.
Record results from the peer May include:
reviews and the data from the • List of issues found in the peer reviews
process. • Data related to process aspects, e.g., prep time,
number of work products or processes, time spent in
peer reviews
398

Communicate results to affected Results include the peer review process data and the
stakeholders. issues.

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
o Number of issues or defects expected
o Causes of defects
o Affected stakeholders

Context Specific
DevSecOps
Through the tools and embedded criteria in them, DevSecOps teams determine which code or
work products are manually peer reviewed and when and how these reviews are conducted.
Collectively between the Continuous Integration / Continuous Delivery (CI/CD) pipeline, tools,
criteria, and settings, the team uses these to:
399
• Validate requirements
• Verify that coding standards and code review criteria are followed
• Describe which types of tests the tools perform
Manual code reviews are typically performed as part of a code pull or code review request and
use a set of coding standards and secure coding practices to evaluate the code for defects or
vulnerabilities. Paired programming and other techniques can also be used to address code
quality. Action items for addressing peer review issues are then parsed into the automated tools
or made directly in the code.
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 affected stakeholders.
stakeholders.

Resolution of issues
Results May include data resulting from the review.
400
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
401

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
• Delivery and operational analysis
• Common issue resolution analysis
• Peer review effectiveness and efficiency

Context Specific
DevSecOps
DevSecOps teams periodically perform reviews of their analysis tool settings and criteria based
on analysis results to minimize false positives, improve code quality, and adjust to changes in
the application environment or emerging threats and vulnerabilities. Static code analyzers and
dashboards can also be used for analysis. Analysis results from these techniques are typically
covered during Retrospectives to enable the team to avoid or prevent recurrence.
402
Planning (PLAN)
PLAN Overview
Intent
Develops plans to describe what is needed to accomplish the work within the standards and
constraints of the organization.
Value
Optimizes cost, functionality, and quality to increase the likelihood of meeting objectives.

Planning should include an approach, activities, and actions needed for the following:
• Identifying and addressing requirements including quality, functionality, customers,
users, etc.
• Developing budgets and schedules based on estimates
• Identifying resource demands and obtaining the necessary resource capacity and
availability
• Identifying the appropriate set of stakeholders and tasks
• Managing risks and opportunities
• Developing and keeping the project plan updated to reflect how to perform the work
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
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
403
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 estimates against capacity and
availability of 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.
404

Planning activities can be performed at varying levels in an organization, e.g., enterprise,
division, department, project, or workgroups; and therefore, can be performed by various
groups in an organization. The organization defines its organizational structures and
accompanying roles and responsibilities for the various functions throughout the organization,
including the perspective for planning.
A “project plan” is the overall plan to manage the project, including a coherent picture of who
does what and when they do it. Develop the project plan as a stand-alone document or
distributed across multiple documents. Use it 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., office supplies
• Staffing calendars
• Resources, e.g., personnel, tools
• Number of parking spaces

Estimating (EST)
Context Specific
Agile Development
405
Figure PLAN-1: Agile Planning
Figure PLAN-1: Agile Planning provides a summary view of a typical agile development
workflow:
• Product Owner: The product owner gathers inputs from all affected stakeholders to
organize and prioritize user stories into epics and Sprints to address the product backlog.
• Product Backlog: A prioritized collection of user stories, epics, and Sprints that represent
the entire set of known requirements. 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 Planning Meeting: During this meeting, the collection of user stories or epics
selected for the Sprint is 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.
• 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. This information is used to
provide input to schedule and budget planning.
o Schedule: Each Sprint has a fixed duration, usually two to four weeks, and the
collection of Sprints defines the total anticipated release schedule.
o 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.
406
Data
of the solution.
Define the data lifecycle that aligns to the business process, including traceability from the
creation or acquisition of the data source to the target. Consider the following data lifecycle
phases and scope the boundaries based on the approaches for managing data:
• Business Direction, e.g., data requirements, creation, acquisition
• Development, e.g., architecture, design
• Implementation, e.g., physical architecture
• Deployment, e.g., insertion into the operational environment
• Operations, e.g., data transformations, usage, performance, maintenance
• Retirement, e.g., decommissioning, archiving
Throughout the data lifecycle, as needed, obtain agreement from stakeholders regarding the
data elements and authoritative data sources.
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
407
DevSecOps
DevSecOps teams build on agile planning principles, and in addition consider and address
additional security requirements and constraints. DevSecOps is directly dependent on having
consistent and repeatable agile development processes in place. One key consideration that
should be addressed in planning is when developers will be using Free Open-Source Software
(FOSS) as part of their software builds or incorporating third-party software in their product. If
FOSS or third-party software is used, then planning should address:
• How developers are trained to protect the software they are writing from FOSS risks and
supply chain attacks
• The mechanisms in place for developers to make them aware of existing vulnerabilities in
a timely manner; this would include a list of the known vulnerabilities in the software they
are planning to reuse or incorporate into their code, such as a Software Bill of Materials
(SBOM)
• The processes and tools needed to detect and remove these vulnerabilities
• Identification of work arounds, mitigation strategies, and continuity response plans that
can be implemented if an attack through one of these vectors should occur
• Any licensing or copyright considerations or restrictions on their use
People
Manage recruiting and retention by leveraging workforce competencies, including:

• Analyze recruitment and retention needs based on evaluation of the existing workforce
against the workforce competencies
• Identify and analyze competency gaps, and compare with industry benchmarks
• Conduct recruiting or establish development plans based on analysis results
• Plan for personnel transitions to minimize disruption and maximize productivity
Safety

408
Plan safety activities considering dependencies between safety components and any other
activity that could be affected. Ensure that related impacts are identified and managed with
planned safety activities. Integrate safety activities into the project plan and schedule, to the
greatest extent possible, while taking into consideration requirements of regulatory agencies.
Security

Determine the necessary security controls, based on the organization’s security criteria. Identify
and plan security activities, resources, and process assets, e.g., guidelines, templates, and
tools; required to meet the necessary security level. This includes:
• Identify the necessary security posture
• Tailor the security activities and process assets for the work according to the security level
• Identify needed security resources and training to perform the work
Integrate the security activities and process assets within the overall work plan, including
consideration of security resources and knowledge needed to perform the security activities.
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.
Suppliers
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 may include such items
as:
• Availability of assets and technologies
• Supplier management objectives and constraints
• Consideration of supplier selection and management methods
• Potential supplier agreement types and terms
409
• 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 keeping updated 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.
410
Level 1
PLAN 1.1
Practice Statement
Develop a list of tasks.
Value
Ensures 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
411
Context Specific
Services
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, e.g., a labor category for a human resource
• Descriptions of needed skills for the personnel resources, e.g., human resources, training,
professional certifications
• Descriptions of needed equipment, tools, or facilities
PLAN 1.2
Practice Statement
Assign people to tasks.
Value
Ensures 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.
412
Example Activities

Assign an individual who is Identify an individual with the skill and experience
responsible for each task. needed to accomplish the task.
Assign any additional people to the Determine the project load and the abilities of the
task. individuals as a part of assigning them to the task.
Review assignments with the Ensure that the assigned individuals understand what is
assigned individuals. needed to complete the task assignment.
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
413
Level 2
PLAN 2.1
Practice Statement
Develop and keep updated the approach for accomplishing the work.
Value
Maximizes 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, and new technologies
• Risks associated with the above and how they are mitigated
• Communication mechanisms, channels, and frequency
Example Activities

Identify the objectives of the Describe what the project is trying to accomplish in
project. terms of expected outcomes and as applicable, Quality
and Process Performance Objectives (QPPOs).
Identify the approach to be used to Describe the why and how:
achieve objectives. • Tasks are performed
• The work is done
• Methods or techniques are used
• Resources are provided to support and accomplish
the work
414

• Information, e.g., schedules, plans, budgets, and
details on inputs and outputs, is communicated and
made accessible
Identify requirements. Record how requirements are addressed in the
approach.
Record business considerations. Business considerations may include:
• Potential costs and benefits
• Intellectual property
• Competitive climate
• Long-term needs and profit margins
• Core competencies to be enhanced
• Core competencies needed from other parties
• Future trends
Define and record the project The project lifecycle describes the major phases and
lifecycle. 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 Reestimating cost and scope
o Renegotiating commitments
o Replanning 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 replanning.
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
constraints. resources. For example:
• Capacity and availability
• Other groups in the organization
• External suppliers
Identify affected stakeholders.
415

Record agreements with Decide the nature of these agreements by considering
stakeholders. each party’s needs, objectives, expectations,
constraints, and risks.
Identify risks or opportunities.
Identify safety and security Consider safety and security in all major planning
approaches. activities.
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?
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
Agile Development
For agile projects, Figure PLAN-2: Agile Development Lifecycle Phases shows the most common
phases of an agile development lifecycle. Each agile iteration follows these basic phases. In
general, agile iterations or Sprints are two to four weeks.
416
Figure PLAN-2: Agile Development Lifecycle Phases
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.
Security

417
Most aspects of security are addressed multiple times within a solution lifecycle, but in general, the
earlier in the lifecycle that security is addressed, the less effort and cost is ultimately required to achieve
the same level of security. Software development in particular can introduce many security vulnerabilities.
However, few software development methodologies or lifecycles explicitly address software security in
detail, so secure software development practices must be added to each phase of the lifecycle to ensure
that the software being developed is well-secured. For more information, refer to NIST Special Publication
800-218, Secure Software Development Framework.
Figure PLAN-3: Development Lifecycle with Security Integration provides an example of
integrating security into a typical solution development lifecycle. While not all activities related
to security are reflected, this graphic provides some of the most common considerations for
integrating related processes. Additional security requirements and objectives should be
considered during estimating, planning, and monitoring.
Figure PLAN-3: Development Lifecycle with Security Integration
418
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.
Suppliers
The acquisition strategy defines the approach for formulating supplier request 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.
419
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
• 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.
420


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
• 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 Consider current and future needs when identifying
knowledge and skills needed versus gaps. Succession planning is often used as a strategy
those held by the currently for retaining capabilities.
assigned people.
421

Select methods for providing Training may be either in-house (both organizational
needed knowledge and skills. and project) or external.
Methods may include:
• Staffing and new hires
• Classroom instruction
• Online or computer-aided training
• Apprenticeship or mentorship 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.

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 change
• 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.
422
Suppliers
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 supplier
request package.
PLAN 2.3
Practice Statement
Based on recorded estimates, develop, and keep the budget and schedule updated.
Value
Enables timely management and corrective actions needed to achieve objectives, through early
detection of significant deviations from the budget and schedule.


Record and keep updated 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.
423

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
o Base personnel 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 • Estimating size, complexity, effort, duration, and cost
them 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
424

• 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

Estimating (EST)
Context Specific
Services
425
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
Suppliers
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.
Value
Ensures that stakeholder needs are addressed when they arise, reducing the amount and cost
of rework.

426

Stakeholder involvement incorporates ongoing sharing of information and allows the project to
focus on:
• Developing the right solutions
• Delivering adequate services
• Acquiring compatible solutions that provide the required functionality
Identify personnel or workgroups 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.
Key elements of effective information sharing include:
• Ensuring the right set of people receive the information
• Sharing information in a timely manner
• Clarifying, as needed, to ensure that the information is understood
• Following up, as needed, to ensure that the information is being acted on
Examples of methods to share information required for performing work include:
• Meetings, e.g., in-person meetings, video conferences, and teleconferences
• Online systems, e.g., ticketing systems, workflow systems, requisitioning systems, and
databases
• Online collaboration tools
• Emails
Example Activities

Develop a list of stakeholders.
Identify the involvement of each Describe how and why each stakeholder is involved and
stakeholder. what is required of them.
Record when the involvement is Address the timing and sequencing for stakeholder
required. input and involvement.
427

Identify information to be shared Consider the following aspects of the communication:
on an ongoing basis. • Information needs
• Sources of the information, e.g., status, client, and
updates
• Responsibilities for communications, e.g., individuals
and workgroups
Identify the communication Consider the following aspects which influence and
parameters. dictate the types of communication:
• Mechanisms, including technology considerations
• Scope
• Importance of message
• Channels
• Frequency
• Security
• Privacy
• Confidentiality
Share information and collect any Use feedback to improve future communications.
communication feedback.

Stakeholder involvement plan May include:
• List of affected stakeholders
• Rationale for involvement
• Relationships, roles, and responsibilities
• Schedule of interaction
• Communication strategy
Responsible, Accountable, Defines the RASCI for activities and work products.
Supporting, Consulted, Informed
(RASCI) table
Results of information sharing For example, meeting minutes, data in online systems,
and emails.
Context Specific
Services
428
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
Suppliers
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.

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
429
• Operational capability of the solutions

• Assignment of responsibility for the transition, delivery, and support
• Activities needed to manage the transition, e.g., project kickoff
• Personnel, including staff augmentation
• Support for the solution in its intended environment, including:
o Definition of transition readiness criteria
o Reviews with affected stakeholders
o Safety considerations
o Security considerations
• Handling of potential risks, including safety risks, security threats, and vulnerabilities
• 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-
criteria. level 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 described who is responsible.
support. Includes:
• Transition infrastructure
• Future enhancements
Determine operations and support Identifies any additional skills, experience, or
training needs. knowledge needed for successful and smooth
operation.
Example Work
Further Explanation
Products
Plans for transition to May include:
operations and support • Scope and objectives
• Assignment of responsibility
• Transition processes and procedures
• Activities needed to manage the transition and support the
solution in its intended environment
430
Example Work
Further Explanation
Products
• 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
Context Specific
Security

Identify and plan the security activities, resources, and process assets, e.g., specifications,
templates, and tools; required to ensure that a consistent security level is obtained and
preserved during operations and transition to operations.
The plan must address:
• Stakeholder responsibilities
• Security procedures
• Security characteristics of the intended operational environment, e.g., physical access,
networks, and perimeter protection
• Specific information necessary to perform security activities
Examples of security assets to consider are:
• Security patch management procedures, which includes communication, delivery, and
installation
• Security configuration and hardening guidelines, which includes scope and content of the
configuration; and hardening for the different solution components, which includes third-
party components, if appropriate
• Security delivery and operations instructions, which includes information about
maintaining the security level during operations, e.g., for managing roles and privileges,
secure handling of passwords, security incident handling, and usage of digital signatures
or fingerprints
• Security commissioning instructions, which includes information for addressing security
during commissioning, e.g., for changing default passwords
431
Suppliers
If support will be provided by an organization different from the supplier, a sufficient overlap
period should be included in the plan.
Typically, the acquirer develops initial transition and support plans and then reviews and
approves more detailed transition and support plans.
In an acquisition, the transition and support plan should also include:
• Expectations for supplier execution of the transition
• Warranty expectations for the acquired solution
• Transition of intellectual property or other acquirer assets to the acquirer's designated
repository
• Resolution steps if any problems are encountered
PLAN 2.6
Practice Statement
Ensure plans are feasible by reconciling estimates against capacity and availability of resources.
Value
Increases likelihood that the objectives are 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
432
• Identifying tools, techniques, and methods that could reduce time or cost
• Implementing incremental delivery
• Renegotiating stakeholder commitments
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

Identify and plan for resource capacity and
availability.
Perform resource leveling to adjust scheduling Resource leveling balances the demand for
of 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
Suppliers
433
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.
PLAN 2.7
Practice Statement
Develop the project plan, ensure consistency among its elements, and keep it updated.
Value
Ensures efficient and effective communication and achievement of objectives through a
consistent project plan.

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
434
• Negotiating and obtaining commitment to the project plan

A 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
• Resources and skills
• Stakeholder roles and involvement
• Infrastructure
• Improvement and sustainment activities
A plan provides the basis for:
• Monitoring and managing project performance
• Taking timely corrective actions to ensure the objectives are met
• Replanning when needed
Example Activities

Record the project plan.
Review the project plan with Ensure that the project plan describes a realistic approach
affected stakeholders. for 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 Planning is an iterative activity.
necessary.

Overall project plans A project plan may be composed of multiple plans (which
may be separate or combined into one or more documents)
such as:
• Staffing Plan
• Stakeholder Involvement Plan
• Data Management Plan
• Data Migration Plan
• Communication Plan
435

• Performance Improvement and Sustainment Plan
• Measurement and Analysis Plan
• Monitoring and Control Plan
• Solicitation and Supplier Management Plan
• Risk and Opportunity Management Plan
• Transition Plan
• Quality Management Plan
• Configuration Management Plan
• Security Plan
• Safety Plan
• Workgroup Management Plan
PLAN 2.8
Practice Statement
Review plans and obtain commitments from affected stakeholders.
Value
Reduces rework and increases the likelihood of achieving objectives through a consistent
understanding and commitment to the plan.


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
reviewing the work they are information needed to understand requirements and
responsible for and the inputs that plans necessary for accomplishing the work.
initiate the work.
Record commitments. • A commitment is a pact that is freely assumed,
visible, and expected to be kept by all involved
436

• 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 may 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
reviews prevent 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
Recorded Includes decisions and agreement to requirements, project plans, and
commitments their 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.
437
• 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.
438
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
Establishes the project process, ensuring the efficient and effective achievement of the
objectives.


Select and tailor or modify processes from the organization’s set of standard 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
439
When the organization's set of standard processes change, there may be changes in the
project’s processes.
Example Activities

Select standard processes from the Collectively, these comprise the project process
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 • Estimating models
as 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.

440
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.
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.
Suppliers
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
Increases the likelihood that the objectives will be met, by using proven organizational assets
for planning the project.

441

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
• 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 Estimates and supporting information typically include:
measurement repository to • Validated historical data from this project or similar
estimate the work. 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
442

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

Revised project estimates Estimates that are based upon organizational
experience with other similar projects help to
accomplish work more accurately and effectively.
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)
443
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 or connection risks include:
• Incomplete interface or connection descriptions
• Unavailability of commercial off-the-shelf (COTS) components
An additional development-specific example of scheduling factors includes:
• Integration and test issues
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
444
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.
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.
445
Value
Reduces risk and increases the likelihood the project will be completed on time, within budget,
and meet quality objectives by paying close attention to critical dependencies.


Example Activities

Identify each critical Record dependencies, relationships, and how they affect
dependency. the plan. Consider personnel or staff augmentation
dependencies.
Integrate schedules. An integrated master schedule (IMS) can be used to
identify critical dependencies between work groups and
functions.
Review and negotiate Communicate new or existing dependencies and changes
dependencies with affected with affected stakeholders to ensure that they can
stakeholders. 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.
446
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.
Example Activities

Analyze project and plan The critical aspects of the project environment are requirements
for resources, facilities, driven. Explore project environment functionality and quality
and 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
447

• Project equipment
o Computers or workstations
o Communications technologies, e.g., telephones, fax
machines, email, and networks
o Office equipment
o Printing and reproduction equipment
• Supplies
• Application software
• Documentation
Assign a responsible Examples of actions include:
individual to plan to • Preparing budget requests
acquire resources, • Developing cost-benefit justifications
facilities, and the • Consulting with Subject Matter Experts (SMEs)
environment needed to • Submitting purchase orders
perform assigned work. • 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.
Plan for support personnel Examples may include:
needs. • Business or administrative
• Computer support personnel
• Technical writing and documentation
• Laboratory technicians
Ensure individuals and Inputs may be taken on a periodic basis, e.g., annually through
groups provide input and employee engagement surveys; or based on a significant event,
participate in decisions e.g., moving to a new facility, changing working hours, or
concerning resources, introducing a personnel canteen. Consider the following areas for
facilities, and collecting inputs:
environment. • Arrangement of project facilities
• Alterations or improvements to the project environment
• Resources needed to perform their project activities
• Remote work operational parameters
Examples of mechanisms for gathering opinions from individuals
include:
• Opinion surveys or organizational culture and engagement
questionnaires
• External surveys or benchmark reports
• Interviews with members of the workforce
448

• Discussions with management, including meetings that allow
individuals to skip levels of management or to meet with
management representatives, such as an ombudsman
• Group meetings on concerns
• Focus groups or advisory boards
• Postmortem project reviews
• Suggestion boxes or other private means of accepting
comments
• Email or other electronic means
To maximize benefits from inputs:
• Acknowledge the receipt of the opinions
• Analyze the inputs collected to identify action plans for
implementation
• Share the analysis along with actions identified for
implementation with the members of the workforce
• Implement the actions identified
• Keep the workforce informed about the status of the identified
actions
Track actions identified
and communicate status.

Project resources, facilities, and May be included as part of the overall project plan or
environment plan may be separate, e.g., for large or complex projects or
environments. Include approach for collecting and
addressing workforce and user inputs.
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
449
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
• 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
Security

Consider security needs when planning for the project environment. Key activities include:
• Analyzing technology needs, e.g., review current platforms, servers, networks, and tools;
and conduct a security needs assessment
• Identifying criteria for selecting security tools and methodologies
• Evaluating and selecting security tools
• Applying security tools and methodologies
• Defining physical security processes, procedures, and protocols
Consider an environment implementation that incorporates defense in depth to maximize
overall mitigation of security risk. Consider the following types of security tools when planning
for the secure environment:
• Badging and physical access control
• Common Weakness Enumeration (CWE) scans, to help identify software vulnerabilities
450
• Secure coding standards and guidelines

• Attack modeling methods/tools
• Source code security analyzers, or Static Application Security Testing (SAST) tools
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
Suppliers
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)
• Configuration Management
• Testing
• Infrastructure hosting
• Information repositories
• Field sites
• Classified facilities
451
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 (QPPOs)
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 • QPPOs
the 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
452

• Stakeholder requirements
• Laws and regulations
Identify or develop alternative May include:
processes for doing the work and • Analyzing organizational process performance
meeting objectives. baselines and models to identify candidate processes
• 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 alternatives. This analysis can be supported by aligning
evaluation criteria. the 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 If needed, repeat these activities several times until
best meets the criteria. confident that the best available alternative has been
identified.
Evaluate the risk of not achieving If the risk cannot be avoided or mitigated, it may be
the project’s QPPOs. necessary to revise the project’s QPPOs.
453

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
Risk assessment of not achieving Risk handling plan and action to be identified. Decision
the project’s QPPOs analysis may be used to identify alternate risk
mitigation practices.

454

PAD Overview
Intent
Develops the process assets necessary to perform the work and keeps them updated.
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 the organization’s processes and
assets available for use in a process asset library.
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 work environment standards available
for use.
PAD 3.6 Develop, keep updated, and make organizational measurement and
analysis standards available for use.
455

Organizational process assets enable:
• 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 Development
Agile is an iterative approach to project management and software development that helps
teams deliver value to their customers faster. Figure PAD-1: Typical Agile Assets shows some
example agile process assets.
• Agile Processes: Agile processes and workflows are typically embedded within tools.
• Product Backlog Tool / Template: A product backlog lists and prioritizes the task-level
details required to execute the strategic plan set forth in the roadmap. The backlog should
communicate what is next on the team’s to-do list as they execute on the roadmap.
Typical items in a product backlog include user stories, bug fixes, and other tasks. The
backlog is a translation of how the team delivers the vision outlined on an agile roadmap.
• Sprint Backlog and Release Plan Tool / Templates
o A Sprint backlog is a list of work items the team plans to complete. These items are
usually pulled from the product backlog during the Sprint planning session.
o Release planning maximizes the chances of achieving the goals of the Sprint.
• Task Board Tool / Template - A Task Board is the focal point of any Agile project and
serves as a good place at which to hold the stand-up meeting or Scrum. Typically, a Task
Board displays only information pertinent to the current Sprint and is cleared off before
the next Sprint begins. The task board depicts the set of tasks to be performed by the
agile team during a particular period of time. One type of task board used by agile teams
is Kanban.
• Burndown Chart Tool / Template - A burndown chart or burn down chart is a graphical
representation of work left to do versus time. The outstanding work (or backlog) is often
on the vertical axis, with time along the horizontal. Burn down charts are a run chart of
outstanding work. It is useful for predicting when all the work will be completed.
456
• Retrospective Tool / Template - Retrospective meetings occur at the end of a project to

help teams pause and think about improving future performance. It's a safe space for
reviewing the project's successes, identifying opportunities for process improvement, and
solving issues that may have come up.
Figure PAD-1: Typical Agile Assets
Data
of the solution.
Establish process assets for managing the data aspects of the work. For example, define
process assets for the following:
• Business rules for data management and data quality, e.g., data sufficiency, data
ownership, data coverage, data completeness
• Metadata management processes, e.g., adding metadata categories, managing metadata
repositories, validating metadata, analyzing impacts of potential data changes
• Data retention criteria and processes, consistent with legal and regulatory requirements
457
• Data security, e.g., access controls, permission levels, levels of data classification
• Archival and retrieval processes, consistent with organizational and regulatory
requirements
• Data remediation processes
• Audit requirements and audit trail logs
DevSecOps
DevSecOps teams rely on a set of automated process assets and tools, allowing developers,
operations, and security to collaborate to build and deploy software to production. This includes
build automation/Continuous Integration (CI), automated testing, validation, and reporting.
Pipelines are built for each DevSecOps team based on the environment, e.g., resources and tool
availability. Pipeline development and process assets improve and evolve over time. Pipelines
may also include manual gates requiring human intervention before code is deployed. A key
characteristic of a DevSecOps pipeline is Continuous Integration / Continuous Delivery (CI/CD),
continuous feedback, and continuous operations. These functions occur on an ongoing basis.
Safety

Safety process maps, processes, and guidelines provide roadmaps to address workplace
environment and functional hazards and other safety related risks and issues. Ensure that the
organization continually supports deployment of safety processes and process assets,
particularly when starting new work. Incorporate the status of safety process deployment
activities within the organization’s list of projects.
Security

Security process maps, processes, and guidelines provide roadmaps to address workplace
environment and security related risks and issues. Ensure that the organization continually
supports deployment of security processes and process assets, particularly when starting new
work. Incorporate the status of security process deployment activities within the organization’s
list of projects.
458
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
459
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
460
PAD 2.2
Practice Statement
Develop, buy, or reuse process assets.
Value
Minimizes 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

461
PAD 2.3
Practice Statement
Make processes and assets available.
Value
Reduces cost and time needed for performing the work by using existing process assets.


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
462
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
463
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
Ensures that processes add value by providing a robust process architecture.

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-2: Structure and Content describes the differences
between the two types.
464
Figure PAD-2: Structure and Content
The content architecture may independently vary over time because of changes to
organizational needs. Structural architectural typically only changes 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
• Improves coordination of efforts
• Reduces unnecessary activities
• Reduces missed activities
• Improves process flow by ensuring that all necessary inputs and outputs are defined
465
Example Activities

Identify process requirements. Describe the business needs addressed by
processes.
Identify process architecture objectives. Process architecture objectives describe how and
why the process architecture is used and the
information that the representation provides.
Develop and record the format of the Process architecture is like solution architecture,
process architecture. except that 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
• Integrated DEFinition Methods (IDEF)
• Suppliers, Inputs, Processes, Outputs,
Customers (SIPOC)
• 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 architecture. process types.
Review and update process architecture Include representatives of each process type
with affected stakeholders. represented in 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
466

Context Specific
DevSecOps
DevSecOps tools and automated processes should be reviewed and considered for any process
architecture. This would include where and how the automated tools interface or connect and
integrate with manual processes.
Safety

Specifically address safety within the organization’s process framework. Define responsibilities
and provide training so that all individuals in the organization understand their role in ensuring
safety. Additionally, define how safety-related activities relate to other development, post-
development, and operational activities, including required inputs and outputs. Integrate safety
processes with other processes to ensure relationship dependencies are captured.
Security

Specifically address security within the organization’s process framework. Define responsibilities
and provide training so that all individuals in the organization understand their role in ensuring
security. Additionally, define how security-related activities relate to other development, post-
development, and operational activities, including required inputs and outputs. Integrate
security processes with other processes to ensure relationship dependencies are captured.
PAD 3.3
Practice Statement
Develop, keep updated, and make the organization’s processes and assets available for use in a
process asset library.
467
Value
Reduces the time and effort needed to organize, access, and update process assets, leading to
reduced cost and waste.

Organizational standard processes and assets are:
• Defined at multiple levels in an organization
• Tailored for each of the organization’s business areas or functions
• Made available in a Process Asset Library (PAL) that contains both process assets and
related work products that are part of the organization’s set of standard processes

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
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.
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.
468
Example Activities

Verify that the organization’s set
of standard processes and assets
are aligned with strategic process
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 May include:
for 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
Design and implement the This includes the library structure and support
organization’s PAL. environment.
Specify criteria for including Assets are selected based primarily on their relationship
assets in the PAL. to the organization’s set of standard processes.
Specify procedures for storing,
updating, and retrieving assets.
Enter selected assets into the Assets include:
PAL and catalog them for easy • Organizational policies
reference 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
Make assets available for use by
projects.
469

Periodically review the usefulness Consider removing assets that are no longer used or
of the assets. viable.
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
• 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
implement actions. and those who perform the process.
Build and record processes and Building and recording processes and assets may include:
assets. • Specifying the attributes of each process or asset
• Specifying relationships among processes or assets
Process attributes may include:
• Applicable standards
• Process performance objectives
• Entry criteria
• Inputs
• Tasks
• Verification and Validation
• Outputs
• Exit criteria
• Connections
• Measures
Perform reviews on the
processes or assets.
470

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
necessary. identified
• 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 These may be made available through a variety of media,
available. including:
• Documents and records
• Apps
• Websites
• Videos and training materials
• Scripts in automated tools
• Intranets and other electronic media

Design of the organization’s PAL
Organization’s PAL
Process-related work products in
the PAL
Action plans
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)
471
Context Specific
DevSecOps
DevSecOps tools and their related automated processes are part of the overall organizational
processes and assets. As with any other process or process assets, these processes should be
periodically reviewed for effectiveness and efficiency.
Safety

Ensure suitable safety guidelines and process assets are available to support the work.
Security

Ensure suitable security guidelines and process assets are available to support the work.
Example activities include:
• Select and adapt existing guidelines and assets, as necessary, to match the technologies
and the context of the work, including security aspects
• Manage the security guidelines and assets, and make them accessible to the organization
• Keep the guidelines and assets updated, based on changes in technology, standards, or
security
o Conduct and incorporate industry research to remain current with the latest industry
trends and state-of-the art information
o Collect and review feedback periodically for updates, considering inputs from external
stakeholders and practitioners
• Verify usage of the correct security assets through periodic reviews
Example security assets include:
• Security design guidelines
• Secure coding guidelines for different programming languages
• Libraries for authentication
• Authorization mechanisms
472
• Shared or integrated security processes across service systems and solutions

• Security architecture
• Security processes and their related assets that are utilized with the supply chain
PAD 3.4
Practice Statement
Develop, keep updated, and use tailoring criteria and guidelines for the set of standard
processes and assets.
Value
Accommodates the unique needs of each project while avoiding unnecessary work.


Consistency across the organization promotes the effective use of organizational standards,
objectives, and strategies, and provides a foundation for sharing of process data and lessons
learned.
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 limited and
consider 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
• 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
473
• 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 determining and selecting tailoring
organization’s set of standard options, e.g., tailoring lifecycle models from the ones
processes. approved by the organization
• Criteria for selecting process elements from the
• Procedures for adapting the organization’s common
measures to address information needs
• Procedures for recording tailoring
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
tailoring guidelines for the part of 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
• Procedures that must be followed in performing and
recording process tailoring
474

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
When defining tailoring guidelines and criteria in a service delivery environment, consider:
• The service catalog, and how standard services and service components are selected or
modified based on the standard services available
• Fixed elements of standard services that will not change. Fixed elements may have
allowable variation within specified limits. Examples of allowable variation:
o Pricing
o Hours of operation
o Geographical coverage
• Knowledge of variability in customer needs to develop tailoring options
• Needs and expectations for service systems, e.g., core assets that are consistent across
standard services
PAD 3.5
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.
475

If Safety is included in the selected view: reflect all relevant safety-related requirements and
considerations in work environment standards.
If Security is included in the selected view: reflect all relevant security-related requirements and
considerations in work environment standards.

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 should also consider on-site, working from
home or remote locations, and hybrid models.
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, ergonomics, safety, and security of the work
environment, e.g., OSHA and other international standards
• Acceptable use policies
• Virtual work or remote workforce requirements
• Workstation hardware and software requirements
• Standard application software and tailoring guidelines
• Standard production and calibration equipment
• Licenses, security passwords, and identification documentation
• Criteria for the use and approval of waivers
• Criteria for tailoring the work environment to meet needs
Example Activities

Evaluate commercially available Choose standards to evaluate based on the
work environment standards. organization’s needs.
Adopt, develop, or tailor work
environment standards to fill gaps
based on the organization’s process
Periodically analyze the work
environment to identify changes or
476

resources that could improve work
performance.
Prioritize potential improvements to Complying with laws and regulations may cause a
the work environment. higher 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 Examples of work environment resources that may
improve performance. enhance 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
the standard work environment from being applied
• There is a new requirement that the standard work
environment currently cannot or does not address
PAD 3.6
477
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
measurement and analysis. of data or analysis techniques.
Specify tailoring guidelines for Includes criteria for when a waiver is allowed or
applying measurement standards to approved.
individual projects.

Organizational measurement and
analysis standards
Waivers or requests for Waivers are not intended to be a means to opt out of
measurement 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
the standard from being applied
• There is a new requirement that the standard
currently cannot or does not address
478

PCM Overview
Intent
Manages and implements the continuous performance improvement of processes and
infrastructure to meet business objectives by identifying and implementing the most beneficial
process improvements and making performance results 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.
PCM 3.4 Provide support for implementing, deploying, and sustaining process
improvements.
479
PCM 3.5 Deploy organizational standard processes and process assets.

PCM 3.6 Evaluate and report 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
An understanding of the workforce competencies should be used to develop and deploy
processes that meet business objectives. As processes and work products are updated, their
alignment with competencies is reviewed and verified.
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.

480
Context Specific
Agile Development
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.
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 produces more robust and
sustainable organizational improvements.
481
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
Reduces effort, cycle time, costs, defects, and waste, and increases 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
482

Assign responsibilities and keep Typically includes:
them updated for coordinating • Defined roles and responsibilities
process related activities. • Following the support structure

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
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.

483

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:
• 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
supported and implemented by stakeholders performing the process roles.
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.
484

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
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.
485


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.
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
486
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 strengths, weaknesses, 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
• Safety evaluations
• Security evaluations

Systematically analyze, prioritize, and record improvement suggestions. This analysis includes:
• Circumstances
• Sources
• Side effects
• Validity
• Benefits
• Effort
• Time to implement
487
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 May include:
for 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 Rationale for the proposed improvements may be
and communicate expected results. captured in a business case, which may include the
following information:
• Value and rationale of each proposed action
• Improvement based on the evaluation of criteria
• Objectives
• Constraints
• Target users
• Risks
• Estimated cost and schedule to implement
• Expected results
• Estimated return on investment
• Deliverables
A business case is typically reviewed with stakeholders
and undergoes an approval process.
488

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
• How to implement the proposed improvement
Business case
Recorded selection criteria
List of selected improvements for Refer to above proposed improvement list.
execution
PCM 2.2
Practice Statement
Develop, keep updated, and follow plans for implementing selected process improvements.
Value
Enables 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
489
• 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.
Example Activities

Select performance improvements to be Select improvements to be deployed based on
deployed. their priority, 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 identified This should include identifying:
process improvements and review with • Tasks
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 needed. • Tasks
• 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 of Make process improvement accomplishments
the deployed improvements. and benefits visible and understandable to all
stakeholders.
Record improvement results. May include:
• Accomplishments
• Timeframe
• Effort and cost
490

• 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
• 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 cause of failures
• Effect on other processes and improvements

Estimating (EST)
Planning (PLAN)
491
Level 3
PCM 3.1
Practice Statement
Develop, keep updated, and use process improvement objectives traceable to the business
objectives.
Value
Ensures that process improvements focus on achieving business objectives.


Example Activities

Identify and record improvement
objectives.
Review improvement objectives Review improvement objectives to ensure traceability
with affected stakeholders. to business objectives. Traceability enables verification
that the improvement objectives contribute to meeting
Monitor and update improvement
objectives as needed.

Process improvement objectives
that are traced to business
objectives
492
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.


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, causal
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 Includes the tracing and mapping of processes and
relationships between the business objectives.
objectives and processes.
Estimate the value of each Consider the key capabilities that the business or
process’s contribution to achieving project is targeting to build or improve, and the
business objectives. primary processes that contribute to those capabilities.
493

Record, keep updated, and Results include identification of the processes that are
communicate the results to the major contributors to meeting objectives.

Business model, objectives, and Consider potential internal or external business
environment review results changes.
Recorded relationships and
traceability between the business
objectives and processes
Estimates of process contribution to Includes:
achieving business objectives • Priority of business objectives
• Measure of contribution of each process to meeting
the objective
• Interrelationships of processes and objectives to
each other
• Analysis results of how processes contribute to
meeting business objectives
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.

494

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. Competency analysis of
the workforce can assist in identifying and evaluating new processes, techniques,
methodologies, and tools.
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 workflow. 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
improvements. may include:
• Techniques
• Methods
• Process frameworks
• Objective evaluations
Use established criteria to decide Update these criteria as organizational needs change.
what documents and measures are Monitoring the evolution of new technology can help
critical enough to include in the identify new criteria for improvement.
organization’s Process Asset Library
(PAL) for use with other or future
projects.
Analyze and evaluate potential
process improvement opportunities.
communicate the results to
495

Potential improvement May include:
opportunities • New ideas and innovations
• Explanation of the ideas
• Potential impact on business objectives
• Initial cost versus 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
Senior management typically delegates the day-to-day process and improvement work to a
team or a dedicated part of the organization.
496
Example Activities

Identify the mechanisms needed to May include:
support process implementation and • User groups, e.g., communities of practice
deployment. • 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
sustainment of the process.
Provide a migration approach from current Approaches may vary depending on the
to newly deployed processes. criticality 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.
affected stakeholders They 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, Typically includes:
and sustaining improvement • Improvement requirements
• Deployment strategy
• Estimated budget, schedule, risks, etc.
• Updated vs. new processes
• Communication methods
497

• List of affected stakeholders
• Implementation expectations
• Migration from current to newly deployed processes
Implementation records

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 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 verifies 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
498
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.
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
processes and assets. deployment, 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
improvement efforts. groups, and organizational groups for each
improvement
• Coordinating activities for deploying related
improvements
Deploy the organizational set of Examples of methods for deploying improvements
standard processes and the include:
organizational process assets to • Deploying improvements incrementally rather than
identified projects. as a single deployment
• 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
improvements using deployment with the deployment plan.
plans.
Review results of objective This helps determine how well the organization’s set of
evaluations. standard processes has been deployed and how well
they are working.
Identify, record, and track to
closure issues related to
499

implementing the organization’s set
of standard processes.
Review the deployment results with
stakeholders.

List of where improvements of new Should include organizational processes and related
or revised processes or assets will process assets.
be deployed
Deployment status report May include:
• Description of the improvement and deployments
• Where, what, and how improvements are deployed
• 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 and report the effectiveness of deployed improvements in achieving process
improvement objectives.
Value
Ensures deployed processes are contributing to meeting process and performance improvement
objectives.

500

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 with affected
stakeholders.
Initiate and track to closure
necessary corrective actions.

Process improvement evaluation May include:
report • 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
501
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.
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
502

• Success criteria
Review validation plans with
Perform each validation in
accordance with the plan
and record results.
Use statistical or other Validation should include determining if objectives are being
quantitative methods to met.
analyze the results of the
validation.
Review, record and Reviewing and recording results of analysis typically involves:
communicate the results of • Reviewing results with stakeholders
validation analysis. • 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
503

PQA Overview
Intent
Verifies and enables improvement of the quality of the processes performed 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 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.
504
A typical project applying quality assurance will:

• 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 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 confirms 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
Agile Development
Ensure that objective evaluations are integrated into the team’s techniques or rhythms, e.g., as
part of daily standups, story point estimation, code reviews, use of tools, continuous
integration, and retrospectives.
An agile project 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 reviews prior accomplishments and identifies opportunities for
improvement for the next iteration
• Management or peers observe agile ceremonies being performed using techniques such
as a gemba walk
505
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.
506
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
507
Example Activities

Develop, record, and keep updated
the quality approach and plan.
Identify areas for evaluation.
Review, update, and approve the
approach with affected
stakeholders.

Quality assurance approach and Identify areas where the project lead would like
plan 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)
508
PQA 2.2
Practice Statement
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.


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
509
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.

Criteria
Checklists
Evaluation reports
Noncompliance reports
Context Specific
Data
of the solution.
Ensure objective evaluation of work products, e.g., criteria and requirements, to verify and
enforce objectivity, and to incorporate all aspects of managing data, e.g., consistent use of the
data glossary terms, data architecture.
510
Safety

Ensure objective evaluation of work products, e.g., criteria and checklists, incorporate all
aspects of safety activities, e.g., safety objectives, approach to address workplace environment
safety, approach to address functional safety, organizational safety function, safety evaluations,
and organizational safety controls.
Security

Ensure objective evaluation of work products, e.g., criteria and checklists, incorporate all
aspects of security activities, e.g., security objectives, approach to address security in the
workplace environment, approach to address physical security needs, mission security needs,
and cybersecurity.
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.
511
Example Activities

Communicate and resolve each Consider reporting a compliance percentage rather
noncompliance issue. than the 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.
Escalate noncompliance issues Escalation may continue through multiple layers of
when 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
Optimizes future quality assurance activities and reduces the cost of future work.

512

Example Activities

Record and keep updated Record information about quality assurance activities
information about quality assurance with enough detail to clarify status and results.
activities. Noncompliance issues recorded as part of the peer
review report are tracked and escalated outside the
project when necessary.

Evaluation records
Quality assurance reports
Status reports of non-compliance
issues and corrective actions
Reports of quality trends
513
Level 3
PQA 3.1
Practice Statement
Identify and record opportunities for improvement during quality assurance activities.
Value
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 kept updated. 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.

514

PI Overview
Intent
Integrates and delivers the solution that addresses functionality, performance, and quality
requirements.
Value
Increases customers’ satisfaction by giving them a solution that meets or exceeds their
functionality and quality requirements.

If Safety is included in the selected view: ensure safety requirements are addressed within the
relevant integration strategies, processes, documentation, and activities.
If Security is included in the selected view: ensure security requirements are addressed within
the relevant integration strategies, processes, documentation, and activities.
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.
515
PI 3.3 Evaluate integrated components for interface or connection compatibility.

Product integration activities include:
• Using recorded integration strategies and procedures
• 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.

Context Specific
Agile Development
Agile teams typically employ automation and may use DevSecOps 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.
Data
of the solution.
516
Incorporate data business rules into the product integration strategy, environment procedures,
criteria, and activities. For example, consider data aggregation, data cleansing, source data
optimization and prevention of data duplication, data conversions, data uploads to systems and
platforms, interfaces or connections, exception handling, data transport, data storage, data
archival or retirement, data sovereignty, and protections for data security and data privacy.
DevSecOps
DevSecOps teams typically employ automation to develop a build and deployment pipeline that
begins with Continuous Integration (CI) when a developer checks in code to source control,
after which automated builds and unit tests are run. Once integration is complete, automated
Continuous Delivery (CD) processes release the code into the test environment where
automated regression and system testing is performed to prepare the code for deployment.
Finally, CD refers to the ability to automatically deploy a developer’s changes from the
repository to production. It addresses the historic problem of manually transferring code to
operations teams that rely on and use mostly manual processes that slow delivery to the
customer. It builds on the benefits of CD by automating the last stage in the pipeline as
illustrated here. Refer to Figure PI-1: DevSecOps Approach.
Figure PI-1: DevSecOps Approach
517
Services
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.
518
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 Necessary information may include:
information to install and use • Configuration
the solution. • Solution component types and serial numbers
• Physical and functional layout
• Installation and tracking information
• Contact information
Use applicable methods to Documentation packaging and delivery methods may include:
package and deliver the • Hardcopy documents
solution. • CDs or DVDs
• Online help
• Cloud-based repository
• Ebooks
• Mobile applications
• Website links for downloads
Deliver the solution and
related documentation;
confirm receipt.
519

Assembled solutions and related
documentation
520
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:
• Integration and evaluation of solutions and components, e.g., as a single build or a series
of builds
• Management of interfaces or connections
• Establishment of the integration environment
• Recorded evaluation results

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 will This includes verifications and validations to
be verified and validated during integration. be performed on interfaces or connections.
Identify alternative integration strategies. Possible strategies include:
• Big bang
• Incremental
• Top-down
• Bottom-up
521

Select the best integration strategy. Align the integration strategy to availability of:
• Product components
• The integration environment
• Test tools and equipment
• Procedures and criteria
• People with the appropriate skills
Periodically review the product integration Ensure that changes in production and
strategy and revise it as needed. delivery schedules have not adversely
impacted the integration sequence.
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
Build pipeline A set of automated processes that allow developers to
compile, build, and deploy code to the target environment
throughout the lifecycle.
522

Selected integration strategy

Context Specific
DevSecOps
DevSecOps teams incrementally build an automated Continuous Integration / Continuous

Delivery (CI/CD) pipeline that spans initial build through automated releases. The integration
strategy is implemented through the scripts and tool chain, however there is an integration
architecture and pipeline set up that is defined before DevSecOps teams start configuring the
tools. The team needs to decide between multiple architectural options which often requires
formal decision-making. The goal is to reduce the risk of encountering integration issues that
occur when teams wait for the end of a milestone, initiative, or a Sprint to merge all the
developers’ code as soon as possible during development. The code is integrated, and any
integration is tested by automated test cases or sequences to look for an error. A primary
benefit of CI is that it saves time and cost during the development cycle by identifying and
addressing issues early. CI will also provide an opportunity to expose how well the built-in
security measures have been working or if more action needs to be taken. It also reduces the
time spent on bug fixes and regression by providing continuous feedback to the development
team, allowing them to take corrective action when the bugs are first identified.
Security

Ensure the integration strategy incorporates appropriate security controls and consideration of
third-party components. Ensure the strategy addresses:
• Level of automation
• Tool use
• Specification scope
• Disabling of services and removal of software that is not needed
• Consideration of threat scenarios
• Usage of adapted tooling to scrutinize moving perimeters and dynamics on a network
• Removal of unnecessary logins
523
• Changing of default passwords and logins at specified periods, e.g., release, deployment,
installation, decommissioning
Consider the following configuration hardening challenges when addressing the integration
strategy:
• Identifying hardening settings based on threat scenarios and intended functionality. In
solutions, intended functionality determines the services, ports, and interfaces or
connections that are redundant or unnecessary and thus how hardening may be achieved.
• Multiple configuration settings and details
• Heterogeneous, complex, or user-hostile interfaces or connections and vulnerabilities that
could have been introduced through design or automation
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 build,
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.
524
Example Activities

Develop requirements for the
integration environment.
Develop verification and validation This is for validating the integration environment and
procedures and criteria for the not for 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 This can be the whole environment or just parts of it.
reuse 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
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 Dispose of integration environment parts that are no
as needed. longer useful.
Communicate with affected
stakeholders.

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

525
Context Specific
DevSecOps
A Continuous Integration (CI) environment consists of four key elements:

• CI Tool Solution: Development teams use CI tools to automate parts of the build and to
develop a recorded development process. When selecting a CI software solution,
consider:
o On-premises or hosted
o Supports containerization
o Ease of use
o Security
• Tools: In DevSecOps, a continuous and automated delivery cycle is critical to making fast
and reliable delivery possible. This requires proper Continuous Integration / Continuous
Delivery (CI/CD) tools. A CI/CD tool solution needs to leverage a team’s workflow to best
leverage the automation feature and develop a reliable CI/CD pipeline. It also needs to
integrate with continuous testing software.
• Version Control System: The version control system, or source control repository, records
and manages changes to files and folders. It records the history of changes and enables
retrieval of previous versions, if needed. The version control system allows different
developers to work on their own branch, resolve editing conflicts, and then merge the
code.
• Hosting Environment: Virtual Machine (VM), Container, and Version Control System
o Virtual Machine: A VM runs a guest operating system on a host computer. VMs behave
like a single computer with its own disk(s), memory, and video card, and behave as if
it has its own dedicated resources. Having multiple operating systems enables each
server to run many virtual desktops on a small number of physical servers. VMs
provide businesses with significant cost savings and scalability to expand capacity as
the company, systems, and amount of data grows.
o Container: By comparison, containers run on the host server and its operating system.
A runtime system supports the containers. Each container shares the host’s system
kernel and its shared libraries. Containers are protected from conflicts because the
runtime shares components as read-only. If containers need to communicate, they use
the network.
526
o Which is better: VMs or containers? It depends on the need of the organization and its
customers. Containers work well for running individual applications, not entire
operating systems. Instead of installing an application on the host, a container is run
that contains everything the application needs. Containers do not need host resources
like a VM does and are lightweight in terms of setup, maintenance, and use as
compared to a virtual machine. Containers also have less overhead when compared to
servers or VMs. VMs share a common operating system, so maintenance is simplified
to patches and bug fixes. Although containers use a variety of different operating
systems for their apps, they are self-contained and require less maintenance.
However, since only VMs can act like complete systems, in some situations, VMs are
the only option.
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
• 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
527
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.
Develop, use, and keep updated
criteria for product component
integration and evaluation.
communicate the product
integration procedures and criteria.

Product integration procedures
Product integration criteria
Context Specific
DevSecOps
Continuous Integration (CI) follows this basic process:

• A developer commits code to the version control repository
• The CI server on the integration build machine periodically polls the source code
repository for changes. After a commit, the CI server checks for changes that may have
occurred in the version control repository.
• The CI server retrieves the latest version of the code from the repository and then
executes a build script, which integrates the software
• The CI server then emails the build results to assigned development team members
• Automated unit tests are then performed if the build succeeds. If the tests are successful,
the code is ready to be deployed to either the staging or the production server.
• The CI server continues to poll the source code repository for updates and the process
repeats
528
PI 2.4
Practice Statement
Confirm, prior to integration, that each component has been properly identified and operates
according to its requirements and design.
Value
Reduces 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
connections before integrating basic counts of interfaces or connections.
product components.
529

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.

Context Specific
DevSecOps
Development teams build their integration criteria into their CI/CD pipeline using scripts and a
sequence of automated tests. Often, teams use CI tools in a sub-optimal manner by creating
environment-specific commands. This approach limits the team to one tool and makes it more
difficult to migrate to a different tool set. Ideally, teams write environment agnostic scripts and
commands. This minimizes the dependence on a single CI environment and allows the team
greater flexibility.
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.

530

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 Example results include:
evaluation 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

531
Context Specific
DevSecOps
In a Continuous Integration (CI) environment, a successful build indicates initial verification of

the requirements. DevSecOps culture adopts the “shift left” testing approach, which means
pushing the testing to the left or into earlier steps of the development process. This culture
results in identifying and removing defects early in the lifecycle, improving quality more cost
effectively. With this “shift left” approach, testing typically begins when development starts
including security testing to identify vulnerabilities and spans the lifecycle, resulting in the
integrated solution.
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 Record all appropriate component information.
the product integration strategy,
procedures, and criteria.
532

Update the product integration
strategy, procedures, and criteria
as needed.
Integrate and deliver the product Integration and delivery should address requirements
and communicate results. for:
• 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
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
Context Specific
DevSecOps
DevSecOps teams use their Continuous Delivery (CD) pipeline where automated builds, tests,
and deployments are orchestrated as one release workflow. Pipelines have software gates that
automatically promote or reject versioned components. If the release protocol is not met, the
pipeline aborts. Alerts are generated and notifications are sent to the DevSecOps team for
remediation.
533
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, kept updated, 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.
534
Example Activities

Review with affected stakeholders Interfaces or connections are usually classified in three
and keep updated interface or main classes:
connection descriptions for • Environmental
coverage, completeness, and • Physical
consistency throughout the • Functional
product’s life.
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

535
Context Specific
DevSecOps
Understanding system impact is essential to DevSecOps. For example, when applications are
built on service-oriented architectures, requirements for one feature may include other system
dependencies. Dependency requirements typically take two forms: 1) changes with a potentially
negative impact on another part of the application, 2) changes with a dependency on some
other part of the application before the feature can be implemented.
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 Logbooks and instructional signage are examples of indirect person-to-person
• 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
536
• 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 or connections
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.


Example Activities

Compare interface or connection This comparison may include:
descriptions with component • Performing a pre-check of all the physical interfaces
or connections before integrating components
537

interfaces or connections and • Performing a functional review of external
identify non-compliances. 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
Context Specific
DevSecOps
As the code moves through the Continuous Integration (CI) process, a series of automated unit
tests are conducted. When using a CI server, eventually a build fails on the CI due to
differences in the environment but passes on the development machine. When this happens,
the configuration issues, language version, package installation, memory limitations, test user
permissions, etc., from the passed tests are eliminated systematically and the issue is narrowed
down to what has changed recently with the build, and any unmet integration requirement is
identified and resolved.
Services
538
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.
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 Compatibility may include:
components 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
539

Interface or connection issues
reports
Context Specific
DevSecOps
CI requires automated unit and integration tests. These tests must be comprehensive enough
so that teams have confidence that the software works as expected, vulnerabilities are
identified and fixed, and meets the requirements. The unit tests must run quickly so that they
do not delay development when check-in occurs. Complex automated tests are typically run
overnight so that developers have the results the next day and can be discussed. The tests
must be run frequently and be kept updated. If the tests are run infrequently, then a test
failure can originate from many different changes, making it much harder and more expensive
to debug and more complicated to keep updated.
Creating maintainable sets of automated unit tests is difficult and complex. An effective way to
solve this problem is to practice Test-Driven Development (TDD), where developers write
automated tests that initially fail, until they implement code that makes the tests pass. TDD
helps ensure developers write code that is modular and easy to test, which reduces the
maintenance of the resulting automated test suites.
Services
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.
540
Requirements Development & Management (RDM)

RDM Overview
Intent
Elicits requirements, confirms common understanding by stakeholders, and aligns requirements,
plans, and work products.
Value
Increases likelihood that the solution meets or exceeds customer expectations and needs.

Practice Summary
Level 1
RDM 1.1 Record requirements.
Level 2
RDM 2.1 Elicit stakeholder needs, expectations, constraints, and interfaces or
connections, and confirm understanding of the requirements.
RDM 2.2 Transform stakeholder needs, expectations, constraints, and interfaces or
connections into prioritized customer requirements.
RDM 2.3 Obtain commitment from project participants that they can implement
the requirements.
RDM 2.4 Develop, record, and keep updated bidirectional traceability among
requirements and activities or work products.
RDM 2.5 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.
541
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
• Scalability
542
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
Agile Development
Agile teams elicit user needs as a backlog of user stories, but a backlog does not typically
include constraints, interfaces or connections, and quality attributes.
Table RDM-1: Typical Agile Requirements Activities shows where requirements activities can
augment a typical agile project.
Table RDM-1: Typical Agile Requirements Activities

Agile Activities Purpose
Release planning Obtain earlier and more complete understanding of the solution and
risks.
Backlog Conduct broader and deeper analysis of user stories or epics to
grooming/review discover potential issues or constraints. Additionally, these analyses
identify risks or opportunities.
Sprint planning Present stories by the product owner, review acceptance by the
team, and estimate the user stories to be delivered during the
upcoming Sprint.
Sprint execution Implement the user stories agreed to during Sprint planning.
543

Sprint review/demo Gain a more thorough understanding of what has been
accomplished during the Sprint.
Sprint retrospective Conduct collaborative sessions where the agile team’s culture,
process, and performance is reviewed.
Agile projects typically 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 user
stories or epics and work products. Traceability also improves the ability to understand and
addresses what is impacted by a user story or epic change.
Data
of the solution.
Ensure data requirements and business rules, e.g., security rules; physical and logical data;
prioritized data quality dimensions for databases, software, and technology; are recorded as
requirements, reflected in business terms, traceable to business objectives, and meet legal and
regulatory requirements. Analyze data requirements based on business objectives and priorities.
Evaluate the criticality of data within scope against high-priority business objectives according
to the primary purpose, e.g., regulatory reporting. Include customer feedback in the analysis to
determine if there are implied or unstated business objectives that may be important to
accommodate. Identify, track, and manage critical data elements.
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.
Security

Determine security needs by addressing and analyzing inputs from various sources, as derived
from:
• Security needs of affected stakeholders
544
• Results of security and threat assessments

• Threat intelligence analysis
Collect inputs for security requirements from stakeholders, consolidate inputs, analyze the
intended operational environments, and resolve conflicts.
Security sources may include:
• Country or region-specific regulations and laws, e.g., personal data protection, export
controls, General Data Protection Regulation (GDPR)
• Request for Proposal (RFP), solicitation, or feature requests
• Solution security risk assessments
• Development of misuse and abuse use cases
• Organization internal protection goals, e.g., intellectual property protection and licensing
regulations
• Security activities of competitors
• Analysis of existing or future threats by using vulnerability databases, e.g., Common
Weakness Enumeration List; and SysAdmin, Audit, Network, Security (SANS) TOP 25 Most
Dangerous Software Errors
• Security topics with high customer profile
• Analysis of security incidents in own or comparable systems
• Organizational security baselines and policies
Refer to Table RDM-2: Security External References for more information.
Table RDM-2: Security External References

Cybersecurity Standards of the North American https://www.nerc.com/pa/Stand
Electric Reliability Corporation [NERC 2011
series]
Health Insurance Portability and Accountability https://www.hhs.gov/hipaa
Act (HIPAA) [US 1996]
Health Information Technology for Economic https://www.asha.org/Practice/reimburse
and Clinical Health Act (HITECH) [US 2009] ment/hipaa/HITECH-Act
Embedded Device Security Assurance https://www.isasecure.org/en-US/News-
Certification Specification [ISCI 2010] Events/ISCI-Publishes-ISASecure-EDSA-
Certification-Specif
Security Requirements for Vendors of the http://osgug.ucaiug.org/conformity/securit
International Instrument Users’ Association WIB y/Shared%20Documents/WIB%20M2784
[WIB 2010] %20PCS%20VendorSecurity%20v2.pdf
System security requirements and security https://www.isa.org/isa99
assurance levels of the ISA99 Committee [ISA
2011]
545

Common Criteria for Information Technology https://www.commoncriteriaportal.org/file
Security Evaluation [CCMB 2009] s/ccfiles/CCPART1V3.1R3.pdf
PCI Security Standards Council (SSC) Data https://www.pcisecuritystandards.org/doc
Security Standard [SSC 2010] ument_library?category=pcidss&subcatego
ry=pcidss_supporting#results
Services
Analyze all stakeholder requirements while developing the service delivery and operational
agreement, approach, and objectives 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
or connections, 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. Service delivery,
operations, and system requirements are monitored throughout the service delivery and
lifecycle.
Suppliers
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.
546
Level 1
RDM 1.1
Practice Statement
Record requirements.
Value
Addresses 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 (SOW)
• Use cases
547
Level 2
RDM 2.1
Practice Statement
Elicit stakeholder needs, expectations, constraints, and interfaces or connections, and confirm
understanding of the requirements.
Value
Ensures a deeper mutual understanding of the requirements and increases the likelihood that
the customer will be satisfied.

Develop and use criteria for identifying appropriate requirements providers.
Develop and use criteria for the evaluation and acceptance of requirements.

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 are addressed.
In order to understand customer needs and expectations, it is important that people who
implement and test solutions against the requirements analyze them with the provider. This is
done 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 by using recorded
evaluation and acceptance criteria.
Evaluation and acceptance criteria are needed to verify and validate that requirements are:
• 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
548
• Traceable to source
• Achievable
• Tied to business value
• Identified as a priority by the customer
Evaluation and acceptance criteria can prevent:
• Inadequate verification
• Costly rework
• Customer rejection
Example Activities

Develop criteria for
identifying appropriate
requirements providers.
Develop criteria for the
evaluation and acceptance of
requirements.
Elicit stakeholder needs, Identify additional requirements not explicitly provided by
expectations, constraints, stakeholders.
and interfaces or Techniques to elicit needs include:
connections.
• Technology demonstrations
• 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
Record and analyze
stakeholder requirements to
549

ensure that established
criteria are met, and keep
them updated.
Obtain understanding of and
commitments to
requirements with the
requirements providers and
the project participants.

Lists of agreed upon and
authorized requirements providers
Criteria for evaluation and
acceptance of requirements
Results of analyses against criteria
List of stakeholder needs, This may be provided by draft stakeholder
expectations, constraints requirements.
List of interfaces or connections Interfaces or connections may include:
• Links
• System
• Human
• Relationships
• Interactions
• Interdependencies
Recorded changes to requirements
Set of approved requirements Reflects the shared understanding between the project
and the customers.
Context Specific
Safety

Analyze requirements from the perspective of safety considerations. For example, the analysis
may include a review of subsystem interrelationships for:
• Compliance with specified Environment, Safety, and Occupational Health (ESOH) design
criteria
550
• Possible independent, dependent, and simultaneous hazardous events, including system

failures, failures of ESOH devices, common cause failures and events, and system
interactions that could develop into a hazard or increase risk
• Degradation of a subsystem or the total system affecting ESOH
• Design changes affecting subsystems
• Effects of reasonable human errors
• The method of implementing hardware, software, and facilities/installation design
requirements and corrective actions that have not introduced any new hazards or
negatively impacted ESOH-related aspects of the system
RDM 2.2
Practice Statement
Transform stakeholder needs, expectations, constraints, and interfaces or connections into
prioritized customer requirements.
Value
Ensures customer priorities are addressed to minimize the cost of rework during acceptance and
maximize customer satisfaction.

If Safety is included in the selected view: Consider, define, and prioritize product or service
system safety requirements throughout the solution lifecycle for any systems, new
development, upgrades, modifications, or resolution of incidents and deficiencies. Identify,
define, and flow down solution safety requirements to the supply chain, as appropriate.
If Security is included in the selected view: Consider, define, and prioritize solution security
requirements throughout the solution lifecycle for any supporting systems, new development,
upgrades, modifications, or resolution of incidents and deficiencies. Identify, define, and flow
down solution security requirements to the supply chain, as appropriate.

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 non-technical descriptions. Solution and contractual
requirements are the expression of these requirements in more explicit technical terms that can
be used for design decisions.
551
Sources for requirements include:

• Customer provided input
• Stakeholder provided input
• Approved personnel positions and job descriptions, including any staff augmentation
requirements
• Previous efforts
• Existing solution systems
• Domain literature
• Laws and regulations
• 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
• Non-technical 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.
552
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
• 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
expectations, constraints, and requirements include:
interfaces or connections into • Key characteristics of the desired capability
recorded customer requirements. • Alignment to high priority business objectives, e.g.,
regulatory reporting
• Obstacles to overcome to achieve the capability
• Competitive gap between the existing and the desired
capability
• Supportability of the desired capability
• Needs and constraints of managing data
Requirements should not specify or constrain design
decisions without careful consideration.
Develop, record, and keep Prioritized customer requirements help to determine
updated a prioritization of project, iteration, or increment scope. This prioritization
customer requirements. verifies that functional and quality attribute requirements
critical to the customer and other stakeholders are given
the highest visibility and attention.
553
Work Products Further Explanation

Prioritized customer requirements
Customer constraints May include constraints related to:
• Design
• Verification
• Validation
Context Specific
Data
of the solution.
Record data interface or connection specifications following established criteria and processes
for shared data, including traceability from creation through consumption, by all sources within
scope.
Safety

Requirements help identify and define all known hazards and their associated risks and enable
the elimination or reduction of safety risks to acceptable levels. Consider outcomes from safety
evaluation activities when identifying safety requirements. Establish traceability of safety
requirements to related hazards. Set a safety target for each safety requirement. For example,
the safety target should ensure the product’s risk is less than or equal to the acceptable risk,
based on the minimum acceptable safety tolerance limits. Ensure the safety target and product
risk information are carried forward into product design. Identify specific system safety
engineering requirements in the system specification including risk assessment and mitigation,
fault tolerance, acceptance, unique classifications and certifications, or any unique mishap
reduction needs, e.g., detection, isolation, annunciation, and recovery.
RDM 2.3
Practice Statement
Obtain commitment from project participants that they can implement the requirements.
Value
Ensures commitments are well understood to minimize delays and rework.
554


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 Negotiate commitments before work starts
commitments.

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
Safety

Perform a safety impact analysis at any point within the solution lifecycle when requirements
change. Some safety groups and standards call these impact analyses System Hazard Analysis
(SHA). They are used to verify system compliance with Environment, Safety, and Occupational
Health (ESOH) requirements contained in system specifications and other relevant documents.
The impact analysis report includes system information for the solution, with hazard analysis
results incorporated, as appropriate. Contents and formats of the hazard information may vary
according to the individual requirements of the program. The detailed content for hazard
analysis results may include:
• Summary of the analysis results
555
• A listing of identified hazards, such as:

o Lifecycle phases affected by the hazard
o Causal factor, e.g., hardware, software, and human
o Effects of the hazard
o Initial risk category and associated attributes
o Mitigation strategies
o Hazard status, e.g., open or closed
o Hazard traceability (running history of actions taken or planned with rationale to
mitigate and risks)
Suppliers
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.4
Practice Statement
Develop, record, and keep updated 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 confirms that:
• Requirements have been completely addressed in customer deliverables
• Lower-level requirements can be traced to a valid source
• Requirements are implemented
556
• Selected requirements are verified and validated

• 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
bidirectional requirements intervening work products to the customer deliverable.
traceability.

Records of bidirectional Consider project tasks or product backlogs, and their
requirements traceability traceability to user requirements.
Context Specific
Safety

Ensure requirements incorporate safety requirements, as based on the results of hazard

identification, hazard analysis, and risk assessment. Ensure safety requirements are traceable to
the related hazard.
Services
557
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.
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.
Suppliers
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.5
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.


558
Example Activities

Review plans, activities, and work Maintaining bidirectional traceability is critical to
products for consistency with maintaining consistency between requirements,
requirements and changes made to them. work products, and plans.
Record inconsistencies and their sources. Identify any changes that should be made to
plans and projects resulting from changes to the
requirements.
Initiate and record any necessary
corrective actions and communicate
results to affected stakeholders.

Records of inconsistencies between
requirements, plans, and work products
Corrective actions
559
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.
bidirectional traceability.
Review requirements for potential
impact to architecture and design.
prioritization of requirements.
nontechnical requirements.
Identify, record, and keep updated
requirements for external and
internal interfaces or connections.
560

Requirements May include:
• Solution requirements
• 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.
RDM 3.2
Practice Statement
Develop operational concepts and scenarios.
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
561
An operational concept can also provide:

• A view of the system or product from the user perspective
• A context for developing or evaluating a set of scenarios
• A description of personnel alignment to manage and support service delivery
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
operational concepts and scenarios. level of 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
RDM 3.3
Practice Statement
Allocate the requirements to be implemented.
Value
Increases customer satisfaction by delivering a complete solution that meets requirements.
562


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 include dependencies in which a change
relationships among allocated in one requirement can affect other requirements.
requirements.
Review requirements allocations
and relationships with affected
stakeholders.

Requirement allocations
Context Specific
Suppliers
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.
563
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. In an environment where staff
augmentation is part of the solution, interfaces and connections can include personnel
interactions, mechanisms, and communications.
Example Activities

Identify, record, and keep As the design progresses, the architecture will be altered
updated internal and external by technical solution processes, developing new
interface or connection interfaces or connections between internal components
requirements. 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
564

• Resolving conflict, non-compliances, and change issues
Review interface or connection Review the interface or connection descriptions with
requirements for coverage and affected 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 May include:
requirements • 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 or connections in terms such as:

• Software
o Origination
o Destination
o Stimulus
o Data characteristics
o Communication interfaces, e.g., protocols such as HTTP, FTP
565
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
566
Example Activities

Perform a requirements Analyze requirements to ensure they are:
analysis to determine if • Relevant
requirements are necessary • Complete
and sufficient. • 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.

567

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
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

Develop and keep updated a This definition can include descriptions, breakdowns,
definition of required functionality and categorizations of the functions.
and quality attributes. A clear understanding of the quality attributes and their
importance based on business objectives or needs is
essential to the design process.
Analyze requirements to ensure Analysis includes use of:
that they balance stakeholder • Models
needs and 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
568

Review, analyze and negotiate
requirements tradeoffs with
customers and stakeholders.
Record and keep updated proposed
requirements changes and
communicate with affected
stakeholders.
Validate requirements to ensure the
resulting service system will
perform as intended in the end
user’s environment.

Operational concepts and This may include:
scenarios, use cases, activity • Required functionality and quality attributes
diagrams, and user stories • Architectural concepts
• Operational and maintenance concepts, e.g.,
installation, training, disposal
Analysis methods and 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.
569
Suppliers
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.


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,
techniques. use multiple validation techniques such as:
• Functional analysis
• Simulation
• Prototypes
• Demonstrations
• Tests
• Reviews or walk-throughs
570

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

571

RSK Overview
Intent
Identifies, records, analyzes, and manages potential risks or opportunities.
Value
Mitigates adverse impacts or capitalizes 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
572
• Identifying and leveraging potential positive impacts for improving performance or

progress towards achieving objectives
• All levels of an organization
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
Agile Development
As an empirical framework, agile, does not define practices and processes for risk and
opportunity management. Risk and opportunity management is performed using 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.
573
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 Identify and clearly describe risks that could negatively
the work. affect 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.
574

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
• 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 Include context, conditions, and consequences of risks
opportunities or benefits of opportunities.
575
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
576

Review the Work Breakdown
Structure (WBS), plan, and
schedule for risks.
Identify the impact of each risk.
Identify the probability of
occurrence for each risk.
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 WBS, 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
577
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.


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 Risks or opportunities may be revised when:
opportunities as additional • New risks or opportunities are identified
information becomes • Corrective or leveraging actions are taken
available. • Risks are retired
• Opportunities are accepted
• Circumstances change significantly
Communicate the risk or Examples of risk or opportunity status include a change in the:
opportunity status to • Probability of occurrence
affected stakeholders. • Costs or benefits
• Priority
• Impact on objectives

Records of risk or opportunity monitoring
Updated risks or opportunities
578
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 Consider internal and external categories, such as:
categories. • 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
according to defined categories. organized for efficient handling.
579

Categories list
Categorized risks or opportunities
RSK 3.2
Practice Statement
Define and use parameters for risk or opportunity analysis and handling.
Value
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.
580
Example Activities

Identify a relative priority for each
risk or opportunity based on
assigned parameters.
Define thresholds to trigger actions Identify which thresholds require a:
for selected risks or opportunities. • Mitigation activity
• Contingency plan
• Opportunity action plan
Prepare and perform assessments Risk assessments focus the components of the risk
for selected risks. strategy 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
Context Specific
Safety

Identify potential hazards associated with any subsystem interfaces and faults. Assess the risk
associated with an integrated system design, including software and subsystem interfaces.
Leverage safety functional groups to assess the severity and probability of safety risks
associated with each identified hazard to determine the potential negative impact of the hazard.
For example, consider potential impacts to:
581
• Personnel
• Facilities
• Equipment
• Operations
• Public
• Environment
• System or solution
If safety risks increase beyond tolerance limits, then identify short-term and long-term actions
to reduce the risk to an acceptable level. Depending on the product and hazard scenario, this
may take the form of operational limitations, usage restrictions, in-service tests/inspections, or
design/manufacturing changes.
RSK 3.3
Practice Statement
Develop and keep updated a risk or opportunity management strategy.
Value
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
• Thresholds
• Risk mitigation techniques
• Opportunity leveraging techniques
• Risk measures
• Opportunity measures, including:
o Costs
o Benefits
• Frequency of risk monitoring or reassessment
582

Develop the strategy early and record it in the organization’s or project’s risk or opportunity
management plan. Keep the strategy updated 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 and opportunity
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
RSK 3.4
Practice Statement
Develop and keep updated risk or opportunity management plans.
583
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 (PoP) for each risk and opportunity management
activity
• Resource reserves to respond to disruptive events
• Lists of available backup equipment
• Backups to key personnel
• Plans for testing emergency response systems
• Posted procedures for emergencies
• Distributed lists of key contacts and information resources for emergencies
• Actions to be taken
584
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 replanning 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)
585
Context Specific
Safety

Evaluate identified safety risks and consider appropriate mitigations:

• To address the minimum safety tolerance limit as defined by requirements and the system
user or customer
• To ensure compliance with laws, e.g., country, federal, and state where applicable,
regulations, executive orders, treaties, and agreements
Following initial hazard identification, identify risk mitigation strategies and evaluate the
expected effectiveness of each alternative or method. Risk mitigation is often an iterative
process for eliminating or reducing risk to the lowest acceptable level within the constraints of
operational effectiveness and suitability, time, and cost.
Collect information and data needed to conduct a mitigation analysis. For example, perform a
Preliminary Hazard Analysis (PHA) to conduct an initial safety risk assessment of a concept or
system. The analysis should include consideration of the following concepts:
• Hazardous components, e.g., fuels, propellants, lasers, radio transmitters, explosives,
toxic substances, hazardous construction materials, pressure systems, and other energy
sources
• Interface considerations among various elements of the solution or system, e.g., material
compatibilities, electromagnetic interference, inadvertent activation, fire/explosive
initiation and propagation, and hardware and software controls; and to other systems
when in a network or system-of-systems architecture
• Operating environment constraints, e.g., drop; shock; vibration; extreme temperatures;
noise; exposure to toxic substances; health hazards; fire; electrostatic discharge;
lightning; electromagnetic environmental effects; and radiation, including ionizing, non-
ionizing, laser, and radio-frequency
• Process constraints for operations, tests, maintenance activities, diagnostics, and
emergency procedures. Other considerations include:
o Environmental impacts
o Human factors engineering
o Human error analysis of operator functions, tasks, and requirements
o Effect of factors such as equipment layout, lighting requirements, potential
exposures to toxic materials, and effects of noise or radiation on human
performance
o Explosive ordnance render-safe and emergency disposal procedures
o Life support requirements and safety implications in manned systems, including
crash safety, egress, rescue, survival, and salvage
586
• Developed infrastructure, property, installed equipment, and support equipment, e.g.,

provisions for storage, assembly, and checkout; proof testing of hazardous
systems/assemblies that may involve toxic, flammable, explosive, corrosive, or cryogenic
materials or wastes; pollution, radiation, or noise emitters; and electrical power sources
• Natural infrastructure, e.g., land use, water resources, air quality, geology and soils,
biological resources, cultural resources, hazardous materials, solid and hazardous waste,
environmental noise, and aesthetic and visual resources
• Environment, Safety, and Occupational Health (ESOH) controls, safeguards, and possible
alternate approaches, e.g., interlocks; system redundancy; fail safe design considerations
using hardware or software controls; subsystem protection; fire detection and suppression
systems; personal protective equipment; heating, ventilation, and air-conditioning; noise
or radiation barriers; and pollution control equipment
• Malfunctions of the system, subsystems, or software; specify each malfunction, determine
the cause-and-result sequence of events, assess the hazard, and develop appropriate
specification or design changes
When identifying mitigations, consider and assess the likelihood of potential hazards leading to
accidents, and the associated impact.
The likelihood may be assessed qualitatively, e.g., frequent, rare, or extremely rare; or
quantitatively, e.g., 1 occurrence in 10 years, 1 occurrence every 10,000 operations, or 1
occurrence every 100 missions. A quantitative measure of the likelihood of a potential accident
is based on the analysis of the hazards for which that accident is a possible consequence.
When systematic failures are seen as contributing to the likelihood of an accident, e.g., where
software failures may cause the accident, quantitative analysis is generally seen as
inappropriate. Instead, the process is often reversed to set safety targets for system failure
rates.
Suppliers
Consider all risks in planning activities. Identify risks or opportunities 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.
587
RSK 3.5
Practice Statement
Manage risks or opportunities by implementing planned risk or opportunity management
activities.
Value
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 Continue to manage risks or opportunities after mitigation,
using the risk or opportunity contingency, or leveraging activities have started.
management plans. Measurement can provide valuable insight into the risk or
opportunity management activities.

Updated status Includes status of mitigation, contingency, and leveraging
plans.
588

SDM Overview
Intent
Delivers services and manages the service delivery system.
Value
Increases 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
If Safety is included in the selected view: ensure the service system addresses and is consistent
with all relevant safety related requirements and considerations.
If Security is included in the selected view: ensure the service system addresses and is
consistent with all relevant security related requirements and considerations.
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.
589
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.

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)
590
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
591
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
592

• Customer based: Organize the service agreement around
a customer; this can cover several services for that
customer
Define, negotiate, obtain
commitment to, and
communicate status of the
service agreement.
Provide the service agreement Affected stakeholders may include:
to 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

593
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.

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
supports 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
594
Example Activities

Receive service requests and
ensure each request is within the
scope of the service agreement.
Record information about the Service request information may come from:
service 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.
Determine the actions to satisfy the Using the categories developed in the approach to
service request. service 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 Record, track, transfer as necessary, and close the
requests until personnel fulfill request status.
requests described in the service
agreement.
Review service request status and In organizations that use a help desk function, the help
confirm results with affected desk communicates the status of service requests.
stakeholders.
Close the service request and Record actions to support satisfying similar service
record the actions taken and requests in the future.
results.
Collect customer satisfaction
information after delivery of
services.
595

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
Records of affected stakeholder
reviews

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 deliver 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.
596
Example Activities

Operate service system
components according to service
system procedures.
Perform operations support These activities can include providing customer and
activities. end user training or orientation as needed.
Perform the activities needed to
fulfill service requests.
Use a request management system The service provider records and tracks status until
to record service requests. they 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

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.
597

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 Sources include:
needs and service provider • Customer and end user feedback
concerns. • Service provider inputs
• Historical data
• Market analysis and demand
• SOW and related solicitation materials
• Support process information
• Service system
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
598

data, supplier agreements, and • Requested service requirements against standard
related service data. service definitions
• 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)
SDM 2.5
Practice Statement
Develop, record, keep updated, and follow the approach for operating and changing the service
system.
599
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
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.
600
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
and each change. approach. 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
resources, and schedule work and available resources against customer and end user
required for operation of needs, including the need to have time to prepare for and
the service system and conduct the change. When appropriate, use actual data from
for a new change. similar changes to estimate cost, resources, and schedule.
Identify affected When identifying affected stakeholders and defining their roles
stakeholders and review and responsibilities, consider outsourced stakeholders.
operations and change
activities.
Develop a plan for Based on the operations, change, and deployment approach and
service system estimates for a transition, record a plan for operations and
operations and for changes to the service system.
changes to operations.
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)
601

Planning (PLAN)
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. In an environment where
staff augmentation is part of the solution, recruiting and hiring personnel should be considered
for confirming readiness.
Example Activities

Confirm that service system Service system components may include:
components and tools are • Tools
operational. • 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
602

Evaluate the results of confirming The service provider may treat deficiencies or issues as
service system component service incidents and address them through the
readiness and determine how to incident handling process.
address 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 delivery needs. Changes of service system
components, e.g., archival, incorporation of new
components, often require updates to procedures.
Ensure that the necessary Service delivery activities and tasks can include:
resources are available for • Operating, monitoring, and repairing service system
performing service delivery components
activities and tasks. • 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
requested. personnel
• 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 affected
stakeholders.
Provide orientation or training to Orient incoming personnel, e.g., new hires, at a shift
incoming service delivery and change, on the current state of operations and pending
support personnel. transition activities to ensure uninterrupted service.

Readiness reports These reports may include:
• Monitoring thresholds
• Operating procedures
• Personnel
• Consumables
Logs of consumable acquisition and use
603

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

604
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 depend 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.
605
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 keep updated 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

606

STSM Overview
Intent
Develops and deploys 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
service descriptions 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.
607
Develop standard services through:

• Active analysis of customer and competitor data
• 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 keeps updated. 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 keep updated 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.

Requirements Development Management (RDM)
608
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
609
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
service descriptions updated. services.
Develop, record, and keep the The service catalog contains all the individual service
service catalog updated. descriptions and related material.

Individual service descriptions
Service catalog or menu

610
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
• Scenario planning
611
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 Include external and internal factors.
strategic 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
612
• External service supplier requirements

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
available when needed. the 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
613

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

Governance (GOV)
Planning (PLAN)
614
Level 3
STSM 3.1
Practice Statement
Develop, keep updated, and use the set of organizational standard service descriptions 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
standard service descriptions. models. Organize services into service lines as
needed to ensure appropriate integration among
services.
Specify the characteristics of each These may include definitions of standard service
service. levels.

Descriptions of services and their Critical characteristics typically include:
characteristics • Features and benefits
615

• 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
Standard service catalog or menu The catalog typically contains tailoring guidelines for
standard services and descriptions of services lines
if needed.

616
Supplier Agreement Management (SAM)

SAM Overview
Intent
Selects qualified suppliers, establishes agreements, and manages the resulting supplier and
acquirer activities over the term of the agreement.
Value
Maximizes the probability of mutual success for acquirers and suppliers.

If Data is included in the selected view: Identify data-related considerations, e.g., privacy, data
quality, to be included in the supplier agreement.
If Safety is included in the selected view: Identify hazard and safety-related considerations,
e.g., functional safety, to be included in the supplier agreement.
If Security is included in the selected view: Identify security-related considerations, e.g.,
physical security, database and information access, background checks, personnel clearances,
to be included in the supplier agreement.
Practice Summary
Level 1
SAM 1.1 Identify, evaluate, and select suppliers.
SAM 1.2 Develop and record the supplier agreement.
SAM 1.3 Accept or reject the supplier deliverables.
SAM 1.4 Process supplier invoices.
Level 2
SAM 2.1 Identify evaluation criteria, potential suppliers, and distribute supplier
requests.
SAM 2.2 Evaluate supplier responses according to recorded evaluation criteria and
select suppliers.
SAM 2.3 Manage supplier activities as specified in the supplier agreement and
keep agreement updated.
SAM 2.4 Verify that the supplier agreement is satisfied before accepting the
acquired supplier deliverable.
617
SAM 2.5 Manage invoices submitted by the supplier according to the supplier
agreements.
Level 3
SAM 3.1 Conduct technical reviews of supplier performance activities and selected
deliverables.
SAM 3.2 Manage supplier performance and processes based on criteria in the
supplier agreement.
Level 4
SAM 4.1 Select measures and apply analytical techniques to quantitatively manage
suppliers against their performance targets.

Supplier management activities involve:
• Selecting qualified suppliers
• Establishing the supplier agreement
• Implementing the supplier agreement
• Monitoring supplier technical activities
• Monitoring supplier processes and performance
• 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
The term “supplier deliverable” refers to an item to be provided to an acquirer or other recipient
as specified in an agreement. The deliverable can be a document, hardware, software,
services, or any type of solution or work product.
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
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 deliverable
• Analyzes the development and implementation of the supplier’s technical deliverable to
confirm technical progress and satisfaction of contractual requirements
618
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 relevant processes, such as
requirements management, risk and opportunity 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 needs to ensure that changes to requirements and supplier
agreements are acceptable given the constraints of the acquisition.

Context Specific
Security

Consider the following when managing agreements with suppliers:

• Focus on brand integrity rather than brand protection; this supports solution lifecycle
threat modeling which proactively identifies and addresses supply chain vulnerabilities
• Use periodic supplier meetings to ensure suppliers understand the customers’ and end
users’ business needs, concerns, and security priorities
• Provide mentoring and training programs to suppliers on key organizational security
objectives and programs
• Identify and monitor security risks, threats, and vulnerabilities that may be introduced by
including supplier solutions or third-party components into the solution
• Use supplier reviews and audits to help determine whether primary suppliers have security
methods, standards, and safeguards in place; and a practice for vetting subordinate
suppliers, for example, second- and third-tier suppliers and subcontractors
• Employ on-site security verification and validation of supplier self-evaluation reviews
• Software or Sales Bill of Materials (SBOM), also known as a Software Bill of Sales (SBOS),
including open-source software or any other potential vulnerabilities present in the
solution
619
Level 1
SAM 1.1
Practice Statement
Identify, evaluate, and select suppliers.
Value
Increases likelihood of selecting suppliers that meet the project’s parameters.


Example Activities

Identify potential suppliers and Requests for Proposals (RFPs) may include:
distribute requests for proposals. • Requirements
o Technical
o Non-technical
o Contractual
o Regulatory
• List of deliverables
• Time constraints
• Cost estimates
• Other identified proposal criteria
Evaluate proposals and select Leverage the criteria from the RFP to evaluate the
suppliers. proposals.

List of potential suppliers
RFP
Proposal evaluation
620
SAM 1.2
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
agreement with the supplier. supplier agreement.
Reach agreement with supplier.

Supplier Agreement May include:
621

• Affected stakeholders and communication involved
• Statement of Work
• Specifications
• List of deliverables
• Schedule
• Budget
• Legal or regulatory information
SAM 1.3
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
622
SAM 1.4
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
623
Level 2
SAM 2.1
Practice Statement
Identify evaluation criteria, potential suppliers, and distribute supplier requests.
Value
Increases likelihood that selected suppliers consistently contribute to meeting business
objectives.


The acquirer may use different types of acquisitions to guide supplier selection based on
technical, regulatory, or customer requirements. Examples of acquisition types may include sole
source, competitive bid, and joint venture. Potential suppliers are identified based on their
capabilities and through mechanisms such as Requests for Information (RFI) and market
research which can then lead into a Request for Proposal (RFP). RFIs and RFPs are examples of
supplier request packages. The term supplier requests can represent requests from the acquirer
to the supplier or from the supplier to the acquirer.
Frequently, acquirers use a competitive bid process for selecting suppliers, based on evaluation
criteria that are shared with potential suppliers. Potential suppliers are identified through
various means based on their capabilities.
The acquirer identifies potential suppliers to receive the 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.
Supplier selection criteria should address factors that are important to the work. These may
include:
• Total lifecycle cost
• 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
• Warranties and maintainability
624
Example Activities

Develop the The SOW typically includes:
Statement of Work • An overview of the project, including objectives and description of
(SOW) for the the project environment and risks
supplier. • Contractual and technical requirements, including Period of
Performance (PoP); milestones; work location; legal, statutory, and
regulatory requirements; delivery format; quantities; content
requirements; solution acceptance criteria; required reviews and
frequency; communication mechanisms; data management; data
quality; security; safety
• Supplier performance requirements and reporting including
measures of quality, process, product, service levels, and
transitions to operations and support
• Design constraints
• Deliverables, e.g., Work Breakdown Structure (WBS) or list of tasks
for the supplier’s work, detailed design, test results
• Ownership, intellectual property, data, and proprietary rights
• 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
• Approach and responsibilities for quality reviews or audits
• Proposal validity period
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 terms and Terms and conditions may include:
conditions and • Recitals or demonstrations of proposals
additional • Compensation and payments
information. • Confidentiality
• Privacy or non-disclosure statements
• Legal, regulatory, certification or other requirements
• Exclusive services, key personnel, supplier personnel at acquirer
sites
• Ownership, intellectual property, data, and proprietary rights
• Non-compete terms
• Force majeure
• Termination for insolvency, breach, non-performance,
convenience, and any assistance terms
• Term (length of the agreement) and renewal period
• Indemnification and insurance
• Right to audit
625
Additional information to help the supplier when responding to the

supplier request 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
• Warranty and licensing provisions
Develop and record Required proposal content requirements typically include:

the required proposal • Company overview, experience, and references
contents. • Evidence of the supplier’s processes and quality management
approach
• Supplier solution description addressing requirements
• Plan for supplier solution delivery, including risk and opportunity
management, critical dependencies etc.
• Supplier pricing methodology may include:
o Calculation of charges, taxes, and credits
o Foreign currency exchange rates
o License fees
o Pass-through costs
o Travel reimbursements
o Alignment to acquirer invoicing requirements
• Compliance with legal, regulatory, certification or other
requirements
• Issue escalation and resolution approach
• Information about intellectual property, data, and proprietary
rights
• Plan for retention of critical team members during the project
626

• Identification of work planned for further outsourcing to additional
subcontractors
Develop proposal The evaluation criteria used should be consistent with the
evaluation criteria. requirements and complexity of the acquired solution. Evaluation
criteria scales, measurements, and weighting should be incorporated
in the supplier request package, as appropriate.
Examples of criteria used to evaluate a potential supplier’s ability and
proposal include:
• Response to all stated requirements contained in the supplier
request package
• Experience with similar solutions or services
• Technical capability, including:
o Technical methodologies and techniques
o Solutions
o Services
o Systems, tools, networks, and technical compatibility
requirements
• Familiarity with acquirer processes, the technical environment, and
the core business
• Security and safety considerations
• Total ownership and lifecycle costs
• Supply chain reliability
• Management, development, and delivery processes
• Financial capability
• Resource capacity, e.g., personnel available, facilities available
• Business size and type
• Intellectual property and proprietary rights
• Compliance with regulatory requirements
Identify and finalize a The acquirer may consider:
list of qualified • Suppliers and their personnel who have experience with similar
suppliers. systems or projects
• Performance of suppliers on previous projects
• Suppliers’ financial capabilities, e.g., credit worthiness, financial
stability, and access to capital
Communicate and Affected stakeholders may include potential suppliers and other
review the supplier industry representatives.
request package with Typical communication to suppliers includes:
affected stakeholders
prior to distribution • Schedule for release of the supplier request package
and obtain • Schedule for the return of proposals
commitment. • Date when the supplier must indicate if they plan to respond to the
supplier request package
• Acknowledgement of receipt of proposal responses
627

Verify that all potential suppliers have equal access and opportunity
to provide feedback on the supplier request package.
Provide the opportunity for selected potential suppliers and
stakeholders to clarify ambiguity and address concerns with
requirements.
Manage supplier Keep the package updated throughout supplier selection process.
request package Communicate changes to the supplier request package or timeline to
all affected stakeholders.

Records of reviews of the supplier request
package and stakeholder commitments
Supplier and proposal evaluation criteria
Supplier request package Manage initial draft, and subsequent approved
versions under configuration management.
List of qualified suppliers
Communication records May include:
• Notifications to potential suppliers
• Supplier submitted questions and requests
for clarification
• Acquirer responses to questions and
requests
SAM 2.2
Practice Statement
Evaluate supplier responses according to recorded evaluation criteria and select suppliers.
Value
Matches selection of the best solution and supplier for meeting contractual requirements.

628

Evaluate proposals submitted in response to supplier request packages in accordance with a
defined timeline. Use proposal evaluation criteria to evaluate potential supplier responses to the
solicitation package. Score proposals against criteria and record evaluation results including
decision-making notes, e.g., advantages and disadvantages of potential suppliers.
Use proposal evaluation results to finalize the supplier selection. In some cases, the acquirer
can take the highest scoring proposals and uses 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.
Example Activities

Verify conformance to requirements Contact the suppliers for corrective action if the
and completeness of supplier response is 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
presentations. the SOW.
Evaluate and score supplier This may include an evaluation of past performance
proposals according to evaluation based on a review of:
criteria. • Supplier’s references
• Any previous experience with the supplier
• Prior performance on similar work
• Supplier management capabilities
• Personnel available to perform the work
• Supply chain issues
• Available facilities and resources
• The project’s ability to work with the proposed
supplier
This also includes evaluating the risks associated with
each proposed supplier.
Perform due diligence on highest Examples of typical due diligence activities include:
ranking suppliers. • Reviews of proposed technical solutions and
interfaces or connections for compatibility with
acquirer systems and environment
629

• Reviews and validation of supplier references
• Reviews of the operating environment’s facilities and
capabilities
• Reviews of regulatory and security requirement
performance
• Reviews of supplier’s capabilities
• Reviews of cost and schedule estimates for the
supplier’s work
Negotiate with suppliers. Negotiate with the 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 proposal
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
• Results of due diligence
Revisions due to negotiations
Supplier selection decision

630
Context Specific
Security

The supplier selection team must evaluate and select suppliers, party components, or solutions
according to an established security selection criteria process. Develop supplier selection and
outsourcing processes jointly with input from Information Technology (IT), security,
engineering, and operations personnel to ensure comprehensive coverage.
Typical criteria that are found in a security selection process include:
• Information security management system, e.g., information security policies, data
protection, physical access, security incident handling processes, security tools and
environment
• Due diligence and background checks to determine if there are any risks associated with
implementing a supplier agreement
• Analysis of supplier processes used to build, operate, and support solutions, information
systems, solution components, and information system services
• Assessment of supplier training and experience in developing and delivering solutions,
solution components, or services with the required security capability. These reviews
provide organizations with increased levels of visibility into supplier activities during the
solution lifecycle to promote more effective supply chain risk and opportunity
management.
• Testing of supplier capabilities, e.g., through a pilot or prototype
• Supplier reviews to determine whether primary suppliers have security safeguards in place
and a practice for vetting subordinate suppliers, for example, second- and third-tier
suppliers and subcontractors. Questions that should be considered for the selection
process include:
o How do the suppliers manage their own personnel? Consider personnel in supplier
companies that have access to the data, systems, or facilities of their customers.
o How do the vendors manage their service providers? Any service provider with access
to company information poses a potential cyber risk
o How do the vendors manage their products and software? Consider solutions with
embedded Information Technology (IT) and Application Programming Interface (API)
that integrate into customer’s systems
Consider possible introduction of threats and vulnerabilities based on acquisition types. For
example, developed versus purchased solutions result in different security implications.
631
SAM 2.3
Practice Statement
Manage supplier activities as specified in the supplier agreement and keep agreement updated.
Value
Maximizes the likelihood that the supplier will fulfill acquirer expectations.


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
• Results from audits and other reviews
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.
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.
632
Example Activities

Establish supplier May include:
agreement. • 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.
Verify that the acquirer Approval may take different forms, such as:
and supplier understand • Signature
and agree to all • Electronic approval or acknowledgement
requirements by • Stamp or record of corporate/company approval
approving the supplier • Other legally-binding acceptance
agreement.
Monitor supplier progress Monitoring can be conducted during agreement, technical, and
and performance, e.g., management reviews. Reviews can include both planned and as-
schedule, effort, cost, needed interactions.
technical, as defined in Reviews cover both formal and informal reviews and include the
the supplier agreement. 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
• Identifying issues and determining corrective actions necessary
to resolve and track the issues to closure
633

• Monitoring risks involving the supplier and mitigating them as
necessary, e.g., supply chain issues
Conduct agreement May include:
reviews with the supplier • Agreement changes or updates
as specified in the • Stakeholder reassignment
supplier agreement. • Interpretation and clarification of terms, conditions, and
deliverables
• Positive or negative feedback on contractual requirements
Conduct technical Technical reviews typically include:
reviews with the supplier • Providing the supplier with visibility into the needs and
as defined in the supplier preferences of the customers and end users as appropriate
agreement. • 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 This typically includes reviewing:
reviews with the supplier • Critical dependencies
as specified in the • Risks involving the supplier
supplier agreement. • 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 Use the results of reviews to improve the supplier’s performance
reviews and interactions. and to establish and nurture long-term relationships with
preferred suppliers.
Manage the supplier This typically includes:
agreement and keep it • Recording all changes formally approved by both the acquirer
updated. and supplier
• Developing, recording, and keeping the requirements updated,
e.g., supplier deliverable requirements, service level
agreements
• Periodically reviewing the supplier agreement to ensure it
accurately reflects current plans, processes, risks, and market
conditions
634

• 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 Formal changes may be recorded as contract addenda for formal
and supplier understand change requests.
and agree to all changes
to requirements by
approving the updated
supplier agreement.
Communicate changes to Ensure that all affected stakeholders are aware of the agreement
the supplier agreement changes.
with affected
stakeholders.

Supplier agreement
Formal change requests or contract addenda
Records of communication, progress, review May include:
materials, and performance reports • Schedule
• Budget information
• Issue and action item list
• Risk matrix
• Meeting minutes
• People assigned corrective actions
• Deliverable status
• Due date for actions

Planning (PLAN)
Context Specific
Security

635
Ensure that all activities identified in contracts contain standard security terms, conditions, and
tailoring options that must be implemented to meet commitments in the supplier agreement.
Ensure the Statement of Work (SOW) addresses the following security related aspects:
• Security governance
• Manufacturing and operational security
• Software engineering and architecture
• Asset management
• Incident management
• Transportation security
• Physical and environmental security
• Personnel security
• Information protection
• Sub-tier supplier and partner security, e.g., service providers and cloud
Establish measurement objectives relevant to managing secure suppliers, including a focus on
understanding the effects of supplier performance on security-related operational and financial
performance. Measurement objectives for the supplier enable tracking of the security-related
service-level expectations recorded in the supplier agreement. Collect supplier measurement
data to provide information in support of managing security aspects of the supplier agreements.
Examples of measures to monitor security for suppliers include:
• Number of threats and vulnerabilities discovered in the supplier’s solutions or solution
components
• Types of threats and vulnerabilities discovered in the solutions or solution components
• Number of supplier work product security evaluations completed, planned versus actual
• Number of supplier security process evaluations completed, planned versus actual
• Number of security incidents, by category, severity, and impact in the supplier’s solution
or solution components
SAM 2.4
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 confirms the supplier
agreement is satisfied before acceptance.
636

The acquirer confirms 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.
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
acceptance criteria and procedures the supplier deliverables.
to 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 May include the following items that demonstrate that
contractual requirements for the the agreed-on requirements have been met:
acquired supplier deliverable are • License
satisfied. • Warranty
• Ownership
• Usage
• Support, service, or maintenance agreements
637

• Other supporting materials, e.g., end-use, operations
or support, and maintenance documentation
Communicate to affected The acquirer provides the supplier with notice that the
stakeholders that the supplier supplier agreement has been satisfied, including
agreement has been satisfied. readiness for transition to operations and support, so
the supplier can be paid, and the supplier agreement
closed.

Acceptance criteria and procedures
Discrepancy reports or corrective
action plans
Acceptance review report with
recorded approval
Formal acceptance notifications Notifications should be communicated to the supplier
and affected stakeholders.
A record that all agreement Approval may take different forms, such as through:
requirements have been met • Signature
• Electronic approval or acknowledgement
• Stamp or record of corporate/company approval
• Other legally-binding acceptance

Planning (PLAN)
Context Specific
Safety

Accept safety-related solutions and solution components and identify hazards that could arise
from accepting and integrating the solution or solution component in the environment.
Methodologies to ensure what was requested is what was received include acceptance reviews,
tests, verification and validation activities, configuration audits, and safety evaluations. Safety
evaluations are a common and effective acceptance methodology, conducted to uncover
hazards.
638
The supplier agreement specifies the acceptance criteria for work products, including
parameters of safety evaluations and risk remediation processes.
Security

Accept security-related solutions and solution components and identify threats and
vulnerabilities that could arise from accepting and integrating the solution or solution
component in the environment.
Methodologies to ensure what was requested is what was received include acceptance reviews,
tests, verification and validation activities, configuration audits, and security evaluations.
Security evaluations are a common and effective acceptance methodology, conducted to
uncover vulnerabilities, e.g., malicious code, malicious processes, defective software, and
counterfeit components.
The supplier agreement specifies the acceptance criteria for work products, including
parameters of security evaluations and flaw remediation processes.
SAM 2.5
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 includes 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.
639
Example Activities

Receive invoices.
Review invoices and related Examples of areas of review for invoices and related
supporting material with authorized support material include:
representatives for accuracy. • Variable charges
• Applicable taxes
• Purchases made by the supplier on behalf of the
acquirer
• 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 reviewed and 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

640
Level 3
SAM 3.1
Practice Statement
Conduct technical reviews of supplier performance activities and selected deliverables.
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.

Technical reviews of supplier performance activities and selected deliverables are conducted
using an organizational approach.

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. Acquirer technical
reviews should include reviews of the subcontractor’s work and deliverables. 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
• Specification tolerance limits
• Mean Time to Failure (MTTF)
641
• Mean Time Between Failure (MTBF)

• Maintainability
• Serviceability
• Updateability
• Modularity
Example Activities

Develop criteria for determining
which technical supplier deliverable
to analyze.
Identify technical supplier Technical supplier deliverables that are typically
deliverables for analysis. analyzed by the acquirer may include:
• Supplier derived deliverable and component
requirements, architectures, and designs
• Deliverable interface or connection descriptions
• Deliverables and deliverable components
• Fit for purpose requirements
Identify the functional and quality A traceability matrix is a useful tool for identifying
attribute requirements to be requirements for each selected technical solution, as it
satisfied by each selected technical typically includes information that relates requirements
supplier deliverable. to 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
• Automated testing
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
642

to specified thresholds of technical
performance measures.
Review critical verification results
and data from verifications
performed by the supplier.
Identify interfaces or connections Example criteria for interfaces or connections include:
that are candidates for acquirer • Spans organizational boundaries
management. • Mission critical
• Difficult or complex to manage
• Key quality attributes
• Multiple acquisition projects
Review identified interfaces or
connections against the selection
criteria and include in the work
plan.
Confirm the compatibility of Confirm that interface or connection descriptions
selected interfaces or connections adhere to applicable standards, criteria, and connection
throughout the life of the solution. requirements 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
643

Analysis methods for each selected
supplier deliverable
Noncompliance and change logs
Record of analysis results May include:
• Issue and action item list
• Meeting minutes
• People assigned corrective actions
• Due date for actions
Criteria to be used in selecting
acquirer managed interfaces or
connections

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 and opportunity 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)
644
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 kept
updated.
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
• 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 regarding verification activities
• Reviews of supplier verification results and corrective actions with the acquirer
645
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.
SAM 3.2
Practice Statement
Manage supplier performance and processes based on criteria in the supplier agreement.
Value
Maximizes the probability that supplier’s performance will meet acquirer’s needs, while
minimizing risk.

An organizational approach for selecting and managing supplier processes and deliverables is in
place and followed.

When close alignment between supplier and acquirer processes is critical to the success of the
project, the acquirer should manage these processes to help prevent problems.
Selecting processes for managing 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, managing key processes may be needed.
646
The acquirer decides on the necessary level of managing depending on the level of risk incurred
when the supplier’s process is not performed correctly. Managing processes can range from
reviewing supplier performance 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 manage processes used Supplier processes that are critical to the success of the
by the supplier as defined in the project should be managed. When selecting processes
supplier agreement. to manage, consider the impact on the supplier.
Analyze processes used by the Analyze results of managing selected processes to
supplier as defined in the supplier detect issues as early as possible that may affect the
agreement and communicate with supplier’s ability to satisfy requirements of the supplier
affected stakeholders. agreement. Trend analysis may be performed and can
rely on internal and external data.

List of processes selected for
managing and rationale for
selection
Reports from managing May include:
• Supplier performance reports
• Discrepancy reports
• Action items and risks
• Data quality assessment results
• Data management assessment results
Record results of analysis

647
Level 4
SAM 4.1
Practice Statement
Select measures and apply analytical techniques to quantitatively manage suppliers against
their performance targets.
Value
Enhances supplier performance by focusing attention on the most critical areas for success.

Supplier performance requirements are shared with the supplier as part of the supplier
agreement. These supplier performance targets are quantitatively managed throughout the life
of the agreement.
The acquirer must statistically or quantitatively manage their own internal processes or the
supplier processes and solutions in conjunction with the supplier when the Quality and Process
Performance Objective (QPPO) requires it.

In situations where the supplier’s related critical processes, solutions or components impact the
acquirer’s business objectives or impact the acquirer’s delivered solution, product or service, the
acquirer establishes QPPOs for their own internal processes or the supplier’s, or both.
Appropriate analytical techniques can enable the acquirer to recognize significant deviations
from performance objectives specified in the supplier agreement. This enables the acquirer to
identify areas for potential corrective action with suppliers, and focuses attention on the most
important elements of supplier performance.
Example Activities

Identify key acquirer QPPOs for
targeted supplier processes and
deliverables.
Establish a performance This should be included in the supplier agreement and
measurement specification to be traceable to the acquirer’s QPPOs.
monitor supplier progress and Trace key measures to the performance measurement
performance using quantitative or specifications and the QPPOs.
statistical techniques.
Selection should not be limited to supplier deliverable,
progress, or performance measures only. Measures can
648

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.
Identify corrective action with the
supplier.
Monitor corrective action to closure.

Supplier-related performance
measurement specifications
List of selected supplier-related Measures may include:
measures • 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 Trace to objectives as defined in the supplier
their targets agreement.
Action item list Include corrective actions and status.

Planning (PLAN)
649

TS Overview
Intent
Designs and builds solutions that meet 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
650
• At any level of the product or service architecture

Design and build solutions that meet customer, functional, and quality requirements by:
• 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 Development
Agile teams build designs incrementally, “emergent design” after developing functionality during
each Sprint. Emergent design can introduce risk when developing critical, complex, or large
systems since design defects introduced early can be expensive to correct later.
It is typical for agile teams 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 for recording designs.
Design activities provide a foundation to ensure that the design is developed, usually
incrementally, prior to implementation, and the results are recorded to:
• Identify minimal viable product
• Efficiently share technical information with stakeholders
• Mitigate technical risks
• Peer review to find defects early
• Support maintenance
Table TS-1: Design Activities in an Agile Project shows where design activities are addressed in
a typical agile project.
Table TS-1: Design Activities in an Agile Project

Release planning Obtain earlier and more complete understanding of the end solution,
completion risks, and appropriate sequencing.
Backlog Allocate requirements to design components to be developed for known
grooming/review user stories during this Sprint. This helps to identify additional
requirements that may have been missed.
651

Sprint planning Gain broader understanding for context of designs and interfaces or
connections for the upcoming Sprint.
Sprint execution Implement the design.
Sprint review Determine what has been accomplished during the Sprint.
Sprint Identify what design components remain.
retrospective
Time is 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.
Data
of the solution.
Establish and keep updated architecture standards and criteria which address data
considerations, e.g., data representations, data lineage, data security, data sovereignty, data
access, data privacy, and data provisioning. Three key concepts to address within architecture
standards include:
• Data representation, e.g., business terms, logical, physical, XML, modeling standards,
model management, data resiliency
• Data access, e.g., common data services, applicable information exchange standards,
standard methods for point-to-point data transit and bulk data movement, data
integration standards for safety and emergencies, data security, data privacy
• Data distribution, e.g., internal and external data provisioning such as distribution control
and management, data scalability, requesting and approving access, access restrictions,
distribution models for push and pull, publish and subscribe, ownership and authority,
regulatory authority and audit
Evaluate design decisions based on architecture standards, e.g., platform, technology, tools, to
ensure resulting solutions meet business needs for managing data.
DevSecOps
652
There is no standard DevSecOps pipeline; the design and implementation of a DevSecOps

pipeline depends on the development group’s technology stack, agile development processes,
team skills and experience, and available resources. Due to the complexities involved, initial
environment configuration can take multiple iterations to automate the development. Common
pipeline technology solutions include Microsoft Azure and Amazon Web Services (AWS).
DevSecOps teams must be trained and have knowledge of both development, operations, and
security including secure coding, infrastructure management, system administration, and
DevSecOps toolchains.
Safety

Consider safety concerns, constraints, hazards, and events throughout all aspects of product or
solution design. Address safety needs like any other requirement or criteria in the design of the
entire solution, e.g., components, interfaces, connections, and integration.
Security

Most aspects of security are addressed multiple times within a solution design, but software
design and development in particular can introduce many security vulnerabilities. However, few
software design methodologies or lifecycles explicitly address software security in detail, so
secure software design practices must be added to each element of the design to ensure that
the software being developed is well-secured. For more information, refer to NIST Special
Publication 800-218, Secure Software Development Framework.
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
653
• 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.
654
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
655
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
656

• Defining a process or thread model
• Identifying major reuse approaches and sources
• Ensuring traceability to requirements
Identify, develop, or acquire Examples of effective design techniques and methods
effective design methods or tools include:
for the 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 As the design matures, track the requirements assigned
to ensure they are satisfied. to 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
657

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
• 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
658

Context Specific
Safety

If possible, eliminate identified potential hazards through design selection/changes. Leverage

the established functional safety approach for the safety in order of precedence, and consider:
• Incorporation of safety devices: if unable to eliminate the hazard through design selection,
reduce the safety risk to an acceptable level using protective safety features or devices
• Use of warning devices: if safety devices do not adequately lower the safety risk of the
hazard, include a detection and warning system to alert personnel to the particular hazard
• Use of procedures and training: when it is not possible to eliminate hazards through
design selection or to reduce the associated risk to an acceptable level with safety and
warning devices, incorporate special procedures and training; procedures may include the
use of personal protective equipment
• Incorporation of fail-safes and system redundancies to mitigate safety risks
For hazards assigned catastrophic or critical severity categories, avoid using warning, caution,
or other written advisory as the only risk reduction method. In general, design changes can
either eliminate or reduce the severity and probability of a hazard. The use of procedures and
training can only reduce the probability of occurrence. This may still be effective in reducing the
hazard risk but cannot eliminate the risk.
Security

Consider security when developing design solutions, including design approaches, design
concepts, and preliminary designs. Apply security design principles, e.g., Principle of Least
Privilege (PoLP) and definition of trust boundaries, when developing solution designs. Evaluate
design solutions and technologies against security requirements.
Consider security risk assessments and review external agency threat lists to support the
decision-making process when designing solutions. Evaluate threats and vulnerabilities for each
solution alternative and use them in the decision process. Baseline and control all these
technologies and decisions in a secure environment.
659
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.


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
perform. the 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:
660

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 Include the role of stakeholders.
to affected stakeholders.
Update the design to address Assign corrective action to the appropriate
identified issues. stakeholders.
Review the solution. May include:
• Conducting peer reviews of selected components
• Performing verification of the components as
appropriate
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
Supports usability and maintainability of the solution.
661


Example Activities

Develop and provide guidance
materials.

Guidance material Guidance material may include:
• Customer documentation
• Operator or user instructions
• Maintenance instructions
• Installation instructions
• Operations instructions
• Administrator instructions
• Online help
Ensure where appropriate that safety and security
information is incorporated within guidance materials
for using and maintaining the solution in all intended
environments.
662
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 Revise criteria when requirements, budget, technology,
criteria with affected stakeholders or resources change or when a defect is discovered.
as needed.

Design criteria Examples of criteria include:
• Complexity
• Cost of:
o Development
o Manufacturing
o Procurement
o Maintenance
o Support
663

• Time to implement
• Technology availability and limitations
• Resources needed
• Performance
• Robustness
• Requirements and technology evolution
• End user and operator capabilities
• Rationale why alternative solutions are not required
• 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
Context Specific
Data
of the solution.
Address data needs, constraints, and requirements within design criteria. Data criteria should
include considerations of governance, privacy, data security, regulations, access, and other
controls.
Security

Address security needs, constraints, and requirements within design criteria. Design criteria
should include previous known design flaws. Typical security design flaws may include lack of:
• Threat modeling
• Secure design patterns
• Secure design principles
• Reference architecture
664
• System, operational, and data administration and management, e.g., Single Sign-On
(SSO), Multi-factor Authentication (MFA)
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
• Functionality and quality attributes
• Terms and conditions of warranties for the products
Record the requirements allocation
for each alternative.
Communicate results.
665

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 A decision analysis and resolution method or approach
analysis. 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
• Costs of acquiring versus developing internally
• Critical delivery and integration dates
• Market research of available products
• Functionality and quality of available solutions
666

• 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.

Record 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 against the Identify and resolve issues with the
selection criteria. alternative solutions and requirements.
High-risk situations may use simulations,
prototypes, or pilots to assist in the
evaluation.
Select the solutions that satisfy the
established criteria.
667

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

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

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
668

• Operations and support
• Solution lifecycle states and changes
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.

669

Example Activities

Define interface or connection When defining criteria for interfaces or connections,
criteria. define or investigate critical parameters to determine if
they are 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
processes. components and the fixtures used during the
manufacturing process
• Interfaces or connections to test beds for software
testing
Identify user interfaces or Examples of users include:
connections. • 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 May include:
specification criteria • Safety
670

• 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
Interface or connection control
documents
Rationale for selected interface or
connection design
671

VV Overview
Intent
Confirms selected solutions and components meet their requirements, and demonstrates
selected solutions and components fulfill their intended use in their target environment.
Value
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
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.
672
Verification and validation address different perspectives:

• 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
Agile Development
Agile teams 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 using defined acceptance criteria.
An agile team considers testing and demonstrations to address how the user will operate the
solution in the intended environment. Recorded results show the status of verification and
validation activities and provide an opportunity for analysis. Refer to Table VV-1: Example Agile
Verification and Validation Activities for examples of agile verification and validation activities.
673
Table VV-1: Example Agile Verification and Validation Activities

Agile Activities Example Verification and Validation Activities
Code reviews Verification: Includes self-reviews and peer reviews against coding
standards and unit test coverage
Manual or Verification: Targets and checks logic flow and identifies criteria to test
automated testing that code meets requirements
Sprint reviews / Validation: Paves the way for user acceptance testing (UAT) and system
demonstrations testing, by providing interim demonstrations to confirm epics and stories
meet customer expectations, and identifies any issues or gaps
Safety

Ensure appropriate techniques are considered for verifying and validating safety requirements
and recorded safety targets. Consider the following:
• Verification of components and the product using simulation
• Testing techniques requiring testing to a specified level of structural, data, or path
coverage
• Use of field-use data, including reference sites and service histories
• Prototype testing
• Stress testing
• Accelerated service-life testing
• Test cases and scripts aligned to potential points of operational failure
• Use of mathematical models to validate high safety assurance cases, e.g., simulations to
verify medical device regulations
These activities rely on other verification and validation to demonstrate that the product
performs its specified function in the intended-use environment and that unintended
functionality is not present.
If new hazards are discovered or known hazards are determined to have a higher risk category
than previously assessed, ensure the risk is formally accepted by the approving authority.
If it is not possible to eliminate an identified hazard, then reduce the associated risk to a level
that is deemed acceptable to the end user or approving authority.
674
Security

solution, work, project, and organization
Incorporate security considerations into all aspects of verification and validation activities, e.g.,
environment setup, test procedures, test cases, and installation checklists. Ensure that
verification and validation environments and technologies meet defined security standards.
Plan for what security work products should be selected for verification and validation activities.
For example, select the security requirements, designs, and prototypes that are the best
predictors of how well the solution or solution components satisfies end user security needs.
Perform verification and validation activities early, e.g., concept and exploration phases, and
incrementally throughout the solution lifecycle, including through the transition to operations
and retirement. Types of verification and validation activities to consider include:
• Penetration testing
• Fuzz testing
• Security focused peer reviews
• Tool-based security code reviews
• Static code analysis
• Dynamic analysis
• Security threat analysis reviews
• Simulations
• White, gray, and black box testing
• Review use of tags, cryptographic hash verifications, or digital signatures
During verification and validation activities, include security representatives to participate and
ensure the security risks, threats, and vulnerabilities have been evaluated, and that security
requirements are being met. Ensure management accepts any residual security risks and
mitigations associated with the solution. If the risk or mitigation is deemed unacceptable, then
the designed solution and associated technologies must be reworked.
When performing verification and validation activities, consider a dedicated test environment to
control the overall security testing parameters. The environment should reflect the intended
operational environment and if operational data is used during verification or validation, remove
or sanitize sensitive information, e.g., Personal Identifiable Information (PII), Personal Health
Information (PHI), and user-specific passwords. As changes are made during security
verification and validation, track solutions tested and reviewed for security purposes and place
them under an appropriate level of configuration control. Ensure compatibility among the
interfaces or connections by considering how to integrate solutions with the management of
internal and external interfaces or connections of secure solutions and solution components.
Services
675
Approaches and processes for verification and validation include:

• Each phase of the service operations, e.g., preparation, operation and monitoring,
maintenance, enhancements, retirement
• A clear description of service environments including service development and setup,
operational service approaches and objectives
• Service system components and processes
• Development, staging, and production environments to pilot or prototype the service
operation
• Different approaches, systems, and processes used to verify and validate service delivery
and operation
676
Level 1
VV 1.1
Practice Statement
Perform verification to ensure the requirements are implemented and record and communicate
results.
Value
Reduces the cost of addressing requirements issues 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
677
VV 1.2
Practice Statement
Perform validation to ensure the solution will function as intended in its target environment and
record and communicate results.
Value
Increases the likelihood that the result provides 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
678
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
679

• User and operational manuals
• Process documentation
Identify requirements to be When identifying requirements for each selected work
satisfied by each selected work product, consult the traceability matrix (or other
product. requirements traceability information) updated as part of
managing requirements for the work.
Determine which customer Target environments may include:
requirements and end user • Testing
needs will be validated. • Operations
• Maintenance
• Training
• Support services
Define, record, and keep Examples of verification methods include:
updated verification and • Requirements inspection
validation methods to be used • Demonstration
for each selected solution. • 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

Lists of solution components selected for verification
and validation
680

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

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
681
Services
Service system components selected for verification and validation should cover:
• Services delivered in accordance with service delivery approaches and agreements
• Changes managed for the service delivery system
• Receipt and processing of service requests
• Sustainment of service delivery performance when changes occur
• Service agreements that describe what a service provider will deliver to the customer, and
includes:
o Service level and availability targets
o Responsibilities of the service provider, customer, and end user based on their process
role
o Communications channels and feedback mechanisms
Methods used for verification and validation of service system components may include:
• Prototyping
• Piloting
• Service delivery walk throughs
• Peer review
• User acceptance testing
VV 2.2
Practice Statement
Develop, keep updated, and use the environment needed to support verification and validation.
Value
Minimizes project delays by ensuring that verification and validation environments are ready
when needed.

682

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 For solutions that include service delivery, requirements
verification and validation should be identified for all phases of services operation
environment. and delivery.
Identify customer-supplied This is typically done in the validation environment if
solutions and components. the customer has existing facilities or components that
are 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.

Verification environment
Validation environment
683
VV 2.3
Practice Statement
Develop, keep updated, and follow procedures for verification and validation.
Value
Reduces costs for performing the activities and strengthens 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
Develop and keep updated Procedures may cover:
procedures for verification and • Maintenance
validation. • Set up and support of test and evaluation facilities
• Training
• Management and acceptable use of test data
Perform verification and validation
in accordance with the procedures.

Verification procedures
Validation procedures
Verification and validation results
684
Level 3
VV 3.1
Practice Statement
Develop, keep updated, and use criteria for verification and validation.
Value
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
• Target service levels and expected results
• Service objectives and measurements
• Customers types and expectations

Verification criteria
Validation criteria
685
VV 3.2
Practice Statement
Analyze and communicate verification and validation results.
Value
Improves 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
that do not meet established criteria and analysis.
determine corrective actions.
Submit improvement proposals for the
verification and validation process.
Record and communicate analysis results
and corrective actions to affected
stakeholders.

Results of actual to expected
comparisons for verification and
validation
Analysis results
686

Corrective actions
687

WE Overview
Intent
Aligns the workforce to the organization’s business objectives and empowers individuals and
workgroups to perform their roles efficiently and effectively.
Value
Enhances the capability of the workforce to contribute to the success of the business.

Practice Summary
Level 1
WE 1.1 Identify and allocate commitments to workgroups.
Level 2
WE 2.1 Record and allocate work assignments and keep them updated
based on an assessment of qualifications, skills, and related
criteria.
WE 2.2 Manage the transition of individuals in and out of roles and
workgroups.
WE 2.3 Develop, keep updated, and use communication and coordination
mechanisms within and across workgroups.
Level 3
WE 3.1 Develop, keep updated, and use workforce competencies to build
organizational capabilities and achieve objectives.
WE 3.2 Develop, keep updated, and use an organizational structure and
approach to empower workgroups.
WE 3.3 Develop, keep updated, and use organizational compensation
strategies and mechanisms.

The performance of an organization is directly affected by the capability of its workforce.
688
The organization identifies its business objectives and determines what competencies are
required to achieve them. The resultant competency information is used to manage the
workforce to meet the performance needs of the organization.
This includes:
• Aligning the capability of the workforce with organizational objectives
• Designing an organizational structure that facilitates workforce empowerment
• Managing personnel in an orderly manner
• Establishing communication and coordination mechanisms within and amongst
workgroups
• Empowering workgroups with the authority and accountability to make decisions
• Establishing and using compensation strategies that motivates continuous performance
improvement

Planning (PLAN)
689
Level 1
WE 1.1
Practice Statement
Identify and allocate commitments to workgroups.
Value
Increases the focus of workgroups on critical business outcomes.


Workgroups must be built to balance the workload with available resources. This is achieved by
reconciling work commitments against the skills needed to accomplish tasks.
Example Activities

Develop a list of work commitments.
Identify the list of skills needed. Required skills are often identified in job
descriptions.
Create workgroups aligning work
commitments to skilled personnel.

Work commitments and assignments
Skills list or matrix
Staffing list
690
Level 2
WE 2.1
Practice Statement
Record and allocate work assignments and keep them updated based on an assessment of
qualifications, skills, and related criteria.
Value
Increases likelihood of workgroups achieving assigned tasks.


Analyze proposed work to determine the skills and effort required to perform it. Identify the
most qualified candidates for further consideration and evaluate the skills and experience of the
candidates against position criteria. Individuals and workgroups make commitments based on
their understanding of the assigned project.
Example Activities

Analyze work commitments to Determine required performance goals and make
determine the effort and skills commitments consistent with them.
required.
Record a work assignment selection This may include an organizational design specification,
strategy. e.g., organization chart, RASCI (Responsible,
Accountable, Supporting, Consulted, Informed) Chart
Conduct selection process for each Criteria typically address job or role specific
position to be filled according to requirements, and may include the following
established criteria. considerations:
• Experience
• Skill level
• Availability
• Location
• Education
• Diversity, Equity, and Inclusion (DEI)
• Environmental, Social, and Governance (ESG)
691

Assess performance against Performance goals are typically based on dialogue with
qualifications and related criteria teams and individuals. Performance goals are
and take corrective action. periodically reviewed and revised, as needed.
Manage work assignments to
balance work commitments among
individuals and workgroups.

Work assignment selection strategy This strategy typically includes:
• Role details
• Prioritized criteria
• Resource loading criteria
• Organizational design specification
Skill evaluation criteria
Workgroup skills analysis results
Selection process results
Work assignments Work assignments are typically recording using a
combination of organization charts, RASCIs, related
role descriptions, processes, and related performance
goals.

Planning (PLAN)
WE 2.2
Practice Statement
Manage the transition of individuals in and out of roles and workgroups.
Value
Accelerates the orientation of individuals to fulfill their responsibilities productively.

692

Staff transition activities include:
• Onboard
• Offboard
• Outplacement
• Transfer
• Career progression
• Promotion
• Demotion
• Virtual or on-site location
• Retirement
• Resignation
• Discharge, e.g., downsizing, disciplinary
Onboarding activities are conducted to assist individuals in adjusting to their new position, and
to the organization if they are a new hire. This typically is managed through a checklist or
transition plan, and may include:
• Orientation
• Training courses
• Equipment and software licenses, e.g., laptops, tablets
• Establishment of access to locations, systems, data, tools
• Reviewing workgroup processes and procedures
• Coaching or mentoring assignment(s) and associated activities
• Introductions to workgroup stakeholders
The timing of transition activities is often critical to ensure successful achievement of goals and
objectives while minimizing inefficiencies and disruptions to workgroup operations.
Offboard activities may be voluntary or involuntary, and if not carefully planned can be
detrimental, causing poor morale, security violations, and performance issues. This typically is
managed through a checklist or transition plan, e.g., succession plan, and may include:
• Removal of system and tool access
• Reallocation of licenses
• Return of equipment
• Knowledge transfer
• Archival of records
• Security debrief
693
• Removal of physical access, e.g., building entry
Example Activities

Plan for personnel transition Clear criteria are typically defined for onboarding,
activities. promotions, professional development, career
progressions, succession planning, and offboarding.
Manage transitions of individuals This may include updates to the organizational design
according to a recorded specification, e.g., organization chart, RASCI Chart.
approach.
Seek input from exit interviews to
identify the potential for
corrective actions.

Staff transition plans Specialized or unique roles may need further clarification
or explanation.
RASCI
Organization charts
Job descriptions Often includes requirements from process descriptions.
Transition checklists
Exit interview and survey results

Planning (PLAN)
WE 2.3
Practice Statement
Develop, keep updated, and use communication and coordination mechanisms within and
across workgroups.
Value
Increases productivity through effective information sharing amongst individuals and
workgroups.
694


Establish a common understanding of work objectives, commitments, and intergroup
dependencies. Individuals and workgroups participate in making decisions about how to
organize and perform their work to satisfy their commitments and dependencies. Awareness of
team norms and values is an important component of effective decision-making processes.
Example Activities

Review work objectives with all Establish and communicate team norms and values.
affected workgroups.
Identify and address team building Consider team building stages, e.g., forming, storming,
requirements. norming, performing, adjourning.
Identify the needs for developing Examples of interpersonal skills that support working
social skills. relationships include:
• Internal and external interpersonal communication
and dynamics
• Emotional intelligence
• Active listening skills
• Group communication and dynamics
• Interaction protocols for specific situations
• Problem resolution skills
• Conflict resolution skills
• Negotiation skills
Identify cultural aspects of This may include culturally related initiatives such as:
communication and coordination.
• Diversity, Equity, and Inclusion (DEI)
• Environmental, Social, and Governance (ESG)
Record and use communication Examples include:
mechanisms. • Clearly defined reporting structures
• Acceptable approaches for issue escalation
• Approved methods for issue resolution
• Team collaboration tools, protocols, and channels
Coordinate activities with
individuals and across workgroups
to accomplish work.
695

Team norms, values, and objectives
Work objective review results
Team building and social skill requirements
Communication mechanisms
Coordination mechanisms
Workforce feedback on engagement and satisfaction

Planning (PLAN)
696
Level 3
WE 3.1
Practice Statement
Develop, keep updated, and use workforce competencies to build organizational capabilities and
achieve objectives.
Value
Maximizes consistent performance of the workforce.

The set of knowledge, skills, and process abilities comprises each organizational workforce
competency that are important to the organization in achieving business results.

The range of workforce competencies needed by an organization is derived from the
organization’s business objectives.
The workforce competencies are each analyzed to identify the essential knowledge,
interpersonal and technical skills, process abilities, and performance expectations required for
an effective workforce. These are recorded as workforce competency descriptions that are
periodically reassessed to ensure alignment with business objectives.
Workforce competency descriptions guide strategic and tactical workforce planning to achieve
the mission and vision of the organization. The descriptions are also used to support
development of the organization’s workforce competencies and enable the tailoring of
workforce activities across the organization.
Analyze the performance expectations and results periodically across the entire organization to
verify integration of business activities and workforce competencies to achieve business
objectives. Skill and competency expectations may require corresponding updates to
operational performance measures.
Example Activities

Analyze the workforce competencies needed to achieve This analysis is typically captured
organizational business objectives. in a competency assessment
approach, which can be based on
industry standards.
697

Identify knowledge, skills, process abilities, and
performance expectations for each workforce
competency.
Assess and track organizational capability in each
workforce competency.
Derive workforce plans and keep them updated based
on the workforce competencies and performance results.
Evaluate performance results periodically across the
entire organization and identify workforce competencies
that do not consistently contribute to successful
business results.
Identify potential improvements to workforce Consider strategies of coaching,
management activities. mentoring, and leveraging other
applicable organizational assets.

Workforce competency lists and Record workforce competency descriptions and
descriptions keep them updated and consistent with
organizational standards to ensure:
• Alignment
• Appropriate level of detail
• Suitability
• Accessibility
List of knowledge, skills, and process
abilities for each workforce competency
Results and actions related to workforce
competency analysis
Workforce development plans May include:
• Recruiting
• Training
• Deployment
• Empowerment
• Mentoring
• Coaching
Results of performance analysis Review to consider updates to workforce
management approach or competencies,
including recruiting and hiring performance.
List of improvements
698

Planning (PLAN)
WE 3.2
Practice Statement
Develop, keep updated, and use an organizational structure and approach to empower
workgroups.
Value
Provides workgroups with the authority and accountability to achieve outcomes effectively.

Performance analysis is used to prioritize updates of the organizational approach, structure, and
processes for achievement of performance objectives.

An empowered workgroup is granted considerable autonomy for managing and performing its
work, and for performing selected workforce management activities across and within
workgroups.
Empowering workgroups involves preparing workgroup members to perform their
interdependent and integrated roles within the constraints of the defined processes. It involves
assigning authority for work results to the empowered workgroup and holding the members
accountable. Empowering workgroups also includes clearly defined decision-making authority.
Empowered workgroups are managed as a group rather than as individuals to integrate their
competencies. Related workforce management activities are tailored for use within and across
empowered workgroups.
Use workgroup performance data to identify and improve individual or workgroup
competencies, performance, and procedures. Performance of each empowered workgroup and
the contributions to performance are considered in making individual and team compensation
decisions, as well as in recognizing and rewarding outstanding performance, or addressing poor
performance.
699
Example Activities

Determine and communicate Typically includes:
delegation of authority to • Team self-governance
workgroups. • Cross team coordination and collaboration
Identify, negotiate, and manage
accountability for the achievement
of workgroup outcomes.

Recorded organizational May include:
delegations of authority, • Decision trees
expectations for accountability, and • RASCI matrix
negotiation results • Workgroup charters
Workgroup performance results

Planning (PLAN)
WE 3.3
Practice Statement
Develop, keep updated, and use organizational compensation strategies and mechanisms.
Value
Motivates the workforce to consistently support achievement of business results.

The compensation strategies and mechanisms are designed to motivate and reward the skills
and behaviors the organization considers vital to business performance. Compensation must be
equitable across the organization.
700

Develop an organization compensation strategy and approach that reinforce organizational
values and behaviors. This strategy should be periodically reviewed and revised against
business policies and objectives.
Compensation decisions are based on criteria stated in the strategy and elaborated in the
approach. Adjustments are made to an individual’s compensation based on performance and
other recorded criteria and communicated to affected individuals along with information about
the basis for the adjustment.
Compensation decisions are reviewed to ensure they are equitable for workgroups and
individuals relative to skills, experience, performance, and other appropriate criteria.
Adjustments are made to address inequities.
Once the workforce perceives the compensation strategy to be equitable, it can be adjusted to
motivate the development of needed skills and maintain alignment of individual performance
with that of the workgroup or organization.
Example Activities

Develop and use a compensation Typically includes:
strategy and approach. • Individual, workgroup, or team considerations
• External market trends
• External resource demand
Review the compensation strategy
to determine whether it needs to
be revised.
Adjust the compensation strategy Adjustments to compensation should address inequities
and approach to address inequities. arising from:
• Differences between performance and objectives
• Changes in workforce competencies
• Compressed salary banding and unfair compensation
distribution
• Market factors
• Mergers/acquisitions

Recorded compensation strategy Strategy should include:
and approach • Addressing compensation outliers
• Leveraging market data on compensation
Compensation equity study
701

External salary and benefit
benchmark study
Review results

Planning (PLAN)
2
Copyright © 2023 ISACA
THIS ISACA MATERIAL IS FURNISHED ON AN “AS-IS” BASIS.

WARRANTIES, WHETHER EXPRESS, IMPLIED, OR STATUTORY, REGARDING OR RELATING
TO THE CAPABILITY MATURITY MODEL INTEGRATION (CMMI), AND ALL MODEL CONTENT,
INCLUDING THE CMMI PERFORMANCE SOLUTIONS ECOSYSTEM, CMMI METHOD DEFINITION
CMMI Content.

information.
3
CMMI V3.0 Model - Appendices
Table of Contents
Appendix A: Core Practice Areas, Categories, and Capability Areas ....................... 5
Introduction ..................................................................................................................... 5
Category: Doing .............................................................................................................. 8
Category: Managing ...................................................................................................... 10
Category: Enabling ........................................................................................................ 13
Category: Improving ...................................................................................................... 16
Appendix B: Predefined Model Views – Maturity and Capability Levels ................ 18
Maturity Levels .............................................................................................................. 18

Capability Levels ........................................................................................................... 23
Creating Customized Views .......................................................................................... 25
Appendix C: CMMI Adoption Resources ................................................................... 26
Appendix D: Common CMMI Misperceptions ........................................................... 27
Appendix E: Glossary ................................................................................................. 30
Glossary Terminology Context....................................................................................... 30

Glossary Terms ............................................................................................................. 30
Appendix F: Abbreviations ......................................................................................... 53
Appendix G: CMMI Development History .................................................................. 61
Appendix H: Additional References........................................................................... 62
Appendix I: Acknowledgements ................................................................................ 63
4
List of Figures, continued

Figure 26. Core Practice Areas ............................................................................................ 5
Figure 27. Domain-Specific Practice Areas ............................................................................ 6
Figure 28. Categories and Capability Areas ........................................................................... 7
Figure 29. Maturity Levels Summary ...................................................................................18
Figure 30. CMMI Maturity Level Requirements .....................................................................19
Figure 31. Core Practice Areas ...........................................................................................21
Figure 32. Domain-Specific Practice Areas ...........................................................................22
Figure 33. Evolutionary View of Practice Group Levels in Practices.........................................23
Figure 34. Capability Level Rating Progression – CM Example ...............................................24
5
Appendix A: Core Practice Areas, Categories, and

Capability Areas
Introduction
The following section is a high-level description of the core Practice Areas (PAs), Categories,
and Capability Areas (CAs) with their associated PAs. Figure 26. Core Practice Areas shows the
core PAs, and Figure 27. Domain-Specific Practice Areas shows the PAs aligned by domain.
Figure 28. Categories and Capability Areas shows the full list of Categories and their CAs.
Figure 26. Core Practice Areas
6
Figure 27. Domain-Specific Practice Areas
7
Figure 28. Categories and Capability Areas
8
Category: Doing
This Category includes CAs for producing, buying, and delivering quality solutions.
Capability Area:
Ensuring Quality
This CA includes PAs important to both quality assurance and quality control.
Peer Reviews identify solution defects or issues.
Process Quality Assurance confirms the process is followed, and

quality solutions are produced.
Requirements Development and Management enables

developing and keeping updated a common understanding of needs
and expectations for the solution.
Verification and Validation confirms requirements are met and the

solution functions as intended in the target environment.
Capability Area:
Engineering and Developing Products
This CA focuses on engineering, developing, and delivering products and product components.
Product Integration covers the assembly of the products and

product components and their delivery to the customer and confirms
inclusion of required functionality and quality characteristics.
Technical Solution focuses on designing and building products and

product components.
9
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.
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 Agreement Management involves evaluating and
selecting suppliers, establishing supplier agreements, managing the
fulfillment of supplier agreements, and managing the delivery of
solutions from suppliers.
10
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 confirms 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.
Monitor and Control provides an understanding of progress so

appropriate corrective actions can be taken when performance
deviates significantly from the plan, schedule, or budget.
Planning involves developing a work plan, schedule, and budget

using estimates, determining resources, and obtaining commitments
from stakeholders to implement the plan.
11
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
promotes timely and effective resolution and prevention of interruptions to minimize the impact
on business operations and confirms 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.
Continuity plans and validates the critical set of functions and

resources needed to continue operations when a significant or
catastrophic event occurs.
Incident Resolution and Prevention identifies actual and

potential incidents that may impact operations and solution delivery,
including an approach for analyzing and addressing incidents and
minimizing their recurrence.
Risk and Opportunity Management includes identifying threats
and opportunities, evaluating their likelihood of occurrence and
impact, and mitigating potential threats or exploiting potential
opportunities.
12
Capability Area:
Managing the Workforce
This CA addresses the way an organization develops, retains, aligns, and empowers the
personnel needed to perform current and future work.
Enabling Virtual Work includes identifying, assessing, and
addressing virtual, remote, and hybrid work needs and constraints in
a systematic and consistent manner. A virtual work approach
addresses personnel, process, technical, and other considerations,
such as security.
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.
Workforce Empowerment aligns the workforce to the

organization’s business objectives and empowers individuals and
workgroups for success.
13
Category: Enabling
This Category focuses on analyzing causes, making decisions, maintaining integrity of work
products and data, and communicating to stakeholders.
Capability Area:
Managing Data
This CA addresses the importance of organizing and using data within the bounds of business
requirements and verifying its integrity for effective decision making and consistent
communications to achieve target performance results.
Data Management consists of processes, techniques, and tools for

collecting, keeping, and using data securely, efficiently, and cost-
effectively to support informed decision-making and improve
performance.
Data Quality provides an approach for identifying, understanding,

and correcting flaws in data to enable effective information
governance across people, processes, and tools.
14
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 recurrence of undesirable
outcomes or ensure recurrence of positive outcomes.
Configuration Management establishes and maintains the

integrity of work products using configuration identification, control,
and audits.
Decision Analysis and Resolution aids in making decisions using

criteria-based evaluation of alternatives and recording the results.
15
Capability Area:
Managing Security and Safety
This CA describes best practices for holistically defining security and safety strategies,
approaches, activities, and functions necessary to protect the organization’s entire ecosystem,
including personnel, resources, and information. It involves identifying and evaluating security
and safety needs and constraints, prioritizing and planning relevant approaches to address
those needs and constraints, responding to and preventing harmful events and incidents, and
protecting and defending against safety incidents and security threats and vulnerabilities.
Managing Security and Safety (MSS) describes the capabilities needed to:
• Prepare: Define approaches for organizational preparedness and readiness to address
safety and security needs and constraints
• Investigate: Analyze, assess, and learn from safety or security events and incidents
• Monitor: Identify and respond to events and incidents that are potentially harmful to the
organization or solution, on a continuous basis
• Protect and Defend: Take steps and actions against current and future potentially harmful
impacts on the organization or solution to either avoid or minimize negative effects
• Preempt and Prevent: Conduct advanced analysis to anticipate and avoid harmful internal
or external threats, activities, or vulnerabilities caused by people, processes, or systems
• Review and Evaluate: Determine the effectiveness of security and safety approaches and
make necessary improvements
Enabling Safety identifies and addresses safety in all aspects of

the organization, including solutions, products, processes, services,
or environments. This encompasses both facilitating and managing
safety activities.
Enabling Security includes performing security activities that
produce secure solutions and environments. Identifying security
needs and constraints is an ongoing, 24/7, 365 days a year activity.
It cannot be an after-thought or a tradeoff item like schedule, cost,
and quality. Enabling security includes systematically identifying,
assessing, and addressing security needs across a project or
organization.
Managing Security Threats and Vulnerabilities includes a
holistic and systematic approach for addressing security threats and
vulnerabilities for an organization, project, or work effort to select
which threats and vulnerabilities are the most critical to address,
given the potential risk and impact to the business, mission, or
solution.
16
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.
Managing Performance and Measurement includes identifying
and communicating business objectives driving performance and
improvement, and using the results of measurement and analysis
activities against those objectives to manage and improve
performance
Process Asset Development develops and keeps updated a usable

set of organizational processes and process assets for performing the
work.
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.
17
Capability Area:
Sustaining Habit and Persistence
This CA verifies that processes are habitually and persistently 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

confirms the processes of an organization are persistently used and
improved.
18
Appendix B: Predefined Model Views – Maturity and

Capability Levels
Maturity Levels
Maturity levels apply to an organization’s performance and process improvement achievements
in a predefined set of Practice Areas (PAs) covering the core PAs and one or more domains.
Within each maturity level, the predefined set of PAs also provide a path to performance
improvement. Figure 29. Maturity Levels Summary shows the names of each maturity level,
along with their characteristics and their evolutionary performance path.
Figure 29. Maturity Levels Summary
19
Figure 30. CMMI Maturity Level Requirements depicts the requirements based on the core
Practice Areas and domains.
Figure 30. CMMI Maturity Level Requirements
20
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.
Maturity levels build on each other and cannot be skipped. CMMI appraisals are conducted to
verify achievement of CMMI practice group levels to determine and rate maturity levels and
capability levels.
The following list of maturity levels describes the evolutionary path, based on the practice
group levels, as required in the group of predefined core PAs, Figure 31. Core Practice Areas,
and one or more selected domains, Figure 32. Domain-Specific Practice Areas:
• Maturity Level 1: achieve Practice Group Level 1 in all targeted PAs
• Maturity Level 2: achieve Practice Group Level 2 in all targeted PAs
(Practice Group Level 1 is subsumed in Practice Group Level 2)
• Maturity Level 3: achieve Practice Group Levels 2 and 3 in all targeted PAs
• Maturity Level 4: achieve Practice Group Levels 2, 3, and 4 in all targeted PAs
• Maturity Level 5: achieve Practice Group Levels 2, 3, 4, and 5 in all targeted PAs
21
Figure 31. Core Practice Areas
22
Figure 32. Domain-Specific Practice Areas
23
Capability Levels
Capability levels apply to an organization’s performance and process improvement
achievements in individual PAs. Within PAs, the practices are organized into a set of practice
group levels labeled Level 1 to Level 5 which provide a path to performance improvement. Each
practice group level builds on the previous levels by adding new functionality or sophistication
resulting in increased capability. Figure 33. Evolutionary View of Practice Group Levels in
Practices shows the evolutionary characteristics of the capability level for practices.
Figure 33. Evolutionary View of Practice Group Levels in Practices
24
All capability level ratings must include II and GOV. The maximum capability level a PA can
achieve is Capability Level 3. Capability level ratings can be assigned to a single PA, if II and
GOV are included in the rating. For example, an organization could achieve a Capability Level 3
for the PLAN PA if the practice group levels for the practices in the PLAN, II, and GOV PAs up to
Practice Group Level 3 are achieved. Figure 34. Capability Level Rating Progression – CM
Example shows the required Practice Groups (PG) for the CM PA to achieve Capability Level 3.
For more information on determining capability levels and ratings, refer to the MDD.
Figure 34. Capability Level Rating Progression – CM Example
25
Creating Customized Views

Customized views can be developed 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 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
• If a rating is a desired outcome, then II and GOV must be included in the appraisal scope
26
Appendix C: CMMI Adoption Resources

Users can register and login to the CMMI website, https://cmmiinstitute.com, to gain access
to valuable CMMI adoption resources through the CMMI Resource Center and a
personalized dashboard. These resources include but are not limited to: the CMMI Adoption
Guidance, CMMI Tech Talks, CMMI Performance Report Summary, and Published Appraisal
Results (PARS). The personalized dashboard also provides access to training course
materials when a user enrolls in CMMI training.
27
Appendix D: Common CMMI Misperceptions

The following list contains some of the most common misperceptions of the CMMI, as compared
to reality.
28
29
30
Appendix E: Glossary
Glossary Terminology Context
Certain words in the CMMI Performance Solutions ecosystem 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.
Glossary Terms
5-Whys
A technique used to determine an issue's potential underlying causes. This technique involves
asking the question "Why?" repeatedly until the 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.”)
Advanced Persistent Threats (APTs)

An adversary that possesses sophisticated levels of expertise and significant resources, which
allow them to develop opportunities to achieve their objectives by using multiple attack vectors,
e.g., cyber, physical, and deception. These objectives typically include establishing and
extending footholds within the information technology infrastructure of the targeted
organizations for purposes of exfiltrating information; undermining or impeding critical aspects
of a mission, program, or organization; or positioning themselves to carry out these objectives
in the future. An Advanced Persistent Threat (APT):
• Pursues its objectives repeatedly over an extended period of time

• Adapts to defenders’ efforts to resist it
• Is determined to maintain the level of interaction needed to execute its objectives
Source: CMMC - NIST SP 800-39
31
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 development
This is a CMMI context-specific tag reserved for identifying unique information for agile
development projects. It is a framework for managing work using an iterative approach. It is
designed for small teams who break their work into actions that can be completed within time-
boxed iterations, e.g., two-weeks, and track progress and replan in 15-minute stand-up
meetings. (Refer to “agile.”)
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.”)
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 predefined CMMI components used to define the appraisal model view
scope. Benchmark Model Views are defined in the CMMI Model, Appendix B.
32
• For maturity levels, the Benchmark Model View is a predefined set of core and domain-
specific Practice Areas, and their levels, for the purposes of conducting Benchmark
Appraisals or Sustainment Appraisals.
• For capability levels, the Benchmark Model View may be either 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.”)
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 and value 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. Available capability level ratings include:
Capability Level 1 (CL1), Capability Level 2 (CL2), and Capability Level 3 (CL3). To achieve a
target capability level:
• All practice groups in the Practice Area must be rated at the target level
• II and GOV practice groups must also be rated up to and including that same target level
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. The CMMI provides a best-practice framework for building, improving, and
sustaining process capability and performance. (Refer to “CMMI Performance Solutions
ecosystem.”)
33
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
An evaluation technique used to identify causes and their relationship to effects. (Refer to “root
cause analysis.”)
change management
A methodical approach for controlling and implementing changes in a planned and structured
manner.
CMMI Performance Solutions ecosystem

The ecosystem components include the model, appraisal method, training and certification,
adoption guidance, and systems and tools.
coaching
Using an experienced, trained, and capable individual to increase the knowledge, skills, and
process abilities of individuals or workgroups for a specific role, skill, or subject matter to
achieve an identified outcome.
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.”)
compensation
Salary, wages, rewards, or recognition that may include benefits offered to employees for skills,
contributions, and work performed.
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 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
34
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” or “change review 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. (Refer to “acquirer”,
“customer requirement”, and “supplier agreement.”)
core Practice Areas

A collection of Practice Areas considered foundational. Core Practice Areas (PAs) enable
organizational improvement and provide the building blocks for achieving maturity levels for
specified domains.
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 or connections to clarify and define the solutions with
affected stakeholders in a way that is acceptable to them. (Refer to “customer.”)
cybersecurity
Protection and restoration of products, services, solutions, and supply chain; including
technology, computers, telecommunications systems and services, and information; to ensure
their availability, integrity, authentication, transport, confidentiality, and resilience. Cybersecurity
is a part of information security.
35
data
Qualitative or quantitative-based information that can be recorded, communicated, and
analyzed.
data cleansing
Typically involves removing or correcting inaccurate, corrupted, duplicate, improperly formatted,
or incomplete data.
data dictionary
A specification of data definitions and elements that includes information such as data type;
owner; table descriptions; source; size; required, default, and allowed values; constraints;
relationships to other data elements and meaning and purpose of the data.
data glossary
Contains the definitions and concepts of key business terms that are used regularly.
defect density
Number of defects per unit of solution size. An example is the number of bugs per thousand
lines of code.
defense in depth approach

A systematic means of layering defenses to provide resiliency against exploited security
vulnerabilities that can cover aspects of physical, personnel, process, mission, and cybersecurity
needs.
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 required to
achieve Practice Group 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.”)
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.
36
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
Creating products or solutions, including hardware and software, and their related components.
In some contexts, development can include maintenance of the developed solution.
DevSecOps
A combination of the terms: “development,” “security,” and “operations”. DevSecOps is a
mindset, a culture, and set of practices that fosters close cooperation between development and
operations teams to plan, develop, test, deploy, release, and maintain a solution. The goal
of DevSecOps 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 and value 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.”)
domain
An organizing principle in both the CMMI and appraisal method. Domains are functionally similar
groupings of Practice Areas that are applicable or tailored to an organization's primary
capabilities, e.g., Development for systems engineering or product development.
Available domains include:
• Data (DATA)
• Development (DEV)
• People (PPL)
• Safety (SAF)
• Security (SEC)
• Services (SVC)
• Suppliers (SPM)
• Virtual (VRT)
37
empowerment
Authority given to a person or group to perform a specific task with the capability to undertake
technical, process, and workforce decisions autonomously.
entry criteria
Conditions that must be met before an effort can begin successfully. (Refer to “exit criteria.”)
evaluation
An examination of products, processes, services, or environments to identify strengths and
weaknesses.
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.
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 or connection functions. (Refer to “architecture” and “functional analysis.”)
functional safety
The detection of a potentially dangerous condition resulting in the activation of a protective or
corrective solution or solution component to prevent hazardous events arising or providing
mitigation to reduce the consequence of the hazardous event.
The aspect of the overall safety of a solution, solution component, or piece of equipment that
depends on automatic protection operating correctly in response to its inputs or failure in a
predictable manner (fail-safe). An automatic protection system may be designed to properly
handle likely human errors, hardware, solution, or solution component failures, and
operational/environmental stress.
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.”
38
habit and persistence

The way an organization conducts business by following and improving processes and
performance. This routine way of doing business is part of the organizational culture for
enduring performance improvement.
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.”)
hazard
A condition or event that poses a risk to safety. Hazards can be internal or external.
High Maturity
CMMI 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
of quality and process performance objectives.
hybrid work
An approach to performing work that encompasses a combination of virtual and in-person work
activities.
informative material
Includes everything other than the required information. Explanatory information in practices is
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. (Refer to “required information.”)
External links can be added to the informative material. These are links to external assets such
as:
• Additional informative material

• Adoption examples
• Transition and adoption guidance from one model or standard to others
• Templates
inherent security risk
The risk level or exposure without considering the actions that have been taken or might be
taken to mitigate the risk.
integration environment
The configuration of processes, systems, tools, people, and associated infrastructure used when
combining components to develop a solution.
39
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.
knowledge
An individual’s understanding of facts or information. Knowledge provides the basis for
performing a skill that an individual must have to perform a task successfully.
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
managed process
A performed process that is recorded, followed, updated, and made persistent and habitual in
its use. A managed process is required to achieve Practice Group 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 (OU) meet the
intents and values 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. Available
maturity level ratings include: Maturity Level 1 (ML1), Maturity Level 2 (ML2), Maturity Level 3
(ML3), Maturity Level 4 (ML4), and Maturity Level 5 (ML5).

Used to describe quantitative targets or goals that are not subjective and do not require the
additional rigor of statistical analysis.
measurement-based
Information obtained by identifying, capturing, and analyzing objective measurable data.
40
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.”)
mentoring
The process and relationship of an experienced individual providing guidance to a less
experienced individual or workgroup in support of their development growth and activities.
model component
Any of the five main architectural elements or parts that compose the CMMI. 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.
offboard
The process of separating an individual from an organization, workgroup, or role. This typically
involves a phased transfer of knowledge, return of equipment, removal of access, transition or
archival of records, and exit interviews. Exit interviews can be used to gather information
relevant to morale and retention.
onboard
The process of integrating an individual into an organization, workgroup, or role.
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 required to achieve Practice Group Level 5 in the CMMI Practice Areas.
(Refer to “quantitatively managed process” and “defined process” for contrast.)
41
or
The use of “or” in the CMMI means either “and” or “or.”
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 or connections 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.”
patch management
The process to identify, acquire, install, and verify a set of changes to a computer program or
its supporting data for solutions and systems. A patch is typically an isolated change of a
specified scope and is sometimes referred to as a bug fix.
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.”)
42
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.
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 required to achieve Practice Group Level 1 in the CMMI Practice Areas.
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 (intent), the value statement,
and the additional required information
• Explanatory practice information: Remaining parts of the practice, including additional
explanatory PA/practice information, example activities and work products, which are
important and useful to better understand the practice statement (intent), value
statement, 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. Practice groups are organized by 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 structural design and ordering, interfaces or connections, interdependencies, and other
relationships among the process elements.
43
process asset
An element of a process that has value to the organization or work effort. An asset can include
hardware, firmware, software, systems, information, measurements, databases, and templates,
as well as the processes and procedures themselves.
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 component, system, tool, robot, 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 goals established to focus performance and process improvement in a specific,
measurable way that improves performance to achieve an organization’s business objectives
and build or improve capability. Process improvement objectives may be qualitative or
quantitative. (Refer to “measurement and performance objective”, “organization’s business
objectives”, and “quantitative objective.”)
process improvement plan

A type of plan that records the objectives, activities, resources, oversight, schedules, and
associated risks to improve performance and processes.
process measurement
Activities performed to collect objective information and assign numeric values related to the
activities, steps, and outputs of following a process. This information is analyzed to determine
the effectiveness, efficiency, and performance 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
44
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.”)
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 (PPBs) 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.
45
product line
A group of products:
• Sharing a common, managed set of systems, features, and processes

• Satisfying specific needs of a selected market or mission
• 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 (project
startup) and end and 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, acquiring, and
managing suppliers, etc. Work in support of a project is sometimes performed by workgroups.
The operational parameters of workgroups can vary based on objectives and should therefore
be clearly defined. Workgroups can operate as a project, if designated accordingly. (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 or event when a project begins. (Refer to “project.”)
Quality and Process Performance Objectives (QPPOs)

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 determine and 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
46
• Scalability
• Security
• Timeliness
• Throughput
• Usability
qualitative objective
Used to describe targets or goals that are subjective and typically not expressed in quantifiable
terms but may contribute to increased performance or capability.
quantitative management
An approach to 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 objective measures. (Refer to “measure”, “process
improvement objectives”, and “Quality and Process Performance Objectives (QPPOs).”)
quantitatively managed process

A defined process evaluated and controlled using statistical and other quantitative techniques. A
quantitatively managed process is required to achieve Practice Group Level 4 in the CMMI
Practice Areas. (Refer to “optimizing process.”)
reference model
A defined model describing practices and activities that is used for improving performance or as
a benchmark for measuring capability or maturity.
remote
An approach to performing work that includes individuals working virtually from different
geographic locations, e.g., work from home, satellite office, hotel, customer facility, coworking
space.
required information
Information required for satisfying a practice or Practice Area. Required information includes
Practice Area Intent statement, practice statement, Value statement, and Additional Required
Information.
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.
47
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 affected 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.”)
residual security risk

The remaining probability of an event occurring and its consequence that still exists after a risk
response has been implemented.
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 objective
achievement.
risk mitigation
A set of planned activities, which if performed, may minimize the probability or impact of the
risk.
root cause analysis

An evaluation approach that uses statistical and other quantitative techniques to identify,
understand, address, and prevent or exploit the underlying cause, source, or trigger, of an
identified and selected event or outcome, which may be negative, null, or positive.
safety
A condition of protection from harm. The two key areas of safety are workplace environment
and functional safety.
security resilience
The ability to prepare for and adapt to changing conditions and withstand and recover rapidly
from security disruptions, including cybersecurity. Resilience includes the capability to withstand
and recover from deliberate attack, accidents, or naturally occurring threats, vulnerabilities, or
other security events.
48
security reviews and evaluations

Security reviews and evaluations that must cover or include security needs, constraints, efforts,
and activities in a continuous manner over time, throughout the lifecycle of a solution, or when
triggered by a security event. These reviews and evaluations focus on identifying and
addressing, and when possible, preventing the most critical and urgent security issues first.
Security events, trends, potential threats, and disruptions can also trigger reviews or
evaluations.
security steps or actions
In the CMMI Performance Solutions ecosystem, the terms “security actions” or “security steps”
are used interchangeably and indicate the same intent or meaning as “security measures.” Most
security standards and frameworks refer to “security measures,” where measures are NOT
measurements (a noun), but rather steps or actions (a verb).
security threats
Any circumstance or event with the potential to adversely impact organizational operations
including mission, functions, assets, personnel, processes, systems, or brand reputation through
unauthorized access, destruction, disclosure, modification of information, or denial of service.
Source: NIST Computer Security Resource Center (CSRC) Glossary
security vulnerabilities
Weakness in a solution, information system, system security procedure, internal control, or
implementation that could be exploited by a threat source.
Source: CMMC/NIST SP 800-30 Rev 1
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
An activity that provides a promised exchange of value between a service provider and
customer, product, or work product. Services do not always produce tangible or storable
products, in such instances, the service itself is the deliverable. (Refer to “solution.”)
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.
49
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 an organization, 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, or solutions. Use size as a basis for scoping
estimates and plans.
skills
The abilities that an individual demonstrates to accomplish work.
solution
A product, product component, service, service system, service system component, process, or
tool that is developed, delivered, acquired, or operated to fulfill a defined need. A solution may
include relevant data, people, safety, or security components or subcomponents.
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.
50
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.
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.
51
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 or 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.
threat intelligence
Information an organization uses to understand the threats that have, will, or are currently
targeting the organization. This information is used to prepare, identify, and prevent security
and cybersecurity threats looking to take advantage of valuable resources. This is also referred
to as cyber threat intelligence.
threat intelligence analysis

The application of individual and collective methods to analyze data and test hypotheses within
various organizational or solution contexts. Threat intelligence data is extracted from multiple
data sources, some of which will be deliberately deceptive. The threat intelligence analyst must
analyze, isolate, separate, and sort the data to determine truth from deception. Although this
discipline is found in its purest form inside national intelligence agencies, its methods are also
applied and used for business or competitive intelligence.
Source: CMMC/NIST 800 171B and CSF
trade study
An evaluation of alternatives based on criteria and systematic analysis, to select the best
alternative for attaining determined objectives.
unit testing
Testing of individual hardware or software units.
version control
Identifies the correct versions of work products and confirms 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.
52
view
A selection of model components relevant to the organization or user. Two primary types of
views currently exist:
• Predefined view: A logical grouping of predefined CMMI components used to define the
appraisal model view scope. Examples include: CMMI-DEV Maturity Level 2, CMMI-SVC
Maturity Level 5.
• Customized view: Any combination of Capability Areas, Practice Areas, practice groups, or
practices that are defined by the end user. Customized views are defined to be relevant to
business objectives. (Refer to “Benchmark Model View.”)
virtual work
Includes use of virtual, remote, or hybrid operations and methods to manage personnel, work
efforts, communication, and collaboration. This also includes operations and delivery of a given
service, process, activity, task, or solution to customers and affected stakeholders.
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.”)
workforce competency
A collection of knowledge, skills, and process abilities performed by individuals or workgroups
that an organization needs for performing a particular type of work. A workforce competency
can be stated as a discipline, such as software engineering, financial accounting, or technical
writing. A workforce competency is frequently decomposed to incorporate the unique needs and
constraints relevant to the organization. For example, software engineering with Scrum Master
experience.
workforce management
Leverages workforce policies, organizational structures, processes, and related infrastructure to
establish and promote workforce empowerment and performance.
workgroup
A collection of people who work closely together on tasks that are highly interdependent to
achieve shared objectives. A workgroup typically reports to a responsible individual who may be
involved in managing its daily activities. The operational parameters of workgroups can vary
based on objectives and should therefore be clearly defined. Workgroups can operate as a
project, if designated accordingly.
53
Appendix F: Abbreviations
Abbreviation Term
AAA access control, authorization, and accounting
AI Artificial Intelligence
AIM Accelerated Improvement Method
API application program interface
APT Advanced Persistent Threat
ASARP As Safe As Reasonably Practicable
ASPICE Automotive Software Process Improvement and Capability Determination
AV Antivirus
AWS Amazon Web Services
BOM Bill of Materials
BYOD Bring Your Own Device
CA Capability Area
CAR Causal Analysis and Resolution (Practice Area)
CBT computer-based training
CCB Change or Configuration Control Board
CCD Career and Competency Development
CCPA California Consumer Privacy Act
CD Continuous Delivery
CDPA Virginia Consumer Data Protection Act
CDR Critical Design Review
CHMLA Certified CMMI High Maturity Lead Appraiser
CI Continuous Integration
CI/CD Continuous Integration/Continuous Delivery
CL Capability Level
CM Configuration Management (Practice Area)
CMM Capability Maturity Model
CMMC Cybersecurity Maturity Model Certification
CMMI Capability Maturity Model Integration
CMMI-DATA CMMI Data (Domain View)
54
Abbreviation Term
CMMI-DEV CMMI Development (Domain View)
CMMI-PPL CMMI People (Domain View)
CMMI-SAF CMMI Safety (Domain View)
CMMI-SEC CMMI Security (Domain View)
CMMI-SPM CMMI Suppliers (Domain View)
CMMI-SVC CMMI Services (Domain View)
CMMI-VRT CMMI Virtual (Domain View)
COBIT Control Objectives for Information and Related Technologies
COI Conflict of Interest (see also OCI)
CONT Continuity (Practice Area)
COOP Continuity Of Operations
COSHH Control of Substances Hazardous to Health
COTS Commercial Off-The-Shelf
CPA Colorado Privacy Act
CPM Critical Path Method
CUI Controlled Unclassified Information
CWE Common Weakness Enumeration
DAM Database Activity Monitoring
DAR Decision Analysis and Resolution (Practice Area)
DDL Data Definition Language
DDoS Distributed Denial of Service
DEI Diversity, Equity, and Inclusion
DEV Development (Domain)
DevSecOps Development, Security, and Operations
DLP Data Loss Prevention
DM Data Management (Practice Area)
DMS Delivering and Managing Services (Capability Area)
DoD Department of Defense
DQ Data Quality (Practice Area)
DSCI Data Security Council of India
EDP Engineering and Developing Products (Capability Area)
55
Abbreviation Term
EDR endpoint detection and remediation
EITVOX Entry Criteria, Inputs, Tasks or activity descriptions, Verification and
Validation, Outputs, Exit Criteria
ENQ Ensuring Quality (Capability Area)
ERM Enterprise Risk Management
ESAF Enabling Safety (Practice Area)
ESEC Enabling Security (Practice Area)
ESG Environmental, Social, and Governance
ESOH Environment, Safety, and Occupational Health
EST Estimating (Practice Area)
ETL Extract, Transform, Load
EU European Union
EVMS Earned Value Management System
EVW Enabling Virtual Work (Practice Area)
EWG Empowered Workgroups
F2F Face-to-Face
FEMA Federal Emergency Management Agency
FFA Functional Failure Analysis
FMEA Failure Mode and Effects Analysis
FMECA Failure Mode, Effects, and Criticality Analysis
FOSS Free Open-Source Software
FTE Full-Time Employee
GDPR General Data Protection Regulation
GEOINT GEOspatial INTelligence
GOV Governance (Practice Area)
GQM Goal Question Metric
GRC Governance, Risk, and Compliance
HAZOP Hazard and Operability Analysis
HIPAA Health Insurance Portability and Accountability Act
HIPs Host Intrusion Prevention system
HITECH Health Information Technology for Economic and Clinical Health Act
56
Abbreviation Term
HMC High Maturity Concepts (Course Title)
HMLA CMMI High Maturity Lead Appraiser (Certification)
IaC Infrastructure as Code
IBR Integrated Baseline Review
IDEF Integrated DEFinition Methods
IDM IDentity Management
IEC International Electrotechnical Commission
II Implementation Infrastructure (Practice Area)
ILT Instructor-Lead Training
IMP Improving Performance (Capability Area)
IMS Integrated Master Schedule
IoT Internet of Things
IPS Intrusion Prevention System
IRP Incident Resolution and Prevention (Practice Area)
ISACA Information Systems Audit and Control Association
ISO International Standards Organization
IT Information Technology
ITAR International Traffic and Arms Regulations
ITIL Information Technology Infrastructure Library
IV&V Independent Verification and Validation
KPI Key Performance Indicators
LA Certified CMMI Lead Appraiser
MAGERIT Methodology of Analysis and Risk Management Information Systems
MBR Managing Business Resilience (Capability Area)
MC Monitor and Control (Practice Area)
MD Managing Data (Capability Area)
MDD CMMI Appraisal Method Definition Document
MDDAP Medical Device Discovery Appraisal Program
MDM mobile device management
MFA Multi-Factor Authentication
ML Maturity Level
57
Abbreviation Term
MPM Managing Performance and Measurement (Practice Area)
MSS Managing Security and Safety (Capability Area)
MST Managing Security Threats and Vulnerabilities (Practice Area)
MTBF Mean Time Between Failures
MTTF Mean Time to Failure
MWF Managing the Workforce (Capability Area)
NAC network access control
NASSCOM National Association of Software and Service Companies
NIST National Institute of Standards and Technology
NTIA National Telecommunications and Information Administration
OB Organizational Behavior
OCI Organizational Conflict of Interest (see also COI)
OE Objective Evidence
OSHA Occupational Safety and Health Administration (US) or Agency (EU)
OT Organizational Training (Practice Area)
OTRR Operational Test Readiness Review
OU Organizational Unit
PA Practice Area
PAD Process Asset Development (Practice Area)
PAL Process Asset Library
PARS Published Appraisal Results System
PCI DSS Payment Card Industry Data Security Standard
PCM Process Management (Practice Area)
PDR Preliminary Design Review
PERT Program Evaluation and Review Technique
PG Practice Groups
PGL Practice Group Level
PHA Preliminary Hazard Analysis
PHI Personal Health Information
PI Product Integration (Practice Area)
PII Personal Identifiable Information
58
Abbreviation Term
PIM privileged identity management
PIPL Personal Information Protection Law
PLAN Planning (Practice Area)
PMW Planning and Managing Work (Capability Area)
PoLP Principle of Least Privilege
PoP Period of Performance
PPE Personal Protective Equipment
PPL People (Domain)
PQA Process Quality Assurance (Practice Area)
PR Peer Reviews (Practice Area)
PRR Production Readiness Review
PSM Practical Software and Systems Measurements
PWS Performance Work Statement
QA Quality Assurance
QPPO Quality and Process Performance Objectives
QRT Quick Response Team
RASCI Responsible, Accountable, Supporting, Consulted, Informed
RDM Requirements Development and Management (Practice Area)
RFI Request for Information
RFP Request for Proposal
ROI Return on Investment
ROT Redundant, Obsolete, and Trivial
RPA Robotic Process Automation
RSK Risk and Opportunity Management (Practice Area)
SAF Safety (Domain)
SAM Supplier Agreement Management (Practice Area)
SANS SysAdmin, Audit, Network, Security
SAST Static Application Security Testing
SBOM Software Bill of Materials or Sales Bill or Materials
SBOS Software Bill of Sales
SCIFs Sensitive Compartmented Information Facilities
59
Abbreviation Term
SDM Service Delivery Management (Practice Area)
SEC Security (Domain)
SEI Software Engineering Institute
SHP Sustaining Habit and Persistence (Capability Area)
SI Supporting Implementation (Capability Area)
SIEM Security information and event management
SIPOC Suppliers, Inputs, Processes, Outputs, Customers
SLA Service Level Agreement
SMART Specific, Measurable, Achievable, Relevant, Time-bound
SME Subject Matter Experts
SMS Selecting and Managing Suppliers (Capability Area)
SOC Security Operations Center
SOO Statement of Objectives
SOP Standard Operating Procedure
SOW Statement of Work
SPM Suppliers (Domain)
SRR System Requirements Review
SSC Security Standards Council
SSL Secure Sockets Layer
SSO Single Sign-On
SSP System Security Plan
STIG Security Technical Implementation Guide
STSM Strategic Service Management (Practice Area)
SVC Services (Domain)
SW-CMM Software CMM
SWOT Strength, Weakness, Opportunity, and Threat
TDD Test-Driven Development
TIP threat intelligence platform
TRA Technology Readiness Assessment
TRR Test Readiness Review
TS Technical Solution (Practice Area)
60
Abbreviation Term
UAT user acceptance testing
UEBA user and entity behavior analytics
UI user interface
UK HSE United Kingdom Health and Safety Executive
US United States
VM Virtual Machine
VPN virtual private network
VRT Virtual (Domain)
VV Verification and Validation (Practice Area)
WAF web application firewall
WBS Work Breakdown Structure
WE Workforce Empowerment (Practice Area)
XML eXtensible Markup Language
NOTE: Government organizations and legislation not otherwise identified are in United States.
61
Appendix G: CMMI Development History

The Capability Maturity Model (CMM) was developed in the late 1980s/early 1990s 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 CMM (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
• 2019 First CMMI V2.0 Appraisals conducted and registered
• 2020 Addition of Enabling Virtual Solution Delivery Practice Area and other content
updates
• 2021 Release of CMMI-Security and CMMI-Safety content and training
• 2023 Release of CMMI V3.0 content and training, including domains of People and Data,
DevSecOps Context Specific information, and enhanced maturity level concept
62
Appendix H: Additional References

Cybersecurity Maturity Model Certification (CMMC) Accreditation Body (AB) Website,
https://cyberab.org
CMMI Tech Talks, https://tinyurl.com/2zpv2zdd
CMMI Website, https://cmmiinstitute.com
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.
Department of Defense (DoD) CMMC Website, https://www.acq.osd.mil/cmmc
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. https://www.iso.org/iso/iso_catalogue.
ISACA, https://www.isaca.org
ISACA, COBIT 2019. Schaumburg, IL: ISACA, 2018. https://www.isaca.org
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.
63
Appendix I: Acknowledgements
The initial launch and continued development of the CMMI Performance Solutions ecosystem is
made possible by hundreds of individuals and organizations who support the development as
sponsors, leaders, developers, contributors, reviewers, and translation verifiers. ISACA is deeply
grateful to the community of people who continue to contribute to the ecosystem. For a list of
individuals and acknowledgements visit:
https://cmmiinstitute.com/products/cmmi/acknowledgements.

CMMIModelV3 0

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

CMMIModelV3 0

Uploaded by

Copyright:

Available Formats

2023-11-20 21:41:42 This copy is licensed solely to Jean Franco Cespedes Pasion, who agrees not to reproduce, duplicate,

copy, sell, resell, assign, transfer or exploit

Copyright © 2023 ISACA

THIS ISACA® MATERIAL IS FURNISHED ON AN “AS-IS” BASIS.

TO THE MAXIMUM EXTENT ALLOWED BY LAW, ISACA SPECIFICALLY DISCLAIMS ALL

Document Change History

CMMI V3.0 - Overview

Why use the CMMI? ........................................................................................................ 7

Part Two: Successfully Adopting CMMI .................................................................... 30

Elevating Performance through Process Improvement ................................................. 30

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

Sustaining Habit and Persistence ................................................................................. 35

Part Four: Achieving High Maturity ........................................................................... 37

Part One: About CMMI and Executive Summary

Figure 1. Why Build Capability?

Why use the CMMI?

Figure 2. Why use CMMI?

CMMI Performance Results and Benefits

Improve Your Performance

Figure 3. Driving Performance through Capability

Model Structure and Content

Model Content Organization

Figure 4. Model Content Organization

CMMI Performance Solutions Overview

Figure 5. CMMI Performance Solutions Ecosystem

Figure 6. Integrated CMMI Products

Figure 7. CMMI Model Structure

Figure 8. CMMI Component Structure

Figure 9. CMMI Component Structure - Views

Figure 10. Domain Descriptions

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

Figure 14. Practice Group Level Characteristics

Each practice group level:

Figure 15. Practice Area Versus Practice Structure

• “or” as in “manage risks or opportunities” can mean managing either risks OR

Additional Content Characteristics

Figure 16. Example Icon, DAR

Figure 17. Model Content Relationships

Explanatory Versus Context Specific

Part Two: Successfully Adopting CMMI

Elevating Performance through Process Improvement

Figure 18. Four Stages of Process Discipline

o Brown bag lunches

Part Three: Process Habit and Persistence

Figure 19. Four Characteristics of Process Habit and Persistence

Sustaining Habit and Persistence

• Training to perform the process activities relevant to assigned responsibilities

Part Four: Achieving High Maturity

Figure 20. High Maturity Foundational Building Blocks

Figure 21. High Maturity QPPO Funnel

Figure 23. Maturity Levels 2 & 3 Versus 4 & 5

Figure 24. Using High Maturity to Determine if Work Should be Accepted

In High Maturity, a statistical measure of variation includes:

• Measure and determine effects of the change

Figure 25. Two Approaches to Improvement

Copyright © 2023 ISACA-CMMI

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

TO THE MAXIMUM EXTENT ALLOWED BY LAW, ISACA SPECIFICALLY DISCLAIMS ALL