Welcome to our brutally honest, totally hip CMMIFAQ.

We're probably going to make as many enemies as friends with this FAQ, but hey, we expect it to be worth it.  :-)

We also did a bit of research and found it pretty hard (if not impossible) to find this kind of information anywhere else on the web.  So anyone who has a problem with our posting this information is probably the kind of person who wants you to pay to get it out of them before you have enough information to even make a good decision.  But we digress... We do that a lot.

This site was designed to provide help with CMMI for people who are researching, trying to get to "the truth" about CMMI, or just looking for answers to basic, frequently asked questions about CMMI and the process of having an appraisal for getting a level rating (or CMMI certification as some people (inaccurately) prefer to say).

The information on this site has also been demonstrated to provide answers and new insights to people who are already (or thought they were) very familiar with CMMI and the appraisal.  Feedback has indicated that there is more than a fair amount of incomplete and actual incorrect information being put forth by supposed experts in CMMI.

Your feedback is therefore very important to us.  If you have any suggestions for other questions, or especially corrections, please don't hesitate to send them to us.

This is a work-in-progress, not all questions have been answered yet -- simply a matter of time to write them, not that we don't know the answers -- but we didn't want to keep you waiting, so we're starting with that we have.

For your own self-study, and for additional information, the source material for many of the answers on CMMI come from the SEI.  They're not hiding anything; it's all there.

We've broken up the FAQs into the following sections (there will be much cross-over, as can be expected):

 

Model FAQs

 

Appraisals/Ratings FAQs

 

CMMI, Agile, LifeCycles and other Process Concepts FAQs

 

SEI FAQs

 

Training FAQs

 

Specific Model Content FAQs

 

 

Model FAQs

WHAT is CMMI?

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

It is NOT an engineering development standard or a development life cycle.  Please take a moment to re-read and reflect on that before continuing.

There are currently three "flavors" of CMMI called constellations.  The most famous one is the CMMI for Development -- i.e., "DEV".  It has been around (in one version or another) for roughly 10 years and has been the subject of much energy for over 20 years when including its CMM ancestors.

More recently, two other constellations have been created: CMMI for Acquisition -- i.e., "ACQ", and CMMI for Services -- i.e., "SVC".  All constellations share many things, but fundamentally, they are all nothing more than frameworks for assembling process improvement systems.  Each constellation has content that targets improvments in particular areas, tuned to organizations whose primary work effort either:

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

NONE of the constellations actually contain processes themselves.  None of them alone can be used to actually develop products, acquire goods or fulfill services.  The assumption with all CMMIs is that the organization has its own standards, processes and procedures by which they actually get things done.  The content of CMMIs are to improve upon the performance of those standards, processes and procedures -- not to define them.

Having said that, it should be noted that there will (hopefully) be overlaps between what any given organization already does and content of CMMIs.  This overlap should not be misinterpreted as a sign that CMMI content *is*, in fact, process content.  It can't be over-emphasized, CMMIs, while chock-full-o examples and explanations, do not contain "how to" anything other than building improvement systems.  The overlap is easy to explain: activities that help improve a process can also be activities to effectively perform a process, and, not every organization performs even the basic activities necessary to perform the process area well.  So, to one organization, what seems trivial and commonplace, to another is salvation from despair.

Another way to look at CMMIs are that they focus on the business processes of developing engineered solutions (DEV), acquiring goods and services (ACQ) and delivering services (SVC).  To date, CMMI has most widely applied in software and systems engineering organizations.  Now, with the expansion of the constellations, where it is applied is a significantly distinct matter from being anything even remotely akin to a standard or certification mechanism for the engineering, methods, technologies, or accreditation necessary to build stuff, buy stuff or do stuff, .  If an organization chose to do so, CMMI could be applied in the construction or even media production industries.  (Exactly, how would be an *entirely* different discussion!)

Before we get too off-track... CMMI is meant to help organizations improve on their capability to consistently and predictably deliver the products, services, and sourced goods their customers want, when they want them and at a price they're willing to pay.  From a purely inwardly-facing perspective, CMMI helps companies get from estimates to actuals in the black, keep customers happy, and purchase the right things the best way.

Without some insight into and control over their internal business processes, how else can a company know how well they're doing before it's too late to do anything about it?  And if/when they wait until the end of a project to see how close/far they were to their promises/expectations, without some idea of what their processes are and how they work, how else could a company ever make whatever changes or improvements they'd want/need to make in order to do better next time?

CMMI provides the models from which to pursue these sorts of insights and activities for improvement.  It's a place to start, not a final destination.  CMMI can't tell an organization what is or isn't important to them.  CMMI, however, can provide a path for an organization to achieve its performance goals.

Furthermore, CMMI is just a model, it's not reality.  Like any other model, CMMI reflects one version of reality, and like most models, it's rather idealistic and unrealistic -- at least in some ways.  When understood as *just* a model, people implementing CMMI have a much higher chance of implementing something of lasting value.  As a model, what CMMI lacks is context.  Specifically, the context of the organization in which it will be implemented for process improvement.  Together with the organization's context, CMMI can be applied to create a process improvement solution appropriate to the context of each unique organization.

Putting it all together: CMMI is a model for process improvement from which (astute) organizations will abstract and create process improvement solutions that fit their unique environment.

At the risk of seeming self-serving, the following address the question of what CMMI is:

What is CMMI & Why Should You Care? & Keys to Enabling CMMI.

Back to Model FAQs

 

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.

Back to Model FAQs

 

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]
    The purpose of Causal Analysis and Resolution (CAR) is to identify causes of defects and other problems and take action to prevent them from occurring in the future.
    Configuration Management, [ML 2]
    The purpose of Configuration Management (CM) is to establish and maintain the integrity of work products using configuration identification, configuration control, configuration status accounting, and configuration audits.
    Decision Analysis & Resolution, [ML 3]
    The purpose of Decision Analysis and Resolution (DAR) is to analyze possible decisions using a formal evaluation process that evaluates identified alternatives against established criteria.
    Integrated Project Management (+ IPPD -- DEV only), [ML 3]
    The purpose of Integrated Project Management (IPM) is to establish and manage the project and the involvement of the relevant stakeholders according to an integrated and defined process that is tailored from the organization’s set of standard processes.
    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]
    The purpose of Measurement and Analysis (MA) is to develop and sustain a measurement capability that is used to support management information needs.
    Organizational Innovation and Deployment, [ML 5]
    The purpose of Organizational Innovation and Deployment (OID) is to select and deploy incremental and innovative improvements that measurably improve the organization’s processes and technologies.  The improvements support the organization’s quality and process performance objectives as derived from the organization’s business objectives.
    Organizational Process Definition (+ IPPD -- DEV only), [ML 3]
    The purpose of Organizational Process Definition (OPD) is to establish and maintain a usable set of organizational process assets and work environment standards.
    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]
    The purpose of Organizational Process Focus (OPF) is to plan, implement, and deploy organizational process improvements based on a thorough understanding of the current strengths and weaknesses of the organization’s processes and process assets.
    Organizational Process Performance, [ML 4]
    The purpose of Organizational Process Performance (OPP) is to establish and maintain a quantitative understanding of the performance of the organization’s set of standard processes in support of quality and process-performance objectives, and to provide the process performance data, baselines, and models to quantitatively manage the organization's projects.
    Organizational Training, [ML 3]
    The purpose of Organizational Training (OT) is to develop the skills and knowledge of people so they can perform their roles effectively and efficiently.
    Project Monitoring and Control, [ML 2]
    The purpose of Project Monitoring and Control (PMC) is to provide an understanding of the project’s progress so that appropriate corrective actions can be taken when the project’s performance deviates significantly from the plan.
    Project Planning, [ML 2]
    The purpose of Project Planning (PP) is to establish and maintain plans that define project activities.
    Process and Product Quality Assurance, [ML 2]
    The purpose of Process and Product Quality Assurance (PPQA) is to provide staff and management with objective insight into processes and associated work products.
    Quantitative Project Management, [ML 4]
    The purpose of Quantitative Project Management (QPM) is to quantitatively manage the project’s defined process to achieve the project’s established quality and process-performance objectives.
    Requirements Management, [ML 2]
    The purpose of Requirements Management (REQM) is to manage the requirements of the project’s products and product components and to identify inconsistencies between those requirements and the project’s plans and work products.
    Risk Management, [ML 3]
    The purpose of Risk Management (RSKM) is to identify potential problems before they occur so that risk-handling activities can be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.

Shared by CMMI for Development and CMMI for Services

    Supplier Agreement Management, [ML 2]
    The purpose of Supplier Agreement Management (SAM) is to manage the acquisition of products from suppliers.

Process Areas Unique to CMMI for Development

    Product Integration, [ML 3]
    The purpose of Product Integration (PI) is to assemble the product from the product components, ensure that the product, as integrated, functions properly, and deliver the product.
    Requirements Development, [ML 3]
    The purpose of Requirements Development (RD) is to produce and analyze customer, product, and product component requirements.
    Technical Solution, [ML 3]
    The purpose of Technical Solution (TS) is to design, develop, and implement solutions to requirements. Solutions, designs, and implementations encompass products, product components, and product-related lifecycle processes either singly or in combination as appropriate.
    Validation, [ML 3]
    The purpose of Validation (VAL) is to demonstrate that a product or product component fulfills its intended use when placed in its intended environment.
    Verification, [ML 3]
    The purpose of Verification (VER) is to ensure that selected work products meet their specified requirements.

Process Areas Unique to CMMI for Acquisition

    Agreement Management, [ML 2]
    The purpose of Agreement Management (AM) is to ensure that the supplier and the acquirer perform according to the terms of the supplier agreement.
    Acquisition Requirements Development, [ML 2]
    The purpose of Acquisition Requirements Development (ARD) is to develop and analyze customer and contractual requirements.
    Acquisition Technical Management, [ML 3]
    The purpose of Acquisition Technical Management (ATM) is to evaluate the supplier’s technical solution and to manage selected interfaces of that solution.
    Acquisition Validation, [ML 3]
    The purpose of Acquisition Validation (AVAL) is to demonstrate that an acquired product or service fulfills its intended use when placed in its intended environment.
    Acquisition Verification, [ML 3]
    The purpose of Acquisition Verification (AVER) is to ensure that selected work products meet their specified requirements.
    Solicitation and Supplier Agreement Development, [ML 2]
    The purpose of Solicitation and Supplier Agreement Development (SSAD) is to prepare a solicitation package, select one or more suppliers to deliver the product or service, and establish and maintain the supplier agreement.

Process Areas Unique to CMMI for Services

    Capacity and Availability Management, [ML 3]
    The purpose of Capacity and Availability Management (CAM) is to ensure effective service system performance and ensure that resources are provided and used effectively to support service requirements.
    Incident Resolution and Prevention, [ML 3]
    The purpose of Incident Resolution and Prevention (IRP) is to ensure timely and effective resolution of service incidents and prevention of service incidents as appropriate.
    Service Continuity, [ML 3]
    The purpose of Service Continuity (SCON) is to establish and maintain plans to ensure continuity of services during and following any significant disruption of normal operations.
    Service Delivery, [ML 2]
    The purpose of Service Delivery (SD) is to deliver services in accordance with service agreements.
    Service System Development*, [ML 3]
    The purpose of Service System Development (SSD) is to analyze, design, develop, integrate, verify, and validate service systems, including service system components, to satisfy existing or anticipated service agreements.
    *SSD is an "Addition"  As such, it is at the organization's discretion whether to implement SSD, and, whether to include SSD in a SCAMPI appraisal.
    Service System Transition, [ML 3]
    The purpose of Service System Transition (SST) is to deploy new or significantly changed service system components while managing their effect on ongoing service delivery.
    Strategic Service Management, [ML 3]
    The purpose of Strategic Service Management (STSM) is to establish and maintain standard services in concert with strategic needs and plans.

Back to Model FAQs

 

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?

Back to Model FAQs

 

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.

Back to Model FAQs

 

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.

Back to Model FAQs

 

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

Back to Model FAQs

 

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]: Perform the specific practices of the process to develop work products and provide services to achieve the specific goals of the process area.
    Generic Goal 2 [GG2]: The process is institutionalized as a managed process.

    Generic Practice 2.1 [GP 2.1]: Establish and maintain an organizational policy for planning and performing the process.

    Generic Practice 2.2 [GP 2.2]: Establish and maintain the plan for performing the process.

    Generic Practice 2.3 [GP 2.3]: Provide adequate resources for performing the process, developing the work products, and providing the services of the process.

    Generic Practice 2.4 [GP 2.4]: Assign responsibility and authority for performing the process, developing the work products, and providing the services of the process.

    Generic Practice 2.5 [GP 2.5]: Train the people performing or supporting the process as needed.

    Generic Practice 2.6 [GP 2.6]: Place designated work products of the process under appropriate levels of configuration management.

    Generic Practice 2.7 [GP 2.7]: Identify and involve the relevant stakeholders as planned.

    Generic Practice 2.8 [GP 2.8]: Monitor and control the process against the plan for performing the process and take appropriate corrective action.

    Generic Practice 2.9 [GP 2.9]: Objectively evaluate adherence of the process against its process description, standards, and procedures, and address noncompliance.

    Generic Practice 2.10 [GP 2.10]: Review the activities, status, and results of the process with higher level management and resolve issues.
    Generic Goal 3 [GG3]: The process is institutionalized as a defined process.

    Generic Practice 3.1 [GP 3.1]: Establish and maintain the description of a defined process.

    Generic Practice 3.2 [GP 3.2]: Collect work products, measures, measurement results, and improvement information derived from planning and performing the process to support the future use and improvement of the organization’s processes and process assets.
    Generic Goal 4 [GG4]: The process is institutionalized as a quantitatively managed process.

    Generic Practice 4.1 [GP 4.1]: Establish and maintain quantitative objectives for the process, which address quality and process performance, based on customer needs and business objectives.

    Generic Practice 4.2 [GP 4.2]: Stabilize the performance of one or more subprocesses to determine the ability of the process to achieve the established quantitative quality and processperformance objectives.
    Generic Goal 5 [GG5]: The process is institutionalized as an optimizing process.

    Generic Practice 5.1 [GP 5.1]: Ensure continuous improvement of the process in fulfilling the relevant business objectives of the organization.

    Generic Practice 5.2 [GP 5.2]: Identify and correct the root causes of defects and other problems in the process.

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.

Back to Model FAQs

 

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

Back to Model FAQs

 

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:

  1. Lack of understanding of the model, and
  2. 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

Back to Model FAQs

 

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

Back to Model FAQs

 

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.

Back to Model FAQs

 

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.

Back to Model FAQs

 

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.

Back to Model FAQs

 

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.

Back to Model FAQs

 

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.

Back to Model FAQs

 

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.

Back to Model FAQs

 

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.

Back to Model FAQs

 

 

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 to 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?

Back to Appraisals/Ratings FAQs

 

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?

Back to Appraisals/Ratings FAQs

 

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
    The Lead Appraiser will need time to meet with you to plan the appraisal, perform some preliminary evidence review (called "Readiness Review") and then to perform the appraisal.  The range of what Lead Appraisers charge is pretty wide.  Most charge about $2000/day +/- $500.
    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
    Every Appraisal for a rating is done by a team.  The minimum number of people is 4 and that can include the Lead Appraiser.  Every person on the team must meet certain individual pre-requisites and contribute to certain team-wide qualifications.  (More on that in answer.) It is best if the team's constituents include people from your company as well as outsiders.  At the appraisal, if you don't have (and can't create) qualified people in your company to be on the team, then you will need to bring in outside team members.  (Most Lead Appraisers keep these in their back pockets -- kinda.) Outside team members are essentially consultants and charge as such.  You're doing well if you can get outside team members for $1000/day.  This would be very high-value.  And, if you're only charged for a day where 1 day = the date on the calendar, and not 1 day = 8 hours, you're doing VERY well.
    Process Improvement Consulting
    If your organization needs to get up to speed on CMMI, you'll probably do one of two things: (1) Look to hire an employee with the expected expertise, or (2) Look to hire a consultant with the expertise.  Which you choose to do depends on your organization's needs.  The pros and cons of either approach are a basic matter of business and strategy.  Either way, there's a cost.  As for consultants, they're a lot like Lead Appraisers.  And yes, many Lead Appraisers are also consultants.  So, what and how they charge is largely up to them.
    Fees
    There are no SEI-mandated fees for improving your processes, using their models, or getting an appraisal.  The only fees charged by the SEI are for SEI-licensed courses, and for using their consultants or Lead Appraisers.  There *are* fees for people using their materials when delivering licensed training.  First of all, only authorized people can use the material and when such people do so, and the people in class want it to be "official", there's a licensing fee that goes to the SEI.
    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.

Back to Appraisals/Ratings FAQs

 

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.

Back to Appraisals/Ratings FAQs

 

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, instantiat