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

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

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

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

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

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

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

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

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

• Staged, and
• Continuous

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