Course Overview

Capability Maturity Model Integration (CMMI) is a process improvement training and appraisal program and service administered and marketed by Carnegie Mellon University and required by many DOD and U.S. Government contracts, especially in software development. Carnegie Mellon University claims CMMI can be used to guide process improvement across a project, division, or an entire organization. Under the CMMI methodology, processes are rated according to their maturity levels, which are defined as: Initial, Managed, Defined, Quantitatively Managed, Optimizing. Currently supported is CMMI Version 1.3. CMMI is registered in the U.S. Patent and Trademark Office by Carnegie Mellon University.

Reviews

•  Introduction

•  High level overview of CMMI

•  CMMI Models within the Framework

•  CMMI Overview.

•  Maturity Levels and Process Areas.

•  CMMI Benefits.

•  Evolution of CMMI

•  CMMI Models

•  Using CMMI Model

•  CMMI Adoption

•  CMMI Process Improvement

•  CMMI Continuous Representation

•  Maturity Level

•  Appraisal Methodology 

WHAT is CMMI?
A: CMMI stands for "Capability Maturity Model Integration". It's the integration of several other CMMs (Capability Maturity Models). By integrating these other CMMs, it also becomes an integration of the processes and practices within the model in ways that previous incarnations of the model(s) didn't achieve. The CMMI is a framework for business process improvement. In other words, it is a model for building process improvement systems. In the same way that models are used to guide thinking and analysis on how to build other things (algorithms, buildings, molecules), CMMI is used to build process improvement systems.

It is NOT an engineering development standard or a development life cycle. Please take a moment to re-read and reflect on that before continuing.
There are currently three "flavors" of CMMI called constellations. The most famous one is the CMMI for Development -- i.e., "DEV". It has been around (in one version or another) for roughly 10 years and has been the subject of much energy for over 20 years when including its CMM ancestors.
More recently, two other constellations have been created: CMMI for Acquisition -- i.e., "ACQ", and CMMI for Services -- i.e., "SVC". All constellations share many things, but fundamentally, they are all nothing more than frameworks for assembling process improvement systems. Each constellation has content that targets improvements in particular areas, tuned to organizations whose primary work effort either:

• Develops products and complex services, and/or
• Acquires goods and services from others, and/or
• Provides/ delivers services.

NONE of the constellations actually contain processes themselves. None of them alone can be used to actually develop products, acquire goods or fulfill services. The assumption with all CMMIs is that the organization has its own standards, processes and procedures by which they actually get things done. The content of CMMIs are to improve upon the performance of those standards, processes and procedures -- not to define them.
Having said that, it should be noted that there will (hopefully) be overlaps between what any given organization already does and content of CMMIs. This overlap should not be misinterpreted as a sign that CMMI content *is*, in fact, process content. It can't be over-emphasized, CMMIs, while chock-full-o examples and explanations, do not contain "how to" anything other than building improvement systems. The overlap is easy to explain: activities that help improve a process can also be activities to effectively perform a process, and, not every organization performs even the basic activities necessary to perform the process area well. So, to one organization, what seems trivial and commonplace, to another is salvation from despair.
Another way to look at CMMIs are that they focus on the business processes of developing engineered solutions (DEV), acquiring goods and services (ACQ) and delivering services (SVC). To date, CMMI has most widely applied in software and systems engineering organizations. Now, with the expansion of the constellations, where it is applied is a significantly distinct matter from being anything even remotely akin to a standard or certification mechanism for the engineering, methods, technologies, or accreditation necessary to build stuff, buy stuff or do stuff, . If an organization chose to do so, CMMI could be applied in the construction or even media production industries. (Exactly, how would be an *entirely* different discussion!)
Before we get too off-track... CMMI is meant to help organizations improve their performance of and capability to consistently and predictably deliver the products, services, and sourced goods their customers want, when they want them and at a price they're willing to pay. From a purely inwardly-facing perspective, CMMI helps companies improve operational performance by lowering the cost of production, delivery, and sourcing.
Without some insight into and control over their internal business processes, how else can a company know how well they're doing before it's too late to do anything about it? And if/ when they wait until the end of a project or work package to see how close/far they were to their promises/expectations, without some idea of what their processes are and how they work, how else could a company ever make whatever changes or improvements they'd want/need to make in order to do better next time?
CMMI provides the models from which to pursue these sorts of insights and activities for improvement. It's a place to start, not a final destination. CMMI can't tell an organization what is or isn't important to them. CMMI, however, can provide a path for an organization to achieve its performance goals.
Furthermore, CMMI is just a model, it's not reality. Like any other model, CMMI reflects one version of reality, and like most models, it's rather idealistic and unrealistic -- at least in some ways. When understood as *just* a model, people implementing CMMI have a much higher chance of implementing something of lasting value. As a model, what CMMI lacks is context. Specifically, the context of the organization in which it will be implemented for process improvement. Together with the organization's context, CMMI can be applied to create a process improvement solution appropriate to the context of each unique organization.
Putting it all together: CMMI is a model for building process improvement systems from which (astute) organizations will abstract and create process improvement solutions that fit their unique environment to help them improve their operational performance.
At the risk of seeming self-serving, the following addresses the question of what CMMI is:

Is CMMI for us?
A: We should start the answer to this question with a quick sentence about what CMMI itself *is*.
CMMI is about improving performance through improving operational processes. In particular, it's improving processes associated with managing how organizations develop or acquire solution-based wares and define and deliver their services. So we should ask you a question before we answer yours: Do you feel that you ought to be looking at improving your processes? What business performance improvements would you like to see from your operations?
SO, is CMMI right for you? Obviously this depends on what you're trying to accomplish. Sometimes it's best to "divide and conquer". So we'll divide the world into two groups: those who develop wares and provide services for US Federal agencies (or their prime contractors) and those who don't.
Those of you in the former group will probably come across CMMI in the form of a pre-qualifier in some RFP. As such, you're probably looking at the CMMI as a necessary evil regardless of whether or not you feel your processes need to be addressed in any way. If you're in this group, there aren't many loop-holes.
One strong case for why your company might not need to mess with CMMI would be if you are selling a product of your own specification. Something that might be called "shrink-wrapped" or even COTS (Commercial Off-The-Shelf). While looking at CMMI for process improvement wouldn't be a bad idea, the point is that unless you are developing wares from scratch to a government (or a Prime's) specification, you ought to be able to elude having someone else require or expect you to pursue CMMI practices when you otherwise might not do so.
A couple of exceptions to this "rule of thumb" would be (a) if you are entering into the world of custom wares for the Feds, even though you currently aren't in it, and/or (b) if the extent to which your product might need modifications or out-of-spec maintenance for it to be bought/used by the government. Governments have an all-too-regular habit of buying a product "as is" functionally, and then realizing that what they need kinda only looks like the original product but is really different. Knowing this, many agencies and prime contractors are using the CMMI's appraisal method (called "SCAMPI") as part of their due diligence before wedding themselves to a product or vendor.
If you're in the latter group, (remember... those who don't sell to the Feds or their Primes) then the question is really this, "what's not working for you with your current way of running your operation?" You'll need to get crystal clear about that. Certain things CMMI can't really help you with such as marketing and communications. OK, it could, but if managing your customers and marketing are your biggest challenges, you've got other fish to fry and frying them with CMMI is a really long way around to get them into the pan. Don't get us wrong, there are aspects of CMMI that can be applied to anything related to *how* you do business. But, if you are worrying about where the next meal is coming from, you might be hungry for a while before the ROI from CMMI will bring home the bacon. It usually takes a number of months.
Having said that... If you're finding that

• customer acquisition, satisfaction, or retention, and/or
• project success, profitability, predictability, or timeliness, and/or
• employee acquisition, satisfaction, or retention, and/or
• service level accuracy, predictability, cycle or lead time

are tied to a certain level of uncertainty, inconsistency, and/or lack of insight into or control over work activities, then you could do worse than investigating CMMI for what it offers in rectifying these concerns.

Is CMMI Dead?
A: NO.
NOTE: This answer assumes you know a thing or two about CMMI, so we won't be explaining some terms you'll find answered elsewhere in this FAQ.

As of this writing, after the 2013 conference and workshop held by the newly-formed CMMI Institute, we can unequivocally state the rumors of the CMMI's demise are greatly exaggerated. The Institute hired a firm to conduct an independent market survey, the Partner Advisory Board conducted a survey of Institute Partners and their sponsored individuals, and, one of the Partners even took it upon themseleves to hire a firm to directly contact at least 50 companies who used CMMI. The interesting finds from these surveys and market data are that use of CMMI for actual improvement (not just ratings) are on the rise. Furthermore, that CMMI for Services is picking-up more users, and, it seems CMMI-SVC getting some users to convert over from CMMI-DEV (which partially explains a drop in CMMI-DEV).

In the US, the DOD no longer mandates use of CMMI as a "minimum pre-qualification", but it does view CMMI as a +1 benefit in offerors' proposals. In addition, most (if not all) of the "big integrators", defense, infrastructure and aerospace firms who use CMMI continue to use and expect the use of CMMI by their subcontractors.

In short, CMMI is far from dead, and, with new initiatives (in content and appraisal approaches) under way and planned for at the CMMI Institute, the relevance and applicability of CMMI to the broader market is expected to pick up again over the coming years.

How many processes are there in CMMI?
A: NONE. Zero. Zip. Nada.Rien.Nil.Bupkis.Big ol' goose-egg. There's not a single process in all of CMMI. They're called Process Areas (PAs) in CMMI, and we're not being obtuse or overly pedantic about semantics. It's an important distinction to understand between processes and Process Areas (PAs).
So, there are *no* processes in CMMI.  No processes, no procedures, no work instructions, nothing. This is often very confusing to CMMI newcomers. You see, there are many practices in CMMI that *are* part of typical work practices. Sometimes they are almost exactly what a given project, work effort, service group or organization might do, but sometimes the practices in CMMI sound the same as likely typical practices in name only and the similarity ends there. Despite the similar names used in typical work practices and in CMMI, they are *not* to be assumed to be referring to one-in-the-same activities. That alone is enough to cause endless hours, days, or months of confusion. What CMMI practices are, are practices that improve existing work practices, but do not *define* what those work practices must be for any given activity or organization.
The sad reality is so many organizations haven't taken the time to look at and understand the present state of their actual work practices, so as a result not only do they not know everything they would need to know to merely run their operation, they then look to CMMI as a means of defining their own practices! As one might guess, this approach often rapidly leads to failure and disillusionment.
How you run your operation would undoubtedly include practices that may happen at any point and time in an effort and during the course of doing the work. Irrespective of where these activities take place in reality, the CMMI PAs are collections of practices to improve those activities. CMMI practices are not to be interpreted as being necessarily in a sequence or to be intrinsically distinct from existing activities or from one CMMI practices to another. Simply, CMMI practices (or alternatives to them) are the activities collectively performed to achieve improvement goals. Goals, we might add, that ought to be tied to business objectives more substantial than simply achieving a rating. There's so much more to say here, but it would be a site unto itself to do so. Besides, we never answered the question....
... in the current version of CMMI for DEVELOPMENT (v1.3, released October 2010) there are 22 Process Areas. (There were 25 in v1.1, and also 22 in v1.2.) CMMI v1.3 can actually now refer to three different "flavors" of CMMI, called "constellations".
CMMI for Development is one "constellation" of PAs. There are two other constellations, one for improving services, and one for acquisition. Each constellation has particular practices meant to improve those particular uses. CMMI for Acquisition and CMMI for Services are now all at v1.3. While much of the focus of this list is on CMMI for Development, we're updating it slowly but surely to at least address CMMI for Services, too.
Meanwhile, we'll just point out that the three constellations share 16 "core" process areas; CMMI for Development and for Services share the Supplier Agreement Management (SAM) process area. The CMMI for Acquisition has a total of 21 PAs, and Services has a total of 24 PAs. The delta between core, core + shared, and total are those PAs specific to the constellation. More on that later.
We would like to thank our friend, Saif, for pointing out that our original answer was not nearly doing justice to those in need of help. The update to this answer was a result of his keen observation. Thanks Saif!
The Process Areas of CMMI are listed below. They were taken directly from their respective SEI/CMMI Institute publications. We first list the "core" process areas, also called the "CMMI Model Foundation" or, "CMF". Then we list the process area shared by two of the constellations, DEV and SVC, then we list the process areas unique to each of the three constellations, in order of chronological appearance: DEV, ACQ, then SVC.
All the PAs are listed in alphabetical order by acronym, and for those who are interested in Maturity Levels, we include in brackets '[]' which Maturity Level each PA is part of. We're also listing the purpose statement of each one.
We should also note that in process area names, purpose statements, and throughout the text, in CMMI for Services, the notion of "project" has largely been replaced with the notion (and use of the term) "work". For example, in CMMI for Services, "Project Planning" becomes "Work Planning", and so forth. The rationale for that is the result of months of debate over the relevance and subsequent confusion over the concept of a "project" in the context of service work. While the concept of a "project" *is* appropriate for many types of services, it is quite inappropriate for most services, and, substituting the notion (and use of the term) "work" for "project" has effectively zero negative consequences in a service context.
This may raise the question of why not merely replace "work" for "project" in all three constellations? In the attitude of this CMMIFAQ, our flippant answer would be something like, "let's take our victories where we can get them and walk away quietly", but a more accurate/appropriate answer would be that product development and acquisition events are generally more discrete entities than services, and the vast majority of product development and acquisition events are, in fact, uniquely identified by the notion of a "project". Furthermore, there is nothing in the models that prevent users from restricting the interpretation of "project" or "work". It's just that re-framing "project" and "work" in their respective contexts made sense in a broader effort to reduce sources of confusion.
Process Areas of CMMI Model Foundation (CMF) -- Common to All CMMI Constellations
Causal Analysis & Resolution, [ML 5]
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.
Configuration Management, [ML 2]
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.
Decision Analysis & Resolution, [ML 3]
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.
Integrated Project Management, [ML 3]
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.
Measurement & Analysis, [ML 2]
The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability that is used to support management information needs.
Organizational Process Definition, [ML 3]
The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets and work environment standards.
Organizational Process Focus, [ML 3]
The purpose of Organizational Process Focus (OPF) is to plan, implement, and deploy organizational process improvements based on a thorough understanding of the current strengths and weaknesses of the organization's processes and process assets.
Organizational Performance Management, [ML5]
The purpose of Organizational Performance Management (OPM) is to proactively manage the organization's performance to meet its business objectives.
Organizational Process Performance, [ML 4]
The purpose of Organizational Process Performance (OPP) is to establish and maintain a quantitative understanding of the performance of the organization's set of standard processes in support of quality and process-performance objectives, and to provide the process performance data, baselines, and models to quantitatively manage the organization's projects.
Organizational Training, [ML 3]
The purpose of Organizational Training (OT) is to develop the skills and knowledge of people so they can perform their roles effectively and efficiently.
Project Monitoring and Control, [ML 2]
The purpose of project Monitoring and Control (PMC) is to provide an understanding of the ongoing work so that appropriate corrective actions can be taken when performance deviates significantly from the plan.
Project Planning, [ML 2]
The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.
Process and Product Quality Assurance, [ML 2]
The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.
Quantitative Project Management, [ML 4]
The purpose of Quantitative Project Management (QPM) is to quantitatively manage the project's defined process to achieve the project's established quality and process-performance objectives.
Requirements Management, [ML 2]
The purpose of Requirements Management (REQM) is to manage requirements of the products and product components and to identify inconsistencies between those requirements and the work plans and work products.
Risk Management, [ML 3]
The purpose of Risk Management (RSKM) is to identify potential problems before they occur so that risk-handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.
Shared by CMMI for Development and CMMI for Services
Supplier Agreement Management, [ML 2]
The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers.
Process Areas Unique to CMMI for Development
Product Integration, [ML 3]
The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product.
Requirements Development, [ML 3]
The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements.
Technical Solution, [ML 3]
The purpose of Technical Solution (TS) is to design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes either singly or in combination as appropriate.
Validation, [ML 3]
The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.
Verification, [ML 3]
The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements.
Process Areas Unique to CMMI for Acquisition
Agreement Management, [ML 2]
The purpose of Agreement Management (AM) is to ensure that the supplier and the acquirer perform according to the terms of the supplier agreement.
Acquisition Requirements Development, [ML 2]
The purpose of Acquisition Requirements Development (ARD) is to develop and analyze customer and contractual requirements.
Acquisition Technical Management, [ML 3]
The purpose of Acquisition Technical Management (ATM) is to evaluate the supplier's technical solution and to manage selected interfaces of that solution.
Acquisition Validation, [ML 3]
The purpose of Acquisition Validation (AVAL) is to demonstrate that an acquired product or service fulfills its intended use when placed in its intended environment.
Acquisition Verification, [ML 3]
The purpose of Acquisition Verification (AVER) is to ensure that selected work products meet their specified requirements.
Solicitation and Supplier Agreement Development, [ML 2]
The purpose of Solicitation and Supplier Agreement Development (SSAD) is to prepare a solicitation package, select one or more suppliers to deliver the product or service, and establish and maintain the supplier agreement.
Process Areas Unique to CMMI for Services
Capacity and Availability Management, [ML 3]
The purpose of Capacity and Availability Management (CAM) is to ensure effective service system performance and ensure that resources are provided and used effectively to support service requirements.
Incident Resolution and Prevention, [ML 3]
The purpose of Incident Resolution and Prevention (IRP) is to ensure timely and effective resolution of service incidents and prevention of service incidents as appropriate.
Service Continuity, [ML 3]
The purpose of Service Continuity (SCON) is to establish and maintain plans to ensure continuity of services during and following any significant disruption of normal operations.
Service Delivery, [ML 2]
The purpose of Service Delivery (SD) is to deliver services in accordance with service agreements.
Service System Development*, [ML 3]
The purpose of Service System Development (SSD) is to analyze, design, develop, integrate, verify, and validate service systems, including service system components, to satisfy existing or anticipated service agreements.
*SSD is an "Addition"  As such, it is at the organization's discretion whether to implement SSD, and, whether to include SSD in a SCAMPI appraisal.
Service System Transition, [ML 3]
The purpose of Service System Transition (SST) is to deploy new or significantly changed service system components while managing their effect on ongoing service delivery.
Strategic Service Management, [ML 3]
The purpose of Strategic Service Management (STSM) is to establish and maintain standard services in concert with strategic needs and plans.

How are the processes organized?
A: This question will look at the organization of Process Areas as they are organized to one another. The next FAQ question addresses the elements of each Process Area. Process Areas are organized in two main ways, called "Representations".

• Staged, and
• Continuous

Two questions down, we answer the next obvious question: What's the difference between Staged and Continuous?  For now, just trust us when we say that this really doesn't matter except to a very few people and organizations who really geek out over this idea of "pathways" through an improvement journey. Ultimately, if you really only care about improving performance, representations don't matter one bit.

What is each process made up of?
A: Each process area is made of two kinds of goals, two kinds of practices, and a whole lot of informative material.
The two goal types are: Specific Goals and Generic Goals. Which then makes the two practices to also follow suit as: Specific Practices and Generic Practices. Astute readers can probably guess that Specific Goals are made up of Specific Practices and Generic Goals are made up of Generic Practices.
Every Process Area (PA) has at least one Specific Goal (SG), made up of at least two Specific Practices (SPs). The SPs in any PA are unique to that PA, whereas, other than the name of the PA in each of the Generic Practices (GPs), the GPs and Generic Goals (GGs) are identical in every PA. Hence, the term "Generic".
PAs all have anywhere from 1 to 3 Generic Goals -- depending on which model representation organization chooses to use, and, the path they intend to be on to mature their process improvement capabilities.
The informative material is very useful, and varies from PA to PA. Readers are well-advised to focus on the Goals and Practices because they are the required and expected components of CMMI when it comes time to be appraised. Again, if improving performance is important to you and appraisals are not something you care about, then these goal-practice relationships and normative/informative philosophies don't really matter at all.. If all you want is improvement, and appraisals are not necessarily important, then it doesn't really matter how the model is organized. Use anything in it to make your operation perform better!