This chapter covers some of the things to consider when combining or aligning multiple process improvement initiatives. Considerations include process improvement team structure, integration of existing procedures, measurement programs, and training programs. Different improvement models have placed different levels of importance on some of these areas. This has naturally resulted in different levels of implementation across the disciplines.
None of the ideas presented in this chapter are difficult to understand. Mainly, they concern understanding the policies, processes, procedures, plans, courses, and people you currently have in place, understanding how they fit together within the expanded scope of the CMMI, and the vision the organization has created for its process improvement journey.
While we have presented these concepts in a simple,
straightforward fashion, this effort actually will take many hours
of hard work. Do not underestimate the level of effort required to
successfully accomplish these
1. Chapter 16 is our "meat and potatoes" chapter on policies, processes, and procedures that will give you more details on some of these concepts, along with Chapter 14 that discusses documentation guidelines.
2. Measures in this section refer to both base and derived
measures. Base measures are simple values of some attribute, for
3. We really do mean many, but not all. We have had the
opportunity to work with both systems and acquisition program that
exhibit high measure maturity but these are the exceptional cases;
and while it may be
The authors of this book do not make any claims as to these arguments. We believe the readers should be able to make up their own minds.
Before continuing, let us discuss some basic terms to avoid any confusion later.
There seems to be no real agreement as to what systems engineering really is. The Systems Engineering Capability Maturity Model, version 1.1, states that "Systems Engineering is the selective application of scientific and engineering efforts to:
Transform operational need into descriptions of the system configuration which best satisfies operational need according to measures of effectiveness
Integrate efforts of all engineering disciplines and specialties into the total engineering effort."
The definition of Systems Engineering from the draft version 0.5 of the Systems Engineering Capability Model EIA 731-1 states that "Systems Engineering is an inter-disciplinary approach and means to enable the realization of successful systems."
The CMMI v1.1 defines Systems Engineering as:
The interdisciplinary approach
governingthe total technical and managerialeffort required to transform a set of customer needs, expectations, and constraints into a product solution, and support that solution, throughout the product's life. This includes the definition of technical performance measures , the integration of engineering specialties towards the establishment of a product architecture, and the definition of supporting life-cycle processes that balance cost, performance, and scheduled objectives.
What do these definitions mean as they relate to CMMI?
Basically, Systems Engineering covers the development of total
may not include
Systems Engineering integrates all
This covers the development of software-focused systems.
Projects begin once a software project manager is assigned and
funding has been received. Software Engineering may be a subset of
Systems Engineering or it may stand alone as
its own area of focus. It is possible to have some systems that are
entirely made up of
This covers the usage of large product development
This covers the identification of a need, selection of
This is the architecture in use by the Software CMM. This
structure focuses an organization's improvement activities on
undertaking the practices depicted in each process area (PA) within
each level. For example, an organization would choose to attain
Level 2 (by
Staged models provide guidance to organizations on the order of improvement activities they should undertake, based on (Key) Process Areas at each stage/maturity level. Performing practices in the appropriate process area at a given level will help stabilize projects, thus allowing the execution of further improvement activities. Incremental improvement is supported in each maturity level/stage because that stage contains a collection of process areas on which to focus current activities. 
This is the architecture in use by the systems engineering
models. This structure focuses process improvement on actions to be
completed within process areas. Organizations are expected to
select the process areas of interest to them. Processes may span
different levels and are grouped by functional categories. More
sophistication in implementing the practices for each process area
is expected at the different levels. There are six capability
Continuous models provide more flexibility in defining process improvement programs. They recognize that individual Process Areas are performed at distinct capability or maturity levels. Organizations need to perform an analysis of how the various process areas address the needs of the organization. This exercise also provides an opportunity to gain consensus on the sequence of improvement activities that are appropriate to the organization as a whole. 
These belong to the Staged Representation. These apply to an
process capability and organizational
maturity. Each maturity level comprises a predefined set of process
areas and generic goals. There are five maturity levels, numbered 1
through 5. These
These belong to the Continuous Representation. These apply to an
organization's process improvement achievement for
process area. There are six capability levels, numbered 0 through
6. Capability levels focus on maturing an organization's ability to
perform, control, and improve its performance in a process area.
These levels enable an organization to track,
This stands for Standard CMMI Assessment Method for Process
Improvement, an assessment technique that is similar to both the
former CBA-IPI and Software Capability Evaluation
This encompasses those organizations having 20 or fewer people, in total, supporting software or system development. Each member of a project may wear several hats (i.e., may perform several different roles) as part of normal daily tasks. Projects are short-lived, that is, between three and six weeks.
 Capability Maturity Model (CMM) for Software, version 1.1.
 Capability Maturity Model Integration (CMMI) for Systems Engineering (SE)/Software Engineering (SW)/Integrated Product and Process Development (IPPD), version 1.1.
 Architectural and Functional Comparison of the CMMI Model Representation, Draft, Mike Konrad and Sandy Shrum, December 1999.
 Expanding the Focus of Software Process Improvement to Include Systems Engineering, Kent Johnson and Joe Dindo, TeraQuest Metrics, Incorporated, Crosstalk, October 1998.