CMMI Levels 1–5, One by One: What Each Level Reviews and What Evidence It Wants

The five levels at a glance

How to read this table: look at the fourth column first, then the second. The second column describes what the capability looks like, which invites people to think "that is roughly us"; the fourth column describes what someone else will come and ask for, and that is the gate you have to stand at. No numeric thresholds are given here — organisation size, assessment scope and the assessing party all change the picture, and the CMMI Institute model documents currently in force and the Lead Appraiser's requirements govern in every case.

1. Level 1 Initial: it can be delivered, but never the same way twice

What is reviewed

Level 1 does not describe "no projects being run"; it describes projects that do get delivered, but never in the same way twice. Give the same team two similar projects and how the plan is sequenced, where the estimate comes from, how reviews are held and how configuration is managed all depend on who is doing the work this time and how hard the customer is pushing. Delivery happens, but it is not repeatable; a crisis can be rescued, but the rescue is not written down, so the next crisis is rescued all over again.

So what Level 1 looks at is not "are there documents" but are there stable management actions: does the project have a plan that is actually used for comparison while it runs; does the estimate have a basis, or was the delivery date fixed first and the effort back-calculated from it; are schedule and effort reviewed regularly, and at what deviation does someone act; when a requirement changes, does anyone assess the impact and record the decision; do work products have baselines, and can changes be traced; do reviews actually raise issues and close them. These actions are not absent in a Level 1 organisation — they are present sometimes, depending on the person and the project. That is what "initial" means.

Who it fits

Teams that have just started, run few projects and first need the work finished are at Level 1 for good reason, and there is no need to assemble a set of documents nobody uses just to look orderly. Companies whose business is mainly one-off custom work, whose process is largely defined by the customer and who cannot reuse work across similar projects also tend to stay here. There is a third group: companies that assess themselves and find "we are actually Level 1". The right move then is to put the Level 2 management actions in place first, not to apply for Level 2 and hope a consultant fills in the paperwork.

How to organize the evidence

• Process assets: there may be only scattered templates, in inconsistent versions. Stating plainly which are company requirements and which each project assembled for itself holds up to questioning better than an improvised "company standard".
• Project evidence: a plan that has drifted from actuals, and records that exist only at kick-off and at closure, are the typical shape at this level. Those gaps are the current state; hiding them tends to surface in interviews.
• People: key actions sit with a few strong individuals, and responsibilities are largely verbal. In an interview, the question "what would happen if someone else did this" usually answers the level question by itself.
• Tools: tools are used per person and data is not aggregated. Provide whatever can be exported; there is no need to buy a platform to look like Level 2 — bought and unused becomes a new gap of its own.

Common return reasons

Level 1 itself is rarely "returned"; what gets returned is a Level 1 situation filed as Level 2. Four patterns are common:

• The plan was written just before the assessment. Document dates cluster in a short window and do not match the actual rhythm of the project, which is visible at a glance.
• The estimate has no basis. Only the resulting number exists — no size, effort, assumptions or historical reference — so the question "how was this calculated" finds nothing underneath.
• Every review is signed but no issues are recorded. All reviews "passed first time", which is precisely the sign that reviews were not doing anything.
• Configuration management is a set of folders. No configuration item identification, no baseline, no change log, with versions told apart by file name and date.

2. Level 2 Managed: bringing a single project under control

What is reviewed

The keyword at Level 2 is "project level". It does not require the whole company to work to one process, but it requires every sampled project to be under control on its own terms. Being under control has four signs: a commitment, a plan, tracking, and correction. Following that loop is the whole of Level 2: when a requirement arrives, does anyone confirm the scope and the acceptance criteria; where does the plan come from, does the estimate have a basis, are dependencies identified; during execution, are schedule and effort reviewed regularly and at what deviation does someone act; when a requirement changes, is the impact assessed, is there an approval, and do the plan and the tests change with it; do work products have baselines and do versions reconcile; are purchased or subcontracted parts covered by agreements and tracked.

The boundary with Level 3 sits here as well: Level 2 proves "this project can be managed", Level 3 proves "this organisation can repeat it". Level 2 therefore allows ten projects to be run in ten ways, as long as each way closes its own loop; Level 3 requires those ways to share an origin, be comparable and be tailorable. Many companies hurry at this step — writing Level 3 documents before the Level 2 loop runs smoothly — and the project records end up hollow, breaking at the first sample.

Who it fits

Companies with a modest number of projects, wide variation between project types, and unstable delivery as the pressing problem: Level 2 addresses that directly — make estimating, planning, tracking, change and configuration real inside projects first. Where the tender document names Level 2 explicitly, prepare to that text and do not add requirements of your own. Companies moving towards Level 3 should also treat Level 2 as the management foundation — an organisational standard process is, in essence, the project practice that already works at Level 2, distilled upwards.

Reasonably deferred: every project is a new domain with no reuse; teams are very small and one person covers all roles, in which case filling in the basic management actions is more practical than applying.

How to organize the evidence

• Process assets: project-level templates, policies and checklists are enough; an organisational standard process set is not required. But templates need versions and need to be in use — they cannot live only on a shared drive.
• Project evidence: project plan and estimating basis, schedule and effort tracking records, regular meetings and weekly reports, review forms and issue closure records, change requests and impact analysis, configuration item lists and baselines, issue and risk logs, closure material. Each project needs at least one complete chain from requirement to closure.
• People: project manager, requirements, development, testing and configuration management roles need to be attached to named people, and the person who signs should be the person who did the work. A role table that names someone who cannot be found in the records under the same name and role is a frequent mismatch.
• Tools: project management, defect tracking and configuration management tools must be producing real data, with history that can be exported. Records entered in a batch the week before the assessment have timestamps that speak for themselves.

Common return reasons

• The plan and the actuals live in two worlds. The plan was written at initiation and never updated; actual progress sits in another sheet, and the two do not reconcile.
• The estimate was back-calculated. The delivery date was fixed first, effort derived from it, with no size, assumptions or historical reference, and no one reviewed it.
• Reviews are signatures only. No issue list, no owner, no close date. Signed without a review taking place is the same as no review.
• Changes are verbal. A requirement changed but the plan, test cases and acceptance criteria did not, and the configuration library still holds the old version.

3. Level 3 Defined: an organisational standard process, tailored per project

What is reviewed

The core of Level 3 is whether one chain can be walked end to end: where the project's plan template came from; which activities were tailored out, under which clause of the tailoring guidelines, and who approved it; whether the reviews, tests, changes and baseline records produced during execution line up with the nodes of the organisational process; and what was done at organisational level with the data inside those records. Walk the chain and Level 3 holds; if any link cannot be answered, the link between "organisational" and "project" is broken.

Look three layers further in. Organisational layer: standard process, templates, checklists, tailoring guidelines, role responsibilities, measurement definitions — do they have versions, effective dates and named maintainers. Project layer: was the project defined process genuinely derived from the tailoring guidelines, and do the execution records run along it. Evidence layer: the time span, density and traceability of the records, and whether in an interview a person can say "this is why I did it that way at the time".

What Level 3 really tests is consistency: different project teams doing similar work should follow processes of the same origin, comparable and tailorable. That is also what makes it harder than Level 2 — documents can be written in a short period, records can only be accumulated by running the work. For the full preparation sequence at Level 3 and how the assessment runs, see the CMMI Level 3 assessment article.

Who it fits

Companies running several projects in parallel, delivering similar work repeatedly, and needing to show customers that "a different project team can do it the same way". The demand usually comes from four sources: supplier admission for government or central state-owned enterprises, vendor programmes, tender qualifications, and internal delivery going out of control (delays, rework, the thread breaking when someone leaves). The fourth type tends to be done solidly, because a real problem is driving it rather than a certificate.

Reasonably deferred: every order is a new type with no reusable project type; the team is very small and maintaining organisational process assets costs more than it returns — for these companies, doing Level 2 first, or putting the ISO 9001 skeleton in place, is the better use of effort.

How to organize the evidence

• Process assets: organisational standard process (policies, processes, templates, checklists), tailoring guidelines, role responsibilities and appointments, measurement definitions and collection methods, training records, process compliance check records. Every document needs a version, an effective date and a maintainer, and must be citable from project records.
• Project evidence: project defined process with tailoring statement and approval, plan and estimate built on the tailored process, requirements and changes, the various reviews, test records, configuration and baselines, issue and risk logs, measurement data, closure material. Cover different project types if you can — one new build, one iterative upgrade, one maintenance — so that "the standard process adapts to different projects" can be argued.
• People: process improvement, QA, project management, configuration management and measurement roles should be separate and match the registered staff. Interviewees need to be the people who actually did the work; a consultant answering in their place loses points here.
• Tools: project management, configuration management, defect and measurement tools should map to process nodes, with data aggregating under one definition. History produced inside the tools is more convincing than any explanatory document.

Common return reasons

• The organisational and project layers are disconnected. The project used its department's own templates, unrelated to the organisational standard process, and can produce no tailoring statement. That chain is exactly what Level 3 examines.
• Tailoring written as "nothing tailored" or "tailored at will". Nothing tailored means the tailoring guidelines are decorative; tailored at will means the process carries no constraint. The workable form is a reason, an approval and a record for each tailoring decision.
• Dates that run backwards. A process document takes effect later than the project records it governs, or records cite a template version that did not yet exist. These are hard to explain and easy to spot.
• Evidence only at the two ends. The project plan and the closure report are complete, but reviews, changes, tests and baselines in the middle are empty. Sampling lands in the middle and the chain breaks.

4. Level 4 Quantitatively Managed: managing with data, not with feeling

What is reviewed

Level 4 assumes Level 3 is genuinely stable: the process for similar projects is already unified and the data definitions already consistent. On that premise, what is reviewed is whether the data can support a judgement. Does the project have quantitative objectives, and are they decomposed from organisational objectives; are estimates and commitments made from the baseline rather than guessed; is process data watched continuously during execution, and when it drifts, can it be judged as normal variation or a special cause; after the judgement, is there an action, and after the action, is the effect verified.

In one line: Level 3 can answer "we work to the standard process"; Level 4 has to answer "with this way of working, roughly where will the result land, why, and is this deviation explainable". Reports without baselines, or baselines without models, leave you at Level 3 and a half — because reports say "what happened", while baselines and models say "what will happen next".

There is a common way to go wrong here: Level 4 is not "the more indicators the better". Choosing three to five indicators that genuinely relate to delivery results and can be collected reliably, fixing their definitions and accumulating thick data, beats spreading twenty indicators with one or two data points each. A baseline is produced by running the work, not by agreeing it in a meeting.

Who it fits

Companies whose process already runs stably, who hold continuous historical data, and whose delivery results need to be predictable: committed dates that get met, quality objectives that hold, costs that can be calculated. Companies whose customers explicitly ask for "capability shown in data" belong here too. A meaningful baseline tends to need larger scale, several projects in parallel and enough similar projects.

Reasonably deferred: Level 3 is not yet running smoothly; project types vary so widely that no comparable baseline forms; data definitions are not yet unified (the same indicator is calculated differently in different projects); nobody in the organisation can explain where the data comes from or how it is used. Forcing Level 4 usually ends as a set of attractive reports that comes apart in one interview.

How to organize the evidence

• Process assets: the measurement system and indicator definitions (definition, collection point, frequency, owner), baseline construction and maintenance rules, model description and verification records, work instructions for quantitative analysis. Definitions need to be specific enough to say "this number comes from this field in this system".
• Project evidence: the project's quantitative objectives and how they map to organisational objectives, estimates and forecasts made from the baseline, continuous process performance data, anomaly judgement and cause analysis, actions and effect verification. A complete chain runs "objective — forecast — actual — deviation — analysis — action — recalculation".
• People: the measurement analysis role and the project lead must be able to explain "where the data comes from, how an anomaly is judged, what an action was based on". If they cannot, the data is being produced for other people rather than used by the organisation.
• Tools: the measurement platform or reports must trace back to source records; the same indicator must be calculated the same way across projects and periods. Changing the algorithm without saying so voids the baseline.

Common return reasons

• Reports but no baseline. Single point values with no historical range. Without a range there is no way to judge whether a value is good or bad.
• A baseline assembled to look right. Too few samples, inconsistent definitions, or different project types mixed into one baseline: it looks like numbers but cannot be used.
• An unverified model. A formula and correlation coefficients, with no statement of applicable range or forecast error, and never recalculated against actual results.
• Anomalies recorded as "noted". The indicator dropped, with no cause analysis, no action and no effect verification, so quantitative management stops at "we saw it".

5. Level 5 Optimizing: improvement as a mechanism, not a campaign

What is reviewed

Level 5 is not "changing a lot" but improvement having become a mechanism: opportunities come from data and root cause rather than from slogans; improvements have objectives, pilots, verification and deployment; and after the change the process assets are updated, the experience enters the repository and other projects can use it. Verification walks one complete chain: how was this improvement identified (a data anomaly, a root cause analysis, customer feedback, a technology change)? Why was it chosen, and what effect was expected? Which project piloted it, and how was the pilot compared with the previous way? How far was it deployed, and were the process assets changed? Is the effect tracked over time, or did it end when the change was made?

One line needs drawing here: fixing a bug, adding staff or replacing equipment are execution-level actions, not process optimisation. Level 5 looks at "the way of working changed and capability rose", not "this problem was solved". In the same way, treating "we deployed a system" as an improvement is common — the system is only a means; with no objective, no comparison and no effect data, optimisation has not been shown.

Who it fits

Organisations where process and data are both mature, where delivery capability is itself the competitive edge, and where cost and quality improvement is continuous. These companies usually already have a standing process improvement role; improvement is part of the everyday mechanism rather than a temporary project team's job. Some companies move towards Level 5 because a customer asks for it or because of industry standing — in that case the Level 4 baseline has to run steadily first, otherwise there is no "before" for Level 5 to compare against.

Reasonably deferred: Level 4 data is still unstable; Level 5 is being treated as "a level that looks good"; there is no improvement owner and improvements depend on temporary assignments. A higher level is not automatically better — Level 5 asks for sustained investment, not one sprint.

How to organize the evidence

• Process assets: the improvement process and root cause analysis method, pilot and deployment rules, the experience repository and reuse mechanism, and the versions and change records of process assets after improvement. Improvements have to reach the documents, otherwise the next round reverts to the old way.
• Project evidence: the complete chain of an improvement from identification to verification, the pilot project and comparison data, deployment scope and execution records, continued tracking of the effect. One file per improvement is more convincing than one summary report.
• People: improvement owner, pilot project team and deployment owner — three roles that map to specific improvement items. Someone proposed it, someone tried it, someone deployed it; all three need a name.
• Tools: data analysis and the experience repository support before-and-after comparison; changes to the tools themselves should also be verified as improvements rather than presented as achievements.

Common return reasons

• "Deployed a system, bought a tool" presented as improvement. No objective, no comparison, no effect data — only the means changed.
• An improvement list with no verification. What changed, whether it worked, who verified it, when it was closed — none of it can be answered.
• Different definitions before and after. One algorithm before the improvement and another after: the numbers look better but are not comparable, so nothing has been shown.
• The pilot works and cannot be deployed. It only works in the project team that cooperates fully, and other projects revert to the old way, which means the improvement never entered the process assets.

Across levels: one shared evidence base, used at all five

The five levels review at different depths, but a block of material is used at every level. Organising that block once into a shared base saves far more effort than digging everything out again for each application, and it is easier to keep consistent. As the level rises, what changes is depth and density, not the set of material.

Shared does not mean copied over as-is. There are three rules, and breaking any one of them shows up during the cross-check:

1. One version per data point. Project name, start and end dates, number of participants, effort and size figures must be identical in the application form, the project description and the measurement reports. The higher the level, the more chances there are for the figures to be cross-checked.
2. A document must take effect before the records it governs. This is a hard constraint of chronology. A process document taking effect later than the project records is self-evidence that the records came before the rule, and it cannot be explained away.
3. Definitions must not change when upgrading. An indicator called this, calculated this way, at Level 3 must still be the same one when baselines are built at Level 4. Change the algorithm midway and the historical data no longer connects; the baseline has to be accumulated again from the start.

The upgrade path and a common planning order

Upgrading is not "submitting the material again"; it is that the evidence the level above requires has already existed continuously. That sentence settles the planning order: run the lower level's actions until they are habit, let the records grow, and only then talk about the level above. The table below sets out, for each step up, the capability that is genuinely added and the evidence that has to be in place first.

On planning order, the line usually runs like this:

1. Fix the scope. Say first which organisational unit it is, and which projects and people it covers. If the scope is not settled, none of the later evidence has anywhere to belong.
2. Take stock of the present. Survey project types, existing processes, existing records, and what data the tools are producing; compare them with the target level to find gaps. Gaps have to land on "which action is missing, which record is absent", not "not enough documents".
3. Set the target level. Take it from the customer or the tender document as written; do not guess from industry habit, and do not follow along because "peers are said to be doing it".
4. Build or complete the process assets. Establish the standard process and tailoring guidelines before talking about project execution. Reverse the order and you are writing records first and adding the rules afterwards.
5. Pick real projects and run them. Choose projects that will let someone turn everything inside out, and run them under the new process until records form a series. A project that has just started and produced no process records is not a usable sample.
6. Aggregate and check at organisational level. Measurement is aggregated under one definition, QA checks that execution matches the standard, and nonconformities are closed.
7. Run a readiness check before booking the assessment. Pre-check documents and evidence, list the gaps, close them, and only then go on site.

On whether levels can be skipped, four judgements are worth remembering:

• A maturity model is cumulative. A higher level presumes the lower level's actions have been institutionalised. Skipping shows up in the evidence as missing lower-level actions, and sampling finds it. Whether an application is accepted, and how it is judged, is subject to the CMMI Institute model documents currently in force and the Lead Appraiser's requirements.
• Starting at Level 3 is reasonable, but there has to be a foundation. Companies that already have an ISO 9001 or ISO 27001 system skeleton, project management and configuration management tools genuinely in use, and a concentrated set of project types can aim at Level 3 directly. But be clear: ISO system documents cannot serve directly as CMMI process assets, and project process records cannot be shared between them — one examines how controls are implemented, the other examines how projects are run. The relationship between them can be read across the ISO 27001 and ISO 20000 pages.
• A higher level is not automatically better. Levels 4 and 5 need quantitative management and process optimisation data, which places requirements on the measurement system of a different order. Forcing them without accumulated continuous data is a poor return on the investment, and repeatedly patching the material drains the team.
• The certificate is not the finish line. An assessment result has a validity period and must be reassessed as required when it expires. If the process stops, records break off or key people leave during that period, the next round is effectively starting over. The validity period and reassessment requirements are subject to the rules in force.

Action list: match yourself against each level, then decide which to apply for

After reading the five levels, the work comes down to a single line. Do not reverse the order — fix the scope, take stock of the present, set the level, and only then talk about documents and the assessment.

• ⬜Write in one sentence which kind of project you mainly deliver (own product, custom development, system integration, industry solution) and what the typical process for that kind of project is
• ⬜List the candidate projects and keep only those genuinely undertaken by your own company for which complete process records can be produced, marking each one's start and end dates and participants
• ⬜Against Level 2, ask four questions: is there an estimating basis, is there a plan and tracking, does a change get approved, is there a configuration baseline — four "yes" answers before looking at Level 3
• ⬜Against Level 3, ask three questions: does the organisation have a standard process, does each project have a tailoring statement and approval, can measurement be aggregated under one definition
• ⬜Against Level 4, ask two questions: do similar projects have a historical range, and when an indicator drops can the cause be judged and an action taken
• ⬜Against Level 5, ask one question: does any past improvement have all four of pilot, comparison, deployment and asset update
• ⬜Check whether the contracting entity, the executing entity and the personnel's employment relationships are the same entity, and deal with anything cross-entity first
• ⬜Build a project master data table (name, start and end dates, participants, size and effort, deliverables) as the reference throughout, so that no second version exists
• ⬜Check the chronology: does each process asset take effect before the project records it governs, and does any template version number look like a "future version"
• ⬜Confirm the target level comes from the customer or the tender document as written, and arrange for people who can explain the process to attend the interviews rather than leaving it all to a consultant

By this point the five levels come down to one sentence said five ways: how far up the ladder of repeatability the way you run projects has got. Level 1 runs on people, Level 2 on project management, Level 3 on organisational definition, Level 4 on prediction from data, Level 5 on evolution through a mechanism. Choose the level correctly and the material is organizing work; choose it too high and the material has to be redone — and the difference between the two often lies in whether you thought through "what this level actually reviews" before picking anything up.

▍Not sure which level you are at today, or whether to move up one? Leave a comment noting "CMMI level self-check" and I will send you an evidence mapping table filed by the five levels.