CMMI FAQ - brutally honest, totally hip, no nonsense answers (a public service of Entinex)

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 process improvement. In particular, it's improving processes associated with managing how organizations develop or acquire solution-based wares. So we should ask you a question before we answer yours: Do you feel that you ought to be looking at improving your processes?

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 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 developing wares?" You'll need to get crystal clear about that. Certain things CMMI can't really help you with such as customer relationship management. 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 real 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 -- especially the technology type. 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

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

How many processes are there in CMMI?

A: NONE. Zero. Zip. Nadda. 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 product development and project management practices. Sometimes they are almost exactly what a given project or organization might do, but sometimes the practices in CMMI sound the same as possible typical product development and project management practices in name only and the similarity ends there. Despite the similar names used in both typical development and management 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 product development and project management practices, but do not *define* what those product development and project management practices must be for any given project or organization.

The sad reality is so many organizations haven't taken the time to look at and understand what their product development and project management practices are, so as a result they look to CMMI as a means of defining their own practices! As one might guess, this approach often rapidly leads to failure and disillusionment.

Product development and project management practices may happen at any point and time in a project and during the course of product development. 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.2, released August 2006) there are 22 Process Areas. (There were 25 in v1.1.) CMMI v1.2 is now called, "CMMI for Development" because there are PAs specific to improving engineering practices of product and services solution development.

CMMI for Development is a "constellation" of PAs. For improving service or acquisition practices, other PAs might be better, so in 2007, CMMI for Acquisition was released, and in February 2009, CMMI for Services was released. Much of the focus of this list is on CMMI for Development, but we're updating it slowly but surely.

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, and the 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 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, 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.

Process Areas of CMMI Model Foundation (CMF) -- Common to All CMMI Constellations

Causal Analysis & Resolution, [ML 5]

Configuration Management, [ML 2]

Decision Analysis & Resolution, [ML 3]

Integrated Project Management (+ IPPD -- DEV only), [ML 3]

IPPD "Addition" (DEV only)
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.

Measurement & Analysis, [ML 2]

Organizational Innovation and Deployment, [ML 5]

Organizational Process Definition (+ IPPD -- DEV only), [ML 3]

IPPD "Addition" (DEV only)
For IPPD, Organizational Process Definition +IPPD also covers the establishment of organizational rules and guidelines that enable conducting work using integrated teams.

Organizational Process Focus, [ML 3]

Organizational Process Performance, [ML 4]

Organizational Training, [ML 3]

Project Monitoring and Control, [ML 2]

Project Planning, [ML 2]

Process and Product Quality Assurance, [ML 2]

Quantitative Project Management, [ML 4]

Requirements Management, [ML 2]

Risk Management, [ML 3]

Shared by CMMI for Development and CMMI for Services

Supplier Agreement Management, [ML 2]

Process Areas Unique to CMMI for Development

Product Integration, [ML 3]

Requirements Development, [ML 3]

Technical Solution, [ML 3]

Validation, [ML 3]

Verification, [ML 3]

Process Areas Unique to CMMI for Acquisition

Agreement Management, [ML 2]

Acquisition Requirements Development, [ML 2]

Acquisition Technical Management, [ML 3]

Acquisition Validation, [ML 3]

Acquisition Verification, [ML 3]

Solicitation and Supplier Agreement Development, [ML 2]

Process Areas Unique to CMMI for Services

Capacity and Availability Management, [ML 3]

Incident Resolution and Prevention, [ML 3]

Service Continuity, [ML 3]

Service Delivery, [ML 2]

Service System Development^*, [ML 3]

^*SSD is an "Addition"

SCAMPI

Service System Transition, [ML 3]

Strategic Service Management, [ML 3]

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?

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 information.

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 5 Generic Goals -- depending on which model representation (see the previous question) the organization chooses to use, and, the path they intend to be on to mature their process improvement capabilities.

The informative material is very useful, but 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. Read more about that here.

What's the difference between Staged and Continuous?

A: It's just different ways of looking at the same data...

The main difference is simply how the model is organized around the path towards process improvement that an organization can take. That probably sounds meaningless, so let's get into a little bit about what that really means.

The SEI, based on the original idea behind the CMM for Software, promoted the notion that there are more basic and more advanced (key)* process areas that organizations should endeavor to get good at on the way to being highly mature, highly capable organizations. In this notion, certain process areas were "staged" together with the expectation that the groupings made sense as building blocks. Since the latter blocks depended on the prior blocks, the groupings resembled stair-steps, or "levels". The idea then was that the first level didn't include any process areas, and that the first staging of (K)PAs* (the actual "level 2") was a set of very fundamental practices that alone could make a significant difference in project performance.

From there, the next staging of PAs, or level 3, could begin to exploit the foundational PAs and begin to affect process improvement changes from a more detailed technical and managerial perspective. Whereas, up through Level 3, where PAs didn't wrangle with other PAs, Levels 4 and 5 add Process Areas that look across all the other process areas and project activities. While Levels 4 and 5 only add a total of four PAs, they are not in the least trivial. They add the maturity and capability to manage processes by numbers rather than only by subjective feedback, and they add the ability to really optimize and continuously improve process across the board.

In comes a group of people who said, in effect, why not be able to improve any one process to the point of optimization without having all processes needing to be there? In fact, why not be able to focus on processes with high value to the organization first and then go after other processes, or maybe even ignore any processes that we don't really do?

In the staged representation, which is the original Software CMM approach, this ability to mature a capability in any one process area doesn't exist, so in CMMI, the idea of a Continuous representation was implemented whereby an organization could choose to get really really good at any number of PAs without having to put forth the effort to implement low-value or unused PAs. This becomes especially meaningful to organizations that want to be able to benchmark themselves (or be formally rated) in only areas that matter to them. So, to understand the Continuous representation of the model, it should be enough to know that this representation allows organizations to pick any number of process areas, and also pick to whatever depth of capability they want to become in those process areas. The key determinant in such a capability lies in the Generic Goals. As we will cover in the next question, the "level" of capability of an organization using the Continuous representation has to do with the Generic Goal they've institutionalized, not the number or mix of PAs.

*In the original CMM for Software, the process areas were called "Key Process Areas", or KPAs, and, there was no distinction between types of levels (see below), therefore there was only one type of level, and when someone said "level 3" everyone understood. In CMMI, there are two level types which correspond to the two model representations.(see below) Saying, "level" in the context of CMMI is incomplete. However, for anyone reading this FAQ from the beginning, this concept has not yet been introduced, and we didn't want to start adding terms that had not yet been defined.

What's the difference between Maturity Level and Capability Level?

A: They are different ways of rating your processes...

Let's start with the basics. A "Maturity Level" is what you can be appraised to and rated as when the organization uses the Staged Representation of the CMMI, and a "Capability Level" is what you can be appraised to and rated as when the organization uses the Continuous Representation of the CMMI. As for the details...

A "Maturity Level" X means that an organization, when appraised, was found to be achieving the goals required by that level (X). Those goals are a combination of specific and generic goals from a specific set of Process Areas. Each "Maturity Level" has a specific set of PAs associated with it, and in turn, within those PAs have a specific set of goals.

Maturity Level 2 (ML 2) requires the following PAs be performed up to and including Generic Goal 2 within them:

Requirements Management (REQM)
Project Planning (PP)
Project Monitoring and Control (PMC)
Supplier Agreement Management (SAM)
Measurement and Analysis (MA)
Process and Product Quality Assurance (PPQA), and
Configuration Management (CM)

Maturity Level 3 (ML 3) requires the ML 2 PAs, plus the following PAs be performed up to and including Generic Goal 3 within all of them:

Requirements Development (RD)
Technical Solution (TS)
Product Integration (PI)
Verification (VER)
Validation (VAL)
Organizational Process Focus (OPF)
Organizational Process Definition (OPD)
Organizational Training (OT)
Integrated Project Management (IPM)
Risk Management (RSKM), and
Decision Analysis and Resolution (DAR)

Maturity Level 4 (ML 4) requires the ML 2 and 3 PAs, plus the following PAs be performed up to and including Generic Goal 3 within all of them:

Organizational Process Performance (OPP) and
Quantitative Project Management (QPM)

And finally, Maturity Level 5 (ML 5) requires the ML 2-4 PAs, plus the following PAs be performed up to and including Generic Goal 3 within all of them:

Organizational Innovation and Deployment (OID) and
Causal Analysis and Resolution (CAR)

Now, if you recall from the earlier FAQ, the Continuous representation is tied to the Generic Goals, and from above, Capability Levels are attained when using the Continuous representation. So with that, Capability Levels are then tied to the Generic Goals. As we noted ealier, there are no collections of PAs in Capability Levels as there are in Maturity Levels or the "staged" representation. Therefore, it is far simpler to explain that a Capability Level is attained PA by PA. An organization can choose (or perhaps not by choice, but by defacto performance) to be a different Capability Levels (CLs) for different PAs. For this reason, the results of a SCAMPI based on the Continuous Representation determine a "Capability Profile" that conveys each PA and the Capabililty Level of each one.

Basically, the Capability Level of a PA is the highest Generic Goal at which the organization is capable of operating. Since there is actually 5 Generic Goals 1-5, an organization can be found to be operating at a Capability Level of ZERO (CL 0), in which they aren't even achieving the first Generic Goal which is simply to "Achieve Specific Goals"

Thus, the five Capability Levels are (in our own words):

Capability Level 1: The organization achieves the specific goals of the respective process area(s).
Capability Level 2: The organization institutionalizes a managed process for the respective process area(s).
Capability Level 3: The organization institutionalizes a defined process for the respective process area(s).
Capability Level 4: The organization institutionalizes a quantitatively managed process for the respective process area(s).
Capability Level 5: The organization institutionalizes an optimizing process for the respective process area(s).

What are the Generic Goals?
a.k.a. What are the differenes among the Capability Levels?
a.k.a. What do they mean when they say process institutionalization?

A: The Generic Goals *are*, in fact, perfectly parallel with the Capability Levels. In other words, Generic Goal 1 (GG1) aligns with Capability Level 1 (CL1). GG2 with CL2, GG3 with CL3, and so on. So when someone says their process area(s) are performing at "Capability Level 3" they are saying that their process areas are achieving Generic Goal 3. The Generic Goals are cumulative, so saying that a process area is CL3 (or GG3) includes that they are achieving GG1 and GG2 as well.

Before we get into a discussion about the idea of institutionalization, let's list the Generic Goals:

Generic Goal 1 [GG1]: 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.

Generic Practice 1.1 [GP 1.1]:

Generic Goal 2 [GG2]: The process is institutionalized as a managed process.

Generic Practice 2.1 [GP 2.1]:

Generic Practice 2.2 [GP 2.2]:

Generic Practice 2.3 [GP 2.3]:

Generic Practice 2.4 [GP 2.4]:

Generic Practice 2.5 [GP 2.5]:

Generic Practice 2.6 [GP 2.6]:

Generic Practice 2.7 [GP 2.7]:

Generic Practice 2.8 [GP 2.8]:

Generic Practice 2.9 [GP 2.9]:

Generic Practice 2.10 [GP 2.10]:

Generic Goal 3 [GG3]: The process is institutionalized as a defined process.

Generic Practice 3.1 [GP 3.1]:

Generic Practice 3.2 [GP 3.2]:

Generic Goal 4 [GG4]: The process is institutionalized as a quantitatively managed process.

Generic Practice 4.1 [GP 4.1]:

Generic Practice 4.2 [GP 4.2]:

Generic Goal 5 [GG5]: The process is institutionalized as an optimizing process.

Generic Practice 5.1 [GP 5.1]:

Generic Practice 5.2 [GP 5.2]:

So, you're wondering what's this business about institutionalization. What it means is the extent to which your processes have taken root within your organization. It's not just a matter of how widespread the processes are, because institutionalization can take place in even 1-project organizations. So then, it's really about how they're performed, how they're managed, how they're defined, what you measure and control the processes by, and how you go about optimizing and continuously improving upon them.

If we look at what it takes to manage a project, we will find what it takes to manage a process. Look above at GG2. You'll see that each of those practices are easy to understand if we were discussing projects, but when it comes to processes, people have trouble internalizing these everyday management concepts. All institutionalization reduces to is the ability to conduct process activities with the same rigor that we put forth to effectively conduct projects.

In very mature (or capable) environments, they can manage projects statistically. They know, based on numbers, how well the projects are performing and predict with high accuracy how well the project will end up performing by the end. The same concepts are applied to processes. If an organization can manage projects numerically, then process management would operate the same way. Once the organization is using numbers to understand where its processes are and how they're performing, these same numbers lead towards the ability to focus in on very specific variations in process performance and to weed out under-performing sub-practices, and optimze overall processes.

We liken that to "Instrument Flight Rules (IFR)" in flying, whereas at lower capability and maturity organizations, most of the "flying" is done via "Visual Flight Rules (VFR)".

These concepts were not as consistently articulated in pre-CMMI versions of CMM. But if all this is still confusing, please let us know where you're hung-up and we'll be happy to try to answer your specific questions.

What's High Maturity About?
a.k.a. What's the fuss about High Maturity Lead Appraisers?
a.k.a. What's the fuss about the informative materials in the High Maturity process areas?

A: "High Maturity" refers to the four process areas that are added to achieve Maturity Levels, 4 and 5:

Organizational Process Performance (OPP),
Quantitative Project Management (QPM),
Organizational Innovation and Deployment (OID), and
Causal Analysis and Resolution (CAR)

For the purposes of discussion, the 2 Generic Goals and their collective 4 Generic Practices of Capability Levels 4 & 5 will be assumed wholly redundant to their Maturity Level/Process Area counterparts.

Collectively, these process areas are all about making decisions about projects and processes based on numbers, not opinions, and eventually not on "rearward-looking" data, rather, forward-looking and predictive analysis.

It's not just any numbers, but numbers that tie directly into the organization's (business and performance) goals, and not just macro-level goal numbers but numbers that come from very specific, high-fidelity sub-processes that are used by projects and can predict a project's performance as well as the process' outcomes.

What enables this sort of quantitative-centric ability are benchmarks about the organization's processes (called process "performance baselines") and the predictive analysis of the organization's processes (called process "performance models"). Together the process performance baselines and models provide the organization with an idea of what their processes are really up to and what they can really do. This is not usually based on macro-level activities, but are based on activities for which nearly every contributing factor to the process is known, quantifiable and measured.

Since process are used by projects, and, since at maturity (and capability) levels of activity beyond level 2 the projects are drawing their processes from a pool of defined practices, the ability to create processes for projects, and to manage performance of both the project activities and process activities is facilitated by the quantification of both project and process performance. This results in process information that simultaneously supports project outcomes as well as provides insight into how well the processes are performing.

In order, however, for the process data to provide value, they must be stable and in control. Determining whether processes are stable and in control is usually a matter of statistical analysis. Therefore, at the core of all this quantification is a significant presence of statistics, without which process data is not always trustworthy (remember: high maturity, it's different at ML2 and 3), and that data's ability to predict outcomes is tenuous, at best.

The eventual need and ability to modify the processes similarly exploits the value richness of statistics and higher analytical techniques. By the time an organization is operating at higher levels of maturity, they will expect themselves to rely on hard data and process professionalism to guide them towards developing, testing, implementing process chages.

The fuss about all this is multi-faceted. To name a few facets, we can begin by categorizing them (though the categories are not unrelated to each other) as:

the only required and expected components of the model are the goals and practice statements, respectively, and
mis-understanding and/or mis-interpretation of the model high maturity practices.

The action to address these facets stems from a flood of findings that many high maturity appraisals didn't accept as evidence those artifacts that convey the proper intent and implementation of these higher maturity concepts were applied at the organizations appraised. In fact, the opposite was found to be true. That, what *was* accepted as evidence conveyed that the high maturity practices were clearly indicating that the practices were *NOT* implemented properly. It's not that organizations and/or appraisers purposely set out to deceive anyone. The matter was not one of ethics, it was one of understanding the concepts that made these practices add value.

The crux of the matter is/was that none of the practices of the model at any level are entirely stand-alone. They (nearly) all have some informative material that provide context and edification for the practice statements. At earlier maturity levels, many of the practices are not foreign to people with some process discipline experience. They may be a bit arcane for some; the practices at lower maturity levels enjoy a wider array of people who can understand and perform them to satisfy the goals of process areas without additional explanation. Methods and alternative implementations for these practices abound. This seems not the case with higher maturity practices. The practices of high maturity activities require a different set of skills and methods that few individuals appying CMMI ever have the need or opportunity to acquire. Thus, the informative materials (namely, sub-practices and typical work products) become far more important -- not towards the required artifacts of an appraisal, but for the proper implementation of the what's intended by the practices.

An analogy used elsewhere bears repeating here: want to implement ML2 and 3? Hire a process improvement specialist. Want to implement ML 4 and 5? Hire a process improvement specialist with expertise in statistical process control and skills in advanced analytical techniques. For people who can claim the latter on their resumé's, little, if anything in ML4 & 5 is new to them. ML 4 & 5 bear much resemblance to Six Sigma activities.

To address these findings, SEI created a certification for lead appraisers, and a class for anyone looking to implement high maturity concepts. The certification is intended to ensure that lead appraiser performing high maturity appraisals understand what the concepts mean and what they need to look for, and the course provides deeper insight and examples about the practices and concepts.

Although there are many lead appraisers providing consulting to clients about high maturity concepts, only SEI-Certified High Maturity Lead Appraisers (HMLAs) can perform the appraisals to those levels. Although a blanket statement would be highly inappropriate, there have been clear, well-documented, cases of non-HMLAs providing very poor advice on high maturity implementations. This FAQ strongly recommends that any organization pursuing high maturity take advantage of some consulting by an SEI-Certified HMLA well before attempting a SCAMPI to those levels. Having said that, organizations should still take steps to ensure they hire a good-fitting lead appraiser.

What's a Constellation?

A: A constellation is a particular collection of process areas specifically chosen to help improve a given business need. Currently there are three (3) constellations:

Development: For improving the development of (product or complex service) solutions.
Acquisition: For improving the purchasing of products, services and/or solutions. And.
Services: For improving delivery of services and creation of service systems (say, to operate a solution but not buy it or build it in the first place).

There are 16 of the process areas common to all three constellations, Basically all the process areas listed here minus the following:

RD
TS
PI
VER
VAL, and
SAM

How many different ways are there to implement CMMI?

A: Infinite, but 2 are most common.

There's what we call the blunt-object (or silo'd or stove-piped) approach, which is, unfortunately, what seems to be the most common approach. In this approach CMMI is implemented with the grace and finesse of a heavy, blunt object at the end of a long lever -- impacting development organizations and project managers' collective craniums. And then, there's the reality-based approach. In which, processes are implemented in such a way that project personnel may not even know it's happening. Can you guess which one we advocate?

The blunt-object approach resembles what many process improvement experts call "process silos", or "stove pipes". This approach is also often implemented *to* a development team *by* some external process entity with brute force and very extreme prejudice. So, not only does the blunt approach employ some very unsavory techniques, subjecting its royal subjects to cruel and unusual process punishment, it also (in its design) is characterized by a "look and feel" of a process where each process is in its own vacuum, without any connection to other processes (or to reality, for that matter), and where the practices of the processes are somehow expected to be performed serially, from one to the next, in the absence of any other project context.

If so many implementations of CMMI are guided by an (internal or external process) "expert", one might (justifiably) wonder how and why CMMI processes could ever be implemented in such an obviously poorly conceived approach!

There are two (sometimes inter-related) reasons:

Lack of understanding of the model, and
Being an expert process auditor, and not a process improvement expert.

Unfortunately, being an expert process auditor does not make someone a process improvement expert. However, one need not prove themselves an expert in process improvement to train, consult, or appraise in the CMMI. So, what you have are many people who become "experts" in CMMI, but they're really only experts in the model's text and in appraising an organization's ability to read the text and produce text-book artifacts. They're not necessarily experts in process improvement, in general, or in implementing CMMI in particular.

We've come across countless examples of organizations' attempts to implement CMMI while being led by someone (or plural) who was at least one of the two types of persons, and too frequently, both at once. Frightening, but true.

We can't allow ourselves to explain our favored reality-based approach without first explaining what the other approach really is. Not so that our approach looks better, and not because we must justify our approach, but because we feel that it's important for people new to CMMI and/or to process improvement to be prepared to recognize the signs of doom and be able to do something about it before it's too late.

All kidding aside, believe it or not, there are organizations for whom the blunt/silo/stove-pipe approach actually works well, and we wouldn't necessarily recommend that they change it. These organizations tend to share certain characteristics including any number of the following: being larger, bureaucratic by necessity, managing very large and/or complex projects; and, there's an actual, justifiable reason for their approach. In fact, in these cases, the effect is actually neither blunt, nor particularly silo'd, but these types of organizations have other mechanisms for "softening" the effect that such an approach would have on smaller projects/organizations. And, that is precisely, how we can characterize the main difference between the two approaches: we believe that the reality-based approach to implementing CMMI works well in most types of organizations and projects of most scope, where the brute-force approach would not.

What does the blunt/brute-force/silo/stove-pipe approach look like?

In a nutshell, the traits of that approach are: Process Area description documents are prescriptive and implementation of the processes do not easily account for the inter-relatedness of the process areas to one another, or of the generic practices to the specific practices. Furthermore, the processes seem to be implemented out-of-step with actual development/project work. Nowhere in the descriptions or artifacts of the processes is it clear how and when the process gets done. It's not a matter of poorly written processes, quite the opposite, many of these processes are the exemplar of process documents. What these processes lack is a connection to the development work as it happens. Without a process subject-matter expert on hand, it's unlikely that the process would actually get done. In many cases (thanks to the sheer size of the organization) such processes *are*, in fact, done by a process specialist, and not by project personnel.

In other words, with such processes, if an organization doesn't have the luxury of process specialists to do the process work, it would be difficult for someone on the project trying to follow the processes to see how the process activities relate to project activities and/or to see when/where/how to implement the process activities on actual development tasks. Because of this, this approach to CMMI often has the feel (or the actual experience) of an external organization coming in to "do" CMMI *to* the project, or as often, that project members must pause their development-oriented work to complete process-oriented activities.

Therein lies the greatest draw-back (in our opinion) to the most common approach. Instead of process improvement being an integral and transparent characteristic of everyday work, it becomes a non-productive layer of overhead activity superimposed on top of "real" work. And yet, this seems to be the prevalent way of implementing CMMI! Crazy, huh?

Why is it so prevalent?

That's where the two reasons of poor implementation, above, come in. People who don't understand the model as well as people who are not process experts (and therefore may have a weak understanding of the model) don't truly "get" that the model is not prescriptive, and so they attempt to make it a prescription. Auditing and appraising to a prescription is far easier and less ambiguous than auditing and appraising to a robust integrated process infrastructure. Frankly, the "common" approach suits the lowest common denominator of companies and appraisers. Those companies and appraisers who aren't after true improvement, and are only after a level rating, and who are willing (companies -- unknowingly) to sacrifice the morale and productivity of their projects for the short-term gain of what becomes a meaningless rating statement.

Alright already! So what's the reality-based approach about?!

The reality-based approach starts with a premise that a successful development organization is already doing what it needs to be doing to be successful, and, that process improvement activities can be designed into the organization's existing routines. Note the use of "designed into". This is crucial. This means that for reality-based process improvement (reality-based CMMI implementation), the development activities must be known, they must be definable, and, they must be at work for the organization. Then, activities that achieve the goals of CMMI can be designed into those pre-existing activities.

This whole business of designing process improvement activities into product/project activities obviates a simple but powerful fact: effective process improvement (CMMI included) requires processes to be engineered. Sadly, a recent Google search on "process engineering" turned up few instances where the search term was associated with software processes, and most of those positive hits were about software products, not process improvement.

Besides the reality of what's already working, another attribute of our preferred implementation approach is that we don't expect the processes to be done by someone else, and, we don't expect them to just apparate into existence. To put both of those attributes in place, the reality-based approach doesn't rely on process descriptions to make the processes happen. Instead, the practices that achieve the goals of the processes are built into the very product and project activities of the organization's life cycles, and, the process descriptions simply describe where in those life cycles to find the practices happening.

One other attribute of our approach that is in stark contrast with the most common approaches is this: one of the expected practices of every managed process area is that they are planned for each project. The common approach interprets this as requiring a distinct plan for each process area for each project. Our approach categorically rejects this notion in favor of an epiphany we like to share with clients. You can have a plan for performing each process without having to create an entirely new plan for doing so as long as you've already done all the planning. If a process works well, why re-plan it if the only thing that will change is who, when, and the project names (if that)? Planning for performing a process is part of institutionalizing a managed process, which is what Generic Goal 2 (thus, Capability Level 2) achieve. If not re-inventing the planning piece for each project is appropriate, can't the same be said for the remainder of the practices in institutionalizing a managed process? We believe, yes.

In the end we extend this concept to account for the capabilities of having managed and defined processes. We extend it in such a way that any and all processes an organization wants to improve can be managed and defined whether or not those processes come from CMMI. The reality-based process improvement approach (CMMI or not) results in process improvement artifacts that appear where the "real" work gets done, and not as an overhead process, or a process performed by process commandos, or a process that only generates artifacts if developers and project managers have to go searching for proof that the process was performed.

For what it's worth, this approach is what we at Entinex call AgileCMMI

Do we have to do everything in the book? Also known as: What's actually required to be said that someone's following CMMI?

A: The Goals are required. Everything else is mostly commentary.

Really.

Honest.

Let's be frank (as if we haven't been frank thus far). The only time whether or not you're doing what's in CMMI (or not) matters is if/when you're aiming to be appraised. Otherwise, you'd just do whatever you want to get the most improvement out of and ignore what you don't need.

Having said that, the context of this answer is then about what's required for people who want it said that they are "doing" CMMI, and for the most part, this means that they're going to determine this via an appraisal. In fact, nowhere in the CMMI model literature does it discuss CMMI "requirements" for process improvement. The model is very careful to only use terms that imply that requirements of the model are for the model, not for process improvement. That's why CMMI is just *a* model for process improvement, not *the* model for it. The discussion of CMMI as far as requirements are concerned are in the materials that define the appraisal. This is also an often misunderstood aspect of CMMI.

SO... in the context of performing to the model -- especially where an appraisal is concerned -- there are three types of components:

required,
expected, and
informative

The goals are required. Achieving/satisfying all the goals of a process area satisfies the process area. Since goals don't get done by themselves (sports analogies work well here), an organization must be performing some kind of practices in order to achieve a goal, therefore, in the absence of any other practices, CMMI provides some practices that an organization might perform to satisfy each goal. That's why the practices are expected, but not required. The organization might have entirely different practices and might have a different number of practices, either of which are entirely OK as far as CMMI goes, but *something* must be happening to achieve a goal.

If an organization is *doing* something, then it must be resulting is some form of identifiable, tangible output. However, not every organization does the same thing, therefore not every organization produces the same outputs, and therefore sub-practices and work products of a process' practices are only informative, and neither expected, nor required.

The appraisal even has a term for practices that achieve goals that aren't in the model. They're called (logically enough) alternative practices! It logically leads to the reality that an organization's alternative practices include sub-practices and produce work products that aren't in the model. However, when it comes to the goals, they are immutable. The goals support the process area's purpose and each purpose supports process improvement. If an organization can claim to satisfactorily perform a process area without achieving some number of goals within it, then the SEI would really like to hear about that, because it would require a whole re-thinking of a goal's (and possibly a process area's) applicability towards process improvement.

What does this mean for an appraisal or the appraiser? It means that in order to demonstrate that an organization's process area (or a goal) is satisfied, they might not be able to rely on the stated practices, "typical" work products, or sub-practices of a process area. This means that not only might it be a good bit of work before an appraisal to get up to speed and elbow-deep into an organization's processes, but it could even drag with it the need to be somewhat competent in the kind of work an organization does or tools they use. DANGER! That kind of in-depth involvement puts appraisers (and consultants) at some risk: they might be exposed for not being competent in the ways and means of modern development! (Did we just say that?) Well, in for a penny... let's go the whole way... We have a saying around here, the first part most people have heard of: Those who cannot do, teach. [We added this next corollary:] Those who cannot teach, audit.

It's much easier on the appraiser if the expected components were investigated as "required" and if some of the informative materials were also expected or required in order to demonstrate the (now) "required" parts. This is closely tied to our discussion above regarding the implementation approaches. But until now, we didn't have enough background to get into it. The blunt approach to CMMI is replete with verbatim practices (which is often fine -- except where they're just floating out there without being tied to everyday work) and verbatim sub-practices, which starts to get a little fishy since sub-practices often change with the context of the projects, and verbatim typical work products, which is even fishier since it's rare that any one project will use/need/produce so many work products. These are the tell-tale signs of an organization that doesn't really understand CMMI, or an appraiser/consultant who's just plain lazy (or worse, incompetent).

Why does it cost so much?

A: That's a loaded and ambiguous question! What qualifies as "so much"? We'll just tell you what goes into the costs here and you can determine whether it's reasonable for you or how you can go about minimizing cost or maximizing value.

Here are the variables that go into the factors that affect cost:

Where you are *now* with respect to your implementation of process improvement using CMMI? (i.e., Gap Analysis Results)
How process-oriented is your company? Do you understand process improvement? Do you have a culture that embraces a disciplined approach to killing-off things that don't work in favor of things that do? Do you have process improvement professionals on staff? Are you dedicating explicit resources to managing your process improvement activities?
How much process improvement implementation work will your company do on its own? vs.
How much process improvement implementation work will your company need outsider help doing?
How much progress do you think you'll be able to make? Meaning, how fast can you absorb change? Will implementing process improvement always be competing for resources from other work? Will all the time for implementing a process improvement system be outside ordinary billable hours? And,
How quickly do you want to make progress?

Other considerations include your organization's size, the kind of work you do, the kind of products you build and techiques and tools you employ to build them, the kind of contracts you find yourself in, your relationship with your clients, the way you manage your projects, skills your people have and the nature and composition of your organization and management structures. NOT trivial.

Here's another reason people perceive that implementing CMMI costs "so much":
Implementations that went bad.

There are far more bad implementation stories than success stories. By "bad" we simply mean those implementations that, while many of them did achieve a maturity level ratings, and all the while they were spending lots of time and money, they were also causing disillusionment, cynicism, and processes that fundamentally didn't work! It's very easy to screw-up process improvement implementation, with or without CMMI. Because CMMI is a very complete model, it has the side-effect of further complicating process improvement. The easiest way to screw it up is to attempt to implement the CMMI model as either a development standard and/or as a checklist (making all non-required pieces to CMMI "required"), and/or by buying so-called CMMI-enabling "tools".

While there are also many ways to being a CMMI implementation "success story", what these stories share in common are the following attributes:

Treat process improvement with the same rigor as a technical project.
Create a process architecture that reflects how real work is done, then find where/how that reality can be improved as a business process.
Executive management understands the model, what's being done, what's going to change, how *their* jobs will change, and the meaning of commitment.
Create and sustain a culture of process improvement.
Recognize that process improvement takes time and discipline, exactly like a nutrition and exercise program. And,
Process Improvement can't be done *to* a project, it's done *by* the project by the very nature of their work, not by any explicit "CMMI activities"

But, we are not in a position to give numbers. We hope you now understand why.

Why does it take so long?

A: That's a loaded and ambiguous question! What qualifies as "so long"? We'll just tell you what goes into the time frames here and you can determine whether it's reasonable for you or how you can go about minimizing time or maximizing progress. Please see the previous question.

Why would anyone want to do CMMI if they didn't have to do it to get business?

A: Because they must be perceiving that the way they do technology development or services now isn't giving them everything they want or need to be confident in their ability to produce the results they want/expect (profit, happy clients, low overhead, etc.) and to do it in a consistent way. If that's not you, move on. Otherwise, give CMMI a shot and check back here for more elaboration on this topic soon.

Isn't CMMI just about software development?

A: Nope. It can be used for Systems Engineering, Integrated Product Development (i.e., large, complex projects), and Supplier Sourcing. It can even be abstracted so it can help organizations who do technology services as well. More on that coming up.

What's the difference between CMMI v1.1 and v1.2?

A: Detailed "deltas" are available from the SEI's web site. The summary of major changes to the model (only) are as follows:

Both representations (Staged/Continuous) are packaged together.
The advanced practices and common feature concepts were eliminated.
Hardware amplifications and examples were added.
All definitions were consolidated in the glossary.
IPPD practices were consolidated and simplified. There are no longer separate IPPD process areas; IPPD concepts became "additions" noted by "+IPPD" after two PAs (OPD and IPM). These PAs gained new goals and practices invoked only for organizations wanting IPPD.
Supplier Agreement Management (SAM) and Integrated Supplier Management (ISM) were consolidated, and the original v1.1 Supplier Sourcing addition was eliminated.
Generic practice (GP) elaborations were added to the (maturity/capability) 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 on projects at their startup.

With v1.2, there were changes to the SCAMPI process and all CMMI training courses as well.

What's the key limitation for approachng CMMI?

A: This question comes to us from one of our readers. We love our readers!

There really are no size or scope limitations to CMMI as far as an organization is concerned. CMMI can be put to good use in any sized organization doing any kind of solution development. The real driver (or limitation) is whether there's any need for process improvement. It's a limitation based in business. As we've said here, CMMI is used as a basis from which to create process improvement solutions that fit your particular organization in all its particular particularness. If an organization doesn't have a process improvement need, there's no need for a process improvement solution, we suppose.

The one limiting attribute of the model is that the organization pick the correct one for the type of work they do. There are currently three "Constellations" of the CMMI model. One each for Development, Acquisition, and Services (due in spring 2009). Neither the model nor the appraisal process are specific as to what type of "development" it applies towards. That means proposal development is just as "process improvable" as software, hardware, or wetware development. All that is necessary for that constellation is the development of solutions according to some abstract concept of a life cycle of your choosing. Because the model is not specific as to whether those solutions are technology products, proposal products, service solutions, or children's lunches, it requires that whoever is implementing it understand exactly what is going to happen when they do implement it. Although written with technology products in mind, it is not impossible to abstract the model for use in any activity where the input is a need and the output is a solution.

On the practical, implementation side, however, there are many limitations. In the previous paragraph we hinted that the broad applicability of the model necessitates a certain level of expertise for an organization to know what decisions must be made, and how to make them most appropriately. If we were pressed to pick only one, we'd have to say that misplaced expectations is the #1 common cause, or limiter in approaching CMMI. Especially the misplaced expectations of senior level organizational management

Misplaced expectations explains a lot about why CMMI efforts fail to meet their goals, or, if they succeed, they do so only at the expense of disillusionment, cynicism, lost moral, and employee turn-over, on top of the high monetary cost of the so-called "achievement" of a level rating.

Misplaced expectations lead to bad decisions in every aspect of life, and this is no different for CMMI. If we look at CMMI implementation like any other project, it becomes very easy to spot what misplaced expectations lead to: insufficient resources, improper allocation of responsibilities, unrealistic time and cost estimates, insufficient training, inappropriate measures of success, lack of leadership insight or oversight, lack of leadership accountability for owning the effort and instilling the necessary discipline to make the project succeed, and a dearth of enthusiasm or buy-in from project participants.

Do you get the picture?

Simply setting ones expectations appropriately with respect to CMMI must be the next step once it is determined that there is something going on within an organization that is a "Development" process (and/or later in 2007, a Service process and/or an Acquisition process).

So, in the end, the only solution to mitigating misplaced expectations is to get smart about what the model is, what the model requires, what are the collateral implications of implementation, and how the appraisal works.

After all. implementing CMMI must be a strategic decision. Every respect an organization pays to other serious strategic decisions must be afforded to the decision to pursue CMMI.

We hate that this is the answer, because we wish it were more cut and dry. But the fact that it's not cut and dry is the same issue that leads people to ask about implementation cost and time long before any such answers ought to be mentioned. There are so many factors that the only way to really get around these challenges (limitations) is to get educated in process improvement, CMMI, and in the appraisal process and requirements.

This FAQ can help a lot. When we set out to create it, we thought it would be helpful. Feedback has indicated that it's been more than helpful, it's a bonefide resource. But the FAQ can't address specific questions from specific companies. After all, those types of questions wouldn't be the "F" in "FAQ", would they?

The authors here believe that these answers ought to be provided to a potential CMMI traveller before they set out on the path. Unfortunately, like an inexperienced canyon hiker who doesn't wear the right shoes or take enough water, we've found that not enough CMMI travellers avail themselves of this information. However, much worse than that, an appallingly high number of CMMI consultants do not volunteer this information as part of their own due diligence to evaluate a potential client and to help the prospect (or new client) arrive at decisions most suitable to their circumstances and context, *That* is a true blemish on the industry.

What's the key effort required in CMMI implementation?

A: This question also comes to us from one of our readers. We love our readers!

Be sure to read the above question and answer as it is closely related to this one.

A key effort, in our opinion, in CMMI implementation is the identification of the organization's actual development life cycle. In other words, what is their reality? Any organization successfully operating and, to some extent, profitably growing must be doing something that *works* for *them* and delivers on customer expectations. Figuring out what that is, for each organization, is key to implementing CMMI. There's really no magic to it.

Another key effort is organizing a process architecture.that simultaneously reflects the reality just discovered and describes where and how process improvement takes place within that reality. If process improvement isn't taking place, now you know where you need to insert process improvement activities, and, you have some insight into how to best design the process improvement solution for the organization. It is highly recommended that the process of designing the process solution receive guidance from someone who knows how to do this as well as someone who understands the CMMI and how it is appraised. Such a person could be a hired gun, or a smart hire, depending on the needs and resources of the organization.

The important consideration to note is that it requires the combined knowledge of each organization's reality-based context as well as knowledge of the CMMI model and of the appraisal to come together to implement CMMI well.

And therein lies an assumption we've made in answering this question. That the organization wants to implement CMMI "smartly", and, in a way that results in lasting value that persists beyond the appraisal. There are other ways to just make it through an appraisal, but since we at CMMIFAQ don't advocate those approaches we're not gonna write about them. If you keep reading, you'll probably figure out what those approaches are. Bottom line: design your process improvement efforts into your revenue-generating activities and you will not only benefit from the improvements, you will also find yourself with a robust process improvement system which requires no evidence production when it comes time to perform appraisals. It becomes a simple matter of just doing the development work and allowing the work products of that development to speak process improvement for themselves.

Appraisals/Ratings FAQs

How do we get "certified"?

A: OK, let's get something straight here and foreverafter: You do not get "certified" in CMMI. At least not yet. In the US, the concept of a "certification" carries a specific legal expectation and companies who are *rated* (and that *IS* the right term) to a level of the CMMI are not being "certified" to anything.

So the correct question is, 'how do you get "rated"?'. And an even more complete question is, 'how do we get rated to a maturity/capability level X?'

We'll get to the difference between Maturity Levels and Capability Levels and what the level numbers mean shortly.

The short answer for how to get rated still leaves a lot of information on the table. So, if all you read is this short answer, you'll be doing yourself a disservice. The really short answer on getting a level rating is that you get appraised by an appraisal team led by an SEI-authorized Lead Appraiser who determine whether you are performing the practices of the CMMI.

This answer is so loaded with hidden terms it's frightening. So just so you know that you've been warned that this answer is too short, we'll point out each of the terms in our previous answer that has hidden meaning in it:

getting
level
rating
you
get appraised
appraisal team
led
SEI-authorized
Lead Appraiser
determine
whether
performing
practices
CMMI.

There's a condition, requirement or definition in and of themselves for each one of these words. Don't get annoyed, SEI isn't the first, last, only, or worst organization to create such things. Every non-trivial discipline is loaded with concepts that experts can do in their sleep but that requires effort to understand by everyone else. It's true of EVERY profession so, CHILL OUT. Need an example? Think of it like getting into shape. The short answer is "diet and exercise". Wonderful. What do you eat? What sort of work-out routine is right for you? See? Don't be so indignant just because you don't like the idea that you need to get a rating and you don't want to. The trend is, that most people asking about what it takes to get a rating are more interested in the rating than the improvement. That's OK... We understand. Sadly, too well.

Keep reading this FAQ. What else did you have to do today anyway?

How long does it take?

A: Here's another one of those dead give-away questions that a company is more interested in the rating than the improvement.

OK, that's a little unfair. Let's just say that as often as we hear this question, our judgmental attitude holds for ALMOST everyone who asks it. Allright, so maybe you are the exception. The truth is, it's a fair question. For every company.

A rare few companies don't care how long it takes. Lucky them. Applying a generous dose of benefit of the doubt, we can assume that the question is asked not for "how soon can we get this out of the way?" as much as from "are there any rules that dictate a minimum time before performing an appraisal?" How we can tell whether the company is interested in the improvements vs. the rating is simply a linear function of how long into the conversation we are before it gets asked. All-too-often, the source of the question is less ignorance of the process and more ignorance of the point behind going through the process.

Process improvement purists wish more people were more interested in the journey than in the destination. We are process improvement pragmatists. We know you're not looking at CMMI because you had nothing better to do with your time and money. That's for Bill Gates and his very worthy charitable endeavors. The company he's famous for founding is still in business for the money. FAST. So, how long it takes is a real question regardless of how you spend your money.

Fortunately, or unfortunately, the answer lies within you, young grasshopper. Really. We can't give you a much better answer than that. What we can do, however, is give you a list of the attributes that you can use to estimate how long it will take you, and give you a few example cases and some very general time-ranges.

Let's start again with our favorite analogy. Say you're carrying around about 40lbs

(18.18kg) of excess body fat. How long will it take you to lose the fat? A year? Two? 6 months? Can one person do in 6 months what another person needs 2 years? We all know the answer to these questions. "IT DEPENDS!"

EXACTLY! How quickly a company can become rated to a pre-determined point in the CMMI's rating scale depends entirely on them and their circumstances. It depends on:

their level of commitment,
their tolerance for and ability to implement change,
how busy they are,
what they know about process improvement in general and CMMI in particular, and
it depends on where they are as a starting point and
how much of the organization they want to include in the rating.

Working backwards from the appraisal itself, the absolute minimum calendar time a company should expect between when the starting gun is fired and when they cross the finish line is a simple matter of logistics. Probably about a month if they're lucky. Two months would be more realistic. These 2 months, of course, are just the logistics and prep-work necessary to plan and conduct the appraisal and the activities that lead to an appraisal. Obviously, this time frame would only be realistic if the company was completely ready for the appraisal, had done all their homework, knew exactly what the state of their process implementation was and were literally trying to do nothing more than figure out how much time they had before they could conduct the appraisal. Of course, such a company wouldn't be asking the question. They'd already know.

So then there's almost everyone else. Everyone else needs time to first determine where they are in their implementation of CMMI practices. This is like saying, first we need to

find out how much excess fat we're carrying around. A trip to the right physician would answer this. For CMMI, it's called a "Gap Analysis" and can take a week or two. Then, depending on those factors bulleted earlier, the gap found by the analysis would need to be filled. This is the part where a company would need to figure out what it's optimum sustainable diet and exercise routine should be, and, how long to stick with it to see the desired results.

In CMMI v1.1, there are 25 Process Areas, and in v1.2 there are 22. There are two ways to look at them. The duration of the gap closure activities would also be a function of how many (and which ones) of the Process Areas the organization wanted appraised. Each of the Process Areas could be analogous to some aspect of a healthy lifestyle such as food choices, food quantity, shopping, cooking, meal planning, exercises, frequency, repetitions, technique, equipment, blood work, rest, stress management, work environment, time management, and so on. Obviously, the more of the lifestyle someone wanted to adopt, the longer it would likely take.

Once a gap is filled (i.e., the weight is lost and/or new muscle mass is added), an organization should give itself at least 3 months (on the short-project end) to 12 months (on the larger project end) to actually use their processes. This would provide them with enough data to actually conduct an appraisal. However, the actual metric isn't the calendar, it's the cycle-time of their development processes. Often called their development life-cycle. Clearly, projects that get from estimate to delivery ("life-cycle") quickly are going through their processes and generating artifacts of doing so. This is the value to key off of moreso than the clock.

On the fat-loss analogy, this would be like finding that point where diet and exercise are enough to keep the weight off and one is able to demonstrate to themselves (or others, as needed) that they can, in fact, live and sustain a healthy lifestyle -- in the face of temptation and other uncertainties.

Once people internalize how process improvement works, how long it takes to earn a rating is a question such people stop asking. Like fat loss and getting into shape, process improvement is a discipline backed by many best practices. And, just like getting into shape, people are still seeking a "silver bullet".

We, on the other hand, stick to a healthy diet and exercise program. When we're off track we know it. We gain fat and feel like crap. When we're on it, we see the results.

Make sense?

How much does it cost?

A: If you've read the answer to the previous question and are still asking this question then you must really only be wondering about fees, attributes of cost or other general costs. Otherwise, go and read the answer to "How long does it take?" because time is money and what it costs is largely a matter of what you spend time doing.

As for fees, attributes of cost and other general costs, here's break-down of things that can or will cost you money towards being rated to a capability or maturity level of the CMMI:

Lead Appraiser

As a benchmark for your ball-park, the SEI has a cadre of Lead Appraisers who can be hired (NOTE: only a few handfuls of Lead Appraisers actually work for the SEI, most are employees of other companies or operate independently of the SEI.). The SEI charges $1800/day from the moment they leave their home (or their last engagement) to the moment they get back home (or to their next engagement). They also charge for all travel expenses as well as time they spend away from your site to do their preparatory and concluding activities. Also, they will often work by the "book". Meaning, a guidebook exists that assists with planning appraisals. The guide suggests that, based on the scope of the appraisal, appraisals be scheduled for a certain duration and not be condensed into fewer days and longer hours. Lead Appraisers are free to charge whatever they want. not many charge the way SEI does.

Someone will also need to provide Appraisal Team Training to the people you plan to have on the Appraisal Team. This takes 2 days and is usually done by a Lead Appraiser, and best if done by the Lead Appraiser you plan to have doing your appraisal.

So, plan on the Lead Appraiser needing about 1-3 weeks to do the preparatory work for an appraisal, including Appraisal Team Training and at least one Readiness Review, and then 1-3 weeks to perform the appraisal itself (depending on the scope), then another day to wrap-up all the paperwork.

Appraisal Team Members

Process Improvement Consulting

Fees

Consulting firms can charge whatever they want and call it whatever they want, but if anyone is implying that there are SEI-mandated "fees" for consulting or appraising, they're only implying this. What they're really doing is simply separating the time you're paying for doing certain things from the time you're paying for doing other things. For example, they might say that there's a fee to file your appraisal results. Not with the SEI, there's not, but it does take time and it's reasonable for them to simply charge you some amount for the time it takes them to put in all the paperwork.
Other General Costs
As above, the only other general costs associated with an appraisal are:

Official training, and
your employees' time on the clock.

NOTICE what's *NOT* in the list above: TOOLS.

There is NO requirement for the purchase or use of any tool. Anyone saying that in order to "comply" with CMMI (or the appraisal) that you must purchase a tool, they're full of *crap!*

Some consultants do use tools as part of their work and as part of you hiring them you are also buying a license to use the tool. That's OK. Since you will end up using the tool after they're gone, it's reasonable that you should pay for using something that is either the consultant's intellectual property, or something they bought and are bringing to the table. And, it's up to you if you want to hire that company. It's not reasonable for you to hire a consultant who tells you they use a tool and then tell them not to use it so you don't have to pay for their tools. Many consultants work their pricing structure into the productivity and efficiencies they gain by using a tool and asking them to stand by their rates when you've asked them to leave their tools in the shed is not playing nice. On the other hand, anyone telling you that if you don't buy their tool then you are not going to meet the CMMI's "requirements" or "pass" the appraisal is FLAT OUT LYING LYING LYING!!! and should be reported to the SEI! And, you can do that by taking a number of actions listed here.

What's involved (in getting a rating)?

A: Um... that's a little broad, don'chya think? But, we get that question frequently enough so we might as well answer it. At least at a very high altitude.

There are three broad steps towards achieving a level rating:

1. Know where you are now.
This is usually called a "gap analysis" The right person to do this is someone who really understands the CMMI and how to appraise for the CMMI. Too often we get into companies who thought they were simply "smart enough " to do it themselves -- in some cases doing nothing more than downloading the model and reading it. Even taking the SEI's Introduction to CMMI course is seldom enough to determine, without any other direct experience, how closely your company is performing the expected practices of CMMI, or how your particular implementation of the practices will fare in an appraisal. Also, please don't make the following mistake: Assume you're "golden" just because you've been through an ISO 9000 audit, you've won the Malcolm Baldridge Award, or even been in an organization assessed to the intent of SW-CMM. We've actually found that prior experience with other process-oriented bodies of work can work against a company's true understanding of what CMMI is about, how to implement it effectively, and how to appraise their practices.

Once you know what and where your gaps are in implementation you're ready for the next broad step.

2. Fill your gaps.
This is usually called, in CMMI circles, "Process Improvement" Although this step implies that your processes aren't up to the task as they stand now, what it really implies is that you will likely be making some changes to your current processes as you implement CMMI's practices and the method you should follow is one of process improvement and not simply a re-skinning of your paper trail. The entire purpose behind CMMI is that of process improvement and companies that simply slap a layer of CMMI processes over top of what they're currently doing is not process improvement, it's death by process.

It's come to our attention that CMMI has a reputation as being "death by process" as it is. We firmly believe that it's the latter approach towards CMMI implementation, as described in the previous paragraph, that causes this, not CMMI. To be blunt (you're used to it by now, yes?), slapping CMMI over top of your existing process, those processes that you feel have been working all along, is a STUPID way to implement CMMI.

On the other hand, if you do find value in practices CMMI promotes, then what you want to be doing is implementing them in a way that continues to provide you with the value-proposition of the things you like about your current processes and replacing or adding with CMMI those things that could use some strengthening. The smoothest way to this approach is by following CMMI as a guide to process improvement. Again, please be advised that doing this on your own without a CMMI expert employee or consultant is not advisable for the same reasons having an expert is best for performing the gap analysis.

One last comment on this step (and it's a bit of an unsung truism about the CMMI): companies who are honestly thrilled with their current process and really have a handle on the outcome of their efforts are probably doing a lot of what the CMMI would have you doing. Such companies may call their activities by different names, they might reach the goals in a less traditional way, but ultimately, they are getting the job done and are still in business, so they must be doing things right. (Or at least doing the right things.) If this is you, then your effort towards implementing CMMI is going to be quite painless and enjoyable.

3. Get appraised.
Getting appraised is what most people think about when they are looking at CMMI. The appraisal is what gives an organization their "Level". Once the appropriate expert can make a sound call on your organization's implementation of the CMMI practices, you can start planning for an appraisal. Details of the appraisal are answered elsewhere in this FAQ.

How does the appraisal work?

A: The appraisal process is guided by something called the Method Definition Document (MDD). If you are not familiar with the appraisal process already (which you aren't 'cause you're asking the question), you don't want to try to read this unless you're doing some whacky exercise in self-hypnosis. The MDD is based on a requirements spec called the Appraisal Requirements for CMMI (ARC). And, reading of that document is strictly forbidden without a prescription or special medical dispensation. The documents are available for download from SEI's Web site and are actually well-written and really useful if you're a Lead Appraiser or studying to be one, but otherwise it's gonna sound like gibberish. Don't say we didn't warn you.

Just so you understand that the complete answer to this question is ordinarily delivered in 2 days' worth of training. We're obviously limited in what we can explain here.

We're going to pick up the appraisal with the portion of the appraisal that most people think about: the on-site period. It's that period of time when there's an appraisal team at your company and they're looking at your evidence and conducting interviews (or performing some other accepted form of verbal affirmation). It's at the end of this period that a company gets the results of the appraisal and, when all goes well, a rating.

So... that's pretty much what happens at the appraisal: A team, lead by a Lead Appraiser looks at evidence and makes a judgment on that evidence regarding the extent to which the it demonstrates that CMMI's practices are being implemented. There are 3 types of evidence: Direct Artifacts, Indirect Artifacts and Affirmations. At least one Direct Artifact plus either an Indirect Artifact or an Affirmation is required for each practice in the scope of the appraisal. There are rules governing the minimum number of Affirmations too. For each practice in the scope of the appraisal the evidence is looked at collectively for that practice and a determination is made regarding the extent to which the practice is being implemented. This is called "practice characterization" The characterization scale is: Fully Implemented, Largely Implemented, Partially Implemented, and Not Implemented. There's also "Not Rated" and "Not Yet" which get a bit too complicated for this medium to address.

The evidence comes from actual projects' work products. In actuality, instead of specifying that evidence come from "projects" the term is instantiations. The number of projects (er, instantiations) is a function of the organization to which the rating will apply. You need a sample of instantiations representative of the organization. And, no, you can't pick them, the Lead Appraiser works with you to pick them; and, no, you can't look at only the "best" aspects of a project and puzzle together all the good-looking evidence from a bunch of different projects. Three is a typical number of instantiations for even large organizations.

The characterizations are then looked at in aggregate according to rules in the MDD across all instantiations. Basically, after aggregating the characterizations across all instantiations, no single practice can be characterized as less than Largely Implemented or it will spell disaster. Even then, if certain practices are found even "Largely Implemented", and the appraisal team believes there's a pattern in what they're seeing that causes these practices to only be found as "Largely Implemented", the team may still choose to say that whatever's causing these practices to not be Fully Implemented is worrisome enough to preclude the organization from achieving the goals of the Process Area, and if any goal in a Process Area isn't achieved, then it can't be said that the whole Process Area is being satisfied, can it? And, that, our friends, is how the appraisal works: it's a search for whether the organization is satisfying the goals of those Process Areas in scope of the appraisal.

What's a SCAMPI?

A: Ah-ha! Finally! A quick and easy question!

Who can do the appraisal?

A: Another quick and easy question, thanks!

An Authorized Lead Appraiser. Authorized by who? The SEI.
Lead Appraisers (as of this writing) have to qualify by surviving the following activities in this order (sort-a):

Introduction to CMMI
Intermediate Concepts of CMMI
Being a team member on at least 2 SCAMPIs*
SCAMPI Lead Appraiser Training, and
Being observed performing a SCAMPI by one of a very few number of people the SEI trust to do that sort of thing

*Participating on 2 SCAMPIs can happen any time after the Introduction to CMMI course but must happen prior to applying for SCAMPI Lead Appraiser Training. The placement of SCAMPI participation is unrelated to when someone takes Intermediate Concepts of CMMI.

New, as of late 2006, Lead Appraisers must become certified by SEI to lead SCAMPIs on maturity or capability levels 4 and 5. Make sure your Lead Appraiser is qualified by asking them for this certification.

IMPORTANT! ALSO new, as of v1.2 of the MDD:
The organization being appraised needs to have a contractual relationship with the Partner Organization sponsoring the Lead Appraiser performing the appraisal in order for the appraisal to be valid.

In other words, Lead Appraisers who aren't directly working for a Partner (or, who aren't themselves representative of a Partner), can't contract to perform a SCAMPI without the contractual involvement of a Partner. That's not to say that money needs to be involved, and, it also doesn't mean that the appraiser needs to negotiate their dealings through Partners, however, it does mean that the Partner at least know about the appraisal and the relationship being established with the organization being appraised. This was done in an effort to improve the Partner knowledge of activities happening in their name. And hopefully, also improve the quality of those activities.

Can we have our own people on the appraisal?

A: Yes! Yes, in fact, it's encouraged.

The appraisal team must be at least 4 people strong (including the Lead Appraiser), and with your company's employees on the appraisal team you increase the odds of buy-in to the appraisal process as well as follow-up and follow-through on any recommended actions from the appraisal. There are a number of qualifications potential team members must meet, the most logistically challenging of them being that candidate team members must have had a licensed delivery of the Introduction to CMMI before going into the appraisal activities (which begin a month or more before the actual on-site period). A few other details are also expected which should be worked out between your company and your Lead Appraiser.

What sort of evidence is required by the appraisal?

A: There are 3 types of evidence: Direct Artifacts (D), Indirect Artifacts (I) and Affirmations (A). For each practice in the scope of an appraisal, the requirement for evidence (in a SCAMPI Class A appraisal -- which we'll get to later) is as follows:

1 * D + 1 * (I or A)

There's a requirement for a minimum number of A's overall, which will touched upon in the explanation of each of the three evidence types:

Direct Artifacts (D)

Indirect Artifacts (I)

Affirmations (A)

Yes, in some cases evidence can be a Direct Artifact for one practice and an Indirect Artifact for a different practice. For example, the Project Monitoring and Control (PMC) Process Area says something along the lines of check in on your project once in a while. You do that and one of the things that you discuss are requirements that have changes since the last status meeting. Well, the notes from the meeting would be a Direct artifact for PMC, but could also be an Indirect artifact for the Requirements Management (ReqM) Process Area that says you should update your requirements as they change during the course of a project.

How much of our company can we get appraised?

A: The part of your company that gets the actual rating is called the "Organizational Unit". This can be the entire company or only parts of it as determined by the types of projects that the company wants the appraisal to apply towards. For the appraisal to apply to an entire company, projects that represent all the sorts of work that the company does would need to be evaluated in the appraisal. A project that consumes the entire company, and is the only project that company has would result in the appraisal on that one project and that company could say that it's entire company has achieved the level rating awarded. The actual composition of the organizational unit is something that needs to be defined up-front during appraisal planning. The Lead Appraiser must analyze the selection of projects to ensure that the projects do, in fact, represent the organizational unit of the appraisal. The more variety in the kinds of projects in the organizational unit, the more projects will be needed. Also, the broader the application of the appraisal results, the broader the scope of projects. Meaning, if the company has a number of sites, projects representing each site must be included. Multi-site projects are OK, but using one location's project to represent another will not work. There are a number of facets that are analyzed including the type of work, the size of the project, where the work is being done, the disciplines involved, the phases of development life cycle that the project covers, the number of people on the projects...etc. All of which are compared to the same facets of the organizational unit at-large. The point to all this is that the sample of projects must be representative of the organizational unit and cannot leave gaps in coverage. The number of projects in needed in each facet is the subject of the next question.

How many projects need to be appraised?

A: Enough such that the projects chosen can represent the organization to which the appraisal results and process improvement recommendations will apply. Within this includes "Focus Projects" (FP) and "Non-Focus Projects" (NFP) What are or are not FPs or NFPs has to do with how much of your development life cycle the projects cover as well as whether the projects came before or after the processes that are being evaluated.

Specifically, the question of Focus Projects and Non-Focus Projects is almost entirely moot when using the Continuous Representation for the model implementation and appraisal AND there are no project management process areas being appraised.

Our good friend, SEI Visiting Scientist, a Lead Appraiser's Lead Appraiser, and super-nice-guy Judah Mogilensky, of Process Enhancement Partners, provided this explanation:

...Okay, FPs and NFPs: This is really a formalization of something that has often gone on, and it is prompted by the need to have "at least 3 instances of each practice in each project-related PA in the model scope of the appraisal." There are two typical situations where one would resort to NFPs:

1. Not Yet situations, e.g., a project is still in major development, and has not yet had the opportunity to enact some of the Product Integration process area practices, at the top system level, that are normally only carried out toward the end of the project. To fill in the NY holes, we pick a completed NFP and examine Product Integration for it.

2. Legacy situations, e.g., a project was started a long time ago, specifically before the current planning and estimating practices [of the Project Planning process area] were put into place. So the planning and estimation artifacts do not reflect the current process. To fill in these holes, we pick a relatively new, early stage NFP and examine Project Planning for it.

It there a risk of cherry-picking? Well, of course, but not more than there always was. What still guards against this is the new requirement in the Appraisal Disclosure Statement to be much more explicit about how well the selected sample [see previous question] covers critical parameters, e.g, not just what percentage of the development population is covered by the selected projects (which used to be the main thing we looked at), but what percentage of the business lines or project types are covered, what percentage of the customer types are covered, what percentage of the geographic locations are covered, maybe even what percentage of the organization’s revenue is covered. There were some attempts at defining required project sampling, but it was always possible to generate a counter-example to every proposal, so the appraisal team settled for full disclosure of the sample basis in the ADS.

The current guidance is a little weak for organizations that have fewer than 3 projects, but those have always been exceptional cases. The expectation, I think, is that we would see a lot of "100%" coverage parameters. And you can’t really ask for more that 100%.

Finally, keep in mind that there is no requirement to have NFPs at all, if they are not needed. Also, FPs need only be examined for all PAs in scope, so, if you have a small appraisal scope of just a few PAs, that’s all the FPs have to cover.

Can we have more than one appraisal and inch our way towards a rating?

A: No, At least not yet. Well, at least not in the way you're thinking.
You can have as many appraisals as you want, however, at this time, if you want a Maturity Level rating (or even a Capability Level rating -- more on that later), you will only achieve that if the appraisal looks at all the evidence for all the Process Areas in the scope of the appraisal in a single appraisal. There is talk afoot of allowing something like a "cumulative" appraisals where you can do some subset of an appraisal scope then come back and do a little more, and so on until you've completed the scope and then putting it all together for a rating, but that's not how it works today. If you do perform several appraisals where none (except, perhaps, the last) are for a complete Maturity Level, it would only serve to provide you a sense of how you're doing, you couldn't use the results of those appraisals to pare down what needs to be done at the appraisal you're conducting for "all the marbles".

If we go for a "level" now, do we have to go through it again to get to the next "level"?

A: Yes. Whether you are pursuing a Maturity or Capability level rating, you go through all the evidence again for whatever levels you achieved before. One reason is that at this time there are no mechanisms in place to allow for "cumulative" appraisals, which is what would be necessary to make this approach work. However, even more fundamentally, the appraisal team and Lead Appraiser can't be expected to assume that there would be evidence from the lower levels to support the higher levels' activities. Even more basic than that is the fact that the levels support one another and it would be very unlikely that appraising to a higher level could be accomplished without evidence from the earlier levels.

The only exception to this is if an appraisal is spread out over a period of time, and is, in fact, one long appraisal. The time-limit for completing a single appraisal is 90 days.

How long does the "certification" last?

A: Setting aside the fact that it's *NOT* a "certification" (See #1), the current answer is that Appraisal Results will be recognized by the SEI for three (3) years from date of the appraisal, or until August 2007, whichever is later.

What is the difference between SCAMPI Class A, B and C appraisals?

A: The differences boil down to the level of rigor, and, as reflection of the level of rigor, to what the outcomes can be.

A SCAMPI class A is the appraisal most people think of when they think about CMMI appraisals. It is the only class of SCAMPI that can result in a level rating. And, as one might imagine, it requires the most rigor: an authorized lead appraiser, a minimum number (4) of people on the appraisal team collectively having explicit qualifications, very specific types of evidence, and certain minimum number (and type) of projects to characterize the process improvement of the organizational unit.

SCAMPI classes B & C have much wider ranges in terms of team composition and evidence, as well as how they're used and the level of rigor one wants to apply. Although a SCAMPI B can't provide an offical (or otherwise) level rating, one can conduct a SCAMPI B with all the rigor and "fanfare" of a SCAMPI A. Many organizations use SCAMPI B as a means of preparing for a SCAMPI A and/or as a means of conduting process reviews or audits. SCAMPI B requires less of the kinds of evidence, only 2 minimum team members, and since no level rating is given, the sample of projects required to be appraised is less specific.

The SCAMPI C is very much the "formal" way to do an otherwise informal process review. It can be performed with only one person as the appraisal team-and-appraiser, it can use either direct, indirect, or interview artifacts, in no specific quantity or combination, and is frequently best used for perfoming what many call a "gap analysis". Of course, it can be used for more that that. Though, due to the low expectation of evidence, SCAMPI C is often used to target specific needs and/or when an organization is generally expecting that there will be many more findings than conclusive improvement to be found.

How do we pick a consultant or lead appraiser?

A: Anyone claiming to be a lead appraiser must be authorized by the SEI to do so. The SEI refers, collectively, to all people authorized to work on their behalf as an "authorized individual". Thus, all actual lead appraisers are "authorized individuals". You can search/sort a list of such people here, and, specifically limit your search to lead appraisers. To narrow your search to a geographic area, you're better off searching for an SEI partner. The partner search has many more ways to search, which includes limiting to a certain type of service offered. And then, once you find a partner, you can see the authorized individuals associated with that partner.

However, one need not be a lead appraiser to consult on CMMI. In fact, there are many people very well experienced in implementing CMMI and with appraisal experience who are not credentialed to do appraisals or official training. Many more experienced people than there are authorized individuals. Frequently, because they don't carry authorizations, they're not able to charge as much as those who are authorized. The trick is: finding them. Many work for partners, so once you find a partner, you might ask about the authorizations of their consultants as a guage of what you can expect to pay. Many people experienced in CMMI work for large organizations who need their services full-time, on site, and moonlight as consultants. Others are just independent consultants and get much of their work by word-of-mouth.

Though, the question isn't "how do we find a consultant or lead appraiser" but, "how do we pick from all the ones out there?!?!?".

As you can guess, there's not a simple answer, but we can say two things:

Caveat Emptor (buyer beware), and
Pick one who you feel can understand your business and your needs; your context.

WHY must the buyer beware? Because interpreting models for how a given implementation can be done, and also recognizing that a given implementation of a model is a ligitimate interpretation of the model are far from exact science.

CMMI is a model not a standard, as we've said many times before. It's not something that, when applied, will look the same each time. Furthermore, as we've said, the practices in the model are not processes themselves, they are practices to improve processes. It takes skill to effectively interpret the model and implement it in a given situation, and, it takes contextual relate-ability to appraise whether the model has been implemented or interpreted properly/effectively.

There are (in our opinion) far too many lead appraisers (and consultants) who don't know how to/don't want to/don't appreciate (or are too lazy to) do what it takes to help clients design contextually appropriate process solutions, and/or to allow for contextually-driven interpretations of model practices when performing an appraisal. Symptoms of such an appraiser or consultant are in what they consider valid evidence of the practices, or valid descriptions of the processes, or how they describe their approach towards working with an organization to build up their practices.

An appraiser or consultant may not be suitable to a given buyer if they only expect to create, see, or will accept "typical work products" as evidence, or if they expect to see, create, or will accept process descriptions with each CMMI practice spelled out, or if they expect organizations starting out to generate artifacts that address model practices but don't add value to the product development process. None of these characteristics are required (or prevented) by CMMI or the SCAMPI appraisal method. Therefore, buyers must be able to select the CMMI service provider whose attitude, knowledge, and experience suits their needs. After all, the model and appraisal process can allow for a wide variety of strategies, tactics, and contexts, but not every consultant or appraiser will (or can) allow for it.

What this means, in practical terms, is that buyers of CMMI services must be able to interview potential consultants and lead appraisers for their attitude towards, and knowledge and experience in practice implementation, evidence of practice implementation, and artifacts of the implementation. Furthermore, buyers must interview providers for the ability of the provider to pick up on, adapt, and appreciate the context in which the model has been or will be implemented.

The easiest example(s) to provide relate to whether the consultant or lead appraiser can communicate with the buyer in terms the buyer understands such as: being a small outfit, or using Agile development methods, or being embedded with the client and using the client's practices as well as their own. Another relevant inquiry is if the buyer can give or ask for some examples of practices as actually carried-out in or envisioned for their organization, and guage the response from the potential CMMI service provider as to what they think of those practices.

The challenge in conducting such an interview is that the buyer must have enough of an understanding of the model and the appraisal process to be able to determine whether what they're hearing is the provider's opinion/approach or whether what they're hearing is dictated by the model or the appraisal process. Sounds like an impossible task. Fear not, some CMMI service providers will give you this sort of unbiased advice or even a quick education for free. This FAQ and its contributors are aimed at providing this sort of advice because we feel it's to the detriment of the entire CMMI enterprise not to do so. Sadly, rough estimates of the number of such providers puts the figure at about 5-10% of the entire authorized population. As a character in a pretty good movie once said, "choose wisely".

Good luck!

Where can we see a list of organizations that have been appraised?

A: Finally! A question with a simple, straight-forward and easy answer!

Simply visit the SEI's Published Appraisal Results System, (PARS) and put in your query. It's fairly uncomplicated.
There are, however, a few points to keep in mind:

Not all organizations have asked to be listed in the system, not appearing does not guarantee they have not been appraised.
If an organization has changed their name after being listed, they will *not* be listed with their subsequent name(s), organizations are only listed with the name they had when the appraisal was performed.
Pay close attention to the Organizational Unit (OU) (discussed on this FAQ here) of the appraisal. Though you may be interested in validating whether a company has been rated, it's rare that entire companies are rated (especially if the company is not small). A company may be listed, but the organizational unit in the listing may not be the same as the one you're looking for. Or, there may be several organizational units within a single company. Do not take for granted that the organization you are researching is (or its people are) the same as the one appearing in the system.
Once all the appraisal data is fully completed and submitted to the SEI, it can take 30 days before appearing in the PARS. Most common causes of taking longer include: » appraisal team or sponsor not completing their appraisal experience surveys, » appraisal sponsor not signing the appraisal disclosure statement (ADS), or » issues with the results that are being investigated by SEI's SCAMPI QA process.

What's the official record of the appraisal results?

A: The Appraisal Disclosure Statement (ADS) is the sole and entirety of the official results of the appraisal, regardless of what does or does not appear in the SEI's Published Appraisal Results System, (PARS). Nothing in any appraisal presentation, and unlikely anything to be found framed and on the wall at a company, or printed on a large banner and hung from a footbridge are offical or complete indication of what exactly was appraised and the meaning and context of the results of an appraisal. (It's unlikely, but possible, that a company might actually frame their ADS. It's several pages long; but in the spirit of avoiding any absolutes we can't prove, above, we used the phrase "...and unlikely anything to be found...".) In any case, the ADS is generated by the Lead Appraiser after all the other data has been collected and submitted to the appraisal system. It's signed by the appraiser and the sponsor, and contains all the details of the appraisal, its circumstances, the explicit organizational unit to which the results apply, and the results themselves. If someone were serious about determining whether an organization has been appraised, when, to what end, and to what scope, they should request to see the non-confidential parts (if any are even confidential) of the ADS.

Can we go directly to (Maturity or Capability) Level 5?

A: Technically, it *is* possible in the most explicit use of the term "possible" to be rated directly at maturity (or capability) level 5. All this means (in the case of maturity level 5, for example) is that the organization was appraised performing the Specific Goals of all 22 process areas up to and including Generic Goal 3 of each process area. The fact that they were not level-rated before this results in the organization having appeared as achieving ML5 "directly".

However, in reality, it's not likely that any organization would proceed to implement all 22 process areas without ever having performed any appraisals between the start of their process improvement program and their appraisal for ML5. What is more likely is that at certain points the organization will conduct appraisals to gauge their progress. Whether or not these intermediate appraisals were used to generate a level rating would be up to them. There's no requirement that appraisals generate ratings, so an organization appraising at ML5 and receiving a rating may appear to have gone directly to ML5, when in fact they had several appraisals before then -- none of which generated a rating.

Of course, there's another reality to consider: the SEI reviews all high maturity appraisals very carefully. If an organization has never had a CMMI (SCAMPI) appraisal prior to their appraisal for ML5, it will be viewed with even more scrutiny, and both the Lead Appraiser and the organization appraised can expect to get a call from the SEI's SCAMPI QA team. Not to mention that not having any appraisals prior to the one aiming for ML5 is extremely risky.

CMMI, Agile, LifeCycles and other Process Concepts FAQs

What if our development life cycle doesn't match-up with CMMI's?

A: CMMI isn't a development life cycle. It's a model for improving very particular areas of managing what goes on during development, regardless of the life cycle. This is a central tenet of Entinex' approach to CMMI and we'll explain further soon. Meanwhile check out our article where this subject comes up.

Doesn't the CMMI only work if you're following the "Waterfall" model?

A: NO! CMMI is not about development life cycles. While a fair criticism of CMMI is that many of the contributors come from a "Waterfall"- centric or a "Big Plan Up Front", "top-down" way of developing wares, they were at least careful not to box anyone into following a specific development method. Nonetheless, it takes very deep understanding of the CMMI to implement it, regardless of which life cycle you follow. We've got more to say on this, so check back in a bit. Meanwhile, you can browse over to our AgileCMMI blog.

How does CMMI compare with ISO/TL 9000 and ITIL? (or other standards?)

A: While there is considerable overlap between these models, frameworks, and "best" practices, they are different from each other and used for different purposes. People who ask this question come from one (or both) of two camps:

They're just totally unfamiliar with CMMI (and/or the others), and are asking innocently enough, and/or
They just look at CMMI (and the others) as some standard they need to comply with, and not as something that can make a positive difference in the operations of business.

(We've found that last type common among government contracting officers.)

Let's address a question of "standards" first.

The process areas and the practices within them are not intended on being or replacing any technical "standard" for doing anything. Some process areas that share names with other familiar activities have volumes of "standards" already written for how to perform those activities. Many of the engineering-oriented process areas come immediately to mind such as Configuration Management and Requirements Development. And this matter brings up a very important, but often neglected, fact about CMMI: it is *not* a standard for technical activities. And, for whatever CMMI *is* supposed to be used for, it does *not* a prescribe how to do anything in it.

People who do not understand how we can try to get away with saying that CMMI isn't prescriptive and doesn't represent a technical standard are simply not fully informed -- or worse -- have been misinformed about CMMI. We'd really love an opportunity to set the record straight.

CMMI is about improving management processes associated with developing and delivering technical products and services. CMMI is not about the technical processes needed to actually do the developing and delivering. The CMMI "process areas" are what the authors believe to be important elements that contribute to a systematic ability to affect process improvement in and among (the management of) those technical process and practices that actually develop and deliver the products and services.

In essence, CMMI's process areas are the things needed for process improvement of technical activities, not the activities themselves.
What CMMI is saying is:
In order to improve your processes, you need to manage your requirements, risks and configurations; you need to plan, monitor and control your projects; you need to measure and analyze the output of your efforts; you need to actually pay attention to the performance of your project to how well they follow processes and to whether your processes are working out for you.
CMMI then says: if you really want to get good at these things you'd have be making a focused effort on your processes, you'd have standardized process assets, an organization-wide training program and a formality to your technical activities that might otherwise be left to fend for themselves.
For the true process zeal: you'd be able to quantify the performance of your projects and processes and you'd be able improve them by focusing on what numbers tell you to focus on, not just what people gripe about the most. CMMI also says that if you're going to do a process, you should have a policy for doing it, a plan for it, resources, assignments, process-level training, stakeholder involvement, and other activities to make them stick.

If process improvement is what you want, it only makes sense, doesn't it?
(The types of activities mentioned here are from the process areas and generic practices, in case they weren't familiar to you.)

You see, CMMI has a number of process areas that are needed for technical activities, but their presence in CMMI is because these process are also needed for process engineering just as much as they are needed for technical engineering.

SO, if we disassemble a process area into its purpose and goals in light of the above understanding we will see that the purpose and goals are not oriented at technical activities, they're oriented towards process improvement activities. We can hope that in this context, the matter of whether CMMI is a technical standard can be laid to rest, and, we hope that we bring a deeper appreciation for how CMMI works.

With that, we can simply explain that ISO/TL 9000 and ITIL have a different focus than CMMI, and just like CMMI has process engineering processes that sound similar to technical engineering processes, these other bodies of knowledge also have their similar-sounding activities that are needed and relevant for the purpose they each represent. Since this isn't a FAQ about ISO/TL 9000 or ITIL, we hope it's enough of an answer for now to explain that wherever CMMI has a practice that seems like it's also in another body, CMMI does not innately conflict with the others.... there are ways of implementing CMMI that can make them all work well... however, an organization can go about implementing any practice under the sun that could conflict with some other practice, CMMI or otherwise, but it would not be because of anything in CMMI.

Aren't CMMI and Agile methods at opposite ends of the spectrum?

A: Not at all. We've got A LOT of content on this subject! Instead of being very redundant by putting something here, please check out the blog on that topic, and the SEI's Technical Note, CMMI or Agile: Why Not Embrace Both!.

How are CMMI and SOX (SarBox / Sarbanes-Oxley) Related?

A: They're not. Well... at least not in the way that many people think they might be.
See, many people think that because the Sarbanes-Oxley Act of 2002 (which we'll just call SarBox) frequently involves business process and IT infrastructure and related systems, that it involves CMMI. But, in actually, the connection to CMMI is rather weak and always is a function of the organization's intentional effort to connect the two.

SarBox is about public company corporate governance. It is a US law that aims to eliminate the excuse by corporate leaders of public companies that they "didn't know" some bit of information about their company that could result in mistakes (or outright lies) about accounting, work-in-process, inventory, earnings reports, valuations, sales/revenue forecasts, and so on.

Its origin is in the several accounting scandals revealed in the late 1990's and early 2000's.

The intersection of SarBox and CMMI is only in that companies working towards SarBox compliance are very often relying on systems and software to help them achieve their compliance. When a company says to an auditor, "our software (or systems) are capturing the data, and we rely on that data to be SarBox-compliant," then they might get into questions about the system's requirements, design, configuration, etc.

A company in such a position might look towards CMMI for ways of improving the management of their development practices if, in fact, they are relying on those practices to maintain their SarBox compliance.

The simple answer is this: SarBox and CMMI are not related and don't have similar practices, EXCEPT that some companies *make* them related because of the context in which they're using technology to be SarBox-compliant, and, their reliance on technology development disciplines and/or institutionalization of process improvement disciplines to make sure they have a handle on how they run the company.

That said, another quick connection between SarBox and CMMI is that a company already familiar with CMMI might want to use the GPs and perhaps a few PAs to deploy whatever they need to deploy to "establish and maintain" SarBox compliance. (Sorry, couldn't resist!)

There's another angle to mention:

Many executives seem to have the nasty trait of putting anything that looks, smells, sounds, tastes or feels like "compliance" requirements into the same "bucket".

When they make this mistake, they then jump to a conclusion that goes something like this:

"This is compliance, that is compliance, and that over there is compliance too. They must all be related, and therefore redundant. Which is best? Which is easiest? Which is cheapest? Which should I do first?"

This, of course, is utter nonsense, but it happens. The fact that implementation of these process-related concepts must be driven by the context of the business is just ignored. It is a symptom of an organization looking for the marketing benefit of some auditable achievement and not the benefit of the concepts behind the effort.

Though, in fairness, companies that must comply with SarBox don't have a choice, unless they can afford to go private by buying back all their stock.

SEI FAQs

Isn't this just a cash cow for the SEI?

A: Um, well, yeah... but as far as the SEI goes, they're just, in effect, a DOD contractor in all this. You see, the DOD put out an RFP for some university-based research/think-tank to come up with a "solution" to the problem of abysmal performance of software projects. The SEI was what the winning proposal would "get". And so, Carnegie Mellon University beat out the University of Maryland in the competition to host the SEI. The DOD liked CMU's proposed CMM (for software) approach for improving the quality, cost, and schedule fidelity of software development more than they liked U of M's Goal-Quality-Metric approach. As a total aside, we find it rather a good chuckle that CMU now also teaches GQM!

But, we digress. SEI is mandated to work on and continuously improve the field and body of knowledge for software management and engineering. That's how we now have CMMI v1.2 and a bevy of other process, engineering and management tools, models, courses, etc., where we started out with just CMM for software. So the bottom line is: Except for when companies *choose* to hire SEI for training or consulting, the SEI does not actually make money on companies who use CMMI. The majority of materials are free because they were developed with taxpayer money, and those things that aren't free are cost-recovery for administration of everyone using SEI services and licensed products. Let's be clear about something: organizations do not need SEI to improve their processes, and if companies want to avoid what they perceive as high costs, they can invest a relatively small amount to grow their own internal CMMI and SCAMPI wherewithal.

What makes SEI the authority on what are "best practices" in software?

A: Lest you think SEI is entirely made-up of ivory-tower academic pinheads, you'd be surprised to learn that SEI is still a university research institute, and as such is as worried as any business or school would be about their credibility, keeping their knowledge-base up-to-date with the latest research, techniques, technology and tools. Besides that, the vast majority of people who work on the CMMI come from industry, not academia. The list of contributors and reviewers is as impressive as it is long. While even we concede that the list is a bit heavy with companies who are Federal contractors and companies who can be described as large, deep-pocketed organizations with plenty of ability to absorb overhead, if we want to be fair, we should note that such companies are not alone, and, that they were among the few companies who showed any interest when things got kicked off. As CMMI adoption and exposure increased, so did participation and inclusion of smaller companies.

It's not so much, then, that SEI is the authority, it's the collection of expert software practitioners from across the business spectrum who are the authority. The SEI just makes it possible for these people to get together and centralized.

The question of whether or not there are actual *best* practices is out of scope for this FAQ. Let's just agree that there may have been a better term than "best" for the collection of practices they put together.

Do the Lead Appraisers work for the SEI?

A: Not all of them. In fact, just a few do. The rest are licensed to appraise through Partners (formerly known as Transition Partners), and some of them are also "visiting scientists" -- a loose way of saying "very part time". SEI does however administer and train people to be authorized to take leadership roles and responsibilities for leading appraisals and delivering Introduction to CMMI instruction.

In particular, SEI controls very closely how and when it allows people to become SCAMPI Lead Appraisers. Even still, while the cadre of people with the authority to observe candidate Lead Appraisers on behalf of the SEI is small, only a few of them are actually SEI employees. The rest are visiting scientists.

What's a "Transition Partner"?
What's the "Partner Network"?

A: Transition Partner is the name previously used for companies/organizations in the SEI's Partner Network. In 2006, the name given to this program (and to these organizations) was changed from Transition Partner to Partner Network. These are organizations (companies, individuals) who holds a license from the SEI to use SEI materials and perform "official" activities which are registered with the SEI such as formal, reported SCAMPIs and training. The original term "Transition Partner" comes from the concept of companies who are out in the field as SEI's partners helping other organizations transition to using CMMI.

All individuals wanting to be authorized to do things by the SEI in any way must be sponsored through a Partner and pay a licensing fee for each credential they want to hold.

How do we report concerns about ethics, conflicts of interest, and/or compliance?

A: Waste, Fraud, Abuse, and Noncompliance with Policies Harms Everyone. If you have concerns about the truth behind an organization's rating, or about the ethics, compliance or conflict-of-interest of a consultant or appraiser, we strongly encourage you to report these concerns to the SEI. You may also want to review the SEI's Partner policies, here, as well to ensure your concern is properly supported. All authorized and licensed individuals and organizations must operate through a Partner, so all investigations will include an inquiry to the Partner.

The SEI's Conflict of Interest form is here,
The web form to report concerns over Ethics and Compliance is here,
The US Hotline Phone Number (24/7/365) is: 1-877-217-6316, and
The direct reporting email address for Ethics and Compliance concerns is: ethics-compliance-reporting@sei.cmu.edu.

We sincerely hope you never have to use any of them, but if you do, we're very sorry. And, we hope you are undeterred from your process improvement aspirations.

Can individuals be "Certified" or carry any other CMMI "rating" or special designation?

A: Individuals can become:

members of the SEI, which is like membership in many other professional organizations,
authorized and/or certified as Instructors, Appraisers, and other designations,
licensed partners to be able to use SEI intellectual property and to register appraisals with the SEI,
Visiting or Affiliate Scientists of the SEI (i.e., part time or volunteer employees),
eligible to be appraisal team members by taking the licensed Introduction to CMMI and registering in the SEI's appraisal system, and
other credentials that are evolving over time, and non-CMMI credentials as well.

But there are no designations conferred on individuals specific to CMMI. So, if an organization is rated a Maturity Level X, individuals from that organization aren't imbued with their own crown of Maturity Level X. Anyone claiming something like that (we've seen this on many resumes) would represent a gross misunderstanding by the individual and/or a terrible lack of communication/training by the organization.

Also, taking Introduction to CMMI, or even the next class, Intermediate Concepts of CMMI, does not designate a person as a "certified" or "authorized" CMMI consultant. (We've seen that too.)

Currently, there are no SEI-authorized "Certified CMMI Consultant" designations whatsoever.

Training FAQs

Is there required training to "do" CMMI?

A: That depends on what you want to accomplish.

To just implement CMMI? None whatsoever. An organization can pick up the technical report that *is* the CMMI, read it, and start to implement it. SEI requires no training to do that. To be completely blunt, however, we have not found a single company yet who could take this layman's approach and make it through a SCAMPI. There are just some things that a few hours with someone willing and qualified to explain everything at least as far as SCAMPI is concerned can make a world of difference between success and disillusionment. (Entinex does that in a 4-hour session we call our Crash Course.)
To be on a SCAMPI team, a prerequisite is the Introduction to CMMI course. Then, in preparation for the SCAMPI itself, team members receive "Appraisal Team Training" from the Lead Appraiser (or an alternative qualified individual) prior to the appraisal -- but this is part of the appraisal process and not training that must be delivered by SEI or a Partner.
To be an Introduction to CMMI Instructor, one also needs Intermediate Concepts of CMMI, the CMMI Instructor Training course and then be observed delivering the course before becoming authorized to deliver it on one's own.
To be a Lead Appraiser, one needs Introduction to CMMI, Intermediate Concepts of CMMI, to participate as a team member on two SCAMPI appraisals, the SCAMPI Lead Appraiser course and also to be observed leading a SCAMPI appraisal.

Who can provide CMMI-related training?

A: The SEI itself, and people authorized by SEI *and* working through a Partner can deliver any training they are authorized to deliver -- if the expectation is that there will be some official registration of the that training event. If there is no such expectation of a Certification of Completion, or if there is no intention of using the training as a pre-requisite to future activities, the training is not controlled. Be sure to be clear with whoever you are receiving the training from about their authority to deliver the expected outcome.
At this time, the SEI is the only source for CMMI-related model training other than Introduction to CMMI.

What sort of CMMI-related training is there?

A: The following are the basic CMMI courses. The SEI also adds specialized courses all the time. Follow this link for the SEI's list of courses:

Introduction to CMMI
Intermediate Concepts of CMMI
CMMI Instructor Training
SCAMPI Lead Appraiser Training
SCAMPI B and C Team Leader Training

How can we learn about the appraisal process?

A: For that we have some bad news.
There are only three ways to learn about the appraisal process, and one of them is not recommended, and another requires a lot of commitment:

Download the Appraisal Requirements Document and the Method Definition Document, and study them.
Go through all the training requirements of becoming a Lead Appraiser.
Hire someone who has done #2 to explain it you.