PLAN 3.

2
Required Practice Information
Practice Statement
Develop a plan and keep it updated, using the project process, the organization’s process
assets, and the measurement repository.
Value
Using proven organizational assets for planning the project increases the likelihood that the
objectives will be met.
Additional Required Information
This section left blank for future content
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Use the tasks and work products of
the project process as a basis for
estimating and planning project
activities.
Use the organization’s measurement Estimates and supporting information typically include:
repository to estimate the work.  Validated historical data from this project or
similar projects
 Similarities and differences between the current project
and the work represented by the historical data
 Reasoning, assumptions, and rationale used to
select historical data
Integrate or develop plans. Other plans that affect the project plan can include:
 Staffing plans
 Training plans
 Stakeholder involvement plans
 Performance improvement and sustainment plans
 Measurement and analysis plans
 Monitoring and control plans
 Solicitation plans
 Agreement management plans
 Risk mitigation plans
 Transition plans
 Quality assurance plans
 Configuration management plans
 Verification and validation plans
 Peer review plans
 Example Activities Further Explanation
Incorporate the definitions of measures Measures may include the:
and measurement activities.  Organization’s common set of measures
 Additional project and product specific measures
Establish objective entry and exit Entry and exit criteria make it clear when people are needed
criteria for tasks and activities. and when they are to start and complete their tasks.
Identify how conflicts will be resolved Identify resolution approaches and mechanisms for
that arise among affected addressing and resolving conflicts, including any agreed to
stakeholders. escalation procedures.

Example Work Products

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

Related Practice Areas

Estimating (EST)
Managing Performance and Measurement (MPM)
Risk and Opportunity Management (RSK)

Context Specific
Development

Context Tag: CMMI-DEV

Context: Use processes to develop quality products and services to meet the needs of
customers and end users.

Examples of development-specific parameters that are considered for similarities and

differences include:
 Design and development approaches
Examples of development-specific product and project interface risks include:
 Incomplete interface descriptions
 Unavailability of commercial off-the-shelf (COTS) components
An additional development-specific example of scheduling factors includes:
 Integration and test issues
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

Context Tag: CMMI-SVC

Context: Use processes to deliver, manage, and improve services to meet customer needs.

The work plan should include service delivery and, when needed, service system development
and service system transition.
Examples of the types of service data contained in the organization’s measurement repository
include:
 Service capacity
 Number of service requests received, closed, cancelled, or in progress
 Number of service requests that missed their service level agreement
 Standard services from the catalog that are in high demand
 Average service request completion time
 Average cost consumed by service request
Plans that affect the work plan include:
 Capacity and availability management strategy
 Service continuity plan
 Incident management approach
 Risk and opportunity management approach
When developing a plan for the project, it is important to develop, keep updated, and follow a
strategy for capacity and availability management for critical services. This will help ensure the
right resources will be available to meet the requirements when needed and that the
organization can meet commitments to customers within agreed limits.
A capacity and availability management strategy is based on requirements, failure and incident
trend analysis, current resource use, and service system performance. Strategy should consider
the minimum, maximum, and average use of resources over the short, medium, and long term.
It may be appropriate for some projects to identify, plan for, and manage the availability of
resources to respond to sudden, unexpected increases in demand. Sometimes, the
management of the obsolescence of certain resources and offerings factor into the strategy for
capacity and availability management.
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
Required Practice Information
Practice Statement
Identify and negotiate critical dependencies.
Value
Paying close attention to critical dependencies reduces risk and increases the likelihood the
project will be completed on time, within budget, and meeting quality objectives.
Additional Required Information
This section left blank for future content.
Explanatory Practice Information
Additional Explanatory Information Example
Activities
Example Activities Further Explanation
Identify each critical dependency. Record dependencies, relationships, and how they affect the
plan.
Integrate schedules An integrated master schedule (IMS) can be used to identify
critical dependencies between work groups and functions.
Review and negotiate dependencies Communicate new or existing dependencies and changes with
with affected stakeholders. affected stakeholders to ensure that they can perform their
work.
Record commitments to address
each critical dependency.
Example Work Products
Example Work Products Further Explanation
Critical dependencies May include:
 Description of the critical dependencies
 Commitments made during negotiations
 Risks associated with the dependency

PLAN 3.4
Required Practice Information
Practice Statement
Plan for the project environment and keep it updated based on the organization’s standards.
Value
Ensures that the resources needed to complete the work are readily available to maximize
productivity.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Analyze project and plan for The critical aspects of the project environment are requirements
resources, facilities, and driven. Explore project environment functionality and quality
environment characteristics with the same rigor as any other project planning
activity. Examples of the resources to be considered include:
 Considerations for the project environment
o Cultural issues
o Visibility
o Voice communication
o Comfortable furniture
o Airborne particulates
o Light for performing work
o Isolation and noise protection
o Space to perform group work activities
o Meeting space
o Support areas
o Laboratories
 Specialized characteristics of workspaces
o Safety
o Security
o Air conditioning
o Tools
o Training
o Remote locations
o Telecommuting
 Storage
 Project equipment
o Computers or work stations
o Communications technologies, e.g., telephones,
fax machines, e-mail, and networks
o Office equipment
o Printing and reproduction equipment
 Supplies
 Application software
 Documentation
Assign a responsible individual to Examples of actions include:
plan to acquire resources,  Preparing budget requests
facilities, and the environment  Developing cost-benefit justifications
needed to perform assigned  Consulting with subject matter experts
work.  Submitting purchase orders
 Negotiating with those responsible for managing building or
computing facilities, distributing equipment or supplies, or
other project environment-related resources
Develop a contingency plan if the
resources, facilities, and
environment cannot be obtained.
 Example Activities Further Explanation
Plan for support personnel needs. May include:
 Business or administrative
 Computer support personnel
 Technical writing and documentation
 Laboratory technicians
Ensure individuals and groups May include:
participate in decisions  Arrangement of project facilities
concerning resources, facilities,  Alterations or improvements to the project environment
and environment.  Resources needed to perform their project

Example Work Products

Example Work Products Further Explanation
Project resources, facilities, and May be included as part of the overall project plan or may be
environment plan separate, e.g., for large or complex projects or environments.
Equipment and tools for the
project
Health and safety considerations,
including any regulatory or legal
requirements
Installation, operation, and
maintenance manuals for the
project environment
User surveys and results
Facilities, resources, and
maintenance records for the
project
Support services needed for the
project environment

Context Specific
Development

Context Tag: CMMI-DEV

Context: Use processes to develop quality products and services to meet the needs of
customers and end users.

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
Services

Context Tag: CMMI-SVC

Context: Use processes to deliver, manage, and improve services to meet customer needs.

Verification and validation of the service system can include both initial and ongoing evaluation
of the environment in which the service provider delivers the service.
Components in the services work environment include those necessary to support service
delivery, software, databases, hardware, tools, test equipment, and appropriate documentation.
Qualification of a service delivery environment includes audits of the environment and its
components for compliance with safety requirements and regulations. Software qualification
includes appropriate certifications. Hardware and test equipment qualification includes
calibration, records and traceability to calibration standards.
Examples of actions to take to improve the services work environment include:
 Adding new equipment and tools
 Acquiring additional networks, equipment, training, and support
Examples of equipment and tools include:
 Resource management tools for service delivery
 Incident and request management tools
Supplier Management

Context Tag: CMMI-SPM

Context: Use processes to identify, select, and manage suppliers and their agreements.

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
Level 4

PLAN 4.1
Required Practice Information
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.
Additional Required Information
Managing the progress towards achieving quality and process performance objectives should be
an integral part of how the project is planned and managed.
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Develop the criteria to use in Criteria can be based on:
evaluating process alternatives for the  Quality and process performance objectives
project.  Availability of process performance data and the
relevance of the data to evaluating an alternative
 Previously recorded process performance baselines
and models that can be used in evaluating an
alternative
 Lifecycle models
 Stakeholder requirements
 Laws and regulations
Identify or develop alternative May include:
processes for doing the work and  Analyzing organizational process performance baselines
meeting objectives. and models to identify candidate processes
 Example Activities Further Explanation
 Identifying processes from the organization’s set of
standard processes as well as tailored processes in
the process asset library
 Identifying processes from external sources, e.g.,
other organizations, professional conferences,
academic research
 Adjusting the level or depth of intensity with which
the processes are applied and can involve the:
o Number, type, and date of peer reviews to be held
o Amount of effort or calendar time devoted to
particular tasks
o Number and selection of people involved
o Skill level requirements for performing specific tasks
o Selective application of specialized construction or
verification techniques
o Reuse decisions and associated risk mitigation strategies
o Sample size for peer reviews

Analyze and evaluate alternative Analyze the relative strengths and weaknesses of
processes against recorded evaluation alternatives. This analysis can be supported by aligning the
criteria. organization’s process performance models with process
performance data.
Perform additional modeling activities if existing process
performance models cannot address significant relationships
among the alternative processes under consideration and
there is high risk of not achieving objectives.
Use historical data and process performance baselines and
models to assist in evaluating alternatives against the
criteria. These evaluations can include a sensitivity analysis,
particularly in high risk situations.
Select the alternative process that best If needed, repeat these activities several times until
meets the criteria. confident that the best available alternative has been
identified.
Evaluate the risk of not achieving the If the risk cannot be avoided or mitigated, it may
project’s quality and process be necessary to revise the project’s quality and
performance objectives. process performance objectives.

Example Work Products

Example Work Products Further Explanation
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
 Example Work Products Further Explanation
Risk assessment of not achieving the Risk handling plan and action to be identified. Decision
project’s quality and process analysis may be used to identify alternate risk mitigation
performance objectives practices.

Related Practice Areas

Decision Analysis and Resolution (DAR)
Managing Performance and Measurement (MPM)
Risk and Opportunity Management (RSK)
 Process Asset Development (PAD)

Required PA Information
Intent
Develop and keep updated the process assets necessary to perform the work.
Value
Provides a capability to understand and repeat successful performance.
Additional Required PA Information
This section left blank for future content.
Explanatory PA Information
Practice Summary
Level 1
PAD 1.1 Develop process assets to perform the work.
Level 2
PAD 2.1 Determine what process assets will be needed to perform the
work. PAD 2.2 Develop, buy, or reuse process assets.
PAD 2.3 Make processes and assets available.
Level 3
PAD 3.1 Develop, keep updated, and follow a strategy for building and updating
process assets.
PAD 3.2 Develop, record, and keep updated a process architecture that
describes the structure of the organization’s processes and process
assets.
PAD 3.3 Develop, keep updated, and make processes and assets available for use.
PAD 3.4 Develop, keep updated, and use tailoring criteria and guidelines for
the set of standard processes and assets.
PAD 3.5 Develop, keep updated, and make the organization’s process asset
library available for use.
PAD 3.6 Develop, keep updated, and make work environment standards available
for use.
PAD 3.7 Develop, keep updated, and make organizational measurement
and analysis standards available for use.
Additional PA Explanatory Information
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
Related Practice Areas
Process Management (PCM)
Context Specific
Agile with Scrum Guidance

Context Tag: Agile with Scrum

Context: Use processes to adapt agile with Scrum techniques.

Agile teams use process assets to perform their work. Figure PAD-1 shows where a team
might develop these assets in sprint 0 to prepare for the first development sprint. Collect
refinement suggestions in the sprint retrospective. Figure PAD-2 shows some example assets
in their template form.
The assets referenced in Process Asset Development extend beyond the typical ones of an agile
project. They include a measurement repository, tailoring guidelines, and work environment
standards.

Figure PAD-1: PAD in an Agile Cycle

Figure PAD-2: Typical Agile Assets
Level 1

PAD 1.1
Required Practice Information
Practice Statement
Develop process assets to perform the work.
Value
Improves consistency to increase likelihood of meeting objectives.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Recording work steps helps to avoid rework and ensure that team members know what needs
to be done.
Example Activities
Example Activities Further Explanation
Record work instructions.

Example Work Products

Example Work Products Further Explanation
Work instructions
Process descriptions
Templates
Level 2

PAD 2.1
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Identify process assets needed for the
project.

Example Work Products

Example Work Products Further Explanation
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
 PAD 2.2
Required Practice Information
Practice Statement
Develop, buy, or reuse process assets.
Value
Helps to minimize costs, effort, and time needed for developing the assets.
Additional Required Information
This section left blank for future content.
Explanatory Practice Information
Additional Explanatory Information Example
Activities
Example Activities Further Explanation
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.
Example Work Products
Example Work Products Further Explanation
Build, buy, reuse analyses results
Process assets

Related Practice Areas

Decision Analysis and Resolution (DAR)

PAD 2.3
Required Practice Information
Practice Statement
Make processes and assets available.
Value
Using existing process assets reduces cost and time needed for performing the work.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Make assets available for use by
projects.
Communicate the availability of
assets for use.

Example Work Products

Example Work Products Further Explanation
Process assets
Level 3

PAD 3.1
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
This section left blank for future content.
Example Activities
Example Activities Further Explanation
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

Example Work Products

Example Work Products Further Explanation
Strategy for building and updating
process assets

PAD 3.2
Required Practice Information
Practice Statement
Develop, record, and keep updated a process architecture that describes the structure of the
organization’s processes and process assets.
Value
A robust process architecture ensures that processes add value.
Additional Required Information
The structure needs to accommodate:
 Processes
 Critical attributes of the process
o Inputs and outputs
o Sequence links
o Dependency links
o Connections
Explanatory Practice Information
Additional Explanatory Information
The process architecture defines the structures necessary to contain the processes, process
assets, and connections. The process architecture needs to be considered from two different
aspects:
 Structural Architecture
 Content Architecture
Both need to be addressed. Figure PAD-3 describes the differences between the two types.
 Figure PAD-3: Structure and Content

The content architecture may independently vary over time because of changes to
organizational needs. Structural architectural will typically only change when there is a major
change to the organization, the process needs, or process approach.
Clearly specified processes interact efficiently resulting in less redundancy and fewer gaps,
therefore ensuring that every process adds value. A process architecture:
 Reduces risks
 Increases quality
 Improves time-to-market
 Increases customer satisfaction
 Facilitates achievement of business objectives
 Promotes understandings between work groups
 Helps clarify roles and responsibilities
  Improves coordination of efforts
 Reduces unnecessary activities
 Reduces missed activities
 Improves process flow by ensuring that all necessary inputs and outputs are defined
Example Activities
Example Activities Further Explanation
Identify process requirements. Process requirements describe the business needs that
processes will address.
Identify process architecture Process architecture objectives describe how and why
objectives. the process architecture will be used and the information
that the representation will provide.
Develop and record the format of the Process architecture is like solution architecture, except that
process architecture. the components are processes. Many of the same tools and
techniques used to design and record solution architectures
can be used to design and record the process architecture.
Different formats can be used at different levels and
may include:
 EITVOX
 IDEF
 Flow charts
 Workflow diagrams
 Process modeling tools
 Context models
 Value chain models
Develop, record, and keep updated the Ensure the process architecture can address all process
process architecture. types.
Review and update process Include representatives of each process type represented in
architecture with affected the process architecture to ensure:
stakeholders.  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.

Example Work Products

Example Work Products Further Explanation
Process requirements
Process architecture format
Process architecture
Related Practice Areas
Process Management (PCM)

PAD 3.3
Required Practice Information
Practice Statement
Develop, keep updated, and make processes and assets available for use.
Value
Enables work to be done more efficiently and effectively, which leads to reduced cost and
waste.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Plan and implement actions that address improvements to the organization’s processes and
assets. Process action plans are detailed implementation plans that target improvements.
For effective implementation of improvements, ensure that support organizations and the
people who perform the process participate in process development, deployment, and
implementation.
Developing and updating processes may involve:
• Management steering committees that set strategies and oversee process
improvement activities
• Process groups that facilitate and manage process improvement activities
• Process action teams that define and implement process actions
• Process owners that manage deployment
Standard processes and assets can be:
• Defined at multiple levels in an organization
• Tailored for each of the organization’s business areas or functions
Each process covers a closely related set of activities. A fully defined process or asset has
enough detail that it can be consistently performed by trained and skilled people.
Tailoring can be done at the organizational, divisional, site, or functional level. Each level or
function of the organization can have a set of standard processes or assets which were tailored
from the organizational set of processes and assets. Some organizations may have only one
level of standard processes.
The organization’s set of standard processes contains process elements that may be
interconnected according to one or more process architectures that describe relationships
among process elements. The organization’s set of standard processes may include:
 Technical, management, administrative, support, and organizational processes
 Sequence, order, and interrelationships of the processes and their elements
 Proven and effective processes and assets
 Lessons learned
Affected stakeholders should also periodically update their defined processes and assets to
incorporate changes made to the organization’s set of standard processes. Update processes
and assets to reflect periodic revisions in the knowledge, skills, and process abilities.
Example Activities
Example Activities Further Explanation
Verify that the organization’s set of
standard processes and assets are
aligned with strategic process needs
and objectives.
Assign responsibilities for acquiring,
developing, and maintaining processes
and assets.
Review and decide if recommendations
resulting from process improvements
should be incorporated into the
organization’s processes and assets.
Develop organizational standards for May include:
processes and assets.  Standards for terminology and use
 Requirements for completeness, correctness, and other
quality attributes
 Semantic structure and organization
 Representation of content
 Format for storage and presentation
 Archiving and access methods
Record process action plans. Action planning may include:
 Recording the action plan
 Reviewing with affected stakeholders
 Revising as necessary
 Negotiating and recording commitments
Process action plans may include:
 Process improvement infrastructure
 Process improvement objectives
 Process improvements to be addressed
 Procedures for planning and tracking process actions
 Responsibility and authority for implementing
process actions
 Resources, schedules, and assignments for implementing
process actions
 Example Activities Further Explanation
 Risks
Track progress and commitments Perform joint reviews with process action teams and
against process action plans. stakeholders to monitor the progress and results of process
actions.
Identify, record, and track to closure issues encountered
when implementing process action plans.
Establish process action teams to Process action teams typically include process owners and
implement actions. those who perform the process.
Build and record processes and assets. Building and recording processes and assets may include:
 Specifying the attributes of each process or asset
 Specifying relationships among processes or
assets Process attributes may include:
 Roles and responsibilities
 Applicable standards
 Process performance objectives
 Entry criteria
 Inputs
 Tasks
 Verification and Validation
 Outputs
 Exit criteria
 Connections
 Measures
Perform reviews on the organization’s
set of standard processes or assets.
Revise the organization’s set of These may need to be revised when:
standard processes and assets as  Improvements to the processes and assets are identified
necessary.  Causal analysis and resolution data indicate a
process change is needed
 Process improvement proposals are selected
for deployment across the organization
 The organization’s process needs and objectives
are updated
Make processes and assets available. These may be made available through a variety of media,
including:
 Documents and records
 Apps
 Websites
 Videos and training materials
 Scripts in automated tools
 Intranets and other electronic media

Example Work Products

Example Work Products Further Explanation
Action plans
 Example Work Products Further Explanation
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

Related Practice Areas

Peer Reviews (PR)

PAD 3.4
Required Practice Information
Practice Statement
Develop, keep updated, and use tailoring criteria and guidelines for the set of standard
processes and assets.
Value
Adapting a standard process to accommodate the unique needs of each project avoids
unnecessary work.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Consistency across the organization ensures that organizational standards, objectives, and
strategies are addressed, and process data and lessons learned can be shared.
Tailoring is a critical activity that allows controlled changes to the processes due to the specific
needs of a project or a part of the organization. Tailoring of processes should be constrained
and take into account business objectives or technical requirements. Tailoring guidelines may
allow additional flexibility when dealing with less critical processes or those that only indirectly
affect business objectives.
Balance tailoring flexibility with consistency of processes across the organization. Flexibility
helps address contextual variables such as:
 Domain
 Nature of the customer
 Cost, schedule, and quality tradeoffs
 Risks
  Technical difficulty of the work
 Experience of the people implementing the process
The amount of tailoring could also depend on the project’s lifecycle model, the use of suppliers,
and other factors.
Tailoring criteria and guidelines can allow for using a standard process “as is,” without tailoring.
Examples of reasons for tailoring include:
• Accommodating the process to a new solution
• Adapting the process to a new work environment
• Modifying the process description, so that it can be used within a given project
• Adding more detail to the process to address a unique solution or constraint
• Modifying or combining elements of a lifecycle model
• Modifying, replacing, or reordering process elements
Example Activities
Example Activities Further Explanation
Specify selection criteria and Examples of criteria and procedures include:
procedures for tailoring the  Criteria for selecting and tailoring lifecycle models
organization’s set of standard from the ones approved by the organization
processes.  Criteria for selecting process elements from
the organization’s set of standard processes
 Procedures for adapting the organization’s common
measures to address information needs
Specify the standards used to record
defined processes.
Specify the procedures used to submit
and obtain approval of waivers from
the organization’s set of standard
processes.
Record, approve, and communicate Reviews of the tailoring guidelines may be used as a part of
tailoring guidelines for the the approval process.
organization’s set of standard
processes.
Revise tailoring guidelines as
necessary.

Example Work Products

Example Work Products Further Explanation
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
 Example Work Products Further Explanation
 Procedures that must be followed in performing
and recording process tailoring
Waivers or requests for process Waivers are not intended to be a means to opt out of
waivers following a process. A waiver may be used when:
 The standard process cannot be tailored to meet
the needs of the project
 A customer, legal, or regulatory constraint prevents
the process from being followed
 There is a new requirement that the standard
process currently cannot address

Related Practice
Areas Peer Reviews
(PR) Context
Specific
Services

Context Tag: CMMI-SVC

Context: Use processes to deliver, manage, and improve services to meet customer needs.

Example Activities
Example Activities Further Explanation
Develop tailoring criteria as Record the fixed elements of standard services that will not
appropriate. change. Fixed elements may have allowable variation
within specified limits.
Examples of allowable variation:
 Pricing
 Hours of operation
 Geographical coverage
The service provider uses knowledge of variability in
customer needs to develop tailoring options.
The tailoring guidelines describe how to:
 Use standard services to guide the development
of individual services
 Use criteria to determine and select tailoring options
 Follow procedures in performing and recording tailoring
Tailoring criteria and procedures include:
 Selecting standard services from the services approved
by the organization
 Selecting service components from the service provider’s
service catalog
 Tailoring the selected services and service components to
satisfy requirements for delivery
All tailoring actions should be subject to required approvals.
Tailoring actions may include:
 Modifying a service level
 Example Activities Further Explanation
 Combining components of different services
 Modifying, replacing, or reordering service components
Identify needs and expectations for If the service provider needs to develop and keep updated
service systems that deliver standard
multiple service systems to deliver its standard services, it
services.
can be helpful to develop core assets. The service provider
develops these at the organizational and project level for
developing and customizing such service systems, e.g., a
project may be for a specific customer-related service.

PAD 3.5
Required Practice Information
Practice Statement
Develop, keep updated, and make the organization’s process asset library available for use.
Value
Reduces the time and effort needed to organize, access, and update process assets.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
The repository contains both process assets and related work products that are part of the
organization’s set of standard processes.
Example Activities
Example Activities Further Explanation
Design and implement the This includes the library structure and support environment.
organization’s process asset library.
Specify criteria for including assets in Assets are selected based primarily on their relationship to
the library. the organization’s set of standard processes.
Specify procedures for storing,
updating, and retrieving assets.
Enter selected assets into the Assets include:
library and catalog them for easy  Organizational policies
reference and retrieval.  Process descriptions
 Procedures, e.g., estimating procedure
 Plans
 Training materials
 Process aids, e.g., templates and checklists
 Work products resulting from performing the processes
 Lessons learned
 Example Activities Further Explanation
Make assets available for use by
projects.
Periodically review the usefulness of Consider removing assets that are no longer used or viable.
the assets.

Example Work Products

Example Work Products Further Explanation
Design of the organization’s process
asset library
Organization’s process asset library
Process-related work products in the
process asset library

PAD 3.6
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Work environment standards allow the organization and projects to benefit from common tools,
training, maintenance, and cost savings. Work environment standards address the needs of all
stakeholders and consider productivity, availability, security, and workplace health, safety, and
ergonomic factors.
Work environment standards help to ensure that the:
 Improvements made to the work environment improve work performance
 Organization’s work environment supports the development and performance
of empowered workgroups
 Work environment supports individuals or projects using the standard
processes Examples of work environment standards include:
• Requirements for the operation, safety, and security of the work environment
• Workstation hardware and software requirements
 • Standard application software and tailoring guidelines
• Standard production and calibration equipment
• Licenses, security passwords, and IDs
• Criteria for the use and approval of waivers
• Criteria for tailoring the work environment to meet needs
Example Activities
Example Activities Further Explanation
Evaluate commercially available work Choose standards to evaluate based on the organization’s
environment standards. needs.
Adopt, develop, or tailor work
environment standards to fill gaps
based on the organization’s process
needs and objectives.
Periodically analyze the work
environment to identify changes or
resources that could improve work
performance.
Prioritize potential improvements to the Complying with laws and regulations may cause a higher
work environment. priority to be placed on some improvements. Seek guidance
from human resources, facilities, legal, or other appropriate
professionals in complying with such laws and regulations.
Identify resources that could improve Examples of work environment resources that may enhance
performance. performance include:
 Facilities or public spaces, such as work areas
and conference rooms
 Offices and spaces close that allow co-location and
that foster collaboration
 Collaborative tools, applications, or other resources
 Enhanced communication capabilities
Ensure projects have the authority to
organize and tailor their work
environments to best support their
business activities.
Review work environments with
projects.

Example Work Products

Example Work Products Further Explanation
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
 Example Work Products Further Explanation
 A customer, legal, or regulatory constraint prevents
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.7
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Specify organizational standards for Different standards may be needed for different types of
measurement and analysis. data or analysis techniques.
Specify tailoring guidelines for applying Includes criteria for when a waiver is allowed or approved.
measurement standards to individual
projects.

Example Work Products

Example Work Products Further Explanation
Organizational measurement and
analysis standards
Waivers or requests for measurement Waivers are not intended to be a means to opt out of
and analysis waivers adhering to a measurement and analysis standard. A waiver
may be used when:
 The standard cannot be tailored to meet the needs of
the project
Example Work Products Further Explanation
 A customer, legal, or regulatory constraint prevents
the standard from being applied
 There is a new requirement that the standard
currently cannot or does not address
 Process Management (PCM)

Required PA Information
Intent
Manages and implements the continuous improvement of processes and infrastructure to:
 Support accomplishing business objectives
 Identify and implement the most beneficial process improvements
 Make the results of process improvement visible, accessible, and sustainable
Value
Ensures that processes, infrastructure, and their improvement contribute to successfully
meeting business objectives.
Additional Required PA Information
This section left blank for future content.
Explanatory PA Information
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.
PCM 3.5 Deploy organizational standard processes and process assets.
PCM 3.6 Evaluate the effectiveness of deployed improvements in achieving
process improvement objectives.
Level 4
PCM 4.1 Use statistical and other quantitative techniques to validate selected
performance improvements against proposed improvement expectations,
business objectives, or quality and process performance objectives.
Additional PA Explanatory Information
Process improvement focuses on the needs of the business to:
 Increase value for customers
 Align with business objectives
 Make business activities more efficient and effective
 Make the business more profitable
 Stay ahead of competition
 Increase employee satisfaction
Improvements to a process will often improve performance, but that is not the only reason to
improve processes. For example, a strategic or regulatory change may drive an improvement or
change to the process. It is also important to refine the improvement approach so that the
processes are more useful to the organization.
Process management activities address the improvement of specific processes based on
proposals from various sources which may include:
 Process evaluations including appraisals and quality assurance activities
 Feedback from users
 Measurement analysis results
 Performance results
Improvements that show demonstrable benefits help develop and support a culture that strives
for ongoing improvement. A continuous improvement culture is essential to sustaining best
practices and avoiding falling back into bad habits. Improving processes also increases
employee satisfaction and retention rates by building an environment where people can be
productive.
Related Practice Areas
Process Asset Development (PAD)
Context Specific
Agile with Scrum Guidance

Context Tag: Agile with Scrum

Context: Use processes to adapt agile with Scrum techniques.

Agile teams collect retrospective data at the end of each sprint that provides a rich source of
improvement ideas. Some agile teams form a community of practice where individuals with a
need for similar improvements can share experiences. Typically, retrospective sessions are
focused on ad-hoc topics and improvements at a team level. Process management adds the
systematic collection, analysis, and coordination of these improvements across the
organization. The organization will benefit by learning from each agile team.

Figure PCM-1: PCM in an Agile Cycle

 Table PCM-1: Retrospective Information

Figure PCM-1 shows where process management activities are performed in an agile project.
Table PCM-1 shows typical retrospective data.
Process management activities can supplement the typical agile team to aid organizational
learning. For example, agile teams collect data, but there is not necessarily a support structure
to manage and use that data. The retrospective session does not typically or systematically
assess each process. The adoption of process management practices will produce more robust
and sustainable organizational improvements.
Level 1

PCM 1.1
Required Practice Information
Practice Statement
Develop a support structure to provide process guidance, identify and fix process problems, and
continuously improve processes.
Value
A process improvement support structure helps to reduce effort, cycle time, costs, defects, and
waste, and increase performance.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Identify and apply a structure for May include:
supporting process related activities  Organizational expectations and direction
and keep it updated.  Guidance for the process improvement
Assign responsibilities and keep them Typically includes:
updated for coordinating process  Defined roles and responsibilities
related activities.  Following the support structure
Example Work Products
Example Work Products Further Explanation
Process support structure A process support structure typically involves:
 How the structure will be set up and updated
 Funding and support
 Training
 Resources needed to sustain the structure
 Roles and responsibilities that may include:
o Management steering committee that sets strategies
and oversees process improvement activities
o Process group that facilitates and manages
process improvement activities
o Process action teams that define and implement
process actions
o Process owners that manage deployment
o Practitioners that perform the process and
provide feedback

Related Process Areas

Governance (GOV)

PCM 1.2
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
implemented.
Appraisals follow a process, are performed by qualified personnel, and may include:
 A formal assessment or evaluation
 A gap analysis
 A review
 A benchmarking activity
 Other methods
Example Activities
Example Activities Further Explanation
Obtain sponsorship and support for the
appraisal from senior management.
Define the scope of the appraisal. Scope includes:
 Organizational scope
 Process scope
 Model scope
Select or define the criteria and Criteria may include:
method for the appraisal.  Rigor
 Sampling
 Ratings
 Re-appraisal triggers
The appraisal method may include:
 Gap analysis
 Benchmarking
 Review
 Example Activities Further Explanation
Plan and schedule the appraisal.
Perform the appraisal.
Record and communicate the appraisal
findings.

Example Work Products

Example Work Products Further Explanation
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
Required Practice Information
Practice Statement
Address improvement opportunities or process issues.
Value
Reduces costs by increasing efficiency and effectiveness of projects.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Assign relevant personnel to address
the improvement opportunities and
process issues.
 Example Activities Further Explanation
Identify and record the action items to
address improvement opportunities
and process issues.
Address the opportunities and issues
and communicate the results.

Example Work Products

Example Work Products Further Explanation
Action items Include:
 Actions to address identified improvement opportunities
and process issues
 Responsible people
 Resources needed to complete actions
Level 2

PCM 2.1
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
During process implementation and execution, identify opportunities and issues for
improvement. These can come from:
 Individuals
 Improvement proposals
 Lessons learned
 Results from a process appraisal
 Value stream analyses
 Causal analysis
 Measurements
 Quality evaluations
Systematically analyze, prioritize, and record improvement suggestions. This analysis includes:
 Circumstances
 Sources
 Side effects
 Validity
 Benefits
 Effort
 Time to implement
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
Example Activities Further Explanation
Identify issues and opportunities.
Group and analyze proposed May include:
improvements.  Cost benefit
 Return on investment
 Expected performance improvement
 Prioritization
 Barriers or risks
Record and keep updated criteria for May include:
selecting improvements.  Those required by law, regulations, or standards (now
or in the future)
 Supporting process improvement objectives
 Avoiding waste
 Ability to implement and execute
Select proposed improvements
for implementation, deployment,
and execution.
Review selections with affected
stakeholders.
Record proposed improvements and May include the:
communicate results.  Value and rationale of each action
 Improvement based on the evaluation of criteria
 Objectives
 Constraints
 Target users
 Risks
 Estimated cost and schedule to implement
 Expected results

Example Work Products

Example Work Products Further Explanation
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
 Example Work Products Further Explanation
 How to implement the proposed improvement
Recorded selection criteria
List of selected improvements for Refer to above proposed improvement list.
implementation, deployment,
and execution

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

Example Work Products

Example Work Products Further Explanation
Process improvement plan May include:
 Approach, including deployment
 Process improvement objectives
 Roles, responsibilities, and authorities
 Commitments
 Example Work Products Further Explanation
 Tasks or items to work on
 Stakeholders
 Infrastructure
 Effort
 Resource plan
 Budget and schedule
 Expected overall value and performance results
 Risks and success criteria
 Pilot plan
 Progress reporting
Action plan May include:
 Actions to be taken to implement the
selected improvements
 Responsibilities
 Due dates
Developed or updated process assets
Status report
Recorded results May include:
 Results from process improvement activities
 Benefit and value obtained from the improvements
 Performance results
 Nature and root cause of failures
 Effect on other processes and improvements

Related Practice Areas

Estimating (EST)
Monitor and Control
(MC) Planning (PLAN)
Process Asset Development (PAD)
 Level 3

PCM 3.1
Required Practice Information
Practice Statement
Develop, keep updated, and use process improvement objectives traceable to the business
objectives.
Value
Ensure that process improvements focus on achieving business objectives.
Additional Required Information
This section left blank for future content.
Explanatory Practice Information
Additional Explanatory Information Example
Activities
Example Activities Further Explanation
Identify and record improvement
objectives.
Review improvement objectives with Review improvement objectives to ensure traceability to
affected stakeholders. business objectives. Traceability enables verification that the
improvement objectives contribute to meeting business
objectives.
Monitor and update improvement
objectives as needed.
Example Work Products
Example Work Products Further Explanation
Process improvement objectives that
are traced to business objectives

PCM 3.2
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Analyze process improvement objectives to determine which are the major contributors to
achieving the business objectives. This may include analyzing:
 Business objectives and how well they are being achieved
 Business models
 Business environment
 Challenges
 Opportunities
 Planned changes
Process improvement objectives may be based on the results of a process appraisal, root cause
analysis, quality evaluation, or other input. These activities will help determine which
improvement objectives have the highest priority.
Example Activities
Example Activities Further Explanation
Review the current business model,
business objectives, and business
environment.
Review potential internal or external
business changes.
Identify and record the relationships Includes the tracing and mapping of processes and
between the objectives and processes. objectives.
Estimate the value of each process’s
contribution to achieving objectives.
Record, keep updated, and Results include identification of the processes that are the
communicate the results to affected major contributors to meeting objectives.
stakeholders.

Example Work Products

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

Example Work Products

Example Work Products Further Explanation
Potential improvement opportunities May include:
 New ideas and innovations
 Explanation of the ideas
 Potential impact on business objectives
 Initial cost vs. benefit analysis

Related Practice Areas

Process Asset Development (PAD)

PCM 3.4
Required Practice Information
Practice Statement
Provide support for implementing, deploying, and sustaining process improvements.
Value
Ensures process improvements provide value to the organization over time.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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.
Example Activities
Example Activities Further Explanation
Identify the mechanisms needed to support May include:
process implementation and deployment.  User groups, e.g., communities of practice
 Management communication, such as:
o All-hands meetings
o Newsletters
o Webinars
 Feedback to proposers of process changes
Ensure that implementation and deployment
activities are planned and coordinated.
Align multiple improvement activities. Helps to avoid:
 Conflicting goals
 Cancelled efforts
 Waste
Obtain senior management commitment to
visibly and actively support implementation,
deployment, and sustainment of the process.
Provide a migration approach from current to Approaches may vary depending on the criticality
newly deployed processes. and impact of the process. Approaches may include:
 Full implementation across the organization
 Incremental changes via pilots
 Iterative implementation by selected projects
Review the deployment results with the Include the people who perform the process. They
affected stakeholders are often the source of knowledge about the
processes and constraints.
Provide records about the success,
issues, obstacles, and progress of the
supporting activities.

Example Work Products

Example Work Products Further Explanation
Plan for implementing, deploying, and Typically includes:
sustaining improvement  Improvement requirements
 Deployment strategy
 Estimated budget, schedule, risks, etc.
 Updated vs. new processes
 Communication methods
 List of affected stakeholders
 Implementation expectations
 Migration from current to newly deployed processes
Implementation records
Related Practice
Areas Governance
(GOV) Planning
(PLAN)

PCM 3.5
Required Practice Information
Practice Statement
Deploy organizational standard processes and process assets.
Value
Ensures efficient, effective, and coordinated process deployment to reduce potential waste from
overlapping improvements.
Additional Required Information
Coordinate the deployment of selected process improvements and assets in the organization.
Explanatory Practice Information
Additional Explanatory Information
Deploy processes and other process assets according to the plan. Involve personnel who are
implementing and executing the process and related functions, e.g., training, quality assurance,
in deployment. Training enables attendees to apply the processes in a consistent and
sustainable way.
Provide ongoing support to prevent frustration when the something goes wrong, or the user
does not understand the process. A very effective supporting element is coaching. Mechanisms
range from question-and-answer support at defined intervals or events to mentoring by guiding
the users in applying processes, techniques, methods, and templates.
Monitoring implementation ensures that the organization’s set of standard processes and other
process assets are effectively deployed. It also helps to understand:
 What assets are being used
 Why they are being used
 Where they are being used
 How they are being used
Update defined processes to incorporate changes to the organization’s set of standard
processes and process assets. Updates help to ensure that activities benefit from what has
been learned. If standard processes and process assets change or are newly developed, work
may not need to change immediately. It may be better to delay deployment until the project
can more effectively adopt the change.
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
Example Activities Further Explanation
Ensure that sufficient support is
available for the deployment.
Identify projects for deployment of Provide criteria for which work is subject to the deployment,
processes and assets. to what extent and which timeframe, e.g., new work, all
work, staggered approach.
Coordinate the deployment of Coordinating deployment includes:
improved processes with other  Coordinating activities of work groups, support groups,
improvement efforts. and organizational groups for each improvement
 Coordinating activities for deploying related improvements
Deploy the organizational set of Examples of methods for deploying improvements include:
standard processes and the  Deploying improvements incrementally rather than as a
organizational process assets to single deployment
identified projects.  Providing comprehensive consulting to early adopters
of improvements in lieu of revised formal training
Monitor the deployment of Confirm that deployment was completed in accordance with
improvements using deployment plans. the deployment plan.
Review results of objective evaluations. This helps determine how well the organization’s set of
standard processes has been deployed and how well they
are working.
Identify, record, and track to closure
issues related to implementing the
organization’s set of standard
processes.
Review the deployment results with
stakeholders.

Example Work Products

Example Work Products Further Explanation
List of where improvements of new or Should include organizational processes and related process
revised processes or assets will be assets.
deployed
Deployment status report May include:
 Description of the improvement and deployments
 Where, what, and how improvements are deployed
 Example Work Products Further Explanation
 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
Required Practice Information
Practice Statement
Evaluate the effectiveness of deployed improvements in achieving process improvement
objectives.
Value
Ensures deployed processes are contributing to meeting process and performance improvement
objectives.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
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.
Example Work Products
Example Work Products Further Explanation
Process improvement evaluation report May include:
 Benefit and value obtained from the improvements
 Comparison of business and process improvement
objectives against the results and accomplishments
 Need for further improvements
 Causal analysis if needed

Level 4

PCM 4.1
Required Practice Information
Practice Statement
Use statistical and other quantitative techniques to validate selected performance improvements
against proposed improvement expectations, business objectives, or quality and process
performance objectives.
Value
Increases the success rate for performance improvement implementation.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Plan the validation. Quantitative success criteria recorded in the
improvement proposal can be useful when planning
validation. Plans to validate selected improvements, may
include:
 Target work and its characteristics
 Use of pilots, if selected
 Schedule for reporting results
 Measurement and analysis activities
 Success criteria
Review validation plans with affected
stakeholders.
Perform each validation in accordance
with the plan and record results.
Use statistical or other quantitative Validation should include determining if objectives are being
methods to analyze the results of the met.
validation.
Review, record and communicate the Reviewing and recording results of analysis typically involves:
results of validation analysis.  Reviewing results with stakeholders
 Deciding whether to:
o Proceed with deployment
o Re-plan and continue the pilot
o Rework implementation of the improvement
o Terminate the deployment
 Updating the disposition of improvement proposals
associated with the deployment
 Identifying and recording new improvement proposals
 Identifying and recording lessons learned and problems
encountered during the deployment including feedback
to the improvement team and changes to the
improvement
 Evaluating validation results using statistical or
quantitative criteria defined in the improvement proposal
Example Work Products
Example Work Products Further Explanation
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
 Process Quality Assurance (PQA)

Required PA Information
Intent
Verify and enable improvement of the quality of the performed processes and resulting work
products.
Value
Increases the consistent use and improvement of the processes to maximize business benefit
and customer satisfaction.
Additional Required PA Information
This section left blank for future content.
Explanatory PA Information
Practice Summary
Level 1
PQA 1.1 Identify and address process and work product issues.
Level 2
PQA 2.1 Develop, keep updated, and follow a quality assurance approach and
plan based on historical quality data.
PQA 2.2 Throughout the project, objectively evaluate selected performed
processes and work products against the recorded process and
applicable standards.
PQA 2.3 Communicate quality and non-compliance issues and ensure
their resolution.
PQA 2.4 Record and use results of quality assurance activities.
Level 3
PQA 3.1 Identify and record opportunities for improvement during quality
assurance activities.
Additional PA Explanatory Information
Objectivity in process quality assurance evaluations is critical to the success of the project.
Evaluators should not evaluate their own work. Personnel independent from the project
typically perform objective evaluations using defined criteria and a set of methods. These
evaluations are a check of the performed processes and resulting work products against
applicable process descriptions, standards, and procedures. Senior management takes an active
role in process quality assurance by regularly reviewing results and taking action as needed.
A typical project applying quality assurance will:
  Demonstrate more consistent process implementation
 Have better insight into the project’s results and issues
 Have better visibility into the project performance
Quality assurance verifies and ensures compliance with implementation to address issues such
as:
 Incorrect and incomplete requirements
 Insufficient release planning
 Unresolved defects
Often, the verification and validation processes evaluate the same work products as quality
assurance. Quality assurance focuses on determining that the verification and validation
activities are done by following their recorded processes. Verification focuses on satisfaction of
requirements. Validation ensures that the product works as intended in its target environment.
Promote an environment that encourages personnel to participate in identifying and reporting
quality issues.
Related Practice Areas
Verification and Validation (VV)
Context Specific
Agile with Scrum Guidance

Context Tag: Agile with Scrum

Context: Use processes to adapt agile with Scrum techniques.

An agile project using Scrum has many opportunities to objectively evaluate processes and work
products, such as when:
 Requirements are examined in the backlog review
 The Scrum Master facilitates the Scrum process
 Feedback on what was built is obtained in the sprint review
 The retrospective event allows the team to collect and organize lessons learned
Ensure that objective evaluations are integrated into the team’s techniques or rhythms, e.g., as
part of daily scrums, story point estimation, code reviews, use of tools, continuous integration,
and retrospectives.
An agile project using Scrum has many opportunities to objectively evaluate ceremonies and
work products, such as when:
 User stories are examined in the backlog grooming ceremony
 The Scrum Master coaches the team during scrum ceremonies
 Feedback on what was built is obtained in the sprint review
 The retrospective ceremony explores team behaviors and performers
  Management or peers observe Scrum ceremonies being performed using
techniques such as a gemba walk
Figure PQA-1 states where quality assurance activities would be performed in an agile project
using Scrum. Table PQA-1 shows example quality assurance results. Table-PQA 2 shows
example retrospective data that can be augmented by quality assurance activities.

Figure PQA-1: PQA in an Agile Framework

Table PQA-1: Example PQA Information

Table PQA-2: PQA Retrospective Information
Level 1

PQA 1.1
Required Practice Information
Practice Statement
Identify and address process and work product issues.
Value
Increases customer satisfaction through improved quality and performance.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Identify issues.
Record issues.
Resolve issues.

Example Work Products

Example Work Products Further Explanation
Recorded issues
Addressed issues Can be immediately addressed or changed in the future.
Level 2

PQA 2.1
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Organizations may not have enough quality assurance resources to review everything in a
project. Planning helps to optimize resource use and focus on the areas where the project is
most likely to have process or work product issues. Using historical data helps to identify areas
where applying resources will be most effective. Consider:
 Where issues have occurred in the past
 Quality trends
o May be positive or negative. Instances where there have been few issues
may not need quality resources applied to them, but areas where issues occur
repeatedly may need increased quality activities.
 Sources of best practices
 Common or recurring problems across projects
 Recent changes in processes
Plan activities and determine the type and resources needed for objective evaluations:
 Ensure qualified personnel who perform quality assurance activities participate in
developing plans, processes, standards, and procedures
 Identify and select processes and associated work products to be evaluated during
the project
 Determine how and when quality assurance activities, findings, and results will be
communicated and resolved within the organization
Example Activities
Example Activities Further Explanation
Develop, record, and keep updated the
quality approach and plan.
Identify areas for evaluation.
 Example Activities Further Explanation
Review, update, and approve the
approach with affected stakeholders.

Example Work Products

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

Related Practice Areas

Planning (PLAN)

PQA 2.2
Required Practice Information
Practice Statement
Throughout the project, objectively evaluate selected performed processes and work products
against the recorded process and applicable standards.
Value
Delivers high-quality solutions by identifying and addressing issues throughout the process
execution.
Additional Required Information
This section left blank for future content.
Explanatory Practice Information
Additional Explanatory Information
Identifying and addressing quality issues should be done throughout the project, and not just
at the end. Catching and addressing issues early reduces the amount of rework. This also
provides timely visibility into the quality of the processes and the resulting products. Objectivity
is critical to the success of quality assurance evaluations. Critical processes or work products
may require independence from the work performed as a way of achieving objectivity.
Objectivity can be achieved by using:
 Independent quality assurance organizations or groups
 Independent reviewers who:
o Are not involved in development or maintenance of the solution
o Work in a separate management reporting chain
 Criteria such as standards, guidelines, etc.
 Checklists based on process descriptions, standards, and procedures
Examples of objective evaluation methods include:
• Formal audits
• Peer reviews with objective reviewers, which can be performed at various levels of
formality
• In-depth review of work at the place it is performed, e.g., desk audits
• Distributed review and comment regarding work products
• Built-in or automated process checks to identify incorrectly performed processes,
e.g., Poka-yoke
Example Activities
Example Activities Further Explanation
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.
Example Work Products
Example Work Products Further Explanation
Criteria
Checklists
Evaluation reports
Noncompliance reports
Improvement proposals

PQA 2.3
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Noncompliance issues are problems identified when team members do not follow applicable
standards, recorded processes, or procedures. The status of noncompliance issues tracked over
time provides an indication of quality trends. Address and resolve noncompliance issues in the
project. Take actions to resolve non-compliance issues at the level closest to the occurrence of
the non-compliance whenever possible. Escalate noncompliance issues through the
management chain for resolution when needed.
Example Activities
Example Activities Further Explanation
Communicate and resolve each Consider reporting a compliance percentage rather than the
noncompliance issue. number of noncompliance issues for a project. Report quality
assurance activities, results, and issues to senior
management on a regular basis so they can take timely and
appropriate action.
Ways to resolve noncompliance issues include:
 Fixing the noncompliance
 Changing the applicable recorded processes, standards,
or procedures
 Obtaining a waiver to cover the noncompliance issue
and accept the associated risk
Track noncompliance issues to resolution.
 Example Activities Further Explanation
Escalate noncompliance issues when Escalation may continue through multiple layers of
they cannot be resolved. management levels until the issue is resolved.
Analyze noncompliance issues to These trends can then be used to focus future quality
identify quality trends. activities.
Ensure affected stakeholders are
aware of evaluation results and
quality trends.

Example Work Products

Example Work Products Further Explanation
Quality trend analysis reports
Noncompliance resolutions

PQA 2.4
Required Practice Information
Practice Statement
Record and use results of quality assurance activities.
Value
Using quality assurance results optimizes future quality assurance activities and reduces the
cost of future work.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
This section left blank for future content.
Example Activities
Example Activities Further Explanation
Record and keep updated information Record information about quality assurance activities with
about quality assurance activities. enough detail to clarify status and results.
Noncompliance issues recorded as part of the peer review
report are tracked and escalated outside the project
when necessary.

Example Work Products

Example Work Products Further Explanation
Evaluation records
Quality assurance reports
 Example Work Products Further Explanation
Status reports of non-compliance
issues and corrective actions
Reports of quality trends
Level 3

PQA 3.1
Required Practice Information
Practice Statement
Identify and record opportunities for improvement during quality assurance activities.
Value
Identifying more efficient and effective ways to perform work improves the organization’s
capability to meet its goals and objectives.
Additional Required Information
This section left blank for future content.
Explanatory Practice Information
Additional Explanatory Information
Quality assurance includes:
 Evaluating the process as performed
 Identifying ways that the process can be improved
 Submitting improvement proposals
Quality assurance personnel should work closely with process management to ensure an
efficient and effective process is deployed, followed, and maintained. Through this relationship,
the process is continuously maintained and improved.
Example Activities
Example Activities Further Explanation
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.

Example Work Products

Example Work Products Further Explanation
Improvement proposals
 Product Integration (PI)

Required PA Information
Intent
Integrate and deliver the solution that addresses functionality and quality requirements.
Value
Increases customers’ satisfaction by giving them a solution that meets or exceeds their
functionality and quality requirements.
Additional Required PA Information
This section left blank for future content.
Explanatory PA Information
Practice Summary
Level 1
PI 1.1 Assemble solutions and deliver to the customer.
Level 2
PI 2.1 Develop, keep updated, and follow an integration strategy.
PI 2.2 Develop, keep updated, and use the integration
environment.
PI 2.3 Develop, keep updated, and follow procedures and criteria for
integrating solutions and components.
PI 2.4 Confirm, prior to integration, that each component has been
properly identified and operates according to its requirements and
design.
PI 2.5 Evaluate integrated components to ensure conformance to the solution’s
requirements and design.
PI 2.6 Integrate solutions and components according to the integration strategy.
Level 3
PI 3.1 Review and keep updated interface or connection descriptions for
coverage, completeness, and consistency throughout the solution’s life.
PI 3.2 Confirm, prior to integration, that component interfaces or
connections comply with interface or connection descriptions.
PI 3.3 Evaluate integrated components for interface or connection compatibility.
Additional PA Explanatory Information
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.
Related Practice
Areas Technical
Solution (TS) Context
Specific
Agile with Scrum Guidance

Context Tag: Agile with Scrum

Context: Use processes to adapt agile with Scrum techniques.

Agile teams using Scrum typically employ automation and DevOps processes for unit testing,
regression testing, system testing, and continuous builds, to reduce human effort as much as
possible. These techniques increase productivity and help to detect defects early in the product
development lifecycle. An agile team using Scrum following processes that meet the intent of
Product Integration practices also ensure that the necessary tools and environment are
planned, and that component functionality and interfaces or connections are checked for
errors before integration
Services

Context Tag: CMMI-SVC

Context: Use processes to deliver, manage, and improve services to meet customer needs.
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.
Level 1

PI 1.1
Required Practice Information
Practice Statement
Assemble solutions and deliver to the customer.
Value
Enables customer satisfaction by delivering a usable solution.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Assemble solution.
Record all necessary information to Necessary information may include:
install and use the solution.  Configuration
 Solution component types and serial numbers
 Physical and functional layout
 Installation and tracking information
 Contact information
Use applicable methods to package Documentation packaging and delivery methods may
and deliver the solution. include:
 Hardcopy documents
 CDs or DVDs
 Online help
 Cloud-based repository
 EBooks
 Mobile applications
 Website links for downloads
Deliver the solution and related
documentation; confirm receipt.

Example Work Products

Example Work Products Further Explanation
Assembled solutions and related
documentation
Level 2

PI 2.1
Required Practice Information
Practice Statement
Develop, keep updated, and follow an integration strategy.
Value
Ensures that the product will meet customer requirements given available resources.
Additional Required Information
The product integration strategy includes how the:
 Solutions and components will be integrated and evaluated, i.e., as a single build or
a series of builds
 Interfaces or connections will be managed
 Integration environment will be developed
 Evaluation results will be recorded
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Identify and record product
components to be integrated.
Identify how solutions and components This includes verifications and validations to be performed on
will be verified and validated during interfaces or connections.
integration.
Identify alternative integration Possible strategies include:
strategies.  Big bang
 Incremental
 Top-down
 Bottom-up
Select the best integration strategy. Align the integration strategy to availability of:
 Product components
 The integration environment
 Test tools and equipment
 Example Activities Further Explanation
 Procedures and criteria
 Affected stakeholders
 People with the appropriate skills
Periodically review the product Ensure that changes in production and delivery schedules
integration strategy and revise it as have not adversely impacted the integration sequence.
needed.
Record and communicate decision
rationale and status.

Example Work Products

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

Related Practice Areas

Decision Analysis and Resolution (DAR)
PI 2.2
Required Practice Information
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.
Additional Required Information
Verify and validate the integration environment before use.
Explanatory Practice Information
Additional Explanatory Information
The integration environment can either be acquired or developed. When developing the
integration environment, consider reusing existing organizational resources and perform make,
buy, or reuse analyses. Environment requirements can include equipment, software, or other
resources.
The environment required at each step of the integration process can include test equipment,
simulators (taking the place of unavailable product components), product components, and
recording devices.
The product integration environment can be a major development for first-time or complex
projects. For small development efforts, the integration environment may be as simple as
a directory structure.
Example Activities
Example Activities Further Explanation
Develop requirements for the
integration environment.
Develop verification and validation This is for validating the integration environment and not for
procedures and criteria for the integrating the product.
integration environment. Verify and validate the integration environment to ensure it
satisfies the requirements in accordance with the integration
strategy.
Decide whether to build, buy, or reuse This can be the whole environment or just parts of it.
the integration environment.
Develop or acquire an integration Examples of activities in developing or acquiring an
environment. integration environment include:
 Planning
 Requirements development
 Technical solutions
 Verification
 Validation
 Risk management
 Example Activities Further Explanation
Verify and validate the integration
environment.
Use the integration environment. The integration environment may be used for testing and
other preparation work prior to solution and component
integration.
Revise the integration environment as Dispose of integration environment parts that are no longer
needed. useful.
Communicate with affected
stakeholders.

Example Work Products

Example Work Products Further Explanation
Verified and validated environment for
product integration
Build, buy, or reuse analyses
Support documentation for the
integration environment

Related Practice Areas

Decision Analysis and Resolution (DAR)
Requirements Development and Management (RDM)
Verification and Validation (VV)

PI 2.3
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Communicate schedule and integration status with affected stakeholders to reduce the risk of
delays and failures.
Example Activities
Example Activities Further Explanation
Develop, use, and keep updated
product integration procedures for
the product components.
Develop, use, and keep updated
criteria for product component
integration and evaluation.
Record, keep updated, and
communicate the product integration
procedures and criteria.

Example Work Products

Example Work Products Further Explanation
Product integration procedures
Product integration criteria

PI 2.4
Required Practice Information
Practice Statement
Confirm, prior to integration, that each component has been properly identified and operates
according to its requirements and design.
Value
Helps reduce total development cost, integration cycle time, and rework.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Track the integration readiness status
of the components.
Ensure components are delivered to
the product integration environment
as described in the product integration
strategy and procedures.
Confirm each component is correctly
identified and received.
Verify and validate that each received
component meets its requirements and
design.
Check the status of the current
configuration against the expected
configuration.
Check all the physical interfaces or For example, check by a visual inspection or using basic
connections before integrating product counts of interfaces or connections.
components.
Communicate results with affected
stakeholders.

Example Work Products

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

Related Practice Areas

Verification and Validation (VV)
PI 2.5
Required Practice Information
Practice Statement
Evaluate integrated components to ensure conformance to the solution’s requirements and
design.
Value
Helps to ensure customer requirements are correctly implemented.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Evaluate integrated components,
interfaces or connections, and testing
using the integration strategy,
procedures, and criteria.
Record and communicate evaluation Example results include:
results.  Integration procedure or criteria changes
 Product configuration changes (spare parts, new release)
 Deviations from evaluation procedures or criteria
 Defects and exceptions

Example Work Products

Example Work Products Further Explanation
Integration evaluation reports
Interface or connection evaluation reports
Test reports
Exception reports
Related Practice Areas
Verification and Validation (VV)

PI 2.6
Required Practice Information
Practice Statement
Integrate solutions and components according to the integration strategy.
Value
Ensures that the customer receives a solution that meets requirements and design.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Integration and evaluation activities can be performed iteratively. Evaluate integrated
components before proceeding to the next integration iteration.
Example Activities
Example Activities Further Explanation
Confirm readiness of the product
integration environment.
Integrate components according to the Record all appropriate component information.
product integration strategy,
procedures, and criteria.
Update the product integration
strategy, procedures, and criteria as
needed.
Integrate and deliver the product and Integration and delivery should address requirements for:
communicate results.  Safety
 Environment protection
 Security
 Transportability
 Disposal
Examples of requirements and standards for packaging and
delivering include:
 Type of storage and delivery media
 Required documentation
 Copyrights
 License provisions
 Preparation of the operational site for product installation
 Example Activities Further Explanation
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.

Example Work Products

Example Work Products Further Explanation
Integrated solution or components
Exception or test reports
Level 3

PI 3.1
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Start managing component interfaces or connections early in the development of the project.
Interfaces or connections include:
 Product component interfaces or connections
 Interfaces or connections with other solutions, systems, or components
 Interfaces or connections with specific environments which may include:
o Verification
o Validation
o Operations
o Support
Interface or connection definitions and designs can affect verification and validation
environments in addition to the components and external systems. Ensure that interface or
connection changes are recorded, maintained, and readily accessible.
Managing interfaces or connections includes maintaining their consistency throughout the life of
the solution, complying with architectural decisions and constraints, and resolving conflicts or
changes. Managing interfaces or connections between solutions acquired from suppliers and
other products or product components is critical for the success of the work.
Example Activities
Example Activities Further Explanation
Review with affected stakeholders and Interfaces or connections are usually classified in three main
keep updated interface or connection classes:
descriptions for coverage,  Environmental
completeness, and consistency  Physical
throughout the product’s life.  Functional
 Example Activities Further Explanation
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
affected stakeholders.

Example Work Products

Example Work Products Further Explanation
Interface or connection review results
List of action items for updating
interfaces or connections
Updated interface or connection
descriptions

Related Practice Areas

Requirements Development and Management (RDM)
Verification and Validation (VV)
Context Specific
Services

Context Tag: CMMI-SVC

Context: Use processes to deliver, manage, and improve services to meet customer needs.

In the context of service systems, interfaces or connections can fit into one of four major
groups: person-to-person, person-to-component, component-to-component, and compound
interfaces:
 Person-to-person interfaces are interfaces or connections that represent direct
or indirect communication between two or more people
o These people can include service provider personnel or end users
o For example, a call script (which defines how a help desk operator
should interact with an end user) defines a direct person-to-person
interface
o Log books and instructional signage are examples of indirect person-to-
person interfaces
  Person-to-component interfaces are interfaces or connections that encompass
interactions between a person and one or more service system components
o These interfaces or connections can include both graphical user interfaces
for automated components, e.g., software applications; and operator control
mechanisms for automated; partially automated; and non-automated
components, e.g., equipment, vehicles
 Component-to-component interfaces are interfaces or connections that do not include
direct human interaction
o This includes the interfaces of interactions between automated components
and other possibilities, such as specifications limiting the physical interaction of
two components, e.g., a delivery truck and a loading dock
 Compound interfaces are interfaces or connections that merge or layer
together interfaces from more than one of the other three groups
o For example, an online help system with live chat support might have a
compound interface built on an integrated combination of person-to-
person, person-to-component, and component-to-component interfaces
Interfaces can be external or internal:
 External interfaces are interactions among components of the service system and any
other entity external to the service system, including people, organizations, and
systems
 Internal interfaces can include interactions among personnel, teams, and functions of the
service provider organization; internal interfaces can also include interaction between
personnel or end users and service system components
Examples of user interface work products include:
 Customer interaction scripts
 Reporting types and frequency
 Application program interfaces

PI 3.2
Required Practice Information
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.
Additional Required Information
This section left blank for future content.
Explanatory Practice Information
Additional Explanatory Information
This section left blank for future content.
Example Activities
Example Activities Further Explanation
Compare interface or connection This comparison may include:
descriptions with component interfaces  Performing a pre-check of all the physical interfaces
or connections and identify non- or connections before integrating components
compliances.  Performing a functional review of external
component interfaces or connections
 Confirming that verification and validation activities were
completed
Address interface or connection non-
compliances and communicate results.

Example Work Products

Example Work Products Further Explanation
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
Updated interface or connection
descriptions or component interfaces
or connections

Context Specific
Services

Context Tag: CMMI-SVC

Context: Use processes to deliver, manage, and improve services to meet customer needs.

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
Required Practice Information
Practice Statement
Evaluate integrated components for interface or connection compatibility.
Value
Reduces the risk of interface or connection failure within integrated components.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Evaluate the integrated components Compatibility may include:
for compatibility.  Alignment with specifications
 Functionality
 Reliability
Record and communicate the Example results include:
evaluation results.  Integration procedure or criteria changes
 Product configuration changes (spare parts, new release)
 Interface or connection and interface or
connection description changes
 Deviations from evaluation procedures or criteria
 Interface or connection defects

Example Work Products

Example Work Products Further Explanation
Interface or connection issues reports

Context Specific
Services

Context Tag: CMMI-SVC

Context: Use processes to deliver, manage, and improve services to meet customer needs.
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.
 Requirements Development and Management (RDM)

Required PA Information
Intent
Elicit requirements, ensure common understanding by stakeholders, and align requirements,
plans, and work products.
Value
Ensures that customers’ needs and expectations are satisfied.
Additional Required PA Information
This section left blank for future content.
Explanatory PA Information
Practice Summary
Level 1
RDM 1.1 Record requirements.
Level 2
RDM 2.1 Elicit stakeholder needs, expectations, constraints, and interfaces or
connections.
RDM 2.2 Transform stakeholder needs, expectations, constraints, and interfaces
or connections into prioritized customer requirements.
RDM 2.3 Develop an understanding with the requirements providers on the
meaning of the requirements.
RDM 2.4 Obtain commitment from project participants that they can
implement the requirements.
RDM 2.5 Develop, record, and maintain bidirectional traceability
among requirements and activities or work products.
RDM 2.6 Ensure that plans and activities or work products remain consistent with
requirements.
Level 3
RDM 3.1 Develop and keep requirements updated for the solution and
its components.
RDM 3.2 Develop operational concepts and scenarios.
RDM 3.3 Allocate the requirements to be implemented.
RDM 3.4 Identify, develop, and keep updated interface or connection
requirements.
 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.
Additional PA Explanatory Information
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
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.
Related Practice Areas
Peer Reviews (PR)
Verification and Validation (VV)
Context Specific
Agile with Scrum Guidance

Context Tag: Agile with Scrum

Context: Use processes to adapt agile with Scrum techniques.

Figure RDM-1 states where requirements activities are performed in an agile project using
Scrum. Figure RDM-2 shows a top-level summary of requirements information and in which
sprint those requirements are addressed.
 Figure RDM-1: RDM in an Agile Framework

Figure RDM-2: Requirements Information

Requirements Development and Management practices can strengthen the typical agile project
by adding greater requirements understanding, clarity, and discovery of issues. Requirements
Development and Management practices add early consideration of other requirement types
beyond the user stories typically used by an agile project using Scrum. Practices in this PA also
add performing analyses to find errors and risks while conducting the requirements definition
activities. For example, agile expects user needs to be elicited as a backlog of user stories, but
a backlog does not typically include constraints, interfaces or connections, and quality
attributes. RDM practices provide a means for capturing and addressing these attributes
during the sprints. Requirements Development and Management practices provide a robust
infrastructure to support requirements development for complex solutions.
These practices can be added iteratively to improve any agile project using Scrum during
backlog creation, grooming, and sprint execution.
Table RDM-1 shows where Requirements Development and Management practices can
augment a typical agile project using Scrum.
 Table RDM-1
Agile Projects using Scrum Requirements Development and Management
Release planning Earlier and more complete understanding of the solution and
risks.
Backlog grooming/review Broader and deeper analysis of user stories or epics to
discover potential issues or constraints. Additionally, these
analyses will identify risks.
Sprint planning Presentation of stories by the product owner, review
acceptance by the team, and estimate of the user stories to
be delivered during the upcoming sprint.
Sprint execution More of the project is spent developing a working solution
vs. refactoring.
Sprint review/demo Enables a more thorough understanding of what has been
accomplished during the sprint.
Sprint retrospective Collaborative sessions where the agile team’s culture,
process, and performance is reviewed

Agile projects using Scrum typically will implement traceability from business need through
epics, user stories, tasks, tests, and the definition of done. Designs and code are often traced
directly to user stories. Traceability enables more efficient and accurate consistency checks
between requirements (user stories or epics) and work products. Traceability also improves the
ability to understand and addresses what is impacted by a requirement (user story or epic)
change.
Development

Context Tag: CMMI-DEV

Context: Use processes to develop quality products and services to meet the needs of
customers and end users.

For product lines, engineering processes (including requirements development) may be applied
at multiple levels. At the product line level, perform a “commonality and variation analysis” to
help elicit, analyze, and develop core assets for use by projects within the product line. At the
project level, use these core assets per the product line plan as part of the project’s engineering
activities.
Supplier Management

Context Tag: CMMI-SPM

Context: Use processes to identify, select, and manage suppliers and their agreements.

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

RDM 1.1
Required Practice Information
Practice Statement
Record requirements.
Value
Recorded requirements are the basis for successfully addressing customer needs and
expectations.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Record the requirements.

Example Work Products

Example Work Products Further Explanation
Recorded requirements Examples include:
 List of requirements
 Statement of work
 Use cases
Level 2

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

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

Example Work Products

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

Example Work Products

Example Work Products Further Explanation
Lists of appropriate requirements
providers
Criteria for evaluation and acceptance
of requirements
Results of analyses against criteria
Recorded changes to requirements
Set of approved requirements Reflects the shared understanding between the project and
the customers.

RDM 2.4
Required Practice Information
Practice Statement
Obtain commitment from project participants that they can implement the requirements.
Value
Ensures commitments are well understood to minimize delays and rework.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Assess the impact of requirements on
existing commitments.
Negotiate and record commitments. Negotiate commitments before work starts
Example Work Products
Example Work Products Further Explanation
Impact assessment Estimate the cost, and the impact to quality, risk, and
schedule.
Recorded commitments that Recorded commitments may be in the form of:
requirements can be met  Meeting minutes
 Sign-off documents
 Email acknowledgements
 May address resources and schedule.

Context Specific
Supplier Management

Context Tag: CMMI-SPM

Context: Use processes to identify, select, and manage suppliers and their agreements.

The acquirer negotiates with the customer and supplier before committing to a requirement
change. A requirements change can lead to modifications to supplier agreements. Ensure the
acquirer, supplier, and customer agree on these changes after appropriate negotiations. In
some acquisitions, the acquirer may represent, and act on behalf of the customer. Deliverables
may include impact assessments when a requirement change occurs.

RDM 2.5
Required Practice Information
Practice Statement
Develop, record, and maintain bidirectional traceability among requirements and activities or
work products.
Value
Ensures consistency between requirements and the solution which increases the likelihood of
customer satisfaction.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Traceability from source requirements to the solution ensures that:
 Requirements have been completely addressed in customer deliverables
 Lower level requirements can be traced to a valid source
 Requirements are implemented
 Selected requirements are verified and validated
  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
Example Activities Further Explanation
Develop, record, and keep updated Trace requirements from their source through intervening
bidirectional requirements traceability. work products to the customer deliverable

Example Work Products

Example Work Products Further Explanation
Records of bidirectional requirements
traceability

Context Specific
Services

Context Tag: CMMI-SVC

Context: Use processes to deliver, manage, and improve services to meet customer needs.

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

Context Tag: CMMI-SPM

Context: Use processes to identify, select, and manage suppliers and their agreements.

The acquirer maintains overall bidirectional traceability between customer requirements and the
solution. The supplier maintains bidirectional traceability between the solution, the solution
components, and the requirements defined in the supplier agreement. The acquirer verifies that
traceability. The supplier also maintains traceability from contractual requirements to derived or
additional requirements.

RDM 2.6
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
This section left blank for future content.
Example Activities
Example Activities Further Explanation
Review plans, activities, and projects Maintaining bidirectional traceability is critical to maintaining
for consistency with requirements and consistency between requirements, work products, and
changes made to them. plans.
Record inconsistencies and their Identify any changes that should be made to plans and
sources. projects resulting from changes to the requirements.
Initiate and record any necessary
corrective actions and communicate
results to affected stakeholders.
Example Work Products
Example Work Products Further Explanation
Records of inconsistencies between
requirements, plans, and work
products
Corrective actions
Level 3

RDM 3.1
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
This section left blank for future content.
Example Activities
Example Activities Further Explanation
Develop, record, and keep updated
requirements in technical terms
necessary for solution and solution
component design.
Derive, record, and keep updated
requirements that result from solution
selections and design decisions.
Record and keep updated bidirectional
traceability.
Review requirements for potential
impact to architecture and design.
Record and keep updated prioritization
of requirements.
Record and keep updated nontechnical
requirements.
Identify, record, and keep updated
requirements for external and internal
interfaces or connections.

Example Work Products

Example Work Products Further Explanation
Requirements May include:
 Solution requirements
 Example Work Products Further Explanation
 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

Context Tag: CMMI-DEV

Context: Use processes to develop quality products and services to meet the needs of
customers and end users.

Selection of a technology brings with it additional requirements. For instance, use of electronics
requires additional technology-specific requirements such as electromagnetic interference limits.
Services

Context Tag: CMMI-SVC

Context: Use processes to deliver, manage, and improve services to meet customer needs.

Analyze stakeholder requirements while developing the operational concept to derive more
detailed and precise sets of requirements called derived requirements. These requirements
address all aspects of the service system associated with service delivery, including work
products, services, processes, consumables, customer resources, other resources, warranty
costs, service incentives, and the functionality and quality attribute needs of affected
stakeholders.
In some service contexts, derived requirements can be as simple as identifying and quantifying
required resources. For complex service systems with many types of components and
interfaces, iteratively refine the initial requirements into lower level sets of more detailed
requirements that can be allocated to service system components as the preferred solution is
refined.
Develop the functionality and quality attribute requirements for the service system through this
analysis and through refinement, derivation, and allocation activities.

RDM 3.2
Required Practice Information
Practice Statement
Develop operational concepts and scenarios.
Value
Enables customers to understand, confirm, and commit to how their requirements will be met.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
A scenario describes a sequence of events that:
 Includes user and product interactions
 May occur in the development, use, or sustainment of the product
An operational concept provides:
 A view of the system or product from the user perspective
 A context for developing or evaluating a set of scenarios
Operational concepts and scenarios together demonstrate what the requirements are trying to
accomplish. For example, the operational concept for a satellite-based communications product
is quite different from one based on landlines. The scenario would cover the steps in the
communication process.
Example Activities
Example Activities Further Explanation
Develop, record, and keep updated Identify and develop scenarios, consistent with the level of
operational concepts and scenarios. detail in the stakeholder needs, expectations, and
constraints.
Ensure scenarios address quality attribute, functions, or
other factors.
Iteratively refine operational concept and scenarios to
include more detail as decisions are made and as lower level
requirements are developed; for example, describe
interactions among the:
 Solution
 End users
 Environment
 Boundaries and constraints
Review operational concepts and
scenarios with affected stakeholders to
refine and discover requirements.

Example Work Products

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

Example Work Products

Example Work Products Further Explanation
Requirement allocations
Context Specific
Supplier Management

Context Tag: CMMI-SPM

Context: Use processes to identify, select, and manage suppliers and their agreements.

Allocate contractual requirements, as appropriate, to supplier deliverables. Record the

requirements for each supplier deliverable. In some cases, technical requirements are allocated
to third-party solutions that the supplier uses, e.g., COTS products.
Example acquirer activities include:
 Allocating requirements to suppliers
 Allocating requirements to supplier deliverables
 Allocating design constraints and record relationships among allocated requirements
and design constraints
 Developing an approach to address requirements shared among multiple stakeholders,
e.g., the acquirer, multiple suppliers, customers, end users

RDM 3.4
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Identify interfaces or connections between functions, objects, or other logical entities.
Interfaces or connections can be internal or external to a solution. Define interface or
connection requirements between solutions or solution components identified in the
architecture. Interfaces or connections are controlled as part of solution integration. Ensure
interface or connection requirements are reviewed by affected stakeholders. This is typically
done within the context of a control group of stakeholders.
Example Activities
Example Activities Further Explanation
Identify, record, and keep updated As the design progresses, the architecture will be altered by
internal and external interface or technical solution processes, developing new interfaces or
connection requirements.
 Example Activities Further Explanation
connections between internal components and components
external to the solution.
Management of the interfaces or connections may include:
 Maintaining consistency of the interface or connection
 Complying with architectural decisions and constraints
 Resolving conflict, non-compliances, and change issues
Review interface or connection Review the interface or connection descriptions with affected
requirements for coverage and stakeholders to:
completeness with affected  Avoid misinterpretations
stakeholders, and record results.  Reduce delays
 Prevent the development of interfaces or connections
that do not work properly

Example Work Products

Example Work Products Further Explanation
Interface or connection requirements May include:
 Categories with lists of interfaces or connections
 Requirements defined for each set of solution components
Interface or connection requirements
review results
Action items for updating interface or
connection requirements
Updated interface or connection
requirements

Related Practice
Areas Product
Integration (PI)
Technical Solution
(TS) Context Specific
Development

Context Tag: CMMI-DEV

Context: Use processes to develop quality products and services to meet the needs of
customers and end users.

Define requirements for interfaces in terms such as:

 Software
o Origination
o Destination
o Stimulus
o Data characteristics
 o Communication interfaces, e.g., protocols such as HTTP, FTP
o User interfaces, e.g., screen layout, font, buttons
 Hardware
o Electrical
o Mechanical
o Hydraulic
o Physical connections
o Power characteristics
o Radiation
o Thermal
o Safety
o Security

RDM 3.5
Required Practice Information
Practice Statement
Ensure that requirements are necessary and sufficient.
Value
Avoids rework by only delivering necessary solutions.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities
Example Activities Further Explanation
Perform a requirements analysis to Analyze requirements to ensure they are:
determine if requirements are  Relevant
necessary and sufficient.  Complete
 Feasible
 Maintainable
 Not in conflict
Analyze operational concepts and scenarios to refine
customer needs, constraints, and interfaces or connections,
and to discover new requirements. This analysis can result in
more detailed operational concepts and scenarios and
supports deriving new requirements.
Review analysis results with
stakeholders.
Update requirements based on review
results.

Example Work Products

Example Work Products Further Explanation
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
Required Practice Information
Practice Statement
Balance stakeholder needs and constraints.
Value
Increases stakeholder satisfaction while addressing conflicting requirements and constraints.
Additional Required Information
This section left blank for future content.
Explanatory Practice Information
Additional Explanatory Information
The intent of this practice is to ensure an understanding and agreement between the project
and the customer about what is delivered given resource constraints. This typically involves
negotiating benefits and tradeoffs with customers and other stakeholders. When costs and
issues outweigh the benefits, consult affected stakeholders to determine what changes may be
needed.
Stakeholder needs and constraints can address:
 Cost
 Schedule
 Performance
 Functionality
 Quality
 Priorities
 Resources
 Reusable components
 Maintainability
 Risk
Analyze requirements to determine whether they reflect an appropriate balance among cost,
schedule, performance, quality, customer needs, and other factors of interest to affected
stakeholders. Models and simulations can be used to estimate the impact that requirements will
have on these factors. Involve stakeholders in the analysis of impacts and issues from different
phases of the solution’s lifecycle. If the issues are considered unacceptable, revise or reprioritize
the requirements to improve the balance of cost, schedule, performance, and quality.
Example Activities
Example Activities Further Explanation
Analyze requirements to ensure Analysis includes use of:
that they balance stakeholder needs  Models
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
Review, analyze and negotiate
requirements tradeoffs with customers
and stakeholders.
Record and keep updated proposed
requirements changes and
communicate with affected
stakeholders.
Example Work Products
Example Work Products Further Explanation
Analysis results Includes:
 Identification of where costs, schedule, performance,
quality, and other factors exceed constraints
 Assessment of risks related to requirements
Proposed requirements changes

Related Practice Areas

Risk and Opportunity Management (RSK)
Context Specific
Services

Context Tag: CMMI-SVC

Context: Use processes to deliver, manage, and improve services to meet customer needs.

Analyze requirements and define required service system functionality and quality attributes to
balance the stakeholders’ needs, expectations, constraints, and interfaces or connections.
Depending on the service delivery context, consider factors such as feasibility, business
objectives and needs, cost constraints, end user types, potential market size, and procurement
strategy. Determine the parameters used to evaluate the effectiveness of service delivery based
on customer and end user input and the preliminary service delivery concept.
Example Activities
Example Activities Further Explanation
Develop and keep updated a definition This definition can include descriptions, breakdowns, and
of required functionality and quality
categorizations of the service’s functions.
attributes.
In addition, the definition specifies design considerations or
constraints on how to achieve the required functionality in
the service system. Some quality attributes will emerge as
architecturally significant and drive subsequent service
system high-level design activities. A clear understanding of
the quality attributes and their importance based on
business objectives or needs is essential to the design
process.
Validate requirements to ensure the
resulting service system will perform
as intended in the end user’s
environment.
Example Work Products
Example Work Products Further Explanation
Operational concepts and scenarios,
use cases, activity diagrams, and user
stories
Service system and service system
component installation, training,
 Example Work Products Further Explanation
operational, maintenance, support, and
disposal concepts
Definition of required functionality and
quality attributes
Architecturally significant quality
attribute requirements
New requirements
Requirement defect reports and
proposed changes to resolve
Assessments of risks related to
requirements
Records of analysis methods and
results
Supplier Management

Context Tag: CMMI-SPM

Context: Use processes to identify, select, and manage suppliers and their agreements.

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
Required Practice Information
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.
Additional Required Information
This section left blank for future content.
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Identify and select validation To broaden and deepen understanding of requirements, use
techniques. multiple validation techniques such as:
 Functional analysis
 Simulation
 Prototypes
 Demonstrations
 Tests
 Reviews or walk-throughs
Validate the requirements using
selected techniques and record results.
Review and communicate validation
results with stakeholders.
Update requirements.

Example Work Products

Example Work Products Further Explanation
Selected validation techniques
Record of validation results
Updated requirements

Related Practice Areas

Verification and Validation (VV)
 Risk and Opportunity Management (RSK)

Required PA Information
Intent
Identify, record, analyze, and manage potential risks or opportunities.
Value
Mitigate adverse impacts or capitalize on positive impacts to increase the likelihood of meeting
objectives.
Additional Required PA Information
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.
Explanatory PA Information
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
affected stakeholders.
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.
Additional PA Explanatory Information
Risk and opportunity management is a continuous, forward-looking process and includes:
 Identifying and mitigating potential negative impacts that may make it difficult to
meet objectives
 Identifying and leveraging potential positive impacts for improving performance
or progress towards achieving objectives
 All levels of an organization
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.
Related Practice
Areas Planning
(PLAN) Context
Specific
Agile with Scrum Guidance

Context Tag: Agile with Scrum

Context: Use processes to adapt agile with Scrum techniques.

Figure RSK-1 states where risk and opportunity management activities can be performed in
an agile project using Scrum. Table RSK-1 shows a simple example of a risk and opportunity
log. Figure RSK-2 shows a risk burndown chart showing total risks decreasing and
opportunities increasing over time.
 Figure RSK-1: RSK in an Agile Framework

Table RSK-1: Example Risk and Opportunity Log

 Figure RSK-2: Example Risk Burndown Chart

As an empirical framework, agile with Scrum, does not define specific practices and processes
for risk and opportunity management. Risk and opportunity management is performed using of
visual information indicators, daily standups, short sprints (iterations) with frequent feedback,
and close collaboration within teams and customers. Some agile teams reduce technical risk by
using “spikes,” or rapid prototypes performed early in the project. Risk and opportunity
management can be easily added to the planning, execution, and retrospective activities of
each sprint, or selected sprints. During each activity, spend a few minutes updating the risk
and opportunity information like that shown in Table RSK-1 and Figure RSK-2.
Level 1

RSK 1.1
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Identify and describe risks or opportunities clearly.
Example Activities
Example Activities Further Explanation
Identify the risks associated with the Identify and clearly describe risks that could negatively affect
work. work and plans. Risk identification should consider:
 Cost
 Schedule
 Work tasks
 Performance
 Achievement of business objectives
 Environmental concerns, e.g., weather or natural
disasters, political changes, or telecommunications failures
 Requirements
 Technology
 Staffing
 Funding
 Suppliers
 Regulatory constraints
Perform risk identification and management during planning
and review activities.
Record the risks. State the risk and the impact of its occurrence.
Identify opportunities. Identify and clearly describe opportunities that could
positively affect work and plans. For example:
 Cost
 Schedule
 Work tasks
 Performance
 Achievement of business objectives
 Requirements
 Technology
 Example Activities Further Explanation
 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.

Example Work Products

Example Work Products Further Explanation
List of identified risks or opportunities Include context, conditions, and consequences of risks or
benefits of opportunities.
Level 2

RSK 2.1
Required Practice Information
Practice Statement
Analyze identified risks or opportunities.
Value
Increases the likelihood of achieving objectives by reducing the impact of risks or leveraging
opportunities.
Additional Required Information
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.
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Analyze the identified risks. Analyze risks to understand their effect on achieving the
work’s objectives.
Examples of risk identification and analysis techniques
include:
 Assessments
 Checklists
 Structured interviews
 Brainstorming
 Failure Mode and Effects Analysis (FMEA)
 Failure Mode, Effects and Criticality Analysis (FMECA)
 Strength, Weakness, Opportunity, and Threat
(SWOT) analysis
 Poka-yoke analysis
Review the work breakdown structure,
plan, and schedule for risks.
Identify the impact of each risk.
Identify the probability of occurrence
for each risk.
 Example Activities Further Explanation
Assign priorities to each risk based on
the impact and probability of
occurrence.
Analyze the identified opportunities. Examples of opportunity identification and analysis
techniques include:
 Assessments
 Checklists
Review the work breakdown structure,
plan, and schedule for opportunities.
Identify the benefits and costs of each
opportunity.
Assign priorities to each opportunity
based on the benefit and cost.
Rank opportunity according to
priorities.
Review assigned opportunity priorities
with affected stakeholders and get
agreement.
Develop the risk and opportunity Include a list of prioritized risks or opportunities.
analysis report.

Example Work Products

Example Work Products Further Explanation
Identified risks or opportunities These include:
 Risk impact and probability of occurrence
 Opportunity benefit and cost
Risk or opportunity priorities
Risk and opportunity analysis reports

RSK 2.2
Required Practice Information
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.
Additional Required Information
This section left blank for future content.
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Periodically review risks or Review risks or opportunities in the context of status,
opportunities. circumstance, and past or planned activities.
Update risks or opportunities as Risks or opportunities may be revised when:
additional information becomes  New risks or opportunities are identified
available.  Corrective or leveraging actions are taken
 Risks are retired
 Opportunities are accepted
 Circumstances change significantly
Communicate the risk or opportunity Examples of risk or opportunity status include a change in
status to affected stakeholders. the:
 Probability of occurrence
 Costs or benefits
 Priority
 Impact on objectives

Example Work Products

Example Work Products Further Explanation
Records of risk or opportunity
monitoring
Updated risks or opportunities
Level 3

RSK 3.1
Required Practice Information
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.
Additional Required Information
Include the name and a brief description for each category.
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Identify risk or opportunity categories. Consider internal and external categories, such as:
 Work activities
 Types of processes used
 Types of resources used
 Types of solutions produced
 Regulations and laws
 Work management uncertainties, e.g., related
to contracts, budget, schedule, quality,
resources
 Technical performance uncertainties, e.g., related to
quality characteristics, reliability
Organize risks or opportunities Related or equivalent risks or opportunities can be organized
according to defined categories. for efficient handling.

Example Work Products

Example Work Products Further Explanation
Categories list
Categorized risks or opportunities
RSK 3.2
Required Practice Information
Practice Statement
Define and use parameters for risk or opportunity analysis and handling.
Value
Identifying high priority risks or opportunities maximizes the likelihood of cost-effectively
achieving objectives.
Additional Required Information
Parameters include:
 Probability of occurrence
 Impact
 Expected outcomes
Explanatory Practice Information
Additional Explanatory Information
Use defined parameters to:
 Determine the severity of the risk
 Estimate the benefit of the opportunity
 Prioritize the actions required for planning
 Select the opportunities to pursue
Parameters for evaluating, categorizing, and prioritizing include:
• Probability, e.g., likelihood of occurrence
• Impact, e.g., consequence and severity of occurrence
• Thresholds to trigger actions
• Expected benefit from opportunity
• Expected cost of opportunity
Parameters are often used in combination when prioritizing risks or opportunities. For example:
 Set priorities by multiplying probability times impact
 Calculate an opportunity value by subtracting the expected cost from the expected
return.
Example Activities
Example Activities Further Explanation
Identify a relative priority for each risk
or opportunity based on assigned
parameters.
 Example Activities Further Explanation
Define thresholds to trigger actions for Identify which thresholds require a:
selected risks or opportunities.  Mitigation activity
 Contingency plan
 Opportunity action plan
Prepare and perform assessments for Risk assessments focus the components of the risk strategy
selected risks. on analyzing a specific situation and risk. Examples of risk
assessments include:
 Exploitation
 Malicious uses
 Safety
 Regulations and laws
 Cyber security
Prepare and perform opportunity Examples of opportunity assessments include:
assessments.  Cost benefit analyses
 Future needs analyses

Example Work Products

Example Work Products Further Explanation
Risk or opportunity evaluation, categorization, and
prioritization parameters
List of risks or opportunities and their assigned priority
Risk or opportunity assessment results

RSK 3.3
Required Practice Information
Practice Statement
Develop and keep updated a risk or opportunity management strategy.
Value
A systematic approach for risk or opportunity management avoids problems and leverages
opportunities to increase the likelihood of achieving objectives.
Additional Required Information
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
Explanatory Practice Information
Additional Explanatory Information
Develop the strategy early and record it in the organization’s or project’s risk or opportunity
management plan, and maintained throughout the project. The strategy is used to guide risk
and opportunity management activities. The strategy may be included as part of the project
plan.
The risk or opportunity management strategy may also include:
• The domain of interest
• Boundaries, inclusions, and exclusions
• Interactions, dependencies, and relationships between the solution or work and
external factors
• Methods to be used to derive:
o Risk or opportunity categories
o Impact and likelihood of occurrence
o Benefit and cost of the opportunity
o Acceptance criteria
• Conditions that initiate a review and potential update to the risk management strategy
Example Activities
Example Activities Further Explanation
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

Example Work Products

Example Work Products Further Explanation
Risk or opportunity management strategy
RSK 3.4
Required Practice Information
Practice Statement
Develop and keep updated risk or opportunity management plans.
Value
Minimizes the impact of risks and maximizes the benefits of opportunities for achieving
objectives.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
 Cost benefit analysis
 Risk acceptance criteria
 Schedule or period of performance for each risk management activity
 Resource reserves to respond to disruptive events
  Lists of available backup equipment
 Backups to key staff
 Plans for testing emergency response systems
 Posted procedures for emergencies
 Distributed lists of key contacts and information resources for emergencies
 Actions to be taken
Generate leverage plans for selected high-priority opportunities. These plans describe how to
maximize the benefit of an opportunity.
Leveraging involves performing actions that maximize the benefits of an opportunity without
increasing the cost beyond the benefit. Typically, leveraging adds a relatively small amount of
cost while yielding a relatively high level of benefit.
Leveraging plans include:
 Cost benefit analyses
 Potential for success analyses
 Preparation activities
 Actions required to leverage opportunity
This activity can result in the discovery of new opportunities that can require re-planning and
reassessment.
Example Activities
Example Activities Further Explanation
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

Example Work Products

Example Work Products Further Explanation
Risk management plans Includes:
 Mitigation
 Contingencies
Opportunity leveraging plans
Updated plans and status

Related Practice Areas

Planning (PLAN)
Context Specific
Supplier Management

Context Tag: CMMI-SPM

Context: Use processes to identify, select, and manage suppliers and their agreements.

Consider all risks in planning activities. Identify risks from multiple perspectives, e.g.,
acquisition, technical, management, operational, supplier agreement, industry, support, end
user. Consider applicable regulatory and statutory requirements, e.g., safety and security, while
identifying risks. As the work evolves, revise risks based on changed conditions.
There are many risks associated with acquiring solutions through suppliers, e.g., the stability of
the supplier, the ability to maintain sufficient insight into the progress of their work, the
supplier’s capability to meet solution requirements, and the skills and availability of supplier
resources to meet commitments.
Analyze the process and solution level measures and associated thresholds to identify where the
organization is at risk of not meeting thresholds. These measures are key indicators of risk.

RSK 3.5
Required Practice Information
Practice Statement
Manage risks or opportunities by implementing planned risk or opportunity management
activities.
Value
Effective risk management reduces unforeseen occurrences that impair ability to achieve
objectives and increases business value by leveraging opportunities.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Manage risks or opportunities using the Continue to manage risks or opportunities after mitigation,
risk or opportunity management plans. contingency, or leveraging activities have started.
Measurement can provide valuable insight into the risk or
opportunity management activities.
Example Work Products
Example Work Products Further Explanation
Updated status Includes status of mitigation, contingency, and leveraging plans.
 Service Delivery Management (SDM)

Required PA Information
Intent
Deliver services and manage the service delivery system.
Value
Increase customer satisfaction by delivering services that meet or exceed customer
expectations.
Additional Required PA Information
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
Explanatory PA Information
Practice Summary
Level 1
SDM 1.1 Use the service system to deliver services.
Level 2
SDM 2.1 Develop, record, keep updated, and follow service agreements.
SDM 2.2 Receive and process service requests in accordance with service
agreements.
SDM 2.3 Deliver services in accordance with service agreements.
SDM 2.4 Analyze existing service agreements and service data to prepare
for updated or new agreements.
SDM 2.5 Develop, record, keep updated, and follow the approach for operating
and changing the service system.
SDM 2.6 Confirm the readiness of the service system to support the delivery of
services.
Level 3
SDM 3.1 Develop, record, keep updated, and use organizational standard
service systems and agreements.
Additional PA Explanatory Information
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.
Related Practice Areas
Incident Resolution and Prevention (IRP)
Monitor and Control (MC)
Planning (PLAN)
Requirements Development and Management (RDM)
Strategic Service Management (STSM)
Level 1

SDM 1.1
Required Practice Information
Practice Statement
Use the service system to deliver services.
Value
Improves customer satisfaction by delivering expected services.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
This section left blank for future content.
Example Activities
Example Activities Further Explanation
Use a service system.
Deliver services.

Example Work Products

Example Work Products Further Explanation
Service system Components can include:
 List or menu of services with prices
 Customer requests
 Steps to fulfill requests
Records of delivered services
Level 2

SDM 2.1
Required Practice Information
Practice Statement
Develop, record, keep updated, and follow service agreements.
Value
Enhances customer satisfaction by aligning service delivery with their expectations.
Additional Required Information
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.
Explanatory Practice Information
Additional Explanatory Information
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
 Terms and conditions
 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
Example Activities Further Explanation
Develop, record, and keep the Examples of structures to consider include:
structure and format of the  Service based: Organize the service agreement around a
service agreement updated. service, e.g., providing corporate email; this can cover
several different customers
 Customer based: Organize the service agreement around
a customer; this can cover several services for that
customer
Define, negotiate, obtain
commitment to, and
 Example Activities Further Explanation
communicate status of the
service agreement.
Provide the service agreement to Affected stakeholders may include:
affected stakeholders.  Service providers
 Customers
 End users
Review and revise the service Perform reviews on a periodic and event-driven basis.
agreement.

Example Work Products

Example Work Products Further Explanation
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

Related Practice Areas

Requirements Development and Management (RDM)
Strategic Service Management (STSM)

SDM 2.2
Required Practice Information
Practice Statement
Receive and process service requests in accordance with service agreements.
Value
Enhances service delivery to better meet customer expectations.
Additional Required Information
Coordinate the receipt and processing of service requests through a request management
approach.
Explanatory Practice Information
Additional Explanatory Information
Customers can submit service requests through various methods, e.g., web forms, phone calls.
Service agreements may identify requests for continuous or repeatedly scheduled services.
When customers or end users identify a need for a service, they submit a service request.
Either the customer or the service provider can determine the initial type of service request.
Types may include:
 Simple service level-based requests
 Continuous or scheduled requests typically specified in service agreements
 Ad-hoc requests identified over time by customers or end users as their needs change
Record, track, and resolve service request through a request management system. This ensures
the fulfillment of all service requests to meet service agreements.
Examples of simple service requests include:
 A menu or catalog with prices and delivery options
 A phone call with automated options
Examples of continuous service requests
include:
 Weekly scheduled services, e.g., lawn, laundry, cleaning, maintenance
 A call center with continuous operations and support
requirements Examples of ad-hoc requests include:
 Requesting a custom-made query on a database as part of a service system
 Calling for a package pick up as part of a package delivery service
 Identifying a broken component of a maintained system as part of a
maintenance service
 Requesting a health check as part of a health program
Example Activities
Example Activities Further Explanation
Receive service requests and ensure
each request is within the scope of the
service agreement.
Record information about the service Sources of service request information may include:
request.  Standard changes
 Service system operations
 Queries
 Complaints
 Feedback
Determine resources required to Which individuals, groups, and other resources are best
address the service request. suited can depend on the type of service request, locations
involved, and effect on the organization or customer.
 Example Activities Further Explanation
Determine the actions to satisfy the Using the categories developed in the approach to service
service request. delivery, determine the appropriate actions to perform. In
some cases, the categories themselves can have pre-
determined actions associated with them.
Examples of actions include:
 Answering a customer inquiry
 Addressing a service defect
 Repairing items (as part of a maintenance service)
 Training an end user
 Providing new consumables or tools
Monitor the status of service requests Record, track, transfer as necessary, and close the request
until personnel fulfill requests status.
described in the service agreement.
Review service request status and In organizations that use a help desk function, the help desk
confirm results with affected communicates the status of service requests.
stakeholders.
Close the service request and record Record actions to support satisfying similar service requests
the actions taken and results. in the future.
Collect customer satisfaction
information after delivery of services.

Example Work Products

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

Related Practice Areas

Monitor and Control (MC)
Verification and Validation (VV)
SDM 2.3
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Using service agreements to delivery services encompasses the activities necessary to deliver
services based on the agreed-upon service delivery approach. Use a request management
system to meet service agreements, and to track and resolve service requests more
effectively.
Example Activities
Example Activities Further Explanation
Operate service system components
according to service system
procedures.
Perform operations support activities. These activities can include providing customer and end user
training or orientation as needed.
Perform the activities needed to fulfill
service requests.
Use a request management system to The service provider records and tracks status until they
record service requests. close the request.
Escalate service delivery issues when necessary.

Example Work Products

Example Work Products Further Explanation
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

Related Practice Areas

Incident Resolution and Prevention
(IRP) Monitor and Control (MC)
SDM 2.4
Required Practice Information
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.
Additional Required Information
Perform analysis on a recurring or as-needed basis throughout the life of a service agreement.
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Collect customer and end user needs Sources include:
and service provider concerns.  Customer and end user feedback
 Service provider inputs
 Historical data
 Market analysis and demand
 SOW and related solicitation materials
 Support process information
 Service system
 Example Activities Further Explanation
Analyze service requests. For more complex service requests, it may be necessary to
assemble a special team to analyze the request.
Examples of complex service requests include:
 The request has a high and broad effect on
the organization or customer
 The cost of addressing the service requests exceeds
pre- defined limits
 Addressing a service request will take considerable time
or effort
Review and analyze existing service This typically includes reviewing:
agreements, request management  Requested service requirements against standard
data, supplier agreements, and related service definitions
service data.  Existing service level agreements and supplier
agreements for their ability to meet identified service
requirements
 Historical service data including:
o Capacity and availability
o Available resources
o Performance data
o Request data
o Delivered service levels
o Incidents and resolutions
 Available industry benchmarks or other published data
for new service requirements

Example Work Products

Example Work Products Further Explanation
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

Related Practice Areas

Incident Resolution and Prevention (IRP)
Managing Performance and Measurement (MPM)
Strategic Service Management (STSM)
Supplier Agreement Management (SAM)
SDM 2.5
Required Practice Information
Practice Statement
Develop, record, keep updated, and follow the approach for operating and changing the service
system.
Value
Increases the likelihood that services and changes to them will meet customer expectations.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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.
Example Activities
Example Activities Further Explanation
Define the approach for Consider the type of change, e.g., new installation, replacement,
service system operation retirement, or a combination of types, when defining an approach.
and each change. Consider priorities and constraints of affected stakeholders.
Define a rollback or backout strategy to restore the service system to its
former state if a deployment is unsuccessful. Include criteria for what
constitutes a successful deployment versus when to back out changes.
If a service system is being retired, address topics such as end user
notification, error handling, archival methods, demolition, and recycling.
Determine the cost, Schedule service system change activities in a way that balances work
resources, and schedule and available resources against customer and end user needs, including
required for operation of the need to have time to prepare for and conduct the change. When
the service system and for appropriate, use actual data from similar changes to estimate cost,
a new change. resources, and schedule.
Identify affected When identifying affected stakeholders and defining their roles and
stakeholders and review responsibilities, consider outsourced stakeholders.
operations and change
activities.
Develop a plan for service Based on the operations, change, and deployment approach and
system operations and estimates for a transition, record a plan for operations and changes to
for changes to the service system.
operations.
Update the service
continuity plan, if a change
affects an essential
function.

Example Work Products

Example Work Products Further Explanation
Service system operations and change approach
Plans for service system operations and changes
Records of reviews with affected stakeholders

Related Practice Areas

Continuity (CONT)
Incident Resolution and Prevention (IRP)
Monitor and Control (MC)
Planning (PLAN)
SDM 2.6
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Confirming the readiness for service delivery is not a one-time event. Perform these activities
repeatedly, even when the service system is not changing. Consider implications of service
system changes on readiness. For example, changes of the service system may require
additional resources, procedures, user guide updates, or training.
Example Activities
Example Activities Further Explanation
Confirm that service system Service system components may include:
components and tools are operational.  Tools
 Consumables
 People
 Processes and procedures
Examples of service system tools that support operations
may include:
 Monitoring tools
 System management tools
 Tracking systems
 Presentation tools
 Log files
 Analysis tools
 Online knowledge management tools
 Virus scanning tools
 Database management tools
Evaluate the results of confirming The service provider may treat deficiencies or issues as
service system component readiness service incidents and address them through the incident
and determine how to address handling process.
deficiencies or issues.
Review the service level requirements
in the service agreements and set
thresholds in service system
monitoring tools.
Develop, review, or refine service The service provider should regularly review, tailor, and
delivery procedures. possibly supplement procedures to meet ongoing service
 Example Activities Further Explanation
delivery needs. Changes of service system components, e.g.,
archival, incorporation of new components, often require
updates to procedures.
Ensure that the necessary resources Service delivery activities and tasks can include:
are available for performing service  Operating, monitoring, and repairing service system
delivery activities and tasks. components
 Supporting users of the service system
 Acquiring and replacing service system components
Prepare and update plans and These plans and schedules typically include:
schedules for delivering services as  Detailed job execution tasks for service delivery personnel
requested.  Due dates and time frames for delivery
 Service delivery monitoring tasks
 Tasks specific to transition activities, e.g., backing up data
Review the service system approach,
plan, and procedures as appropriate
with affect stakeholders.
Provide orientation or training to Orient incoming personnel, e.g., new hires, at a shift change,
incoming service delivery and support on the current state of operations and pending transition
personnel. activities to ensure uninterrupted service.

Example Work Products

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

Related Practice Areas

Incident Resolution and Prevention (IRP)
Strategic Service Management (STSM)
Level 3

SDM 3.1
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
To provide broader and more scalable services, organizations use standardized approaches to
service systems, service agreements, and their maintenance. Maintenance types include:
• Corrective maintenance, e.g., correcting and repairing components that degrade
the operational capability of the service system
• Preventive maintenance, e.g., preventing service incidents and defects from
occurring through pre-planned activities
• Adaptive maintenance, e.g., adapting the service system to a changing or
different service delivery environment
• Perfective maintenance, e.g., developing or acquiring additional or improved
operational capability of the service system
Apply standardization and the resulting maintenance to any portion of a service system, on
service agreements, request management systems, and their components, including
consumables, processes, software, hardware, infrastructure, and people.
For service system components where maintenance and availability depends on a third party
vendor, include such items as:
 Cloud-based databases
 Customer relationship management components
 Ticket management components
Additionally, maintenance activities may include renewing service contracts, identifying and
dealing with maintenance windows, and identifying and notifying affected stakeholders about
vendor disruptions.
Example Activities
Example Activities Further Explanation
Review and prioritize standardization
and maintenance needs and requests.
Analyze effect of standardization and
maintenance on service delivery.
Develop an approach or process to
standardize or maintain service
agreements, service systems, or their
components.
Communicate changes and
notifications to affected stakeholders.
Update and retain service system
documentation as appropriate.

Example Work Products

Example Work Products Further Explanation
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

Related Practice Areas

Configuration Management (CM)
Process Management (PCM)
Requirements Development and Management (RDM)
Strategic Service Management (STSM)

Strategic Service Management (STSM)

Required PA Information
Intent
Develop and deploy standard services that are compatible with strategic business needs and
plans.
Value
Increases likelihood of meeting business objectives by aligning standard services with customer
needs.
Additional Required PA Information
This section left blank for future content.
Explanatory PA Information
Practice Summary
Level 1
STSM 1.1 Develop a list of current services.
Level 2
STSM 2.1 Develop, keep updated, and use descriptions of current services.
STSM 2.2 Collect, record, and analyze data about strategic needs and capabilities
for service delivery.
STSM 2.3 Develop, keep updated, and follow an approach for providing new
or changed services derived from strategic needs and capabilities.
Level 3
STSM 3.1 Develop, keep updated, and use the set of organizational
standard services and service levels.
Additional PA Explanatory Information
The management of strategic services involves:
• Analyzing capabilities and needs for services that can span multiple customers
and agreements
• Developing and keeping updated standard services, service levels, and
descriptions that reflect these capabilities and needs
Strategic service management processes improve alignment between the set of standard
services offered by an organization and its strategic business objectives.
Develop standard services through:
 Active analysis of customer and competitor data
  Analysis of market trends and opportunities
 Understanding service provider capabilities, strengths, and weaknesses
The objective is to get the information needed to make effective strategic decisions about the
set of standard services that the organization offers and maintains. Standard services provide a
basis for ensuring that a service provider’s capabilities meet their business objectives. Standard
services improve service quality, opportunity development, and customer and end user
satisfaction. Standard service levels are a key component of standard services. Service levels
make expectations and responsibilities clear, specific, and measurable between the service
provider and the customer while reducing costs, errors, and time to develop and deliver
services.
Service providers typically describe standard services in a service catalog oriented to the
information needs of customers. Service providers should also maintain standard
service descriptions oriented to their needs.
While customer and end user needs may differ, both are critical when collecting and analyzing
data to develop standard services and understand strategic needs and plans. Focusing on these
needs and the use of current services, service providers identify requirements to improve
existing services and plan for future services.
Related Practice Areas
Service Delivery Management (SDM)
Level 1

STSM 1.1
Required Practice Information
Practice Statement
Develop a list of current services.
Value
Aligns offered services with customer and stakeholder needs and expectations.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
This section left blank for future content.
Example Activities
Example Activities Further Explanation
Identify current services.

Example Work Products

Example Work Products Further Explanation
List of current services
Level 2

STSM 2.1
Required Practice Information
Practice Statement
Develop, keep updated, and use descriptions of current services.
Value
Enables consistent service delivery that aligns with customer needs.
Additional Required Information
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.
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Develop, record, and keep individual These are based on the current list of available services.
service descriptions updated.
Develop, record, and keep the service The service catalog contains all the individual service
catalog updated. descriptions and related material.

Example Work Products

Example Work Products Further Explanation
Individual service descriptions
Service catalog or menu

Related Practice Areas

Service Delivery Management (SDM)
STSM 2.2
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities
Example Activities Further Explanation
Collect and analyze data on Include capabilities of:
capabilities.  The projects or organizations offering the services
 Customers and end users
 Systems and processes used to provide services
 Competitors
Collect and analyze data on strategic Include external and internal factors.
needs.
Communicate the capabilities and
strategic needs to affected
stakeholders.

Example Work Products

Example Work Products Further Explanation
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
Required Practice Information
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.
Additional Required Information
The approach includes plans for new or changed services. These plans typically include:
 How customer and end user needs and requirements will be met
 Actions needed to balance capabilities and resources
 External service supplier requirements
Explanatory Practice Information
Additional Explanatory Information
This section left blank for future content.
Example Activities
Example Activities Further Explanation
Develop, record, and confirm Senior management should articulate, review, and approve
strategic business objectives. strategic objectives.
Identify requirements for services
based on strategic business needs,
objectives, and capabilities.
Record descriptions of services This may include details about:
provided or changed.  Components
 Resources
 Service level ranges
Identify changes to services These changes can include:
offered.  Developing new services
 Revising or improving current services to fit evolving or
future needs
 Retiring services that no longer fit the needs of customers
or current capabilities
Set priorities and decide which actions to take.
New or changed services may require new or changed service
systems.
Develop, keep updated, and follow
plans for new or changed services.
Verify that planned services are Analyze the provided services and ensure that they address the
available when needed. following factors:
 Availability of personnel needed to provide the service
 Required skills and experience of personnel
 Capacity of available personnel to produce the expected
quality of work
 Ability of personnel to meet deadlines

Example Work Products

Example Work Products Further Explanation
Descriptions of strategic business objectives
Service descriptions
Analysis of service system needs
Plans for services
Plan verification results

Related Practice Areas

Governance (GOV)
Planning (PLAN)
Process Management (PCM)
Verification and Validation (VV)
Level 3

STSM 3.1
Required Practice Information
Practice Statement
Develop, keep updated, and use the set of organizational standard services and service levels.
Value
Minimizes cost and achieves faster time to market for new or changed services.
Additional Required Information
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.
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Develop, record, and keep updated Follow organizational policies, standards, and models.
standard service descriptions. Organize services into service lines as needed to ensure
appropriate integration among services.
Specify the characteristics of each service. These may include definitions of standard service
levels.
Example Work Products
Example Work Products Further Explanation
Descriptions of services and their Critical characteristics typically include:
characteristics  Features and benefits
 Available service levels and categories
 Capacity and availability requirements
 Costs
 Descriptions of current and intended users
 Service components
 Service delivery systems
 Related services
 List of needed service delivery materials
 Example Work Products Further Explanation
Standard service catalog or menu The catalog typically contains tailoring guidelines for
standard services and descriptions of services lines
if needed.

Related Practice Areas

Process Asset Development (PAD)
Process Management (PCM)
Service Delivery Management (SDM)
 Supplier Agreement Management (SAM)

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

SAM 1.1
Required Practice Information
Practice Statement
Develop and record the supplier agreement.
Value
Increases likelihood of meeting requirements when using suppliers.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Develop and record a supplier
agreement.
Negotiate the terms of the candidate Negotiation may require updates to the supplier agreement.
agreement with the supplier.
Reach agreement with supplier.

Example Work Products

Example Work Products Further Explanation
Supplier Agreement May include:
 Example Work Products Further Explanation
 Affected stakeholders and communication involved
 Statement Of Work
 Specifications
 Terms and conditions
 List of deliverables
 Schedule
 Budget
 Legal or regulatory information

SAM 1.2
Required Practice Information
Practice Statement
Accept or reject the supplier deliverables.
Value
Increases the likelihood the supplier provides the agreed-on supplier deliverable.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Accept or reject the supplier
deliverable based on the extent that
the agreed-on supplier deliverable
meets contractual requirements.

Example Work Products

Example Work Products Further Explanation
Deliverables per the supplier
agreement
SAM 1.3
Required Practice Information
Practice Statement
Process supplier invoices.
Value
Maintains a good working relationship with suppliers while meeting agreements.
Additional Required Information
This section left blank for future content.
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Process supplier invoices in accordance
with agreements.

Example Work Products

Example Work Products Further Explanation
Records of supplier invoices
Level 2

SAM 2.1
Required Practice Information
Practice Statement
Monitor supplier as specified in the supplier agreement and keep agreement updated.
Value
Improves the likelihood that the supplier provides the right supplier deliverable.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Monitor and update the supplier agreement based on the supplier selection decision and based
on actual results.
The acquirer, supplier, and affected stakeholders should review agreement requirements to
ensure that a common understanding is kept up-to-date through the life of the agreement.
After establishing the supplier agreement, requirements may change, based on factors such
as:
 Applicability of requirements
 Availability of new technology
 Reduction of overly burdensome reporting
 Organization changes, e.g., merger or acquisition
 Legal or regulatory changes
The supplier agreement and work documents should be revised to reflect changes in conditions.
This includes updating cost, schedule, and budget as needed. Legal or contract advisors often
are responsible for reviewing supplier agreements among independent legal entities prior to
approval.
The content of the supplier agreement should specify how the agreement will be monitored and
revised as required. This should be done in a way that is appropriate to the acquisition or
supplier deliverable being acquired.
Example Activities
Example Activities Further Explanation
Record the supplier agreement and This typically includes:
keep it updated.  Recording all changes formally approved by both
the acquirer and supplier
 Developing, recording, and keeping the requirements
updated, e.g., supplier deliverable requirements,
service
level agreements
 Example Activities Further Explanation
 Periodically reviewing the supplier agreement to ensure
it accurately reflects current plans, processes, risks, and
market conditions
 Ensuring that the agreement, and data related to it,
are stored and managed for future use
 Performing impact assessments across technical
and commercial aspects of the agreement
 Assessing all alternatives associated with the change
Verify that the acquirer and supplier Approval may take different forms, such as:
understand and agree to all  Signature
requirements by approving the  Electronic approval or acknowledgement
supplier agreement.  Stamp or record of corporate/company approval
 Other legally-binding acceptance
Communicate the supplier Ensure that all affected stakeholders are aware of the
agreement within the acquiring agreement.
organization as required.

Example Work Products

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

Related Practice Areas

Configuration Management (CM)
Monitor and Control (MC)
Requirements Development and Management (RDM)

SAM 2.2
Required Practice Information
Practice Statement
Perform activities as specified in the supplier agreement.
Value
Improves the acquirer’s confidence in the ability of the supplier to deliver the right supplier
deliverable with the right quality.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
The acquirer monitors the supplier’s progress against the agreement to identify and resolve
issues. Monitoring includes internal and external communication as well as the use of
information by the acquirer and supplier regarding the relationship, performance, results, and
impact to the business. Agreement, management, technical, and other reviews may be
conducted together or separately.
Example Activities
Example Activities Further Explanation
Monitor supplier progress and Monitoring can be conducted during agreement, technical,
performance, e.g., schedule, effort, and management reviews. Reviews can include both planned
cost, technical, as defined in the and as-needed interactions.
supplier agreement. Reviews cover both formal and informal reviews and include
the following steps:
 Preparing for the review
 Ensuring that affected stakeholders participate
 Conducting the review
 Preparing, distributing, or making a summary
report available to the affected stakeholders
 Example Activities Further Explanation
 Identifying issues and determining corrective
actions necessary to resolve and track the issues to
closure
 Monitoring risks involving the supplier and mitigating them
as necessary
Conduct agreement reviews with the May include:
supplier as specified in the supplier  Agreement changes or updates
agreement.  Stakeholder reassignment
 Interpretation and clarification of terms, conditions, and
deliverables
 Positive or negative feedback on contractual requirements
Conduct technical reviews with the Technical reviews typically include:
supplier as defined in the supplier  Providing the supplier with visibility into the needs
agreement. and preferences of the customers and end users as
appropriate
 Reviewing the supplier’s technical activities and verifying
that the supplier’s interpretation and implementation of
the requirements are consistent with the acquirer’s
interpretation
 Ensuring that technical commitments are being met and
that technical issues are communicated and resolved in
a timely manner
 Obtaining technical information about the
supplier’s deliverables
 Providing appropriate technical information and support to
the supplier
Conduct management reviews with the This typically includes reviewing:
supplier as specified in the supplier  Critical dependencies
agreement.  Risks involving the supplier
 Schedule and budget
 The supplier’s compliance with legal and
regulatory requirements
Unresolved issues escalate through the appropriate
management chain according to a project’s or organization’s
issue resolution process.
Record results of the reviews and Use the results of reviews to improve the supplier’s
interactions. performance and to establish and nurture long-term
relationships with preferred suppliers.

Example Work Products

Example Work Products Further Explanation
Agreement updates, progress reports May include:
 Issue and action item list
 Meeting minutes
 People assigned corrective actions
 Due date for actions
 Example Work Products Further Explanation
Supplier progress and performance
reports
Issue, risk, and action item lists May include:
 Description of risk, issues, or action items
 People assigned corrective actions
 Due date for actions
Records of the submission and
acceptance of the supplier deliverable
and other deliverables

Related Practice Areas

Monitor and Control
(MC) Planning (PLAN)
Risk and Opportunity Management (RSK)

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

Example Work Products

Example Work Products Further Explanation
Acceptance procedures
Discrepancy reports or corrective
action plans
Acceptance review report with
recorded approval
Formal acceptance notifications Notifications should be communicated to the supplier and
affected stakeholders.
A record that all agreement Approval may take different forms, such as through:
requirements have been met  Signature
 Example Work Products Further Explanation
 Electronic approval or acknowledgement
 Stamp or record of corporate/company approval
 Other legally-binding acceptance

Related Practice Areas

Monitor and Control
(MC) Planning (PLAN)
Verification and Validation (VV)

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

Example Work Products

Example Work Products Further Explanation
Invoices approved for payment
Record or receipt of payment Payment per the supplier agreement, e.g., check, money
order, credit card, electronic transfer of funds to supplier
Archived invoice and payment records
Level 3

SAM 3.1
Required Practice Information
Practice Statement
Select technical supplier deliverables for analysis and conduct technical reviews.
Value
Improves the acquirer’s confidence in the ability of the supplier to provide the right supplier
deliverable at the right time with the right quality.
Additional Required Information
This requires that organizational standards and processes are in place and followed.
Explanatory Practice Information
Additional Explanatory Information
Technical reviews are used by the acquirer to confirm that supplier deliverables being
developed or produced by suppliers meet requirements.
Technical reviews are conducted:
 When the technical supplier deliverable under development meets the criteria
specified in the supplier agreement
 At the transition from one acquisition phase to the next and at major transition
points of technical effort
The supplier is responsible for managing the requirements and interfaces or connections of the
supplier deliverable it is developing. However, the acquirer identifies interfaces or connections
that it manages as well, particularly external interfaces or connections.
The interfaces or connections being considered for selection should include other supplier
deliverables in the operations, support, verification, and validation environments. The acquirer
should review all supplier interface or connection data for completeness.
In addition to interfaces or connections, the acquirer should consider the following criteria
when selecting supplier deliverables for analysis and review:
 Performance
 Recovery
 Safety
 Security
 Mean Time to Failure (MTTF)
 Mean Time Between Failure (MTBF)
 Maintainability
 Serviceability
 Updateability
  Modularity
Example Activities
Example Activities Further Explanation
Develop criteria for determining which
technical supplier deliverable to
analyze.
Identify technical supplier deliverables Technical supplier deliverables that are typically analyzed by
for analysis. the acquirer may include:
 Supplier derived deliverable and component
requirements, architectures, and designs
 Deliverable interface or connection descriptions
 Deliverables and deliverable components
Identify the functional and quality A traceability matrix is a useful tool for identifying
attribute requirements to be satisfied requirements for each selected technical solution, as it
by each selected technical supplier typically includes information that relates requirements to
deliverable. work products. When identifying requirements for each
selected technical supplier deliverable, consult the
appropriate traceability matrix.
Identify the analysis methods to be Examples of techniques used for analysis include:
used for each selected technical  Simulations
supplier deliverable.  Prototyping
 Architecture evaluation
 Demonstrations
 Peer Reviews
Include analysis methods and review
activities in the work plan.
Confirm that the selected technical
supplier deliverable adheres to
applicable standards and criteria.
Confirm that the selected technical
supplier deliverable adheres to
allocated functional and quality
attribute requirements.
Use analysis results to compare
actual performance measurements to
specified thresholds of technical
performance measures.
Review critical verification results and
data from verifications performed by
the supplier.
Identify interfaces or connections that Example criteria for interfaces or connections include:
are candidates for acquirer  Spans organizational boundaries
management.  Mission critical
 Difficult or complex to manage
 Key quality attributes
 Multiple acquisition projects
 Example Activities Further Explanation
Review identified interfaces or
connections against the selection
criteria and include in the work plan.
Confirm the compatibility of selected Confirm that interface or connection descriptions adhere to
interfaces or connections applicable standards, criteria, and connection requirements
throughout the life of the solution. between the supplier’s supplier deliverable and acquirer’s
intended environment.
Verify that interfaces or
connections have been sufficiently
tested by the supplier.
Verify that issues identified during
testing have been resolved
appropriately, with deliverable
revisions, if necessary.
Resolve conflict, noncompliance, and
change issues for the selected
interfaces or connections.

Example Work Products

Example Work Products Further Explanation
Activity reports
Discrepancy reports
Criteria used to select technical
supplier deliverables for analysis
Lists of supplier requirements and
technical supplier deliverables selected
for analysis
Analysis methods for each selected
supplier deliverable
Record of analysis results May include:
 Issue and action item list
 Meeting minutes
 People assigned corrective actions
 Due date for actions
Criteria to be used in selecting acquirer
managed interfaces or connections

Related Practice Areas

Configuration Management (CM)
Decision Analysis and Resolution (DAR)
Managing Performance and Measurement (MPM)
Planning (PLAN)
Requirements Development and Management (RDM)
Risk and Opportunity Management (RSK)
Verification and Validation (VV)
Context Specific
Development

Context Tag: CMMI-DEV

Context: Use processes to develop quality products and services to meet the needs of
customers and end users.

Perform technical reviews throughout the work lifecycle to gain confidence that the
requirements, architecture, and technical supplier deliverables provide the required capability.
These reviews should be integrated with risk management activities.
Types of technical reviews that can be conducted include:
 Integrated Baseline Review (IBR)
 Technology Readiness Assessment (TRA)
 System Requirements Review (SRR)
 Preliminary Design Review (PDR)
 Critical Design Review (CDR)
 Test Readiness Review (TRR)
 Production Readiness Review (PRR)
 Operational Test Readiness Review (OTRR)
Depending on where in the acquisition lifecycle the highest risks occur, the acquirer selects
technical supplier deliverables for analysis to reduce those risks. Select analysis methods based
on the type of technical solution being analyzed and the nature of the risk. For example:
 In the design phases of the solution, quality attribute models, simulations, prototypes,
or pilots can be used to provide additional information about the properties of the
potential design solutions to aid in their evaluation and selection. Simulations can be
particularly useful for complex systems.
 In the implementation phase, the acquirer can examine a supplier deliverable to
determine if it is ready for production and if the supplier has accomplished adequate
production planning. The analysis determines if production or production preparations
pose unacceptable risks that might compromise cost, schedule, performance, or other
established objectives. The acquirer might evaluate the full production configured
supplier deliverable to determine if it correctly and completely implements all
contractual requirements. The acquirer could also determine whether the traceability of
the final contractual requirements to the final production configured solution has been
maintained.
The acquirer should select a supplier’s design to analyze the adequacy and completeness of
that design. The acquirer may also confirm that:
 The selected design adheres to applicable design standards and criteria
  The design adheres to allocated functional and quality attribute requirements
 The resulting supplier deliverable will perform appropriately in its target environment
 The solution baseline enables hardware fabrication and software coding to proceed with
proper configuration management
 Adequate production processes and measures are in place for the work to succeed
 The design can be implemented within the production budget
During implementation, the supplier implements the design reviewed and analyzed by the
acquirer by developing supplier deliverable components, integrating those components,
performing unit and integration testing of the solution, and developing operational and end user
documentation.
The acquirer can require delivery of verification results from the supplier of the technical
solution, as applicable. The suppliers can perform verifications in an iterative fashion,
concurrently with the acquirer’s technical analyses, or the supplier can be required to
perform follow-on verifications of technical solutions.
Typical expectations for verification addressed by the supplier agreement may include:
 List of deliverables and other work products that must be verified by the supplier
 Applicable standards, procedures, methods, and tools
 Criteria for verification of supplier work products
 Measurements to be collected and provided by the supplier with regard to
verification activities
 Reviews of supplier verification results and corrective actions with the
acquirer Examples of considerations for follow up verifications of technical solutions
include if:
 During the production stage of the work, there are changes in either materials or
manufacturing processes
 Production re-starts after a significant shutdown period
 Production starts up with a new supplier
 A manufacturing site has relocated
The acquirer can determine if the supplier’s implementation is successful by analyzing if the:
 Supplier deliverable is ready to be brought into the acquirer environment for
further integration and acceptance testing
 Production capability is satisfactory enough to perform pilot studies or move to full-
rate production
 Requirements are fully met in the final production configuration
The acquirer should also confirm that sufficient end user documentation has been developed
and is aligned with the tested implementation. The supplier can develop preliminary versions of
the installation, operations, and maintenance documentation in early phases of the work
lifecycle for review by the acquirer and affected stakeholders.
SAM 3.2
Required Practice Information
Practice Statement
Select and monitor supplier processes and deliverables based on criteria in the supplier
agreement.
Value
Provides better visibility into supplier capability and performance to minimize risk.
Additional Required Information
This requires that organizational standards and processes are in place and followed.
Explanatory Practice Information
Additional Explanatory Information
When close alignment between supplier and acquirer processes is critical to the success of the
project, the acquirer should monitor these processes to help prevent problems.
Selecting processes for monitoring involves considering the impact of the supplier’s processes
on the project. On larger projects with significant subcontracts with critical supplier deliverables
or solution components, monitoring key processes may be needed.
The acquirer decides on the necessary level of monitoring depending on the level of risk
incurred when the supplier’s process is not performed correctly. Monitoring processes can
range from reviewing supplier-produced process data to conducting on-site appraisals of the
supplier’s processes. Analyzing selected processes involves compiling and analyzing supplier
process data to determine whether there are serious risks or issues.
Example Activities
Example Activities Further Explanation
Select and monitor processes used Supplier processes that are critical to the success of the
by the supplier as defined in the project should be monitored. When selecting processes to
supplier agreement. monitor, consider the impact on the supplier.
Analyze processes used by the supplier Analyze results of monitoring selected processes to detect
as defined in the supplier agreement issues as early as possible that may affect the supplier’s
and communicate with affected ability to satisfy requirements of the supplier agreement.
stakeholders. Trend analysis may be performed and can rely on internal
and external data.

Example Work Products

Example Work Products Further Explanation
List of processes selected for
monitoring and rationale for selection
Reports from monitoring May include:
 Process performance reports
 Discrepancy reports
 Action items and risks
 Example Work Products Further Explanation
Record results of analysis

Related Practice Areas

Decision Analysis and Resolution (DAR)
Managing Performance and Measurement (MPM)
Monitor and Control (MC)
Planning (PLAN)
Level 4

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

Example Work Products

Example Work Products Further Explanation
Performance measurement
specifications
List of selected measures Measures may include:
 Operational definitions suitable to support statistical and
other quantitative management
 Identified statistical and other quantitative techniques to
analyze the measures
 Representations of data and analysis results
 Identified key performance objectives
 Supplier process data
Results of the analyses against their Trace to objectives as defined in the supplier agreement.
targets
Action item list Include corrective actions and status.
 Supplier Source Selection (SSS)

Required PA Information
Intent
Develop and keep updated a package of materials used to seek proposals from potential
suppliers and select one or more suppliers to deliver the solution.
Value
Improves the ability to select the most qualified suppliers to deliver solutions.
Additional Required PA Information
This section left blank for future content.
Explanatory PA Information
Practice Summary
Level 1
SSS 1.1 Determine the type of acquisition.
SSS 1.2 Identify potential suppliers and distribute requests for proposals.
SSS 1.3 Evaluate proposals and select suppliers.
Level 2
SSS 2.1 Develop a solicitation package and keep it updated.
SSS 2.2 Identify qualified potential suppliers and distribute the solicitation
package for their response.
SSS 2.3 Evaluate proposed solutions according to recorded evaluation criteria and
select suppliers.
Level 3
SSS 3.1 Develop, keep updated, and follow negotiation approaches for
soliciting, evaluating, and selecting suppliers.
Additional PA Explanatory Information
The purpose of Supplier Source Selection is to prepare a solicitation package and select one or
more suppliers to deliver the solution.
The acquirer is responsible for defining and keeping updated ground rules for initial
communication and interaction with potential suppliers. Define and use the roles and
responsibilities of affected stakeholders and potential suppliers.
Supplier Source Selection involves:
 Identifying potential suppliers
 Developing and distributing the solicitation package
  Developing supplier qualification criteria
 Developing proposal evaluation criteria
 Evaluating potential suppliers’ proposals
 Negotiating with potential suppliers
 Selecting suppliers that best meet the evaluation criteria
Develop the solicitation package using:
 Technical and contractual requirements
 Performance specifications
 Acceptance criteria
Related Practice Areas
Decision Analysis and Resolution (DAR)
Managing Performance and Measurement (MPM)
Requirements Development and Management (RDM)
Supplier Agreement Management (SAM)

Level 1

SSS 1.1
Required Practice Information
Practice Statement
Determine the type of acquisition.
Value
Aligns the acquisition type to satisfy the project needs, requirements, and constraints.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
The acquirer may use different types of acquisitions to acquire solutions based on technical,
regulatory, or customer requirements.
The acquirer may use a competitive bid process for selecting suppliers or they may choose to
pursue a sole source acquisition.
Example Activities
Example Activities Further Explanation
Review possible acquisition types. Examples of acquisition types include:
 Example Activities Further Explanation
 Purchasing Commercial Off-The-Shelf (COTS) solutions
 Obtaining solutions from an external supplier
 Obtaining solutions from an in-house supplier, e.g., from
within the same organization, but from outside the
project
 Obtaining solutions from the customer
 Obtaining solutions from a preferred supplier
 Purchasing supplier labor hours
 Combining some of the above, e.g., a COTS solution
that an external supplier must customize to fully meet
requirements
Select the type of acquisition to use. Different parts of a single solution may require selecting
multiple acquisition types.

Example Work Products

Example Work Products Further Explanation
List of possible acquisition types
Acquisition type selected for the
solution

Related Practice Areas

Requirements Development and Management (RDM)

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

Example Work Products

Example Work Products Further Explanation
List of potential suppliers
Request for proposals

SSS 1.3
Required Practice Information
Practice Statement
Evaluate proposals and select suppliers.
Value
Increases likelihood of project success.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Consider the advantages and disadvantages of each proposed solution prior to making a
supplier selection. Use proposal evaluation results to select suppliers. Retain notes related
to the supplier selection for future reference.
Example Activities
Example Activities Further Explanation
Evaluate supplier proposals. The acquirer typically evaluates proposals against:
 Requirements
o Technical
o Non-technical
o Contractual
 Example Activities Further Explanation
o Regulatory
 Time constraints
 Cost estimates
 Other identified proposal criteria
Select suppliers.

Example Work Products

Example Work Products Further Explanation
Results of proposal evaluation
Official selection notice
Level 2

SSS 2.1
Required Practice Information
Practice Statement
Develop a solicitation package and keep it updated.
Value
Maintains the integrity of the solicitation package for the objective comparison and evaluation of
proposals.

Additional Required Information

This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Use solicitation packages to seek proposals from potential suppliers. Solicitation packages
typically include:
 Technical requirements to be satisfied by the solution
 The Statement of Work (SOW) for the supplier
 A description of the process and criteria to evaluate proposals
 Required proposal contents
 Terms and conditions to include in the supplier agreement
 Guidance on how potential suppliers are to respond to the solicitation package
 The schedule for completing the solicitation process for both the supplier and
the acquirer
 Procedures for addressing questions and points of contact
The acquirer structures the solicitation package to facilitate a consistent, accurate, and
complete response from each potential supplier. This enables the acquirer to effectively and
objectively compare and evaluate submitted proposals.
The complexity and level of detail of the solicitation package should be consistent with the
value of, and risk associated with, the planned acquisition.
Example Activities
Example Activities Further Explanation

Develop the SOW for the supplier. The SOW typically includes:
 Project objectives
 An overview of the project with sufficient information
for the supplier to understand the project environment
and risks
 Requirements (including period of performance;
milestones; work location; legal, statutory, and regulatory
 Example Activities Further Explanation
requirements; delivery format; quantities; content
requirements)
 Design constraints
 Deliverables, e.g., work breakdown structure (WBS) or
list of tasks and activities for the supplier’s work, detailed
design, test results
 Ownership, intellectual property, data, and
proprietary rights
 Specifications for the supplier’s transition of the product to
operations and support
 Requirements for performance including measures
of quality, process, product, and service level
 Required reports that provide the acquirer visibility into
supplier progress and performance
 Additional services required related to the acquired
solution, e.g., study reports, development of training
materials, delivery of training to end users
 Acquirer specified processes for the project, e.g.,
configuration management, quality assurance,
issue escalation and resolution, corrective action for
noncompliance, change management
 Reviews conducted with the supplier and their frequency
 Communication mechanisms
 Solution acceptance criteria and required supplier
involvement in the acquirer’s validation and
acceptance activities
 Post-project support
The acquirer can revise and refine the SOW for the supplier
as it moves through the solicitation, negotiation, and
supplier agreement development processes until finally
incorporating it into a signed supplier agreement.
Develop and record the required Required proposal content requirements typically include:
proposal contents.  Company overview, experience, and references
 Evidence of the supplier’s processes, including
commitment to execute processes to provide the
solution
 Description of the solution the supplier will provide
to meet customer requirements
 Plan describing how the supplier will provide the required
solution
 Risk management plan describing how the supplier will
manage risks
 Supplier pricing methodology including:
o Calculation of charges, taxes, and credits
o Foreign currency exchange rates
o License fees
o Pass-through costs
o Travel reimbursements
 Example Activities Further Explanation
 Acquirer invoicing requirements including frequency, term,
and pricing type, e.g., fixed price, lump sum, time and
materials
 Compliance with legal, regulatory, certification or
other requirements
 Supplier’s approach to assuring the quality of the solution
 Approach for the escalation and resolution of issues
 Information about ownership, intellectual property, data,
and proprietary rights
 Plan for retention of critical team members during
the project
 Identification of work subcontractors will perform
Develop proposal evaluation criteria. Develop and use evaluation criteria to rate or score suppliers
and their proposals.
The evaluation criteria used should be consistent with the
requirements and complexity of the acquired solution.
Examples of criteria used to evaluate a potential supplier’s
ability and proposal include:
 Response to all stated requirements contained in
the solicitation package
 Experience with similar solutions or services
 Technical capability, including:
o Technical methodologies and techniques
o Solutions
o Services
 Familiarity with acquirer processes, the
technical environment, and the core business
 Total ownership and lifecycle costs
 Management, development, and delivery processes
and procedures
 Financial capability
 Resource capacity, e.g., personnel available,
facilities available
 Business size and type
 Intellectual property and proprietary rights
 Compliance with regulatory requirements
Include evaluation processes and associated criteria in the
solicitation package.
Develop terms and conditions and Terms and conditions may include:
additional information.  Recitals or demonstrations of proposals
 Deliverables and rights
 Compensation and payments
 Confidentiality
 Privacy or non-disclosure statements
 Legal, regulatory, certification or other requirements
 Exclusive services, key personnel, supplier personnel
at acquirer sites
 Example Activities Further Explanation
 Ownership, intellectual property, data, and
proprietary rights
 Force majeure
 Termination for insolvency, breach, non-
performance, convenience, etc.
 Termination assistance
 Term (length of the agreement)
 Renewal period
 Indemnification
 Insurance
 Right to audit
 Notices
Additional information to help the supplier when responding
to the solicitation package may include:
 Submission of intent to submit proposal
 Submission due date, time, and destination
 Number of proposal response copies the supplier
must submit
 Proposal format
 Non-complying proposals
 Proposal ownership
 Bidder inquiries
 Key dates and activities
 Discretionary selection and potential modifications of the
solicitation process
 Statements that:
o The solicitation itself is not an implied contract
o The response is not an obligation to do the work
 Confidentiality of information
 Publicity
 Use of subcontractors
 Due diligence
 Incurred costs
 Language requirements
 Statutory units
 Warranty provisions
 Licensing provisions
Review the solicitation package with Affected stakeholders may include potential suppliers and
affected stakeholders prior to other industry representatives.
distribution.

Obtain stakeholder commitment to the Commitment to the solicitation package reflects that
solicitation package. stakeholders understand and support the contents.

Example Work Products

Example Work Products Further Explanation
Record of reviews of the solicitation
package
 Example Work Products Further Explanation
Records of stakeholder commitment to
the solicitation package
Supplier and proposal evaluation
criteria
Finalized solicitation package

Related Practice Areas

Decision Analysis and Resolution
(DAR) Peer Reviews (PR)
Process Asset Development (PAD)

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

Example Work Products

Example Work Products Further Explanation
List of qualified suppliers
Notice to potential suppliers about the
solicitation or any changes to the
solicitation
 Example Work Products Further Explanation
Supplier questions and requests for
clarification
Responses to supplier questions and
requests for clarification
Changes to the solicitation package

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

Example Work Products

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

Related Practice Areas

Decision Analysis and Resolution (DAR)
Risk and Opportunity Management (RSK)

Level 3

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

Example Work Products

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

Required PA Information
Intent
Design and build solutions that meet customer requirements.
Value
Provides a cost-effective design and solution that meets customer requirements and reduces
rework.
Additional Required PA Information
This section left blank for future content.
Explanatory PA Information
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.
Additional PA Explanatory Information
Activities for designing and building solutions can be applied:
 To products or product components
 To services, service systems, and service components
 At any level of the product or service architecture
Design and build solutions that meet customer, functional, and quality requirements by:
  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.
Related Practice
Areas Product
Integration (PI)
Context Specific
Agile with Scrum Guidance

Context Tag: Agile with Scrum

Context: Use processes to adapt agile with Scrum techniques.

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

Table TS-1: Technical Solution Activities in an Agile Project Using Scrum

Agile with Scrum Technical Solution
Release planning Earlier and more complete understanding of the end solution and
completion risks.
Backlog grooming/review Allocation of requirements to design components to be developed
for known user stories during this sprint. This helps to identify
additional requirements that may have been missed.
 Agile with Scrum Technical Solution
Sprint planning Broader understanding for context of designs and interfaces or
connections for the upcoming sprint
Sprint execution More of the execution is spent developing a working solution vs.
refactoring.
Sprint review Enables a more thorough understanding of what has been accomplished
during the sprint.
Sprint retrospective Provides a comprehensive understanding of what design components
remain.

Technical Solution activities can be performed iteratively to improve any agile project during
sprint execution. Time can be allocated to each sprint to perform design practices. Design
documentation can be in the form of a picture and bulleted design notes stored in the same
tools used to store user stories or epics and other project data.
Services

Context Tag: CMMI-SVC

Context: Use processes to deliver, manage, and improve services to meet customer needs.

It is important to remember that in some simple service systems the components are just the
people and the processes they perform.
Service system development focuses on the following activities:
 Collecting, coordinating, analyzing, validating, and allocating stakeholder
requirements for service systems
 Evaluating and selecting from alternative service system solutions that meet
requirements
 Designing, building or composing (as needed), integrating, and recording
service systems that meet requirements
 Verifying and validating service systems to confirm satisfaction with intended
requirements and satisfaction with customer and end user expectations during
actual service delivery
The service organization chooses to develop the service system from a wide range of options,
from internal development to outsourcing to commercial product integration. Most service
organizations engage a development team to build a service system. Choose the development
method(s) based on the requirements to fulfill and the service system components to develop.
When service system components comprise product components, develop requirements, as well
as operational concepts and scenarios for the system, that consider the objectives of the service
system, business needs, customer needs, user needs, and the needs of other affected
stakeholders.
Level 1

TS 1.1
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
This section left blank for future content.
Example Activities
Example Activities Further Explanation
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

Example Work Products

Example Work Products Further Explanation
Product or service
Level 2

TS 2.1
Required Practice Information
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.
Additional Required Information
The design describes solution structure, interfaces or connections, and functionality.
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Define the architecture. May include:
 Developing the structural relationships and interface or
connection rules between elements
 Developing the structure that will support and integrate
the solution components needed to meet the
requirements
 Identifying major internal and external interfaces
or connections
 Defining component behavior and interaction
 Recording definitions using an architecture
description language
 Developing infrastructure capabilities and services
 Developing solution component templates, classes,
or frameworks
 Developing design rules and authority for
making decisions
 Defining a process or thread model
 Identifying major reuse approaches and sources
 Ensuring traceability to requirements
 Example Activities Further Explanation
Identify, develop, or acquire effective Examples of effective design techniques and methods
design methods or tools for the include:
solution.  Prototypes and associated design lessons
 Structural models
 Object-oriented design
 Essential systems analysis
 Entity relationship models
 Design reuse
 Design patterns
Evaluate commercial off-the-shelf Care in evaluating and selecting COTS products and the
(COTS) products. supplier can be critical to the project if the COTS product:
 Is a significant part of the project or solution
 Represents significant risk
Aspects to consider in the selection decision include
proprietary issues and the availability of the products.
Develop a preliminary design. The preliminary design is the foundation for the solution and
the architecture, and may include:
 Architectural styles and patterns
 Component identification
 System states and modes
 Major component interfaces or connections
 External product interfaces or connections
 Algorithms to be employed
 Data definition
Develop a detailed design. May include:
 Finalizing the architecture
 Completing component and interfaces or
connection descriptions
 Optimizing design
 Selecting legacy or commercial components
 Verifying and validating requirements
Track requirements against design to As the design matures, track the requirements assigned to
ensure they are satisfied. lower level solution components and verify that those
requirements are satisfied.
Build the solution. Includes the allocation, refinement, and verification of each
product component. It also involves the coordination
between the various product component development
efforts. Steps to build the solution may include:
 Using effective methods to build the solution.
For example:
o Structured programming
o Automatic code generation
o Software code reuse
o Fabrication methods
o Computer aided design drawing
o Simulation
 Example Activities Further Explanation
 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

Example Work Products

Example Work Products Further Explanation
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

Related Practice Areas

Decision Analysis and Resolution (DAR)
Requirements Development and Management (RDM)

TS 2.2
Required Practice Information
Practice Statement
Evaluate the design and address identified issues.
Value
Reduces cost by minimizing defects and ensuring that the solution meets requirements.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Determine what types of reviews to To evaluate the design, complete a technical review of the
perform. solution and identify deficiencies or potential improvements.
Types of evaluations include:
 Structured design walkthroughs
 Inspections
Identify review participants. Participants can include:
 Authors
 Technical team members
 Project managers
 Subject matter experts (SMEs)
Send draft designs to reviewers. Send these in advance so participants have enough time to
review them.
Conduct a technical review. Develop a review checklist to be available during the review.
Use technical reviews to:
 Present the design to affected stakeholders to develop
a common understanding and gather input regarding
the solution being considered
 Decide the validity of the solution
 Identify issues and concerns with the solution
 Verify that the technical concepts are:
o Correct
o Consistently and correctly used and represented
o Providing value to the solution
Record decisions, issues, and concerns.
Identify potential fixes.
Communicate issues and decisions to Include the role of stakeholders.
affected stakeholders.
Update the design to address identified Assign corrective action to the appropriate stakeholders.
issues.
Review the solution. May include:
 Conducting peer reviews of selected components
 Performing verification of the components as appropriate
 Example Activities Further Explanation
Revise the component as necessary.

Example Work Products

Example Work Products Further Explanation
Design evaluation issues Identified deficiency or improvement with the design.
Design review meeting minutes
Updated design
Updated solution

Related Practice Areas

Peer Reviews (PR)
Requirements Development and Management (RDM)
Verification and Validation (VV)

TS 2.3
Required Practice Information
Practice Statement
Provide guidance on use of the solution.
Value
Helps to ensure that the solution is usable and maintainable.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
This section left blank for future content.
Example Activities
Example Activities Further Explanation
Develop and provide guidance
materials.

Example Work Products

Example Work Products Further Explanation
Guidance material Guidance material may include:
 User manual
 Maintenance manual
Example Work Products Further Explanation
 Installation manual
 Operations manual
 Online help
 Training materials
Level 3

TS 3.1
Required Practice Information
Practice Statement
Develop criteria for design decisions.
Value
Increases the likelihood of producing a robust design that meets customer requirements and
constraints.
Additional Required Information
Record the name and detailed description for each criterion.
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Analyze, develop, evaluate, use, and
keep updated design criteria.
Review and revise the design criteria Revise criteria when requirements, budget, technology, or
with affected stakeholders as needed. resources change or when a defect is discovered.

Example Work Products

Example Work Products Further Explanation
Design criteria Examples of criteria include:
 Complexity
 Cost of:
o Development
o Manufacturing
o Procurement
o Maintenance
o Support
 Time to implement
 Technology availability and limitations
 Resources needed
 Performance
 Robustness
 Requirements and technology evolution
 End use and operator capabilities
 Rationale why alternative solutions are not required
 Example Work Products Further Explanation
 Whether the solution needs to be:
o Modular
o Clear
o Simple
o Maintainable
o Verifiable
o Portable
o Reliable
o Accurate
o Secure
o Scalable
o Usable

TS 3.2
Required Practice Information
Practice Statement
Develop alternative solutions for selected components.
Value
Ensures that the most beneficial solution is identified and selected.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
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
 Example Activities Further Explanation
 Functionality and quality attributes
 Terms and conditions of warranties for the products
Record the requirements allocation for
each alternative.
Communicate results.

Example Work Products

Example Work Products Further Explanation
Alternative solutions

TS 3.3
Required Practice Information
Practice Statement
Perform a build, buy, or reuse analysis.
Value
Ensures that the most effective way to implement the design has been chosen.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Perform a build, buy, or reuse analysis. A decision analysis and resolution method or approach may
be used to address the design criteria and provide the
rationale for making the decision.
Record analysis and communicate
results.

Example Work Products

Example Work Products Further Explanation
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
 Example Work Products Further Explanation
 Costs of acquiring versus developing internally
 Critical delivery and integration dates
 Market research of available products
 Functionality and quality of available solutions
 Skills and capabilities of potential suppliers
 Licenses, warranties, responsibilities, and
limitations associated with solutions being acquired
 Availability
 Proprietary issues
 Regulatory or legal issues
 Risk reduction

Related Practice Areas

Decision Analysis and Resolution (DAR)

TS 3.4
Required Practice Information
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.
Additional Required Information
Include the rationale for selecting the solution.
Explanatory Practice Information
Additional Explanatory Information
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
Example Activities Further Explanation
Evaluate each alternative solution Identify and resolve issues with the alternative solutions and
against the selection criteria. requirements.
High-risk situations may use simulations, prototypes, or
pilots to assist in the evaluation.
Select the solutions that satisfy the
established criteria.
 Example Activities Further Explanation
Based on evaluation of alternatives, Update criteria if additional derived requirements or criteria
reassess and update selection criteria are discovered.
when necessary.
Develop, use, and keep updated
records of solutions, evaluations, and
rationale.

Example Work Products

Example Work Products Further Explanation
Recorded solutions, evaluations, and Includes rationale for selection or rejection.
rationale

Related Practice Areas

Decision Analysis and Resolution (DAR)

TS 3.5
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
This section left blank for future content.
Example Activities
Example Activities Further Explanation
Record the information needed to The technical description defines the required design
implement the solution. configuration and procedures to ensure the performance of
the item is adequate. Provide a technical description of the
solution that addresses such aspects as:
 Development
 Production
 Logistics
 Maintenance
 Operations and support
 Solution lifecycle states and changes
 Example Activities Further Explanation
Revise the information needed to Revise information as scope, requirements, or criteria
implement the solution, as needed. change.

Example Work Products

Example Work Products Further Explanation
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
Required Practice Information
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.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
This section left blank for future content.
Example Activities
Example Activities Further Explanation
Define interface or connection criteria. When defining criteria for interfaces or connections, define or
investigate critical parameters to determine if they are
 Example Activities Further Explanation
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 connections. Examples of users include:
 Developers
 Testers
 Operators
 Users
Each may have their own needs, norms, and perspectives
that may influence how they interact with the solution.
Record, keep updated, use, and
communicate selected interface or
connection criteria, design, and
selection rationale.

Example Work Products

Example Work Products Further Explanation
Interface or connection specification May include:
criteria  Safety
 Security
 Performance
 Standards
 Capacity
Interface or connection design Consistently and correctly designed interfaces or
specification connections, can include:
 Origin
 Destination
 Sequencing constraints or protocols
 Resources needed or consumed
 Exception or error handling behavior for inputs that are
erroneous or out of specified limits
 Electrical, mechanical, and functional characteristics
 Interfaces or connections between solutions
 Interfaces or connections with users, operators,
and maintainers of the solution
 Example Work Products Further Explanation
Interface or connection control
documents
Rationale for selected interface or
connection design
 Verification and Validation (VV)

Required PA Information
Intent
Verification and validation includes activities that:
 Confirm selected solutions and components meet their requirements
 Demonstrate selected solutions and components fulfill their intended use in their target
environment
Value
Verification and validation of selected solutions and components throughout the project
increases the likelihood that the solution will satisfy the customer.
Additional Required PA Information
This section left blank for future content.
Explanatory PA Information
Practice Summary
Level 1
VV 1.1 Perform verification to ensure the requirements are implemented
and record and communicate results.
VV 1.2 Perform validation to ensure the solution will function as intended in
its target environment and record and communicate results.
Level 2
VV 2.1 Select components and methods for verification and validation.
VV 2.2 Develop, keep updated, and use the environment needed to
support verification and validation.
VV 2.3 Develop, keep updated, and follow procedures for verification
and validation.
Level 3
VV 3.1 Develop, keep updated, and use criteria for verification and
validation. VV 3.2 Analyze and communicate verification and validation results.
Additional PA Explanatory Information
Verification and validation activities include identifying corrective actions from verification and
validation activities and tracking them to closure.
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.
Related Practice Areas
Requirements Development and Management (RDM)
Context Specific
Agile with Scrum Guidance

Context Tag: Agile with Scrum

Context: Use processes to adapt agile with Scrum techniques.

Figure VV-1 states where verification and validation activities are performed in an agile
project using Scrum project. Table VV-1 shows example criteria and results.
Agile teams using Scrum typically define a definition of done for each user story or requirement.
Work is performed until the definition of done is met for each User Story. Acceptance from the
product owner is obtained during the sprint review.
The differences between a typical agile project using Scrum and one using verification and
validation practices are the:
 Degree of clarity regarding the procedures used
 Definition of the expected operating environment
  Recording and analyzing of the results
For example, an agile team using Scrum would need to ensure that testing and demonstrations
consider and address how the user will use the solution in the intended environment. Recorded
results show the status of verification and validation activities and provide an opportunity for
analysis.

Figure VV-1: VV in an Agile Framework

Table VV-1: VV Information

Level 1

VV 1.1
Required Practice Information
Practice Statement
Perform verification to ensure the requirements are implemented and record and communicate
results.
Value
Early detection of requirements issues reduces the cost of addressing them and increases
customer satisfaction.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Verification throughout the lifecycle helps to ensure that requirements are implemented
correctly and issues are identified early.
Example Activities
Example Activities Further Explanation
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.

Example Work Products

Example Work Products Further Explanation
Verification results
Action items

VV 1.2
Required Practice Information
Practice Statement
Perform validation to ensure the solution will function as intended in its target environment and
record and communicate results.
Value
Validation activities increase the likelihood that the result will provide the right solution to meet
customer expectations.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
This section left blank for future content.
Example Activities
Example Activities Further Explanation
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.

Example Work Products

Example Work Products Further Explanation
Validation results
Analysis results
Level 2

VV 2.1
Required Practice Information
Practice Statement
Select components and methods for verification and validation.
Value
Produces solutions that meet or exceed customer expectations and needs.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Select solution components for Select solution components based on their contribution to
verification and validation. meeting objectives for the solution. For each solution
component, determine the:
 Scope of the verification and validation activities
 Requirements to be satisfied
 Methods or tools to be used
Solution components that can be verified and validated
include:
 Requirements, designs, and constraints
 Acquired and developed solutions and related components
 User interfaces or connections
 User and operational manuals
 Training materials
 Process documentation
Identify requirements to be satisfied by When identifying requirements for each selected work
each selected work product. product, consult the traceability matrix (or other
 Example Activities Further Explanation
requirements traceability information) maintained as part of
managing requirements for the work.
Determine which customer Target environments may include:
requirements and end user needs will  Testing
be validated.  Operations
 Maintenance
 Training
 Support services
Define, record, and keep updated Examples of verification methods include:
verification and validation methods to  Requirements inspection
be used for each selected solution.  Demonstration
 Load, stress, and performance testing
 Functional, interface or connection, and integration testing
 Prototyping, modeling, and
simulation Examples of validation
methods include:
 Reviews with end users
 Prototype demonstrations
 Functional demonstrations
 Pilots
 Tests of solution components by end users and
other affected stakeholders
Attributes to consider for verification and validation may
include:
 Quality
 Functionality
 Maintainability
 Reliability
Review the validation selection, roles,
responsibilities, constraints, and
methods with affected stakeholders.

Example Work Products

Example Work Products Further Explanation
Lists of solution components selected
for verification and validation
Verification and validation methods for
each selected solution component
List of requirements to be verified and
validated

Related Practice Areas

Decision Analysis and Resolution (DAR)
Requirements Development and Management (RDM)
Context Specific
Development

Context Tag: CMMI-DEV

Context: Use processes to develop quality products and services to meet the needs of
customers and end users.

Verification and validation for hardware engineering typically considers:

 Environmental conditions, e.g., pressure, temperature, vibration, humidity
 Input ranges, e.g., input power could be rated at 20V to 32V for a planned nominal
of 28V
 Variations induced from part to part tolerance issues
Hardware verification normally tests most variables separately except when problematic
interactions are suspected. Hardware verification and validation methods include:
 Modeling to validate form, fit, and function of mechanical designs
 Thermal modeling
 Maintainability and reliability analysis
 Timeline demonstrations
 Simulations
Verification and validation for software engineering typically includes:
 Simulation
 Traceability studies
 Functional reviews or audits
 Physical reviews or audits
 Peer reviews
 Demonstrations
 Prototypes
 Formal reviews
 Module, regression, and system integration testing

VV 2.2
Required Practice Information
Practice Statement
Develop, keep updated, and use the environment needed to support verification and validation.
Value
Project delays are minimized by ensuring that verification and validation environments are
ready when needed.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Identify requirements for the
verification and validation
environment.
Identify customer-supplied solutions This is typically done in the validation environment if the
and components. customer has existing facilities or components that will be
part of the intended environment.
Identify verification and validation Identify verification and validation resources that are
resources, equipment, and tools. available for reuse and modification.
Develop or acquire and keep the
verification and validation
environments updated.
Example Work Products
Example Work Products Further Explanation
Verification environment
Validation environment

VV 2.3
Required Practice Information
Practice Statement
Develop, keep updated, and follow procedures for verification and validation.
Value
Following verification and validation procedures reduces costs for performing the activities and
ensures more predictable performance.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
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
Example Activities Further Explanation
Identify criteria for selecting work
products and activities for verification
and validation.
Develop and keep updated procedures Procedures may cover:
for verification and validation.  Maintenance
 Set up and support of test and evaluation facilities
 Training
Perform verification and validation in
accordance with the procedures.

Example Work Products

Example Work Products Further Explanation
Verification procedures
Validation procedures
Verification and validation results
Level 3

VV 3.1
Required Practice Information
Practice Statement
Develop, keep updated, and use criteria for verification and validation.
Value
Using criteria minimizes waste by ensuring the verification and validation activities focus on
critical needs.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Examples of sources for verification and validation criteria include:
 Solution or solution component requirements
 Business process descriptions
 Standards, regulatory and legal requirements
 Customer requirements
 Customer acceptance criteria
 Solution performance
 Contracts and agreements
Example Activities
Example Activities Further Explanation
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

Example Work Products

Example Work Products Further Explanation
Verification criteria
Validation criteria
VV 3.2
Required Practice Information
Practice Statement
Analyze and communicate verification and validation results.
Value
Analysis and communication of results helps to improve verification and validation effectiveness
over time.
Additional Required Information
This section left blank for future
content. Explanatory Practice
Information Additional Explanatory
Information
Analysis and communication of verification and validation results ensure that issues receive the
appropriate attention from stakeholders and management.
Example Activities
Example Activities Further Explanation
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 may include defect, error, or issue analysis.
results that do not meet established
criteria and determine corrective actions.
Submit improvement proposals where
improvements to verification and validation
process are identified.
Record and communicate analysis results
and corrective actions to affected
stakeholders.

Example Work Products

Example Work Products Further Explanation
Results of actual to expected comparisons
for verification and validation
Analysis results
Corrective actions
Improvement proposals
Appendices
Part Six: Appendices

Appendix A: Core Practice Areas, Categories, and Capability Areas

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

Capability Area:
Ensuring Quality

This CA area includes PAs important to both quality assurance and quality control. The Ensuring
Quality CA includes the following PAs:

Requirements Development and Management enables developing and

keeping updated a common understanding of needs and expectations for the
solution.

Process Quality Assurance ensures the process is followed, and quality

solutions are produced.

Verification and Validation ensures requirements are met and the solution
functions as intended in the target environment.

Peer Reviews identify solution defects or issues.

Capability Area:
Engineering and Developing Products

This CA focuses on engineering, developing, and delivering products and product components.
 Technical Solution focuses on designing and building products and product
components.

Product Integration covers the assembly of the products and product

components and their delivery to the customer and ensures inclusion of
required functionality and quality characteristics.

Capability Area:
Delivering and Managing Services

This CA focuses on developing the capability to deliver agreed upon services, deploying new or
modified services, and establishing a portfolio of services.

Service Delivery Management includes delivering services in accordance

with the established service level agreements.

Strategic Service Management includes developing and keeping a portfolio

of updated standard services that are compatible with strategic needs and
plans.
 Capability Area:
Selecting and Managing Suppliers

This CA establishes the buyer and supplier partnership to ensure that quality solutions are
delivered to the customer and end user.

Supplier Source Selection involves:

 Selecting one or more suppliers to deliver the solution
 Preparing a solicitation package
 Evaluating the supplier’s solution and managing selected connections
of that solution

Supplier Agreement Management involves:

 Developing and keeping updated the supplier agreement
 Ensuring that the supplier and the buyer perform according to the
terms of the supplier agreement

Category: Managing
This category includes CAs for planning and managing work and the workforce.

Capability Area:
Planning and Managing Work

This CA involves determining the amount of work that needs to be done, planning and
scheduling the work, and then ensuring the work is being done in accordance with the plans
and schedules. It also ensures that resources are adequate to meet the plan and schedule.

Estimating includes forecasting the size, effort, and cost for the work
required to develop, acquire, or deliver the solution.
 Planning involves:
 Using the estimates to develop a work plan, schedule, and budget
 Determining the necessary resources to accomplish the plan,
within schedule and budget
 Obtaining commitment to the work plan from stakeholders

Monitor and Control provides an understanding of progress so

appropriate corrective actions can be taken when performance deviates
significantly from the plan, schedule, and budget.

Capability Area:
Managing Business Resilience

This CA addresses the ability to anticipate, prepare for, and respond to interruptions in order to
continue operations. It involves identifying, evaluating, prioritizing, and handling risks. It
ensures timely and effective resolution and prevention of interruptions to minimize the impact
on business operations and ensures the best possible level of service quality. It addresses
defining a minimum set of critical functions that must continue in the event of significant
interruption of normal operations.

Risk and Opportunity Management includes:

 Identifying threats and opportunities
 Evaluating their likelihood of occurrence and impact
 Mitigating potential threats
 Leveraging potential opportunities

Incident Resolution and Prevention includes:

 Identifying actual and potential incidents that may impact delivery
 Establishing the approach for addressing incidents as they occur
 Analyzing incidents to prevent recurrence

Continuity plans and validates the critical set of functions and resources
needed to continue operations when a significant or catastrophic event occurs.
 Capability Area:
Managing the Workforce

This CA addresses the way an organization develops and retains the human resources needed
to perform current and future work.

(FUTURE) Compensation and Rewards involves providing individuals with

wages and benefits based on their contribution and value to the organization.

(FUTURE) Staffing and Workforce Management develops a formal

process to align work with resources and to recruit, select, and transition
qualified individuals to assignments.

(FUTURE) Career and Competency Development enhances the

knowledge, skills, and performance of individuals in the workforce through
mentoring and other professional development techniques.

Organizational Training provides a strategy and capability for training to

support the organization’s strategic business objectives, meet common tactical
needs, and deliver training across the organization.

(FUTURE) Empowered Workgroups builds teams with the skills and

experience needed to accomplish a set of objectives that have clear goals
and well-defined tasks.
Category: Enabling
This category focuses on analyzing causes, making decisions, maintaining integrity of work
products, and communicating to stakeholders.

Capability Area:
Supporting Implementation

This CA involves identifying and addressing the causes of selected outcomes, creating a
decision-making approach and structure, maintaining the integrity of work products,
and fostering communication and coordination among stakeholders.

Causal Analysis and Resolution identifies causes of selected outcomes and

acts to either prevent reoccurrence of undesirable outcomes or ensure
reoccurrence of positive outcomes.

Decision Analysis and Resolution aids in making decisions using criteria-

based evaluation of alternatives and recording the results.

Configuration Management establishes and maintains the integrity of work

products using configuration identification, control, and audits.

(FUTURE) Communication and Coordination promotes timely

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

This CA ensures that safety business objectives and expectations translate into safety policies
that define clear, tangible directives to the organization. Managing safety involves ensuring that
safety is adequately addressed throughout all stages of the solution lifecycle.

(FUTURE) Managing and Planning Safety addresses approaches useful in

the management of environmental, safety, and health mishap risks
encountered in the development, test, production, use, and disposal of
solutions, systems, subsystems, equipment, and facilities.

(FUTURE) Ensuring Safety includes identifying criteria and techniques for

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

This CA ensures security related policies define clear expectations from translating business
objectives into tangible security directives.

(FUTURE) Managing and Planning Security identifies security business

objectives, processes, and assets for secure solution development that satisfy
the needs and objectives of the organization.

(FUTURE) Developing Secure Solutions includes performing security

activities that produce secure solutions.

(FUTURE) Managing Security Threats and Vulnerabilities helps identify

the security threats that could compromise the security objectives of the
solution, analyze the resulting level of risk, and define adequate security
measures and risk handling.

(FUTURE) Managing Supplier Security describes the selection and

management of suppliers to identify threats and vulnerabilities before final
solution integration.

(FUTURE) Planning and Supporting Security in Work includes

information to systematically develop planning and support activities to
achieve security objectives.
Category: Improving
This category involves developing, managing, and improving processes and their related assets
with a primary focus on improving organizational performance.

Capability Area:
Improving Performance

This CA focuses on measuring, analyzing and understanding an organization’s or project’s

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

Process Management develops capabilities and improves performance

though planning, implementing, and deploying improvements based on a
thorough understanding of the current strengths and weaknesses of the
organization’s processes and process assets.

Process Asset Development develops and keeps updated a usable set of

organizational processes and process assets for performing the work.

Managing Performance and Measurement involves:

 Ensuring that benefits and business objectives are the leading
factors driving performance and improvement
 Changing the paradigm:
o From: process improvement leads to performance improvement
o To: performance needs are the primary drivers of
process improvements
 Using the results of measurement and analysis to manage and
control performance at various work and business levels
 Capability Area:
Sustaining Habit and Persistence

This CA ensures that processes are persistent and habitually performed and sustained
throughout the organization and effectively contribute to meeting business performance
objectives.

Governance provides guidance to senior management on their role in

ensuring that work is performed in a way that is relevant and important to the
business and organization.

Implementation Infrastructure provides a framework that ensures the

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

Required and Explanatory Information

As noted in the Overview, both Practice Areas (PAs) and Practices contain required and
explanatory information. In both cases, Required Information is used for verifying that either
the PA or practice intent is being achieved during appraisals. For PA, in order to correctly
interpret and verify that the intent of the PA is met, the following must be looked at
collectively:
 Intent statement
 Value statement
 Additional Required Information
For practices, in order to correctly interpret and verify that the intent of the practice is met, the
following must be looked at collectively:
 Practice statement
 Value statement
 Additional Required Information
Everything other than the required information is informative material. The informative
material of the model cannot be ignored; it is needed to understand the meaning of the
required information of the model. The terms “required” and “informative” in the model are
specifically relevant in the context of appraisals. When adopting CMMI, all model content is
critical to achieving performance and process improvement. For more information on
appraisals, reference the appropriate appraisal requirements, such as the Method Definition
Document (MDD). Figure 25 shows the similarities and differences between PAs and
Practices.
Figure 25. Practice Area vs. Practice Structure
Capability Levels
Capability levels apply to an organization’s performance and process improvement
achievements in individual practice areas. Within PAs, the practices are organized into a set of
evolutionary levels labeled Level 0 to Level 5 which provide a path to performance
improvement. Each evolutionary level builds on the previous levels by adding new functionality
or sophistication resulting in increased capability. Capability levels are represented graphically
by a two-axis bar chart, where one axis is the PA and the other axis is the capability level (i.e.,
0-3) achieved for that PA. Figure 26 shows the evolutional characteristics of the capability
level for practices.
 Figure 26. Evolutionary View of Practice Group Levels in Practices

All capability level ratings must include II and GOV. The maximum level a PA can achieve is
Capability Level 3. Capability levels can be benchmarked to a single PA, if II and GOV are
included. For example, an organization could achieve a Capability Level 3 for the PLAN PA if the
capability levels for the practices in the PLAN, II, and GOV PAs up to Capability Level 3 are
achieved. Figure 27 shows the required Practice Groups (PG) needed for the CM PA to achieve
Capability Level 3. For more information on determining capability levels and ratings, refer to
the MDD.

Figure 27. Capability Level Rating Progression – CM Example

Maturity Levels
Maturity levels apply to an organization’s performance and process improvement achievements
in a predefined set of PAs. Within each maturity level, the predefined set of PAs also provide a
path to performance improvement. Figure 28 shows the names of each maturity level, along
with their characteristics and their evolutionary performance path.
 Figure 28. Maturity Levels Summary

Within each maturity level, performance has been built in to allow organizations to easily
identify performance improvement needs, and then use the model practices to improve. Like
capability levels, maturity levels build on each other and cannot be skipped. The following list
contains a brief description on how maturity levels build on each other.
 Maturity Level 0: the intent of all predefined PAs is not achieved
 Maturity Level 1: the intent of all predefined PAs up to and including Level 1 practices is
achieved at Practice Group Level 1
 Maturity Level 2: the intent of all predefined PAs up to and including Level 2 practices is
achieved at Practice Group Level 2
 Maturity Level 3: the intent of all predefined PAs up to and including Level 3 practices is
achieved at Practice Group 3
 Maturity Level 4: the intent of all predefined PAs up to and including Level 4 practices is
achieved at Practice Group 4
  Maturity Level 5: the intent of all predefined PAs up to and including Level 5 practices is
achieved at Practice Group 5
The CMMI is an integrated set of best practices that improve performance and key capabilities
for the following current and potential CMMI Institute predefined model views:
 CMMI Development (CMMI-DEV), based in part, on the CMMI for Development v1.3 model,
for improving processes and performance for developing better products and services.
 CMMI Services (CMMI-SVC), based in part, on the CMMI for Services v1.3 model, for
improving capabilities and processes for providing better service performance
 CMMI Supplier Management (CMMI-SPM), based in part, on the CMMI for Acquisition v1.3
model, for improving processes and performance for optimizing the supply chain
 (FUTURE) CMMI People Management (CMMI-PPL), based in part, on the People CMM v2
model for Improving processes and performance for managing people
The following tables in Figure 29 through Figure 32 show the organization of the PAs in
Maturity Levels 2-5 for each of the CMMI Institute predefined model views.
Figure 29. CMMI Development, Maturity Levels 2-5
Figure 30. CMMI Services, Maturity Levels 2-5
Figure 31. CMMI Supplier Management, Maturity Levels 2-5
Creating Customized Views
In the future, customized views can also be created and used to address any given challenge,
issue or improvement opportunity. Below are two customized view examples:
Example 1: For a very small development organization just starting out on their performance
and process improvement journey, the following PAs could address their critical problems:
 Estimating (EST)
 Planning (PLAN)
 Monitor and Control (MC)
 Technical Solution (TS)
 Product Integration (PI)
Example 2: For a technical division in an organization that manages development, services, and
suppliers, the following PAs could address their performance improvement needs:
 Incident Resolution and Prevention (IRP)
 Continuity (CONT)
 Strategic Service Management (STSM)
 Technical Solution (TS)
 Product Integration (PI)
 Managing Performance and Measurement (MPM)
 Service Delivery Management (SDM)
 Supplier Source Selection (SSS)
 Supplier Agreement Management (SAM)
 Requirements Development and Management (RDM)
 Governance (GOV)
 Implementation Infrastructure (II)
A key aspect of creating customized views is to:
 Identify the problems
 Determine root causes
 Identify potential process focal points
Figure 32. Development and Multi-Model Capability Area View Examples
Appendix C: CMMI Adoption and Transition Resources
Appendix D: Common CMMI Misperceptions
The following list contains some of the most common misperceptions of the CMMI, as compared
to reality.
Appendix E: Glossary

Glossary Terminology Context

Certain words in the CMMI product suite have special meaning. When applicable, that term is
included in the glossary. Otherwise the common English meaning of words, e.g. Webster or
Oxford dictionary, applies.
Terms appearing in the CMMI glossary take on the characteristics of the content where they
appear in the model or Method Definition Document (MDD). For example, if a term is used in
required information, it is required in that context, or if it appears in the explanatory
information, it is an explanatory term in that context.

5-Whys
A technique used to determine an issue's root causes. This technique involves asking the
question "Why?" repeatedly until the root cause is identified.

acceptance criteria
Criteria that a solution must satisfy to be accepted by customers.

acceptance testing
Testing performed to determine whether a customer, acquirer, user, or their designee should
accept a solution.

acquirer
The stakeholder who obtains a solution from a supplier. (Refer to “affected stakeholder.”)

acquisition
Obtaining solutions by establishing and executing supplier agreements. (Refer to “supplier
agreement.”)

affected stakeholders
People impacted by a process, activity, work product, or decision.

agile
An approach to project management or delivery methodology in which the customer is
intimately involved in the project, tasks are divided into short phases of work, and there is
frequent reassessment and adaptation of plans.

agile with Scrum

This is a CMMI context-specific tag reserved for identifying unique information for agile
projects using Scrum. It is a framework for managing work with an emphasis on software
development. It is designed for small teams of developers who break their work into actions
that can be completed within time-boxed iterations, called sprints, e.g., two-weeks; and track
progress and re-plan in 15-minute stand-up meetings, called daily scrums. (Refer to “agile.”)
allocated requirement
Requirement that results from levying all or part of a higher-level requirement on a solution's
lower-level design component. Requirements can be assigned to logical or physical
components including people, consumables, delivery increments, or the architecture.

appraisal
An examination of one or more processes by a trained team using a reference model as the
basis for determining, at a minimum, strengths and weaknesses.

architecture
The set of structures that need to be considered to establish a solution. These structures are
comprised of smaller components or elements, relationships among those structures and
elements, and the properties of both. (Refer to "functional architecture.”)

assignable cause of process variation

An extraordinary event outside the bounds of the usual steps following the process.

base measure
A base measure is functionally independent of other measures, and cannot be expressed in
other terms. A base measure is defined in terms of an attribute and the method for quantifying
it. (Refer to “derived measure.”)

baseline
A set of specifications or work products that:

 has been formally reviewed and agreed on,

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

Benchmark Model View

A logical grouping of CMMI Institute predefined CMMI model components used to define the
appraisal model view scope.

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

Capability Area (CA)

A group of related Practice Areas that can provide improved performance in the skills and
activities of an organization or project. Capability Areas are a type of view.

capability level
The highest practice group level for a given Practice Area at which the intent of all practices is
met. Capability levels are cumulative and for each practice group level met, all lower level
practice groups must also be met.

Capability Maturity Model Integration (CMMI)

An integrated model of best practices that enable businesses to improve performance by
improving their processes. Product teams developed the model with global members from
across industry and from CMMI Institute. The CMMI provides a best-practice framework for
building, improving, and sustaining process capability. (Refer to “CMMI product suite.”)

capable process
A stable process able to meet the quality and process performance objectives set for it. The
process variation is within set specification limits. (Refer to “stable process.”)
category
Categories are logical groups or types of views of related capability areas that address common
problems encountered by businesses when producing or delivering solutions.

causal analysis
A method of searching for the origination of certain effects. (Refer to “root cause.”)

change management
A methodical approach for controlling and implementing changes in a planned and structured
manner.

CMMI product suite

The integrated set of components that comprise CMMI. The product suite components include
the model, appraisal method, training and certification, adoption guidance, and systems and
tools.
Commercial Off-The-Shelf (COTS)
Describes items that can be purchased from a commercial supplier and used without tailoring.

common cause of variation

The variation of a process that exists because of normal and expected interactions among
components of a process. Also referred to as “inherent cause” of variation. (Refer to “special
cause of variation.”)

configuration audit
An audit conducted to verify that a configuration item or a collection of configuration items in a
baseline conforms to a baseline description. (Refer to “audit” and “configuration item.”)

configuration baseline
The configuration information formally designated at a specific time during a solution or
solution component’s life. Configuration baselines plus approved changes from those baselines
constitute the current configuration information. (Refer to “product lifecycle.”)

configuration control
The process of managing changes to a formal configuration baseline. The process consists of
evaluating the change, coordinating any effects, approving or disapproving the change, and
implementing the changes to configuration items in the baseline. (Refer to, "configuration
identification”, "configuration item”, and "configuration management.”)

configuration control board

A group of people responsible for evaluating and approving or disapproving proposed changes
to configuration items and for ensuring implementation of approved changes. Configuration
control boards are also known as “change control boards”. (Refer to “configuration item.”)

configuration identification
A configuration management activity that involves selecting a product’s configuration items,
assigning them unique identifiers, and recording their functional and physical characteristics in
technical documentation. (Refer to “configuration item” and “configuration management.”)

configuration item
Work products designated for configuration management and treated as a single entity in the
configuration management process. (Refer to “configuration management.”)

configuration management
The process of managing the integrity of work products using configuration identification,
version control, change control, and audits. (Refer to “configuration identification”,
“configuration item”, “configuration audit”, and “version control.”)

contractual requirements
Result of analysis and refinement of customer requirements into a set of requirements suitable
for inclusion in solicitation packages or supplier agreements.

Contractual requirements include technical and nontechnical requirements necessary to

acquire a solution.
(Refer to “acquirer”, “customer requirement”, and “supplier agreement.”)

core assets
Assets essential to a solution and may include:

 Components
 Domain models
 Requirements
 Performance models
 Estimates and plans
 Test plans and test descriptions
 Process descriptions
customer
The party responsible for buying or accepting a solution or for authorizing payment for a
solution. Customers may also be end users.

customer requirement
The result of eliciting and consolidating needs, and resolving conflicts among those needs,
expectations, constraints, and interfaces to clarify and define the solutions with affected
stakeholders in a way that is acceptable to them. (Refer to “customer.”)

data
Qualitative or quantitative-based information that can be recorded, communicated, and
analyzed.

defect density
Number of defects per unit of solution size. An example is the number of bugs per thousand
lines of code.

defined process
The subset of organizational process assets that are essential for any tailored and managed
process. A fully defined process has enough detail that it can be consistently performed by
trained and skilled people and is both persistent and habitual. A defined process is necessary
at the practice group evolutionary level 3 in the CMMI practice areas (Refer to “managed
process.”)
deliverable
An item to be provided to an acquirer or other designated recipient as specified in an
agreement. This item can be a document, hardware item, software item, service, or any type of
work product. (Refer to “acquirer.”)

derived measure
Measure defined as a function of two or more base measures. Derived measures are often
expressed as ratios, composite indices, or other aggregate summary measures. (Refer to “base
measure.”)
derived requirements
Requirements that are not explicitly stated in customer requirements, but are inferred and
developed from:

 contextual requirements, e.g., applicable standards, laws, policies, common

practices, management decisions; or
 requirements needed to specify a solution component.
Derived requirements can also arise during analysis and design of solution components. (Refer
to “product component requirements.”)

design review
A formal, recorded, comprehensive, and systematic examination of a solution or component
design to determine if the design meets applicable requirements, identify problems, and
propose solutions.

develop, use, and keep updated

This phrase is a fundamental principle in CMMI: work products resulting from projects’ and
organizational processes must be used and useful to the work and enable performance. The
work products should be kept current to reflect how work is performed or improved.

development
To create a solution by deliberate effort. In some contexts, development can include
maintenance of the developed product or service system. In the CMMI product suite, when this
term is used with the phrase “Development context specific”, it is referring to this definition.

DevOps
A combination of the terms: “development” and “operations”. This is an enterprise software
development phrase used to mean a type of agile relationship between development and
Information Technology (IT) operations. The goal of DevOps is to change and improve the
relationship between development and operations by advocating better communication and
collaboration between these two business units.

document
A collection of information and data, regardless of the medium, that generally has permanence
and can be read by humans or machines. Documents can be work products reflecting the
implementation of processes that meet the intent of one or more model practices. Documents
may be embedded within an automated, robotic, or online system. Documents can be
hardcopies, softcopies, or accessible via hyperlinks in a web-based environment or application.
Documents are used and kept updated. (Refer to “artifact” and “record.”)
entry criteria
Conditions that must be met before an effort can begin successfully. (Refer to “exit criteria.”)

example activities
Possible actions that may be taken when implementing processes that meet the intent of
a practice. The intent of "Example Activities" is to serve as guidance and suggestions, not
as required activities. It is not intended to be a comprehensive list.
example work products
Possible outputs of implementing processes that meet the intent of a practice. The intent of
"Example Work Products" is to serve as guidance and suggestions, not as required work
products. It is not intended to be a comprehensive list.

exit criteria
Conditions that must be met before successful completion of an effort. (Refer to “entry
criteria.”)

functional analysis
An examination of functions of the solution or solution components to broaden and deepen
understanding.

functional architecture
The conceptual structure and logical arrangement of functions. This may include internal and
external interface functions. (Refer to “architecture” and “functional analysis.”)

gemba walk
The term used to describe personal observation of work – where the work is happening. The
original Japanese term comes from gembutsu, which means “real thing”. (Also known as
“genba walk.”)

hardware engineering
The application of a systematic, disciplined, and measurable approach to transforming a set of
requirements, using documented techniques and technology to design, implement, and
maintain a tangible solution. In CMMI, hardware engineering represents all technical fields,
e.g., electrical, mechanical; that transform requirements and ideas into tangible solutions.
(Refer to “software engineering” and “systems engineering.”)
High Maturity
CMMI Model practice group levels (and their associated practices) of 4 or 5 are considered High
Maturity practices and levels. High Maturity organizations and projects use quantitative and
statistical analysis to determine, identify, and manage central tendency and dispersion and
understand and address process stability and capability and how these impact the achievement
quality and process performance objectives.
informative material
Includes everything other than the required information. Explanatory information in practices
are part of the informative material. Informative material also includes the overview and
appendices, e.g. glossary, index. Informative material must not be ignored, it is needed to
correctly understand and adopt the model.

External links can be added to the informative material. These are links to external assets such
as:

 Additional informative material

 Adoption examples
  Transition and adoption guidance from one model or standard to others
 Templates
 Training materials
integration environment
The configuration of processes, systems, tools, people, and associated infrastructure used when
combining components to develop a solution.

interface data
Information describing interfaces or connections.

interface or connection
A shared boundary across components, humans, services, hardware, or software that needs or
exchanges information or data. Either term “interface” or “connection” may be used to
describe this boundary.

interface or connection description

A description of the functional and physical characteristics of a component and its boundaries,
e.g. user, system, that describes its interaction with another component.

lifecycle model
A representation or description of the steps and activities for the development and updating of
a solution communicated to stakeholders and followed by a project or organization. This
description may include:

 Phases
 Sequence
 Interrelationships
 Inputs
 Outputs
 Decisions points
 Roles and responsibilities
managed process
A performed process that is recorded, followed, updated, and made persistent and habitual in
its use. A managed process is necessary at the Practice Group evolutionary level 2 in the CMMI
Practice Areas (Refer to “performed process.”)

maturity level

A rating that describes the degree to which processes in an Organizational Unit meet the intents
of a predefined set of Practice Areas. The rating is based on the achievement of a specified set
of practice group levels within the predefined set of Practice Areas.
measurement and performance objectives
Used to describe quantitative or qualitative objectives that do not require the additional rigor of
statistical or quantitative analysis.

measurement-based
Numerical data obtained by performing measurements, but not based on statistical and
quantitative management.

memorandum of agreement
A record of expectations and arrangements between two or more parties also known as a
“memorandum of understanding”. (Refer to “Statement Of Work.”)

model component
Any of the five main architectural elements or parts that compose the CMMI model. These
include the view, practice area, practice group, practice, and informative material. (Refer to
“informative material”, “practice”, “practice area”, “practice group”, and “view.”)

natural bounds
The inherent range of variation in a process, as determined by process performance measures.
Natural bounds are sometimes referred to as “control limits” or the “voice of the process”.

objectively evaluate
To review activities and work products against criteria that minimize subjectivity and bias by
the reviewer.

operational concept
A general description of the way in which a component or solution is used or operates. An
operational concept may also be referred to a “concept of operations.”

operational scenario
A description of a potential sequence of events that includes the interaction of a component or
solution with its environment and users, and with other solution components. Operational
scenarios are used to evaluate the requirements and design of the system and to verify and
validate the system.

opportunity
An uncertain event that may positively impact meeting objectives.

optimizing process
A quantitatively managed process that is continually improved to increase its capability. These
continuous improvements can be made through both incremental and innovative improvements.
An optimizing process is necessary at the practice group evolutionary level 5 in the CMMI
Practice Areas. (Refer to “quantitatively managed process” and “defined process” for contrast.)

or
The use of “or” in the CMMI model means either “and” or “or.”
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.”)

organization’s set of standard processes

A collection of process descriptions that guide consistent process implementation across an
organization. These process descriptions cover the fundamental process elements and their
relationships to each other such as ordering and interfaces that should be incorporated into the
defined processes that are implemented in work groups across the organization. A standard
process is essential for long-term stability and improvement. (Refer to “process description”
and “process element.”)
organizational directives
Expectations established by senior management that are adopted by an organization to
influence and determine decisions, may also be referred to as “organizational policies.”

peer reviews
The examination of work products performed by similarly skilled personnel during the
development of work products to identify defects for removal. Peer reviews are sometimes
called work product inspections. (Refer to “work product.”)

performance parameters
Measurable criteria used to monitor progress towards quantitative objectives. Collectively,
performance parameters provide a metric for determining success for the business or project.
Performance Work Statement (PWS)
A Statement of Work (SOW) for performance-based acquisitions that clearly describes the
performance objectives and standards that are expected of the contractor. When a contract is
awarded, the PWS is a legally binding document upon the contractor. (Refer to “SOW.”)

performed process
A simple approach or set of steps that produces solutions or work products. A performed
process is characteristic of practice group evolutionary level 1 in the CMMI Practice Areas.

persistent and habitual

The routine way of doing business and following and improving process that an organization
follows as part of its culture.

practice
A practice consists of two parts:

 Required practice information: Information required to understand the full intent and
value of the practice, which includes the practice statement, the value statement, and the
additional required information
 Explanatory practice information: Remaining parts of the practice, including example
activities and work products, which are important and useful to better understand the
meaning and intent of the required information, including the practice statement, value, and
additional required information
Practice Area (PA)
A collection of similar practices that together achieve the defined intent, value, and required
information described in that Practice Area.

Practice Area (PA) Required Information

The intent, value, and any additional required information for a Practice Area.

practice group
The organizing structure for practices within a Practice Area to aid understanding and adoption
and provides a path for performance improvement. Currently, the practice groups defined for
CMMI are evolutionary levels.

process
A set of interrelated activities, which transform inputs into outputs to achieve a given purpose.
(Refer to “process element.”)

process action team

A team with responsibility for developing and implementing process improvement activities for
an organization. (Refer to “process group.”)

process architecture
The ordering, interfaces, interdependencies, and other relationships among the process
elements in a standard process, or standard processes.
process capability
A recorded range of expected results that can be achieved by following a process.

process description
A record for a specific process. Process descriptions may be documents, embedded or
automated steps or instructions in a robot, component, system or tool, or graphical
representations, etc.

process element
The fundamental unit of a process that cannot be further broken down.

process group
The people or team who hold a process role and are responsible for developing, deploying, and
updating the organization's process assets. (Refer to “process role.”)
process improvement
Tasks and activities planned, performed and used to improve an organization's process
capability and performance to achieve business objectives more effectively. (Refer to
“organization’s business objectives.”)

process improvement objectives

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

process improvement plan

A process improvement plan records the objectives, activities, resources, oversight, schedules,
and associated risks to improve processes.

process measurement
Activities performed to collect information and assign numeric values related to the activities,
steps, and outputs of following a process. This information is analyzed to determine the
effectiveness and efficiency of a process. (Refer to “measurement” and "process
performance.”)

process owner
The person or team responsible for developing, updating or following a process. An
organization or project can have multiple owners at different levels of responsibility for:

 organization’s set of standard processes

 project-specific and project-defined processes
process performance
A measure of results achieved by following a process. Process performance may be
characterized by both process measures, e.g., effort, cycle time, defect removal efficiency, and
solution measures, e.g., reliability, defect density, response time. (Refer to “business
performance.”)
process performance baseline
A record and description of historical process performance resulting from following a defined
process, which can include central tendency, e.g., mean, medium, mode, variation, and
reflects how the process is being performed. Process performance baselines can be used as
benchmarks for comparing actual process performance to expected process performance and
can be used in process performance models to predict future process performance. (Refer to
“process performance” and “process performance model.”)

process performance model

A predictive analytical tool that identifies the controllable factors and describes the relationships
between measurable attributes of one or more processes, subprocesses, process elements, or
work products. (Refer to “process performance baseline” and “quality and process performance
objectives.”)

process role
A description of the roles of people who develop, use, or follow a process in an organization.
This role is typically recorded in a process description or related artifact, e.g., a roles and
responsibility table or matrix. People in these roles provide objective evidence OE showing and
explaining their roles and responsibilities and how they participate in the processes.

product component
A work product that is a building block of the product, or solution. Integrate product
components to produce the final product, or solution. There can be multiple levels of
components.

product lifecycle
A representation of the set of steps or activities, consisting of phases, that begins at
conception of a product or service and ends when the product or service is no longer available
for use. For example, a product lifecycle could consist of the following phases:

 concept and vision

 feasibility
 design/development
 production
 delivery
 phase out, retire, or sunset
Organizations can produce multiple products or services for multiple customers, and so may
define multiple product lifecycles. These lifecycles may be adapted from published literature for
use in an organization.

product line
A group of products:

 sharing a common, managed set of features

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

quality and process performance objectives

Quantitative objectives and performance requirements for solution quality and process
performance. These objectives include the use of statistical and quantitative analysis on the
related data. (Refer to “measurement and performance objectives.”)

quality attribute
Property of a solution by which affected stakeholders will judge its quality. Quality attributes
are:

 "Non-functional”
 Significantly influence architecture
 Characterized by one or more
measures Quality attribute examples:

 Availability
 Maintainability
 Modifiability
 Reliability
 Responsiveness
 Scalability
 Security
 Timeliness
 Throughput
  Usability
quantitative management
Managing a project using quantitative techniques to understand actual or predicted process
performance relative to quality and process performance objectives, variation, and identifying
corrective action needed to meet the objectives.

quantitative objective
Desired target value expressed using measures. (Refer to “measure”, “process improvement
objectives”, and “quality and process performance objectives.”)

quantitatively managed process

A defined process evaluated and controlled using statistical and other quantitative techniques.
A quantitatively managed process is necessary at the practice group evolutionary level 4 in the
CMMI Practice Areas.

reference model
A defined model describing practices and activities that is used for improving performance or as
a benchmark for measuring capability or maturity.

requirement
A recorded description of an aspect, performance, or capability required by a user or customer.

requirements analysis
Tasks that determine the needs or conditions to meet a new or altered solution, accounting for
multiple perspectives, e.g., balancing stakeholder needs and constraints, allocation of
requirements to components, breaking down complex requirements to lower level
requirements.
requirements elicitation
A technique used to gather knowledge or information to proactively identify and record
customer and end user needs.

requirements management
The process of documenting, analyzing, tracing, prioritizing and agreeing on requirements and
then controlling change and communicating to relevant stakeholders. It is a continuous process
throughout a project.

requirements traceability
A record of the relationships between requirements and related requirements, implementations,
and verifications. (Refer to “bidirectional traceability.”)

Return On Investment (ROI)

The ratio of benefit of a process or solution improvement to implementation costs to determine
the value.

risk
A potential uncertain event that may be harmful or may negatively impact achieving objectives.
risk mitigation
A set of planned activities, which if performed, may minimize the probability or impact of the
risk.

root cause
The underlying source of a defect or problem.

senior management
The person or persons who provide the policy and overall guidance for the process, but do not
typically provide the direct day-to-day monitoring and controlling of the process. A senior
manager has authority to direct the allocation or reallocation of resources in support of
organizational process improvement effectiveness. A senior manager can be any manager who
satisfies this description, including the head of the organization.
Service Level Agreement (SLA)
A contract between a service provider, either internal or external, and the customer or end user
that defines the level of service expected from the service provider. SLAs are output-based in
that their purpose is specifically to define what the customer will receive. SLAs do not define
how the service itself is provided or delivered.

service system
An integrated and interdependent combination of components that satisfies stakeholder
requirements.

service system component

A process, work product, person, consumable, customer, or other resource required for a
service system to deliver value. Service system components can include components owned by
the customer or a third party.
service system consumable
An item used by the service system that ceases to be available or becomes permanently
changed by its use during the delivery of a service.
shared vision
A common understanding of guiding principles, including mission, objectives, expected
behavior, values, and final outcomes, developed and used by a project or work group.

size
Number of items, or volume of work effort or work products being produced, such as activities,
pages, requirements, number of components, solutions. Use size as a basis for scoping when
producing estimates and plans.

solution
A product, product component, service, service system, service system component, or delivered
or acquired product or service.
solution component
A work product that is a building block of the solution. Solution components are integrated
to produce the solution. There can be multiple levels of solution components. (Refer to
“product component.”)

special cause of variation

A cause of process variation that is a result of a known factor that results in a non-random
distribution of output. Also referred to as “exceptional” or “assignable” cause variation and is
temporary in nature and not an inherent part of the process. (Refer to “common cause of
variation.”)

stable process
The state in which special causes of process variation have been removed from the process and
prevented from recurring. In a stable process, only common cause variation of the process
remains. (Refer to “capable process”, “common cause of variation”, and “special cause of
variation.”)

Statement Of Objectives (SOO)

The recorded top-level objectives of an acquisition or procurement, used to guide discussions
and negotiations between the acquirer and the supplier.

Statement Of Work (SOW)

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

statistical and other quantitative techniques

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

statistical process control

Statistical analysis that identifies common and special causes of process variation and seeks to
maintain process performance within limits. (Refer to “common cause of variation”, “special
cause of variation”, and “statistical techniques.”)

statistical techniques
Mathematical techniques used with the collection, analysis, interpretation, and presentation of
masses of numerical data to understand process variation and predict process performance.
Examples include sampling techniques, analysis of variance, chi-squared tests, regression
analysis, and process control charts.

subprocess
A process that is part of a larger process. Subprocesses can be further decomposed into
subprocesses and/or process elements. (Refer to "process”, "process description”, and "process
element.”)

supplier
An entity having an agreement with an acquirer to design, develop, manufacture, maintain,
modify, deliver, or supply solutions under terms of an agreement. Examples include individuals,
partnerships, companies, corporations, and associations. (Refer to “acquirer.”)

supplier deliverable
An item to be provided to an acquirer or other recipient as specified in an agreement. The item
can be a document, hardware or software item, a service, a solution, or any type of work
product.

systems engineering
Interdisciplinary approach governing technical and managerial effort required to transform a set
of customer needs, expectations, and constraints into solutions and to support solutions
throughout their lifecycle.

tailoring
Developing or adapting a process description or work product according to organizational
defined standard guidelines to achieve a result. For example, a project develops its tailored
process from the organization’s set of standard processes to meet objectives, constraints within
the project environment. (Refer to “organization’s set of standard processes” and “process
description.”)

tailoring guidelines
Organizational guidelines that enable individuals, projects, and organizational functions to
appropriately adapt standard processes for their use. Tailoring guidelines may allow additional
flexibility when dealing with less critical processes or those that only indirectly affect business
objectives. (Refer to “organization’s set of standard processes” and “tailoring.”)

technical data package

A set of work products and information used to implement the design, e.g., coding standards,
version control information, and engineering drawings.

technical performance
Characteristic of a process or solution generally defined by a functional or technical requirement
that is often recorded in a contract or Statement Of Work.

trade study
An evaluation of alternatives, based on criteria and systematic analysis, to select the best
alternative for attaining determined objectives.
unit testing
Testing of individual hardware or software units.

version control
Identifies the correct versions of work products and ensures the right versions are available for
use or for restoring to a previous version. Also includes the establishment and maintenance of
baselines and the identification of changes to baselines to obtain previous baselines.

Work Breakdown Structure (WBS)

A list of tasks and activities, related work elements and their relationship to each other and to
the end product or service.

work product
An output from a process, activity, or task and may be a stand-alone output, or part of a
solution.

work product and task attributes

Characteristics of solutions and tasks used to estimate work. These characteristics often include
size, complexity, weight, form, fit, and function. Characteristics are typically used as one input
to deriving other resource estimates, e.g., effort, cost, schedule. (Refer to “work product.”)
Appendix F: Abbreviations

Abbreviation Term
CA Capability Area
CAR Causal Analysis and Resolution
CCB Change or Configuration Control Board
CCD Career and Competency Development
CDR Critical Design Review
CL Capability Level
CM Configuration Management
CMM Capability Maturity Model
CMMI Capability Maturity Model Integration
CMMI-DEV CMMI for Development
CMMI-PPL CMMI for People Management
CMMI-SPM CMMI for Supplier Management
CMMI-SVC CMMI for Services
COCO Communication and Coordination
COMP Compensation and Rewards
CONT Continuity
COOP Continuity Of Operations
COTS Commercial Off-The-Shelf
CPM Critical Path Method
DAR Decision Analysis and Resolution
DEV Development
DSS Develop Secure Solutions
ES Ensuring Safety
EST Estimating
EVMS Earned Value Management System
EWG Empowered Workgroups
FMEA Failure Mode and Effects Analysis
FMECA Failure Mode, Effects, and Criticality Analysis
GOV Governance
GQM Goal Question Metric
IBR Integrated Baseline Review
Abbreviation Term
II Implementation Infrastructure
IMS Integrated Master Schedule
IRP Incident Resolution and Prevention
IT Information Technology
IV&V Independent Verification and Validation
MC Monitor and Control
MDD Method Definition Document
ML Maturity Level
MPM Managing Performance and Measurement
MPS Managing and Planning Security
MPSF Managing and Planning Safety
MSS Managing Secure Suppliers
MST Managing Security Threats and Vulnerabilities
MTBF Mean Time Between Failures
MTTF Mean Time to Failure
OT Organizational Training
OTRR Operational Test Readiness Review
PA Practice Area
PAD Process Asset Development
PAL Process Asset Library
PCM Process Management
P-CMM People-CMM
PDR Preliminary Design Review
PERT Program Evaluation and Review Technique
PG Practice Groups
PI Product Integration
PLAN Planning
PPL People Management
PQA Process Quality Assurance
PR Peer Reviews
PRR Production Readiness Review
PSSW Planning and Supporting Security in Work
PWS Performance Work Statement
Abbreviation Term
QPPO Quality and Process Performance Objectives
RASCI Responsible, Accountable, Support, Consulted, Informed
RDM Requirements Development and Management
RFP Request For Proposal
ROI Return on Investment
RSK Risk and Opportunity Management
SAM Supplier Agreement Management
SCAMPI Standard CMMI Appraisal Method for Process Improvement
SDM Service Delivery Management
SEI Software Engineering Institute
SHP Sustaining Habit and Persistence
SLA Service Level Agreement
SME Subject Matter Experts
SOO Statement Of Objectives
SOP Standard Operating Procedure
SOW Statement Of Work
SPM Supplier Management
SRR System Requirements Review
SSS Supplier Source Selection
STSM Strategic Service Management
SVC Services
SW-CMM Software CMM
SWM Staffing and Workforce Management
SWOT Strength, Weakness, Opportunity, and Threat
TRA Technology Readiness Assessment
TRR Test Readiness Review
TS Technical Solution
VV Verification and Validation
WBS Work Breakdown Structure
Appendix G: CMMI Development History
The Capability Maturity Model (CMM) was developed in the late 1980s/early1990s and version
1.0 was released in 1991. CMMI originally was a combination of software and systems
engineering CMMs along with product line and supplier sourcing models first released in 2000.
The release timeline is listed below:
 1984 Carnegie Mellon University awarded funding to establish the Software
Engineering Institute (SEI)
 1987 SEI releases a software process maturity framework and maturity questionnaire to
support organizations in improving their software process.
 1991 Software CMMI (SW-CMM) V1.0
 1993 SW-CMM V1.1
 1995 People CMM (P-CMM) V1.0
 1997 SW-CMM work on CMM V1.2 stopped
 1999 Undersecretary of Defense (J. Gansler) Memo – SW-CMM ML3 Required for ACAT 1
programs
 2000 CMMI V1.02
 2002 CMMI V1.1
 2004 CMMI-ACQ V1.0
 2005 CMMI-ACQ V1.1
 2006 CMMI V1.2 (Included CMMI-DEV)
 2007 CMMI-ACQ V1.2
 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
Appendix H: References

CMMI Institute. CMMI for Acquisition, Version 1.3, Pittsburgh, PA: November
2010. http://cmmiinstitute.com/cmmi-models

CMMI Institute. CMMI for Development, Version 1.3. Pittsburgh, PA, August
2006. http://cmmiinstitute.com/cmmi-models

CMMI Institute. CMMI for Services, Version 1.3. Pittsburgh, PA: November 2010.
http://cmmiinstitute.com/cmmi-models

CMMI Institute. Data Management Maturity Model, Version 1.3. Pittsburgh, PA: 2011.
http://cmmiinstitute.com/cmmi-models

CMMI Institute. People CMM, Version 2.0. Pittsburgh, PA: November 2010.
http://cmmiinstitute.com/cmmi-models

CMMI Institute. Standard CMMI Appraisal Method for Process Improvement (SCAMPI) A,
Version 1.3, Pittsburgh, PA: 2011. http://cmmiinstitute.com/cmmi-models

Crosby, Philip B. Quality Is Free: The Art of Making Quality Certain. New York: McGraw-Hill,
1979.

Deming, W. Edwards. Out of the Crisis. Cambridge, MA: MIT Center for Advanced Engineering,
1986.

Humphrey, Watts S. Managing the Software Process. Reading, MA: Addison-Wesley, 1989.

Institute of Electrical and Electronics Engineers. Multiple Standards. New York: IEEE, 2017.
https://www.ieee.org/standards/index.html

International Organization for Standardization. ISO 9001:2015 Quality management systems -

Requirements. ISO, 2015. http://www.iso.org/iso/iso_catalogue/.

ISACA, COBIT 5.0. Rolling Meadows, IL: ISACA,

2012.http://www.isaca.org/COBIT/Pages/COBIT-5-Framework-product-page.aspx

Juran, Joseph M. Juran on Planning for Quality. New York: Macmillan, 1988.

SAE International/Electronic Industries Alliance standard ANSI/EIA-748, Earned Value

Management Systems (EVMS), Version C, Warrendale, PA, April 2014.

Shewhart, Walter A. Economic Control of Quality of Manufactured Product. New York: Van
Nostrand, 1931.

Wheeler, Donald J. Understanding Variation The Key to Managing Chaos. SPC Press, Knoxville,
TN: 2000.
Appendix I: Acknowledgements

Corporate Sponsors
CMMI Institute is grateful to the organizations who sponsored the development of the
CMMI V2.0 Product Suite. These organizations provided crucial input, direction, and
resources that made the leap to the CMMI V2.0 Product Suite possible.
“CMMI V2.0’s benchmark appraisal method has improved our confidence in the results and
lowered the overall lifecycle cost of our appraisals. In addition, using the sustainment appraisal
approach with brief mid-cycle evaluations has increased our focus on both process
implementation and improvement.”
-Allan McQuarrie, Deputy Vice President/General Manager, Technology Solutions, BAE Systems

“We are very proud that Siemens as a thought leader contributed to the CMMI V2.0. Topics
such as Agile, Lean, Security, and Performance Management are essential for our business. We
are welcoming very much that these are now strengthened in the new CMMI.”
-Jürgen Kirsch, Vice President CD C PLM Consulting, Siemens
CMMI V2.0 Product Suite Leadership Team
The CMMI V2.0 Project was led by a committed team made up of individuals from sponsor
organizations and the CMMI Institute. This team used the insights from market research to
build a product suite and strategy to meet the needs of industry today, while creating a
platform that will grow and change for the needs of the future. Thank you to the CMMI V2.0
Leadership Team!
 Kirk Botula, CEO, CMMI Institute
 Joe Callahan, Director of Marketing, CMMI Institute
 Timothy Crumbley, NASA Software Engineering Program Executive, NASA
 Ryan Fulmer, Project Manager, CMMI Institute
 Sally Godfrey, Emeritus, NASA
 Craig Hollenbach, Technical Fellow; Manager of Performance and
Governance, Engineering Center of Excellence, Northrop Grumman Corporation
 Michael LaBarge, Consultant, Performance and Methods Consulting
 Ron Lear, Architect of CMMI Institute Products, CMMI Institute
 Lisa McConihe, Senior Principal Engineer, BAE Systems
 Darlene Moore, Quality Manager, CMMI Institute
 Sheela Nath, Business Writer, CMMI Institute
 Lynn Penn, President, Performance and Methods Consulting
 Winfried Russwurm, Principal Consultant, Siemens AG
 Prabhakar Sundar, Director - Global, Honeywell International
 Reewa Saluja, Director, CMMI Product Solutions, CMMI Institute
 Kevin Schaaff, CMMI Practice Leader, CMMI Institute
 Alexander Stall, CMMI Practice Leader, CMMI Institute
 Katie Tarara, Manager of Partner and Client Services, CMMI Institute
 Kathryn Tate, Training Development Manager, CMMI Institute
 Dan Torrens, COO, CMMI Institute
 Sean Ways, IT Manager, CMMI Institute
 Rusty Young, CMMI Architect - Emeritus, CMMI Institute
CMMI V2.0 Product Suite Developers
These Product Developers worked together with the Leadership Team to build the content,
materials, and systems for CMMI V2.0. Thank you to the Development team of Product
Developers!
 Madison Borgmann, UX Designer, CMMI Institute
 Tony Destro, Senior Web Developer, CMMI Institute
 Kieran Doyle, President, Excellence in Measurement Technology
 Adrian Gill, Founder, Gillpage Associates
 Jason Godesky, UI/UX Engineer, CMMI Institute
 Fred Haigh, VP, COO, Haigh Group
 Mary Anne Herndon, Consultant, Transdyne Corporation
 Paul Kimmerly, Consultant, Double Play Process Diagnostics
 Michele Lamptey-Uhrich, Manager, Process Initiatives, Northrop Grumman Corporation
 Brian Mack, Senior QA Analyst, CMMI Institute
 Winifred Menezes, Consultant, Freya Consulting
 Rajesh Naik, Founder Partner, QAI India
 Heather Oppenheimer, Senior Partner, Oppenheimer Partners
 Guido Paolano, Principal Engineer, CMMI Institute
 Madhumita Poddar Sen, Madhumita
 Neil Potter, Consultant, The Process Group
 Enrique Roman, Consultant, Innevo
 Thomas Seckel, Principal Engineer, Northrop Grumman Corporation
 Agapi Svolou, Owner, Alexanna
 Richard Waina, Principal Consultant, Multi-Dimensional Maturity
Contributors to CMMI V2.0 Product Suite
Many individual contributors volunteered their time and expertise to make CMMI V2.0 possible.
They provided insight from their years of experience and helped the developers create better
products. Thank you to these CMMI V2.0 contributors!
 Peter Barletto, Global Process Solutions
 Richard Bechtold, Abridge Technology
 Scott Bender, Aetna
 William Bettesworth, Honeywell International
 Bradley Bittorf, Raytheon
 Daniel Blazer, Leidos
 Petr Bohacek, Honeywell International
 Antonio Braga, Crest Consulting
 Glyn Davies, BAE Systems
 Juliet Davis, Boeing
 Jeff Dotseth, General Dynamics
 John Ekas, CMMI Institute
 Valeria Franzitta, Robert Bosch GmbH
 Maggie Glover, Excellence in Measurement Technology
 Luciano Guerrero, Procesix
 Jean-Yves Guilbaud, Inspearit
 Satinder Kaur, CMMI Institute
 Ravindra Khetan, RH Process Consulting
 Randy Kitano, ESPN
 Gary Lunsford, Gary Lunsford Consulting
 Monika Maidl, Siemens AG
 Diane McDonald, StepUp Solutions
 Amanda Parrotte, CMMI Institute
 Dan Payne, ABI Consultants LLC
 David Quinn, MOSAIC Technologies Group
 Siva Ravuri, Wabtec
 John Ryskowski, John F Ryskowski Consulting
 Mary Segnit, Harris Corporation
 Anandkumar K. Shelat, KPMG
 Marian Tadros, TRI EXL
 Geoff Terrell, CMMI Institute
 Kerry Trujillo, Raytheon
 Dean Venable, Lockheed Martin Corporation
 David Walker, David Walker SPCS
 Beth Wise, Boeing
 Sreeramamurthy Yellayi, SPA Business Services
 Christian Zion, Thales
Reviewers for CMMI V2.0 Product Suite
Over 100 people with years of experience using CMMI reviewed the various pieces of the CMMI
V2.0 Product Suite and provided their input and feedback. Their comments—thousands of them
—greatly strengthened the final product. Thank you to the CMMI V2.0 reviewers!
 Ahmed Abd El Aziz  Peter Leeson
 Inigo Garro
 Drew Allison
 Yasser Ghanim
 Délio Almeida
 Aditya Goel
 Lemis Altan
 Sharonlyne Graves
 Naoya Anada
 David Greer
 Shane Atkinson
 César Pablo Gutiérrez
 Joachim Bauchrowitz Martinez
 Yan Bello  Michael Hallinan
 Bonnie Bollinger  Kileen Harrison
 Eileen Bozzolo  Zhou Heng
 Paul Byrnes  Casimiro Hernandez Parro
 Maria Eugenia Caetano  Yanjun (Jim) Hu
 Arnaud Chivard  Shu-Min Hwang
 Po-Ching (Antoine) Chuang  Nevine Iskandar
 PJ Corum  Seongkyu Jeong
 Claudio Costa  Kent Johnson
 Mira Culley  Ho-Won Jung
 Jeff Dalton  Himanshu Karkhanis
 Sundar Gopal Das  Mangesh Katalkar
 David Dayton  Muhammad Furqan Khan
 Christophe Debou  Takami Kihara
 Huey Der Chu  Sungil Kim
 Sankararaman Dhandapani  Denise Kirkham
 Yasser Dakroury  Ralf Kneuper
 Saswata Dutta  Galina Knopman
 Emily Finnegan  Alexander Kondakov
 Livia Franzitta  Krishnamurthy
Kothandaraman
 Kathy Gallucci
 Moustanir Lamnabhi
 Roger Gamage
 Beth Layman
 Sam Gao
 Fei Li
 Binshan Liao
 Mirko Lovo
 Mukul Madan
 Gururaj Managuli
 Kaliappan Marappa
 Don Marohl
 Larry McCarthy
 Eugene McGuire
 Karen McKeown
 Takeshige Miyoshi
 Deke Moellerd
 Jyoti Mohile
 Cecilia Montero
 Enrique Morey
 Manpreet Mudahar
 Boris Mutafelija
 Raghavan Nandyal
 Hasan Syed Niaz
 Gary Norausky
 Yoetsu Otaki
 Pat O'Toole
 Francois Ouellette
 Dilek Ozdemirci
 Geetha Parthasarathy
 Malcom Patrick
 Rich Pavlik
 Mariana Perez-Vargas
 Erwin Petry
 Marilyn Phillips
 William Pierce
 Louis Poulin
 Shawn Presson
 Teenu Puri
 Kris Puthucode
 Pascal Rabbath
 Parthasarathy Ramachandran
 Puthucode Ratnagiri Ganesh
 Aihua Ren
 Jialin (Dylan) Ren
 Leigh Riley
 Paul Riviere
 Viviana Rubinstein
 Jesús Sánchez
 Hitesh Sanghavi
 Giuseppe Satriani
 Vladimir Savin
 Henry Schneider
 Joe Schofield
 Pamela Schoppert
 Balaji Selvaraju
 Prabhuu Sinha
 Samiya Slim
 Kathy Smith
 Daniele Sorrentino
 Srijith Sreenivasan
 Sanjay Srinivasan
 Kimberly Stewart
 Beril Tasdemir