CMMI-demo

1. 
   

   
   

Pittsburgh,
PA 15213-3890

CMMI^®
for Development, Version 1.2

CMMI-DEV, V1.2

CMU/SEI-2006-TR-008

ESC-TR-2006-008

Improving
processes for better products

CMMI Product Team

August 2006

Unlimited
distribution subject to the copyright.

This work is sponsored by the
U.S. Department of Defense. The Software Engineering Institute is a

federally funded research and development center sponsored by the
U.S. Department of Defense.

Copyright 2006 by Carnegie Mellon
University.

NO WARRANTY

THIS CARNEGIE
MELLON^®
UNIVERSITY AND SOFTWARE ENGINEERING INSTITUTE MATERIAL IS FURNISHED
ON AN “AS-IS” BASIS. CARNEGIE MELLON UNIVERSITY MAKES NO
WARRANTIES OF ANY KIND, EITHER EXPRESSED OR IMPLIED, AS TO ANY MATTER
INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR PURPOSE OR
MERCHANTABILITY, EXCLUSIVITY, OR RESULTS OBTAINED FROM USE OF THE
MATERIAL. CARNEGIE MELLON UNIVERSITY DOES NOT MAKE ANY WARRANTY OF
ANY KIND WITH RESPECT TO FREEDOM FROM PATENT, TRADEMARK, OR COPYRIGHT
INFRINGEMENT.

Use of any trademarks in this
report is not intended in any way to infringe on the rights of the
trademark holder.

Internal use.
Permission to reproduce this document and to prepare derivative works
from this document for internal use is granted, provided the
copyright and “No Warranty” statements are included with all
reproductions and derivative works.

External use. Requests for
permission to reproduce this document or prepare derivative works of
this document for external and commercial use should be addressed to
the SEI Licensing Agent.

This work was
created in the performance of Federal Government Contract Number
FA8721-05-C-0003 with Carnegie Mellon University for the operation of
the Software Engineering Institute, a federally funded research and
development center. The Government of the United States has a
royalty-free government-purpose license to use, duplicate, or
disclose the work, in whole or in part and in any manner, and to have
or permit others to do so, for government purposes pursuant to the
copyright license under the clause at 252.227-7013.

For information about purchasing
paper copies of SEI reports, please visit the publications portion of
our Web site (http://www.sei.cmu.edu/publications/pubweb.html).

The following service marks and registered marks are
used in this document:
Capability
Maturity Model^?
CMM^?
CMM
Integration^SM
CMMI^?
IDEAL^SM

SCAMPI^SM

CMMI, CMM, and Capability
Maturity Model are registered in the U.S. Patent and Trademark
Office.

CMM Integration, SCAMPI, and IDEAL are service marks of
Carnegie Mellon University.

Preface

CMMI^®
(Capability Maturity Model^® Integration) is a process
improvement maturity model for the development of products and
services. It consists of best practices that address development and
maintenance activities that cover the product lifecycle from
conception through delivery and maintenance.

This
latest iteration of the model as represented herein integrates bodies
of knowledge that are essential for development and maintenance, but
that have been addressed separately in the past, such as software
engineering, systems engineering, hardware and design engineering,
the engineering “-ilities,” and acquisition. The prior
designations of CMMI for systems engineering and software engineering
(CMMI-SE/SW) are superseded by the title “CMMI for Development”
to truly reflect the comprehensive integration of these bodies of
knowledge and the application of the model within the organization.
CMMI for Development (CMMI-DEV) provides a comprehensive integrated
solution for development and maintenance activities applied to
products and services.

CMMI
for Development, Version 1.2 is a continuation and update of CMMI
version 1.1 and has been facilitated by the concept of CMMI
“constellations” wherein a set of core components can be
augmented by additional material to provide application-specific
models with highly common content. CMMI-DEV is the first of such
constellations and represents the development area of interest.

Purpose

The purpose of CMMI for Development is to help organizations improve
their development and maintenance processes for both products and
services. CMMI for Development is a collection of best practices that
is generated from the CMMI Framework.¹
The CMMI Framework supports the CMMI Product Suite by allowing
multiple models, training courses, and appraisal methods to be
generated that support specific areas of interest.

A
constellation is a collection of CMMI components that includes a
model, its training materials, and appraisal-related documents for an
area of interest. Currently there are three planned constellations
supported by the version 1.2 model framework: development, services,
and acquisition. “Additions” are used to expand constellations
for specific additional content.

This
document contains the CMMI for Development constellation and contains
both the base CMMI-DEV as well as CMMI-DEV with the IPPD addition
(CMMI-DEV+IPPD).

If
you are not using IPPD, ignore the information that is marked “IPPD
Addition,” and you will be using the CMMI for Development model.

Unlike
CMMI version 1.1, there is but a single model document that describes
both the staged and continuous approaches to process improvement
versus the prior use of two representations of staged and continuous
in separate documents. This consolidated presentation of model
material for both approaches was first used in the book, CMMI:
Guidelines for Process Integration and Product Improvement.
Thanks to Peter Gordon, publishing partner at Addison-Wesley
Professional, and the book’s authors, Mary Beth Chrissis, Mike
Konrad, and Sandy Shrum, we were able to use the book’s manuscript
as the basis for developing CMMI version 1.2 [Chrissis 2003].

Acknowledgments

Many
talented people were involved as part of the product team for the
CMMI v1.2 Product Suite. Three primary groups involved in this
development were the Steering Group, Product Team, and Configuration
Control Board.

The
Steering Group guides and approves the plans of the Product Team,
provides consultation on significant CMMI project issues, and ensures
involvement from a variety of interested communities.

The
Product Team writes, reviews, revises, discusses, and agrees on the
structure and technical content of the CMMI Product Suite, including
the framework, models, training, and appraisal materials. Development
activities are based on multiple inputs. These inputs include an
A-Specification and guidance specific to each release provided by the
Steering Group, source models, change requests received from the user
community, and input received from pilots and other stakeholders [SEI
2004].

The
Configuration Control Board is the official mechanism for controlling
changes to the CMMI models and Introduction to CMMI training.
As such, this group ensures integrity over the life of the product
suite by reviewing all proposed changes to the baseline and approving
only those changes that satisfy the identified issues and meet the
criteria for the upcoming release.

Members
of these groups that were involved in developing CMMI v1.2, are
listed in Appendix C.

Audience

The
audience for this model includes anyone interested in process
improvement in a development and maintenance environment. Whether you
are familiar with the concept of Capability Maturity Models or
whether you are seeking information to get started on your
improvement efforts, this document will be useful to you.

This
model is also intended for people who want to use an appraisal²
to see where they are, those who already know what they want to
improve, and those who are just getting started and want to develop a
general understanding of the CMMI for Development constellation.

Organization of
This Document

This
document is available on the SEI Web site³
and serves as a guide for improvement of organizational processes. It
is organized into three main parts:

• 
  Part
  One—About CMMI for Development

  
  

• 
  Part
  Two—Generic Goals and Generic Practices, and the Process Areas

  
  

• 
  Part
  Three—The Appendices and Glossary

  
  

Part
One, “About CMMI for Development,” consists of five chapters:

• 
  Chapter
  1, “Introduction,” offers a broad view of CMMI and the CMMI for
  Development constellation. It introduces you to the concepts of
  process improvement, and describes the history of models used for
  process improvement and different process improvement approaches.

  
  

• 
  Chapter
  2, “Process Area Components,” describes all of the components of
  the CMMI for Development process areas.

  
  

• 
  Chapter
  3, “Tying It All Together,” assembles the model components and
  explains the concepts of maturity levels and capability levels.

  
  

• 
  Chapter
  4, “Relationships among Process Areas,” provides insight into
  the meaning and interactions of the CMMI for Development process
  areas.

  
  

• 
  Chapter
  5, “Using CMMI Models,” describes paths to adoption and use of
  CMMI for process improvement and benchmarking.

  
  

Part
Two, “Generic Goals and Generic Practices, and the Process Areas,”
contains all of the CMMI for Development constellation’s required
and expected components. It also contains related informative
components, including component names, subpractices, notes, and
typical work products.

Part
Two contains 23 sections. The first section contains the generic
goals and practices, including a description of how they are used and
how they relate to the process areas. The remaining 22 sections each
represent one of the CMMI for Development process areas.⁴
To make these process areas easy to find, they are organized
alphabetically by process area acronym. Each section contains
descriptions of goals, best practices, and examples.

Part
Three, “The Appendices and Glossary,” consists of four
information resources:

• 
  Appendix
  A, “References,” contains references you can use to locate
  documented sources of information such as reports, process
  improvement models, industry standards, and books that are related
  to CMMI for Development.

  
  

• 
  Appendix
  B, “Acronyms,” defines the acronyms used herein.

  
  

• 
  Appendix
  C, “CMMI for Development Project Participants,” contains lists
  of people and their organizations who participated in the
  development of CMMI for Development, Version 1.2.
  

  
  

• 
  The
  “Glossary” defines many of the terms used in CMMI.

  
  

How to Use This
Document

Whether
you are new to process improvement, new to CMMI, or already familiar
with CMMI, Part One can help you understand why CMMI for Development
is the best model to use for improving your development and
maintenance processes.

Readers New to Process
Improvement

If
you are new to process improvement or new to the CMM^®
concept, we suggest that you read Chapter 1, “Introduction,”
first. Chapter 1 will give you an overview of process improvement and
explain what CMMI is all about.

Next,
skim Part Two, including generic goals and practices as well as
specific goals and practices, to get a feel for the scope of the best
practices contained in the model. Pay closest attention to the
purpose and introductory notes at the beginning of each section.

In
Part Three, look through the references in Appendix A and select
additional sources you think would be beneficial to read before
moving forward with using CMMI for Development. Read through the
acronyms and glossary to become familiar with the language of CMMI.
Then, go back and read the details of Part Two.

Readers Experienced
with Process Improvement

If
you are new to CMMI but have experience with other process
improvement models, such as the Software CMM (version 1.1) or the
Systems Engineering Capability Model (i.e., EIA 731), you will
immediately recognize many similarities [EIA 1998].

We
recommend that you read Part One to understand how CMMI is different
from other process improvement models, but you may want to read some
of the sections more quickly than others. Read Part Two with an eye
open for best practices you recognize from the models you have
already tried. Identifying familiar material gives you a feel for
what is new and what has been carried over from the model you already
know.

Next,
review the glossary to understand how some terminology may differ
from that used in the process improvement model you know. Many
concepts will be repeated, but they may be called something
different.

Readers Familiar with
CMMI

If
you have reviewed or used a CMMI model before, you will quickly
recognize the CMMI concepts discussed and the best practices
presented. The differences between version 1.2 and version 1.1 are
explained in detail on the SEI Web site in the version 1.2 release
notes. These differences reflect the enhancements suggested by the
users of version 1.1.

The
following improvements were made to version 1.2:

• 
  Both
  representations are presented together.

  
  

• 
  The
  advanced practice and common feature concepts have been removed.

  
  

• 
  The
  generic goal and practice descriptions were moved to Part Two.

  
  

• 
  Hardware
  amplifications were added.

  
  

• 
  All
  definitions were consolidated in the glossary.

  
  

• 
  IPPD
  practices were consolidated and simplified. There are no longer any
  separate IPPD process areas.

  
  

• 
  Supplier
  Agreement Management (SAM) and Integrated Supplier Management (ISM)
  were consolidated and Supplier Sourcing was removed.

  
  

• 
  Generic
  practice (GP) elaborations were added to the level 3 GPs.

  
  

• 
  An
  explanation of how process areas support the implementation of GPs
  was added.

  
  

• 
  Material
  was added to ensure that standard processes are deployed to projects
  at their startup.

  
  

Additional
Information and Reader Feedback

You
can find additional information from various other sources about
CMMI, such as the background and history of the CMMI models, as well
as the benefits of using CMMI models. Many of these sources are
listed in Appendix A and are also published on the CMMI Web
site—http://www.sei.cmu.edu/cmmi/ [SEI 2].

Suggestions
for improving CMMI are welcome. For information on how to provide
feedback, see the CMMI Web site at
http://www.sei.cmu.edu/cmmi/models/change-requests.html. If you have
questions about CMMI, send an email to cmmi-comments@sei.cmu.edu.

Part One

About CMMI for
Development

1Introduction

Now,
more than ever, companies want to deliver products and services
better, faster, and cheaper. At the same time, in the high-technology
environment of the twenty-first century, nearly all organizations
have found themselves building increasingly complex products and
services. Today, a single company usually does not develop all the
components that compose a product or service. More commonly, some
components are built in-house and some are acquired; then all the
components are integrated into the final product or service.
Organizations must be able to manage and control this complex
development and maintenance process.

The
problems these organizations address today involve enterprise-wide
solutions that require an integrated approach. Effective management
of organizational assets is critical to business success. In essence,
these organizations are product and service developers that need a
way to manage an integrated approach to their development activities
as part of achieving their business objectives.

In
the current marketplace, there are maturity models, standards,
methodologies, and guidelines that can help an organization improve
the way it does business. However, most available improvement
approaches focus on a specific part of the business and do not take a
systemic approach to the problems that most organizations are facing.
By focusing on improving one area of a business, these models have
unfortunately perpetuated the stovepipes and barriers that exist in
organizations.

Capability
Maturity Model^® Integration (CMMI^®) provides
an opportunity to avoid or eliminate these stovepipes and barriers
through integrated models that transcend disciplines. CMMI for
Development consists of best practices that address development and
maintenance activities applied to products and services. It addresses
practices that cover the product’s lifecycle from conception
through delivery and maintenance. The emphasis is on the work
necessary to build and maintain the total product.

About Capability
Maturity Models

In
its research to help organizations develop and maintain quality
products and services, the Software Engineering Institute (SEI) has
found several dimensions that an organization can focus on to improve
its business. Figure 1.1 illustrates the three critical dimensions
that organizations typically focus on: people, procedures and
methods, and tools and equipment.

Figure
1.1: The Three Critical Dimensions

But
what holds everything together? It is the processes used in your
organization. Processes allow you to align the way you do business.
They allow you to address scalability and provide a way to
incorporate knowledge of how to do things better. Processes allow you
to leverage your resources and to examine business trends.

This
is not to say that people and technology are not important. We are
living in a world where technology is changing by an order of
magnitude every ten years. Similarly, people typically work for many
companies throughout their careers. We live in a dynamic world. A
focus on process provides the infrastructure necessary to deal with
an ever-changing world, and to maximize the productivity of people
and the use of technology to be more competitive.

Manufacturing
has long recognized the importance of process effectiveness and
efficiency. Today, many organizations in manufacturing and service
industries recognize the importance of quality processes. Process
helps an organization’s workforce meet business objectives by
helping them work smarter, not harder, and with improved consistency.
Effective processes also provide a vehicle for introducing and using
new technology in a way that best meets the business objectives of
the organization.

In
the 1930s, Walter Shewhart began work in process improvement with his
principles of statistical quality control [Shewhart 1931]. These
principles were refined by W. Edwards Deming [Deming 1986], Phillip
Crosby [Crosby 1979], and Joseph Juran [Juran 1988]. Watts Humphrey,
Ron Radice, and others extended these principles even further and
began applying them to software in their work at IBM and the SEI
[Humphrey 1989]. Humphrey’s book, Managing the Software Process,
provides a description of the basic principles and concepts on which
many of the capability maturity models (CMMs^®) are based.

The
SEI has taken the process management premise, “the quality of a
system or product is highly influenced by the quality of the process
used to develop and maintain it,” and defined CMMs that embody this
premise. The belief in this premise is seen worldwide in quality
movements, as evidenced by the International Organization for
Standardization/International Electrotechnical Commission (ISO/IEC)
body of standards.

CMMs
focus on improving processes in an organization. They contain the
essential elements of effective processes for one or more disciplines
and describe an evolutionary improvement path from ad hoc, immature
processes to disciplined, mature processes with improved quality and
effectiveness.

The
SEI created the first CMM designed for software organizations and
published it in a book, The Capability Maturity Model: Guidelines
for Improving the Software Process [SEI 1995].

The
SEI’s book applied the principles introduced almost a century ago
to this never-ending cycle of process improvement. The value of this
process improvement approach has been confirmed over time.
Organizations have experienced increased productivity and quality,
improved cycle time, and more accurate and predictable schedules and
budgets [Gibson 2006].

Evolution of CMMI

Since
1991, CMMs have been developed for myriad disciplines. Some of the
most notable include models for systems engineering, software
engineering, software acquisition, workforce management and
development, and integrated product and process development (IPPD).

Although
these models have proven useful to many organizations in different
industries, the use of multiple models has been problematic. Many
organizations would like their improvement efforts to span different
groups in their organizations. However, the differences among the
discipline-specific models used by each group, including their
architecture, content, and approach, have limited these
organizations’ capabilities to broaden their improvements
successfully. Further, applying multiple models that are not
integrated within and across an organization is costly in terms of
training, appraisals, and improvement activities.

The
CMM Integration^SM project was formed to sort out the
problem of using multiple CMMs. The CMMI Product Team’s initial
mission was to combine three source models:

1. 
   The
   Capability Maturity Model for Software (SW-CMM) v2.0 draft C
   [SEI 1997b]
   

   
   

2. 
   The
   Systems Engineering Capability Model (SECM) [EIA 1998]⁵

   
   

3. 
   The
   Integrated Product Development Capability Maturity Model
   (IPD-CMM) v0.98 [SEI 1997a]

   
   

The
combination of these models into a single improvement framework was
intended for use by organizations in their pursuit of enterprise-wide
process improvement.

These
three source models were selected because of their widespread
adoption in the software and systems engineering communities and
because of their different approaches to improving processes in an
organization.

Using
information from these popular and well-regarded models as source
material, the CMMI Product Team created a cohesive set of integrated
models that can be adopted by those currently using the source
models, as well as by those new to the CMM concept. Hence, CMMI is a
result of the evolution of the SW-CMM, the SECM, and the IPD-CMM.

Developing
a set of integrated models involved more than simply combining
existing model materials. Using processes that promote consensus, the
CMMI Product Team built a framework that accommodates multiple
disciplines and is flexible enough to support the different
approaches of the source models [Ahern 2003].

Figure
1.2: The History of CMMs

Since
the release of CMMI v1.1, we have seen that this improvement
framework can be applied to other areas of interest [SEI 2002a, SEI
2002b]. To apply to multiple areas of interest, the framework groups
best practices into what we call “constellations.” A
constellation is a collection of CMMI components that are used to
build models, training materials, and appraisal documents.

Recently,
the CMMI model architecture was improved to support multiple
constellations and the sharing of best practices among constellations
and their member models. Work has begun on two new constellations:
one for services (CMMI for Services) and the other for acquisition
(CMMI for Acquisition). Although CMMI for Development incorporates
the development of services, including the combination of components,
consumables, and people intended to meet service requirements, it
differs from the planned CMMI for Services (CMMI-SVC), which focuses
on the delivery of services. The CMMI models that have been available
in the community prior to 2006 are now considered part of the CMMI
for Development constellation.

CMMI for
Development

The
CMMI for Development constellation consists of two models: CMMI for
Development +IPPD and CMMI for Development (without IPPD). Both
models share much of their material and are identical in these shared
areas. However, CMMI for Development +IPPD contains additional goals
and practices that cover IPPD.

Currently,
only one model is published since the CMMI for Development +IPPD
model contains the full complement of practices available in this
constellation, and you can derive the other model from this material.
If you are not using IPPD, ignore the information that is marked
“IPPD Addition,” and you will be using the CMMI for Development
model. If the need arises or the development constellation is
expanded, the architecture will allow other models to be generated
and published.

CMMI
for Development is the designated successor of the three source
models. The SEI has retired the Software CMM and the IPD-CMM. EIA has
retired the SECM. All three of these models are succeeded by CMMI for
Development.

The
best practices in the CMMI models have gone through an extensive
review process. CMMI version 0.2 was publicly reviewed and used in
pilot activities.

The
CMMI Product Team evaluated more than 3,000 change requests to create
CMMI version 1.0. Shortly thereafter, version 1.02 was released,
which incorporated several minor improvements.

Version
1.1 incorporated improvements guided by feedback from early use, with
more than 1,500 change requests submitted as part of the public
review, and hundreds of comments as part of the change control
process.

CMMI
version 1.2 was developed using input from nearly 2,000 change
requests submitted by CMMI users. More than 750 of those requests
were directed at CMMI model content. As you can see, not only is CMMI
widely adopted, but it is improved based on the feedback received
from the community.

The Scope of CMMI
for Development

CMMI
for Development is a reference model that covers the development and
maintenance activities applied to both products and services.
Organizations from many industries, including aerospace, banking,
computer hardware, software, defense, automobile manufacturing, and
telecommunications, use CMMI for Development.

Models
in the CMMI for Development constellation contain practices that
cover project management, process management, systems engineering,
hardware engineering, software engineering, and other supporting
processes used in development and maintenance. The CMMI for
Development +IPPD model also covers the use of integrated teams for
development and maintenance activities.

The Group of IPPD
Additions

In
CMMI, “additions” are used to include material that may be of
interest to particular users. For the CMMI for Development
constellation, additional material was included to address IPPD.

The
IPPD group of additions covers an IPPD approach that includes
practices that help organizations achieve the timely collaboration of
relevant stakeholders throughout the life of the product to satisfy
customers’ needs, expectations, and requirements [DoD 1996]. When
using processes that support an IPPD approach, you should integrate
these processes with other processes in the organization. To support
those using IPPD-related processes, the CMMI for Development
constellation allows organizations to optionally select the IPPD
group of additions.

When
you select CMMI for Development +IPPD, you are selecting the CMMI for
Development model plus all the IPPD additions. When you select CMMI
for Development, you are selecting the model without the IPPD
additions. In the text in Part One of this document, we may use “CMMI
for Development” to refer to either of these models, for the sake
of brevity.

Resolving Different
Approaches of CMMs

The
definition of a CMM allows the community to develop models supporting
different approaches to process improvement. As long as a model
contains the essential elements of effective processes for one or
more disciplines and describes an evolutionary improvement path from
ad hoc, immature processes to disciplined, mature processes with
improved quality and effectiveness, it is considered a CMM. CMMI
enables you to approach process improvement and appraisals using two
different representations: continuous and staged.

The
continuous representation enables an organization to select a process
area (or group of process areas) and improve processes related to it.
This representation uses capability levels to characterize
improvement relative to an individual process area.

The
staged representation uses predefined sets of process areas to define
an improvement path for an organization. This improvement path is
characterized by maturity levels. Each maturity level provides a set
of process areas that characterize different organizational
behaviors.

Choosing a
Representation

If
you are new to process improvement and are not familiar with either
the staged or the continuous representation, you cannot go wrong if
you choose one representation or the other. There are many valid
reasons to select either representation.

If
you have been using a CMM and you are familiar with a particular
representation, we suggest that you continue to use that
representation because it will make the transition to CMMI easier.
Once you have become completely comfortable with CMMI, you might then
decide to use the other representation.

Because
each representation has advantages over the other, some organizations
use both representations to address particular needs at various times
in their improvement programs. In the following sections, we provide
the advantages and disadvantages of each representation to help you
decide which representation is best for your organization.

Continuous
Representation

The
continuous representation offers maximum flexibility when using a
CMMI model for process improvement. An organization may choose to
improve the performance of a single process-related trouble spot, or
it can work on several areas that are closely aligned to the
organization’s business objectives. The continuous representation
also allows an organization to improve different processes at
different rates. There are some limitations on an organization’s
choices because of the dependencies among some process areas.

If
you know the processes that need to be improved in your organization
and you understand the dependencies among the process areas described
in CMMI, the continuous representation is a good choice for your
organization.

Staged Representation

The
staged representation offers a systematic, structured way to approach
model-based process improvement one stage at a time. Achieving each
stage ensures that an adequate process infrastructure has been laid
as a foundation for the next stage.

Process
areas are organized by maturity levels that take some of the guess
work out of process improvement. The staged representation prescribes
an order for implementing process areas according to maturity levels,
which define the improvement path for an organization from the
initial level to the optimizing level. Achieving each maturity level
ensures that an adequate improvement foundation has been laid for the
next maturity level and allows for lasting, incremental improvement.

If
you do not know where to start and which processes to choose to
improve, the staged representation is a good choice for you. It gives
you a specific set of processes to improve at each stage that has
been determined through more than a decade of research and experience
with process improvement.

Comparison of the
Continuous and Staged Representations

Table
1.1 compares the advantages of each representation and may assist you
with determining which representation is right for your organization.

Table
1.1 Comparative Advantages of Continuous and Staged Representations

Continuous Representation	Staged Representation
Grants explicit freedom to select the order of improvement that best meets the organization’s business objectives and mitigates the organization’s areas of risk	Enables organizations to have a predefined and proven improvement path
Enables increased visibility of the capability achieved in each individual process area	Focuses on a set of processes that provide an organization with a specific capability that is characterized by each maturity level
Allows improvements of different processes to be performed at different rates	Summarizes process improvement results in a simple form—a single maturity level number
Reflects a newer approach that does not yet have the data to demonstrate its ties to return on investment	Builds on a relatively long history of use that includes case studies and data that demonstrate return on investment

Factors in Your
Decision

Three
categories of factors that may influence your decision when selecting
a representation are business, culture, and legacy.

Business Factors

An
organization with mature knowledge of its own business objectives is
likely to have a strong mapping of its processes to its business
objectives. Such an organization may find the continuous
representation useful to appraise its processes and in determining
how well the organization’s processes support and meet its business
objectives.

If
an organization with a product-line focus decides to improve
processes across the entire organization, it might be served best by
the staged representation. The staged representation will help an
organization select the critical processes to focus on for
improvement.

The
same organization may opt to improve processes by product line. In
that case, it might select the continuous representation—and a
different appraised rating of capability might be achieved for each
product line. Both approaches are valid. The most important
consideration is which business objectives you would like your
process improvement program to support and how these business
objectives align with the two representations.

Cultural Factors

Cultural
factors to consider when selecting a representation have to do with
an organization’s capability to deploy a process improvement
program. For instance, an organization might select the continuous
representation if the corporate culture is process based and
experienced in process improvement or has a specific process that
needs to be improved quickly. An organization that has little
experience in process improvement may choose the staged
representation, which provides additional guidance on the order in
which changes should occur.

Legacy

If
an organization has experience with another model that has a staged
representation, it may be wise to continue with the staged
representation when using CMMI, especially if it has invested
resources and deployed processes across the organization that are
associated with a staged representation. The same is true for the
continuous representation.

Why Not Both
Representations?

Whether
used for process improvement or appraisals, both representations are
designed to offer essentially equivalent results. Nearly all of the
CMMI model content is common to both representations. Therefore, an
organization need not select one representation over another.

In
fact, an organization may find utility in both representations. It is
rare that an organization will implement either representation
exactly as prescribed. Organizations that are successful in process
improvement often define an improvement plan that focuses on the
unique needs of that organization and therefore use the principles of
both the staged and the continuous representations.

For
example, organizations that select the staged representation and are
at maturity level 1 often implement the maturity level 2 process
areas but also the Organizational Process Focus process area, which
is included at maturity level 3. Another example is an organization
that chooses the continuous representation for guiding its internal
process improvement effort and then chooses the staged representation
to conduct an appraisal.

Your Approach to
Process Improvement

To
demonstrate how to use this model, let us look at two different
scenarios. Scenario 1 is an electronic systems developer that wants
to improve its product development processes using a continuous
approach. Scenario 2 is a software development company that uses
IPPD, has been using the Software CMM, and now wants to use CMMI.
This company most recently has been rated at maturity level 3 using
the Software CMM (version 1.1).

Scenario 1

In
this scenario, you are using a continuous approach and, therefore,
you select the processes that are important to your business
objectives. Since there are 22 process areas to choose from, this is
usually too many to focus on when starting out. You may need to
narrow your focus. For example, you may find that your competitor
always releases its product before yours. You may choose to focus on
improving your engineering and project management processes.

Building
on this decision, you select all the Engineering process areas as a
starting point: Product Integration, Requirements Development,
Requirements Management, Technical Solution, Validation, and
Verification. You also select Project Planning and Project Monitoring
and Control.

You
may at this point decide that eight process areas are still too many
to focus on initially, and you decide that the requirements process
is really where the problems are. Consequently, you select the
Requirements Development and Requirements Management process areas to
begin your improvement efforts.

Next
you decide how much improvement is needed in the requirements area.
Do you have any processes in place already? If you do not, your
process improvement objective may be to get to capability level 1.

Do
you have your requirements development and management processes in
place for each project, but they are not managed processes? For
example, policies, training, and tools are not implemented to support
the processes. If your requirements processes are in place but there
is no supporting infrastructure, your process improvement objective
may be to get to capability level 2.

Do
you have all your requirements development and management processes
and their management in place, but each project performs these
processes differently? For example, your requirements elicitation
process is not performed consistently across the organization. If
this is the case, your process improvement objective may be to get to
capability level 3.

Do
you consistently manage and perform your requirements development and
management processes but do not have an objective way to control and
improve these processes? If this is the case, your process
improvement objective may be to get to capability level 4.

Do
you want to ensure that you are selecting the right subprocesses to
improve based on quantitative objectives to maximize your business?
If so, your process improvement objective may be to get to capability
level 5 for selected processes. In the description of each process
area, remember to look for amplifications introduced by the phrases
“For Hardware Engineering,” “For Systems Engineering,” and
“For Software Engineering.” Use all information that has no
specific markings and the material in the boxes labeled “Continuous
Only.”

As
you can see from this scenario, you need to understand which
processes need improvement and how much you want to mature each
process. This way of proceeding reflects the fundamental principle
behind the continuous representation.

Scenario 2

In
the second scenario, you are a software development company using
IPPD, using the Software CMM, and you want to use CMMI. You select
the process areas at maturity levels 2 and 3 and choose the CMMI for
Development +IPPD model.

This
selection includes the following seven process areas at maturity
level 2: Requirements Management, Project Planning, Project
Monitoring and Control, Supplier Agreement Management, Measurement
and Analysis, Process and Product Quality Assurance, and
Configuration Management. It also includes the following 11 process
areas at maturity level 3: Requirements Development, Technical
Solution, Product Integration, Verification, Validation,
Organizational Process Focus, Organizational Process Definition
+IPPD, Organizational Training, Integrated Project Management +IPPD,
Risk Management, and Decision Analysis and Resolution. You will also
include the IPPD additions.

Since
you have already been rated at maturity level 3 for the Software CMM,
look at the CMMI process areas that were not in the Software CMM.
These process areas include Measurement and Analysis, Requirements
Development, Technical Solution, Product Integration, Verification,
Validation, Risk Management, and Decision Analysis and Resolution.
Determine if you have these processes in your organization even
though they were not described in the Software CMM. If any processes
in place correspond to these process areas and the other process
areas that were in the Software CMM, perform a gap analysis against
the goals and practices to make sure you addressed the intent of each
CMMI process area.

Remember,
in each process area you select, to look for information labeled “For
Software Engineering” and “IPPD Addition.” Use all information
that has no specific markings, as well as the material in boxes
labeled “Staged Only.”

As
you can see, the information provided in this document can be used in
a variety of ways, depending on your improvement needs. The overall
goal of CMMI is to provide a framework that can share consistent
process improvement best practices and approaches, but can be
flexible enough to address the rapidly changing needs of the
community.

2Process Area Components

This
chapter describes the components of each process area, generic goal,
and generic practice. Understanding the meaning of these components
is critical to using the information in Part Two effectively. If you
are unfamiliar with Part Two, you may want to skim the Generic Goals
and Generic Practices section and a couple of process area sections
to get a general feel for the content and layout before reading this
chapter.

Required, Expected,
and Informative Components

Model
components are grouped into three categories—required, expected,
and informative—that reflect how to interpret them.

Required Components

Required
components describe what an organization must achieve to satisfy a
process area. This achievement must be visibly implemented in an
organization’s processes. The required components in CMMI are the
specific and generic goals. Goal satisfaction is used in appraisals
as the basis for deciding whether a process area has been achieved
and satisfied.

Expected Components

Expected
components describe what an organization may implement to achieve a
required component. Expected components guide those who implement
improvements or perform appraisals. Expected components include the
specific and generic practices.

Before
goals can be considered satisfied, either the practices as described,
or acceptable alternatives to them, are present in the planned and
implemented processes of the organization.

Informative Components

Informative
components provide details that help organizations get started in
thinking about how to approach the required and expected components.
Subpractices, typical work products, amplifications, generic practice
elaborations, goal and practice titles, goal and practice notes, and
references are examples of informative model components.

The
CMMI glossary of terms is not a required, expected, or informative
component of CMMI models. You should interpret the terms in the
glossary in the context of the model component in which they appear.

Components
Associated with Part Two

The
model components associated with Part Two can be summarized to
illustrate their relationships, as shown in Figure 2.1.

Figure
2.1: CMMI Model Components

The
following sections provide detailed descriptions of the model
components.

Process Areas

A
process area is a cluster of related practices in an area that, when
implemented collectively, satisfy a set of goals considered important
for making improvement in that area.

There
are 22 process areas, presented here in alphabetical order by
acronym:

• 
  Causal
  Analysis and Resolution (CAR)

  
  

• 
  Configuration
  Management (CM)

  
  

• 
  Decision
  Analysis and Resolution (DAR)

  
  

• 
  Integrated
  Project Management +IPPD (IPM+IPPD)⁶

  
  

• 
  Measurement
  and Analysis (MA)

  
  

• 
  Organizational
  Innovation and Deployment (OID)

  
  

• 
  Organizational
  Process Definition +IPPD (OPD+IPPD)⁶

  
  

• 
  Organizational
  Process Focus (OPF)

  
  

• 
  Organizational
  Process Performance (OPP)

  
  

• 
  Organizational
  Training (OT)

  
  

• 
  Product
  Integration (PI)

  
  

• 
  Project
  Monitoring and Control (PMC)

  
  

• 
  Project
  Planning (PP)

  
  

• 
  Process
  and Product Quality Assurance (PPQA)

  
  

• 
  Quantitative
  Project Management (QPM)

  
  

• 
  Requirements
  Development (RD)

  
  

• 
  Requirements
  Management (REQM)

  
  

• 
  Risk
  Management (RSKM)

  
  

• 
  Supplier
  Agreement Management (SAM)

  
  

• 
  Technical
  Solution (TS)

  
  

• 
  Validation
  (VAL)

  
  

• 
  Verification
  (VER)

  
  

Purpose Statements

The
purpose statement describes the purpose of the process area and is an
informative component.

For
example, the purpose statement of the Organizational Process
Definition process area is “The purpose of Organizational Process
Definition (OPD) is to establish and maintain a usable set of
organizational process assets and work environment standards.”

Introductory Notes

The
introductory notes section of the process area describes the major
concepts covered in the process area and is an informative component.

An
example from the introductory notes of the Project Planning process
area is “Planning begins with requirements that define the product
and project.”

Related Process Areas

The
related process areas section lists references to related process
areas and reflects the high-level relationships among the process
areas. The related process area section is an informative component.

An
example of a reference found in the related process areas section of
the Project Planning process area is “Refer to the Risk Management
process area for more information about identifying and managing
risks.”

Specific Goals

A
specific goal describes the unique characteristics that must be
present to satisfy the process area. A specific goal is a required
model component and is used in appraisals to help determine whether a
process area is satisfied.

For
example, a specific goal from the Configuration Management process
area is “Integrity of baselines is established and maintained.”

Only
the statement of the specific goal is a required model component. The
title of a specific goal (preceded by the goal number) and any notes
associated with the goal are considered informative model components.

Generic Goals

Generic
goals are called “generic” because the same goal statement
applies to multiple process areas. A generic goal describes the
characteristics that must be present to institutionalize the
processes that implement a process area. A generic goal is a required
model component and is used in appraisals to determine whether a
process area is satisfied. (See the Generic Goals and Generic
Practices section on page 75 for a more detailed description of
generic goals.)

An
example of a generic goal is “The process is institutionalized as a
defined process.”

Only
the statement of the generic goal is a required model component. The
title of a generic goal (preceded by the goal number) and any notes
associated with the goal are considered informative model components.

Specific Goal and
Practice Summaries

The
specific goal and practice summary provides a high-level summary of
the specific goals, which are required components, and the specific
practices, which are expected components. The specific goal and
practice summary is an informative component.

Specific Practices

A
specific practice is the description of an activity that is
considered important in achieving the associated specific goal. The
specific practices describe the activities that are expected to
result in achievement of the specific goals of a process area. A
specific practice is an expected model component.

For
example, a specific practice from the Project Monitoring and Control
process area is “Monitor commitments against those identified in
the project plan.”

Only
the statement of the specific practice is an expected model
component. The title of a specific practice (preceded by the practice
number) and any notes associated with the specific practice are
considered informative model components.

Typical Work Products

The
typical work products section lists sample output from a specific
practice. These examples are called typical work products because
there are often other work products that are just as effective but
are not listed. A typical work product is an informative model
component.

For
example, a typical work product for the specific practice “Monitor
the actual values of the project planning parameters against the
project” in the Project Monitoring and Control process area is
“Records of significant deviations.”

Subpractices

A
subpractice is a detailed description that provides guidance for
interpreting and implementing a specific or generic practice.
Subpractices may be worded as if prescriptive, but are actually an
informative component meant only to provide ideas that may be useful
for process improvement.

For
example, a subpractice for the specific practice “Take corrective
action on identified issues” in the Project Monitoring and Control
process area is “Determine and document the appropriate actions
needed to address the identified issues.”

Generic Practices

Generic
practices are called “generic” because the same practice applies
to multiple process areas. A generic practice is the description of
an activity that is considered important in achieving the associated
generic goal. A generic practice is an expected model component.

For
example, a generic practice for the generic goal “The process is
institutionalized as a managed process” is “Provide adequate
resources for performing the process, developing the work products,
and providing the services of the process.”

Only
the statement of the generic practice is an expected model component.
The title of a generic practice (preceded by the practice number) and
any notes associated with the practice are considered informative
model components.

To
reduce the repetitiveness of this information and to conserve the
number of pages required to present this information, only the
generic practice title, statement, and elaborations appear in the
process areas. (See the Generic Goals and Generic Practices section
on page 75 for a complete description of the generic practices.)

Generic Practice
Elaborations

A
generic practice elaboration appears after a generic practice in a
process area to provide guidance on how the generic practice should
be applied uniquely to the process area. A generic practice
elaboration is an informative model component.

For
example, a generic practice elaboration after the generic practice
“Establish and maintain an organizational policy for planning and
performing the project planning process” in the Project Planning
process area is “This policy establishes organizational
expectations for estimating the planning parameters, making internal
and external commitments, and developing the plan for managing the
project.”

Supporting
Informative Components

In
many places, further information is needed to describe a concept.
This informative material is provided in the form of the following
components:

• 
  Notes

  
  

• 
  Examples

  
  

• 
  Amplifications

  
  

• 
  References

  
  

Notes

A
note is text that can accompany nearly any other model component. It
may provide detail, background, or rationale. A note is an
informative model component.

For
example, a note that accompanies the specific practice “Implement
the selected action proposals that were developed in causal analysis”
in the Causal Analysis and Resolution process area is “Only changes
that prove to be of value should be considered for broad
implementation.”

Examples

An
example is a component comprising text and often a list of items,
usually in a box, that can accompany nearly any other component and
provides one or more examples to clarify a concept or described
activity. An example is an informative model component.

The
following is an example that accompanies the subpractice “Document
noncompliance issues when they cannot be resolved within the project”
under the specific practice “Communicate quality issues and ensure
resolution of noncompliance issues with the staff and managers” in
the Process and Product Quality Assurance process area.

Examples
of ways to resolve noncompliance within the project include the
following:

• 
  Fixing
  the noncompliance

  
  

• 
  Changing
  the process descriptions, standards, or procedures that were
  violated

  
  

• 
  Obtaining
  a waiver to cover the noncompliance issue

  
  

Amplifications

An
amplification is a note or example that is relevant to a particular
discipline. The disciplines covered in this model are hardware
engineering, systems engineering, and software engineering.

Each
amplification is labeled with a heading that indicates the discipline
to which it applies. For example, an amplification for software
engineering is labeled “For Software Engineering.” An
amplification is an informative model component.

An
example of an amplification is the one that accompanies the specific
practice “Establish and maintain the overall project plan content”
in the Project Planning process area. The amplification states “For
Hardware Engineering: For hardware, the planning document is often
referred to as a hardware development plan. Development activities in
preparation for production may be included in the hardware
development plan or defined in a separate production plan.”

References

A
reference is a pointer to additional or more detailed information in
related process areas and can accompany nearly any other model
component. A reference is an informative model component.

For
example, a reference that accompanies the specific practice “Select
the subprocesses that compose the project’s defined process based on
historical stability and capability data” in the Quantitative
Project Management process area is “Refer to the Organizational
Process Definition process area for more information about the
organization’s process asset library, which might include a process
element of known and needed capability.”

Numbering Scheme

Specific
and generic goals are numbered sequentially. Each specific goal
begins with the prefix SG (e.g., SG 1). Each generic goal begins with
the prefix GG (e.g., GG 2).

Each
specific practice begins with the prefix SP, followed by a number in
the form x.y (e.g., SP 1.1). The x is the same number as the goal to
which the specific practice maps. The y is the sequence number of the
specific practice under the specific goal.

An
example of specific practice numbering is in the Project Planning
process area. The first specific practice is numbered SP 1.1 and the
second is SP 1.2.

Each
generic practice begins with the prefix GP, followed by a number in
the form x.y (e.g., GP 1.1).

The
x corresponds to the number of the generic goal. The y is the
sequence number of the generic practice under the generic goal. For
example, the first generic practice associated with GG 2 is numbered
GP 2.1 and the second is GP 2.2.

Typographical
Conventions

The
typographical conventions used in this model were designed to enable
you to select what you need and use it effectively. We present model
components in formats that allow you to find them quickly on the
page.

Figures
2.2 through 2.4 are sample pages from process areas in Part Two; they
show the different process area components, labeled so that you can
identify them. Notice that components differ typographically so that
you can easily identify each one.

Figure
2.2: Sample Page from CAR

Figure
2.3: Sample Page from VER

Figure
2.4: Sample Page from IPM+IPPD

Representation-Specific
Content

In
Part Two, you will notice that some components in the Generic
Practices by Goal section of each process area are in a box and
labeled “Staged Only,” “Continuous Only,” or
“Continuous/Maturity Levels 3–5.”

Components
that are not marked apply to both representations. Components marked
“Staged Only” apply only if you are using the staged
representation. Components marked “Continuous Only” apply only if
you are using the continuous representation. (See Figure 2.4 for an
example.)

Components
marked “Continuous/Maturity Levels 3–5” apply if you are using
the continuous representation or if you are using the staged
representation and are pursuing maturity level 3, 4, or 5. However,
these components do not apply if you are pursuing a maturity level 2
rating using the staged representation.

Additions

An
addition can be informative material, a specific practice, a specific
goal, or a process area that extends the scope of a model or
emphasizes a particular aspect of its use. In this document, all
additions apply to IPPD.

An
example of an addition is the one from the Organizational Training
process area that appears after specific goal 1, “Establish an
Organizational Training Capability.” The addition states
“Cross-functional training, leadership training, interpersonal
skills training, and training in the skills needed to integrate
appropriate business and technical functions is needed by integrated
team members. The potentially wider range of requirements and
participant backgrounds may require relevant stakeholders who were
not involved in requirements development to take cross training in
the disciplines involved in product design in order to commit to
requirements with a full understanding of the range of requirements
and their interrelationships.”

3Tying It All Together

Now
that you have been introduced to the components of CMMI models, you
need to understand how they all fit together to meet your process
improvement needs [Dymond 2004]. In this chapter, we introduce the
concept of levels and show how the process areas are organized and
used. To do this, we need to revisit the discussion that began in
Chapter 1.

Understanding
Levels

Levels
are used in CMMI to describe an evolutionary path recommended for an
organization that wants to improve the processes it uses to develop
and maintain its products and services. Levels can also be the
outcome of the rating activity of appraisals.⁷
Appraisals can be performed for organizations that comprise entire
(usually small) companies, or for smaller groups such as a group of
projects or a division within a company.

CMMI
supports two improvement paths. One path enables organizations to
incrementally improve processes corresponding to an individual
process area (or process areas) selected by the organization. The
other path enables organizations to improve a set of related
processes by incrementally addressing successive sets of process
areas.

These
two improvement paths are associated with the two types of levels
that correspond to the two representations discussed in Chapter 1.
For the continuous representation, we use the term “capability
level.” For the staged representation, we use the term “maturity
level.”

Regardless
of which representation you select, the concept of levels is the
same. Levels characterize improvement from an ill-defined state to a
state that uses quantitative information to determine and manage
improvements that are needed to meet an organization’s business
objectives.

To
reach a particular level, an organization must satisfy all of the
appropriate goals of the process area or set of process areas that
are targeted for improvement, regardless of whether it is a
capability or a maturity level.

Both
representations also provide ways to implement process improvement to
achieve business objectives. Both representations provide the same
essential content and use the same model components.

Structures of the
Continuous and Staged Representations

Figure
3.1 illustrates the structures of the continuous and staged
representations. The differences jump out at you immediately when you
look at the structure of both representations. The staged
representation utilizes maturity levels, whereas the continuous
representation utilizes capability levels.

Figure
3.1: Structure of the Continuous and Staged Representations

What
may strike you as you compare these two representations is their
similarity. Both have many of the same components (e.g., process
areas, specific goals, and specific practices), and these components
have the same hierarchy and configuration.

What
is not readily apparent from the high-level view in Figure 3.1 is
that the continuous representation focuses on process area capability
as measured by capability levels and the staged representation
focuses on organizational maturity as measured by maturity levels.
These dimensions (the capability/maturity dimensions) of CMMI are
used for benchmarking and appraisal activities, as well as guiding an
organization’s improvement efforts.

• 
  Capability
  levels, which belong to a continuous representation, apply to an
  organization’s process improvement achievement in individual
  process areas. These levels are a means for incrementally improving
  the processes corresponding to a given process area. There are six
  capability levels, numbered 0 through 5.

  
  

• 
  Maturity
  levels, which belong to a staged representation, apply to an
  organization’s process improvement achievement across multiple
  process areas. These levels are a means of predicting the general
  outcomes of the next project undertaken. There are five maturity
  levels, numbered 1 through 5.

  
  

Table
3.1 compares the six capability levels to the five maturity levels.
Notice that the names of four of the levels are the same in both
representations. The differences are that there is no maturity level
0 for the staged representation, and at level 1, the capability level
is Performed, whereas the maturity level is Initial. Therefore, the
starting point is different for the two representations.

Table
3.1 Comparison of Capability and Maturity Levels

Level	Continuous Representation Capability Levels	Staged Representation Maturity Levels
Level 0	Incomplete	N/A
Level 1	Performed	Initial
Level 2	Managed	Managed
Level 3	Defined	Defined
Level 4	Quantitatively Managed	Quantitatively Managed
Level 5	Optimizing	Optimizing

The
continuous representation is concerned with selecting both a
particular process area to improve and the desired capability level
for that process area. In this context, whether a process is
performed or incomplete is important. Therefore, the name
“incomplete” is given to the continuous representation starting
point.

Because
the staged representation is concerned with the overall maturity of
the organization, whether individual processes are performed or
incomplete is not the primary focus. Therefore, the name “initial”
is given to the staged representation starting point.

Both
capability levels and maturity levels provide a way to measure how
well organizations can and do improve their processes. However, the
associated approach to process improvement is different.

Understanding
Capability Levels

To
support those using the continuous representation, all CMMI models
reflect capability levels in their design and content. A capability
level consists of a generic goal and its related generic practices as
they relate to a process area, which can improve the organization’s
processes associated with that process area. As you satisfy the
generic goal and its generic practices at each capability level, you
reap the benefits of process improvement for that process area.

The
six capability levels, designated by the numbers 0 through 5, are as
follows:

0. 
   Incomplete

   
   

1. 
   Performed

   
   

2. 
   Managed

   
   

3. 
   Defined

   
   

4. 
   Quantitatively
   Managed

   
   

5. 
   Optimizing

   
   

The
fact that capability levels 2 through 5 use the same terms as generic
goals 2 through 5 is intentional because each of these generic goals
and practices reflects the meaning of the capability levels in terms
of goals and practices you can implement. (See the Generic Goals and
Generic Practices section on page 75 for more information about
generic goals and practices.) A short description of each capability
level follows.

Capability Level 0:
Incomplete

An
“incomplete process” is a process that either is not performed or
partially performed. One or more of the specific goals of the process
area are not satisfied, and no generic goals exist for this level
since there is no reason to institutionalize a partially performed
process.

Capability Level 1:
Performed

A
capability level 1 process is characterized as a “performed
process.” A performed process is a process that satisfies the
specific goals of the process area. It supports and enables the work
needed to produce work products.

Although
capability level 1 results in important improvements, those
improvements can be lost over time if they are not institutionalized.
The application of institutionalization (the CMMI generic practices
at capability levels 2 through 5) helps to ensure that improvements
are maintained.

Capability Level 2:
Managed

A
capability level 2 process is characterized as a “managed process.”
A managed process is a performed (capability level 1) process that
has the basic infrastructure in place to support the process. It is
planned and executed in accordance with policy; employs skilled
people who have adequate resources to produce controlled outputs;
involves relevant stakeholders; is monitored, controlled, and
reviewed; and is evaluated for adherence to its process description.
The process discipline reflected by capability level 2 helps to
ensure that existing practices are retained during times of stress.

Capability Level 3:
Defined

A
capability level 3 process is characterized as a “defined process.”
A defined process is a managed (capability level 2) process that is
tailored from the organization’s set of standard processes
according to the organization’s tailoring guidelines, and
contributes work products, measures, and other process improvement
information to the organizational process assets.

A
critical distinction between capability levels 2 and 3 is the scope
of standards, process descriptions, and procedures. At capability
level 2, the standards, process descriptions, and procedures may be
quite different in each specific instance of the process (e.g., on a
particular project). At capability level 3, the standards, process
descriptions, and procedures for a project are tailored from the
organization’s set of standard processes to suit a particular
project or organizational unit and therefore are more consistent,
except for the differences allowed by the tailoring guidelines.

Another
critical distinction is that at capability level 3, processes are
typically described more rigorously than at capability level 2. A
defined process clearly states the purpose, inputs, entry criteria,
activities, roles, measures, verification steps, outputs, and exit
criteria. At capability level 3, processes are managed more
proactively using an understanding of the interrelationships of the
process activities and detailed measures of the process, its work
products, and its services.

Capability Level 4:
Quantitatively Managed

A
capability level 4 process is characterized as a “quantitatively
managed process.” A quantitatively managed process is a defined
(capability level 3) process that is controlled using statistical and
other quantitative techniques. Quantitative objectives for quality
and process performance are established and used as criteria in
managing the process. Quality and process performance is understood
in statistical terms and is managed throughout the life of the
process.

Capability Level 5:
Optimizing

A
capability level 5 process is characterized as an “optimizing
process.” An optimizing process is a quantitatively managed
(capability level 4) process that is improved based on an
understanding of the common causes of variation inherent in the
process. The focus of an optimizing process is on continually
improving the range of process performance through both incremental
and innovative improvements.

Remember
that capability levels 2 through 5 use the same terms as generic
goals 2 through 5, and a detailed description of these terms appears
in the Generic Goals and Generic Practices section on page 75.

Advancing through
Capability Levels

The
capability levels of a process area are achieved through the
application of generic practices or suitable alternatives to the
processes associated with that process area.

Reaching
capability level 1 for a process area is equivalent to saying that
the processes associated with that process area are “performed
processes.”

Reaching
capability level 2 for a process area is equivalent to saying that
there is a policy that indicates you will perform the process. There
is a plan for performing it, resources are provided, responsibilities
are assigned, training to perform it is provided, selected work
products related to performing the process are controlled, and so on.
In other words, a capability level 2 process can be planned and
monitored just like any project or support activity.

Reaching
capability level 3 for a process area assumes that an organizational
standard process exists associated with that process area, which can
be tailored to the needs of the project. The processes in the
organization are now more consistently defined and applied because
they are based on organizational standard processes.

Reaching
capability level 4 for a process area assumes that this process area
is a key business driver that the organization wants to manage using
quantitative and statistical techniques. This analysis gives the
organization more visibility into the performance of selected
subprocesses that will make it more competitive in the marketplace.

Reaching
capability level 5 for a process area assumes that you have
stabilized the selected subprocesses and that you want to reduce the
common causes of variation within that process. Remember that
variation is a natural occurrence in any process, so although it is
conceptually feasible to improve all processes, it would not be
economical to improve all processes to level 5. Again, you would
concentrate on those processes that would help you to meet your
business objectives.

Understanding
Maturity Levels

To
support those using the staged representation, all CMMI models
reflect maturity levels in their design and content. A maturity level
consists of related specific and generic practices for a predefined
set of process areas that improve the organization’s overall
performance. The maturity level of an organization provides a way to
predict an organization’s performance in a given discipline or set
of disciplines. Experience has shown that organizations do their best
when they focus their process improvement efforts on a manageable
number of process areas at a time and that those areas require
increasing sophistication as the organization improves.

A
maturity level is a defined evolutionary plateau for organizational
process improvement. Each maturity level matures an important subset
of the organization’s processes, preparing it to move to the next
maturity level. The maturity levels are measured by the achievement
of the specific and generic goals associated with each predefined set
of process areas.

There
are five maturity levels, each a layer in the foundation for ongoing
process improvement, designated by the numbers 1 through 5:

1. 
   Initial

   
   

2. 
   Managed

   
   

3. 
   Defined

   
   

4. 
   Quantitatively
   Managed

   
   

5. 
   Optimizing

   
   

Remember
that maturity levels 2 through 5 use the same terms as capability
levels 2 through 5. This was intentional because the concepts of
maturity levels and capability levels are complementary. Maturity
levels are used to characterize organizational improvement relative
to a set of process areas, and capability levels characterize
organizational improvement relative to an individual process area.

Maturity Level 1:
Initial

At
maturity level 1, processes are usually ad hoc and chaotic. The
organization usually does not provide a stable environment to support
the processes. Success in these organizations depends on the
competence and heroics of the people in the organization and not on
the use of proven processes. In spite of this chaos, maturity level 1
organizations often produce products and services that work; however,
they frequently exceed their budgets and do not meet their schedules.

Maturity
level 1 organizations are characterized by a tendency to over commit,
abandonment of processes in a time of crisis, and an inability to
repeat their successes.

Maturity Level 2:
Managed

At
maturity level 2, the projects of the organization have ensured that
processes are planned and executed in accordance with policy; the
projects employ skilled people who have adequate resources to produce
controlled outputs; involve relevant stakeholders; are monitored,
controlled, and reviewed; and are evaluated for adherence to their
process descriptions. The process discipline reflected by maturity
level 2 helps to ensure that existing practices are retained during
times of stress. When these practices are in place, projects are
performed and managed according to their documented plans.

At
maturity level 2, the status of the work products and the delivery of
services are visible to management at defined points (e.g., at major
milestones and at the completion of major tasks). Commitments are
established among relevant stakeholders and are revised as needed.
Work products are appropriately controlled. The work products and
services satisfy their specified process descriptions, standards, and
procedures.

Maturity Level 3:
Defined

At
maturity level 3, processes are well characterized and understood,
and are described in standards, procedures, tools, and methods. The
organization’s set of standard processes, which is the basis for
maturity level 3, is established and improved over time. These
standard processes are used to establish consistency across the
organization. Projects establish their defined processes by tailoring
the organization’s set of standard processes according to tailoring
guidelines. (See the glossary for a definition of “organization’s
set of standard processes.”)

A
critical distinction between maturity levels 2 and 3 is the scope of
standards, process descriptions, and procedures. At maturity level 2,
the standards, process descriptions, and procedures may be quite
different in each specific instance of the process (e.g., on a
particular project). At maturity level 3, the standards, process
descriptions, and procedures for a project are tailored from the
organization’s set of standard processes to suit a particular
project or organizational unit and therefore are more consistent,
except for the differences allowed by the tailoring guidelines.

Another
critical distinction is that at maturity level 3, processes are
typically described more rigorously than at maturity level 2. A
defined process clearly states the purpose, inputs, entry criteria,
activities, roles, measures, verification steps, outputs, and exit
criteria. At maturity level 3, processes are managed more proactively
using an understanding of the interrelationships of the process
activities and detailed measures of the process, its work products,
and its services.

At
maturity level 3, the organization must further mature the maturity
level 2 process areas. The generic practices associated with generic
goal 3 that were not addressed at maturity level 2 are applied to
achieve maturity level 3.

Maturity Level 4:
Quantitatively Managed

At
maturity level 4, the organization and projects establish
quantitative objectives for quality and process performance and use
them as criteria in managing processes. Quantitative objectives are
based on the needs of the customer, end users, organization, and
process implementers. Quality and process performance is understood
in statistical terms and is managed throughout the life of the
processes [SEI 2001].

For
selected subprocesses, detailed measures of process performance are
collected and statistically analyzed. Quality and process-performance
measures are incorporated into the organization’s measurement
repository to support fact-based decision making [McGarry 2000].
Special causes of process variation are identified and, where
appropriate, the sources of special causes are corrected to prevent
future occurrences. (See the definition of “special cause of
process variation” in the glossary.)

A
critical distinction between maturity levels 3 and 4 is the
predictability of process performance. At maturity level 4, the
performance of processes is controlled using statistical and other
quantitative techniques, and is quantitatively predictable. At
maturity level 3, processes are typically only qualitatively
predictable.

Maturity Level 5:
Optimizing

At
maturity level 5, an organization continually improves its processes
based on a quantitative understanding of the common causes of
variation inherent in processes. (See the definition of “common
cause of process variation” in the glossary.)

Maturity
level 5 focuses on continually improving process performance through
incremental and innovative process and technological improvements.
Quantitative process improvement objectives for the organization are
established, continually revised to reflect changing business
objectives, and used as criteria in managing process improvement. The
effects of deployed process improvements are measured and evaluated
against the quantitative process improvement objectives. Both the
defined processes and the organization’s set of standard processes
are targets of measurable improvement activities.

A
critical distinction between maturity levels 4 and 5 is the type of
process variation addressed. At maturity level 4, the organization is
concerned with addressing special causes of process variation and
providing statistical predictability of the results. Although
processes may produce predictable results, the results may be
insufficient to achieve the established objectives. At maturity level
5, the organization is concerned with addressing common causes of
process variation and changing the process (to shift the mean of the
process performance or reduce the inherent process variation
experienced) to improve process performance and to achieve the
established quantitative process improvement objectives.

Advancing through
Maturity Levels

Organizations
can achieve progressive improvements in their organizational maturity
by achieving control first at the project level and continuing to the
most advanced level—organization-wide continuous process
improvement—using both quantitative and qualitative data to make
decisions.

Since
improved organizational maturity is associated with improvement in
the range of expected results that can be achieved by an
organization, it is one way of predicting the general outcomes of the
organization’s next project. For instance, at maturity level 2, the
organization has been elevated from ad hoc to disciplined by
establishing sound project management. As your organization achieves
the generic and specific goals for the set of process areas in a
maturity level, you are increasing your organizational maturity and
reaping the benefits of process improvement. Because each maturity
level forms a necessary foundation for the next level, trying to skip
maturity levels is usually counterproductive.

At
the same time, you must recognize that process improvement efforts
should focus on the needs of the organization in the context of its
business environment and that process areas at higher maturity levels
may address the current needs of an organization or project. For
example, organizations seeking to move from maturity level 1 to
maturity level 2 are frequently encouraged to establish a process
group, which is addressed by the Organizational Process Focus process
area that resides at maturity level 3. Although a process group is
not a necessary characteristic of a maturity level 2 organization, it
can be a useful part of the organization’s approach to achieving
maturity level 2.

This
situation is sometimes characterized as establishing a maturity level
1 process group to bootstrap the maturity level 1 organization to
maturity level 2. Maturity level 1 process improvement activities may
depend primarily on the insight and competence of the process group
staff until an infrastructure to support more disciplined and
widespread improvement is in place.

Organizations
can institute specific process improvements at any time they choose,
even before they are prepared to advance to the maturity level at
which the specific practice is recommended. In such situations,
however, organizations should understand that the success of these
improvements is at risk because the foundation for their successful
institutionalization has not been completed. Processes without the
proper foundation may fail at the very point they are needed
most—under stress.

A
defined process that is characteristic of a maturity level 3
organization can be placed at great risk if maturity level 2
management practices are deficient. For example, management may
commit to a poorly planned schedule or fail to control changes to
baselined requirements. Similarly, many organizations prematurely
collect the detailed data characteristic of maturity level 4, only to
find the data uninterpretable because of inconsistencies in processes
and measurement definitions.

Another
example of using processes associated with higher maturity-level
process areas is in the building of products. Certainly, we would
expect maturity level 1 organizations to perform requirements
analysis, design, integration, and verification. These activities are
not described until maturity level 3, however, where they are
described as the coherent, well-integrated engineering processes that
complement a maturing project management capability, put in place so
that the engineering improvements are not lost by an ad hoc
management process.

Process Areas

Process
areas are viewed differently in the two representations. Figure 3.2
compares views of how process areas are used in the continuous
representation and the staged representation.

Figure
3.2: Process Areas in Continuous and Staged Representations

The
continuous representation enables the organization to choose the
focus of its process improvement efforts by choosing those process
areas, or sets of interrelated process areas, that best benefit the
organization and its business objectives. Although there are some
limits on what an organization can choose because of the dependencies
among process areas, the organization has considerable freedom in its
selection.

To
support those using the continuous representation, process areas are
organized into four categories: Process Management, Project
Management, Engineering, and Support. These categories emphasize the
relationships that exist among the process areas and are discussed in
Chapter 4.

Once
you select the process areas, you must also select how much you would
like to mature the processes associated with those process areas
(i.e., select the appropriate capability level). Capability levels
and generic goals and practices support the improvement of processes
associated with individual process areas. For example, an
organization may wish to strive to reach capability level 2 in one
process area and capability level 4 in another. As the organization
reaches a capability level, it sets its sights on the next capability
level for one of these same process areas or decides to widen its
view and address a larger number of process areas.

This
selection is typically described through a target profile. A target
profile defines all of the process areas to be addressed and the
targeted capability level for each. This profile then governs which
goals and practices the organization will address in its process
improvement efforts.

Most
organizations will, at minimum, target capability level 1, which
requires that all specific goals of the process area be achieved.
However, organizations that target capability levels higher than 1
will concentrate on the institutionalization of the selected
processes in the organization by implementing the associated generic
goals and practices.

Conversely,
you will see that the staged representation encourages you to always
look at process areas in the context of the maturity level to which
they belong. The process areas are organized by maturity levels to
reinforce this concept.

The
staged representation provides a predetermined path of improvement
from maturity level 1 to maturity level 5 that involves achieving the
goals of the process areas at each maturity level. To support those
using the staged representation, process areas are grouped by
maturity level, indicating which process areas to implement to
achieve each maturity level. For example, at maturity level 2, there
is a set of process areas that an organization would use to guide its
process improvement until it could achieve all the goals of all these
process areas. Once maturity level 2 is achieved this way, the
organization focuses its efforts on maturity level 3 process areas,
and so on. The generic goals that apply to each process area are also
predetermined. Generic goal 2 applies to maturity level 2 and generic
goal 3 applies to maturity levels 3 through 5.

Table
3.2 provides a list of all process areas and their associated
categories and maturity levels. To explain how the components of the
process areas are viewed in each representation, we must discuss how
the representations address specific practices.

Table
3.2 Process Areas and Their Associated Categories and Maturity Levels

Process Area	Category	Maturity Level
Causal Analysis and Resolution	Support	5
Configuration Management	Support	2
Decision Analysis and Resolution	Support	3
Integrated Project Management +IPPD	Project Management	3
Measurement and Analysis	Support	2
Organizational Innovation and Deployment	Process Management	5
Organizational Process Definition +IPPD	Process Management	3
Organizational Process Focus	Process Management	3
Organizational Process Performance	Process Management	4
Organizational Training	Process Management	3
Product Integration	Engineering	3
Project Monitoring and Control	Project Management	2
Project Planning	Project Management	2
Process and Product Quality Assurance	Support	2
Quantitative Project Management	Project Management	4
Requirements Development	Engineering	3
Requirements Management	Engineering	2
Risk Management	Project Management	3
Supplier Agreement Management	Project Management	2
Technical Solution	Engineering	3
Validation	Engineering	3
Verification	Engineering	3

Generic Goals and
Practices

Generic
goals are required model components that apply to all process areas.
Figure 3.3 illustrates the generic goals and practices. All of the
generic goals and practices are used in the continuous
representation. (See the Generic Goals and Generic Practices section
on page 75 for a more detailed description of generic goals and
practices.) The capability level you are targeting for your
improvement effort will determine which generic goals and practices
you will apply to the process area you have selected.

Figure
3.3: Generic Goals and Generic Practices

In
the staged representation, only generic goals 2 and 3 are used, as
illustrated by the generic practices highlighted in gray in Figure
3.3. When you try to reach maturity level 2, you use the process
areas at maturity level 2 as well as generic goal 2 and its generic
practices.

Notice
that generic goals 4 and 5 and their associated generic practices are
not used. This is because not all processes will be “raised”
above (i.e., matured beyond) a defined process. Only select processes
and subprocesses will be quantitatively managed and optimized, and
which processes and subprocesses are selected is addressed by the
process areas at maturity levels 4 and 5.

When
you reach maturity levels 3, 4, and 5, you use the process areas at
the appropriate maturity levels as well as all of those at the lower
maturity levels. In addition, generic goal 3 and its associated
generic practices (which include the generic practices associated
with generic goal 2) are applied to all of these process areas. This
means that even though you have already achieved a maturity level 2
rating, to achieve a maturity level 3 rating you must return to the
maturity level 2 process areas and apply generic goal 3 and its
generic practices as well.

Representation
Comparison

Table
3.3 summarizes the differences between the two representations.

Table
3.3 Comparing Continuous and Staged Representations

Continuous Representation	Staged Representation
The organization selects process areas and capability levels based on its process improvement objectives.	The organization selects process areas based on the maturity levels.
Improvement is measured using capability levels. Capability levels Measure maturity of a particular process across an organization. Range from 0 through 5.	Improvement is measured using maturity levels. Maturity levels Measure maturity of a set of processes across an organization. Range from 1 through 5.
Capability level profiles are used to target and track process improvement performance.	Maturity levels are used to target and track process improvement performance.
Equivalent staging allows an organization using the continuous approach to process improvement to derive a maturity level as part of an appraisal.	There is no need for an equivalence mechanism back to the continuous approach.

Equivalent Staging

Equivalent
staging is a way to compare results from using the continuous
representation to those of the staged representation. In essence, if
you measured improvement relative to selected process areas using
capability levels in the continuous representation, how would you
compare that to maturity levels? Is this possible?

Up
to this point, we have not discussed process appraisals in much
detail. The SCAMPI^SM method⁸
is used for appraising organizations using CMMI, and one result of an
appraisal is a rating [Ahern 2005]. If the continuous representation
is used for an appraisal, the rating is a capability level profile.
If the staged representation is used for an appraisal, the rating is
a maturity level (e.g., maturity level 3) rating.

A
capability level profile is a list of process areas and the
corresponding capability level achieved for each. This profile
enables an organization to track its capability level by process
area. The profile is an achievement profile when it represents the
organization’s actual progress for each process area.
Alternatively, the profile is a target profile when it represents the
organization’s planned process improvement objectives. Figure 3.4
illustrates both a target profile and an achievement profile. The
gray portion of each bar represents what has been achieved. The
unshaded portion represents what remains to be accomplished to meet
the target profile.

Figure
3.4: An Example of an Achievement Profile and a Target Profile

An
achievement profile, when compared with a target profile, enables an
organization to plan and track its progress for each selected process
area. Maintaining capability level profiles is advisable when using
the continuous representation.

Target
staging is a sequence of target profiles that describes the path of
process improvement to be followed by the organization. When building
target profiles, the organization should pay attention to the
dependencies between generic practices and process areas. If a
generic practice depends on a certain process area, either to carry
out the generic practice or to provide a prerequisite product, the
generic practice may be much less effective when the process area is
not implemented.⁹

Although
there are many reasons to use the continuous representation, the
ratings provided by capability level profiles are limited in their
ability to provide organizations with a way to generally compare
themselves with other organizations. Capability level profiles could
be used if each organization selected the same process areas;
however, maturity levels have been used to compare organizations for
years and already provide predefined sets of process areas.

Because
of this situation, equivalent staging was created. Equivalent staging
enables an organization using the continuous representation for an
appraisal to convert a capability level profile to the associated
maturity level rating.

The
most effective way to depict equivalent staging is to provide a
sequence of target profiles, each of which is equivalent to a
maturity level rating of the staged representation. The result is a
target staging that is equivalent to the maturity levels of the
staged representation.

Figure
3.5 shows a summary of the target profiles that must be achieved when
using the continuous representation to be equivalent to maturity
levels 2 through 5. Each shaded area in the capability level columns
represents a target profile that is equivalent to a maturity level.

Name	Abbr	ML	CL1	CL2	CL3	CL4	CL5
Requirements Management	REQM	2	Target Profile 2
Project Planning	PP	2
Project Monitoring and Control	PMC	2
Supplier Agreement Management	SAM	2
Measurement and Analysis	MA	2
Process and Product Quality Assurance	PPQA	2
Configuration Management	CM	2
Requirements Development	RD	3
Technical Solution	TS	3
Product Integration	PI	3
Verification	VER	3
Validation	VAL	3	Target Profile 3
Organizational Process Focus	OPF	3
Organizational Process Definition +IPPD	OPD +IPPD	3
Organizational Training	OT	3
Integrated Project Management +IPPD	IPM +IPPD	3
Risk Management	RSKM	3
Decision Analysis and Resolution	DAR	3
Organizational Process Performance	OPP	4	Target Profile 4
Quantitative Project Management	QPM	4
Organizational Innovation and Deployment	OID	5	Target Profile 5
Causal Analysis and Resolution	CAR	5

Figure
3.5: Target Profiles and Equivalent Staging

The
following rules summarize equivalent staging:

• 
  To
  achieve maturity level 2, all process areas assigned to maturity
  level 2 must achieve capability level 2 or higher.

  
  

• 
  To
  achieve maturity level 3, all process areas assigned to maturity
  levels 2 and 3 must achieve capability level 3 or higher.

  
  

• 
  To
  achieve maturity level 4, all process areas assigned to maturity
  levels 2, 3, and 4 must achieve capability level 3 or higher.

  
  

• 
  To
  achieve maturity level 5, all process areas must achieve capability
  level 3 or higher.

  
  

These
rules and the table for equivalent staging are complete; however, you
may ask why target profiles 4 and 5 do not extend into the CL4 and
CL5 columns. The reason is that the maturity level 4 process areas
describe a selection of the subprocesses to be stabilized based, in
part, on the quality and process-performance objectives of the
organization and projects. Not every process area will be addressed
in the selection and CMMI does not presume in advance which process
areas might be addressed in the selection.

So,
the achievement of capability level 4 for process areas cannot be
predetermined because the choices depend on the selections made by
the organization in its implementation of the maturity level 4
process areas. Thus, Figure 3.5 does not show target profile 4
extending into the CL4 column, although some process areas will have
achieved capability level 4. The situation for maturity level 5 and
target profile 5 is similar.

The
existence of equivalent staging should not discourage users of the
continuous representation from establishing target profiles that
extend above capability level 3. Such a target profile would be
determined in part by the selections made by the organization to meet
its business objectives.

4Relationships Among Process Areas

In
this chapter, we describe interactions among process areas to help
you see the organization’s view of process improvement and which
process areas build on the implementation of other process areas.
Relationships among process areas are presented in two dimensions.

The
first dimension comprises the interactions of individual process
areas that show how information and artifacts flow from one process
area to another. Shown by the multiple figures and descriptions in
this chapter, these interactions help you see a larger view of
process improvement.

The
second dimension comprises the interactions of groups of process
areas. Shown by the classification of some process areas as Basic and
others as Advanced, these classifications illustrate that the Basic
process areas should be implemented before the Advanced process areas
to ensure that the prerequisites are met to successfully implement
the Advanced process areas.

Successful
process improvement initiatives must be driven by the business
objectives of the organization. For example, a common business
objective is to reduce the time it takes to get a product to market.
The process improvement objective derived from that might be to
improve the project management processes to ensure on-time delivery;
those improvements rely on best practices in the Project Planning and
Project Monitoring and Control process areas.

Four Categories of
CMMI Process Areas

Process
areas can be grouped into four categories:

• 
  Process
  Management
  

  
  

• 
  Project
  Management
  

  
  

• 
  Engineering

  
  

• 
  Support

  
  

Although
we are grouping process areas this way to discuss their interactions,
process areas often interact and have an effect on one another
regardless of their defined group. For example, the Decision Analysis
and Resolution process area provides specific practices to address
the formal evaluation that is used in the Technical Solution process
area for selecting a technical solution from alternative solutions.
Technical Solution is an Engineering process area and Decision
Analysis and Resolution is a Support process area.

Being
aware of the interactions that exist among CMMI process areas and
which process areas are Basic and Advanced will help you apply CMMI
in a useful and productive way. The following sections describe the
interactions of process areas within the categories and only briefly
describe the interactions among process areas in other categories.
Interactions among process areas that belong to different categories
are described in references within the Related Process Areas section
of the process areas in Part Two. Refer to Chapter 2 for more
information about references.

Process Management

Process
Management process areas contain the cross-project activities related
to defining, planning, deploying, implementing, monitoring,
controlling, appraising, measuring, and improving processes.

The
Process Management process areas of CMMI are as follows:

• 
  Organizational
  Process Focus

  
  

• 
  Organizational
  Process Definition +IPPD¹⁰

  
  

• 
  Organizational
  Training

  
  

• 
  Organizational
  Process Performance

  
  

• 
  Organizational
  Innovation and Deployment

  
  

Basic Process
Management Process Areas

The
Basic Process Management process areas provide the organization with
a capability to document and share best practices, organizational
process assets, and learning across the organization.

Figure
4.1 provides a bird’s-eye view of the interactions among the Basic
Process Management process areas and with other process area
categories. As illustrated in Figure 4.1, the Organizational Process
Focus process area helps the organization to plan, implement, and
deploy organizational process improvements based on an understanding
of the current strengths and weaknesses of the organization’s
processes and process assets.

Figure
4.1: Basic Process Management Process Areas

Candidate
improvements to the organization’s processes are obtained through
various means. These include process improvement proposals,
measurement of the processes, lessons learned in implementing the
processes, and results of process appraisal and product evaluation
activities.

The
Organizational Process Definition process area establishes and
maintains the organization’s set of standard processes, work
environment standards, and other assets based on the process needs
and objectives of the organization. These other assets include
descriptions of lifecycle models, process tailoring guidelines, and
process-related documentation and data. Projects tailor the
organization’s set of standard processes to create their defined
processes. The other assets support tailoring as well as
implementation of the defined processes. Experiences and work
products from performing these defined processes, including
measurement data, process descriptions, process artifacts, and
lessons learned, are incorporated as appropriate into the
organization’s set of standard processes and other assets. With the
+IPPD addition, Organizational Process Definition +IPPD provides IPPD
rules and guidelines to the projects.

The
Organizational Training process area identifies the strategic
training needs of the organization as well as the tactical training
needs that are common across projects and support groups. In
particular, training is developed or obtained to develop the skills
required to perform the organization’s set of standard processes.
The main components of training include a managed training
development program, documented plans, personnel with appropriate
knowledge, and mechanisms for measuring the effectiveness of the
training program.

Advanced Process
Management Process Areas

The
Advanced Process Management process areas provide the organization
with an improved capability to achieve its quantitative objectives
for quality and process performance.

Figure
4.2 provides a bird’s-eye view of the interactions among the
Advanced Process Management process areas and with other process area
categories. Each of the Advanced Process Management process areas
depends on the ability to develop and deploy processes and supporting
assets. The Basic Process Management process areas provide this
ability.

Figure
4.2: Advanced Process Management Process Areas

As
illustrated in Figure 4.2, the Organizational Process Performance
process area derives quantitative objectives for quality and process
performance from the organization’s business objectives. The
organization provides projects and support groups with common
measures, process-performance baselines, and process-performance
models. These additional organizational assets support quantitative
project management and statistical management of critical
subprocesses for both projects and support groups. The organization
analyzes the process-performance data collected from these defined
processes to develop a quantitative understanding of product quality,
service quality, and process performance of the organization’s set
of standard processes.

The
Organizational Innovation and Deployment process area selects and
deploys proposed incremental and innovative improvements that improve
the organization’s ability to meet its quality and
process-performance objectives. The identification of promising
incremental and innovative improvements should involve the
participation of an empowered workforce aligned with the business
values and objectives of the organization. The selection of
improvements to deploy is based on a quantitative understanding of
the likely benefits and predictable costs of deploying candidate
improvements, and the funding available for such deployment.

Project Management

Project
Management process areas cover the project management activities
related to planning, monitoring, and controlling the project.

The
Project Management process areas of CMMI are as follows:

• 
  Project
  Planning

  
  

• 
  Project
  Monitoring and Control

  
  

• 
  Supplier
  Agreement Management

  
  

• 
  Integrated
  Project Management +IPPD¹¹

  
  

• 
  Risk
  Management

  
  

• 
  Quantitative
  Project Management

  
  

Basic Project
Management Process Areas

The
Basic Project Management process areas address the activities related
to establishing and maintaining the project plan, establishing and
maintaining commitments, monitoring progress against the plan, taking
corrective action, and managing supplier agreements.

Figure
4.3 provides a bird’s-eye view of the interactions among the Basic
Project Management process areas and with other process area
categories. As illustrated in Figure 4.3, the Project Planning
process area includes developing the project plan, involving
stakeholders appropriately, obtaining commitment to the plan, and
maintaining the plan. When using IPPD, stakeholders represent not
just the technical expertise for product and process development, but
also the business implications of product and process development.

Figure
4.3: Basic Project Management Process Areas

Planning
begins with requirements that define the product and project (“What
to Build” in Figure 4.3). The project plan covers the various
project management and development activities performed by the
project. The project reviews other plans that affect the project from
various relevant stakeholders and establish commitments with those
stakeholders for their contributions to the project. For example,
these plans cover configuration management, verification, and
measurement and analysis.

The
Project Monitoring and Control process area includes monitoring
activities and taking corrective action. The project plan specifies
the appropriate level of project monitoring, the frequency of
progress reviews, and the measures used to monitor progress. Progress
is determined primarily by comparing project status to the plan. When
the actual status deviates significantly from the expected values,
corrective actions are taken as appropriate. These actions may
include replanning.

The
Supplier Agreement Management process area addresses the need of the
project to acquire those portions of work that are produced by
suppliers. Sources of products that may be used to satisfy project
requirements are proactively identified. The supplier is selected,
and a supplier agreement is established to manage the supplier. The
supplier’s progress and performance are tracked by monitoring
selected work products and processes, and the supplier agreement is
revised as appropriate. Acceptance reviews and tests are conducted on
the supplier-produced product component.

Advanced Project
Management Process Areas

The
Advanced Project Management process areas address activities such as
establishing a defined process that is tailored from the
organization’s set of standard processes, establishing the project
work environment from the organization’s work environment
standards, coordinating and collaborating with relevant stakeholders,
managing risk, forming and sustaining integrated teams for the
conduct of projects, and quantitatively managing the project’s
defined process.

Figure
4.4 provides a bird’s-eye view of the interactions among the
Advanced Project Management process areas and with other process area
categories. Each Advanced Project Management process area depends on
the ability to plan, monitor, and control the project. The Basic
Project Management process areas provide this ability.

Figure
4.4: Advanced Project Management Process Areas

The
Integrated Project Management process area establishes and maintains
the project’s defined process that is tailored from the
organization’s set of standard processes. The project is managed
using the project’s defined process. The project uses and
contributes to the organization’s process assets. The project’s
work environment is established and maintained from the
organization’s work environment standards.

The
management of the project ensures that the relevant stakeholders
associated with the project coordinate their efforts in a timely
manner. It does this by providing for the management of stakeholder
involvement; the identification, negotiation, and tracking of
critical dependencies; and the resolution of coordination issues
within the project and with relevant stakeholders.

With
the +IPPD addition, Integrated Project Management +IPPD establishes
and maintains the shared vision of the project and an integrated team
structure for the project and then establishes integrated teams to
perform the work of the project, ensuring the appropriate
collaboration across teams.

Although
risk identification and monitoring are covered in the Project
Planning and Project Monitoring and Control process areas, the Risk
Management process area takes a continuing, forward-looking approach
to managing risks with activities that include identification of risk
parameters, risk assessments, and risk mitigation.

The
Quantitative Project Management process area applies quantitative and
statistical techniques to manage process performance and product
quality. Quality and process-performance objectives for the project
are based on the objectives established by the organization. The
project’s defined process comprises, in part, process elements and
subprocesses whose process performance can be predicted. At a
minimum, the process variation experienced by subprocesses critical
to achieving the project’s quality and process-performance
objectives is understood. Corrective action is taken when special
causes of process variation are identified. (See the definition of
“special cause of process variation” in the glossary.)

Engineering

Engineering
process areas cover the development and maintenance activities that
are shared across engineering disciplines. The Engineering process
areas were written using general engineering terminology so that any
technical discipline involved in the product development process
(e.g., software engineering or mechanical engineering) can use them
for process improvement.

The
Engineering process areas also integrate the processes associated
with different engineering disciplines into a single product
development process, supporting a product-oriented process
improvement strategy. Such a strategy targets essential business
objectives rather than specific technical disciplines. This approach
to processes effectively avoids the tendency toward an organizational
“stovepipe” mentality.

The
Engineering process areas apply to the development of any product or
service in the development domain (e.g., software products, hardware
products, services, or processes).

The
technical foundation for IPPD is grounded in a robust systems
engineering approach that encompasses development in the context of
the phases of the product’s life. The Engineering process areas
provide this technical foundation. The implementation of IPPD is
further addressed through amplifications to specific practices in the
Engineering process areas that emphasize concurrent development and
focus on all phases of the product’s life.

The
Engineering process areas of CMMI are as follows:

• 
  Requirements
  Development

  
  

• 
  Requirements
  Management

  
  

• 
  Technical
  Solution

  
  

• 
  Product
  Integration

  
  

• 
  Verification

  
  

• 
  Validation

  
  

Figure
4.5 provides a bird’s-eye view of the interactions among the six
Engineering process areas.

Figure
4.5: Engineering Process Areas

The
Requirements Development process area identifies customer needs and
translates these needs into product requirements. The set of product
requirements is analyzed to produce a high-level conceptual solution.
This set of requirements is then allocated to establish an initial
set of product component requirements. Other requirements that help
define the product are derived and allocated to product components.
This set of product and product component requirements clearly
describes the product’s performance, design features, verification
requirements, and so forth, in terms the developer understands and
uses.

The
Requirements Development process area supplies requirements to the
Technical Solution process area, where the requirements are converted
into the product architecture, the product component design, and the
product component itself (e.g., coding and fabrication). Requirements
are also supplied to the Product Integration process area, where
product components are combined and interfaces are verified to ensure
that they meet the interface requirements supplied by Requirements
Development.

The
Requirements Management process area maintains the requirements. It
describes activities for obtaining and controlling requirement
changes and ensuring that other relevant plans and data are kept
current. It provides traceability of requirements from customer to
product to product component.

Requirements
Management ensures that changes to requirements are reflected in
project plans, activities, and work products. This cycle of changes
may affect all the other Engineering process areas; thus,
requirements management is a dynamic and often recursive sequence of
events. The Requirements Management process area is fundamental to a
controlled and disciplined engineering design process.

The
Technical Solution process area develops technical data packages for
product components that will be used by the Product Integration or
Supplier Agreement Management process area. Alternative solutions are
examined with the intent of selecting the optimum design based on
established criteria. These criteria may be significantly different
across products, depending on product type, operational environment,
performance requirements, support requirements, and cost or delivery
schedules. The task of selecting the final solution makes use of the
specific practices in the Decision Analysis and Resolution process
area.

The
Technical Solution process area relies on the specific practices in
the Verification process area to perform design verification and peer
reviews during design and prior to final build.

The
Verification process area ensures that selected work products meet
the specified requirements. The Verification process area selects
work products and verification methods that will be used to verify
work products against specified requirements. Verification is
generally an incremental process, starting with product component
verification and usually concluding with verification of fully
assembled products.

Verification
also addresses peer reviews. Peer reviews are a proven method for
removing defects early and provide valuable insight into the work
products and product components being developed and maintained.

The
Validation process area incrementally validates products against the
customer’s needs. Validation may be performed in the operational
environment or in a simulated operational environment. Coordination
with the customer on the validation requirements is an important
element of this process area.

The
scope of the Validation process area includes validation of products,
product components, selected intermediate work products, and
processes. These validated elements may often require reverification
and revalidation. Issues discovered during validation are usually
resolved in the Requirements Development or Technical Solution
process area.

The
Product Integration process area contains the specific practices
associated with generating the best possible integration sequence,
integrating product components, and delivering the product to the
customer.

Product
Integration uses the specific practices of both Verification and
Validation in implementing the product integration process.
Verification practices verify the interfaces and interface
requirements of product components prior to product integration. This
is an essential event in the integration process. During product
integration in the operational environment, the specific practices of
the Validation process area are used.

Recursion and
Iteration of Engineering Processes

Most
process standards agree that there are two ways that processes can be
applied. These two ways are called recursion and iteration.

Recursion
occurs when a process is applied to successive levels of system
elements within a system structure. The outcomes of one application
are used as inputs to the next level in the system structure. For
example, the verification process is designed to apply to the entire
assembled product, the major product components, and even components
of components. How far into the product you apply the verification
process depends entirely on the size and complexity of the end
product.

Iteration
occurs when processes are repeated at the same system level. New
information is created by the implementation of one process that
feeds back into a related process. This new information typically
raises questions that must be resolved before completing the
processes. For example, iteration will most likely occur between
requirements development and technical solution. Reapplication of the
processes can resolve the questions that are raised. Iteration can
ensure quality prior to applying the next process.

Engineering
processes (e.g., requirements development or verification) are
implemented repeatedly on a product to ensure that these engineering
processes have been adequately addressed before delivery to the
customer. Further, engineering processes are applied to components of
the product. For example, some questions that are raised by processes
associated with the Verification and Validation process areas may be
resolved by processes associated with the Requirements Development or
Product Integration process area. Recursion and iteration of these
processes enable the project to ensure quality in all components of
the product before it is delivered to the customer.

Support

Support
process areas cover the activities that support product development
and maintenance. The Support process areas address processes that are
used in the context of performing other processes. In general, the
Support process areas address processes that are targeted toward the
project and may address processes that apply more generally to the
organization. For example, Process and Product Quality Assurance can
be used with all the process areas to provide an objective evaluation
of the processes and work products described in all the process
areas.

The
Support process areas of CMMI are as follows:

• 
  Configuration
  Management

  
  

• 
  Process
  and Product Quality Assurance

  
  

• 
  Measurement
  and Analysis

  
  

• 
  Decision
  Analysis and Resolution

  
  

• 
  Causal
  Analysis and Resolution

  
  

Basic Support Process
Areas

The
Basic Support process areas address fundamental support functions
that are used by all process areas. Although all Support process
areas rely on the other process areas for input, the Basic Support
process areas provide support functions that also help implement
several generic practices.

Figure
4.6 provides a bird’s-eye view of the interactions among the Basic
Support process areas and with all other process areas.

Figure
4.6: Basic Support Process Areas

The
Measurement and Analysis process area supports all process areas by
providing specific practices that guide projects and organizations in
aligning measurement needs and objectives with a measurement approach
that will provide objective results. These results can be used in
making informed decisions and taking appropriate corrective actions.

The
Process and Product Quality Assurance process area supports all
process areas by providing specific practices for objectively
evaluating performed processes, work products, and services against
the applicable process descriptions, standards, and procedures, and
ensuring that any issues arising from these reviews are addressed.
Process and Product Quality Assurance supports the delivery of
high-quality products and services by providing the project staff and
all levels of managers with appropriate visibility into, and feedback
on, the processes and associated work products throughout the life of
the project.

The
Configuration Management process area supports all process areas by
establishing and maintaining the integrity of work products using
configuration identification, configuration control, configuration
status accounting, and configuration audits. The work products placed
under configuration management include the products that are
delivered to the customer, designated internal work products,
acquired products, tools, and other items that are used in creating
and describing these work products. Examples of work products that
may be placed under configuration management include plans, process
descriptions, requirements, design data, drawings, product
specifications, code, compilers, product data files, and product
technical publications.

Advanced Support
Process Areas

The
Advanced Support process areas provide the projects and organization
with an improved support capability. Each of these process areas
relies on specific inputs or practices from other process areas.

Figure
4.7 provides a bird’s-eye view of the interactions among the
Advanced Support process areas and with all other process areas.

Figure
4.7: Advanced Support Process Areas

Using
the Causal Analysis and Resolution process area, project members
identify causes of selected defects and other problems and take
action to prevent them from occurring in the future. While the
project’s defined processes are the principal targets for
identifying the cause of the defect, the process improvement
proposals they create target the organization’s set of standard
processes, which will prevent recurrence of the defect across the
organization.

The
Decision Analysis and Resolution process area supports all the
process areas by determining which issues should be subjected to a
formal evaluation process and then applying a formal evaluation
process to them.

5Using CMMI Models

The
complexity of today’s products demands an integrated view of how
organizations do business. CMMI can reduce the cost of process
improvement across enterprises that depend on multiple functions or
groups to produce products and services.

To
achieve this integrated view, the CMMI Framework includes common
terminology, common model components, common appraisal methods, and
common training materials. This chapter describes how organizations
can use the CMMI Product Suite not only to improve their quality,
reduce their costs, and optimize their schedules, but also to gauge
how well their process improvement program is working.

Adopting CMMI

Research
has shown that the most powerful initial step to process improvement
is to build strong organizational support through strong senior
management sponsorship. To gain senior management sponsorship, it is
often beneficial to expose senior management to the performance
results experienced by others who have used CMMI to improve their
processes.

For
more information about CMMI performance results, see the SEI Web site
at www.sei.cmu.edu/cmmi/results.html [SEI 3].

The
senior manager, once committed as the process improvement sponsor,
must be actively involved in the CMMI-based process improvement
effort. Activities performed by the senior management sponsor include
(but are not limited to) the following:

• 
  Influence
  the organization to adopt CMMI.

  
  

• 
  Choose
  the best people to manage the process improvement effort.

  
  

• 
  Monitor
  the process improvement effort personally.

  
  

• 
  Be
  a visible advocate and spokesperson for the process improvement
  effort.

  
  

• 
  Ensure
  that adequate resources are available to enable the process
  improvement effort to be successful.

  
  

Given
sufficient senior management sponsorship, the next step is
establishing a strong, technically competent process group that
represents relevant stakeholders to guide process improvement
efforts.

For
an organization with a mission to develop software-intensive systems,
the process group might include engineers representing the different
technical disciplines across the organization and other selected
members based on the business needs driving improvement. For example,
a systems administrator may focus on information-technology support,
whereas a marketing representative may focus on integrating
customers’ needs. Both members could make powerful contributions to
the process group.

Once
your organization has decided to adopt CMMI, planning can begin with
an improvement approach such as the IDEAL^SM (Initiating,
Diagnosing, Establishing, Acting, & Learning) model. For more
information about the IDEAL model, see the SEI Web site at
www.sei.cmu.edu/ideal/ideal.html [SEI 1].

Your Process
Improvement Program

Use
the CMMI Product Suite to help establish your organization’s
process improvement program. Using the product suite for this purpose
can be a relatively informal process that involves understanding and
applying CMMI best practices to your organization. Or, it can be a
formal process that involves extensive training, creation of a
process improvement infrastructure, appraisals, and more.

Selections That
Influence Your Program

You
must make three selections to apply CMMI to your organization for
process improvement:

1. 
   Select
   a part of the organization.

   
   

2. 
   Select
   a model.

   
   

3. 
   Select
   a representation.

   
   

Selecting
the projects to be involved in your process improvement program is
critical. If you select a group that is too large, it may be too much
for the initial improvement effort. The selection should also
consider how homogeneous the group is (i.e., whether they all are
software engineers, whether they all work on the same product or
business line, and so on).

Selecting
the model to be used depends on the areas your organization is
interested in improving. Not only must you select a constellation
(e.g., Development, Acquisition, or Services), but you must also
decide whether to include any additions (e.g., IPPD).

The
process of selecting the representation to be used has some
guidelines because of how CMMI models are built. If your organization
likes the idea of maturity levels and the staged representation, your
improvement roadmap is already defined. If your organization likes
the continuous representation, you can select nearly any process area
or group of process areas to guide improvement, although dependencies
among process areas should be considered when making such a
selection.

As
the process improvement plans and activities progress, other
important selections must be made, including which appraisal method
should be used, which projects should be appraised, how training for
personnel should be secured, and which personnel should be trained.

CMMI Models

CMMI
models describe what have been determined to be best practices that
organizations have found to be productive and useful to achieving
their business objectives.

Regardless
of your type of organization, to apply CMMI best practices, you must
use professional judgment when interpreting them for your situation,
needs, and business objectives. Although process areas depict the
characteristics of an organization committed to process improvement,
you must interpret the process areas using an in-depth knowledge of
CMMI, your organization, the business environment, and the specific
circumstances involved.

As
you begin using a CMMI model to improve your organization’s
processes, map your real-world processes to CMMI process areas. This
mapping enables you to initially judge and later track your
organization’s level of conformance to the CMMI model you are using
and to identify opportunities for improvement.

To
interpret practices, it is important to consider the overall context
in which these practices are used and to determine how well the
practices satisfy the goals of a process area in that context. CMMI
models do not explicitly prescribe nor imply particular processes
that are right for any organization or project. Instead, CMMI
describes minimal criteria necessary to plan and implement processes
selected by the organization for improvement based on business
objectives.

CMMI
practices purposely use nonspecific phrases such as “relevant
stakeholders,” “as appropriate,” and “as necessary” to
accommodate the needs of different organizations and projects. The
specific needs of a project may also differ at various points during
its life.

Using CMMI
Appraisals

Many
organizations find value in measuring their progress by conducting an
appraisal and thus earning a maturity level rating or a capability
level achievement profile. These appraisals are typically conducted
for one or more of the following reasons:

• 
  To
  determine how well the organization’s processes compare to CMMI
  best practices and identify areas where improvement can be made

  
  

• 
  To
  inform external customers and suppliers about how well the
  organization’s processes compare to CMMI best practices

  
  

• 
  To
  meet the contract requirements of one or more customers

  
  

Appraisals
of organizations using a CMMI model must conform to the requirements
defined in the Appraisal Requirements for CMMI (ARC) document. These
appraisals focus on identifying improvement opportunities and
comparing the organization’s processes to CMMI best practices.
Appraisal teams use a CMMI model and ARC-conformant appraisal method
to guide their evaluation of the organization as well as how they
report their conclusions. The appraisal results are then used (by a
process group, for example) to plan improvements for the
organization.

Appraisal Requirements
for CMMI

The
ARC document describes the requirements for several types of
appraisals. A full benchmarking class of appraisal is defined as a
Class A appraisal. Less formal methods are defined as Class B or
Class C methods. The ARC document was designed to help improve
consistency across appraisal methods, and to help appraisal method
developers, sponsors, and users understand the tradeoffs associated
with various methods [SEI 2006a].

Depending
on the purpose of the appraisal and the nature of the circumstances,
one class may be preferred over the others. Sometimes
self-assessments, initial appraisals, quick-look, or mini-appraisals,
incremental appraisals, or external appraisals are appropriate, and
other times a formal benchmarking appraisal is appropriate.

A
particular appraisal method is declared an ARC Class A, B, or C
appraisal method based on the sets of ARC requirements that the
method developer addressed when designing the method.

More
information about the ARC is available on the SEI Web site at
www.sei.cmu.edu/cmmi/appraisals/appraisals.html.

SCAMPI Appraisal
Methods

The
SCAMPI appraisal methods are the generally accepted methods used for
conducting appraisals using CMMI models. The SCAMPI Method Definition
Document (MDD) defines rules for ensuring the consistency of
appraisal ratings. For benchmarking against other organizations,
appraisals must ensure consistent ratings. The achievement of a
specific maturity level or the satisfaction of a process area must
mean the same thing for different appraised organizations.

The
SCAMPI family of appraisals includes Class A, B, and C appraisal
methods. SCAMPI A is the most rigorous method and the only method
that can result in a rating. SCAMPI B provides options in model
scope, but the characterization of practices is fixed to one scale
and is performed on implemented practices. SCAMPI C provides a wide
range of options, including characterization of planned approaches to
process implementation according to a scale defined by the user.

More
information about SCAMPI methods is available on the SEI Web site at
www.sei.cmu.edu/cmmi/appraisals/appraisals.html [SEI 2006b].

Appraisal
Considerations

Choices
that affect a CMMI-based appraisal include the following:

• 
  Which
  CMMI model to use for the appraisal (for this constellation, the
  choice would be between the CMMI for Development model and the CMMI
  for Development +IPPD model)

  
  

• 
  Establishing
  the appraisal scope, including the organizational unit to be
  appraised, the CMMI process areas to be investigated, and the
  maturity level or capability level(s) to be appraised

  
  

• 
  Selecting
  the appraisal method

  
  

• 
  Selecting
  the appraisal team members

  
  

• 
  Selecting
  appraisal participants from the appraisal entities to be interviewed

  
  

• 
  Establishing
  appraisal outputs (e.g., ratings or instantiation-specific findings)

  
  

• 
  Establishing
  appraisal constraints (e.g., time spent on site)

  
  

The
SCAMPI MDD allows the selection of predefined options for use in an
appraisal. These appraisal options are designed to help organizations
align CMMI with their business needs and objectives.

Documentation
of CMMI appraisal plans and results must always include a description
of the appraisal options, model scope, and organizational scope
selected. This documentation confirms whether an appraisal meets the
requirements for benchmarking.

For
organizations that wish to appraise multiple functions or groups,
CMMI’s integrated approach enables some economy of scale in model
and appraisal training. One appraisal method can provide separate or
combined results for multiple functions.

The
appraisal principles for the CMMI Product Suite¹²
remain the same as those used in appraisals for other process
improvement models. Those principles are as follows:

• 
  Senior
  management sponsorship¹³

  
  

• 
  A
  focus on the organization’s business objectives

  
  

• 
  Confidentiality
  for interviewees

  
  

• 
  Use
  of a documented appraisal method

  
  

• 
  Use
  of a process reference model (e.g., a CMMI model) as a base

  
  

• 
  A
  collaborative team approach

  
  

• 
  A
  focus on actions for process improvement

  
  

CMMI-Related
Training

Whether
your organization is new to process improvement or is already
familiar with process improvement models, training is a key element
in the ability of organizations to adopt CMMI. An initial set of
courses is provided by the SEI and its Partners, but your
organization may wish to supplement these courses with internal
instruction. This approach allows your organization to focus on the
areas that provide the greatest business value.

The
SEI and its Partners offer the Introduction to CMMI course,
which provides a basic overview of the CMMI models. The SEI also
offers the Intermediate Concepts of CMMI course to those who
plan to become more deeply involved in CMMI adoption or appraisal—for
example, those who will guide improvement as part of a process group,
those who will lead SCAMPI appraisals, and those who will teach the
Introduction to CMM course. Current information about
CMMI-related training is available on the SEI Web site at
www.sei.cmu.edu/cmmi/training/training.html.

Part Two

Generic Goals and
Generic Practices, and the Process Areas

Generic Goals and
Generic Practices

Overview

This
section describes, in detail, all the generic goals and generic
practices of CMMI—model components that directly address process
institutionalization.

In
the process areas, generic goals and generic practices appear at the
end of each process area. Generic practice elaborations appear after
generic practices to show how these practices should uniquely be
applied to the process area.

The
entire text of the generic goals and generic practices is not
repeated in the process areas (i.e., subpractices, notes, examples,
and references are omitted). Instead, only the generic goal and
generic practice titles and statements appear. As you address each
process area, refer to this section for the details of all generic
practices.

Process
Institutionalization

Institutionalization
is an important concept in process improvement. When mentioned in the
generic goal and generic practice descriptions, institutionalization
implies that the process is ingrained in the way the work is
performed and there is commitment and consistency to performing the
process.

An
institutionalized process is more likely to be retained during times
of stress. When the requirements and objectives for the process
change, however, the implementation of the process may also need to
change to ensure that it remains effective. The generic practices
describe activities that address these aspects of
institutionalization.

The
degree of institutionalization is embodied in the generic goals and
expressed in the names of the processes associated with each goal as
indicated in Table 6.1.

Table 6.1 Generic Goals
and Process Names

Generic Goal	Progression of Processes
GG 1	Performed process
GG 2	Managed process
GG 3	Defined process
GG 4	Quantitatively managed process
GG 5	Optimizing process

The
progression of process institutionalization is characterized in the
following descriptions of each process.

Performed Process

A
performed process is a process that accomplishes the work necessary
to produce work products. The specific goals of the process area are
satisfied.

Managed Process

A
managed process is a performed process that is planned and executed
in accordance with policy; employs skilled people who have adequate
resources to produce controlled outputs; involves relevant
stakeholders; is monitored, controlled, and reviewed; and is
evaluated for adherence to its process description. The process may
be instantiated by a project, group, or organizational function.
Management of the process is concerned with institutionalization and
the achievement of other specific objectives established for the
process, such as cost, schedule, and quality objectives. The control
provided by a managed process helps to ensure that the established
process is retained during times of stress.

The
requirements and objectives for the process are established by the
organization. The status of the work products and delivery of the
services are visible to management at defined points (e.g., at major
milestones and completion of major tasks). Commitments are
established among those performing the work and the relevant
stakeholders and are revised as necessary. Work products are reviewed
with relevant stakeholders and are controlled. The work products and
services satisfy their specified requirements.

A
critical distinction between a performed process and a managed
process is the extent to which the process is managed. A managed
process is planned (the plan may be part of a more encompassing plan)
and the performance of the process is managed against the plan.
Corrective actions are taken when the actual results and performance
deviate significantly from the plan. A managed process achieves the
objectives of the plan and is institutionalized for consistent
performance.

Defined Process

A
defined process is a managed process that is tailored from the
organization’s set of standard processes according to the
organization’s tailoring guidelines; has a maintained process
description; and contributes work products, measures, and other
process improvement information to the organizational process assets.

The
organizational process assets are artifacts that relate to
describing, implementing, and improving processes. These artifacts
are assets because they are developed or acquired to meet the
business objectives of the organization, and they represent
investments by the organization that are expected to provide current
and future business value.

The
organization’s set of standard processes, which are the basis of
the defined process, are established and improved over time. Standard
processes describe the fundamental process elements that are expected
in the defined processes. Standard processes also describe the
relationships (e.g., the ordering and the interfaces) among these
process elements. The organization-level infrastructure to support
current and future use of the organization’s set of standard
processes is established and improved over time. (See the definition
of “standard process” in the glossary.)

A
project’s defined process provides a basis for planning,
performing, and improving the project’s tasks and activities. A
project may have more than one defined process (e.g., one for
developing the product and another for testing the product).

A
defined process clearly states the following:

• 
  Purpose

  
  

• 
  Inputs

  
  

• 
  Entry
  criteria

  
  

• 
  Activities

  
  

• 
  Roles

  
  

• 
  Measures

  
  

• 
  Verification
  steps

  
  

• 
  Outputs

  
  

• 
  Exit
  criteria

  
  

A
critical distinction between a managed process and a defined process
is the scope of application of the process descriptions, standards,
and procedures. For a managed process, the process descriptions,
standards, and procedures are applicable to a particular project,
group, or organizational function. As a result, the managed processes
of two projects in one organization may be different.

Another
critical distinction is that a defined process is described in more
detail and is performed more rigorously than a managed process. This
means that improvement information is easier to understand, analyze,
and use. Finally, management of the defined process is based on the
additional insight provided by an understanding of the
interrelationships of the process activities and detailed measures of
the process, its work products, and its services.

Quantitatively Managed
Process

A
quantitatively managed process is a defined process that is
controlled using statistical and other quantitative techniques. The
product quality, service quality, and process-performance attributes
are measurable and controlled throughout the project.

Quantitative
objectives are established based on the capability of the
organization’s set of standard processes; the organization’s
business objectives; and the needs of the customer, end users,
organization, and process implementers, subject to the availability
of resources. The people performing the process are directly involved
in quantitatively managing the process.

Quantitative
management is performed on the overall set of processes that produces
a product. The subprocesses that are significant contributors to
overall process performance are statistically managed. For these
selected subprocesses, detailed measures of process performance are
collected and statistically analyzed. Special causes of process
variation are identified and, where appropriate, the source of the
special cause is addressed to prevent its recurrence.

The
quality and process-performance measures are incorporated into the
organization’s measurement repository to support future fact-based
decision making.

Activities
for quantitatively managing the performance of a process include the
following:

• 
  Identifying
  the subprocesses that are to be brought under statistical management

  
  

• 
  Identifying
  and measuring product and process attributes that are important
  contributors to quality and process performance

  
  

• 
  Identifying
  and addressing special causes of subprocess variations (based on the
  selected product and process attributes and subprocesses selected
  for statistical management)

  
  

• 
  Managing
  each of the selected subprocesses, with the objective of bringing
  their performance within natural bounds (i.e., making the subprocess
  performance statistically stable and predictable based on the
  selected product and process attributes)

  
  

• 
  Predicting
  the ability of the process to satisfy established quantitative
  quality and process-performance objectives

  
  

• 
  Taking
  appropriate corrective actions when it is determined that the
  established quantitative quality and process-performance objectives
  will not be satisfied

  
  

These
corrective actions include changing the objectives or ensuring that
relevant stakeholders have a quantitative understanding of, and have
agreed to, the performance shortfall.

A
critical distinction between a defined process and a quantitatively
managed process is the predictability of process performance. The
term quantitatively managed implies using appropriate statistical and
other quantitative techniques to manage the performance of one or
more critical subprocesses so that the performance of the process can
be predicted. A defined process provides only qualitative
predictability.

Optimizing Process

An
optimizing process is a quantitatively managed process that is
changed and adapted to meet relevant current and projected business
objectives. An optimizing process focuses on continually improving
process performance through both incremental and innovative
technological improvements. Process improvements that address common
causes of process variation, root causes of defects, and other
problems; and those that would measurably improve the organization’s
processes are identified, evaluated, and deployed as appropriate.
These improvements are selected based on a quantitative understanding
of their expected contribution to achieving the organization’s
process improvement objectives versus the cost and impact to the
organization.

Selected
incremental and innovative technological process improvements are
systematically managed and deployed into the organization. The
effects of the deployed process improvements are measured and
evaluated against the quantitative process improvement objectives.

In
a process that is optimized, common causes of process variation are
addressed by changing the process in a way that will shift the mean
or decrease variation when the process is restabilized. These changes
are intended to improve process performance and to achieve the
organization’s established process improvement objectives.

A
critical distinction between a quantitatively managed process and an
optimizing process is that the optimizing process is continuously
improved by addressing common causes of process variation. A
quantitatively managed process is concerned with addressing special
causes of process variation and providing statistical predictability
of the results. Although the process may produce predictable results,
the results may be insufficient to achieve the organization’s
process improvement objectives.

Relationships among
Processes

The
generic goals evolve so that each goal provides a foundation for the
next. Therefore the following conclusions can be made:

• 
  A
  managed process is a performed process.

  
  

• 
  A
  defined process is a managed process.

  
  

• 
  A
  quantitatively managed process is a defined process.

  
  

• 
  An
  optimizing process is a quantitatively managed process.

  
  

Thus,
applied sequentially and in order, the generic goals describe a
process that is increasingly institutionalized from a performed
process to an optimizing process.

Achieving
GG 1 for a process area is equivalent to saying you achieve the
specific goals of the process area.

Achieving
GG 2 for a process area is equivalent to saying you manage the
performance of processes associated with the process area. There is a
policy that indicates you will perform it. There is a plan for
performing it. There are resources provided, responsibilities
assigned, training on how to perform it, selected work products from
performing the process are controlled, and so on. In other words, the
process is planned and monitored just like any project or support
activity.

Achieving
GG 3 for a process area assumes that an organizational standard
process exists that can be tailored to result in the process you will
use. Tailoring might result in making no changes to the standard
process. In other words, the process used and the standard process
may be identical. Using the standard process “as is” is tailoring
because the choice is made that no modification is required.

Each
process area describes multiple activities, some of which are
repeatedly performed. You may need to tailor the way one of these
activities is performed to account for new capabilities or
circumstances. For example, you may have a standard for developing or
obtaining organizational training that does not consider Web-based
training. When preparing to develop or obtain a Web-based course, you
may need to tailor the standard process to account for the particular
challenges and benefits of Web-based training.

Achieving
GG 4 or GG 5 for a process area is conceptually feasible but may not
be economical except, perhaps, in situations where the product domain
has become stable for an extended period or in situations in which
the process area or domain is a critical business driver.

Generic Goals and
Generic Practices

This
section describes all of the generic goals and generic practices, as
well as their associated subpractices, notes, examples, and
references. The generic goals are organized in numerical order, GG 1
through GG 5. The generic practices are also organized in numerical
order under the generic goal they support.

As
mentioned earlier, the subpractices, notes, examples, and references
are not repeated in the process areas; the details of each generic
goal and generic practice are found only here.

GG 1 Achieve Specific
Goals

The process supports and enables
achievement of the specific goals of the process area by transforming
identifiable input work products to produce identifiable output work
products.

GP 1.1 Perform
Specific Practices

Perform the specific practices
of the process area to develop work products and provide services to
achieve the specific goals of the process area.

The
purpose of this generic practice is to produce the work products and
deliver the services that are expected by performing the process.
These practices may be done informally, without following a
documented process description or plan. The rigor with which these
practices are performed depends on the individuals managing and
performing the work and may vary considerably.

GG 2 Institutionalize
a Managed Process

The process is institutionalized
as a managed process.

GP 2.1 Establish an
Organizational Policy

Establish and maintain an
organizational policy for planning and performing the process.

The
purpose of this generic practice is to define the organizational
expectations for the process and make these expectations visible to
those in the organization who are affected. In general, senior
management is responsible for establishing and communicating guiding
principles, direction, and expectations for the organization.

Not
all direction from senior management will bear the label “policy.”
The existence of appropriate organizational direction is the
expectation of this generic practice, regardless of what it is called
or how it is imparted.

GP 2.2 Plan the
Process

Establish and maintain the plan
for performing the process.

The
purpose of this generic practice is to determine what is needed to
perform the process and to achieve the established objectives, to
prepare a plan for performing the process, to prepare a process
description, and to get agreement on the plan from relevant
stakeholders.

The
practical implications of applying a generic practice vary for each
process area. For example, the planning described by this generic
practice as applied to the Project Monitoring and Control process
area may be carried out in full by the processes associated with the
Project Planning process area. However, this generic practice, when
applied to the Project Planning process area, sets an expectation
that the project planning process itself be planned. Therefore, this
generic practice may either reinforce expectations set elsewhere in
CMMI or set new expectations that should be addressed.

Refer
to the Project Planning process area for more information on
establishing and maintaining a project plan.

Establishing
a plan includes documenting the plan and a process description.
Maintaining the plan includes updating it to reflect corrective
actions or changes in requirements or objectives.

The
plan for performing the process typically includes the following:

• 
  Process
  description

  
  

• 
  Standards
  and requirements for the work products and services of the process

  
  

• 
  Specific
  objectives for the performance of the process (e.g., quality, time
  scale, cycle time, and resource usage)

  
  

• 
  Dependencies
  among the activities, work products, and services of the process

  
  

• 
  Resources
  (including funding, people, and tools) needed to perform the process

  
  

• 
  Assignment
  of responsibility and authority

  
  

• 
  Training
  needed for performing and supporting the process

  
  

• 
  Work
  products to be controlled and the level of control to be applied

  
  

• 
  Measurement
  requirements to provide insight into the performance of the process,
  its work products, and its services

  
  

• 
  Involvement
  of identified stakeholders

  
  

• 
  Activities
  for monitoring and controlling the process

  
  

• 
  Objective
  evaluation activities of the process

  
  

• 
  Management
  review activities for the process and the work products

  
  

Subpractices

1. Define
and document the plan for performing the process.

This
plan may be a stand-alone document, embedded in a more comprehensive
document, or distributed across multiple documents. In the case of
the plan being distributed across multiple documents, ensure that a
coherent picture of who does what is preserved. Documents may be
hardcopy or softcopy.

2. Define
and document the process description.

The
process description, which includes relevant standards and
procedures, may be included as part of the plan for performing the
process or may be included in the plan by reference.

3. Review
the plan with relevant stakeholders and get their agreement.

This
includes reviewing that the planned process satisfies the applicable
policies, plans, requirements, and standards to provide assurance to
relevant stakeholders.

4. Revise
the plan as necessary.

GP 2.3 Provide
Resources

Provide adequate resources for
performing the process, developing the work products, and providing
the services of the process.

The
purpose of this generic practice is to ensure that the resources
necessary to perform the process as defined by the plan are available
when they are needed. Resources include adequate funding, appropriate
physical facilities, skilled people, and appropriate tools.

The
interpretation of the term “adequate” depends on many factors and
can change over time. Inadequate resources may be addressed by
increasing resources or by removing requirements, constraints, and
commitments.

GP 2.4 Assign
Responsibility

Assign responsibility and
authority for performing the process, developing the work products,
and providing the services of the process.

The
purpose of this generic practice is to ensure that there is
accountability for performing the process and achieving the specified
results throughout the life of the process. The people assigned must
have the appropriate authority to perform the assigned
responsibilities.

Responsibility
can be assigned using detailed job descriptions or in living
documents, such as the plan for performing the process. Dynamic
assignment of responsibility is another legitimate way to perform
this generic practice, as long as the assignment and acceptance of
responsibility are ensured throughout the life of the process.

Subpractices

1. Assign
overall responsibility and authority for performing the process.

2. Assign
responsibility and authority for performing the specific tasks of the
process.

3. Confirm
that the people assigned to the responsibilities and authorities
understand and accept them.

GP 2.5 Train People

Train the people performing or
supporting the process as needed.

The
purpose of this generic practice is to ensure that the people have
the necessary skills and expertise to perform or support the process.

Appropriate
training is provided to the people who will be performing the work.
Overview training is provided to orient people who interact with
those performing the work.

Examples
of methods for providing training include self-study; self-directed
training; self-paced, programmed instruction; formalized on-the-job
training; mentoring; and formal and classroom training.

Training
supports the successful performance of the process by establishing a
common understanding of the process and by imparting the skills and
knowledge needed to perform the process.

Refer
to the Organizational Training process area for more information
about training the people performing or supporting the process.

GP 2.6 Manage
Configurations

Place designated work products
of the process under appropriate levels of control.

The
purpose of this generic practice is to establish and maintain the
integrity of the designated work products of the process (or their
descriptions) throughout their useful life.

The
designated work products are specifically identified in the plan for
performing the process, along with a specification of the appropriate
level of control.

Different
levels of control are appropriate for different work products and for
different points in time. For some work products, it may be
sufficient to maintain version control (i.e., the version of the work
product in use at a given time, past or present, is known, and
changes are incorporated in a controlled manner). Version control is
usually under the sole control of the work product owner (which may
be an individual, a group, or a team).

Sometimes,
it may be critical that work products be placed under formal or
baseline configuration management. This type of control includes
defining and establishing baselines at predetermined points. These
baselines are formally reviewed and agreed on, and serve as the basis
for further development of the designated work products.

Refer
to the Configuration Management process area for more information
about placing work products under configuration management.

Additional
levels of control between version control and formal configuration
management are possible. An identified work product may be under
various levels of control at different points in time.

GP 2.7 Identify and
Involve Relevant Stakeholders

Identify and involve the
relevant stakeholders of the process as planned.

The
purpose of this generic practice is to establish and maintain the
expected involvement of stakeholders during the execution of the
process.

Involve
relevant stakeholders as described in an appropriate plan for
stakeholder involvement. Involve stakeholders appropriately in
activities such as the following:

• 
  Planning

  
  

• 
  Decisions

  
  

• 
  Commitments

  
  

• 
  Communications

  
  

• 
  Coordination

  
  

• 
  Reviews

  
  

• 
  Appraisals

  
  

• 
  Requirements
  definitions

  
  

• 
  Resolution
  of problems/issues

  
  

Refer
to the Project Planning process area for information on the project
planning for stakeholder involvement.

The
objective of planning stakeholder involvement is to ensure that
interactions necessary to the process are accomplished, while not
allowing excessive numbers of affected groups and individuals to
impede process execution.

Subpractices

1. Identify
stakeholders relevant to this process and their appropriate
involvement.

Relevant
stakeholders are identified among the suppliers of inputs to, the
users of outputs from, and the performers of the activities within
the process. Once the relevant stakeholders are identified, the
appropriate level of their involvement in process activities is
planned.

2. Share
these identifications with project planners or other planners as
appropriate.

3. Involve
relevant stakeholders as planned.

GP 2.8 Monitor and
Control the Process

Monitor and control the process
against the plan for performing the process and take appropriate
corrective action.

The
purpose of this generic practice is to perform the direct day-to-day
monitoring and controlling of the process. Appropriate visibility
into the process is maintained so that appropriate corrective action
can be taken when necessary. Monitoring and controlling the process
involves measuring appropriate attributes of the process or work
products produced by the process.

Refer
to the Project Monitoring and Control process area for more
information about monitoring and controlling the project and taking
corrective action.

Refer
to the Measurement and Analysis process area for more information
about measurement.

Subpractices

1. Measure
actual performance against the plan for performing the process.

The
measures are of the process, its work products, and its services.

2. Review
accomplishments and results of the process against the plan for
performing the process.

3. Review
activities, status, and results of the process with the immediate
level of management responsible for the process and identify issues.
The reviews are intended to provide the immediate level of management
with appropriate visibility into the process. The reviews can be both
periodic and event driven.

4. Identify
and evaluate the effects of significant deviations from the plan for
performing the process.

5. Identify
problems in the plan for performing the process and in the execution
of the process.

6. Take
corrective action when requirements and objectives are not being
satisfied, when issues are identified, or when progress differs
significantly from the plan for performing the process.

There
are inherent risks that should be considered before any corrective
action is taken.

Corrective
action may include the following:

• 
  Taking remedial
  action to repair defective work products or services

  
  

• 
  Changing the plan
  for performing the process

  
  

• 
  Adjusting
  resources, including people, tools, and other resources

  
  

• 
  Negotiating
  changes to the established commitments

  
  

• 
  Securing change
  to the requirements and objectives that have to be satisfied

  
  

• 
  Terminating the
  effort

  
  

7. Track
corrective action to closure.

GP 2.9 Objectively
Evaluate Adherence

Objectively evaluate adherence
of the process against its process description, standards, and
procedures, and address noncompliance.

The
purpose of this generic practice is to provide credible assurance
that the process is implemented as planned and adheres to its process
description, standards, and procedures. This generic practice is
implemented, in part, by evaluating selected work products of the
process. (See the definition of objectively evaluate in the
glossary.)

Refer
to the Process and Product Quality Assurance process area for more
information about objectively evaluating adherence.

People
not directly responsible for managing or performing the activities of
the process typically evaluate adherence. In many cases, adherence is
evaluated by people within the organization, but external to the
process or project, or by people external to the organization. As a
result, credible assurance of adherence can be provided even during
times when the process is under stress (e.g., when the effort is
behind schedule or over budget).

GP 2.10 Review Status
with Higher Level Management

Review the activities, status,
and results of the process with higher level management and resolve
issues.

The
purpose of this generic practice is to provide higher level
management with the appropriate visibility into the process.

Higher
level management includes those levels of management in the
organization above the immediate level of management responsible for
the process. In particular, higher level management includes senior
management. These reviews are for managers who provide the policy and
overall guidance for the process, and not for those who perform the
direct day-to-day monitoring and controlling of the process.

Different
managers have different needs for information about the process.
These reviews help ensure that informed decisions on the planning and
performing of the process can be made. Therefore, these reviews are
expected to be both periodic and event driven.

GG 3 Institutionalize
a Defined Process

The process is institutionalized
as a defined process.

GP 3.1 Establish a
Defined Process

Establish and maintain the
description of a defined process.

The
purpose of this generic practice is to establish and maintain a
description of the process that is tailored from the organization’s
set of standard processes to address the needs of a specific
instantiation. The organization should have standard processes that
cover the process area, as well as have guidelines for tailoring
these standard processes to meet the needs of a project or
organizational function. With a defined process, variability in how
the processes are performed across the organization is reduced and
process assets, data, and learning can be effectively shared.

Refer
to the Organizational Process Definition process area for more
information about the organization’s set of standard processes and
tailoring guidelines.

Refer
to the Integrated Project Management process area for more
information on establishing and maintaining the project’s defined
process.

The
descriptions of the defined processes provide the basis for planning,
performing, and managing the activities, work products, and services
associated with the process.

Subpractices

1. Select
from the organization’s set of standard processes those processes
that cover the process area and best meet the needs of the project or
organizational function.

2. Establish
the defined process by tailoring the selected processes according to
the organization’s tailoring guidelines.

3. Ensure
that the organization’s process objectives are appropriately
addressed in the defined process.

4. Document
the defined process and the records of the tailoring.

5. Revise
the description of the defined process as necessary.

GP 3.2 Collect
Improvement Information

Collect work products, measures,
measurement results, and improvement information derived from
planning and performing the process to support the future use and
improvement of the organization’s processes and process assets.

The
purpose of this generic practice is to collect information and
artifacts derived from planning and performing the process. This
generic practice is performed so that the information and artifacts
can be included in the organizational process assets and made
available to those who are (or who will be) planning and performing
the same or similar processes. The information and artifacts are
stored in the organization’s measurement repository and the
organization’s process asset library.

Examples
of relevant information include the effort expended for the various
activities, defects injected or removed in a particular activity, and
lessons learned.

Refer
to the Organizational Process Definition process area for more
information about the organization’s measurement repository and
process asset library and for more information about the work
products, measures, and improvement information that are incorporated
into the organizational process assets.

Refer
to the Integrated Project Management process area for more
information on contributing work products, measures, and documented
experiences to the organizational process assets.

Subpractices

1. Store
process and product measures in the organization’s measurement
repository.

The
process and product measures are primarily those that are defined in
the common set of measures for the organization’s set of standard
processes.

2. Submit
documentation for inclusion in the organization’s process asset
library.

3. Document
lessons learned from the process for inclusion in the organization’s
process asset library.

4. Propose
improvements to the organizational process assets.

GG 4 Institutionalize
a Quantitatively Managed Process

The process is institutionalized
as a quantitatively managed process.

GP 4.1 Establish
Quantitative Objectives for the Process

Establish and maintain
quantitative objectives for the process, which address quality and
process performance, based on customer needs and business objectives.

The
purpose of this generic practice is to determine and obtain agreement
from relevant stakeholders about specific quantitative objectives for
the process. These quantitative objectives can be expressed in terms
of product quality, service quality, and process performance.

Refer
to the Quantitative Project Management process area for information
on how quantitative objectives are set for subprocesses of the
project’s defined process.

The
quantitative objectives may be specific to the process or they may be
defined for a broader scope (e.g., for a set of processes). In the
latter case, these quantitative objectives may be allocated to some
of the included processes.

These
quantitative objectives are criteria used to judge whether the
products, services, and process performance will satisfy the
customers, end users, organization management, and process
implementers. These quantitative objectives go beyond the traditional
end-product objectives. They also cover intermediate objectives that
are used to manage the achievement of the objectives over time. They
reflect, in part, the demonstrated performance of the organization’s
set of standard processes. These quantitative objectives should be
set to values that are likely to be achieved when the processes
involved are stable and within their natural bounds.

Subpractices

1. Establish
the quantitative objectives that pertain to the process.

2. Allocate
the quantitative objectives to the process or its subprocesses.

GP 4.2 Stabilize
Subprocess Performance

Stabilize the performance of one
or more subprocesses to determine the ability of the process to
achieve the established quantitative quality and process-performance
objectives.

The
purpose of this generic practice is to stabilize the performance of
one or more subprocesses of the defined process, which are critical
contributors to overall performance, using appropriate statistical
and other quantitative techniques. Stabilizing selected subprocesses
supports predicting the ability of the process to achieve the
established quantitative quality and process-performance objectives.

Refer
to the Quantitative Project Management process area for information
on selecting subprocesses for statistical management, monitoring
performance of subprocesses, and other aspects of stabilizing
subprocess performance.

A
stable subprocess shows no significant indication of special causes
of process variation. Stable subprocesses are predictable within the
limits established by the natural bounds of the subprocess.
Variations in the stable subprocess are due to a constant system of
chance causes, and the magnitude of the variations can be small or
large.

Predicting
the ability of the process to achieve the established quantitative
objectives requires a quantitative understanding of the contributions
of the subprocesses that are critical to achieving these objectives
and establishing and managing against interim quantitative objectives
over time.

Selected
process and product measures are incorporated into the organization’s
measurement repository to support process-performance analysis and
future fact-based decision making.

Subpractices

1. Statistically
manage the performance of one or more subprocesses that are critical
contributors to the overall performance of the process.

2. Predict
the ability of the process to achieve its established quantitative
objectives considering the performance of the statistically managed
subprocesses.

3. Incorporate
selected process-performance measurements into the organization’s
process-performance baselines.

GG 5 Institutionalize
an Optimizing Process

The process is institutionalized
as an optimizing process.

GP 5.1 Ensure
Continuous Process Improvement

Ensure continuous improvement of
the process in fulfilling the relevant business objectives of the
organization.

The
purpose of this generic practice is to select and systematically
deploy process and technology improvements that contribute to meeting
established quality and process-performance objectives.

Refer
to the Organizational Innovation and Deployment process area for
information about selecting and deploying incremental and innovative
improvements that measurably improve the organization’s processes and
technologies.

Optimizing
the processes that are agile and innovative depends on the
participation of an empowered workforce aligned with the business
values and objectives of the organization. The organization’s
ability to rapidly respond to changes and opportunities is enhanced
by finding ways to accelerate and share learning. Improvement of the
processes is inherently part of everybody’s role, resulting in a
cycle of continual improvement.

Subpractices

1. Establish
and maintain quantitative process improvement objectives that support
the organization’s business objectives.

The
quantitative process improvement objectives may be specific to the
individual process or they may be defined for a broader scope (i.e.,
for a set of processes), with the individual processes contributing
to achieving these objectives. Objectives that are specific to the
individual process are typically allocated from quantitative
objectives established for a broader scope.

These
process improvement objectives are primarily derived from the
organization’s business objectives and from a detailed
understanding of process capability. These objectives are the
criteria used to judge whether the process performance is
quantitatively improving the organization’s ability to meet its
business objectives. These process improvement objectives are often
set to values beyond the current process performance, and both
incremental and innovative technological improvements may be needed
to achieve these objectives. These objectives may also be revised
frequently to continue to drive the improvement of the process (i.e.,
when an objective is achieved, it may be set to a new value that is
again beyond the new process performance).

These
process improvement objectives may be the same as, or a refinement
of, the objectives established in the “Establish Quantitative
Objectives for the Process” generic practice, as long as they can
serve as both drivers and criteria for successful process
improvement.

2. Identify
process improvements that would result in measurable improvements to
process performance.

Process
improvements include both incremental changes and innovative
technological improvements. The innovative technological improvements
are typically pursued as efforts that are separately planned,
performed, and managed. Piloting is often performed. These efforts
often address specific areas of the processes that are determined by
analyzing process performance and identifying specific opportunities
for significant measurable improvement.

3. Define
strategies and manage deployment of selected process improvements
based on the quantified expected benefits, the estimated costs and
impacts, and the measured change to process performance.

The
costs and benefits of these improvements are estimated
quantitatively, and the actual costs and benefits are measured.
Benefits are primarily considered relative to the organization’s
quantitative process improvement objectives. Improvements are made to
both the organization’s set of standard processes and the defined
processes.

Managing
deployment of the process improvements includes piloting changes and
implementing adjustments where appropriate, addressing potential and
real barriers to deployment, minimizing disruption to ongoing
efforts, and managing risks.

GP 5.2 Correct Root
Causes of Problems

Identify and correct the root
causes of defects and other problems in the process.

The
purpose of this generic practice is to analyze defects and other
problems that were encountered in a quantitatively managed process,
to correct the root causes of these types of defects and problems,
and to prevent these defects and problems from occurring in the
future.

Refer
to the Causal Analysis and Resolution process area for more
information about identifying and correcting root causes of selected
defects. Even though the Causal Analysis and Resolution process area
has a project context, it can be applied to processes in other
contexts as well.

Root
cause analysis can be applied beneficially to processes that are not
quantitatively managed. However, the focus of this generic practice
is to act on a quantitatively managed process, though the final root
causes may be found outside of that process.

Applying Generic
Practices

This
section helps you to develop a better understanding of the generic
practices and provides information for interpreting and applying the
generic practices in your organization.

Generic
practices are components that are common to all process areas. Think
of generic practices as reminders. They serve the purpose of
reminding you to do things right, and are expected model components.

For
example, when you are achieving the specific goals of the Project
Planning process area, you are establishing and maintaining a plan
that defines project activities. One of the generic practices that
applies to the Project Planning process area is “Establish and
maintain the plan for performing the project planning process” (GP
2.2). When applied to this process area, this generic practice
reminds you to plan the activities involved in creating the plan for
the project.

When
you are satisfying the specific goals of the Organizational Training
process area, you are developing the skills and knowledge of people
in your project and organization so that they can perform their roles
effectively and efficiently. When applying the same generic practice
(GP 2.2) to the Organizational Training process area, this generic
practice reminds you to plan the activities involved in developing
the skills and knowledge of people in the organization.

Process Areas That
Support Generic Practices

While
generic goals and generic practices are the model components that
directly address the institutionalization of a process across the
organization, many process areas likewise address
institutionalization by supporting the implementation of the generic
practices. Knowing these relationships will help you effectively
implement the generic practices.

Such
process areas contain one or more specific practices that when
implemented may also fully implement a generic practice or generate a
work product that is used in the implementation of a generic
practice.

An
example is the Configuration Management process area and GP 2.6,
“Place designated work products of the process under appropriate
levels of control.” To implement the generic practice for one or
more process areas, you might choose to implement the Configuration
Management process area, all or in part, to implement the generic
practice.

Another
example is the Organizational Process Definition process area and GP
3.1, “Establish and maintain the description of a defined process.”
To implement this generic practice for one or more process areas, you
should first implement the Organizational Process Definition process
area, all or in part, to establish the organizational process assets
that are needed to implement the generic practice.

Table
6.2 describes (1) the process areas that support the implementation
of generic practices, and (2) the recursive relationships between
generic practices and their closely related process areas. Both types
of relationships are important to remember during process improvement
to take advantage of the natural synergies that exist between the
generic practices and their related process areas.

Table
6.2 Generic Practice and Process Area Relationships

Generic Practice	Roles of Process Areas in Implementation of the Generic Practice	How the Generic Practice Recursively Applies to its Related Process Area(s)14
GP 2.2 Plan the Process	Project Planning: The project planning process can implement GP 2.2 in full for all project-related process areas (except for Project Planning itself).	GP 2.2 applied to the project planning process can be characterized as “plan the plan” and covers planning project planning activities.
GP 2.3 Provide Resources GP 2.4 Assign Responsibility	Project Planning: The part of the project planning process that implements Project Planning SP 2.4, “Plan for necessary resources to perform the project,” supports the implementation of GP 2.3 and GP 2.4 for all project-related process areas (except perhaps initially for Project Planning itself) by identifying needed processes, roles, and responsibilities to ensure the proper staffing, facilities, equipment, and other assets needed by the project are secured.
GP 2.5 Train People	Organizational Training: The organizational training process supports the implementation of GP 2.5 as applied to all process areas by making the training that addresses strategic or organization-wide training needs available to those who will perform or support the process. Project Planning: The part of the project planning process that implements Project Planning SP 2.5, “Plan for knowledge and skills needed to perform the project,” together with the organizational training process, supports the implementation of GP 2.5 in full for all project-related process areas.	GP 2.5 applied to the organizational training process area covers training for performing the organizational training activities, which addresses the skills required to manage, create, and accomplish the training.
GP 2.6 Manage Configurations	Configuration Management: The configuration management process can implement GP 2.6 in full for all project-related process areas as well as some of the organizational process areas.	GP 2.6 applied to the configuration management process covers change and version control for the work products produced by configuration management activities.
GP 2.7 Identify and Involve Relevant Stakeholders	Project Planning: The part of the project planning process that implements Project Planning SP 2.6, “Plan Stakeholder Involvement,” can implement the stakeholder identification part (first two subpractices) of GP 2.7 in full for all project-related process areas. Project Monitoring and Control: The part of the project monitoring and control process that implements Project Monitoring and Control SP 1.5, “Monitor Stakeholder Involvement,” can aid in implementing the third subpractice of GP 2.7 for all project-related process areas. Integrated Project Management: The part of the integrated project management process that implements Integrated Project Management SP 2.1, “Manage Stakeholder Involvement,” can aid in implementing the third subpractice of GP 2.7 for all project-related process areas.	GP 2.7 applied to the project planning process covers the involvement of relevant stakeholders in project planning activities. GP 2.7 applied to the project monitoring and control process covers the involvement of relevant stakeholders in project monitoring and control activities. GP 2.7 applied to the integrated project management process covers the involvement of relevant stakeholders in integrated project management activities.
GP 2.8 Monitor and Control the Process	Project Monitoring and Control: The project monitoring and control process can implement GP 2.8 in full for all project-related process areas. Measurement and Analysis: For all processes, not just project-related processes, the Measurement and Analysis process area provides general guidance about measuring, analyzing, and recording information that can be used in establishing measures for monitoring actual performance of the process.	GP 2.8 applied to the project monitoring and control process covers the monitoring and controlling of the project’s monitor and control activities.
GP 2.9 Objectively Evaluate Adherence	Process and Product Quality Assurance: The process and product quality assurance process can implement GP 2.9 in full for all process areas (except perhaps for Process and Product Quality Assurance itself).	GP 2.9 applied to the process and product quality assurance process covers the objective evaluation of quality assurance activities.
GP 2.10 Review Status with Higher Level Management	Project Monitoring and Control: The part of the project monitoring and control process that implements Project Monitoring and Control SP 1.6, “Conduct Progress Reviews,” and SP 1.7, “Conduct Milestone Reviews,” supports the implementation of GP 2.10 for all project-related process areas, perhaps in full, depending on higher level management involvement in these reviews.
GP 3.1 Establish a Defined Process	Integrated Project Management: The part of the integrated project management process that implements Integrated Project Management SP 1.1, “Establish and maintain the project’s defined process from project startup through the life of the project,” can implement GP 3.1 in full for all project-related process areas. Organizational Process Definition: For all processes, not just project-related processes, the organizational process definition process establishes the organizational process assets needed to implement GP 3.1.	GP 3.1 applied to the integrated project management process covers establishing defined processes for integrated project management activities.
GP 3.2 Collect Improvement Information	Integrated Project Management: The part of the integrated project management process that implements Integrated Project Management SP 1.6, “Contribute work products, measures, and documented experiences to the organizational process assets,” can implement GP 3.2 in part or full for all project-related process areas. Organizational Process Focus: The part of the organizational process focus process that implements Organizational Process Focus SP 3.4, “Incorporate process-related work products, measures, and improvement information derived from planning and performing the process into the organizational process assets,” can implement GP 3.2 in part or full for all process areas. Organizational Process Definition: For all processes, the organizational process definition process establishes the organizational process assets needed to implement GP 3.2.	GP 3.2 applied to the integrated project management process covers collecting improvement information derived from planning and performing integrated project management activities.
GP 4.1 Establish Quantitative Objectives for the Process	Quantitative Project Management: The part of the quantitative project management process that implements Quantitative Project Management SP 1.1, “Establish and maintain the project’s quality and process-performance objectives,” supports the implementation of GP 4.1 for all project-related process areas by providing objectives from which the objectives for each particular process can be derived. If these objectives become established as part of implementing subpractices 5 and 8 of Quantitative Project Management SP 1.1, then the quantitative project management process implements GP 4.1 in full. Organizational Process Performance:The part of the organizational process performance process that implements Organizational Process Performance SP 1.3, “Establish and maintain quantitative objectives for quality and process performance for the organization,” supports the implementation of GP 4.1 for all process areas.	GP 4.1 applied to the quantitative project management process covers establishing quantitative objectives for quantitative project management activities. GP 4.1 applied to the organizational process performance process covers establishing quantitative objectives for organizational process-performance activities.
GP 4.2 Stabilize Subprocess Performance	Quantitative Project Management: The part of the quantitative project management process that implements Quantitative Project Management SG 2, “Statistically Manage Subprocess Performance,” can implement GP 4.2 in full for all project-related process areas to which a statistically managed subprocess can be mapped. Organizational Process Performance: For all processes, not just project-related processes, the organizational process performance process establishes organizational process assets that may be needed to implement GP 4.2.	GP 4.2 applied to the quantitative project management process covers the stabilization of selected subprocesses within quantitative project management activities.
GP 5.1 Ensure Continuous Process Improvement	Organizational Innovation and Deployment: The organizational innovation and deployment process can implement GP 5.1 in full for all process areas providing that quality and process-performance objectives for the organization have been defined. (The latter would be the case, say, if the Organizational Process Performance process area has been implemented.)	GP 5.1 applied to the organizational innovation and deployment process covers ensuring continuous process improvement of organizational innovation and deployment activities.
GP 5.2 Correct Root Causes of Problems	Causal Analysis and Resolution: The causal analysis and resolution process can implement GP 5.2 in full for all project-related process areas.	GP 5.2 applied to the causal analysis and resolution process covers identifying root causes of defects and other problems in causal analysis and resolution activities.

Given
the dependencies that generic practices have on these process areas,
and given the more “holistic” view that many of these process
areas provide, these process areas are often implemented early, in
whole or in part, before or concurrent with implementing the
associated generic practices.

There
are also a few situations where the result of applying a generic
practice to a particular process area would seem to make a whole
process area redundant, but, in fact, it does not. It may be natural
to think that applying GP 3.1, Establish a Defined Process, to the
Project Planning and Project Monitoring and Control process areas
gives the same effect as the first specific goal of Integrated
Project Management, “The project is conducted using a defined
process that is tailored from the organization’s set of standard
processes.”

Although
it is true that there is some overlap, the application of the generic
practice to these two process areas provides defined processes
covering project planning and project monitoring and control
activities. These defined processes do not necessarily cover support
activities (such as configuration management), other project
management processes (such as supplier agreement management), or the
engineering processes. In contrast, the project’s defined process,
provided by the Integrated Project Management process area, covers
all appropriate project management, engineering, and support
processes.

Causal Analysis and
Resolution

A
Support Process Area at Maturity Level 5

Purpose

The
purpose of Causal Analysis and Resolution (CAR) is to identify causes
of defects and other problems and take action to prevent them from
occurring in the future.

Introductory Notes

The
Causal Analysis and Resolution process area involves the following:

• 
  Identifying
  and analyzing causes of defects and other problems

  
  

• 
  Taking
  specific actions to remove the causes and prevent the occurrence of
  those types of defects and problems in the future

  
  

Causal
analysis and resolution improves quality and productivity by
preventing the introduction of defects into a product. Reliance on
detecting defects after they have been introduced is not cost
effective. It is more effective to prevent defects from being
introduced by integrating causal analysis and resolution activities
into each phase of the project.

Since
defects and problems may have been previously encountered on other
projects or in earlier phases or tasks of the current project, causal
analysis and resolution activities are a mechanism for communicating
lessons learned among projects.

The
types of defects and other problems encountered are analyzed to
identify any trends. Based on an understanding of the defined process
and how it is implemented, the root causes of the defects and the
future implications of the defects are determined.

Causal
analysis may also be performed on problems unrelated to defects. For
example, causal analysis may be used to improve quality attributes
such as cycle time. Improvement proposals, simulations, dynamic
systems models, engineering analyses, new business directives, or
other items may initiate such analysis.

When
it is impractical to perform causal analysis on all defects, defect
targets are selected by tradeoffs on estimated investments and
estimated returns of quality, productivity and cycle time.

A
measurement process should already be in place. The defined measures
can be used, though in some instances new measures may be needed to
analyze the effects of the process change.

Refer
to the Measurement and Analysis process area for more information
about establishing objectives for measurement and analysis,
specifying the measures and analyses to be performed, obtaining and
analyzing measures, and reporting results.

Causal
Analysis and Resolution activities provide a mechanism for projects
to evaluate their processes at the local level and look for
improvements that can be implemented.

When
improvements are judged to be effective, the information is extended
to the organizational level.

Refer
to the Organizational Innovation and Deployment process area for more
information about improving organizational level processes through
proposed improvements and action proposals.

The
informative material in this process area is written with the
assumption that the specific practices are applied to a
quantitatively managed process. The specific practices of this
process area may be applicable, but with reduced value, if this
assumption is not met.

See
the definitions of “stable process” and “common cause of
process variation” in the glossary.

Related Process
Areas

Refer
to the Quantitative Project Management process area for more
information about the analysis of process performance and the
creation of process capability measures for selected project
processes.

Refer
to the Organizational Innovation and Deployment process area for more
information about the selection and deployment of improvements to
organizational processes and technologies.

Refer
to the Measurement and Analysis process area for more information
about establishing objectives for measurement and analysis,
specifying the measures and analyses to be performed, obtaining and
analyzing measures, and reporting results.

Specific Goal and
Practice Summary

SG 1 Determine Causes of
Defects

SP 1.1 Select Defect Data
for Analysis

SP 1.2 Analyze Causes

SG 2 Address Causes of
Defects

SP 2.1 Implement the
Action Proposals

SP 2.2 Evaluate the
Effect of Changes

SP 2.3 Record Data

Specific Practices
by Goal

SG 1 Determine Causes
of Defects

Root causes of defects and other
problems are systematically determined.

A
root cause is a source of a defect such that, if it is removed, the
defect is decreased or removed.

SP 1.1 Select Defect
Data for Analysis

Select the defects and other
problems for analysis.

Typical
Work Products

1. Defect
and problem data selected for further analysis

Subpractices

1. Gather
relevant defect or problem data.

Examples
of relevant defect data may include the following:

• 
  Defects reported
  by the customer

  
  

• 
  Defects reported
  by end users

  
  

• 
  Defects found in
  peer reviews

  
  

• 
  Defects found in
  testing

  
  

Examples
of relevant problem data may include the following:

• 
  Project
  management problem reports requiring corrective action

  
  

• 
  Process
  capability problems

  
  

• 
  Process duration
  measurements

  
  

• 
  Earned value
  measurements by process (e.g., cost performance index)

  
  

• 
  Resource
  throughput, utilization, or response time measurements

  
  

Refer
to the Verification process area for more information about work
product verification.

Refer
to the Quantitative Project Management process area for more
information about statistical management.

2. Determine
which defects and other problems will be analyzed further.

When
determining which defects to analyze further, consider the impact of
the defects, their frequency of occurrence, the similarity between
defects, the cost of analysis, the time and resources needed, the
safety considerations, etc.

Examples
of methods for selecting defects and other problems include the
following:

• 
  Pareto analysis

  
  

• 
  Histograms

  
  

• 
  Process
  capability analysis

  
  

SP 1.2 Analyze Causes

Perform causal analysis of
selected defects and other problems and propose actions to address
them.

The
purpose of this analysis is to develop solutions to the identified
problems by analyzing the relevant data and producing action
proposals for implementation.

Typical
Work Products

1. Action
proposal

Subpractices

1. Conduct
causal analysis with the people who are responsible for performing
the task.

Causal
analysis is performed, typically in meetings, with those people who
have an understanding of the selected defect or problem under study.
The people who have the best understanding of the selected defect are
typically those responsible for performing the task.

Examples
of when to perform causal analysis include the following:

• 
  When a stable
  process does not meet its specified quality and process-performance
  objectives

  
  

• 
  During the task,
  if and when problems warrant a causal analysis meeting

  
  

• 
  When a work
  product exhibits an unexpected deviation from its requirements

  
  

Refer
to the Quantitative Project Management process area for more
information about achieving the project’s quality and
process-performance objectives.

2. Analyze
selected defects and other problems to determine their root causes.

Depending
on the type and number of defects, it may make sense to first group
the defects before identifying their root causes.

Examples
of methods to determine root causes include the following:

• 
  Cause-and-effect
  (fishbone) diagrams

  
  

• 
  Check sheets

  
  

3. Group
the selected defects and other problems based on their root causes.

Examples
of cause groups, or categories, include the following:

• 
  Inadequate
  training

  
  

• 
  Breakdown of
  communications

  
  

• 
  Not accounting
  for all details of a task

  
  

• 
  Making mistakes
  in manual procedures (e.g., typing)

  
  

• 
  Process
  deficiency

  
  

4. Propose
and document actions that need to be taken to prevent the future
occurrence of similar defects or other problems.

Examples
of proposed actions include changes to the following:

• 
  The process in
  question

  
  

• 
  Training

  
  

• 
  Tools

  
  

• 
  Methods

  
  

• 
  Communications

  
  

• 
  Work products

  
  

Examples
of specific actions include the following:

• 
  Providing
  training in common problems and techniques for preventing them

  
  

• 
  Changing a
  process so that error-prone steps do not occur

  
  

• 
  Automating all or
  part of a process

  
  

• 
  Reordering
  process activities

  
  

• 
  Adding process
  steps to prevent defects, such as task kickoff meetings to review
  common defects and actions to prevent them

  
  

An
action proposal usually documents the following:

• 
  Originator of the
  action proposal

  
  

• 
  Description of
  the problem

  
  

• 
  Description of
  the defect cause

  
  

• 
  Defect cause
  category

  
  

• 
  Phase when the
  problem was introduced

  
  

• 
  Phase when the
  defect was identified

  
  

• 
  Description of
  the action proposal

  
  

• 
  Action proposal
  category

  
  

SG 2 Address Causes of
Defects

Root causes of defects and other
problems are systematically addressed to prevent their future
occurrence.

Projects
operating according to a well-defined process will systematically
analyze the operation where problems still occur and implement
process changes to eliminate root causes of selected problems.

SP 2.1 Implement the
Action Proposals

Implement the selected action
proposals that were developed in causal analysis.

Action
proposals describe the tasks necessary to remove the root causes of
the analyzed defects or problems and avoid their reoccurrence.

Only
changes that prove to be of value should be considered for broad
implementation.

Typical
Work Products

1. Action
proposals selected for implementation

2. Improvement
proposals

Subpractices

1. Analyze
the action proposals and determine their priorities.

Criteria
for prioritizing action proposals include the following:

• 
  Implications of
  not addressing the defects

  
  

• 
  Cost to implement
  process improvements to prevent the defects

  
  

• 
  Expected impact
  on quality

  
  

2. Select
the action proposals that will be implemented.

3. Create
action items for implementing the action proposals.

Examples
of information provided in an action item include the following:

• 
  Person
  responsible for implementing it

  
  

• 
  Description of
  the areas affected by it

  
  

• 
  People who are to
  be kept informed of its status

  
  

• 
  Next date that
  status will be reviewed

  
  

• 
  Rationale for key
  decisions

  
  

• 
  Description of
  implementation actions

  
  

• 
  Time and cost for
  identifying the defect and correcting it

  
  

• 
  Estimated cost of
  not fixing the problem

  
  

To
implement the action proposals, the following tasks must be done:

• 
  Make assignments

  
  

• 
  Coordinate the
  persons doing the work

  
  

• 
  Review the
  results

  
  

• 
  Track the action
  items to closure

  
  

Experiments
may be conducted for particularly complex changes.

Examples
of experiments include the following:

• 
  Using a
  temporarily modified process

  
  

• 
  Using a new tool

  
  

Action
items may be assigned to members of the causal analysis team, members
of the project team, or other members of the organization.

4. Identify
and remove similar defects that may exist in other processes and work
products.

5. Identify
and document improvement proposals for the organization’s set of
standard processes.

Refer
to the Organizational Innovation and Deployment process area for more
information about the selection and deployment of improvement
proposals for the organization’s set of standard processes.

SP 2.2 Evaluate the
Effect of Changes

Evaluate the effect of changes
on process performance.

Refer
to the Quantitative Project Management process area for more
information about analyzing process performance and creating process
capability measures for selected processes.

Once
the changed process is deployed across the project, the effect of the
changes must be checked to gather evidence that the process change
has corrected the problem and improved performance.

Typical
Work Products

1. Measures
of performance and performance change

Subpractices

1. Measure
the change in the performance of the project’s defined process as
appropriate.

This
subpractice determines whether the selected change has positively
influenced the process performance and by how much.

An
example of a change in the performance of the project’s defined
design process would be the change in the defect density of the
design documentation, as statistically measured through peer reviews
before and after the improvement has been made. On a statistical
process control chart, this would be represented by a change in the
mean.

2. Measure
the capability of the project’s defined process as appropriate.

This
subpractice determines whether the selected change has positively
influenced the ability of the process to meet its quality and
process-performance objectives, as determined by relevant
stakeholders.

An
example of a change in the capability of the project’s defined
design process would be a change in the ability of the process to
stay within its process-specification boundaries. This can be
statistically measured by calculating the range of the defect density
of design documentation, as collected in peer reviews before and
after the improvement has been made. On a statistical process control
chart, this would be represented by lowered control limits.

SP 2.3 Record Data

Record causal analysis and
resolution data for use across the project and organization.

Data
are recorded so that other projects and organizations can make
appropriate process changes and achieve similar results.

Record
the following:

• 
  Data
  on defects and other problems that were analyzed

  
  

• 
  Rationale
  for decisions

  
  

• 
  Action
  proposals from causal analysis meetings

  
  

• 
  Action
  items resulting from action proposals

  
  

• 
  Cost
  of the analysis and resolution activities

  
  

• 
  Measures
  of changes to the performance of the defined process resulting from
  resolutions

  
  

Typical
Work Products

1. Causal
analysis and resolution records

Generic Practices
by Goal

Continuous Only

GG 1 Achieve Specific Goals The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products. GP 1.1 Perform Specific Practices Perform the specific practices of the causal analysis and resolution process to develop work products and provide services to achieve the specific goals of the process area. GG 2 Institutionalize a Managed Process The process is institutionalized as a managed process.

Staged Only
GG 3 Institutionalize a Defined Process The process is institutionalized as a defined process. This generic goal’s appearance here reflects its location in the staged representation.

GP 2.1 Establish an
Organizational Policy

Establish and maintain an
organizational policy for planning and performing the causal analysis
and resolution process.

Elaboration:

This
policy establishes organizational expectations for identifying and
systematically addressing root causes of defects and other problems.

GP 2.2 Plan the
Process

Establish and maintain the plan
for performing the causal analysis and resolution process.

Elaboration:

This
plan for performing the causal analysis and resolution process can be
included in (or referenced by) the project plan, which is described
in the Project Planning process area. This plan differs from the
action proposals and associated action items described in several
specific practices in this process area. The plan called for in this
generic practice would address the project’s overall causal
analysis and resolution process (perhaps tailored from a standard
process maintained by the organization). In contrast, the process
action proposals and associated action items address the activities
needed to remove a specific root cause under study.

GP 2.3 Provide
Resources

Provide adequate resources for
performing the causal analysis and resolution process, developing the
work products, and providing the services of the process.

Elaboration:

Examples
of resources provided include the following tools:

• 
  Database
  systems

  
  

• 
  Process
  modeling tools

  
  

• 
  Statistical
  analysis packages

  
  

• 
  Tools,
  methods, and analysis techniques (e.g., Ishikawa or fishbone
  diagram, Pareto analysis, histograms, process capability studies, or
  control charts)

  
  

GP 2.4 Assign
Responsibility

Assign responsibility and
authority for performing the process, developing the work products,
and providing the services of the causal analysis and resolution
process.

GP 2.5 Train People

Train the people performing or
supporting the causal analysis and resolution process as needed.

Elaboration:

Examples
of training topics include the following:

• 
  Quality
  management methods (e.g., root cause analysis)

  
  

GP 2.6 Manage
Configurations

Place designated work products
of the causal analysis and resolution process under appropriate
levels of control.

Elaboration:

Examples
of work products placed under control include the following:

• 
  Action
  proposals

  
  

• 
  Action
  proposals selected for implementation

  
  

• 
  Causal
  analysis and resolution records

  
  

GP 2.7 Identify and
Involve Relevant Stakeholders

Identify and involve the
relevant stakeholders of the causal analysis and resolution process
as planned.

Elaboration:

Examples
of activities for stakeholder involvement include the following:

• 
  Conducting
  causal analysis

  
  

• 
  Assessing
  the action proposals

  
  

GP 2.8 Monitor and
Control the Process

Monitor and control the causal
analysis and resolution process against the plan for performing the
process and take appropriate corrective action.

Elaboration:

Examples
of measures and work products used in monitoring and controlling
include the following:

• 
  Number
  of root causes removed

  
  

• 
  Change
  in quality or process performance per instance of the causal
  analysis and resolution process

  
  

• 
  Schedule
  of activities for implementing a selected action proposal

  
  

GP 2.9 Objectively
Evaluate Adherence

Objectively evaluate adherence
of the causal analysis and resolution process against its process
description, standards, and procedures, and address noncompliance.

Elaboration:

Examples
of activities reviewed include the following:

• 
  Determining
  causes of defects

  
  

• 
  Addressing
  causes of defects

  
  

Examples
of work products reviewed include the following:

• 
  Action
  proposals selected for implementation

  
  

• 
  Causal
  analysis and resolution records

  
  

GP 2.10 Review Status
with Higher Level Management

Review the activities, status,
and results of the causal analysis and resolution process with higher
level management and resolve issues.

Continuous Only
GG 3 Institutionalize a Defined Process The process is institutionalized as a defined process. This generic goal’s appearance here reflects its location in the continuous representation.

GP 3.1 Establish a
Defined Process

Establish and maintain the
description of a defined causal analysis and resolution process.

GP 3.2 Collect
Improvement Information

Collect work products, measures,
measurement results, and improvement information derived from
planning and performing the causal analysis and resolution process to
support the future use and improvement of the organization’s
processes and process assets.

Elaboration:

Examples
of work products, measures, measurement results, and improvement
information include the following:

• 
  Action
  proposals

  
  

• 
  Number
  of action proposals that are open and for how long

  
  

• 
  Action
  proposal status reports

  
  

Continuous Only

GG 4 Institutionalize a Quantitatively Managed Process The process is institutionalized as a quantitatively managed process. GP 4.1 Establish Quantitative Objectives for the Process Establish and maintain quantitative objectives for the causal analysis and resolution process, which address quality and process performance, based on customer needs and business objectives. GP 4.2 Stabilize Subprocess Performance Stabilize the performance of one or more subprocesses to determine the ability of the causal analysis and resolution process to achieve the established quantitative quality and process-performance objectives. GG 5 Institutionalize an Optimizing Process The process is institutionalized as an optimizing process. GP 5.1 Ensure Continuous Process Improvement Ensure continuous improvement of the causal analysis and resolution process in fulfilling the relevant business objectives of the organization. GP 5.2 Correct Root Causes of Problems Identify and correct the root causes of defects and other problems in the causal analysis and resolution process.

Configuration
Management

A
Support Process Area at Maturity Level 2

Purpose

The
purpose of Configuration Management (CM) is to establish and maintain
the integrity of work products using configuration identification,
configuration control, configuration status accounting, and
configuration audits.

Introductory Notes

The
Configuration Management process area involves the following:

• 
  Identifying
  the configuration of selected work products that compose the
  baselines at given points in time

  
  

• 
  Controlling
  changes to configuration items

  
  

• 
  Building
  or providing specifications to build work products from the
  configuration management system

  
  

• 
  Maintaining
  the integrity of baselines

  
  

• 
  Providing
  accurate status and current configuration data to developers, end
  users, and customers

  
  

The
work products placed under configuration management include the
products that are delivered to the customer, designated internal work
products, acquired products, tools, and other items that are used in
creating and describing these work products. (See the definition of
“configuration management” in the glossary.)

Acquired
products may need to be placed under configuration management by both
the supplier and the project. Provisions for conducting configuration
management should be established in supplier agreements. Methods to
ensure that the data is complete and consistent should be established
and maintained.

Refer
to the Supplier Agreement Management process area for more
information about establishing and maintaining agreements with
suppliers.

Examples
of work products that may be placed under configuration management
include the following:

• 
  Plans

  
  

• 
  Process
  descriptions

  
  

• 
  Requirements

  
  

• 
  Design
  data

  
  

• 
  Drawings

  
  

• 
  Product
  specifications

  
  

• 
  Code

  
  

• 
  Compilers

  
  

• 
  Product
  data files

  
  

• 
  Product
  technical publications

  
  

Configuration
management of work products may be performed at several levels of
granularity. Configuration items can be decomposed into configuration
components and configuration units. Only the term “configuration
item” is used in this process area. Therefore, in these practices,
“configuration item” may be interpreted as “configuration
component” or “configuration unit” as appropriate. (See the
definition of “configuration item” in the glossary.)

Baselines
provide a stable basis for continuing evolution of configuration
items.

An
example of a baseline is an approved description of a product that
includes internally consistent versions of requirements, requirement
traceability matrices, design, discipline-specific items, and
end-user documentation.

Baselines
are added to the configuration management system as they are
developed. Changes to baselines and the release of work products
built from the configuration management system are systematically
controlled and monitored via the configuration control, change
management, and configuration auditing functions of configuration
management.

This
process area applies not only to configuration management on
projects, but also to configuration management on organizational work
products such as standards, procedures, and reuse libraries.

Configuration
management is focused on the rigorous control of the managerial and
technical aspects of work products, including the delivered system.

This
process area covers the practices for performing the configuration
management function and is applicable to all work products that are
placed under configuration management.

Related Process
Areas

Refer
to the Project Planning process area for information on developing
plans and work breakdown structures, which may be useful for
determining configuration items.

Refer
to the Project Monitoring and Control process area for more
information about performance analyses and corrective actions.

Specific Goal and
Practice Summary

SG 1 Establish Baselines

SP 1.1 Identify
Configuration Items

SP 1.2 Establish a
Configuration Management System

SP 1.3 Create or Release
Baselines

SG 2 Track and Control
Changes

SP 2.1 Track Change
Requests

SP 2.2 Control
Configuration Items

SG 3 Establish Integrity

SP 3.1 Establish
Configuration Management Records

SP 3.2 Perform
Configuration Audits

Specific Practices
by Goal

SG 1 Establish
Baselines

Baselines of identified work
products are established.

Specific
practices to establish baselines are covered by this specific goal.
The specific practices under the Track and Control Changes specific
goal serve to maintain the baselines. The specific practices of the
Establish Integrity specific goal document and audit the integrity of
the baselines.

SP 1.1 Identify
Configuration Items

Identify the configuration
items, components, and related work products that will be placed
under configuration management.

Configuration
identification is the selection, creation, and specification of the
following:

• 
  Products
  that are delivered to the customer

  
  

• 
  Designated
  internal work products

  
  

• 
  Acquired
  products

  
  

• 
  Tools
  and other capital assets of the project’s work environment

  
  

• 
  Other
  items that are used in creating and describing these work products

  
  

Items
under configuration management will include specifications and
interface documents that define the requirements for the product.
Other documents, such as test results, may also be included,
depending on their criticality to defining the product.

A
“configuration item” is an entity designated for configuration
management, which may consist of multiple related work products that
form a baseline. This logical grouping provides ease of
identification and controlled access. The selection of work products
for configuration management should be based on criteria established
during planning.

Typical
Work Products

1. Identified
configuration items

Subpractices

1. Select
the configuration items and the work products that compose them based
on documented criteria.

Example
criteria for selecting configuration items at the appropriate work
product level include the following:

• 
  Work products
  that may be used by two or more groups

  
  

• 
  Work products
  that are expected to change over time either because of errors or
  change of requirements

  
  

• 
  Work products
  that are dependent on each other in that a change in one mandates a
  change in the others

  
  

• 
  Work products
  that are critical for the project

  
  

Examples
of work products that may be part of a configuration item include the
following:

• 
  Process
  descriptions

  
  

• 
  Requirements

  
  

• 
  Design

  
  

• 
  Test plans and
  procedures

  
  

• 
  Test results

  
  

• 
  Interface
  descriptions

  
  

• 
  Drawings

  
  

• 
  Source code

  
  

• 
  Tools (e.g.,
  compilers)

  
  

2. Assign
unique identifiers to configuration items.

3. Specify
the important characteristics of each configuration item.

Example
characteristics of configuration items include author, document or
file type, and programming language for software code files.

4. Specify
when each configuration item is placed under configuration
management.

Example
criteria for determining when to place work products under
configuration management include the following:

• 
  Stage of the
  project lifecycle

  
  

• 
  When the work
  product is ready for test

  
  

• 
  Degree of control
  desired on the work product

  
  

• 
  Cost and schedule
  limitations

  
  

• 
  Customer
  requirements

  
  

5. Identify
the owner responsible for each configuration item.

SP 1.2 Establish a
Configuration Management System

Establish and maintain a
configuration management and change management system for controlling
work products.

A
configuration management system includes the storage media, the
procedures, and the tools for accessing the configuration system.

A
change management system includes the storage media, the procedures,
and tools for recording and accessing change requests.

Typical
Work Products

1. Configuration
management system with controlled work products

2. Configuration
management system access control procedures

3. Change
request database

Subpractices

1. Establish
a mechanism to manage multiple control levels of configuration
management.

The
level of control is typically selected based on project objectives,
risk, and/or resources. Control levels may vary in relation to the
project lifecycle, type of system under development, and specific
project requirements.

Example
levels of control include the following:

• 
  Create –
  controlled by author

  
  

• 
  Engineering –
  notification to relevant stakeholders when changes are made

  
  

• 
  Development –
  lower level CCB control

  
  

• 
  Formal – higher
  level CCB control with customer involvement

  
  

Levels
of control can range from informal control that simply tracks changes
made when the configuration items are being developed to formal
configuration control using baselines that can only be changed as
part of a formal configuration management process.

2. Store
and retrieve configuration items in a configuration management
system.

Examples
of configuration management systems include the following:

• 
  Dynamic (or
  author’s) systems contain components currently being created or
  revised. They are in the author’s workspace and are controlled by
  the author. Configuration items in a dynamic system are under
  version control.

  
  

• 
  Master (or
  controlled) systems contain current baselines and changes to them.
  Configuration items in a master system are under full configuration
  management as described in this process area.

  
  

• 
  Static systems
  contain archives of various baselines released for use. Static
  systems are under full configuration management as described in this
  process area.

  
  

3. Share
and transfer configuration items between control levels within the
configuration management system.

4. Store
and recover archived versions of configuration items.

5. Store,
update, and retrieve configuration management records.

6. Create
configuration management reports from the configuration management
system.

7. Preserve
the contents of the configuration management system.

Examples
of preservation functions of the configuration management system
include the following:

• 
  Backups and
  restoration of configuration management files

  
  

• 
  Archiving of
  configuration management files

  
  

• 
  Recovery from
  configuration management errors

  
  

8. Revise
the configuration management structure as necessary.

SP 1.3 Create or
Release Baselines

Create or release baselines for
internal use and for delivery to the customer.

A
baseline is a set of specifications or work products that has been
formally reviewed and agreed on, that thereafter serves as the basis
for further development or delivery, and that can be changed only
through change control procedures. A baseline represents the
assignment of an identifier to a configuration item or a collection
of configuration items and associated entities. As a product evolves,
several baselines may be used to control its development and testing.

For Systems
Engineering

One common set of
baselines includes the system-level requirements,
system-element-level design requirements, and the product definition
at the end of development/beginning of production. These are
typically referred to as the “functional baseline,” “allocated
baseline,” and “product baseline.”

For Software
Engineering

A software baseline
can be a set of requirements, design, source code files and the
associated executable code, build files, and user documentation
(associated entities) that have been assigned a unique identifier.

Typical
Work Products

1. Baselines

2. Description
of baselines

Subpractices

1. Obtain
authorization from the configuration control board (CCB) before
creating or releasing baselines of configuration items.

2. Create
or release baselines only from configuration items in the
configuration management system.

3. Document
the set of configuration items that are contained in a baseline.

4. Make
the current set of baselines readily available.

SG 2 Track and Control
Changes

Changes to the work products
under configuration management are tracked and controlled.

The
specific practices under this specific goal serve to maintain the
baselines after they are established by the specific practices under
the Establish Baselines specific goal.

SP 2.1 Track Change
Requests

Track change requests for the
configuration items.

Change
requests address not only new or changed requirements, but also
failures and defects in the work products.

Change
requests are analyzed to determine the impact that the change will
have on the work product, related work products, budget, and
schedule.

Typical
Work Products

1. Change
requests

Subpractices

1. Initiate
and record change requests in the change request database.

2. Analyze
the impact of changes and fixes proposed in the change requests.

Changes
are evaluated through activities that ensure that they are consistent
with all technical and project requirements.

Changes
are evaluated for their impact beyond immediate project or contract
requirements. Changes to an item used in multiple products can
resolve an immediate issue while causing a problem in other
applications.

3. Review
change requests that will be addressed in the next baseline with the
relevant stakeholders and get their agreement.

Conduct
the change request review with appropriate participants. Record the
disposition of each change request and the rationale for the
decision, including success criteria, a brief action plan if
appropriate, and needs met or unmet by the change. Perform the
actions required in the disposition, and report the results to
relevant stakeholders.

4. Track
the status of change requests to closure.

Change
requests brought into the system need to be handled in an efficient
and timely manner. Once a change request has been processed, it is
critical to close the request with the appropriate approved action as
soon as it is practical. Actions left open result in larger than
necessary status lists, which in turn result in added costs and
confusion.

SP 2.2 Control
Configuration Items

Control changes to the
configuration items.

Control
is maintained over the configuration of the work product baseline.
This control includes tracking the configuration of each of the
configuration items, approving a new configuration if necessary, and
updating the baseline.

Typical
Work Products

1. Revision
history of configuration items

2. Archives
of the baselines

Subpractices

1. Control
changes to configuration items throughout the life of the product.

2. Obtain
appropriate authorization before changed configuration items are
entered into the configuration management system.

For
example, authorization may come from the CCB, the project manager, or
the customer.

3. Check
in and check out configuration items from the configuration
management system for incorporation of changes in a manner that
maintains the correctness and integrity of the configuration items.

Examples
of check-in and check-out steps include the following:

• 
  Confirming that
  the revisions are authorized

  
  

• 
  Updating the
  configuration items

  
  

• 
  Archiving the
  replaced baseline and retrieving the new baseline

  
  

4. Perform
reviews to ensure that changes have not caused unintended effects on
the baselines (e.g., ensure that the changes have not compromised the
safety and/or security of the system).

5. Record
changes to configuration items and the reasons for the changes as
appropriate.

If
a proposed change to the work product is accepted, a schedule is
identified for incorporating the change into the work product and
other affected areas.

Configuration
control mechanisms can be tailored to categories of changes. For
example, the approval considerations could be less stringent for
component changes that do not affect other components.

Changed
configuration items are released after review and approval of
configuration changes. Changes are not official until they are
released.

SG 3 Establish
Integrity

Integrity of baselines is
established and maintained.

The
integrity of the baselines, established by processes associated with
the Establish Baselines specific goal, and maintained by processes
associated with the Track and Control Changes specific goal, is
provided by the specific practices under this specific goal.

SP 3.1 Establish
Configuration Management Records

Establish and maintain records
describing configuration items.

Typical
Work Products

1. Revision
history of configuration items

2. Change
log

3. Copy
of the change requests

4. Status
of configuration items

5. Differences
between baselines

Subpractices

1. Record
configuration management actions in sufficient detail so the content
and status of each configuration item is known and previous versions
can be recovered.

2. Ensure
that relevant stakeholders have access to and knowledge of the
configuration status of the configuration items.

Examples
of activities for communicating configuration status include the
following:

• 
  Providing access
  permissions to authorized end users

  
  

• 
  Making baseline
  copies readily available to authorized end users

  
  

3. Specify
the latest version of the baselines.

4. Identify
the version of configuration items that constitute a particular
baseline.

5. Describe
the differences between successive baselines.

6. Revise
the status and history (i.e., changes and other actions) of each
configuration item as necessary.

SP 3.2 Perform
Configuration Audits

Perform configuration audits to
maintain integrity of the configuration baselines.

Configuration
audits confirm that the resulting baselines and documentation conform
to a specified standard or requirement. Audit results should be
recorded as appropriate. (See the glossary for a definition of
“configuration audit.”)

Examples
of audit types include the following:

• 
  Functional
  Configuration Audits (FCA) – Audits conducted to verify that the
  as-tested functional characteristics of a configuration item have
  achieved the requirements specified in its functional baseline
  documentation and that the operational and support documentation is
  complete and satisfactory.

  
  

• 
  Physical
  Configuration Audit (PCA) – Audits conducted to verify that the
  as-built configuration item conforms to the technical documentation
  that defines it.

  
  

• 
  Configuration
  management audits – Audits conducted to confirm that configuration
  management records and configuration items are complete, consistent,
  and accurate.

  
  

Typical
Work Products

1. Configuration
audit results

2. Action
items

Subpractices

1. Assess
the integrity of the baselines.

2. Confirm
that the configuration management records correctly identify the
configuration items.

3. Review
the structure and integrity of the items in the configuration
management system.

4. Confirm
the completeness and correctness of the items in the configuration
management system.

Completeness
and correctness of the content is based on the requirements as stated
in the plan and the disposition of approved change requests.

5. Confirm
compliance with applicable configuration management standards and
procedures.

6. Track
action items from the audit to closure.

Generic Practices
by Goal

Continuous Only

GG 1 Achieve Specific Goals The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products. GP 1.1 Perform Specific Practices Perform the specific practices of the configuration management process to develop work products and provide services to achieve the specific goals of the process area.

GG 2 Institutionalize
a Managed Process

The process is institutionalized
as a managed process.

GP 2.1 Establish an
Organizational Policy

Establish and maintain an
organizational policy for planning and performing the configuration
management process.

Elaboration:

This
policy establishes organizational expectations for establishing and
maintaining baselines, tracking and controlling changes to the work
products (under configuration management), and establishing and
maintaining integrity of the baselines.

GP 2.2 Plan the
Process

Establish and maintain the plan
for performing the configuration management process.

Elaboration:

This
plan for performing the configuration management process can be
included in (or referenced by) the project plan, which is described
in the Project Planning process area.

GP 2.3 Provide
Resources

Provide adequate resources for
performing the configuration management process, developing the work
products, and providing the services of the process.

Elaboration:

Examples
of resources provided include the following tools:

• 
  Configuration
  management tools

  
  

• 
  Data
  management tools

  
  

• 
  Archiving
  and reproduction tools

  
  

• 
  Database
  programs

  
  

GP 2.4 Assign
Responsibility

Assign responsibility and
authority for performing the process, developing the work products,
and providing the services of the configuration management process.

GP 2.5 Train People

Train the people performing or
supporting the configuration management process as needed.

Elaboration:

Examples
of training topics include the following:

• 
  Roles,
  responsibilities, and authority of the configuration management
  staff

  
  

• 
  Configuration
  management standards, procedures, and methods

  
  

• 
  Configuration
  library system

  
  

GP 2.6 Manage
Configurations

Place designated work products
of the configuration management process under appropriate levels of
control.

Elaboration:

Refer
to Table 6.2 on page 95 in Generic Goals and Generic Practices for
more information about the relationship between generic practice 2.6
and the Configuration Management process area.

Examples
of work products placed under control include the following:

• 
  Access
  lists

  
  

• 
  Change
  status reports

  
  

• 
  Change
  request database

  
  

• 
  CCB
  meeting minutes

  
  

• 
  Archived
  baselines

  
  

GP 2.7 Identify and
Involve Relevant Stakeholders

Identify and involve the
relevant stakeholders of the configuration management process as
planned.

Elaboration:

Examples
of activities for stakeholder involvement include the following:

• 
  Establishing
  baselines

  
  

• 
  Reviewing
  configuration management system reports and resolving issues

  
  

• 
  Assessing
  the impact of changes for the configuration items

  
  

• 
  Performing
  configuration audits

  
  

• 
  Reviewing
  the results of configuration management audits

  
  

GP 2.8 Monitor and
Control the Process

Monitor and control the
configuration management process against the plan for performing the
process and take appropriate corrective action.

Elaboration:

Examples
of measures and work products used in monitoring and controlling
include the following:

• 
  Number
  of changes to configuration items

  
  

• 
  Number
  of configuration audits conducted

  
  

• 
  Schedule
  of CCB or audit activities

  
  

GP 2.9 Objectively
Evaluate Adherence

Objectively evaluate adherence
of the configuration management process against its process
description, standards, and procedures, and address noncompliance.

Elaboration:

Examples
of activities reviewed include the following:

• 
  Establishing
  baselines

  
  

• 
  Tracking
  and controlling changes

  
  

• 
  Establishing
  and maintaining integrity of baselines

  
  

Examples
of work products reviewed include the following:

• 
  Archives
  of the baselines

  
  

• 
  Change
  request database

  
  

GP 2.10 Review Status
with Higher Level Management

Review the activities, status,
and results of the configuration management process with higher level
management and resolve issues.

Staged Only
GG3 and its practices do not apply for a maturity level 2 rating, but do apply for a maturity level 3 rating and above.

Continuous/Maturity Levels 3 - 5 Only

GG 3 Institutionalize a Defined Process The process is institutionalized as a defined process. GP 3.1 Establish a Defined Process Establish and maintain the description of a defined configuration management process. GP 3.2 Collect Improvement Information Collect work products, measures, measurement results, and improvement information derived from planning and performing the configuration management process to support the future use and improvement of the organization’s processes and process assets. Elaboration: Examples of work products, measures, measurement results, and improvement information include the following: Trends in the status of configuration items Configuration audit results Change request aging reports

Continuous Only

GG 4 Institutionalize a Quantitatively Managed Process The process is institutionalized as a quantitatively managed process. GP 4.1 Establish Quantitative Objectives for the Process Establish and maintain quantitative objectives for the configuration management process, which address quality and process performance, based on customer needs and business objectives. GP 4.2 Stabilize Subprocess Performance Stabilize the performance of one or more subprocesses to determine the ability of the configuration management process to achieve the established quantitative quality and process-performance objectives. GG 5 Institutionalize an Optimizing Process The process is institutionalized as an optimizing process. GP 5.1 Ensure Continuous Process Improvement Ensure continuous improvement of the configuration management process in fulfilling the relevant business objectives of the organization. GP 5.2 Correct Root Causes of Problems Identify and correct the root causes of defects and other problems in the configuration management process.

Decision Analysis
and Resolution

A
Support Process Area at Maturity Level 3

Purpose

The
purpose of Decision Analysis and Resolution (DAR) is to analyze
possible decisions using a formal evaluation process that evaluates
identified alternatives against established criteria.

Introductory Notes

The
Decision Analysis and Resolution process area involves establishing
guidelines to determine which issues should be subjected to a formal
evaluation process and then applying formal evaluation processes to
these issues.

A
formal evaluation process is a structured approach to evaluating
alternative solutions against established criteria to determine a
recommended solution to address an issue. A formal evaluation process
involves the following actions:

• 
  Establishing
  the criteria for evaluating alternatives

  
  

• 
  Identifying
  alternative solutions

  
  

• 
  Selecting
  methods for evaluating alternatives

  
  

• 
  Evaluating
  the alternative solutions using the established criteria and methods

  
  

• 
  Selecting
  recommended solutions from the alternatives based on the evaluation
  criteria

  
  

Rather
than using the phrase “alternative solutions to address issues”
each time it is needed, we will use one of two shorter phrases:
“alternative solutions” or “alternatives.”

A
formal evaluation process reduces the subjective nature of the
decision and has a higher probability of selecting a solution that
meets the multiple demands of relevant stakeholders.

While
the primary application of this process area is to technical
concerns, formal evaluation processes can also be applied to many
nontechnical issues, particularly when a project is being planned.
Issues that have multiple alternative solutions and evaluation
criteria lend themselves to a formal evaluation process.

Trade
studies of equipment or software are typical examples of formal
evaluation processes.

During
planning, specific issues requiring a formal evaluation process are
identified. Typical issues include selection among architectural or
design alternatives, use of reusable or commercial off-the-shelf
(COTS) components, supplier selection, engineering support
environments or associated tools, test environments, delivery
alternatives, and logistics and production. A formal evaluation
process can also be used to address a make-or-buy decision, the
development of manufacturing processes, the selection of distribution
locations, and other decisions.

Guidelines
are created for deciding when to use formal evaluation processes to
address unplanned issues. Guidelines often suggest using formal
evaluation processes when issues are associated with medium to high
risks or when issues affect the ability to achieve project
objectives.

Formal
evaluation processes can vary in formality, type of criteria, and
methods employed. Less formal decisions can be analyzed in a few
hours, use only a few criteria (e.g., effectiveness and cost to
implement), and result in a one- or two-page report. More formal
decisions may require separate plans, months of effort, meetings to
develop and approve criteria, simulations, prototypes, piloting, and
extensive documentation.

Both
numeric and non-numeric criteria can be used in a formal evaluation
process. Numeric criteria use weights to reflect the relative
importance of the criteria. Non-numeric criteria use a more
subjective ranking scale (e.g., high, medium, or low). More formal
decisions may require a full trade study.

A
formal evaluation process identifies and evaluates alternative
solutions. The eventual selection of a solution may involve iterative
activities of identification and evaluation. Portions of identified
alternatives may be combined, emerging technologies may change
alternatives, and the business situation of vendors may change during
the evaluation period.

A
recommended alternative is accompanied by documentation of the
selected methods, criteria, alternatives, and rationale for the
recommendation. The documentation is distributed to relevant
stakeholders; it provides a record of the formal evaluation process
and rationale that are useful to other projects that encounter a
similar issue.

While
some of the decisions made throughout the life of the project involve
the use of a formal evaluation process, others do not. As mentioned
earlier, guidelines should be established to determine which issues
should be subjected to a formal evaluation process.

Related Process
Areas

Refer
to the Project Planning process area for more information about
general planning for projects.

Refer
to the Integrated Project Management process area for more
information about establishing the project’s defined process. The
project’s defined process includes a formal evaluation process for
each selected issue and incorporates the use of guidelines for
applying a formal evaluation process to unforeseen issues.

Refer
to the Risk Management process area for more information about
identifying and mitigating risks. A formal evaluation process is
often used to address issues with identified medium or high risks.
Selected solutions typically affect risk mitigation plans.

Specific Goal and
Practice Summary

SG 1 Evaluate
Alternatives

SP 1.1 Establish
Guidelines for Decision Analysis

SP 1.2 Establish
Evaluation Criteria

SP 1.3 Identify
Alternative Solutions

SP 1.4 Select Evaluation
Methods

SP 1.5 Evaluate
Alternatives

SP 1.6 Select Solutions

Specific Practices
by Goal

SG 1 Evaluate
Alternatives

Decisions are based on an
evaluation of alternatives using established criteria.

Issues
requiring a formal evaluation process may be identified at any time.
The objective should be to identify issues as early as possible to
maximize the time available to resolve them.

SP 1.1 Establish
Guidelines for Decision Analysis

Establish and maintain
guidelines to determine which issues are subject to a formal
evaluation process.

Not
every decision is significant enough to require a formal evaluation
process. The choice between the trivial and the truly important will
be unclear without explicit guidance. Whether a decision is
significant or not is dependent on the project and circumstances, and
is determined by the established guidelines.

Typical
guidelines for determining when to require a formal evaluation
process include the following:

• 
  When
  a decision is directly related to topics assessed as being of medium
  or high risk

  
  

• 
  When
  a decision is related to changing work products under configuration
  management

  
  

• 
  When
  a decision would cause schedule delays over a certain percentage or
  specific amount of time

  
  

• 
  When
  a decision affects the ability to achieve project objectives

  
  

• 
  When
  the costs of the formal evaluation process are reasonable when
  compared to the decision’s impact

  
  

• 
  When
  a legal obligation exists during a solicitation

  
  

Refer
to the Risk Management process area for more information about
determining which issues are medium or high risk.

Examples
of when to use a formal evaluation process include the following:

• 
  On
  decisions involving the procurement of material when 20 percent of
  the material parts constitute 80 percent of the total material costs

  
  

• 
  On
  design-implementation decisions when technical performance failure
  may cause a catastrophic failure (e.g., safety of flight item)

  
  

• 
  On
  decisions with the potential to significantly reduce design risk,
  engineering changes, cycle time, response time, and production costs
  (e.g., to use lithography models to assess form and fit capability
  before releasing engineering drawings and production builds)

  
  

Typical
Work Products

1. Guidelines
for when to apply a formal evaluation process

Subpractices

1. Establish
guidelines.

2. Incorporate
the use of the guidelines into the defined process where appropriate.

Refer
to the Integrated Project Management process area for more
information about establishing the project’s defined process.

SP 1.2 Establish
Evaluation Criteria

Establish and maintain the
criteria for evaluating alternatives, and the relative ranking of
these criteria.

The
evaluation criteria provide the basis for evaluating alternative
solutions. The criteria are ranked so that the highest ranked
criteria exert the most influence on the evaluation.

This
process area is referenced by many other process areas in the model,
and there are many contexts in which a formal evaluation process can
be used. Therefore, in some situations you may find that criteria
have already been defined as part of another process. This specific
practice does not suggest that a second development of criteria be
conducted.

Document
the evaluation criteria to minimize the possibility that decisions
will be second-guessed, or that the reason for making the decision
will be forgotten. Decisions based on criteria that are explicitly
defined and established remove barriers to stakeholder buy-in.

Typical
Work Products

1. Documented
evaluation criteria

2. Rankings
of criteria importance

Subpractices

1. Define
the criteria for evaluating alternative solutions.

Criteria
should be traceable to requirements, scenarios, business case
assumptions, business objectives, or other documented sources. Types
of criteria to consider include the following:

• 
  Technology
  limitations

  
  

• 
  Environmental
  impact

  
  

• 
  Risks

  
  

• 
  Total ownership
  and lifecycle costs

  
  

2. Define
the range and scale for ranking the evaluation criteria.

Scales
of relative importance for evaluation criteria can be established
with non-numeric values or with formulas that relate the evaluation
parameter to a numeric weight.

3. Rank
the criteria.

The
criteria are ranked according to the defined range and scale to
reflect the needs, objectives, and priorities of the relevant
stakeholders.

4. Assess
the criteria and their relative importance.

5. Evolve
the evaluation criteria to improve their validity.

6. Document
the rationale for the selection and rejection of evaluation criteria.

Documentation
of selection criteria and rationale may be needed to justify
solutions or for future reference and use.

SP 1.3 Identify
Alternative Solutions

Identify alternative solutions
to address issues.

A
wider range of alternatives can surface by soliciting as many
stakeholders as practical for input. Input from stakeholders with
diverse skills and backgrounds can help teams identify and address
assumptions, constraints, and biases. Brainstorming sessions may
stimulate innovative alternatives through rapid interaction and
feedback. Sufficient candidate solutions may not be furnished for
analysis. As the analysis proceeds, other alternatives should be
added to the list of potential candidate solutions. The generation
and consideration of multiple alternatives early in a decision
analysis and resolution process increases the likelihood that an
acceptable decision will be made, and that consequences of the
decision will be understood.

Typical
Work Products

1. Identified
alternatives

Subpractices

1. Perform
a literature search.

A
literature search can uncover what others have done both inside and
outside the organization. It may provide a deeper understanding of
the problem, alternatives to consider, barriers to implementation,
existing trade studies, and lessons learned from similar decisions.

2. Identify
alternatives for consideration in addition to those that may be
provided with the issue.

Evaluation
criteria are an effective starting point for identifying
alternatives. The evaluation criteria identify the priorities of the
relevant stakeholders and the importance of technical, logistical, or
other challenges.

Combining
key attributes of existing alternatives can generate additional and
sometimes stronger alternatives.

Solicit
alternatives from relevant stakeholders. Brainstorming sessions,
interviews, and working groups can be used effectively to uncover
alternatives.

3. Document
the proposed alternatives.

SP 1.4 Select
Evaluation Methods

Select the evaluation methods.

Methods
for evaluating alternative solutions against established criteria can
range from simulations to the use of probabilistic models and
decision theory. These methods need to be carefully selected. The
level of detail of a method should be commensurate with cost,
schedule, performance, and risk impacts.

While
many problems may need only one evaluation method, some problems may
require multiple methods. For instance, simulations may augment a
trade study to determine which design alternative best meets a given
criterion.

Typical
Work Products

1. Selected
evaluation methods

Subpractices

1. Select
the methods based on the purpose for analyzing a decision and on the
availability of the information used to support the method.

For
example, the methods used for evaluating a solution when requirements
are weakly defined may be different from the methods used when the
requirements are well defined.

Typical
evaluation methods include the following:

• 
  Modeling and
  simulation

  
  

• 
  Engineering
  studies

  
  

• 
  Manufacturing
  studies

  
  

• 
  Cost studies

  
  

• 
  Business
  opportunity studies

  
  

• 
  Surveys

  
  

• 
  Extrapolations
  based on field experience and prototypes

  
  

• 
  User review and
  comment

  
  

• 
  Testing

  
  

• 
  Judgment provided
  by an expert or group of experts (e.g., Delphi Method)

  
  

2. Select
evaluation methods based on their ability to focus on the issues at
hand without being overly influenced by side issues.

Results
of simulations can be skewed by random activities in the solution
that are not directly related to the issues at hand.

3. Determine
the measures needed to support the evaluation method.

Consider
the impact on cost, schedule, performance, and risks.

SP 1.5 Evaluate
Alternatives

Evaluate alternative solutions
using the established criteria and methods.

Evaluating
alternative solutions involves analysis, discussion, and review.
Iterative cycles of analysis are sometimes necessary. Supporting
analyses, experimentation, prototyping, piloting, or simulations may
be needed to substantiate scoring and conclusions.

Often,
the relative importance of criteria is imprecise and the total effect
on a solution is not apparent until after the analysis is performed.
In cases where the resulting scores differ by relatively small
amounts, the best selection among alternative solutions may not be
clear cut. Challenges to criteria and assumptions should be
encouraged.

Typical
Work Products

1. Evaluation
results

Subpractices

1. Evaluate
the proposed alternative solutions using the established evaluation
criteria and selected methods.

2. Evaluate
the assumptions related to the evaluation criteria and the evidence
that supports the assumptions.

3. Evaluate
whether uncertainty in the values for alternative solutions affects
the evaluation and address as appropriate.

For
instance, if the score can vary between two values, is the difference
significant enough to make a difference in the final solution set?
Does the variation in score represent a high risk? To address these
concerns, simulations may be run, further studies may be performed,
or evaluation criteria may be modified, among other things.

4. Perform
simulations, modeling, prototypes, and pilots as necessary to
exercise the evaluation criteria, methods, and alternative solutions.

Untested
criteria, their relative importance, and supporting data or functions
may cause the validity of solutions to be questioned. Criteria and
their relative priorities and scales can be tested with trial runs
against a set of alternatives. These trial runs of a select set of
criteria allow for the evaluation of the cumulative impact of the
criteria on a solution. If the trials reveal problems, different
criteria or alternatives might be considered to avoid biases.

5. Consider
new alternative solutions, criteria, or methods if the proposed
alternatives do not test well; repeat the evaluations until
alternatives do test well.

6. Document
the results of the evaluation.

Document
the rationale for the addition of new alternatives or methods and
changes to criteria, as well as the results of interim evaluations.

SP 1.6 Select
Solutions

Select solutions from the
alternatives based on the evaluation criteria.

Selecting
solutions involves weighing the results from the evaluation of
alternatives. Risks associated with implementation of the solutions
must be assessed.

Typical
Work Products

1. Recommended
solutions to address significant issues

Subpractices

1. Assess
the risks associated with implementing the recommended solution.

Refer
to the Risk Management process area for more information about
identifying and managing risks.

Decisions
must often be made with incomplete information. There can be
substantial risk associated with the decision because of having
incomplete information.

When
decisions must be made according to a specific schedule, time and
resources may not be available for gathering complete information.
Consequently, risky decisions made with incomplete information may
require re-analysis later. Identified risks should be monitored.

2. Document
the results and rationale for the recommended solution.

It
is important to record both why a solution is selected and why
another solution was rejected.

Generic Practices
by Goal

Continuous Only

GG 1 Achieve Specific Goals The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products. GP 1.1 Perform Specific Practices Perform the specific practices of the decision analysis and resolution process to develop work products and provide services to achieve the specific goals of the process area. GG 2 Institutionalize a Managed Process The process is institutionalized as a managed process.

Staged Only
GG 3 Institutionalize a Defined Process The process is institutionalized as a defined process. This generic goal’s appearance here reflects its location in the staged representation.

GP 2.1 Establish an
Organizational Policy

Establish and maintain an
organizational policy for planning and performing the decision
analysis and resolution process.

Elaboration:

This
policy establishes organizational expectations for selectively
analyzing possible decisions using a formal evaluation process that
evaluates identified alternatives against established criteria. The
policy should also provide guidance on which decisions require a
formal evaluation process.

GP 2.2 Plan the
Process

Establish and maintain the plan
for performing the decision analysis and resolution process.

Elaboration:

This
plan for performing the decision analysis and resolution process can
be included in (or referenced by) the project plan, which is
described in the Project Planning process area.

GP 2.3 Provide
Resources

Provide adequate resources for
performing the decision analysis and resolution process, developing
the work products, and providing the services of the process.

Elaboration:

Examples
of resources provided include the following tools:

• 
  Simulators
  and modeling tools

  
  

• 
  Prototyping
  tools

  
  

• 
  Tools
  for conducting surveys

  
  

GP 2.4 Assign
Responsibility

Assign responsibility and
authority for performing the process, developing the work products,
and providing the services of the decision analysis and resolution
process.

GP 2.5 Train People

Train the people performing or
supporting the decision analysis and resolution process as needed.

Elaboration:

Examples
of training topics include the following:

• 
  Formal
  decision analysis

  
  

• 
  Methods
  for evaluating alternative solutions against criteria

  
  

GP 2.6 Manage
Configurations

Place designated work products
of the decision analysis and resolution process under appropriate
levels of control.

Elaboration:

Examples
of work products placed under control include the following:

• 
  Guidelines
  for when to apply a formal evaluation process

  
  

• 
  Evaluation
  reports containing recommended solutions

  
  

GP 2.7 Identify and
Involve Relevant Stakeholders

Identify and involve the
relevant stakeholders of the decision analysis and resolution process
as planned.

Elaboration:

Examples
of activities for stakeholder involvement include the following:

• 
  Establishing
  guidelines for which issues are subject to a formal evaluation
  process

  
  

• 
  Establishing
  evaluation criteria

  
  

• 
  Identifying
  and evaluating alternatives

  
  

• 
  Selecting
  evaluation methods

  
  

• 
  Selecting
  solutions

  
  

GP 2.8 Monitor and
Control the Process

Monitor and control the decision
analysis and resolution process against the plan for performing the
process and take appropriate corrective action.

Elaboration:

Examples
of measures and work products used in monitoring and controlling
include the following:

• 
  Cost-to-benefit
  ratio of using formal evaluation processes

  
  

• 
  Schedule
  for the execution of a trade study

  
  

GP 2.9 Objectively
Evaluate Adherence

Objectively evaluate adherence
of the decision analysis and resolution process against its process
description, standards, and procedures, and address noncompliance.

Elaboration:

Examples
of activities reviewed include the following:

• 
  Evaluating
  alternatives using established criteria and methods

  
  

Examples
of work products reviewed include the following:

• 
  Guidelines
  for when to apply a formal evaluation process

  
  

• 
  Evaluation
  reports containing recommended solutions

  
  

GP 2.10 Review Status
with Higher Level Management

Review the activities, status,
and results of the decision analysis and resolution process with
higher level management and resolve issues.

Continuous Only
GG 3 Institutionalize a Defined Process The process is institutionalized as a defined process. This generic goal’s appearance here reflects its location in the continuous representation.

GP 3.1 Establish a
Defined Process

Establish and maintain the
description of a defined decision analysis and resolution process.

GP 3.2 Collect
Improvement Information

Collect work products, measures,
measurement results, and improvement information derived from
planning and performing the decision analysis and resolution process
to support the future use and improvement of the organization’s
processes and process assets.

Elaboration:

Examples
of work products, measures, measurement results, and improvement
information include the following:

• 
  Number
  of alternatives considered

  
  

• 
  Evaluation
  results

  
  

• 
  Recommended
  solutions to address significant issues

  
  

Continuous Only

GG 4 Institutionalize a Quantitatively Managed Process The process is institutionalized as a quantitatively managed process. GP 4.1 Establish Quantitative Objectives for the Process Establish and maintain quantitative objectives for the decision analysis and resolution process, which address quality and process performance, based on customer needs and business objectives. GP 4.2 Stabilize Subprocess Performance Stabilize the performance of one or more subprocesses to determine the ability of the decision analysis and resolution process to achieve the established quantitative quality and process-performance objectives. GG 5 Institutionalize an Optimizing Process The process is institutionalized as an optimizing process. GP 5.1 Ensure Continuous Process Improvement Ensure continuous improvement of the decision analysis and resolution process in fulfilling the relevant business objectives of the organization. GP 5.2 Correct Root Causes of Problems Identify and correct the root causes of defects and other problems in the decision analysis and resolution process.

Integrated Project
Management +IPPD

A
Project Management Process Area at Maturity Level 3

Purpose

The
purpose of Integrated Project Management (IPM) is to establish and
manage the project and the involvement of the relevant stakeholders
according to an integrated and defined process that is tailored from
the organization’s set of standard processes.

IPPD
Addition

For
IPPD, Integrated Project Management +IPPD also covers the
establishment of a shared vision for the project and the
establishment of integrated teams that will carry out objectives of
the project.

Introductory Notes

Integrated
Project Management involves the following:

• 
  Establishing
  the project’s defined process at project startup by tailoring the
  organization’s set of standard processes

  
  

• 
  Managing
  the project using the project’s defined process

  
  

• 
  Establishing
  the work environment for the project based on the organization’s
  work environment standards

  
  

• 
  Using
  and contributing to the organizational process assets

  
  

• 
  Enabling
  relevant stakeholders’ concerns to be identified, considered, and,
  when appropriate, addressed during the development of the product

  
  

• 
  Ensuring
  that the relevant stakeholders perform their tasks in a coordinated
  and timely manner (1) to address product and product component
  requirements, plans, objectives, problems, and risks; (2) to fulfill
  their commitments; and (3) to identify, track, and resolve
  coordination issues

  
  

IPPD Addition

Integrated Project
Management +IPPD also involves the following:

• 
  Establishing a shared
  vision for the project

  
  

• 
  Establishing integrated
  teams that are tasked to accomplish project objectives

  
  

The
integrated and defined process that is tailored from the
organization’s set of standard processes is called the project’s
defined process.

Managing
the project’s effort, cost, schedule, staffing, risks, and other
factors is tied to the tasks of the project’s defined process. The
implementation and management of the project’s defined process are
typically described in the project plan. Certain activities may be
covered in other plans that affect the project, such as the quality
assurance plan, risk management strategy, and the configuration
management plan.

Since
the defined process for each project is tailored from the
organization’s set of standard processes, variability among
projects is typically reduced and projects can more easily share
process assets, data, and lessons learned.

This
process area also addresses the coordination of all activities
associated with the project such as the following:

• 
  Development
  activities (e.g., requirements development, design, and
  verification)

  
  

• 
  Service
  activities (e.g., delivery, help desk, operations, and customer
  contact)

  
  

• 
  Acquisition
  activities (e.g., solicitation, contract monitoring, and transition
  to operation)

  
  

• 
  Support
  activities (e.g., configuration management, documentation,
  marketing, and training)

  
  

The
working interfaces and interactions among relevant stakeholders
internal and external to the project are planned and managed to
ensure the quality and integrity of the entire product. Relevant
stakeholders participate, as appropriate, in defining the project’s
defined process and the project plan. Reviews and exchanges are
regularly conducted with the relevant stakeholders to ensure that
coordination issues receive appropriate attention and everyone
involved with the project is appropriately aware of the status,
plans, and activities. (See the definition of “relevant
stakeholder” in the glossary.) In defining the project’s defined
process, formal interfaces are created as necessary to ensure that
appropriate coordination and collaboration occurs.

This
process area applies in any organizational structure, including
projects that are structured as line organizations, matrix
organizations, or integrated teams. The terminology should be
appropriately interpreted for the organizational structure in place.

Related Process
Areas

Refer
to the Project Planning process area for more information about
planning the project, which includes identifying relevant
stakeholders and their appropriate involvement in the project.

Refer
to the Project Monitoring and Control process area for more
information about monitoring and controlling the project.

Refer
to the Verification process area for more information about peer
reviews.

Refer
to the Organizational Process Definition process area for more
information about organizational process assets and work environment
standards.

Refer
to the Measurement and Analysis process area for more information
about defining a process for measuring and analyzing processes.

IPPD
Addition

Refer
to the Organizational Process Definition +IPPD process area for more
information about creating the organizational rules and guidelines
for IPPD.

Specific Goal and
Practice Summary

SG 1 Use the Project’s
Defined Process

SP 1.1 Establish the
Project’s Defined Process

SP 1.2 Use Organizational
Process Assets for Planning Project Activities

SP 1.3 Establish the
Project’s Work Environment

SP 1.4 Integrate Plans

SP 1.5 Manage the Project
Using the Integrated Plans

SP 1.6 Contribute to the
Organizational Process Assets

SG 2 Coordinate and
Collaborate with Relevant Stakeholders

SP 2.1 Manage Stakeholder
Involvement

SP 2.2 Manage
Dependencies

SP 2.3 Resolve
Coordination Issues

IPPD Addition SG 3 Apply IPPD Principles SP 3.1 Establish the Project’s Shared Vision SP 3.2 Establish the Integrated Team Structure SP 3.3 Allocate Requirements to Integrated Teams SP 3.4 Establish Integrated Teams SP 3.5 Ensure Collaboration among Interfacing Teams

Specific Practices
by Goal

SG 1 Use the Project’s
Defined Process

The project is conducted using a
defined process that is tailored from the organization’s set of
standard processes.

The
project’s defined process must include those processes from the
organization’s set of standard processes that address all processes
necessary to acquire or develop and maintain the product. The
product-related lifecycle processes, such as the manufacturing and
support processes, are developed concurrently with the product.

SP 1.1 Establish the
Project’s Defined Process

Establish and maintain the
project’s defined process from project startup through the life of
the project.

Refer
to the Organizational Process Definition process area for more
information about the organizational process assets.

Refer
to the Organizational Process Focus process area for more information
about organizational process needs and objectives and deploying the
organization’s set of standard processes on projects.

The
project’s defined process consists of defined processes that form
an integrated, coherent lifecycle for the project.

IPPD Addition

The project’s defined
process supports IPPD with processes that

• 
  Make the integrated
  project management environment more amenable to collocated or
  distributed teams

  
  

• 
  Select the project’s
  integrated team structure

  
  

• 
  Allocate limited
  personnel resources

  
  

• 
  Implement
  cross-integrated team communication

  
  

The
project’s defined process should satisfy the project’s contractual
and operational needs, opportunities, and constraints. It is designed
to provide a best fit for the project’s needs. A project’s defined
process is based on the following factors:

• 
  Customer
  requirements

  
  

• 
  Product
  and product component requirements

  
  

• 
  Commitments

  
  

• 
  Organizational
  process needs and objectives

  
  

• 
  Organization’s
  set of standard processes and tailoring guidelines

  
  

• 
  Operational
  environment

  
  

• 
  Business
  environment

  
  

Establishing
the project’s defined process at project startup helps to ensure
that project staff and stakeholders implement a set of activities
needed to efficiently establish an initial set of requirements and
plans for the project. As the project progresses, the description of
the project’s defined process is elaborated and revised to better
meet the project’s requirements and the organization’s process
needs and objectives. Also, as the organization’s set of standard
processes change, the project’s defined process may need to be
revised.

Typical
Work Products

1. The
project’s defined process

Subpractices

1. Select
a lifecycle model from those available from the organizational
process assets.

Examples
of project characteristics that could affect the selection of
lifecycle models include the following:

• 
  Size of the
  project

  
  

• 
  Experience and
  familiarity of staff in implementing the process

  
  

• 
  Constraints such
  as cycle time and acceptable defect levels

  
  

2. Select
the standard processes from the organization’s set of standard
processes that best fit the needs of the project.

3. Tailor
the organization’s set of standard processes and other
organizational process assets according to the tailoring guidelines
to produce the project’s defined process.

Sometimes
the available lifecycle models and standard processes are inadequate
to meet a specific project’s needs. Sometimes the project will be
unable to produce required work products or measures. In such
circumstances, the project will need to seek approval to deviate from
what is required by the organization. Waivers are provided for this
purpose.

4. Use
other artifacts from the organization’s process asset library as
appropriate.

Other
artifacts may include the following:

• 
  Lessons-learned
  documents

  
  

• 
  Templates

  
  

• 
  Example documents

  
  

• 
  Estimating models

  
  

5. Document
the project’s defined process.

The
project’s defined process covers all of the activities for the
project and its interfaces to relevant stakeholders.

Examples
of project activities include the following:

• 
  Project planning

  
  

• 
  Project
  monitoring

  
  

• 
  Requirements
  development

  
  

• 
  Requirements
  management

  
  

• 
  Supplier
  management

  
  

• 
  Configuration
  management

  
  

• 
  Quality assurance

  
  

• 
  Risk management

  
  

• 
  Decision analysis
  and resolution

  
  

• 
  Product
  development and support

  
  

• 
  Solicitation

  
  

6. Conduct
peer reviews of the project’s defined process.

Refer
to the Verification process area for more information about
conducting peer reviews.

7. Revise
the project’s defined process as necessary.

SP 1.2 Use
Organizational Process Assets for Planning Project Activities

Use the organizational process
assets and measurement repository for estimating and planning the
project’s activities.

Refer
to the Organizational Process Definition process area for more
information about organizational process assets and the
organization’s measurement repository.

Typical
Work Products

1. Project
estimates

2. Project
plans

Subpractices

1. Use
the tasks and work products of the project’s defined process as a
basis for estimating and planning the project’s activities.

An
understanding of the relationships among the various tasks and work
products of the project’s defined process, and of the roles to be
performed by the relevant stakeholders, is a basis for developing a
realistic plan.

2. Use
the organization’s measurement repository in estimating the
project’s planning parameters.

This
estimate typically includes the following:

• 
  Using appropriate
  historical data from this project or similar projects

  
  

• 
  Accounting for
  and recording similarities and differences between the current
  project and those projects whose historical data will be used

  
  

• 
  Independently
  validating the historical data

  
  

• 
  Recording the
  reasoning, assumptions, and rationale used to select the historical
  data

  
  

Examples
of parameters that are considered for similarities and differences
include the following:

• 
  Work product and
  task attributes

  
  

• 
  Application
  domain

  
  

• 
  Design approach

  
  

• 
  Operational
  environment

  
  

• 
  Experience of the
  people

  
  

Examples
of data contained in the organization’s measurement repository
include the following:

• 
  Size of work
  products or other work product attributes

  
  

• 
  Effort

  
  

• 
  Cost

  
  

• 
  Schedule

  
  

• 
  Staffing

  
  

• 
  Defects

  
  

• 
  Response time

  
  

• 
  Service capacity

  
  

• 
  Supplier
  performance

  
  

SP 1.3 Establish the
Project’s Work Environment

Establish and maintain the
project’s work environment based on the organization’s work
environment standards.

An
appropriate work environment for a project comprises an
infrastructure of facilities, tools, and equipment that people need
to perform their jobs effectively in support of business and project
objectives. The work environment and its components are maintained at
a level of performance and reliability indicated by the
organizational work environment standards. As required, the project’s
work environment or some of its components can be developed
internally or acquired from external sources.

IPPD Addition

An effective work
environment helps projects employing IPPD to conduct work using
collocated or distributed integrated teams. Two-way communications
media should be readily accessible by all relevant stakeholders in
the project.

The
project’s work environment might encompass environments for product
integration, verification, and validation or they might be separate
environments.

Refer
to the Establish Work Environment Standards specific practice in the
Organizational Process Definition process area for more information
about work environment standards.

Refer
to the Establish the Product Integration Environment specific
practice of the Product Integration process area for more information
about establishing and maintaining the product integration
environment for the project.

Refer
to the Establish the Verification Environment specific practice of
the Verification process area for more information about establishing
and maintaining the verification environment for the project.

Refer
to the Establish the Validation Environment specific practice of the
Validation process area for more information about establishing and
maintaining the validation environment for the project.

Typical
Work Products

1. Equipment
and tools for the project

2. Installation,
operation, and maintenance manuals for the project work environment

3. User
surveys and results

4. Usage,
performance, and maintenance records

5. Support
services for the project’s work environment

Subpractices

1. Plan,
design, and install a work environment for the project.

The
critical aspects of the project work environment are, like any other
product, requirements driven. Work environment functionality and
operations are explored with the same rigor as is done for any other
product development.

It
may be necessary to make tradeoffs among performance, costs, and
risks. The following are examples of each:

• 
  Performance
  considerations may include timely interoperable communications,
  safety, security, and maintainability.

  
  

• 
  Costs may include
  capital outlays, training, support structure, disassembly and
  disposal of existing environments, and operation and maintenance of
  the environment.

  
  

• 
  Risks may include
  workflow and project disruptions.

  
  

Examples
of equipment and tools include the following:

• 
  Office software

  
  

• 
  Decision support
  software

  
  

• 
  Project
  management tools

  
  

• 
  Requirements
  management tools, design tools

  
  

• 
  Configuration
  management tools

  
  

• 
  Evaluation tools

  
  

• 
  Test and/or
  evaluation equipment

  
  

2. Provide
ongoing maintenance and operational support for the project’s work
environment.

Maintenance
and support of the work environment can be accomplished either with
capabilities found inside the organization or hired from outside the
organization.

Examples
of maintenance and support approaches include the following:

• 
  Hiring people to
  perform the maintenance and support

  
  

• 
  Training people
  to perform the maintenance and support

  
  

• 
  Contracting the
  maintenance and support

  
  

• 
  Developing expert
  users for selected tools

  
  

3. Maintain
the qualification of the components of the project’s work
environment.

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

4. Periodically
review how well the work environment is meeting the project’s needs
and supporting collaboration, and take action as appropriate.

Examples
of actions that might be taken include the following:

• 
  Adding new tools

  
  

• 
  Acquiring
  additional networks, equipment, training, and support

  
  

SP 1.4 Integrate Plans

Integrate the project plan and
the other plans that affect the project to describe the project’s
defined process.

Refer
to the Project Planning process area for more information about
establishing and maintaining a project plan.

Refer
to the Organizational Process Definition process area for more
information about organizational process assets and, in particular,
the organization’s measurement repository.

Refer
to the Measurement and Analysis process area for more information
about defining measures and measurement activities and using analytic
techniques.

Refer
to the Risk Management process area for more information about
identifying and analyzing risks.

Refer
to the Organizational Process Focus process area for more information
about organizational process needs and objectives.

This
specific practice extends the specific practices for establishing and
maintaining a project plan to address additional planning activities
such as incorporating the project’s defined process, coordinating
with relevant stakeholders, using organizational process assets,
incorporating plans for peer reviews, and establishing objective
entry and exit criteria for tasks.

The
development of the project plan should account for current and
projected needs, objectives, and requirements of the organization,
customer, suppliers, and end users, as appropriate.

IPPD Addition

The plans of the
integrated teams are included in this integration. Developing a
complete project plan and the project’s defined process may require
an iterative effort if a complex, multi-layered, integrated team
structure is being deployed.

Typical
Work Products

1. Integrated
plans

Subpractices

1. Integrate
other plans that affect the project with the project plan.

Other
plans that affect the project may include the following:

• 
  Quality assurance
  plans

  
  

• 
  Configuration
  management plans

  
  

• 
  Risk management
  strategy

  
  

• 
  Documentation
  plans

  
  

2. Incorporate
into the project plan the definitions of measures and measurement
activities for managing the project.

Examples
of measures that would be incorporated include the following:

• 
  Organization’s
  common set of measures

  
  

• 
  Additional
  project-specific measures

  
  

3. Identify
and analyze product and project interface risks.

Examples
of product and project interface risks include the following:

• 
  Incomplete
  interface descriptions

  
  

• 
  Unavailability of
  tools or test equipment

  
  

• 
  Availability of
  COTS components

  
  

• 
  Inadequate or
  ineffective team interfaces

  
  

4. Schedule
the tasks in a sequence that accounts for critical development
factors and project risks.

Examples
of factors considered in scheduling include the following:

• 
  Size and
  complexity of the tasks

  
  

• 
  Integration and
  test issues

  
  

• 
  Needs of the
  customer and end users

  
  

• 
  Availability of
  critical resources

  
  

• 
  Availability of
  key personnel

  
  

5. Incorporate
the plans for performing peer reviews on the work products of the
project’s defined process.

Refer
to the Verification process area for more information about peer
reviews.

6. Incorporate
the training needed to perform the project’s defined process in the
project’s training plans.

This
task typically involves negotiating with the organizational training
group the support they will provide.

7. Establish
objective entry and exit criteria to authorize the initiation and
completion of the tasks described in the work breakdown structure
(WBS).

Refer
to the Project Planning process area for more information about the
WBS.

8. Ensure
that the project plan is appropriately compatible with the plans of
relevant stakeholders.

Typically
the plan and changes to the plan will be reviewed for compatibility.

9. Identify
how conflicts will be resolved that arise among relevant
stakeholders.

SP 1.5 Manage the
Project Using the Integrated Plans

Manage the project using the
project plan, the other plans that affect the project, and the
project’s defined process.

Refer
to the Organizational Process Definition process area for more
information about the organizational process assets.

Refer
to the Organizational Process Focus process area for more information
about organizational process needs and objectives and coordinating
process improvement activities with the rest of the organization.

Refer
to the Risk Management process area for more information about
managing risks.

Refer
to the Project Monitoring and Control process area for more
information about monitoring and controlling the project.

Typical
Work Products

1. Work
products created by performing the project’s defined process

2. Collected
measures (“actuals”) and progress records or reports

3. Revised
requirements, plans, and commitments

4. Integrated
plans

Subpractices

1. Implement
the project’s defined process using the organization’s process
asset library.

This
task typically includes the following:

• 
  Incorporating
  artifacts from the organization’s process asset library into the
  project as appropriate

  
  

• 
  Using lessons
  learned from the organization’s process asset library to manage
  the project

  
  

2. Monitor
and control the project’s activities and work products using the
project’s defined process, project plan, and other plans that
affect the project.

This
task typically includes the following:

• 
  Using the defined
  entry and exit criteria to authorize the initiation and determine
  the completion of the tasks

  
  

• 
  Monitoring the
  activities that could significantly affect the actual values of the
  project’s planning parameters

  
  

• 
  Tracking the
  project’s planning parameters using measurable thresholds that
  will trigger investigation and appropriate actions

  
  

• 
  Monitoring
  product and project interface risks

  
  

• 
  Managing external
  and internal commitments based on the plans for the tasks and work
  products of the project’s defined process

  
  

An
understanding of the relationships among the various tasks and work
products of the project’s defined process, and of the roles to be
performed by the relevant stakeholders, along with well-defined
control mechanisms (e.g., peer reviews) achieves better visibility
into the project’s performance and better control of the project.

3. Obtain
and analyze the selected measures to manage the project and support
the organization’s needs.

Refer
to the Measurement and Analysis process area for more information
about defining a process for obtaining and analyzing measures.

4. Periodically
review and align the project’s performance with the current and
anticipated needs, objectives, and requirements of the organization,
customer, and end users, as appropriate.

This
review includes alignment with the organizational process needs and
objectives.

Examples
of actions that achieve alignment include the following:

• 
  Accelerating the
  schedule, with appropriate adjustments to other planning parameters
  and the project risks

  
  

• 
  Changing the
  requirements in response to a change in market opportunities or
  customer and end-user needs

  
  

• 
  Terminating the
  project

  
  

SP 1.6 Contribute to
the Organizational Process Assets

Contribute work products,
measures, and documented experiences to the organizational process
assets.

Refer
to the Organizational Process Focus process area for more information
about process improvement proposals.

Refer
to the Organizational Process Definition process area for more
information about the organizational process assets, the
organization’s measurement repository, and the organization’s
process asset library.

This
specific practice addresses collecting information from processes in
the project’s defined process.

Typical
Work Products

1. Proposed
improvements to the organizational process assets

2. Actual
process and product measures collected from the project

3. Documentation
(e.g., exemplary process descriptions, plans, training modules,
checklists, and lessons learned)

4. Process
artifacts associated with tailoring and implementing the
organization’s set of standard processes on the project

Subpractices

1. Propose
improvements to the organizational process assets.

2. Store
process and product measures in the organization’s measurement
repository.

Refer
to the Project Planning process area for more information about
recording planning and replanning data.

Refer
to the Project Monitoring and Control process area for more
information about recording measures.

This
typically includes the following:

• 
  Planning data

  
  

• 
  Replanning data

  
  

• 
  Measures

  
  

Examples
of data recorded by the project include the following:

• 
  Task descriptions

  
  

• 
  Assumptions

  
  

• 
  Estimates

  
  

• 
  Revised estimates

  
  

• 
  Definitions of
  recorded data and measures

  
  

• 
  Measures

  
  

• 
  Context
  information that relates the measures to the activities performed
  and work products produced

  
  

• 
  Associated
  information needed to reconstruct the estimates, assess their
  reasonableness, and derive estimates for new work

  
  

3. Submit
documentation for possible inclusion in the organization’s process
asset library.

Examples
of documentation include the following:

• 
  Exemplary process
  descriptions

  
  

• 
  Training modules

  
  

• 
  Exemplary plans

  
  

• 
  Checklists

  
  

4. Document
lessons learned from the project for inclusion in the organization’s
process asset library.

5. Provide
process artifacts associated with tailoring and implementing the
organization’s set of standard processes in support of the
organization’s process monitoring activities.

Refer
to the Monitor Implementation specific practice of the Organization
Process Focus process area for more information about the
organization’s activities to understand the extent of deployment of
standard processes on new and existing projects.

SG 2 Coordinate and
Collaborate with Relevant Stakeholders

Coordination and collaboration
of the project with relevant stakeholders is conducted.

SP 2.1 Manage
Stakeholder Involvement

Manage the involvement of the
relevant stakeholders in the project.

Stakeholder
involvement is managed according to the project’s integrated and
defined process.

Refer
to the Project Planning process area for more information about
identifying stakeholders and their appropriate involvement and about
establishing and maintaining commitments.

Typical
Work Products

1. Agendas
and schedules for collaborative activities

2. Documented
issues (e.g., issues with customer requirements, product and product
component requirements, product architecture, and product design)

3. Recommendations
for resolving relevant stakeholder issues

Subpractices

1. Coordinate
with the relevant stakeholders who should participate in the
project’s activities.

The
relevant stakeholders should already be identified in the project
plan.

2. Ensure
that work products that are produced to satisfy commitments meet the
requirements of the recipient projects.

Refer
to the Verification process area for more information about verifying
work products against their requirements.

This
task typically includes the following:

• 
  Reviewing,
  demonstrating, or testing, as appropriate, each work product
  produced by relevant stakeholders

  
  

• 
  Reviewing,
  demonstrating, or testing, as appropriate, each work product
  produced by the project for other projects with representatives of
  the projects receiving the work product

  
  

• 
  Resolving issues
  related to the acceptance of the work products

  
  

3. Develop
recommendations and coordinate the actions to resolve
misunderstandings and problems with the product and product component
requirements, product and product component architecture, and product
and product component design.

SP 2.2 Manage
Dependencies

Participate with relevant
stakeholders to identify, negotiate, and track critical dependencies.

Refer
to the Project Planning process area for more information about
identifying stakeholders and their appropriate involvement and about
establishing and maintaining commitments.

Typical
Work Products

1. Defects,
issues, and action items resulting from reviews with relevant
stakeholders

2. Critical
dependencies

3. Commitments
to address critical dependencies

4. Status
of critical dependencies

Subpractices

1. Conduct
reviews with relevant stakeholders.

2. Identify
each critical dependency.

3. Establish
need dates and plan dates for each critical dependency based on the
project schedule.

4. Review
and get agreement on the commitments to address each critical
dependency with the people responsible for providing the work product
and the people receiving the work product.

5. Document
the critical dependencies and commitments.

Documentation
of commitments typically includes the following:

• 
  Describing the
  commitment

  
  

• 
  Identifying who
  made the commitment

  
  

• 
  Identifying who
  is responsible for satisfying the commitment

  
  

• 
  Specifying when
  the commitment will be satisfied

  
  

• 
  Specifying the
  criteria for determining if the commitment has been satisfied

  
  

6. Track
the critical dependencies and commitments and take corrective action
as appropriate.

Refer
to the Project Monitoring and Control process area for more
information about tracking commitments.

Tracking
the critical dependencies typically includes the following:

• 
  Evaluating the
  effects of late and early completion for impacts on future
  activities and milestones

  
  

• 
  Resolving actual
  and potential problems with the responsible people whenever possible

  
  

• 
  Escalating to the
  appropriate managers the actual and potential problems not
  resolvable with the responsible people

  
  

SP 2.3 Resolve
Coordination Issues

Resolve issues with relevant
stakeholders.

Examples
of coordination issues include the following:

• 
  Late
  critical dependencies and commitments

  
  

• 
  Product
  and product component requirements and design defects

  
  

• 
  Product-level
  problems

  
  

• 
  Unavailability
  of critical resources or personnel

  
  

Typical
Work Products

1. Relevant
stakeholder coordination issues

2. Status
of relevant stakeholder coordination issues

Subpractices

1. Identify
and document issues.

2. Communicate
issues to the relevant stakeholders.

3. Resolve
issues with the relevant stakeholders.

4. Escalate
to the appropriate managers those issues not resolvable with the
relevant stakeholders.

5. Track
the issues to closure.

6. Communicate
with the relevant stakeholders on the status and resolution of the
issues.

IPPD Addition

SG 3 Apply IPPD Principles The project is managed using IPPD principles. The purpose of this specific goal and its practices is to create an IPPD environment that enables integrated teams to efficiently meet the project’s requirements and produce a quality product. SP 3.1 Establish the Project’s Shared Vision Establish and maintain a shared vision for the project. A project does not operate in isolation. Understanding organizational mission, goals, expectations and constraints allows the project to align its direction, activities, and shared vision with the organization and helps create a common purpose within which project activities can be coordinated. To enable this, it is critical to understand the interfaces between the project and stakeholders external to the project and the objectives and expectations of all relevant stakeholders (internal and external). When creating a shared vision, consider: external stakeholder expectations and requirements the aspirations and expectations of the project leader, team leaders, and team members the project’s objectives the conditions and outcomes the project will create interfaces the project needs to maintain the visions created by interfacing groups the constraints imposed by outside authorities (e.g., environmental regulations) project operation while working to achieve its objectives (both principles and behaviors) When creating a shared vision, all people in the project should be invited to participate. Although there may be a draft proposal, the larger population must have an opportunity to speak and be heard about what really matters to them. The shared vision is articulated in terms of both the core ideology (values, principles, and behaviors) and the desired future to which each member of the project can commit. An effective communications strategy is key to implementing and focusing the shared vision throughout the project. Promulgation of the shared vision is a public declaration of the commitment of the project to their shared vision and provides the opportunity for others to examine, understand, and align their activities in a common direction. The shared vision should be communicated, and agreement and commitment of the relevant stakeholders should be obtained. Effective communications are also especially important when incorporating new project members. New members of the project often need more or special attention to ensure that they understand the shared vision, have a stake in it, and are prepared to follow it in doing their work. Typical Work Products 1. Documented shared vision 2. Communications strategy 3. Published principles, shared vision statement, mission statement, and objectives (e.g., posters, wallet cards, and presentations) Subpractices 1. Articulate the project’s shared vision in terms of purpose or mission, vision, values, and objectives. 2. Reach consensus on the project’s shared vision. 3. Establish a strategy to communicate the project’s shared vision both externally and internally. 4. Create presentations suitable for the various audiences that need to be informed about the project’s shared vision. 5. Ensure that project and individual activities and tasks are aligned with the project’s shared vision. SP 3.2 Establish the Integrated Team Structure Establish and maintain the integrated team structure for the project. Product requirements, cost, schedule, risk, resource projections, business processes, the project’s defined process, and organizational guidelines are evaluated to establish the basis for defining integrated teams and their responsibilities, authorities, and interrelationships. A typical integrated team structure may be based on the product-oriented hierarchy found in the WBS. More complex structuring occurs when the WBS is not product oriented, product risks are not uniform, and resources are constrained. The integrated team structure is a dynamic entity that is adjusted to changes in people, requirements, and the nature of tasks, and to tackle many difficulties. For small projects, the integrated team structure can treat the whole project as an integrated team. The integrated team structure should be continuously monitored to detect malfunctions, mismanaged interfaces, and mismatches of the work to the staff. Corrective action should be taken when performance does not meet expectations. Refer to the Establish Rules and Guidelines for Integrated Teams specific practice in the Organizational Process Definition +IPPD process area for more information about establishing organizational rules and guidelines for structuring and forming integrated teams. Typical Work Products 1. Assessments of the product and product architectures, including risk and complexity 2. Integrated team structure Subpractices 1. Establish an integrated team structure. An integrated team structure is dependent on: An assessment of product risk and complexity Location and types of risks Integration risks, including product component interfaces and inter-team communication Resources, including availability of appropriately skilled people Limitations on team size for effective collaboration Need for team membership of stakeholders external to the project Business processes Organizational structure The integrated team structure should be based on an understanding of the project’s defined process and shared vision, the organization’s standard processes, and the organizational process assets applicable to teams and team structures. 2. Periodically evaluate and modify the integrated team structure to best meet project needs. Changes to the product requirements or architecture could affect the team structure. Continuously monitor the integrated team structure to detect problems such as mismanaged interfaces, and mismatches between the work assigned and the staff performing the work. Take corrective action, including assessing the deployed teams and structures, when performance does not meet expectations. Changes in team structure can include the following: Retiring a team for a period of time (e.g., while long-duration manufacturing or verifications are done) Disbanding a team when it is no longer cost effective in serving the project Combining teams to achieve operating efficiencies Adding teams as new product components are identified for development SP 3.3 Allocate Requirements to Integrated Teams Allocate requirements, responsibilities, tasks, and interfaces to teams in the integrated team structure. This allocation of requirements to integrated teams is done before any teams are formed to verify that the integrated team structure is workable and covers all the necessary requirements, responsibilities, authorities, tasks, and interfaces. Once the structure is confirmed, integrated team sponsors are chosen to establish the individual teams in the structure. Typical Work Products 1. Responsibilities allocated to each integrated team 2. Work product requirements, technical interfaces, and business (e.g., cost accounting and project management) interfaces each integrated team will be responsible for satisfying 3. List of integrated team sponsors Subpractices 1. Allocate the tasks, responsibilities, and work products to be delivered, and the associated requirements and interfaces to the appropriate integrated teams. Business, management, and other nontechnical responsibilities and authorities for each integrated team are necessary elements to proper team function. Integrated team responsibilities and authorities are normally developed by the project and are consistent with established organization practices. Example responsibilities and authorities, include the following: Authority of teams to pick their own leader Authority of teams to implement subteams (e.g., a product team forming an integration subteam) Reporting chains Reporting requirements (cost, schedule, and performance status) Progress reporting measures and methods 2. Check that the distribution of requirements and interfaces covers all specified product requirements and other requirements. In the event that complete coverage of requirements is not achieved, corrective action should be taken to redistribute requirements or to alter the integrated team structure. 3. Designate the sponsor for each integrated team. An integrated team sponsor is a manager (individual or team) who is responsible for establishing and providing resources to an integrated team, monitoring its activities and progress, and taking corrective action when needed. A sponsor may manage one or many teams. Team sponsors can be project managers. SP 3.4 Establish Integrated Teams Establish and maintain integrated teams in the structure. The integrated teams within the integrated team structure are established by the team sponsors. This process encompasses choosing team leaders and team members, and establishing the team charter for each integrated team based on the allocation of requirements. It also involves providing the resources required to accomplish the tasks assigned to the team. Refer to the Establish Rules and Guidelines for Integrated Teams specific practice in the Organizational Process Definition +IPPD process area for more information about establishing organizational rules and guidelines for structuring and forming integrated teams. Typical Work Products 1. List of team leaders 2. List of team members assigned to each integrated team 3. Integrated team charters 4. Measures for evaluating the performance of integrated teams 5. Periodic integrated team status reports Subpractices 1. Choose a leader for each integrated team. The extent of organizational and project direction in selecting the leader is often a function of product risk and complexity or an organization’s need to “grow” new leaders. Team sponsors may select the team leader or team members may vote on a leader from within the team, depending on organizational policies. 2. Allocate resources to each integrated team. The people and other resources are allocated to each integrated team. These items are discussed with the team to ensure that the resources are adequate and that the people are adequate to carry out the tasks and are compatible with other members of the team. 3. Charter each integrated team. The team charter is the contract among the team members and between the team and its sponsor for the expected work and level of performance. Charters establish the rights, guarantees, privileges, and permissions for organizing and performing the team’s assigned requirements and interfaces, responsibilities and tasks. The integrated team and its sponsor develop the team charter as a negotiation activity. When both approve it, the team charter constitutes a recognized agreement with management authority. Charters can include the following aspects: How assignments are accepted How resources and input are accessed How work gets done Who checks and reviews work How work is approved How work is delivered and communicated 4. Review the composition of an integrated team and its place in the integrated team structure when its team leader changes or another significant change of membership occurs. A change of this kind may significantly affect the ability of the team to accomplish its objectives. A review of the match between the new composition and the current responsibilities should be made. If the match is not satisfactory, the team composition should be changed or the team’s responsibility should be modified. 5. Review the composition of a team and its tasking when a change in team responsibility occurs. Changes in responsibilities often occur as the project moves from one phase to the next. For example, less design expertise on teams may be needed when detailed design is completed and fabrication and integration of product components begins. 6. Manage the overall performance of the teams. The charter should specify how both team and individual performance will be measured and should include the critical success factors for the team within the project. SP 3.5 Ensure Collaboration among Interfacing Teams Ensure collaboration among interfacing teams. The success of an integrated team-based project is a function of how effectively and successfully the integrated teams collaborate with one another to achieve project objectives. This collaboration may be accomplished using interface control working groups. See the Coordinate and Collaborate with Relevant Stakeholders specific goal of this process area for more information about managing stakeholder involvement, critical dependencies, and resolving coordination issues. Refer to the Establish Rules and Guidelines for Integrated Teams specific practice in the Organizational Process Definition +IPPD process area for more information about establishing organizational expectations and rules that will guide how the integrated teams work collectively. Typical Work Products 1. Work product ownership agreements 2. Team work plans 3. Commitment lists Subpractices 1. Establish and maintain the boundaries of work product ownership among interfacing teams within the project or organization. 2. Establish and maintain interfaces and processes among interfacing teams for the exchange of inputs, outputs, or work products. 3. Develop, communicate, and distribute among interfacing teams the commitment lists and work plans that are related to work product or team interfaces.

Generic Practices
by Goal

Continuous Only

GG 1 Achieve Specific Goals The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products. GP 1.1 Perform Specific Practices Perform the specific practices of the integrated project management process to develop work products and provide services to achieve the specific goals of the process area. GG 2 Institutionalize a Managed Process The process is institutionalized as a managed process.

Staged Only
GG 3 Institutionalize a Defined Process The process is institutionalized as a defined process. This generic goal’s appearance here reflects its location in the staged representation.

GP 2.1 Establish an
Organizational Policy

Establish and maintain an
organizational policy for planning and performing the integrated
project management process.

Elaboration:

This
policy establishes organizational expectations for establishing and
maintaining the project’s defined process from project startup
through the life of the project, using the project’s defined
process in managing the project, and coordinating and collaborating
with relevant stakeholders.

IPPD Addition

This policy also
establishes organizational expectations for applying IPPD principles.

GP 2.2 Plan the
Process

Establish and maintain the plan
for performing the integrated project management process.

Elaboration:

This
plan for the integrated project management process unites the
planning for the project planning and monitor and control processes.
The planning for performing the planning-related practices in
Integrated Project Management is addressed as part of planning the
project planning process. This plan for performing the
monitor-and-control-related practices in Integrated Project
Management can be included in (or referenced by) the project plan,
which is described in the Project Planning process area.

Refer
to Table 6.2 on page 95 in Generic Goals and Generic Practices for
more information about the relationship between generic practice 2.2
and project planning processes.

GP 2.3 Provide
Resources

Provide adequate resources for
performing the integrated project management process, developing the
work products, and providing the services of the process.

Elaboration:

Examples
of resources provided include the following tools:

• 
  Problem-tracking
  and trouble-reporting packages

  
  

• 
  Groupware

  
  

• 
  Video
  conferencing

  
  

• 
  Integrated
  decision database

  
  

• 
  Integrated
  product support environments

  
  

GP 2.4 Assign
Responsibility

Assign responsibility and
authority for performing the process, developing the work products,
and providing the services of the integrated project management
process.

GP 2.5 Train People

Train the people performing or
supporting the integrated project management process as needed.

Elaboration:

Examples
of training topics include the following:

• 
  Tailoring
  the organization’s set of standard processes to meet the needs of
  the project

  
  

• 
  Procedures
  for managing the project based on the project’s defined process

  
  

• 
  Using
  the organization’s measurement repository

  
  

• 
  Using
  the organizational process assets

  
  

• 
  Integrated
  management

  
  

• 
  Intergroup
  coordination

  
  

• 
  Group
  problem solving

  
  

IPPD Addition

Examples of training
topics also include the following:

• 
  Building the project’s
  shared vision

  
  

• 
  Team building

  
  

GP 2.6 Manage
Configurations

Place designated work products
of the integrated project management process under appropriate levels
of control.

Elaboration:

Examples
of work products placed under control include the following:

• 
  The
  project’s defined process

  
  

• 
  Project
  plans

  
  

• 
  Other
  plans that affect the project

  
  

• 
  Integrated
  plans

  
  

• 
  Actual
  process and product measures collected from the project

  
  

IPPD Addition

Examples of work products
placed under control also include the following:

• 
  Project’s shared vision

  
  

• 
  Integrated team
  structure

  
  

• 
  Integrated team charters

  
  

GP 2.7 Identify and
Involve Relevant Stakeholders

Identify and involve the
relevant stakeholders of the integrated project management process as
planned.

Elaboration:

Refer
to Table 6.2 on page 95 in Generic Goals and Generic Practices for
more information about the relationship between generic practice 2.7
and the Manage Stakeholder Involvement practice in this process area.

Examples
of activities for stakeholder involvement include the following:

• 
  Resolving
  issues about the tailoring of the organizational process assets

  
  

• 
  Resolving
  issues among the project plan and the other plans that affect the
  project

  
  

• 
  Reviewing
  project performance to align with current and projected needs,
  objectives, and requirements

  
  

IPPD Addition

Examples of activities
for stakeholder involvement also include the following:

• 
  Creating the project’s
  shared vision

  
  

• 
  Defining the integrated
  team structure for the project

  
  

• 
  Populating the
  integrated teams

  
  

GP 2.8 Monitor and
Control the Process

Monitor and control the
integrated project management process against the plan for performing
the process and take appropriate corrective action.

Elaboration:

Examples
of measures and work products used in monitoring and controlling
include the following:

• 
  Number
  of changes to the project’s defined process

  
  

• 
  Schedule
  and effort to tailor the organization’s set of standard processes

  
  

• 
  Interface
  coordination issue trends (i.e., number identified and number
  closed)

  
  

• 
  Schedule
  for project tailoring activities

  
  

IPPD Addition

Examples of measures and
work products used in monitoring and controlling also include the
following:

• 
  Project’s shared vision
  usage and effectiveness

  
  

• 
  Integrated
  team-structure usage and effectiveness

  
  

• 
  Integrated team charters
  usage and effectiveness

  
  

GP 2.9 Objectively
Evaluate Adherence

Objectively evaluate adherence
of the integrated project management process against its process
description, standards, and procedures, and address noncompliance.

Elaboration:

Examples
of activities reviewed include the following:

• 
  Establishing,
  maintaining, and using the project’s defined process

  
  

• 
  Coordinating
  and collaborating with relevant stakeholders

  
  

IPPD Addition

Examples of activities
reviewed also include the following:

• 
  Using the project’s
  shared vision

  
  

• 
  Organizing integrated
  teams

  
  

Examples
of work products reviewed include the following:

• 
  Project’s
  defined process

  
  

• 
  Project
  plans

  
  

• 
  Other
  plans that affect the project

  
  

IPPD Addition

Examples of work products
reviewed also include the following:

• 
  Integrated team
  structure

  
  

• 
  Integrated team charters

  
  

• 
  Shared vision statements

  
  

GP 2.10 Review Status
with Higher Level Management

Review the activities, status,
and results of the integrated project management process with higher
level management and resolve issues.

Continuous Only
GG 3 Institutionalize a Defined Process The process is institutionalized as a defined process. This generic goal’s appearance here reflects its location in the continuous representation.

GP 3.1 Establish a
Defined Process

Establish and maintain the
description of a defined integrated project management process.

Elaboration:

Refer
to Table 6.2 on page 95 in Generic Goals and Generic Practices for
more information about the relationship between generic practice 3.1
and the Integrated Project Management process area.

GP 3.2 Collect
Improvement Information

Collect work products, measures,
measurement results, and improvement information derived from
planning and performing the integrated project management process to
support the future use and improvement of the organization’s
processes and process assets.

Elaboration:

Refer
to Table 6.2 on page 95 in Generic Goals and Generic Practices for
more information about the relationship between generic practice 3.2
and the Integrated Project Management process area.

Examples
of work products, measures, measurement results, and improvement
information include the following:

• 
  Project’s
  defined process

  
  

• 
  Number
  of tailoring options exercised by the project to create its defined
  process

  
  

• 
  Interface
  coordination issue trends (i.e., number identified and number
  closed)

  
  

• 
  Number
  of times the PAL is accessed for assets related to project planning
  by project personnel

  
  

• 
  Records
  of expenses related to holding face-to-face meetings versus holding
  meetings using collaborative equipment such as teleconferencing and
  videoconferencing

  
  

IPPD Addition

Examples of work
products, measures, measurement results, and improvement information
also include the following:

• 
  Integrated team charters

  
  

• 
  Project shared vision

  
  

Continuous Only

GG 4 Institutionalize a Quantitatively Managed Process The process is institutionalized as a quantitatively managed process. GP 4.1 Establish Quantitative Objectives for the Process Establish and maintain quantitative objectives for the integrated project management process, which address quality and process performance, based on customer needs and business objectives. GP 4.2 Stabilize Subprocess Performance Stabilize the performance of one or more subprocesses to determine the ability of the integrated project management process to achieve the established quantitative quality and process-performance objectives. GG 5 Institutionalize an Optimizing Process The process is institutionalized as an optimizing process. GP 5.1 Ensure Continuous Process Improvement Ensure continuous improvement of the integrated project management process in fulfilling the relevant business objectives of the organization. GP 5.2 Correct Root Causes of Problems Identify and correct the root causes of defects and other problems in the integrated project management process.

Measurement and
Analysis

A
Support Process Area at Maturity Level 2

Purpose

The
purpose of Measurement and Analysis (MA) is to develop and sustain a
measurement capability that is used to support management information
needs.

Introductory Notes

The
Measurement and Analysis process area involves the following:

• 
  Specifying
  the objectives of measurement and analysis such that they are
  aligned with identified information needs and objectives

  
  

• 
  Specifying
  the measures, analysis techniques, and mechanism for data
  collection, data storage, reporting, and feedback

  
  

• 
  Implementing
  the collection, storage, analysis, and reporting of the data

  
  

• 
  Providing
  objective results that can be used in making informed decisions, and
  taking appropriate corrective actions

  
  

The
integration of measurement and analysis activities into the processes
of the project supports the following:

• 
  Objective
  planning and estimating

  
  

• 
  Tracking
  actual performance against established plans and objectives

  
  

• 
  Identifying
  and resolving process-related issues

  
  

• 
  Providing
  a basis for incorporating measurement into additional processes in
  the future

  
  

The
staff required to implement a measurement capability may or may not
be employed in a separate organization-wide program. Measurement
capability may be integrated into individual projects or other
organizational functions (e.g., quality assurance).

The
initial focus for measurement activities is at the project level.
However, a measurement capability may prove useful for addressing
organization- and/or enterprise-wide information needs. To support
this capability, the measurement activities should support
information needs at multiple levels including the business,
organizational unit, and project to minimize re-work as the
organization matures.

Projects
may choose to store project-specific data and results in a
project-specific repository. When data are shared more widely across
projects, the data may reside in the organization’s measurement
repository.

Measurement
and analysis of the product components provided by suppliers is
essential for effective management of the quality and costs of the
project. It is possible, with careful management of supplier
agreements, to provide insight into the data that support
supplier-performance analysis.

Related Process
Areas

Refer
to the Project Planning process area for more information about
estimating project attributes and other planning information needs.

Refer
to the Project Monitoring and Control process area for more
information about monitoring project performance information needs.

Refer
to the Configuration Management process area for more information
about managing measurement work products.

Refer
to the Requirements Development process area for more information
about meeting customer requirements and related information needs.

Refer
to the Requirements Management process area for more information
about maintaining requirements traceability and related information
needs.

Refer
to the Organizational Process Definition process area for more
information about establishing the organization’s measurement
repository.

Refer
to the Quantitative Project Management process area for more
information about understanding variation and the appropriate use of
statistical analysis techniques.

Specific Goal and
Practice Summary

SG 1 Align Measurement
and Analysis Activities

SP 1.1 Establish
Measurement Objectives

SP 1.2 Specify Measures

SP 1.3 Specify Data
Collection and Storage Procedures

SP 1.4 Specify Analysis
Procedures

SG 2 Provide Measurement
Results

SP 2.1 Collect
Measurement Data

SP 2.2 Analyze
Measurement Data

SP 2.3 Store Data and
Results

SP 2.4 Communicate
Results

Specific Practices
by Goal

SG 1 Align Measurement
and Analysis Activities

Measurement objectives and
activities are aligned with identified information needs and
objectives.

The
specific practices covered under this specific goal may be addressed
concurrently or in any order:

• 
  When
  establishing measurement objectives, experts often think ahead about
  necessary criteria for specifying measures and analysis procedures.
  They also think concurrently about the constraints imposed by data
  collection and storage procedures.

  
  

• 
  It
  often is important to specify the essential analyses that will be
  conducted before attending to details of measurement specification,
  data collection, or storage.

  
  

SP 1.1 Establish
Measurement Objectives

Establish and maintain
measurement objectives that are derived from identified information
needs and objectives.

Measurement
objectives document the purposes for which measurement and analysis
are done, and specify the kinds of actions that may be taken based on
the results of data analyses.

The
sources for measurement objectives may be management, technical,
project, product, or process implementation needs.

The
measurement objectives may be constrained by existing processes,
available resources, or other measurement considerations. Judgments
may need to be made about whether the value of the results will be
commensurate with the resources devoted to doing the work.

Modifications
to identified information needs and objectives may, in turn, be
indicated as a consequence of the process and results of measurement
and analysis.

Sources
of information needs and objectives may include the following:

• 
  Project
  plans

  
  

• 
  Monitoring
  of project performance

  
  

• 
  Interviews
  with managers and others who have information needs

  
  

• 
  Established
  management objectives

  
  

• 
  Strategic
  plans

  
  

• 
  Business
  plans

  
  

• 
  Formal
  requirements or contractual obligations

  
  

• 
  Recurring
  or other troublesome management or technical problems

  
  

• 
  Experiences
  of other projects or organizational entities

  
  

• 
  External
  industry benchmarks

  
  

• 
  Process
  improvement plans

  
  

Example
measurement objectives include the following:

• 
  Reduce
  time to delivery

  
  

• 
  Reduce
  total lifecycle cost

  
  

• 
  Deliver
  specified functionality completely

  
  

• 
  Improve
  prior levels of quality

  
  

• 
  Improve
  prior customer satisfaction ratings

  
  

• 
  Maintain
  and improve the acquirer/supplier relationships

  
  

Refer
to the Project Planning process area for more information about
estimating project attributes and other planning information needs.

Refer
to the Project Monitoring and Control process area for more
information about project performance information needs.

Refer
to the Requirements Development process area for more information
about meeting customer requirements and related information needs.

Refer
to the Requirements Management process area for more information
about maintaining requirements traceability and related information
needs.

Typical
Work Products

1. Measurement
objectives

Subpractices

1. Document
information needs and objectives.

Information
needs and objectives are documented to allow traceability to
subsequent measurement and analysis activities.

2. Prioritize
information needs and objectives.

It
may be neither possible nor desirable to subject all initially
identified information needs to measurement and analysis. Priorities
may also need to be set within the limits of available resources.

3. Document,
review, and update measurement objectives.

It
is important to carefully consider the purposes and intended uses of
measurement and analysis.

The
measurement objectives are documented, reviewed by management and
other relevant stakeholders, and updated as necessary. Doing so
enables traceability to subsequent measurement and analysis
activities, and helps ensure that the analyses will properly address
identified information needs and objectives.

It
is important that users of measurement and analysis results be
involved in setting measurement objectives and deciding on plans of
action. It may also be appropriate to involve those who provide the
measurement data.

4. Provide
feedback for refining and clarifying information needs and objectives
as necessary.

Identified
information needs and objectives may need to be refined and clarified
as a result of setting measurement objectives. Initial descriptions
of information needs may be unclear or ambiguous. Conflicts may arise
between existing needs and objectives. Precise targets on an already
existing measure may be unrealistic.

5. Maintain
traceability of the measurement objectives to the identified
information needs and objectives.

There
must always be a good answer to the question, “Why are we measuring
this?”

Of
course, the measurement objectives may also change to reflect
evolving information needs and objectives.

SP 1.2 Specify
Measures

Specify measures to address the
measurement objectives.

Measurement
objectives are refined into precise, quantifiable measures.

Measures
may be either “base” or “derived.” Data for base measures are
obtained by direct measurement. Data for derived measures come from
other data, typically by combining two or more base measures.

Examples
of commonly used base measures include the following:

• 
  Estimates
  and actual measures of work product size (e.g., number of pages)

  
  

• 
  Estimates
  and actual measures of effort and cost (e.g., number of person
  hours)

  
  

• 
  Quality
  measures (e.g., number of defects by severity)

  
  

Examples
of commonly used derived measures include the following:

• 
  Earned
  Value

  
  

• 
  Schedule
  Performance Index

  
  

• 
  Defect
  density

  
  

• 
  Peer
  review coverage

  
  

• 
  Test
  or verification coverage

  
  

• 
  Reliability
  measures (e.g., mean time to failure)

  
  

• 
  Quality
  measures (e.g., number of defects by severity/total number of
  defects)

  
  

Derived
measures typically are expressed as ratios, composite indices, or
other aggregate summary measures. They are often more quantitatively
reliable and meaningfully interpretable than the base measures used
to generate them.

Typical
Work Products

1. Specifications
of base and derived measures

Subpractices

1. Identify
candidate measures based on documented measurement objectives.

The
measurement objectives are refined into specific measures. The
identified candidate measures are categorized and specified by name
and unit of measure.

2. Identify
existing measures that already address the measurement objectives.

Specifications
for measures may already exist, perhaps established for other
purposes earlier or elsewhere in the organization.

3. Specify
operational definitions for the measures.

Operational
definitions are stated in precise and unambiguous terms. They address
two important criteria as follows:

• 
  Communication:
  What has been measured, how was it measured, what are the units of
  measure, and what has been included or excluded?

  
  

• 
  Repeatability:
  Can the measurement be repeated, given the same definition, to get
  the same results?

  
  

4. Prioritize,
review, and update measures.

Proposed
specifications of the measures are reviewed for their appropriateness
with potential end users and other relevant stakeholders. Priorities
are set or changed, and specifications of the measures are updated as
necessary.

SP 1.3 Specify Data
Collection and Storage Procedures

Specify how measurement data
will be obtained and stored.

Explicit
specification of collection methods helps ensure that the right data
are collected properly. It may also aid in further clarifying
information needs and measurement objectives.

Proper
attention to storage and retrieval procedures helps ensure that data
are available and accessible for future use.

Typical
Work Products

1. Data
collection and storage procedures

2. Data
collection tools

Subpractices

1. Identify
existing sources of data that are generated from current work
products, processes, or transactions.

Existing
sources of data may already have been identified when specifying the
measures. Appropriate collection mechanisms may exist whether or not
pertinent data have already been collected.

2. Identify
measures for which data are needed, but are not currently available.

3. Specify
how to collect and store the data for each required measure.

Explicit
specifications are made of how, where, and when the data will be
collected. Procedures for collecting valid data are specified. The
data are stored in an accessible manner for analysis, and it is
determined whether they will be saved for possible reanalysis or
documentation purposes.

Questions
to be considered typically include the following:

• 
  Have the
  frequency of collection and the points in the process where
  measurements will be made been determined?

  
  

• 
  Has the timeline
  that is required to move measurement results from the points of
  collection to repositories, other databases, or end users been
  established?

  
  

• 
  Who is
  responsible for obtaining the data?

  
  

• 
  Who is
  responsible for data storage, retrieval, and security?

  
  

• 
  Have necessary
  supporting tools been developed or acquired?

  
  

4. Create
data collection mechanisms and process guidance.

Data
collection and storage mechanisms are well integrated with other
normal work processes. Data collection mechanisms may include manual
or automated forms and templates. Clear, concise guidance on correct
procedures is available to those responsible for doing the work.
Training is provided as necessary to clarify the processes necessary
for collection of complete and accurate data and to minimize the
burden on those who must provide and record the data.

5. Support
automatic collection of the data where appropriate and feasible.

Automated
support can aid in collecting more complete and accurate data.

Examples
of such automated support include the following:

• 
  Time stamped
  activity logs

  
  

• 
  Static or dynamic
  analyses of artifacts

  
  

However,
some data cannot be collected without human intervention (e.g.,
customer satisfaction or other human judgments), and setting up the
necessary infrastructure for other automation may be costly.

6. Prioritize,
review, and update data collection and storage procedures.

Proposed
procedures are reviewed for their appropriateness and feasibility
with those who are responsible for providing, collecting, and storing
the data. They also may have useful insights about how to improve
existing processes, or be able to suggest other useful measures or
analyses.

7. Update
measures and measurement objectives as necessary.

Priorities
may need to be reset based on the following:

• 
  The importance of
  the measures

  
  

• 
  The amount of
  effort required to obtain the data

  
  

Considerations
include whether new forms, tools, or training would be required to
obtain the data.

SP 1.4 Specify
Analysis Procedures

Specify how measurement data
will be analyzed and reported.

Specifying
the analysis procedures in advance ensures that appropriate analyses
will be conducted and reported to address the documented measurement
objectives (and thereby the information needs and objectives on which
they are based). This approach also provides a check that the
necessary data will in fact be collected.

Typical
Work Products

1. Analysis
specifications and procedures

2. Data
analysis tools

Subpractices

1. Specify
and prioritize the analyses that will be conducted and the reports
that will be prepared.

Early
attention should be paid to the analyses that will be conducted and
to the manner in which the results will be reported. These should
meet the following criteria:

• 
  The analyses
  explicitly address the documented measurement objectives

  
  

• 
  Presentation of
  the results is clearly understandable by the audiences to whom the
  results are addressed

  
  

Priorities
may have to be set within available resources.

2. Select
appropriate data analysis methods and tools.

Refer
to the Select Measures and Analytic Techniques and Apply Statistical
Methods to Understand Variation specific practices of the
Quantitative Project Management process area for more information
about the appropriate use of statistical analysis techniques and
understanding variation, respectively.

Issues
to be considered typically include the following:

• 
  Choice of visual
  display and other presentation techniques (e.g., pie charts, bar
  charts, histograms, radar charts, line graphs, scatter plots, or
  tables)

  
  

• 
  Choice of
  appropriate descriptive statistics (e.g., arithmetic mean, median,
  or mode)

  
  

• 
  Decisions about
  statistical sampling criteria when it is impossible or unnecessary
  to examine every data element

  
  

• 
  Decisions about
  how to handle analysis in the presence of missing data elements

  
  

• 
  Selection of
  appropriate analysis tools

  
  

Descriptive
statistics are typically used in data analysis to do the following:

• 
  Examine
  distributions on the specified measures (e.g., central tendency,
  extent of variation, or data points exhibiting unusual variation)

  
  

• 
  Examine the
  interrelationships among the specified measures (e.g., comparisons
  of defects by phase of the product’s lifecycle or by product
  component)

  
  

• 
  Display changes
  over time

  
  

3. Specify
administrative procedures for analyzing the data and communicating
the results.

Issues
to be considered typically include the following:

• 
  Identifying the
  persons and groups responsible for analyzing the data and presenting
  the results

  
  

• 
  Determining the
  timeline to analyze the data and present the results

  
  

• 
  Determining the
  venues for communicating the results (e.g., progress reports,
  transmittal memos, written reports, or staff meetings)

  
  

4. Review
and update the proposed content and format of the specified analyses
and reports.

All
of the proposed content and format are subject to review and
revision, including analytic methods and tools, administrative
procedures, and priorities. The relevant stakeholders consulted
should include intended end users, sponsors, data analysts, and data
providers.

5. Update
measures and measurement objectives as necessary.

Just
as measurement needs drive data analysis, clarification of analysis
criteria can affect measurement. Specifications for some measures may
be refined further based on the specifications established for data
analysis procedures. Other measures may prove to be unnecessary, or a
need for additional measures may be recognized.

The
exercise of specifying how measures will be analyzed and reported may
also suggest the need for refining the measurement objectives
themselves.

6. Specify
criteria for evaluating the utility of the analysis results and for
evaluating the conduct of the measurement and analysis activities.

Criteria
for evaluating the utility of the analysis might address the extent
to which the following apply:

• 
  The results are
  (1) provided on a timely basis, (2) understandable, and (3) used for
  decision making.

  
  

• 
  The work does not
  cost more to perform than is justified by the benefits that it
  provides.

  
  

Criteria
for evaluating the conduct of the measurement and analysis might
include the extent to which the following apply:

• 
  The amount of
  missing data or the number of flagged inconsistencies is beyond
  specified thresholds.

  
  

• 
  There is
  selection bias in sampling (e.g., only satisfied end users are
  surveyed to evaluate end-user satisfaction, or only unsuccessful
  projects are evaluated to determine overall productivity).

  
  

• 
  The measurement
  data are repeatable (e.g., statistically reliable).

  
  

• 
  Statistical
  assumptions have been satisfied (e.g., about the distribution of
  data or about appropriate measurement scales).

  
  

SG 2 Provide
Measurement Results

Measurement results, which
address identified information needs and objectives, are provided.

The
primary reason for doing measurement and analysis is to address
identified information needs and objectives. Measurement results
based on objective evidence can help to monitor performance, fulfill
contractual obligations, make informed management and technical
decisions, and enable corrective actions to be taken.

SP 2.1 Collect
Measurement Data

Obtain specified measurement
data.

The
data necessary for analysis are obtained and checked for completeness
and integrity.

Typical
Work Products

1. Base
and derived measurement data sets

2. Results
of data integrity tests

Subpractices

1. Obtain
the data for base measures.

Data
are collected as necessary for previously used as well as for newly
specified base measures. Existing data are gathered from project
records or from elsewhere in the organization.

Note
that data that were collected earlier may no longer be available for
reuse in existing databases, paper records, or formal repositories.

2. Generate
the data for derived measures.

Values
are newly calculated for all derived measures.

3. Perform
data integrity checks as close to the source of the data as possible.

All
measurements are subject to error in specifying or recording data. It
is always better to identify such errors and to identify sources of
missing data early in the measurement and analysis cycle.

Checks
can include scans for missing data, out-of-bounds data values, and
unusual patterns and correlation across measures. It is particularly
important to do the following:

• 
  Test and correct
  for inconsistency of classifications made by human judgment (i.e.,
  to determine how frequently people make differing classification
  decisions based on the same information, otherwise known as
  “inter-coder reliability”).

  
  

• 
  Empirically
  examine the relationships among the measures that are used to
  calculate additional derived measures. Doing so can ensure that
  important distinctions are not overlooked and that the derived
  measures convey their intended meanings (otherwise known as
  “criterion validity”).

  
  

SP 2.2 Analyze
Measurement Data

Analyze and interpret
measurement data.

The
measurement data are analyzed as planned, additional analyses are
conducted as necessary, results are reviewed with relevant
stakeholders, and necessary revisions for future analyses are noted.

Typical
Work Products

1. Analysis
results and draft reports

Subpractices

1. Conduct
initial analyses, interpret the results, and draw preliminary
conclusions.

The
results of data analyses are rarely self-evident. Criteria for
interpreting the results and drawing conclusions should be stated
explicitly.

2. Conduct
additional measurement and analysis as necessary, and prepare results
for presentation.

The
results of planned analyses may suggest (or require) additional,
unanticipated analyses. In addition, they may identify needs to
refine existing measures, to calculate additional derived measures,
or even to collect data for additional base measures to properly
complete the planned analysis. Similarly, preparing the initial
results for presentation may identify the need for additional,
unanticipated analyses.

3. Review
the initial results with relevant stakeholders.

It
may be appropriate to review initial interpretations of the results
and the way in which they are presented before disseminating and
communicating them more widely.

Reviewing
the initial results before their release may prevent needless
misunderstandings and lead to improvements in the data analysis and
presentation.

Relevant
stakeholders with whom reviews may be conducted include intended end
users and sponsors, as well as data analysts and data providers.

4. Refine
criteria for future analyses.

Valuable
lessons that can improve future efforts are often learned from
conducting data analyses and preparing results. Similarly, ways to
improve measurement specifications and data collection procedures may
become apparent, as may ideas for refining identified information
needs and objectives.

SP 2.3 Store Data and
Results

Manage and store measurement
data, measurement specifications, and analysis results.

Storing
measurement-related information enables the timely and cost-effective
future use of historical data and results. The information also is
needed to provide sufficient context for interpretation of the data,
measurement criteria, and analysis results.

Information
stored typically includes the following:

• 
  Measurement
  plans

  
  

• 
  Specifications
  of measures

  
  

• 
  Sets
  of data that have been collected

  
  

• 
  Analysis
  reports and presentations

  
  

The
stored information contains or references the information needed to
understand and interpret the measures and to assess them for
reasonableness and applicability (e.g., measurement specifications
used on different projects when comparing across projects).

Data
sets for derived measures typically can be recalculated and need not
be stored. However, it may be appropriate to store summaries based on
derived measures (e.g., charts, tables of results, or report prose).

Interim
analysis results need not be stored separately if they can be
efficiently reconstructed.

Projects
may choose to store project-specific data and results in a
project-specific repository. When data are shared more widely across
projects, the data may reside in the organization’s measurement
repository.

Refer
to the Establish the Organization’s Measurement Repository specific
practice of the Organizational Process Definition process area for
more information about establishing the organization’s measurement
repository.

Refer
to the Configuration Management process area for information about
managing measurement work products.

Typical
Work Products

1. Stored
data inventory

Subpractices

1. Review
the data to ensure their completeness, integrity, accuracy, and
currency.

2. Store
the data according to the data storage procedures.

3. Make
the stored contents available for use only by appropriate groups and
personnel.

4. Prevent
the stored information from being used inappropriately.

Examples
of ways to prevent inappropriate use of the data and related
information include controlling access to data and educating people
on the appropriate use of data.

Examples
of inappropriate use include the following:

• 
  Disclosure of
  information that was provided in confidence

  
  

• 
  Faulty
  interpretations based on incomplete, out-of-context, or otherwise
  misleading information

  
  

• 
  Measures used to
  improperly evaluate the performance of people or to rank projects

  
  

• 
  Impugning the
  integrity of specific individuals

  
  

SP 2.4 Communicate
Results

Report results of measurement
and analysis activities to all relevant stakeholders.

The
results of the measurement and analysis process are communicated to
relevant stakeholders in a timely and usable fashion to support
decision making and assist in taking corrective action.

Relevant
stakeholders include intended users, sponsors, data analysts, and
data providers.

Typical
Work Products

1. Delivered
reports and related analysis results

2. Contextual
information or guidance to aid in the interpretation of analysis
results

Subpractices

1. Keep
relevant stakeholders apprised of measurement results on a timely
basis.

Measurement
results are communicated in time to be used for their intended
purposes. Reports are unlikely to be used if they are distributed
with little effort to follow up with those who need to know the
results.

To
the extent possible and as part of the normal way they do business,
users of measurement results are kept personally involved in setting
objectives and deciding on plans of action for measurement and
analysis. The users are regularly kept apprised of progress and
interim results.

Refer
to the Project Monitoring and Control process area for more
information about the use of measurement results.

2. Assist
relevant stakeholders in understanding the results.

Results
are reported in a clear and concise manner appropriate to the
methodological sophistication of the relevant stakeholders. They are
understandable, easily interpretable, and clearly tied to identified
information needs and objectives.

The
data are often not self-evident to practitioners who are not
measurement experts. Measurement choices should be explicitly clear
about the following:

• 
  How and why the
  base and derived measures were specified

  
  

• 
  How the data were
  obtained

  
  

• 
  How to interpret
  the results based on the data analysis methods that were used

  
  

• 
  How the results
  address information needs

  
  

Examples
of actions to assist in understanding of results include the
following:

• 
  Discussing the
  results with the relevant stakeholders

  
  

• 
  Providing a
  transmittal memo that provides background and explanation

  
  

• 
  Briefing users on
  the results

  
  

• 
  Providing
  training on the appropriate use and understanding of measurement
  results

  
  

Generic Practices
by Goal

Continuous Only

GG 1 Achieve Specific Goals The process supports and enables achievement of the specific goals of the process area by transforming identifiable input work products to produce identifiable output work products. GP 1.1 Perform Specific Practices Perform the specific practices of the measurement and analysis process to develop work products and provide services to achieve the specific goals of the process area.

GG 2 Institutionalize
a Managed Process

The process is institutionalized
as a managed process.

GP 2.1 Establish an
Organizational Policy

Establish and maintain an
organizational policy for planning and performing the measurement and
analysis process.

Elaboration:

This
policy establishes organizational expectations for aligning
measurement objectives and activities with identified information
needs and objectives and for providing measurement results.

GP 2.2 Plan the
Process

Establish and maintain the plan
for performing the measurement and analysis process.

Elaboration:

This
plan for performing the measurement and analysis process can be
included in (or referenced by) the project plan, which is described
in the Project Planning process area.

GP 2.3 Provide
Resources

Provide adequate resources for
performing the measurement and analysis process, developing the work
products, and providing the services of the process.

Elaboration:

Measurement
personnel may be employed full time or part time. A measurement group
may or may not exist to support measurement activities across
multiple projects.

Examples
of other resources provided include the following tools:

• 
  Statistical
  packages

  
  

• 
  Packages
  that support data collection over networks

  
  

GP 2.4 Assign
Responsibility

Assign responsibility and
authority for performing the process, developing the work products,
and providing the services of the measurement and analysis process.

GP 2.5 Train People

Train the people performing or
supporting the measurement and analysis process as needed.

Elaboration:

Examples
of training topics include the following:

• 
  Statistical
  techniques

  
  

• 
  Data
  collection, analysis, and reporting processes

  
  

• 
  Development
  of goal-related measurements (e.g., Goal Question Metric)

  
  

GP 2.6 Manage
Configurations

Place designated work products
of the measurement and analysis process under appropriate levels of
control.

Elaboration:

Examples
of work products placed under control include the following:

• 
  Specifications
  of base and derived measures

  
  

• 
  Data
  collection and storage procedures

  
  

• 
  Base
  and derived measurement data sets

  
  

• 
  Analysis
  results and draft reports

  
  

• 
  Data
  analysis tools

  
  

GP 2.7 Identify and
Involve Relevant Stakeholders

Identify and involve the
relevant stakeholders of the measurement and analysis process as
planned.

Elaboration:

Examples
of activities for stakeholder involvement include the following:

• 
  Establishing
  measurement objectives and procedures

  
  

• 
  Assessing
  measurement data

  
  

• 
  Providing
  meaningful feedback to those responsible for providing the raw data
  on which the analysis and results depend

  
  

GP 2.8 Monitor and
Control the Process

Monitor and control the
measurement and analysis process against the plan for performing the
process and take appropriate corrective action.

Elaboration:

Examples
of measures and work products used in monitoring and controlling
include the following:

• 
  Percentage
  of projects using progress and performance measures

  
  

• 
  Percentage
  of measurement objectives addressed

  
  

• 
  Schedule
  for collection and review of measurement data

  
  

GP 2.9 Objectively
Evaluate Adherence

Objectively evaluate adherence
of the measurement and analysis process against its process
description, standards, and procedures, and address noncompliance.

Elaboration:

Examples
of activities reviewed include the following:

• 
  Aligning
  measurement and analysis activities

  
  

• 
  Providing
  measurement results

  
  

Examples
of work products reviewed include the following:

• 
  Specifications
  of base and derived measures

  
  

• 
  Data
  collection and storage procedures

  
  

• 
  Analysis
  results and draft reports

  
  

GP 2.10 Review Status
with Higher Level Management

Review the activities, status,
and results of the measurement and analysis process with higher level
management and resolve issues.

Staged Only
GG3 and its practices do not apply for a maturity level 2 rating, but do apply for a maturity level 3 rating and above.

Continuous/Maturity Levels 3 - 5 Only

GG 3 Institutionalize a Defined Process The process is institutionalized as a defined process. GP 3.1 Establish a Defined Process Establish and maintain the description of a defined measurement and analysis process. GP 3.2 Collect Improvement Information Collect work products, measures, measurement results, and improvement information derived from planning and performing the measurement and analysis process to support the future use and improvement of the organization’s processes and process assets. Elaboration: Examples of work products, measures, measurement results, and improvement information include the following: Data currency status Results of data integrity tests Data analysis reports

Continuous Only

GG 4 Institutionalize a Quantitatively Managed Process The process is institutionalized as a quantitatively managed process. GP 4.1 Establish Quantitative Objectives for the Process Establish and maintain quantitative objectives for the measurement and analysis process, which address quality and process performance, based on customer needs and business objectives. GP 4.2 Stabilize Subprocess Performance Stabilize the performance of one or more subprocesses to determine the ability of the measurement and analysis process to achieve the established quantitative quality and process-performance objectives. GG 5 Institutionalize an Optimizing Process The process is institutionalized as an optimizing process. GP 5.1 Ensure Continuous Process Improvement Ensure continuous improvement of the measurement and analysis process in fulfilling the relevant business objectives of the organization. GP 5.2 Correct Root Causes of Problems Identify and correct the root causes of defects and other problems in the measurement and analysis process.

Organizational
Innovation and Deployment

A
Process Management Process Area at Maturity Level 5

Purpose

The
purpose of Organizational Innovation and Deployment (OID) is to
select and deploy incremental and innovative improvements that
measurably improve the organization’s processes and technologies.
The improvements support the organization’s quality and
process-performance objectives as derived from the organization’s
business objectives.

Introductory Notes

The
Organizational Innovation and Deployment process area enables the
selection and deployment of improvements that can enhance the
organization’s ability to meet its quality and process-performance
objectives. (See the definition of “quality and process-performance
objectives” in the glossary.) The term “improvement,” as used
in this process area, refers to all of the ideas (proven and
unproven) that would change the organization’s processes and
technologies to better meet the organization’s quality and
process-performance objectives.

Quality
and process-performance objectives that this process area might
address include the following:

• 
  Improved
  product quality (e.g., functionality, performance)

  
  

• 
  Increased
  productivity

  
  

• 
  Decreased
  cycle time

  
  

• 
  Greater
  customer and end-user satisfaction

  
  

• 
  Shorter
  development or production time to change functionality or add new
  features, or adapt to new technologies

  
  

• 
  Reduce
  delivery time

  
  

• 
  Reduce
  time to adapt to new technologies and business needs

  
  

Achievement
of these objectives depends on the successful establishment of an
infrastructure that enables and encourages all people in the
organization to propose potential improvements to the organization’s
processes and technologies. Achievement of these objectives also
depends on being able to effectively evaluate and deploy proposed
improvements to the organization’s processes and technologies. All
members of the organization can participate in the organization’s
process- and technology-improvement activities. Their proposals are
systematically gathered and addressed.

Pilots
are conducted to evaluate significant changes involving untried,
high-risk, or innovative improvements before they are broadly
deployed.

Process
and technology improvements that will be deployed across the
organization are selected from process- and technology-improvement
proposals based on the following criteria:

• 
  A
  quantitative understanding of the organization’s current quality
  and process performance

  
  

• 
  The
  organization’s quality and process-performance objectives

  
  

• 
  Estimates
  of the improvement in quality and process performance resulting from
  deploying the process and technology improvements

  
  

• 
  Estimated
  costs of deploying process and technology improvements, and the
  resources and funding available for such deployment

  
  

The
expected benefits added by the process and technology improvements
are weighed against the cost and impact to the organization. Change
and stability must be balanced carefully. Change that is too great or
too rapid can overwhelm the organization, destroying its investment
in organizational learning represented by organizational process
assets. Rigid stability can result in stagnation, allowing the
changing business environment to erode the organization’s business
position.

Improvements
are deployed, as appropriate, to new and ongoing projects.

In
this process area, the term “process and technology improvements”
refers to incremental and innovative improvements to processes and
also to process or product technologies (including project work
environments).

The
informative material in this process area is written with the
assumption that the specific practices are applied to a
quantitatively managed process. The specific practices of this
process area may be applicable, but with reduced value, if the
assumption is not met.

The
specific practices in this process area complement and extend those
found in the Organizational Process Focus process area. The focus of
this process area is process improvement that is based on a
quantitative knowledge of the organization’s set of standard
processes and technologies and their expected quality and performance
in predictable situations. In the Organizational Process Focus
process area, no assumptions are made about the quantitative basis of
improvement.

Related Process
Areas

Refer
to the Organizational Process Definition process area for more
information about incorporating the deployed process improvements
into organizational process assets.

Refer
to the Organizational Process Focus process area for more information
about soliciting, collecting, and handling process improvement
proposals and coordinating the deployment of process improvement into
the project’s defined processes.

Refer
to the Organizational Training process area for more information
about providing updated training to support deployment of process and
technology improvements.

Refer
to the Organizational Process Performance process area for more
information about quality and process-performance objectives and
process-performance models. Quality and process-performance
objectives are used to analyze and select process- and
technology-improvement proposals for deployment. Process-performance
models are used to quantify the impact and benefits of innovations.

Refer
to the Measurement and Analysis process area for more information
about establishing objectives for measurement and analysis,
specifying the measures and analyses to be performed, obtaining and
analyzing measures, and reporting results.

Refer
to the Integrated Project Management process area for more
information about coordinating the deployment of process and
technology improvements into the project’s defined process and
project work environment.

Refer
to the Decision Analysis and Resolution process area for more
information about formal evaluations related to improvement proposals
and innovations.

Specific Goal and
Practice Summary

SG 1 Select Improvements

SP 1.1 Collect and
Analyze Improvement Proposals

SP 1.2 Identify and
Analyze Innovations

SP 1.3 Pilot Improvements

SP 1.4 Select
Improvements for Deployment

SG 2 Deploy Improvements

SP 2.1 Plan the
Deployment

SP 2.2 Manage the
Deployment

SP 2.3 Measure
Improvement Effects

Specific Practices
by Goal

SG 1 Select
Improvements

Process and technology
improvements, which contribute to meeting quality and
process-performance objectives, are selected.

SP 1.1 Collect and
Analyze Improvement Proposals

Collect and analyze process- and
technology-improvement proposals.

Each
process- and technology-improvement proposal must be analyzed.

Simple
process and technology improvements, with well-understood benefits
and effects, will not usually undergo detailed evaluations.

Examples
of simple process and technology improvements include the following:

• 
  Add
  an item to a peer review checklist.

  
  

• 
  Combine
  the technical review and management review for suppliers into a
  single technical/management review.

  
  

Typical
Work Products

1. Analyzed
process- and technology-improvement proposals

Subpractices

1. Collect
process- and technology-improvement proposals.

A
process- and technology-improvement proposal documents proposed
incremental and innovative improvements to specific processes and
technologies. Managers and staff in the organization, as well as
customers, end users, and suppliers can submit process- and
technology-improvement proposals. Process and technology improvements
may be implemented at the local level before being proposed for the
organization.

Examples
of sources for process- and technology-improvement proposals include
the following:

• 
  Findings and
  recommendations from process appraisals

  
  

• 
  The
  organization’s quality and process-performance objectives

  
  

• 
  Analysis of data
  about customer and end-user problems as well as customer and
  end-user satisfaction

  
  

• 
  Analysis of data
  about project performance compared to quality and productivity
  objectives

  
  

• 
  Analysis of
  technical performance measures

  
  

• 
  Results of
  process and product benchmarking efforts

  
  

• 
  Analysis of data
  on defect causes

  
  

• 
  Measured
  effectiveness of process activities

  
  

• 
  Measured
  effectiveness of project work environments

  
  

• 
  Examples of
  process- and technology-improvement proposals that were successfully
  adopted elsewhere

  
  

• 
  Feedback on
  previously submitted process- and technology-improvement proposals

  
  

• 
  Spontaneous ideas
  from managers and staff

  
  

Refer
to the Organizational Process Focus process area for more information
about process- and technology-improvement proposals.

2. Analyze
the costs and benefits of process- and technology-improvement
proposals as appropriate.

Process-
and technology-improvement proposals that have a large
cost-to-benefit ratio are rejected.

Criteria
for evaluating costs and benefits include the following:

• 
  Contribution
  toward meeting the organization’s quality and process-performance
  objectives

  
  

• 
  Effect on
  mitigating identified project and organizational risks

  
  

• 
  Ability to
  respond quickly to changes in project requirements, market
  situations, and the business environment

  
  

• 
  Effect on related
  processes and associated assets

  
  

• 
  Cost of defining
  and collecting data that supports the measurement and analysis of
  the process- and technology-improvement proposal

  
  

• 
  Expected life
  span of the proposal

  
  

Process-
and technology-improvement proposals that would not improve the
organization’s processes are rejected.

Process-performance
models provide insight into the effect of process changes on process
capability and performance.

Refer
to the Organizational Process Performance process area for more
information about process-performance models.

3. Identify
the process- and technology-improvement proposals that are
innovative.

Innovative
improvements are also identified and analyzed in the Identify and
Analyze Innovations specific practice.

Whereas
this specific practice analyzes proposals that have been passively
collected, the purpose of the Identify and Analyze Innovations
specific practice is to actively search for and locate innovative
improvements. The search primarily involves looking outside the
organization.

Innovative
improvements are typically identified by reviewing process- and
technology-improvement proposals or by actively investigating and
monitoring innovations that are in use in other organizations or are
documented in research literature. Innovation may be inspired by
internal improvement objectives or by the external business
environment.

Innovative
improvements are typically major changes to the process that
represent a break from the old way of doing things (e.g., changing
the lifecycle model). Innovative improvements may also include
changes in the products that support, enhance, or automate the
process (e.g., using off-the-shelf products to support the process).

Examples
of innovative improvements include the following:

• 
  Advances in
  computer and related hardware products

  
  

• 
  New support tools

  
  

• 
  New techniques,
  methodologies, processes, or lifecycle models

  
  

• 
  New interface
  standards

  
  

• 
  New reusable
  components

  
  

• 
  New management
  techniques

  
  

• 
  New
  quality-improvement techniques

  
  

• 
  New process
  development and deployment support tools

  
  

4. Identify
potential barriers and risks to deploying each process- and
technology-improvement proposal.

Examples
of barriers to deploying process and technology improvements include
the following:

• 
  Turf guarding and
  parochial perspectives

  
  

• 
  Unclear or weak
  business rationale

  
  

• 
  Lack of
  short-term benefits and visible successes

  
  

• 
  Unclear picture
  of what is expected from everyone

  
  

• 
  Too many changes
  at the same time

  
  

• 
  Lack of
  involvement and support of relevant stakeholders

  
  

Examples
of risk factors that affect the deployment of process and technology
improvements include the following:

• 
  Compatibility of
  the improvement with existing processes, values, and skills of
  potential end users

  
  

• 
  Complexity of the
  improvement

  
  

• 
  Difficulty
  implementing the improvement

  
  

• 
  Ability to
  demonstrate the value of the improvement before widespread
  deployment

  
  

• 
  Justification for
  large, up-front investments in areas such as tools and training

  
  

• 
  Inability to
  overcome “technology drag” where the current implementation is
  used successfully by a large and mature installed base of end users

  
  

5. Estimate
the cost, effort, and schedule required for deploying each process-
and technology-improvement proposal.

6. Select
the process- and technology-improvement proposals to be piloted
before broadscale deployment.

Since
innovations, by definition, usually represent a major change, most
innovative improvements will be piloted.

7. Document
the results of the evaluation of each process- and
technology-improvement proposal.

8. Monitor
the status of each process- and technology-improvement proposal.

SP 1.2 Identify and
Analyze Innovations

Identify and analyze innovative
improvements that could increase the organization’s quality and
process performance.

The
specific practice, Collect and Analyze Improvement Proposals,
analyzes proposals that are passively collected. The purpose of this
specific practice is to actively search for, locate, and analyze
innovative improvements. This search primarily involves looking
outside the organization.

Typical
Work Products

1. Candidate
innovative improvements

2. Analysis
of proposed innovative improvements

Subpractices

1. Analyze
the organization’s set of standard processes to determine areas where
innovative improvements would be most helpful.

These
analyses are performed to determine which subprocesses are critical
to achieving the organization’s quality and process-performance
objectives and which ones are good candidates to be improved.

2. Investigate
innovative improvements that may improve the organization’s set of
standard processes.

Investigating
innovative improvements involves the following:

• 
  Systematically
  maintaining awareness of leading relevant technical work and
  technology trends

  
  

• 
  Periodically
  searching for commercially available innovative improvements

  
  

• 
  Collecting
  proposals for innovative improvements from the projects and the
  organization

  
  

• 
  Systematically
  reviewing processes and technologies used externally and comparing
  them to those used within the organization

  
  

• 
  Identifying areas
  where innovative improvements have been used successfully, and
  reviewing data and documentation of experience using these
  improvements

  
  

• 
  Identifying
  improvements that integrate new technology into products and project
  work environments

  
  

3. Analyze
potential innovative improvements to understand their effects on
process elements and predict their influence on the process.

Process-performance
models can provide a basis for analyzing possible effects of changes
to process elements.

Refer
to the Organizational Process Performance process area for more
information about process-performance models.

4. Analyze
the costs and benefits of potential innovative improvements.

Innovative
improvements that have a very large cost-to-benefit ratio are
rejected.

5. Create
process- and technology-improvement proposals for those innovative
improvements that would result in improving the organization’s
processes or technologies.

6. Select
the innovative improvements to be piloted before broadscale
deployment.

Since
innovations, by definition, usually represent a major change, most
innovative improvements will be piloted.

7. Document
the results of the evaluations of innovative improvements.

SP 1.3 Pilot
Improvements

Pilot process and technology
improvements to select which ones to implement.

Pilots
are performed to assess new and unproven major changes before they
are broadly deployed, as appropriate.

The
implementation of this specific practice may overlap with the
implementation of the Implement the Action Proposals specific
practice in the Causal Analysis and Resolution process area (e.g.,
when causal analysis and resolution is implemented organizationally
or across multiple projects).

Typical
Work Products

1. Pilot
evaluation reports

2. Documented
lessons learned from pilots

Subpractices

1. Plan
the pilots.

When
planning pilots, it is critical to define quantitative criteria to be
used for evaluating pilot results.

2. Review
and get relevant stakeholder agreement on the plans for the pilots.

3. Consult
with and assist the people performing the pilots.

4. Perform
each pilot in an environment that is characteristic of the
environment present in a broadscale deployment.

5. Track
the pilots against their plans.

6. Review
and document the results of pilots.

Pilot
results are evaluated using the quantitative criteria defined during
pilot planning. Reviewing and documenting the results of pilots
usually involves the following:

• 
  Deciding whether
  to terminate the pilot, replan and continue the pilot, or proceed
  with deploying the process and technology improvement

  
  

• 
  Updating the
  disposition of process- and technology-improvement proposals
  associated with the pilot

  
  

• 
  Identifying and
  documenting new process- and technology-improvement proposals as
  appropriate

  
  

• 
  Identifying and
  documenting lessons learned and problems encountered during the
  pilot

  
  

SP 1.4 Select
Improvements for Deployment

Select process and technology
improvements for deployment across the organization.

Selection
of process and technology improvements for deployment across the
organization is based on quantifiable criteria derived from the
organization’s quality and process-performance objectives.

Typical
Work Products

1. Process
and technology improvements selected for deployment