CSMM's Five Levels, One by One: What Each One Reviews and What Evidence It Wants

The five levels at a glance

How to read this table: read the fourth column first, then the second. The second column describes what capability looks like, and it is easy to read a row and think "that is roughly us"; the fourth column describes what will be asked for during assessment, and that is the gate you either pass or do not. No numeric thresholds are given here — organisation size, assessment scope and the number of projects covered differ so much that everything is subject to the rules in force.

1. Level 1: the process rests on people, so delivery cannot be repeated

What is reviewed

Level 1 does not describe "no projects being run"; it describes projects that do get built, but never the same way twice. Give one team two projects of the same kind and how the plan is sequenced, where the estimate comes from, how reviews are held and how versions are controlled all depend on who is doing it this time and how hard the customer is pushing. The work gets finished, but the way of working does not stay behind; when something goes wrong it can be rescued, but nobody records how it was rescued, and the next project is rescued all over again.

So what this level looks at is not "are there documents", but are there stable management actions: does the project have a plan that is genuinely used for comparison while it runs; does the estimate rest on something, or is the delivery date fixed first and the effort worked backwards from it; are progress and effort looked at regularly, and at what deviation does something happen; when requirements change, does anyone assess the impact and record the decision; do work products have a baseline, and can changes be traced; do reviews actually raise issues and close them. These actions are not entirely absent in a Level 1 organisation — they are sometimes there, depending on the person and the project. That is what "initial" means here.

Who it fits

Teams that have just started, run few projects and are focused on getting the work out of the door are at Level 1, and that is normal; there is no need to assemble a set of documents nobody uses in order to look orderly. Companies whose business is mainly one-off custom work, whose process is largely defined by the customer, and which never build up a reusable project type often stay in this state too. A third group is companies that self-assess 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 at Level 2 and hope the material can be filled in afterwards.

How to organise the evidence

• Process assets: there may be nothing beyond scattered templates, with versions that do not match. Saying honestly which ones the company requires and which a project put together itself survives questioning better than improvising a "company standard" on the spot.
• Project evidence: a plan that has drifted from reality, and records that exist only at kick-off and at closure, are the usual shape at this level. Those gaps are the current state; hiding them only means they surface in the interviews.
• People: key actions sit with a few core staff, and responsibilities are usually agreed verbally. In an interview, one question — "what would happen if someone else did this?" — usually answers the level question by itself.
• Tools: tools are used person by person and the data is never aggregated. Provide what can be exported; there is no need to buy a platform at short notice to "look like Level 2" — bought and left unused, it becomes a new weak point.

Common return reasons

Level 1 itself is rarely "returned"; what gets returned is a Level 1 state filed as Level 2. Four cases come up often:

• The plan was written just before the assessment. Document dates cluster into a short window and do not match the real rhythm of the project, which is visible at a glance.
• The estimate has no basis. Only the resulting number, with no size, effort, assumptions or historical reference — one question, "how was this calculated?", and it collapses.
• Review signatures are complete but there are no issue records. Every review "passed first time", which is precisely the sign that the reviews did nothing.
• Configuration management is a folder. No configuration item identification, no baseline, no change records; versions are told apart by file name and date.

2. Level 2: bringing a single project under control

What is reviewed

The keyword at Level 2 is "project level". It does not require a unified process across the company, but it does require every project selected for sampling to be under control in its own right. Being under control shows in four things: a commitment, a plan, tracking, and correction. Follow that loop and you have the whole of this level: when requirements come in, does anyone confirm the scope and acceptance criteria; where does the plan come from, does the estimate have a basis, have dependencies been identified; during execution, are progress and effort looked at regularly, and at what deviation does something have to happen; when requirements change, is there impact analysis, who approved it, did the plan and the tests follow; do work products have baselines, and do the versions reconcile; does purchased or subcontracted work have an agreement and tracking.

The boundary with Level 3 sits here too: Level 2 proves "this project can be managed", Level 3 proves "this organisation can repeat it". So Level 2 allows ten projects to be run ten different ways, as long as each way closes its own loop; Level 3 is where those ways must come from one source, be comparable and be tailorable. Many companies hurry at this point — writing Level 3 documents before the Level 2 loop runs properly — and the result is hollow project records that break as soon as a sample is drawn.

Who it fits

Companies with few projects, quite different project types, and delivery instability as the pressing problem are a good fit for Level 2: get estimating, planning, tracking, change and configuration genuinely working inside projects first. Where the tender document states Level 2, prepare to the original text and do not add requirements of your own. Companies heading for Level 3 are also advised to treat Level 2 as the management chassis — the organisation standard process at Level 3 is, in essence, the project practice that already works at Level 2 lifted one level up.

What can wait: every project being a new domain with no reuse between them; a very small team where one person covers every role — there, filling in the basic management actions is more practical than applying.

How to organise the evidence

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

Common return reasons

• Plan and reality are two different documents. The plan was written at kick-off and never updated; actual progress lives in another sheet, and the two do not reconcile.
• The estimate was worked backwards. The delivery date is fixed first and the effort derived from it, with no size, assumptions or historical reference, and nobody reviews it.
• Reviews are signatures only. No issue list, no owner, no closure date. Signed but never held is the same as not reviewed.
• Change is verbal. Requirements changed, but the plan, test cases and acceptance criteria did not follow, and the version in the repository is still the old one.

3. Level 3: organisation process assets, and projects executing after tailoring

What is reviewed

The core of Level 3 is whether one chain runs end to end: where did this project's plan template come from; which activities were tailored out, against which clause of the tailoring guideline, approved by whom; do the review, test, change and baseline records produced during execution line up with the nodes of the organisation process; and what was done at organisation level with the data inside those records. If the chain runs, the level holds; if any link cannot be answered, the organisation level and the project level are disconnected.

Inside that, three layers. Organisation layer: standard process, templates, checklists, tailoring guideline, role responsibilities and measurement definitions — with version, effective date and owner. Project layer: whether the project's defined process was really generated from the tailoring guideline, and whether execution records follow it. Evidence layer: the time span, density and traceability of the records, and whether people in an interview can say "this is why I did it that way". What this level really tests is consistency, and that is what makes it harder than Level 2 — documents can be written in one short burst, records can only be run up.

Who it fits

Companies running several projects in parallel, delivering the same type of project repeatedly, and needing to show a customer that "a different project team could do this the same way" are a good fit for Level 3. The drivers are usually one of four: supplier admission for government or state-owned buyers, a large enterprise's supplier system, a tender requirement, or delivery losing control internally (slippage, rework, everything stopping when one person leaves). The fourth is often done solidly, because a real problem is driving it rather than the wish for a certificate.

What can wait: every order being a new type with no reusable project type; a very small team where maintaining organisation-level process assets costs more than it returns. For those companies Level 2 is the better buy first.

How to organise the evidence

• Process assets: organisation standard process (policy, process, templates, checklists), tailoring guideline, role responsibilities and appointments, measurement definitions and how they are collected, training records, process compliance check records. Every document needs a version, an effective date and an owner, and must be citable from the project records.
• Project evidence: the project defined process with its tailoring statement and approval, the plan and estimate built on the tailored process, requirements and changes, the various reviews, test records, configuration and baselines, issue and risk log, measurement data, closure material. Cover different project types where possible — one new build, one enhancement, one maintenance — so that "the standard process fits different projects" can actually be argued.
• People: process improvement, process checking, project manager, configuration management and measurement should be separate roles, consistent with the personnel register. Interviewees have to be the people who 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 that aggregates on one set of definitions. A history run up inside the tools is more persuasive than any explanatory document.

Common return reasons

• Organisation level and project level disconnected. The project used its department's own templates, unrelated to the organisation standard process, and no tailoring statement can be produced. This level checks exactly that chain.
• Tailoring written as "nothing tailored" or "tailored at random". Nothing tailored means the guideline is decorative; tailored at random means the process carries no constraint. The right pattern is a reason, an approval and a record for each tailoring.
• Dates running backwards. The process document takes effect after the project records were produced, or a record shows a template from a "future version". These are easy to find and hard to explain.
• Evidence at both ends only. The plan and the closure report are complete; the reviews, changes, tests and baselines in between are empty. A sample taken from the middle breaks.

4. Level 4: quantitative management, where the result has to be predictable

What is reviewed

Level 4 assumes Level 3 is genuinely stable: the process for this project type is already unified and the data definitions already consistent. On that assumption, what is reviewed is whether the data can support a judgement. Does the project have quantitative objectives, and are they decomposed from organisation objectives; are estimates and commitments made from baselines rather than from instinct; is process data watched continuously during execution, and when it deviates can you tell normal variation from a special cause; after the judgement, is there an action, and after the action, is the effect verified.

One sentence to compare: Level 3 can answer "we work to the standard process"; Level 4 has to answer "working this way, where will the result land, why, and is this deviation explainable". Reports without baselines, or baselines without models, are still level three and a half — a report says what happened; a baseline and a model say what happens next.

Another place people drift: this level is not "more metrics is better". Three to five metrics genuinely tied to delivery results, collected reliably, with the definitions pinned down and the data built up, beat twenty metrics with one or two data points each. A baseline is run up, not agreed in a meeting.

Who it fits

Companies whose process already runs stably, with continuous historical data, where delivery results need to be predictable: promised dates have to be met, quality targets held, cost accounted for. Companies whose customers explicitly ask them to "show capability with data" belong here too. A larger scale, several projects in parallel and enough projects of one type are what make a meaningful baseline possible.

What can wait: Level 3 not yet running smoothly; project types so different that no baseline of a kind can form; definitions not yet unified (the same metric calculated differently across projects); nobody in the organisation able to explain where the data comes from or how it is used. Forcing this level usually produces a set of handsome reports and one interview that sees through them.

How to organise the evidence

• Process assets: measurement system and metric definitions (definition, collection point, frequency, owner), rules for building and maintaining baselines, model description and validation records, work instructions for quantitative analysis. Definitions have to be detailed enough to say "this number comes from this field in this system".
• Project evidence: the project quantitative objectives and how they map to organisation objectives, estimates and forecasts made from baselines, continuous process performance data, deviation judgement and cause analysis, actions and effect verification. The complete chain is "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 and what an action rests on. If they cannot, the data is there for other people to look at, not for their own use.
• Tools: the measurement platform or reports can be traced back to source records; the same metric is calculated the same way across projects and periods. Changing the calculation without saying so voids the baseline.

Common return reasons

• Reports but no baseline. Single-point numbers with no historical range. Without a range there is no way to say whether a value is good or bad.
• The baseline was assembled. Too few samples, inconsistent definitions, or different project types mixed into one baseline — numbers on paper that cannot be used.
• The model was never validated. A formula and a correlation coefficient, with no stated range of application, no forecast error, and no back-testing against actual results.
• An anomaly is logged as "monitored". The metric dropped, and there is no cause analysis, no action and no verification of effect, so quantitative management stops at "seeing".

5. Level 5: continual optimisation becomes routine

What is reviewed

This level is not about "changing a lot", but about improvement becoming a mechanism: opportunities come from data and root causes rather than from slogans; improvement has an objective, a pilot, verification and rollout; when it is done, the process assets are updated, the lesson goes into the library and other projects can use it. Verification follows one complete chain: how was this improvement identified (data anomaly, root cause analysis, customer feedback, technology change)? Why was it chosen, and what effect was expected? In which project was it piloted, and how was the pilot compared with the existing way? How far was it rolled out, and were the process assets changed afterwards? Is the effect tracked over time, or did it stop when the change was made?

One boundary to draw: fixing a defect, adding people or replacing equipment are execution-level actions, not process optimisation. This level looks at "the way of working changed and the capability rose", not "this problem was solved". For the same reason, "we installed a system" is often presented as an improvement — a system is a means; without an objective, a comparison and effect data, it proves nothing about optimisation.

Who it fits

Organisations where process and data are both mature, delivery capability itself is part of the competitive position, and quality and efficiency have to keep rising. They usually already have a standing process improvement role, and improvement is part of the daily mechanism rather than a temporary task force. Some companies move towards Level 5 because a customer asks for it or their industry position calls for it; in that case the Level 4 baseline has to run steadily first, otherwise Level 5 has no "before" to compare against.

What can wait: Level 4 data not yet stable; treating Level 5 as "a level that looks good"; no improvement owner, with improvement staffed by whoever is free. A higher level is not automatically better — this one asks for sustained investment, not a sprint.

How to organise the evidence

• Process assets: improvement process and root cause analysis method, pilot and rollout rules, lessons library and reuse mechanism, the version and change records of process assets after improvement. Improvement has to reach the documents, otherwise the next project goes back to the old way.
• Project evidence: the complete chain of an improvement from identification to verification, comparison data between the pilot project and the existing practice, rollout scope and execution records, sustained tracking of the effect. One file per improvement is more persuasive than one summary report.
• People: the improvement owner, the pilot project team and the rollout owner — three roles that must map to specific improvements. Who proposed it, who trialled it and who rolled it out all need a name.
• Tools: data analysis and the lessons library must support before-and-after comparison; a change to the tools themselves is also verified as an improvement, not displayed as an achievement.

Common return reasons

• "Installing a system, buying a tool" treated as improvement. No objective, no comparison, no effect data — just a different means.
• An improvement list with no verification. What changed, whether it changed, who verified it, when it was closed — no answer.
• Different definitions before and after. One calculation before, another after; the numbers look better but are not comparable, which proves nothing.
• The pilot works and the rollout does not. It only holds in the project team that cooperates; move it to another project and the old practice returns, which shows the improvement never entered the process assets.

6. The relationship with CMMI: same direction, two roads

This is a set of questions that comes up often, and one that is easy to answer wrongly in front of a customer. Both systems look at process capability in software development and delivery, and the assessment logic is similar — both look at process definition, both look at project evidence, both are judged by assessors. But they are two independent systems, with different ownership and different bodies carrying them out: they are not mutually recognised or interchangeable.

What can be shared: much of the underlying work is the same — process definition, project plans and review records, test and defect data, measurement definitions, retrospective mechanisms. This is the same R&D operating data, so a second system does not start from zero. In practice the usual order is "get the process working, then apply where needed": normalise the process and the evidence follows naturally; fixing the certificate first and back-filling the process is usually slower.

What cannot be mixed: the clause structures, evidence requirements and assessment arrangements are independent, so material has to be prepared to each set of rules — not one set with a new cover page. Still less should you tell a customer that "we hold CMMI, which means we hold CSMM": that sentence does not survive a bid evaluation, and it makes the buyer doubt your understanding of qualifications. Nor can the two level sequences be mapped number to number: each system grades and judges on its own, so do not put a conversion in a tender. The grading logic on the CMMI side can be read alongside in CMMI's five levels explained, where the differences are plainer.

7. The upgrade path and the usual planning order

Upgrading is not "submitting the material again"; it is the evidence the level above asks for already existing continuously. That sentence decides the planning order: make the lower level's actions a habit, let the records grow, then talk about the level above. The table below sets out, for each step, the capability that genuinely gets added and the evidence that has to exist first.

On planning order, the usual line runs like this:

1. Fix the scope. Say first which organisational unit it is and which projects and people it covers. If the scope cannot be fixed, none of the evidence afterwards has an owner.
2. Take stock of the current state. Survey project types, existing processes, existing records, and what data the tools are producing, then compare against the target level to find the gaps. Gaps have to land on "which action is missing, which record is absent", not "not enough documents".
3. Set the target level. Go by the original text of the customer's requirement or the tender document — do not guess from industry habit, and do not follow along because "we hear everyone else is doing it".
4. Build or complete the process assets. Build the standard process and tailoring guideline first, and talk about project execution after; reverse the order and you are writing records before writing the rules.
5. Pick projects and actually run them. Choose real projects whose files you are willing to have turned over, and run them under the new process to produce a run of records. A project just started, with no process records yet, is not a suitable sample.
6. Aggregate and check at organisation level. Aggregate the measures on one set of definitions, check execution against the standard, and close out every nonconformity.
7. Schedule the assessment only after a readiness check. Pre-check the documents and evidence, list the gaps, fill them, and then go on site.

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

• Maturity levels are cumulative. A higher level presupposes that the lower level's actions are institutionalised. When an application goes in above its level, the evidence shows it as missing lower-level actions, and a sample exposes it. Whether an application is accepted, and how it is judged, is subject to the assessing body's rules in force.
• Aiming straight at Level 3 is possible, but it needs a chassis. Companies that already have the skeleton of a management system, project management and configuration management tools genuinely in use, and a concentrated set of project types can take Level 3 as the target. But be clear: ISO system documents cannot serve directly as CSMM process assets, and project process records cannot be shared — one checks how control measures land, the other checks how projects run. The relationship between the two can be compared across ISO 27001 and ISO 20000.
• A higher level is not automatically better. Levels 4 and 5 want quantitative management and process optimisation data, which is another order of measurement system. Pushing for them without continuous data is a poor return on the investment, and repeatedly topping up material wears the team down.
• The conclusion is not the finish line. An assessment result carries a validity period and has to be reassessed as required when it expires; if the process stops, records break and core people leave during that period, the next round is effectively a restart. Validity and reassessment requirements are subject to the rules in force.

8. Action list: match yourself to a level, then decide which one to apply for

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

• ⬜Write in one sentence which type of project you mainly deliver (own product, custom development, system integration, industry solution) and the typical process for that type
• ⬜List the candidate projects, keeping only those genuinely undertaken by your own company for which complete process records can be produced, and mark each project's start and end dates and participants
• ⬜Against Level 2, ask four questions: is there a basis for the estimate, is there a plan and tracking, does anyone approve change, is configuration baselined — four "yes" answers before looking up at Level 3
• ⬜Against Level 3, ask three questions: does the organisation have a standard process, do projects have a tailoring statement and approval, can the measures aggregate on one set of definitions
• ⬜Against Level 4, ask two questions: does this project type have a historical range, and when a metric drops can you judge the cause and take an action
• ⬜Against Level 5, ask one question: among recent improvements, is there a case with all four in place — pilot, comparison, rollout, 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) and use it as the reference throughout — never two versions
• ⬜Check the chronology: does the process asset take effect before the project records were produced, and does any template version number look like a "future version"
• ⬜Confirm the target level comes from the original text of the customer requirement or tender document, and arrange for someone who can explain the process to be present at interview rather than leaving it all to an external 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 reached. Level 1 rests on people, Level 2 on project management, Level 3 on organisational definition, Level 4 on data, Level 5 on an evolving 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 does this level actually review" before picking anything up.

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