A capability maturity model turns “how good are we at this?” into a score you can compare, track and act on. It's one of the most useful tools an architect or consultant has for showing leadership where to invest.
A capability maturity model is a scale for judging how well an organisation performs a business capability — not whether it has one, but how consistently, how repeatably and with how much supporting evidence.
The point is comparability. Without a shared scale, "our procurement is quite good" and "our procurement is a mess" are two opinions with no way to reconcile them. With one, they become a 3 and a 2, and the conversation moves to why.
Most models use five levels. The labels vary; the substance does not.
| Level | Name | What it looks like in practice |
|---|---|---|
| 1 | Initial | Ad hoc. Outcomes depend on individuals. No documented process; results vary widely between teams. |
| 2 | Repeatable | A process exists and is followed by some teams some of the time. Knowledge is still largely tacit. |
| 3 | Defined | Documented, owned, consistently applied across the organisation. People are trained into it rather than absorbing it. |
| 4 | Managed | Measured. Metrics exist, are reviewed, and drive intervention when performance drifts. |
| 5 | Optimising | Deliberately improved. Changes are tested, benchmarked and fed back. Rare, and rarely necessary everywhere. |
A common misreading is to treat level 5 as the goal for every capability. It is not. Most organisations should be at 4 for the handful of capabilities that differentiate them and comfortably at 2 or 3 for the rest. Pushing a commodity capability to level 5 is a waste of money.
A capability scored as one number hides where the problem is. Score each capability across several dimensions and the diagnosis falls out of the data:
A capability at People 4, Process 4, Technology 1 tells a completely different investment story from one at People 1, Process 2, Technology 4 — the first needs tooling, the second needs organisational work. A single score of "2.5" tells you neither.
The credibility of the whole assessment rests on whether a sceptical executive can challenge a score and get a real answer. That means evidence, not impressions.
For each score, capture what you saw. A documented process is a document you can name. A measured capability has a metric someone can produce. An owned capability has a person whose objectives reference it. When the evidence is a claim in an interview and nothing else, record it as a claim — and score accordingly.
Two practical rules keep assessments honest. First, score what is true today, not what is planned; roadmaps are a separate conversation. Second, when two sources disagree, the lower score is usually closer to reality, because people describe the intended process rather than the one that ran last Tuesday.
The hardest problem in maturity assessment is not gathering evidence — it is ensuring that a 3 awarded on Monday by one assessor means the same as a 3 awarded on Thursday by another.
Three things help. Write level descriptors specific enough to argue with, so "defined" has observable criteria rather than being a feeling. Run a calibration session after the first handful of capabilities, where assessors compare scores and reconcile interpretation before the rest are done. And have one person review the full set at the end looking only for inconsistency — capabilities scored the same that clearly are not, or scored differently on identical evidence.
Maturity alone is not a priority. A capability at level 2 that nobody depends on is fine; a capability at level 3 that the strategy rests on may be the biggest risk you have.
The prioritisation that executives respond to plots maturity against importance. Low maturity plus high importance is where investment goes. High maturity plus low importance is where you may be overspending. The gap — the distance between current maturity and the level a capability actually needs — matters far more than the raw score. For how the same comparison works across the application, data and technology domains, see enterprise architecture gap analysis.
Presenting this well is its own skill; presenting a capability assessment to the board covers the narrative that lands.
A focused assessment of 30 to 40 capabilities takes about a week of concentrated effort: a day to prepare and tailor the model, two to three days of interviews and workshops, a day to score and calibrate, a day to build the story. Assessments that run for months usually do so because scope was never fixed or because the team tried to assess 200 capabilities at a depth nobody needed.
You will need a capability map before you can assess anything — that is the frame the scores hang on.
The Business Capability Assessment Toolkit includes a five-level maturity model, a 40-capability reference model, a scoring calculator with heatmaps, a questionnaire, a 5-day playbook and two worked examples.
