CMMI (Capability Maturity Model Integration): CMMI – Tutorial (about 60 minutes)

CMMI (Capability Maturity Model Integration) is a collection of proven practices that organisations use to find out how capable their ways of working really are and to improve them step by step, so that projects and services become more predictable and perform better. It is used by software and systems developers, IT service providers, government contractors, outsourcing firms and, increasingly, by organisations that care about data, security, safety and remote work. After this tutorial you will be able to explain how the model is built, what the maturity and capability levels mean, how an improvement programme and an official appraisal work, and how CMMI fits next to ISO standards, agile methods and IT service frameworks.

Free tutorial · about 60 minutes · 7 lessons · 4 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current version is CMMI V3.0, published in April 2023 by the CMMI Institute, which has been part of ISACA since 2016 (ISACA now presents the offering as "CMMI Performance Solutions"). V3.0 replaced the V2.x series (V2.0 appeared in March 2018); ISACA aligned its CMMI courses, exams and certification policies with V3.0 during 2024. As of the verification date no newer version (for example a V3.1 or V4.0) has been announced, and official appraisals are performed against V3.0. CMMI is a proprietary model, not an ISO or national standard: the full model text is licensed through ISACA's online model viewer, and only free summaries are public. This tutorial explains the model in its own words and does not reproduce model content. Verified 2026-10-29.

Who it is for: software and systems engineers, project and delivery managers, quality assurance and process people, service managers, security and compliance staff, and anyone who has been told "we are going for CMMI Level 3" and wants to understand what that really involves. No earlier exposure to process models is assumed.

Prerequisites: none. It helps if you have worked on at least one project that ran late or over budget, because CMMI was created to answer the question of why that keeps happening and what an organisation can do about it.

How to use this tutorial: read the seven lessons in order (roughly 45 minutes), study the four diagrams, then use the remaining time on the reflection questions before you take the 25-question knowledge check.

Learning objectives:

You will be able to explain why CMMI exists, who owns it and how it evolved from the original Software CMM to V3.0.
You will be able to describe the model architecture: categories, capability areas, practice areas, practice groups, practices, domains and views.
You will be able to distinguish maturity levels from capability levels and describe what changes in an organisation at each maturity level.
You will be able to plan a realistic, performance-driven CMMI improvement programme with the right roles and artefacts.
You will be able to compare the four appraisal types, explain who may lead them and what a rating does and does not mean.
You will be able to recognise common misuses of CMMI and relate the model to ISO 9001, ISO/IEC 33001, ITIL, Scrum and other frameworks.

Lesson 1 – Origins, purpose and scope

The problem CMMI set out to solve

In the 1980s the United States Department of Defense was buying more and more software, and a large share of it arrived late, cost far more than planned or did not work as intended. The department funded the Software Engineering Institute (SEI) at Carnegie Mellon University to find a way of judging which contractors were likely to deliver. Watts Humphrey and colleagues at the SEI observed that the organisations that delivered reliably were not simply staffed with better programmers; they had disciplined, repeatable ways of planning, tracking, controlling changes and checking quality. The organisations that struggled depended on individual heroes, and their results swung wildly from one project to the next.

That observation led to the idea of process maturity: an organisation can be placed on a path from chaotic, hero-driven work towards managed, standardised and finally data-driven, continuously improving work. Each stage creates the foundation for the next one. You cannot meaningfully analyse statistics about a process that is performed differently every time, and you cannot standardise across the company practices that individual projects do not yet perform.

From Software CMM to CMMI V3.0

The first result was the Capability Maturity Model for Software (often called the Software CMM or SW-CMM), developed at the SEI from the late 1980s through the 1990s. Its five-level ladder became famous worldwide. Other maturity models followed for systems engineering, acquisition and people management, and organisations that used several of them found the overlaps confusing and expensive. The answer was integration: a single framework that brought these models together, hence the name Capability Maturity Model Integration.

The CMMI 1.x series (version 1.1 in 2002, 1.2 in 2006 and 1.3 in 2010) was organised into three "constellations" for development, acquisition and services, built from process areas with specific and generic goals and practices. Appraisals used a method called SCAMPI. In 2013 the CMMI work moved from the SEI to a new organisation, the CMMI Institute, which ISACA acquired in 2016.

CMMI V2.0 (2018) was a deep redesign. The separate constellations became one model with selectable content, process areas became practice areas, generic practices were replaced by two practice areas about governance and infrastructure, the language was made simpler, and the model put much more emphasis on business performance rather than on paperwork. A new appraisal method replaced SCAMPI. V2.x updates added content for safety, security and virtual delivery. CMMI V3.0 (2023) built on V2.x: it added practice areas for data management, data quality and workforce empowerment, renamed the virtual-delivery content to cover virtual work in general, refreshed the agile and DevSecOps guidance and tidied up many practices.

Purpose and scope today

CMMI is best understood as a best-practice reference for building organisational capability. It tells you what effective organisations do, not exactly how to do it. It covers the full span of work that delivers products and services: understanding requirements, planning and estimating, monitoring work, managing risks, engineering and integrating solutions, verifying quality, running services, handling incidents, managing suppliers, training staff, protecting security and safety, managing data and improving processes over time. It applies to organisations of any size, using any lifecycle, including agile and DevOps teams, because it describes outcomes and practices rather than prescribing documents or ceremonies.

Organisations use CMMI for three main purposes. First, as an improvement roadmap: a gap analysis against the model shows which practices are weak and in what order to strengthen them. Second, as a benchmark: an official appraisal gives a rating that customers, especially in government contracting and outsourcing, recognise when choosing suppliers. Third, as a common language: managers, engineers and customers can discuss process capability with shared terms.

Lesson 2 – Key concepts and vocabulary

CMMI has its own vocabulary, and much confusion comes from mixing V1.3 terms with V2.0/V3.0 terms. The list below uses the current terms and notes older ones where they still circulate.

Process – a set of activities that turns inputs into outputs to achieve a purpose. In CMMI a process is not a document; it is what people actually do. A written description is only useful when it reflects real work.
Process improvement – deliberate, measured change to how work is done so that the organisation meets its business and performance objectives more reliably.
Practice – a short statement of something an effective organisation does, together with the value it brings. Practices are the smallest required building blocks of the model.
Practice area – a group of related practices that together achieve a value, for example planning, configuration management or incident resolution. Practice areas replaced the "process areas" of V1.3.
Practice group – a subset of the practices within a practice area, labelled with a level number. Lower-level groups contain basic practices; higher-level groups add rigour, organisational standards or quantitative management.
Capability area – a cluster of related practice areas that together address a broader business need, such as planning and managing work or ensuring quality.
Category – the top grouping of capability areas. There are four: Doing, Managing, Enabling and Improving.
Domain – a subject focus that selects relevant content, such as Development, Services, Suppliers, Security, Safety, People, Data or Virtual.
View – the selection of practice areas used for an appraisal or improvement effort. Predefined views (for example Development) are used for maturity-level ratings; custom views allow organisations to pick specific practice areas for capability-level ratings.
Maturity level – a staged rating from 1 to 5 that describes how mature the organisation is across a predefined set of practice areas.
Capability level – a rating from 0 to 3 that describes how well an organisation performs one individual practice area.
High maturity – the informal name for maturity levels 4 and 5, where statistical and other quantitative techniques are used to understand and improve performance.
Organisational process assets – the reusable building blocks an organisation keeps for its projects: standard processes, tailoring guidelines, templates, checklists, lessons learned and measurement data.
Tailoring – adapting the organisation's standard process to the needs of a specific project or service within agreed guidelines, for example lighter documentation for a small internal tool.
Appraisal – an examination by a trained team, led by a certified lead appraiser, of how an organisation performs against the model. Official appraisals can result in ratings; organisations are "appraised", not "certified".
Organisational unit – the part of the organisation that is appraised, such as one business unit or delivery centre. A rating always applies to a defined organisational unit, never automatically to the whole company.
Context-specific information – guidance that explains how practices look in a particular setting, such as agile development, DevSecOps, data or people management.

Two more ideas are worth fixing early. CMMI distinguishes required content from informative content. The intent and value of each practice area and the practice statements themselves must be met; explanations, example activities and example work products help you understand the practice but are not a checklist. And CMMI is performance-oriented: since V2.0 the model asks organisations to set performance objectives and show that their processes help meet them, not only to show that the processes exist.

Lesson 3 – Structure of the model

From categories down to practices

The model is arranged as a hierarchy. At the top are four categories. Doing covers the activities that produce and deliver the product or service, such as requirements, engineering, verification and service delivery. Managing covers planning and steering the work: estimating, planning, monitoring, risk, continuity and workforce matters. Enabling covers supporting activities that make other work possible, such as configuration management, decision analysis and root-cause analysis, together with security, safety and virtual work. Improving covers sustaining and improving processes and performance: governance, implementation infrastructure, process management, process assets and performance measurement.

Each category contains capability areas, each capability area contains practice areas, and each practice area contains practices arranged in practice groups by level. V3.0 contains around thirty practice areas. A core set applies to almost every organisation; others belong to specific domains, such as Technical Solution and Product Integration for development, Service Delivery Management and Incident Resolution and Prevention for services, Supplier Agreement Management for suppliers, Data Management and Data Quality for data, Workforce Empowerment for people, and dedicated practice areas for security, safety and virtual work.

Figure 1 – CMMI V3.0 is a hierarchy from four categories through capability areas and practice areas down to practices grouped by level, with domains and views selecting the relevant content.

The core practice areas in plain language

You do not need to memorise every practice area, but recognising the core ones makes the model far less abstract:

Requirements Development and Management – eliciting, agreeing and managing what stakeholders need.
Estimating, Planning, and Monitor and Control – working out size, effort and cost, building realistic plans and steering the work against them.
Risk and Opportunity Management – identifying, analysing and handling risks and opportunities before they become surprises.
Configuration Management – controlling versions and changes of work products so that everyone uses the right baseline.
Peer Reviews, Verification and Validation, and Process Quality Assurance – checking work products, checking the product fits its intended use and objectively checking that processes are followed.
Decision Analysis and Resolution and Causal Analysis and Resolution – making important decisions with defined criteria and tackling the causes of problems and successes.
Organisational Training, Process Management and Process Asset Development – building people's skills, steering process improvement and maintaining the organisation's standard processes and assets.
Managing Performance and Measurement – setting performance objectives, collecting and analysing data, and using the results to make decisions.
Governance and Implementation Infrastructure – making sure senior management sponsors and oversees the processes, and that people, tools, funding and training exist so that processes are followed by habit rather than by heroics.

The last pair deserves attention. In V1.3, "generic practices" were repeated inside every process area. Since V2.0 their purpose lives in these two practice areas, which apply to every other practice area in scope. In appraisals they often decide whether a process is merely performed or is genuinely institutionalised, which is CMMI's word for being part of how the organisation normally works.

Inside a practice area

Each practice area states its intent (what it is for) and its value (why the business should care), then lists its practices in level order. Practice group level 1 contains basic practices that address the intent only partly. Level 2 adds practices that make the approach simple but complete. Level 3 adds the use and improvement of organisational standards. Some practice areas, notably Managing Performance and Measurement and Causal Analysis and Resolution, also contain level 4 and level 5 practice groups for quantitative and continuous improvement. Each practice comes with explanatory material, example activities and example work products, plus context-specific guidance such as how the practice looks in an agile team.

Domains and views

Because no organisation needs everything, content is selected by domain. A software product company might work in the Development domain; an IT operations provider in Services; a company that relies on subcontractors adds Suppliers; a medical device maker may add Safety; a bank may add Security and Data. The chosen domains together form a view, which defines which practice areas are in scope for improvement or appraisal. A predefined view supports a maturity-level rating; a custom view lets an organisation select individual practice areas, which is useful when it wants capability-level ratings for a few areas without a full maturity-level appraisal.

Lesson 4 – Maturity levels, capability levels and how CMMI works in practice

Two kinds of level

CMMI offers two complementary ways of describing progress. A capability level describes one practice area. Level 0 (Incomplete) means the approach is incomplete: it may or may not meet the intent of any practice, and performance is inconsistent. Level 1 (Initial) means the basic practices are performed, often to solve immediate problems. Level 2 (Managed) means a simple but complete approach that covers the whole intent and tracks progress against objectives. Level 3 (Defined) means the approach uses tailored organisational standards and contributes back to the organisation's assets. Capability levels suit organisations that want to fix a few specific weaknesses first.

A maturity level describes the organisation across a predefined set of practice areas. It is the famous five-step staircase:

Maturity level 1, Initial – work gets done, but it is unpredictable and reactive, often late and over budget. Success depends on individuals.
Maturity level 2, Managed – projects are planned, performed, measured and controlled. Commitments are realistic and changes are controlled, but each project may do things in its own way.
Maturity level 3, Defined – the organisation has standard processes, tailored for each project, and projects learn from and contribute to shared assets. The organisation is proactive rather than reactive.
Maturity level 4, Quantitatively Managed – the organisation sets quantitative objectives for quality and process performance and uses statistical and other quantitative techniques to predict and control results.
Maturity level 5, Optimizing – the organisation continuously improves performance using quantitative understanding, innovation and the analysis of causes, and adapts quickly to change.

Official material also mentions a level 0 (Incomplete) for work that is ad hoc and may not be completed, but ratings in practice start at level 1. To achieve a maturity level, the organisational unit must satisfy all practices in the practice groups up to that level for every practice area in the selected view. For example, maturity level 3 needs the level 1, 2 and 3 practices of all practice areas in the view, and maturity level 4 also needs the level 4 practices that exist in the view. Levels cannot be skipped, because each one depends on the foundation laid by the levels below.

Figure 2 – The five maturity levels form a staircase: each level builds on the practices of the levels beneath it, so levels cannot be skipped.

Running an improvement programme

CMMI does not prescribe an implementation method, but successful programmes share a recognisable pattern:

Link to business goals. Start from what the business needs: fewer late deliveries, lower defect leakage, faster incident recovery, credibility in a tender. These goals become performance objectives.
Secure sponsorship. A senior sponsor provides funding and authority, and a steering group decides priorities. Without this the Governance practice area will not be satisfied anyway.
Choose scope. Decide on the organisational unit, the domains (and therefore the view) and the target level or capability levels.
Perform a gap analysis. Compare current practice with the model, often helped by a lead appraiser or consultant, and possibly using an informal evaluation appraisal.
Plan improvements. Prioritise the gaps that most affect the business objectives, and form small working groups of practitioners to design or improve processes.
Pilot, then deploy. Test new processes on one or two projects, adjust, then roll them out with training, tools and coaching.
Measure and institutionalise. Track whether performance objectives improve, keep process assets current and make the processes habitual through governance and infrastructure.
Appraise and sustain. When practices are routine, plan a benchmark appraisal, then keep improving and use sustainment appraisals to keep the rating valid.

Figure 3 – A performance-driven CMMI improvement cycle: objectives drive the gap analysis, improvements are piloted and deployed, results are measured, and appraisals confirm progress before the cycle repeats.

Roles and artefacts

Typical roles include the executive sponsor, a process improvement lead or engineering process group that coordinates the work, process owners for important areas such as planning or configuration management, quality assurance staff who objectively check adherence, project and service managers who apply the processes, and, at appraisal time, a CMMI Certified Lead Appraiser and an appraisal team. Common artefacts include the organisation's set of standard processes, tailoring guidelines, templates and checklists, a process asset library, a measurement repository, training records, quality assurance reports and improvement proposals. None of these artefacts is valuable on its own; they matter when they are actually used and reflect real work.

CMMI with agile and DevOps

A common myth is that CMMI demands heavy documentation and waterfall lifecycles. The model is lifecycle-neutral, and V3.0 contains agile and DevSecOps context guidance. A Scrum team already has much of what the model looks for: a backlog that serves as the managed set of requirements, sprint planning and estimation, daily coordination and burn-down charts as monitoring, reviews and a definition of done as verification, and retrospectives as a source of improvement. CMMI then asks additional questions: are risks identified and tracked beyond the next sprint, are supplier agreements managed, is configuration management reliable across teams, is quality assurance objective, and does the organisation learn from teams and spread good practices? Used this way, CMMI strengthens agile delivery rather than replacing it.

Lesson 5 – Appraisal, rating and certification

Appraisal, not certification of the organisation

Organisations often say they are "CMMI certified", but strictly they are appraised and receive a rating. People, on the other hand, are certified: ISACA certifies individuals such as CMMI Associates, CMMI Practitioners, CMMI Certified Lead Appraisers and CMMI Instructors through courses and exams. Appraisals follow ISACA's official CMMI appraisal method, which since V2.0 replaced the older SCAMPI method and is described in a method definition document.

The four appraisal types

ISACA describes four appraisal types, which differ in rigour, effort and outcome:

Benchmark appraisal – the most rigorous type, covering the full organisational unit and model scope. It is led by a CMMI Certified Lead Appraiser with a team of at least four members including the leader, produces ratings and, according to ISACA, remains valid for three years. This is the appraisal that establishes an official maturity level or capability levels.
Sustainment appraisal – a lighter "check-up" that reviews a subset of the previous benchmark scope with a smaller team, to confirm the organisation is maintaining its level. It must be completed and accepted before the previous rating expires to extend validity, and ISACA allows no more than three sustainment appraisals in a row before a new benchmark is required.
Action plan reappraisal – a second chance when an organisation narrowly misses its target in a benchmark or sustainment appraisal. The organisation fixes the identified weaknesses and a limited reappraisal must be completed within four months of the end of the original appraisal; validity and team follow the original appraisal.
Evaluation appraisal – a flexible, informal appraisal used to prepare for a benchmark or to measure progress. It identifies strengths and weaknesses but does not produce ratings.

Figure 4 – How the four appraisal types fit together: evaluations prepare, a benchmark sets the rating, an action plan reappraisal can rescue a near miss, and sustainment appraisals keep the rating valid until a new benchmark is due.

How a benchmark appraisal works

A benchmark appraisal is planned well in advance. The lead appraiser and the sponsor agree the organisational unit, the view and the target level. The method uses a sample of projects or work groups drawn so that the organisation cannot simply show its best project; the appraisal team then examines objective evidence from the sampled work. Evidence takes two forms: artefacts, such as plans, review records, configuration logs and measurement reports, and affirmations, which are interviews or demonstrations by the people who actually do the work. The team characterises how well each practice is implemented, identifies strengths and weaknesses, and finally rates the practice areas and, if applicable, the maturity level. ISACA reviews and accepts the results, and an organisation may choose to publish its rating in ISACA's Published Appraisal Results System (PARS), which buyers can search to verify claims.

Several features protect the credibility of ratings. The lead appraiser must be certified and independent enough to judge objectively; appraisal team members must hold the required CMMI training and certification and have relevant experience; the method also looks at performance data that show how the processes support the organisation's objectives. Appraisal team members are often a mix of external and trained internal staff, but internal members should not judge work they are directly responsible for.

What a rating means, and what it does not

A rating says that, at the time of the appraisal, the appraised organisational unit implemented the practices of the selected view up to the stated level. It does not guarantee that every project in the company performs equally well, that the organisation is still performing at that level years later, or that a product is defect-free. A buyer who sees "CMMI Level 3" in a proposal should therefore ask: which organisational unit, which domains or view, which model version, which appraisal type, and is the rating still valid and listed in PARS?

Lesson 6 – Worked example: a services company climbs to maturity level 3

Consider a fictional company, Harbourline Software, with 280 staff. It builds custom business applications for clients and also runs application support for several of them. It has grown quickly; some projects are excellent, others miss deadlines badly, and two large customers have asked for evidence of a CMMI rating in their next tenders.

Step 1 – Start from business objectives

The managing director sponsors the programme, but she insists that the goal is better delivery, not a certificate on the wall. With the leadership team she sets three performance objectives for the next 18 months: reduce schedule overruns on fixed-price projects from about 35 percent to below 15 percent, halve the number of defects found by clients after release, and resolve priority-1 support incidents within the contractual time on at least 95 percent of occasions. These objectives later become central evidence for the Managing Performance and Measurement practice area.

Step 2 – Choose scope

Harbourline defines its organisational unit as the delivery division in two offices, about 220 people. Because it both builds and supports applications, it selects the Development and Services domains, and because it subcontracts some testing to a partner, it adds Suppliers. The long-term target is maturity level 3; the first milestone is a stable maturity level 2 way of working.

Step 3 – Gap analysis

An external lead appraiser runs an evaluation appraisal over two weeks, sampling four projects and two support teams. The findings are typical for a growing company. Requirements are captured in a ticket tool, but changes are agreed informally by email and often not reflected in estimates. Estimation relies on the gut feeling of senior developers. Configuration management is strong for source code but weak for documents and environment settings. Quality assurance consists of testing; nobody objectively checks whether agreed processes are followed. Each project manager plans differently, so lessons are not shared. There is no structured risk management. The subcontracted test partner works without a clear agreement on deliverables or acceptance.

Step 4 – Plan and organise

The sponsor appoints a process improvement lead and forms a small engineering process group with one experienced person from development, support and quality. Working groups of practitioners, not consultants, design the improvements. The plan is ordered by business impact: first estimating, planning and requirements change control, because they drive schedule overruns; second configuration management and peer reviews, because they drive escaped defects; third incident handling for support; then supplier agreements, risk management and objective quality assurance.

Step 5 – Pilot and deploy

The estimating working group introduces a simple sizing technique and requires every estimate to record its assumptions. Two pilot projects use it, and the group compares estimates with actuals after each release. A lightweight change request flow in the existing ticket tool makes every scope change visible together with its impact on effort and dates. Peer reviews of code and key designs become part of the definition of done for agile teams. Support teams adopt clear incident categories, escalation rules and a weekly review of breached incidents. A written agreement with the test partner now defines deliverables, acceptance criteria and a monthly performance review. After three months the pilots show fewer surprises, so the practices are deployed to all projects with short training sessions and templates in a shared process asset library.

Step 6 – Institutionalise and move towards level 3

Harbourline now builds the organisational layer. It documents a standard delivery process with tailoring rules: small maintenance requests follow a light path, large fixed-price projects a fuller one. A process quality assurance role, staffed by people independent of the projects, checks a sample of projects each month and reports non-compliances to the steering group, which resolves them. A measurement repository collects estimation accuracy, defect leakage and incident resolution data from all projects, so new estimates can draw on history. Decision analysis is used for major choices such as selecting a new deployment platform. Training needs are identified for each role. The steering group reviews the progress of the programme quarterly, which demonstrates governance.

Step 7 – Appraise and sustain

After about 20 months, a second evaluation appraisal finds only minor weaknesses, which are fixed. The benchmark appraisal follows: the method selects a sample of projects and support teams, and a lead appraiser with a five-person team, including two trained Harbourline staff from outside the sampled work, reviews artefacts and interviews practitioners. The division is rated at maturity level 3 for the Development, Services and Suppliers domains, and Harbourline publishes the result in PARS. Equally important, the business results have moved: schedule overruns have dropped to around 12 percent and escaped defects by roughly 40 percent, while incident targets are met on 96 percent of occasions. The company now plans sustainment appraisals before the rating expires and considers whether high maturity is worth pursuing for its largest client programme.

Notice what made this example work: business goals came first, practitioners designed the processes, changes were piloted and measured, and the rating came at the end as a confirmation rather than as the goal.

Lesson 7 – Relationship to other standards and frameworks

CMMI rarely stands alone. Many organisations already hold ISO certifications or use agile and IT service frameworks, and understanding the overlaps helps avoid duplicated effort.

Framework	What it is	How it relates to CMMI
ISO 9001	International standard for a quality management system, assessed by accredited certification bodies.	ISO 9001 states requirements for a management system and leads to certification; CMMI describes engineering and service practices in more depth and leads to an appraisal rating. Many organisations use both, sharing the same process assets and audits.
ISO/IEC 33001 family (successor of ISO/IEC 15504, "SPICE")	International standards for process assessment, with capability levels per process.	Similar ideas of process capability and assessment, but published by ISO/IEC and used with process reference models such as ISO/IEC/IEEE 12207 and Automotive SPICE. CMMI is a proprietary model with its own appraisal method.
Automotive SPICE	Process assessment model used by vehicle manufacturers to assess suppliers.	Covers similar development practices, but the automotive industry generally requires Automotive SPICE assessments rather than CMMI ratings.
ITIL and ISO/IEC 20000-1	Guidance (ITIL) and a certifiable standard (ISO/IEC 20000-1) for IT service management.	Overlap with the CMMI Services domain on incidents, continuity and service delivery. ITIL gives detailed practice guidance; CMMI focuses on capability and maturity across the organisation.
Scrum and other agile methods	Lightweight frameworks for iterative delivery.	Complementary: agile methods define how teams work day to day; CMMI checks that practices such as risk, supplier and configuration management are covered and that the organisation improves systematically.
CMMC	Cybersecurity Maturity Model Certification of the US Department of Defense.	Despite the similar name, CMMC is a separate cybersecurity programme based on NIST security requirements, not a CMMI domain. CMMI security practice areas can help but do not satisfy CMMC.
TMMi	Test Maturity Model integration, a maturity model for testing.	Uses a similar five-level staged structure and was designed to complement CMMI by going deeper into test process improvement.

A practical approach is to keep one integrated set of processes and map them to each framework, rather than building separate "CMMI processes" and "ISO processes". For example, a single internal audit programme can serve ISO 9001 and the objective checks expected by process quality assurance, while incident management processes can satisfy both ITIL-based service management and the CMMI Services domain.

Common pitfalls and best practices

Common pitfalls:

Chasing the level instead of performance. When the rating is the goal, organisations create documents for the appraisal that nobody uses afterwards. Results do not improve and the practices decay soon after.
Treating example work products as a checklist. The examples in the model are informative. Producing every listed document adds cost without adding value; what matters is that the intent and value of each practice are met.
Imposing processes from outside. Consultants or a central group writing processes without practitioners produces procedures that do not fit real work, leading to resistance and workarounds.
Showcasing a "golden project". Preparing one model project for the appraisal fails because the method samples work, and it hides the real state of the organisation.
Misreading the rating. Assuming that a rating covers the whole company, every domain or every year leads to wrong decisions by both suppliers and buyers.
Ignoring governance and infrastructure. Processes that rely on the enthusiasm of a few people disappear when they leave, because no budget, tools, training or management oversight sustain them.
Collecting measures nobody uses. Measurement programmes that gather dozens of metrics without decisions attached waste effort and erode trust.

Best practices:

Start from business objectives and select the domains, practice areas and target level that serve them.
Involve practitioners in designing processes so they reflect how good work actually gets done.
Pilot before deploying, measure the effect and adjust before rolling out widely.
Keep processes lean and tailorable, integrated into existing tools such as ticket systems, repositories and pipelines.
Use evaluation appraisals to check readiness and learn, rather than gambling on a first benchmark.
Make quality assurance objective and focus it on helping projects improve, not on punishing them.
Plan for sustainment from the start, so the processes and the rating outlive the appraisal.

Summary and key takeaways

CMMI is a proprietary best-practice model owned by ISACA through the CMMI Institute; the current version is V3.0, released in April 2023.
It grew out of SEI research showing that predictable delivery depends on disciplined, repeatable processes rather than on individual heroes.
The model is a hierarchy of four categories, capability areas, practice areas and practices arranged in levelled practice groups; domains and views select what is in scope.
Capability levels (0–3) rate individual practice areas; maturity levels (1–5) rate an organisational unit across a predefined set of practice areas and cannot be skipped.
Governance and Implementation Infrastructure turn performed practices into habits that survive staff changes.
Organisations are appraised, not certified; benchmark, sustainment, action plan reappraisal and evaluation appraisals serve different purposes, and only some produce ratings.
A rating applies to a defined organisational unit, view and time period, and can be verified in ISACA's published results.
CMMI works best when driven by business performance objectives and integrated with agile methods, ISO management systems and service frameworks.

Reflection questions

Think of a project you worked on that went badly. Which practice areas described in this tutorial were weak, and what maturity level best describes how that work was run?
Your organisation wants a CMMI rating mainly to win a tender. How would you persuade the sponsor to set performance objectives as well, and which objectives would you propose?
For your own team or company, which domains would you select and why? Would a maturity-level rating or capability levels for a few practice areas serve you better?
How would you show an appraisal team that your agile teams meet the intent of planning, monitoring and quality assurance practices without creating extra documents?
A supplier claims "CMMI Level 5". Which questions would you ask, and what would you check, before giving that claim weight in a selection decision?