[js] [/js]
Benefits in Using CMMI
Capability Maturity Model Integration (CMMI) is a product suite developed and maintained by the Software Engineering Institute (SEI) at Carnegie Mellon Univ. to improve the organisational process maturity in the fields of product development, acquisition, and service delivering. CMMI is a process improvement approach that provides organisations with the essential elements for effective process improvement in software engineering, organisational change, and organisational development. The model defines what processes and activities need to be done and not how these processes and activities are done.
The goal of CMMI is process improvement and CMMI can be thought of as a software process improvement framework. It can be used to guide process improvement across a project, a division, or an entire organisation.
CMMI helps to integrate traditionally separate organisational functions, to set process improvement goals and priorities, to provide guidance for quality processes, and to provide a point of reference for appraising current processes.
The CMMI product suite can provide verification that processes are established, maintained, and implemented consistent with state-of-the-art understanding as to what constitutes "world class performance. However, CMMI will not provide validation that an organisation has the correct product for the customers or market or that a product itself is profitable. Use of the CMMI should therefore be undertaken only in conjunction with a complete understanding of the business goals and objectives, the market and customer base, and the overall product strategy.
The CMMI framework is based on proven practices collected from various organisation and fields of application. It is applicable for any organisation. By implementing CMMI, organisations can be assured of improved processes which give benefits like:
- improved schedule and budget predictability
- improved cycle time
- increased productivity
- improved quality (as measured by defects)
- increased customer satisfaction
- improved employee morale
- increased return on investment
- decreased costs of quality
CMMI is being used worldwide for internal process improvement, as a high-value discriminator in supplier selection, and for monitoring on-going product development operations. Its development and use is founded upon two premises:
- the quality of a product is closely related to the quality of the processes used to perform, manage and support its development throughout product definition, design, construction, and testing.
- improving product quality during the development stages reduces rework, costs and time to market. Adoption of the CMMI represents an organisation's commitment to achieving competitive business goals in the world market. Attaining a formal maturity or capability rating by appraisal provides a company with visible demonstration of its commitment to exceeding its customer's expectations.
The CMMI product suite can provide verification that processes are established, maintained, and implemented consistent with state-of-the-art understanding as to what constitutes "world class performance. However, CMMI will not provide validation that an organisation has the correct product for the customers or market or that a product itself is profitable. Use of the CMMI should therefore be undertaken only in conjunction with a complete understanding of the business goals and objectives, the market and customer base, and the overall product strategy.
Evolution of CMMI
The Capability Maturity Model Integration (CMMI) is based on four pillars:
- Capability — a capable process consistently produces output that is within its specifications. Execution of capable process always gives predictable results. — For more information see my post on Process Capability.
- Maturity — maturity means that whatever the company is doing, the company does it in a way that is well-documented, where everyone knows what is expected of them and performs accordingly, where performance is not dependent on heroes, and where decisions are made on proper analysis of the situation. — For more information see my post on Process Maturity.
- Model — a model is a framework or way of doing something. CMMI only provides a framework to define processes at your organisation and it does not give exact process details. It only guides to implement efficient and effective processes.
- Integration — from a historical point of view CMMI was a fusion of proven practices from a number of different Software and System Development capability maturity models.
CMMI in its current state is an evolution of the SEI's Capability Maturity Model for Software (SW-CMM), the Electronic Industries Alliance Interim Standard EIA/IS 731 model for systems engineering, and the Integrated Product Development Capability Maturity Model (IPD-CMM). SEI had sunset the legacy SW-CMM, and both the CBA IPI and SCE appraisal methods, by December 31, 2005 and thereafter support only the CMMI product suite by now. Historically, in the mid 1980's the US Dept. of Defense needed a way to determine whether their contractors could provide software on time, within budget and to specifications.
SEI at Carnegie Mellon Univ. presented the solution: Capability Maturity Model (CMM) was a way to assess and describe the quality of an organisation's software development. In August 1991 the first version of the Capability Maturity Model for Software (SW-CMM) was published by the SEI, Systems Engineering Capability Maturity Model (SE-CMM) was developed and published. The International Council on Systems Engineering (INCOSE) developed and published the so-called Systems Engineering Capability Assessment Model (SECAM). Other CMMs were additionally developed, including: the Software Acquisition CMM, the People CMM, and the Integrated Product Development CMM. Some business domains also produced their own CMMs. For example, the Electronic Industries Alliance (EIA) published in concert with other partners the so-called Systems Engineering Capability Model (SECM) which was termed later EIA/IS-731. At the long run, several issues arose from these models:
- all of the systems engineering models shared similar principles.
- the content of SW-CMM and the system engineering models overlapped
- the systems engineering models were based on a different representation than the SW-CMM and similar to that of ISO/IEC 15504. — These models employed a continuous representation, whereas SW-CMM employed a staged representation (see below).
CMMI v1.0
CMMI v1.0 was in 2000 the sunrise of integrating the several existing CMM models to one integrated model. CMMI v1.0 included a common set of process areas forming the core of an integrated capability model which integrated process improvement guidance for systems engineering, software engineering, and Integrated Product and Process Development (IPPD). The foundation for the CMMI product suite was laid. The CMMI product suite provided an integrated approach to reduce the redundancy and complexity resulting from the use of separate, multiple capability maturity models (CMMs).
CMMI v1.1
For further model integration, the SEI steering committee formulated more requirements for a Capability Maturity Model-Integrated (CMMI) product suite. The suite should include a framework for generating CMMI products. The generated products should be based on CMMI models for specified disciplines and discipline combinations, training products, assessment materials, glossary terms, and tailoring requirements. The disciplines initially specified include Systems Engineering, Software Engineering, and Integrated Product and Process Development.
CMMI v1.2
CMMI for Development (CMMI-DEV) v.1.2 is an upgrade of CMM v.1.1. The focus of the CMMI v.1.2 effort is on improving the quality of CMMI products and the consistency of how they are applied. Version 1.2 includes the concept of CMMI so-called constellations: these are sets of CMMI components designed to meet the needs of specific areas of business interest.
CMMI v1.3
CMMI High Maturity Lead Appraisers and the CMMI Steering Group at the SEI reviewed subsequently the notion of constellation models v.1.2 at a workshop in late September 2008. As a result, the Steering Group determined that modernising the practices for maturity levels 4 and 5 was a priority. The CMMI Steering Committee targeted CMMI v.1.3 to focus on:
- High maturity
- More effective General Practices
- Appraisal efficiency
- Commonality across the constellations
- All changes to the CMMI product suite (see below) have to meet certain primary criteria.
For more information see my post on CMMI 1.3 — Changes.
CMMI Product Suite
Since CMMI v1.3 the CMMI product suite addresses by the notion "constellations" process areas of different business interest, e.g. it covers the domains of product development (CMMI-DEV), service development (CMMI-SVC), and acquisition (CMMI-ACQ).
The CMMI product suite includes a framework for generating CMMI products, and a set of CMMI products produced by the framework. The framework includes common elements and best features of the existing models as well as rules and methods for generating CMMI products. Users may select discipline specific elements of the CMMI product suite based on their business objectives and mission needs.
The CMMI product suite consists of:
- Framework
- Capability Maturity Model Integration Models
- Training Products
- Assessment/Appraisal Products
- Glossary
CMMI Constellations and Models
Since version 1.2, CMMI includes the concept of constellations. A CMMI constellation is a particular collection of process areas specifically chosen to help improve a given business need within the CMMI framework. It is a set of CMMI components designed to meet the needs of a specific area of interest. With v1.2 three major areas of interest were focused: ((The People CMM (PCMM), which addresses managing and developing organisational workforces, stands apart from CMMI product suite v1.3.))
- Product and service development
- Acquisition
- Services
CMMI constellations give a common approach to implement many Project Management, Organisational Process Management and Supporting process areas of work in an organisation. A constellation can produce one or more related CMMI models — i.e. the published proven practices and related appraisal and training materials. There are now (v.1.3) three areas of business interest covered by related CMMI models: Development, Acquisition, and Services:
- CMMI for Development (CMMI-DEV) addresses product and service development processes.
- CMMI for Acquisition (CMMI-ACQ) addresses supply chain management, acquisition, and outsourcing processes in government and industry.
- CMMI for Services (CMMI-SVC) addresses guidance for delivering services within an organisation and to external customers.
These models/constellations were released as CMMI v. 1.3 in November 2010.
CMMI models provide guidance to use in developing processes. CMMI models are not themselves processes or process descriptions — the actual processes used in an organisation depend on many factors, including application domain(s) and organisation structure and size. Rather, CMMI contains and is produced from a framework, the CMMI Model Foundation (CMF). The CMF provides the ability to generate multiple models and associated training and appraisal materials. These models may reflect content from different bodies of knowledge (e.g., systems engineering, software engineering, integrated product and process development, ITIL, CobIT, etc.).
CMMI Process Areas
Process vs. Process Area
It's an important distinction to understand between processes and process areas (PAs).
An individual process is realisied by distinctive work instructions specifiying how a prescribed work product is achieved.
Instead a process area specifies goals and proven practices for performing professional work without specifiying how to do this. More, the resulting work product is specified by its characteristics only.
All CMMI v1.3 models define a set of Process Areas (e.g. Project Planning PP or Configuration Management CM).
The process area specifies goals and proven practices for performing professional work (e.g. one goal of PP is "establish estimates" with the proven practice "project scope estimation").
Process Area (engl.) | Process Area (dt.) ((German CMMI-DEV translations in referral to German Lead Appraiser and Instructor Board)) | Category | Maturity Level | CMMI model |
---|---|---|---|---|
AM - Agreement Management | Vereinbarungsmanagement | Acquisition | 2 | ACQ |
ARD - Acquisition Requirements Development | Entwicklung der Beschaffungsanforderungen | Acquisition | 2 | ACQ |
ATM - Acquisition Technical Management | Technisches Beschaffungsmanagement | Acquisition | 3 | ACQ |
AVAL - Acquisition Validation | Validierung der Beschaffungen | Acquisition | 3 | ACQ |
AVER - Acquisition Verification | Verifikation der Beschaffungen | Acquisition | 3 | ACQ |
CAM - Capacity and Availability Management | Servicekapazitäts- und verfügbarkeitsmanagement | Service Establishment and Delivery | 3 | SVC |
CAR - Causal Analysis and Resolution | Ursachenanalyse und -beseitigung | Support | 5 | ACQ, DEV, SVC |
CM - Configuration Management | Konfigurationsmanagement | Support | 2 | ACQ, DEV, SVC |
DAR - Decision Analysis and Resolution | Entscheidungfindung | Support | 3 | ACQ, DEV, SVC |
IPM - Integrated Project Management IWM - Integrated Work Management | Fortgeschrittenes Projektmanagement Fortgeschrittenes Arbeitsmanagement | Project Management | 3 | ACQ, DEV, SVC |
IRP - Incident Resolution and Prevention | Störungsbeseitigung und -vermeidung | Service Establishment and Delivery | 3 | SVC |
MA - Measurement and Analysis | Messung und Analyse | Support | 2 | ACQ, DEV, SVC |
OPD - Organisational Process Definition | Organisationsweite Prozessentwicklung | Process Management | 3 | ACQ, DEV, SVC |
OPF - Organisational Process Focus | Organisationsweite Prozessausrichtung | Process Management | 3 | ACQ, DEV, SVC |
OPM - Organisational Performance Management | Organisationsweites Prozessfähigkeitsmanagement | Process Management | 5 | ACQ, DEV, SVC |
OPP - Organisational Process Performance | Organisationsweite Prozessfähigkeit | Process Management | 4 | ACQ, DEV, SVC |
OT - Organisational Training | Organisationsweites Aus- und Weiterbildung | Process Management | 3 | ACQ, DEV, SVC |
PI - Product Integration | Produktintegration | Engineering | 3 | DEV |
PMC - Project Monitoring and Control WMC - Work Monitoring and Control | Projektverfolgung und -steuerung Arbeitsverfolgung und -steuerung | Project Management | 2 | ACQ, DEV, SVC |
PP - Project Planning WP - Work Planning | Projektplanung Arbeitsplannung | Project Management | 2 | ACQ, DEV, SVC |
PPQA - Process and Product Quality Assurance | Qualitätssicherung von Prozessen und Produkten | Support | 2 | ACQ, DEV, SVC |
QPM - Quantitative Project Management QWM - Quantitative Work Management | Quantitatives Projektmanagement Quantitatives Arbeitsmanagement | Project Management | 4 | ACQ, DEV, SVC |
RD - Requirements Development | Anforderungsentwicklung | Engineering | 3 | DEV |
REQM - Requirements Management | Anforderungsmanagement | Project Management | 2 | ACQ, DEV, SVC |
RSKM - Risk Management | Risikomanagement | Project Management | 3 | ACQ, DEV, SVC |
SAM - Supplier Agreement Management | Management von Lieferantenvereinbarungen | Project Management | 2 | DEV, SVC |
SCON - Service Continuity | Kontinuität des Services | Service Establishment and Delivery | 3 | SVC |
SD - Service Delivery | Serviceerbringung | Service Establishment and Delivery | 2 | SVC |
SSAD - Solicitation and Supplier Agreement Development | Einholen von Angeboten und Entwicklung der Lieferantenvereinbarungen | Acquisition | 2 | ACQ |
SSD - Service System Development | Servicesystementwickung | Service Establishment and Delivery | 3 | SVC |
SST - Service System Transition | Servicesystemablösung | Service Establishment and Delivery | 3 | SVC |
STSM - Strategic Service Management | Strategisches Servicemanagement | Service Establishment and Delivery | 3 | SVC |
TS - Technical Solution | Technische Umsetzung | Engineering | 3 | DEV |
VAL - Validation | Validierung | Engineering | 3 | DEV |
VER - Verification | Verifizierung | Engineering | 3 | DEV |
Process Area (engl.) | Process Area (dt.) | Category | Maturity Level | CMMI model |
Core Process Areas
In CMMI v1.3 Core Process Areas are common to all CMMI constellations. Since v1.2 the three constellations have 16 PAs in common. Because of the very specific nature of some constellations, the terminology used in those constellations was refined in v1.3.
One such term was the word "project" that was used in all three v1.2 CMMI models. However, for the service providers this term posed difficulties to interpret — since development usually is, deployed in projects, whereas services usually are realisied in teams with corresponding work load. In CMMI-SVC v1.3 "project" was changed to "work". That resulted in changing the PA names such as Work Planning, Work Management and Control, Integrated Work Management.
Even though the PA names changed those PAs are still considered core process areas. There is only one shared PA: Supplier Agreement Management (SAM).
CMMI Model Characteristics
CMMI models are characterised by
- Process Categories with related Process Areas
- Generic Goals (GG) and generic practices describe the PA's purposes
- Specific Goals (SG) and specific practices to fulfill these GGs
- Capability and maturity levels associated to generic and specific practices
Process Categories and Process Areas
In CMMI process areas are clustered by categories. All three CMMI v.1.3 constellations have the following three categories in common:
- Project Management
- Support
- Process Management
Process management and process improvement are organisation wide issues. In some firms the process areas of this category will be implemented by teams or projects, in other companies organisation wide.
In addition for each of these constellation resp. model there is a domain-specific category:
- Engineering for CMMI-DEV
- Acquisition for CMMI-ACQ
- Service Establishment and Delivery for CMMI-SVC
Generic Goals and Generic Practices
Each process area is defined by a set of goals and practices: Generic Goals (GG) and generic practices describing the PA's purposes and Specific Goals (SG) and specific practices to fulfill these GGs. Generic goals and generic practices are a part of every process area. They describe generically the goals and resp. ways how to achieve them. Generic goals and generic practices are further detailled by specific goals and specific practices (see below). Generic goals apply to more than one PA.
- GG 1 Achieve Specific Goals
- GP 1.1 Perform Specific Practices
- GG 2 Institutionalise a Managed Process
- GP 2.1 Establish an Organisational Policy
- GP 2.2 Plan the Process
- GP 2.3 Provide Resources
- GP 2.4 Assign Responsibility
- GP 2.5 Train People
- GP 2.6 Control Work Products
- GP 2.7 Identify and Involve Relevant Stakeholders
- GP 2.8 Monitor and Control the Process
- GP 2.9 Objectively Evaluate Adherence
- GP 2.10 Review Status with Higher Level Management
- GG 3 Institutionalise a Defined Process
- GP 3.1 Establish a Defined Process
- GP 3.2 Collect Process Related Experiences
Achieving each of these goals relative to a certain PA significantly improves the performance of the associated process. Achieving each of these goals relative to each PA significantly enables the institutionalization that will ensure the process is repeatable and lasting. The Generic Goals are cumulative related to maturity levels in specifiying how a certain level can be achieved. So saying that a process area is CL3 (or GG3) includes that they are achieving GG1 and GG2 as well. Generic Goals are, in fact, perfectly in parallel with the process capability levels (see below and my post on Process Capability). In other words, Generic Goal 1 (GG1) aligns with Capability Level 1 (CL1), GG2 with CL2, and GG3 with CL3, and so on. So when someone says their process area(s) are performing at "Capability Level 3" she is saying that their process areas are achieving Generic Goal 3. Generic Practices are practices that apply to any PA because, in principle, they can improve the performance of any process. The description of generic practices directly follows the generic goal to which they contribute.
Specific Goals and Specific Practices
Specific Goals apply to only one PA and address the unique characteristics that describe what must be implemented to satisfy the purpose of the PA. In this context a Specific Practice is an activity that is considered important in achieving the specific goal that is mapped to a PA.
In the following as example the Specific Goals and Specific Practices for Process Area PP - Project Planning is stated. PP is a process area at Maturity Level 2 with the purpose to establish and maintain plans that define project activities.
Specific Practices by Goal
- SG 1 Establish Estimates
- SP 1.1 Estimate the Scope of the Project
- SP 1.2 Establish Estimates of Work Product and Task Attributes
- SP 1.3 Define Project Lifecycle Phases
- SP 1.4 Estimate Effort and Cost
- SG 2 Develop a Project Plan
- SP 2.1 Establish the Budget and Schedule
- SP 2.2 Identify Project Risks
- SP 2.3 Plan Data Management
- SP 2.4 Plan the Project's Resources
- SP 2.5 Plan Needed Knowledge and Skills
- SP 2.6 Plan Stakeholder Involvement
- SP 2.7 Establish the Project Plan
- SG 3 Obtain Commitment to the Plan
- SP 3.1 Review Plans that Affect the Project
- SP 3.2 Reconcile Work and Resource Levels
- SP 3.3 Obtain Plan Commitment
CMMI Representations
Reading Time: 2 minutes Process maturity and capability can have two different representations: staged or continuous. The differences between the structures are subtle but significant. The staged representation uses so-called maturity levels to characterise the overall state of the organisation's processes relative to the model as a whole. Instead, the continuous representation of uses so-called capability levels to characterise the state of the organisation's processes relative to an individual process area. Process capability relates to the performances of (some) processes of a certain process area.
Maturity and Capability Levels
Reading Time: 4 minutes Process maturity means that whatever an organisation is doing, it is done in a well-documented way, and everyone knows what is expected of them and performs accordingly. A process is capable if it satisfies its specified product quality, service quality, and process performance objectives. A capable process consistently produces output that is within specifications. Execution of capable process always gives predictable results. Process maturity levels classify organisations according to their ability to control their various processes. Process capability levels classify the performances of (some) processes of a certain process area done by an organisation, organisational department, or project. Process maturity models define reference and assessment schemes for maturity resp. capability levels in detail.Process Institutionalisation
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 company-wide commitment and consistency to performing the process.
Process Institutionalization ensures that
- process improvement is related to business goals
- processes will be executed or managed consistently
- the processes will survive staff or leadership changes
- commitment to provide resources or infrastructure to support or improve the processes
- historical data will be useful to support future projects
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 the following table.
Generic Goal | Progression of Processes |
---|---|
GG 1 | Performed process |
GG 2 | Managed process |
GG 3 | Defined process |
GG 4 | Quantitatively managed process |
GG 5 | Optimising process |
A process can be instantiated by a project, group, or organisational 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. 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 can be part of a more encompassing plan) and the execution of the process is managed against the plan. Corrective actions are taken when the actual results and execution deviate significantly from the plan. A managed process achieves the objectives of the plan and is institutionalized for consistent execution. While generic goals and generic practices are the model components that directly address the institutionalization of a process across the organisation, many process areas likewise address institutionalization by supporting the implementation of the generic practices. Such process areas contain one or more specific practices that when implemented can also fully implement a generic practice or generate a work product that is used in the implementation of a generic practice.
Process Improvement
An organisation can use a CMMI model to help set process improvement objectives and priorities, improve processes, and provide guidance for ensuring stable, capable, and mature processes.
A capability maturity model outlines the characteristics of a mature, capable process. It identifies the practices that are basic to implementing effective processes as well as advanced practices. It also assigns to those practices associated maturity levels ranging from unrepeatable to a mature, well-managed process.
Typically a path for improvement is recommended through the various practices to achieve higher levels of maturity and, therefore, improve an organisation's processes.
CMMI supports two improvement paths using levels. One path enables organisations to incrementally improve processes corresponding to an individual process area (or group of process areas) selected by the organisation. The other path enables organisations 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: capability levels and maturity levels. These levels correspond to two approaches to process improvement called "representations" — continuous and staged.
Using the continuous representation enables you to achieve "capability levels." — Using the staged representation enables you to achieve "maturity levels."
To reach a particular level, an organisation must satisfy all of the 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 provide ways to improve your processes to achieve business objectives, and both provide the same essential content and use the same model components.
CMMI process improvement initiatives usually follows the IDEAL methodology. The IDEAL model — Initiating, Diagnosing, Establishing, Acting & Learning. IDEAL is an organisational process improvement and defect-reduction methodology published by SEI. It serves as a roadmap for initiating, planning, and implementing CMMI improvement actions. The IDEAL model is named for the five phases it describes: Initiating, Diagnosing, Establishing, Acting, Learning.
Process Maturity Appraisals
CMMI models provide guidance for developing or improving processes that meet the business goals of an organisation. A CMMI model may also be used as a framework for appraising the process maturity of the organisation. Regardless of which model an organisation chooses, CMMI proven practices should be adapted to each individual organisation according to its business objectives. Organisations cannot be CMMI "certified". Instead, an organisation is appraised (e.g., using an appraisal method like SCAMPI) and is awarded a 1-5 level rating. The rating results of such an appraisal can be published if released by the appraised organisation.
Further Readings
- SEI CMMI main Page
- All CMMI models, published by SEI
- CMMI FAQ by Entinex, Inc.
- Mary Beth Chrissis, Mike Konrad, Sandy Shrum: Addison-Wesley Longman, Amsterdam; 2nd ed. 2006.
- Dennis M. Ahern, Aaron Clouse, Richard Turner: (SEI Series in Software Engineering). Addison-Wesley Longman, Amsterdam, 2001.
- Ralf Kneuper, Ernest Wallmüller (Hrsg.): dpunkt Verlag. 2009.
- Malte Foegen, Mareike Solbach, Claudia Raak, Mike Konrad: Springer, Berlin, 2007.
Leave A Comment