Course Overview

Capability Maturity Model Integration (CMMI) is a training and appraisal program and service offered and marketed by Carnegie Mellon University and mandated by numerous DOD and U.S. Government contracts, particularly in software development. Carnegie Mellon University asserts CMMI can be utilized to direct process improvement on a project, department, or across an entire company. In CMMI methodology, processes are graded based on their maturity levels, which are classified as: Initial, Managed, Defined, Quantitatively Managed, Optimizing. Version 1.3 is currently supported. CMMI is licensed in the U.S. Patent and Trademark Office by Carnegie Mellon University.

Reviews

1. Knowledge of Software Project execution procedure / Software Engineering principles.
2. Background knowledge of the ISO 9001-2000 & CMM® model is desired.

• Introduction
• Overview of CMMI at the high level
• CMMI Models in the Framework
• Overview of CMMI.
• Maturity Levels and Process Areas.
• Advantages of CMMI.
• History of evolution of CMMI
• CMMI Models
• Application of CMMI Model
• CMMI Adoption
• Process improvement through CMMI
• Continuous Representation of CMMI
• Maturity Level
• Appraisal Methodology

WHAT is CMMI?
A: CMMI means "Capability Maturity Model Integration". It is the integration of various other CMMs (Capability Maturity Models). Through integrating other CMMs, it also becomes an integration of processes and practices in the model to a greater extent than earlier versions of the model(s) did. The CMMI is a business process improvement framework. That is, it is a model for creating process improvement systems. In the same fashion that models serve to direct thinking and analysis on how to construct other things (algorithms, buildings, molecules), CMMI is applied to construct process improvement systems.

It is NOT an engineering development standard or a life cycle of development. Take a moment to go back and read and think about that before going on.
There are now three "flavors" of CMMI referred to as constellations. The most well-known one is the CMMI for Development -- i.e., "DEV". It has been in existence (in some version or another) for about 10 years and has been the focus of considerable energy for more than 20 years when including its CMM precursors.
Two additional constellations were more recently created: CMMI for Acquisition -- i.e., "ACQ", and CMMI for Services -- i.e., "SVC". There are several things that all constellations have in common, but at their core, they are all nothing more than scaffolds for building process improvement systems. Each constellation contains material aimed at improving specific domains, tailored to organizations whose main effort either:

Produces products and complex services, and/or
Acquires goods and services from other sources, and/or
Delivers/ offers services.
NONE of the constellations themselves contain processes. None of them individually can be employed to actually create products, procure goods or deliver services. The premise with all CMMIs is that the organization already has its own standards, processes and procedures by which they actually accomplish things. The materials of CMMIs are to enhance the performance of those standards, processes and procedures -- not to establish them.
That being said, it must be remembered that there will (hopefully) be areas of overlap between what any particular organization is already doing and CMMI content. This overlap should not be confused as an indication that CMMI content *is*, in fact, process content. It can't be overstated, CMMIs, although full-o examples and descriptions, don't include "how to" anything other than constructing improvement systems. The overlap is simple to explain: work that assists in making an activity better is also work to do an activity well, and, not all organizations do even the most elementary activities needed to do the process area well. So, to one firm, what is mundane and unremarkable, to another is a savior from hopelessness.
Another perspective on CMMIs is that they emphasize the business practices of building engineered solutions (DEV), procurement of goods and services (ACQ) and service delivery (SVC). Up to now, CMMI has been most extensively used in software and systems engineering companies. Now that the constellations have been expanded, where it is used is a far different issue than being anything remotely similar to a standard or certification process for the engineering, methodologies, technologies, or accreditation involved in constructing things, purchasing things or performing things,. Were an organization to so desire, CMMI could be utilized in the construction or even the media production business. (Exactly, how would be a *wholly* different discussion!)
Before we dig too far off-topic. CMMI is intended to enable organizations to increase their performance of and ability to reliably and consistently deliver the products, services, and sourced materials their customer’s demand, when they demand them and at a cost they're willing to pay. From an exclusively inwardly-oriented view, CMMI assists firms in optimizing operational performance by reducing 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 only wait until the end of a project or work package to find out how close/far they were from their promises/expectations, without having some notion of what their processes are and how they operate, how else could a company ever implement whatever changes or improvements they'd want/need to make so that they'd do better the next time?
CMMI gives the models upon which to embark on these kinds of insights and activities for enhancement. It's a starting point, not an endpoint. CMMI is not capable of telling an organization what is important or unimportant to them. CMMI can, nonetheless, offer an avenue for an organization to gain its performance objectives.
Additionally, CMMI is only a model, it's not life. 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. Along with the context of the organization, CMMI can be used to develop a process improvement solution fitting to the context of every distinct organization.
Pulling it all together: CMMI is a model from which (astute) organizations will take abstraction and develop process improvement solutions to fit their own special environment to assist them in improving their performance operationally.
At the risk of sounding self-serving, the following deals with the question of what CMMI is:

Is CMMI for us?
A: We need to begin answering this question with a brief sentence describing what CMMI *is*.
CMMI is all about optimizing performance by enhancing operational processes. Specifically, it's enhancing processes related to running how organizations make or buy solution-oriented wares and define and provide their services. So let's ask you a question prior to answering your question: Do you think you should be in the process of improving your processes? What performance improvements in the business would you like to derive from your operations?
SO, is CMMI appropriate for you? Clearly this will depend on what you are attempting to achieve. Occasionally it is best to "divide and conquer". So we will split the world into two categories: those who produce wares and deliver services for US Federal agencies (or their prime contractors) and those who do not.
You of the first group will likely encounter CMMI as a pre-qualifier in some RFP. Therefore, you're likely to be looking at the CMMI as a necessary evil whether or not you believe your processes need to be touched in any manner. If you are in this category, there aren't many loop-holes.
A good argument for why your company may not have to fiddle with CMMI would be if you are marketing a product of your own design. A product that may get described as "shrink-wrapped" or even COTS (Commercial Off-The-Shelf). Whereas glancing over CMMI for process enhancement wouldn't hurt, the fact is that short of creating wares from ground up to the specification of a government (or a Prime's), you should be able to avoid having another person mandate or expect you to follow CMMI practices when you might otherwise not.

A couple of exceptions to this "rule of thumb" would be (a) if you are getting into the business of custom wares for the Feds, even if you are not in it currently, and/or (b) if the degree to which your product may require modifications or out-of-spec maintenance for it to be purchased/used by the government. Governments have a too-common practice of purchasing a product "as is" functionally and then discovering that what they actually require kinda sorta resembles the original product but is actually not. With that in mind, numerous agencies and prime contractors are employing the CMMI's appraisal technique (referred to as "SCAMPI") as part of their due diligence prior to tying themselves to a product or vendor.
If you fall into the latter category, (keep in mind. those not selling to the Feds or their Primes) then the question is quite simply this, "what isn't working for you with what you're currently doing to operate your business?" You'll need to become very clear on that. Some things CMMI can't help you with very well like marketing and communications. OK, it might, but if your biggest pain is dealing with your customers and marketing, you've got other fish to fry and frying them with CMMI is a very long way around to get them into the pan. Don't misunderstand us, there are certainly elements of CMMI that can be used to anything having to do with *how* you do business. But if you're concerned about where your next meal is, you may go hungry for a bit before the return on investment from CMMI brings home the bacon. It typically takes several months.
Now that I've said that. If you're discovering 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 connected to some degree of uncertainty, inconsistency, and/or absence of insight into or control over work activities, then you might do worse than looking into CMMI for what it has to say in addressing these issues.

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

As of the writing of this post, following the 2013 conference and workshop of the brand-new CMMI Institute, we can unequivocally declare the rumors of the CMMI's death to be greatly exaggerated. The Institute commissioned a company to carry out an independent market study, the Partner Advisory Board undertook a survey among Institute Partners and their sponsorees, and, one of the Partners even commissioned a company to contact at least 50 companies using CMMI directly. The noteworthy discoveries of the surveys and market statistics are described as follows:
That adoption of CMMI for real improvement (and not merely fill-in ratings) is increasing. In addition, that CMMI for Services is gaining more users, and, apparently, CMMI-SVC acquiring some users to switch over from CMMI-DEV to it (partially accounting for a decline in CMMI-DEV).

In the US, the DOD no longer requires the use of CMMI as a "minimum pre-qualification", but does consider CMMI as a +1 advantage in offers’ proposals. Furthermore, the majority (if not all) of the "big integrators", defense, infrastructure and aerospace companies that utilize CMMI still utilize and expect utilization of CMMI by their subcontractors.

Briefly, CMMI is very much alive, and, with new initiatives (in content and appraisal methods) in progress and in the pipeline at the CMMI Institute, the applicability and relevance of CMMI to the wider market are likely to regain momentum in the next few 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 referred to as Process Areas (PAs) in CMMI, and we're not being obtuse or excessively pedantic about semantics. It's a vital distinction to recognize between processes and Process Areas (PAs).
So, there are *no* processes in CMMI. No processes, no procedures, no work instructions, nothing. This is usually very confusing to CMMI newcomers. You see, there are a lot of practices in CMMI that *are* standard work practices. At times they're almost word-for-word what a particular project, work effort, service group or organization would do, but other times the practices in CMMI read the same as probable typical practices but the similarity goes no further. Even with the same-sounding names applied in common work activity and applied in CMMI, they are *not* to be construed to be pointing to one-in-the-same activities. That alone would lead to infinite hours, days, or months of confusion. What CMMI practices are, are work practices that enhance current work practices, but do not *define* what those work practices need to be for any activity or organization.
The unfortunate truth is that so many organizations have not spent the time to examine and grasp the current state of their true work practices, so therefore not only do they not know all they would need to know to simply operate their business, they then turn to CMMI as a way of establishing their own practices! And as one would expect, this methodology usually quickly ends in failure and disappointment.
How you operate your business would certainly involve practices that could occur at any time and place in an attempt and in the process of getting the work done. Regardless of where these activities occur in the real world, the CMMI PAs are sets of practices to enhance those activities. CMMI practices are not to be assumed necessarily to be in a sequence or to be inherently separate from current activities or from one CMMI practices to the next. Plainly, CMMI practices (or alternatives thereto) are the activities collectively done in order to meet improvement objectives. Objectives, we should point out, that should be connected to business objectives more significant than merely receiving a rating. There's a lot more that can be said here, but it would be a site in and of itself to do that. In addition, we never actually answered the question.
. in the latest edition of CMMI for DEVELOPMENT (v1.3, published October 2010) there are 22 Process Areas. (There were 25 in v1.1, as well as 22 in v1.2.) CMMI v1.3 can now actually refer to three different "flavors" of CMMI, referred to as "constellations.".
CMMI for Development is one "constellation" of PAs. There are two other constellations, one for services improvement, and one for acquisition. Each constellation contains specific practices intended to enhance those specific uses. CMMI for Acquisition and CMMI for Services are now all at v1.3. While most of the emphasis of this list is on CMMI for Development, we're working on updating it gradually but surely to at least cover CMMI for Services, as well.

For now, we will note 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 21 total PAs, and Services has 24 total PAs. This difference between core, core + shared, and total is made up of constellation specific PAs. More on that later.

We want to express our gratitude to our friend Saif. He pointed out that our initial answer wasn't sufficient for those who need help. Thanks to his sharp eye, we made improvements. Thank you, Saif!
Here are the Process Areas of CMMI. These come straight from the SEI/CMMI Institute publications. First, we list the "core" process areas, also called the "CMMI Model Foundation" or "CMF". Next, we present the process areas shared by two groups, DEV and SVC. Finally, we show the process areas unique to each of the three groups, in this order: DEV, ACQ, and SVC.

All Process Areas (PAs) are organized alphabetically by their short forms. For those curious about Maturity Levels, we include in brackets '[]' the Maturity Level each PA belongs to. We also provide the purpose of each area.

In CMMI for Services, the term "project" is often replaced with "work". For instance, "Project Planning" is now "Work Planning". This change followed months of discussion because the concept of a "project" doesn't always fit service work. While "project" is suitable for some services, it doesn't apply to most. Substituting "work" for "project" doesn't cause any issues in the service context.

You might wonder why not replace "project" with "work" everywhere. Our casual answer might be, "let's appreciate our successes and quietly move on." However, a better explanation is that product development and acquisition are usually distinct, specific events. Most of these are clearly defined as a "project". The models allow users to choose how to interpret "project" or "work". Re-defining "project" and "work" in their specific contexts helps reduce confusion.
Process Areas of CMMI Model Foundation (CMF) are common across all CMMI groups.

Resolutions and Causal Analysis, [ML 5]
Causal Analysis and Resolution (CAR) aims to find sources of flaws and other issues as well as act to stop them from developing going forward.
Control of Configuration, [ML 2]
By means of configuration identification, configuration control, configuration status accounting, and configuration audits, configuration management (CM) seeks to establish and preserve the integrity of work products.
Resolution and Decision Analysis in [ML 3]
Decision Analysis and Resolution (DAR) aims to examine possible decisions by means of a formal evaluation process that compares found alternatives against predefined criteria.

Integrated Project Management [ML 3]
Integrated Project Management (IPM) aims to establish and control the project and involve the pertinent stakeholders in line with an integrated and defined process catered from the set of standard processes of the company.
Analysis and Measurement, [ML 2]
Measurement and Analysis (MA) aims to build and maintain a measurement capacity utilized to support management information needs.

Definition of Organizations, [ML 3]
Organizational Process Definition (OPD) serves to define and preserve a usable set of organizational process assets and work environment standards.

Organizational Process Focus, [ML 3]
Organizational Process Focus (OPF) is meant to plan, execute, and apply organizational process enhancements grounded on a comprehensive knowledge of the present strengths and shortcomings of the organizational process assets.
Management of Organizational Performance: [ML5]
Organizational Performance Management (OPM) aims to actively control the performance of the company so as to satisfy its commercial goals.
[ML 4] Organizational Process Performance
Organizational Process Performance (OPP) serves to establish and preserve a quantitative knowledge of the performance of the set of standard processes of the organization in support of quality and process-performance objectives, and it offers the process performance data, baselines, and models to quantitatively control the organization's projects.

Training for Organizations, [ML 3]
Developing people's abilities and knowledge to enable them to carry out their jobs effectively and efficiently is the goal of organizational training, or OT.
Monitoring and Control of Projects, [ML 2]
Understanding the ongoing work is the goal of project monitoring and control, or PMC, so that when performance significantly deviates from the plan, the proper corrective action can be taken.
Planning a Project, [ML 2]
Creating and maintaining plans that specify project activities is the aim of project planning (PP).

Assurance of Process and Product Quality, [ML 2]

Process and Product Quality Assurance (PPQA) aims to give management and employees unbiased information about processes and related work products.

[ML 4] Quantitative Project Management

In order to accomplish the project's set quality and process-performance goals, quantitative project management, or QPM, is used to manage the project's defined process.

Operation of Conditions,( ML 2)
Managing product and element conditions and spotting disagreement between them and work plans and final products are the pretensions of conditions operation, or REQM.
ML 3) Risk Management
In order to plan and apply threat- handling procedures as demanded throughout the association, threat operation( RSKM) aims to descry possible issues before they arise.
operation of Supplier Agreements,( ML 2)
Managing the purchase of goods from suppliers is the end of Supplier Agreement Management( SAM).

Process Areas Specific to Development Product Integration with CMMI,( ML 3)
Product integration( PI) aims to assemble the product from its element corridor, guarantee that the integrated product operates as intended, and deliver the product.
Development of Conditions,( ML 3)
Conditions development( RD) is the process of creating and assessing conditions for guests, products, and product factors.
ML 3) Technical Solution
Designing, creating, and enforcing results to conditions is the thing of Specialized results( TS). Products, product factors, and product- related lifecycle processes are all included in results, designs, and executions, either independently or in combination as demanded.
confirmation,( ML 3)
The thing of confirmation( VAL) is to demonstrate that a product or product element performs as intended when it's placed in its willed terrain.
Evidence,( ML 3)
The purpose of Verification( VER) is to corroborate that the linked work products are meeting the assessed conditions.
Process Areas simply in CMMI for Acquisition
Agreement Management,( ML 2)
The function of Agreement Management( AM) is to make sure the supplier and the acquirer conduct business within the supplier agreement terms.
Acquisition Conditions Development,( ML 2)
The thing of Acquisition Conditions Development( ARD) is to develop and dissect client and contractual conditions.
Acquisition Technical Management,( ML 3)
The part of Acquisition Technical Management( ATM) is to The function of Service Continuity (SCON) is to create and sustain arrangements for the continuity of services during and after any major disruption of normal business.
Service Delivery, [ML 2]
The aim of Service Delivery (SD) is to deliver services in accordance with service agreements.
Service System Development*, [ML 3]
The objective of Service System Development (SSD) is to design, create, integrate, verify, and validate service systems and service system components to meet existing or future service contracts.
*SSD is an "Addition"
Thus, whether or not to utilize SSD is an organization's choice, and, whether or not to add SSD on a SCAMPI appraisal.
Service System Transition, [ML 3]
The objective of Service System Transition (SST) is to implement new or significantly altered service system components while controlling their impact on ongoing service delivery.
Strategic Service Management, [ML 3]
The aim of Strategic Service Management (STSM) is to develop and keep up standard services in harmony with strategic requirements and strategies.

How are the procedures organized?

A: This question will examine Process Area organization because they are organized to one another. The second FAQ question concerns the elements of each Process Area. Process Areas are composed of two main forms, which are called "Representations".

Staged, and
Ongoing
Two questions in, we respond to the next most obvious question: What's Continuous vs. Staged? Worry about this later, but just believe me when I say that this doesn't matter at all to anybody but a relatively tiny minority of people and companies who actually do geek out about this concept of "pathways" through some improvement journey. And finally, if you actually only care about making performance better, representations do not matter squat.

What are they made up of?
A: Every process area consists of two types of goals, two types of practices, and a whole lot of information material.
The two goal types are: Specific Goals and Generic Goals. Which in turn makes the two practices also of the same type as: Specific Practices and Generic Practices? Smart readers can probably conclude that Specific Goals include Specific Practices and Generic Goals include Generic Practices.
Each Process Area (PA) must have a minimum of one Specific Goal (SG), a minimum of two Specific Practices (SPs). The SPs within any PA are PA-specific, while, with the exception of the PA name within each of the Generic Practices (GPs), the GPs and Generic Goals (GGs) are the same for all PAs. The use of the word "Generic" thus.
PAs all have between 1 and 3 Generic Goals -- depending on which model representation is in use that the organization might be using, and, the direction they are looking to be on to improve their process improvement ability. The informative content is extremely valuable and varies from PA to PA. Readers are best served by focusing on the Goals and Practices because they are the anticipated and required parts of CMMI when the appraisal time arrives. Again, if you don't care about better performance and appraisals are not your issue, then these goal-practice mappings and normative/informative philosophies don't count at all. If you only need improvement, and appraisals are not really that high on your agenda, then it doesn't really matter what the model structure is. Take whatever from it and enhance your operation!