Capability Maturity and the Maturity Theatre Problem

The maturity assessment is finished. Forty-one capabilities, each scored from one to five, displayed as a heat map in the institution's colours: the capability map, with each capability shaded red, amber, or green according to its current maturity score, so leaders can see at a glance where the institution looks strong and where it looks weak. The consultants presented it well, and the steering group nodded along. The roadmap says most capabilities should reach Level 3 within three years.

You're the one who has to turn it into decisions. And there's a question the heat map can't answer: which of these scores is actually a problem?

Employer Partnership Management scored a two. So did Timetabling. On the map, the scores look identical. But one of them might be the maturity gap that decides whether your strategy succeeds. The other might be exactly where that capability should be: a deliberate two, in an area where raising maturity any further would cost more than it returns. The heat map gives them the same colour. The maturity roadmap treats them the same way. And the improvement budget will be spread across both, as if higher maturity were a good thing in itself.

That isn't a flaw in the scoring. The assessment measured how mature each capability is. Nothing measured how mature each one needs to be, and that second number can't come from the capability itself. It comes from what the organisation is trying to achieve: its strategy.

Capability maturity is the practice of measuring how well an organisation performs each of its business capabilities, on a scale that runs from ad hoc to optimised, and then deliberately improving the ones that matter most. The practice breaks down at a predictable point: deciding which capabilities matter most, and how mature each one actually needs to be.

Think of the map and the numbers as two separate layers. The capability map answers the question "What are we able to do?" It's the shared inventory of capabilities, and on its own it contains no scores at all. The numbers are laid over the top of it. Each capability can have three, each answering a different question and each coming from a different source:

• Current comes from the assessment and answers "How mature is this capability today?"
• Required comes from the strategy and answers "How mature does it need to be?"
• Validated comes from outcome evidence and answers "How much of the claimed maturity is real?"

Your assessment delivered the first of these, current, forty-one times over, and it's the only one of the three that can't change a decision on its own. The other two are where the money moves. They tell a crisis-level two apart from a deliberate two. They turn a heat map you present into a budget you actually reallocate. And they give you an answer the next time the steering group asks, "Why these capabilities, at this cost?"

A note on terms. A target is the level a roadmap aims for; the required level is what the strategy actually needs. The roadmap's "Level 3 within three years" is a target. In a sound program, targets and required levels are the same number. In Maturity Theatre, the targets are set and the required levels are never worked out.

Same current, opposite finding. The assessment delivers the first number forty-one times; the finding appears only once required is drawn beside it.

Good practitioner guidance already recommends colouring the map by the gap between current and target maturity, or plotting importance against maturity. That's the right instinct. But it leaves the hardest question unanswered: where does the target come from? Score importance by interviewing capability owners and every owner reports their capability as strategic. The target has to come from the strategy itself.

A capability maturity score without a target drawn from the strategy is just a number, not a finding.

This is where most capability maturity roadmaps quietly fail. If the leadership team has never made its strategic choices explicit (where the organisation will compete, and how it intends to win), there's nothing to set the targets from. The only reference left is the scoring model itself, so the roadmap points every capability at a higher level and calls that a plan.

The organisations getting real value from maturity work aren't scoring more rigorously than you. They're setting targets differently, and you can tell the difference just by reading a roadmap, before a single dollar is spent on capability investment. Targets drawn from strategic choices naturally come out uneven: some capabilities are pushed hard, and others are deliberately left alone. Targets that default to the scoring model come out uniform. If the roadmap in front of you says "everything to Level 3," you already know which kind you're holding.

The Maturity Theatre Diagnostic

Maturity Theatre is what happens when an organisation rigorously climbs maturity levels toward targets that were never grounded in a strategic choice. The scoring rubric is defensible. The improvement program is funded, governed, and reporting progress. But no one chose the ladder it's all climbing: no one can name the strategic choice that requires these capabilities to reach these levels. From the outside it looks like diligence, which is exactly why it survives.

If you've read the OKR pillar or the benefits realization pillar, you'll recognise the pattern. It's the same failure of anchoring that produces OKR Theatre and Measurement Theatre, this time at the capability level: a rigorous apparatus with nothing holding it in place.

Related reading: The Phase Every Management System Skips. All three failures come down to the same skipped phase: Define, the strategic choice that none of these tools will make for you.

Five questions will show whether your program is doing real maturity work or Maturity Theatre. They take less than ten minutes.

1. Can you name the strategic choice that sets the target level for each capability you're investing in?

Take the three biggest items in your capability maturity roadmap. For each one, complete this sentence: "This capability must reach this level of maturity because we chose to win in this specific way." If the honest answer is "because the maturity model has five levels and we're at a two," the target is a default, not a decision. Uniform targets fail this test automatically. Every capability to the same level by the same date is a target nobody actually worked out.

2. Does your assessment score performance, or just deployment?

"The CRM is implemented and staff are trained" is deployment. "Enquiry-to-enrolment conversion improved, and we know by how much" is performance. If the scoring rubric awards levels because systems exist, processes are documented, and training is complete, rather than because outcomes are improving, a capability can reach Level 4 while performing no better than it did at Level 2. Maturity practitioners in healthcare learned this the hard way and gave the failure a name; the cases below show what it costs.

3. Is any capability deliberately targeted to stay at a low level of maturity?

A genuine strategy produces some capabilities that are deliberately held low, for one of two reasons. Some are commodities: good enough really is enough, and every dollar spent maturing them further is a dollar taken from the capabilities that carry the strategy. Others are exploratory: their value comes from experimentation, and adding process would slow down the very thing that makes them valuable. Either way, the decision is explicit, and someone can say which reason applies. If every capability's target is at or above its current level, that decision was never made, and the roadmap is treating maturity as good in itself. That's the same as never having asked what each capability is for.

4. Did the last maturity assessment change an investment decision?

Name one: a funding line that moved, a duplication that was merged, an improvement that was cancelled because the capability was already mature enough for what the strategy asks of it. If the heat map's only output was the heat map itself (presented, admired, filed away), the assessment produced a slide deck, not a decision. The map isn't where the value lies. The reallocation is.

5. Is your business case built on your own baseline, or on someone else's return on investment?

A business case built on borrowed numbers can never be proven right or wrong, and a case that can't be proven wrong protects the program rather than the organisation. The classic figures trace back to a 1994 study of thirteen software organisations, from a body of research that has rarely, if ever, reported a loss. That borrowed number describes someone else's best case and predicts nothing about yours. The only evidence that can ever show your program worked is your own baseline: your current performance, measured capability by capability, before the program begins.

Each question tests one of the Three Numbers, or the gap between two of them. If three or more have no clear answer in your organisation, the program is doing Maturity Theatre, and now you can say exactly what that means: it's a program running on one number. The scoring is probably sound. What's missing are the other two numbers, and the fix isn't a better rubric. It's setting targets from strategic choices before the next capability investment is committed.

Take the full diagnostic: Find Your Gap: 4-minute assessment →

The Maturity Contour

A flat maturity roadmap isn't a plan. It's written proof that no strategic choices were made.

The fix has a shape. The right maturity profile across a capability map is deliberately uneven, shaped by the organisation's strategic choices.

One thing needs pinning down first, because everything that follows depends on it: what the scale actually measures. A maturity level measures how firmly embedded a capability's way of operating is: how repeatable, measured, and ingrained its people, processes, technology, and information are, from ad hoc effort at the bottom of the scale to measured, continuously improving operation at the top. Performance evidence is what confirms a claimed level. A capability hasn't truly reached Level 4 unless the services that rely on it are producing measurably better results than they were at Level 2, and the outcomes those results serve are moving with them. Evidence that something has been deployed confirms nothing.

Maturity only means something in relation to other numbers; a score on its own tells you little. The scale gives each capability its three numbers (where the required number comes from is covered two sections ahead), and the findings lie in the gaps between them:

• Current below required is a strategic gap, and the only situation that deserves to be called a crisis.
• Current above required is over-investment: money spent climbing a wall the strategy never asked anyone to climb.
• Claimed current above validated is the Infrastructure Trap: deployment dressed up as capability.
• Current equal to required, by design, is the deliberate two: the capability runs with a light operation, but its outcomes are still good enough for what the strategy needs.

Four patterns, one scale. Only the first is a real crisis; the rest are choices, or the absence of one.

That's how to read the numbers from here on, whatever rubric your assessment used.

With the numbers defined, two things need to be in place before the contour can be drawn: a shared map, and a source for the targets.

Map before score

Mapping and scoring are complementary layers, not competing frameworks. A capability map with no maturity scores on it is a static picture. A maturity assessment with no shared map can't be compared, benchmarked, or acted on consistently. The field has split three ways over this distinction:

• Staged maturity models score levels, but can't tell you which level you need.
• Capability reference models map what you do, but deliberately say nothing about how well you do it.
• Outcome-based capability models reject levels altogether.

Each camp holds part of the answer. The contour uses all three: the shared map, the scale, and the rule that only performance evidence confirms a level.

How far the market actually gets with those layers is now measured. The State of Business Capability Modelling codes 99 job postings, 11 tool vendors, and 20 public reference models, and finds that half of all capability hiring stops at the map layer, with the feedback loop asked for in one posting out of 99. That report is the evidence; the contour is what to do about it.

Higher education makes a good demonstration because the sector has already solved the hard half of the problem. The Higher Education Reference Models (HERM), maintained by CAUDIT and used by more than a thousand institutions worldwide, give the sector a standard business capability model. HERM is deliberately neutral on maturity: it provides the map, not the scoring rubric. That keeps the shared vocabulary stable while each institution assesses itself against its own strategy. Banking has BIAN and telecommunications has eTOM, though both built their shared maps from other units first (service domains and processes; BIAN only recently layered a capability view on top). Higher education is the rare sector that went capability-first. Either way the shared-map pattern holds; what no sector can share is target levels, because targets come from strategy, and strategy is the one thing peer institutions don't have in common.

A shared map also makes like-for-like benchmarking possible, and it's worth being precise about what benchmarking is for, because it isn't target-setting. A benchmark is a ruler, not a decision-maker. It can tell you where you sit compared with your peers, but never where you need to sit, because that's for the strategy to decide. So when the contour sets a strategy-critical capability above the sector norm, the target still comes from the strategy. The strategy does the deciding; the benchmark only does the measuring.(HERM's Data Reference Model does the same job for the information layer; the higher education data architecture pillar covers that half of the story.)

Where targets come from

A capability map becomes a decision-making tool when each capability is assessed on three dimensions: strategic importance, maturity, and adaptability. Adaptability comes back at the end of this piece, because it turns out to measure something bigger than any single capability. Strategic importance is the anchor. It can't be settled by interviewing capability owners, because every owner believes their capability is strategic. It has to be worked out in the room where the strategic choices are made.

The tool for working it out is the Strategic Choice Cascade: winning aspiration, where to play, how to win, required capabilities, and management systems. The fourth choice is where target maturity levels come from. An organisation that has decided where to play and how to win has already decided, whether or not it has written this down, which capabilities must be distinctive, which only need to be competent, and which should be deliberately kept to a minimum.

One exception before the cascade takes over: some minimum levels aren't the strategy's to set. Regulators set minimum maturity for capabilities such as cybersecurity, privacy, and research ethics, whatever the organisation's chosen way of winning. These minimums don't break the rule that targets come from strategy. Choosing to operate in a regulated area is itself a where-to-play choice, and the minimum comes with it. The contour is drawn above these minimums, never in place of them.

An organisation whose strategy is a list of priorities, rather than a set of connected choices, has no way to work out strategic importance. Its maturity targets will be set by the only forces left: the maturity model's ladder, the loudest capability owner, and the consultant's benchmark.

Working out a target level

Watch the process happen once, because the whole discipline is contained in it. It answers what we'll call the target-level question: the question every heat map raises and no maturity model can answer. How mature does this capability need to be, and which strategic choice says so?

Take an institution whose way of winning is to offer the best-supported first year in the region. The capability that claim depends on is student support, and specifically its early-alert function: the ability to spot a struggling student and step in before they withdraw. The strategy's claim is comparative (best-supported in the region), so the sector norm is the thing to beat. Peer institutions run early alert at a defined but unmeasured level: the process exists and interventions happen, but no one tracks the outcomes. Call that the benchmark three.

A three can't support the claim, because matching your peers wins you nothing. A five, a fully optimising operation that redesigns itself term after term, is more than the claim needs, and would absorb investment the cascade has committed elsewhere. So the target is a four: interventions that are tracked and measured, and confirmed by outcome evidence, in this case the retention of the students the system flags. Treat that four as provisional for now. A target set for one capability is a first draft. It only becomes final once the value-stream walk, covered further down, confirms the handoffs it depends on.

Now complete the diagnostic sentence: this capability must reach Level 4 because we chose to win on first-year support, and winning means being measurably better than a sector that operates at three. That sentence, repeated for the handful of capabilities the strategy actually depends on, is the Define-phase output your assessment was always missing.

Free worksheet: The Maturity Contour Worksheet runs this derivation across a whole map: the Three Numbers per capability, the strike, minimum, peak, plateau and valley walk, and the choosing sentence every row has to survive.

Peaks, plateaus, and valleys

Repeat that process across the whole map and the contour appears: the Three Numbers plotted for every capability, with the gaps between them made visible. The contour has three features.

Peaks are the small number of capabilities where the organisation's way of winning lives. The early-alert four worked out above is one. Peaks must sit above the sector norm, because the strategy's claim is comparative, and underinvesting in them creates a gap that threatens the strategy itself. A three at a peak is a crisis, whatever the benchmark says.

Plateaus are the table-stakes capabilities that every peer runs. Payroll, procurement, and timetabling need to be reliably boring: standardised, efficient, and probably indistinguishable from any peer's. Here the heat map's most valuable finding is duplication. Three faculties running the same capability three different ways is a consolidation decision waiting to be made. And investing in a plateau beyond "efficient and reliable" means spending money meant for distinctiveness on a capability that can never deliver it.

Valleys are capabilities that are deliberately kept loose: incubating new programs, exploring research directions, trying new kinds of partnership. Stage gates and maturity improvement here would slow down the very experimentation that produces the next peak. A valley is the deliberate two at the scale of the whole map: a chosen low-maturity state, with a clear rationale, clear boundaries, and a regular review. When an experiment turns into an ongoing operation, it moves onto the contour proper.

Neglect is different. Neglect is the absence of a decision. A neglected two and a deliberate two look identical on a heat map. The difference is whether anyone can produce the sentence that chose it.

Walking the map can produce two further verdicts, and neither is a target level.

Strike. A reference model like HERM lists everything an institution could do. Your where-to-play choices select the subset you actually do. An institution with no clinical programs doesn't hold clinical trials management at a deliberate two. It strikes the capability from its map, and records the sentence explaining why.

Source. Some capabilities need to be performed but don't need to be owned, and commodity plateaus are the natural candidates. Outsourcing a capability doesn't make its target disappear; the target shifts to how well you manage the provider. The one thing that can never be outsourced is a peak. If a vendor can supply your way of winning, it was never really your way of winning.

The flat roadmap you were given, against the contour your strategy implies. Red marks where the flat plan under-invests the strategy; the plateaus, valley, and the struck and sourced capabilities are all deliberate choices.

Higher maturity isn't automatically better. Maturity discipline pays off where predictability matters: in stable, repeatable, high-volume capabilities. It costs you where discovery matters. A capability maturity model can't tell which is which. A strategy can.

One caution as you draw the contour: it tells you how high each capability needs to be, not how to get it there. Reaching a four at a peak is rarely just a matter of adding process, because every capability is realised through four elements (people, process, technology, and information), and the gap can sit in any of them. No one with the skills to work with employers is a people gap. No shared definition of a partnership across faculties is an information gap. A system that can't handle the load is a technology gap. The contour tells you how high to climb. The gap classification in the next section tells you what kind of climbing it takes.

The second pass: walk the value stream

Working through the cascade sets targets one capability at a time, and that has a blind spot. It can't see a broken handoff between two capabilities that are each adequate on their own. So the contour needs a second pass. Take each value stream that carries the organisation's way of winning, walk through it from end to end, and check every capability it passes through. A capability that looks like a plateau but sits on a strategy-critical value stream picks up requirements that the capability-by-capability pass will never reveal.

Take timetabling, the example of "reliably boring" from a moment ago. At an institution whose way of winning is work-integrated learning, timetabling sits right on the value stream that carries the strategy, because placements succeed or fail on scheduling. Its plateau target only survives the second pass if its handoffs do.

This is also where the Deliver question gets its method. A service blueprint of the strategy-critical value stream is how you test whether a capability's maturity holds up when it meets the person it exists to serve.

Capability Maturity and the Four Ares

The contour isn't a fifth phase tacked onto the Design4 framework. Each phase of the cycle already asks a maturity question:

Each phase already asks a maturity question, and asking it catches a specific failure: the Infrastructure Trap at Discover, flat targets at Define, misclassified gaps at Develop, broken handoffs at Deliver.

Two implications stand out from the table.

A low maturity score is a symptom with three possible causes. The Design4 pillar's gap classification distinguishes three kinds of gap. A maturity gap means you have the capability, but it isn't good enough. A resource gap means you don't have it. An integration gap means the pieces exist but don't connect. Each needs a different remedy, and a score on its own can't tell you which one you're looking at. Treating a resource gap with process improvement, or an integration gap with a technology purchase, is how organisations spend years fixing the wrong problem. The score tells you where to look. The classification tells you what to do.

Same low score, three different problems, and three different remedies.

The cycle is what makes the maturity ladder safe to use. A capability maturity model without Define leads to every capability climbing to the same level. Without Discover, it leads to the Infrastructure Trap. Without Deliver, it leads to capabilities that look mature on paper but break down at the handoffs. Inside the cycle, the model is a useful tool. Outside it, the model is a hazard, and no maturity model will ever tell you where its own usefulness ends.

No one Publishes a Failed Maturity Program

One warning before the case studies, because the business case that paid for your heat map probably cited a return multiple. In three decades of published research on the returns from maturity programs, studies documenting a loss are vanishingly rare. Failed programs happen, but they don't get written up, so the literature is a record of what the survivors achieved. The vendor side of the market behaves the same way: across sixteen years of coded tool-vendor customer stories, the research report found not one named customer with a quantified outcome that ran through a capability model. The classic benchmarks trace back to a 1994 study of thirteen software organisations, and the stronger modern evidence, from healthcare's studies of digital maturity and outcomes, is honestly correlational rather than causal.The full argument, and how to write a maturity business case the evidence actually supports, is here.

The short version: expect a plausible range rather than a headline multiple. Budget for the J-curve, because new processes reduce productivity before they raise it. And measure your own baseline before the program starts, beginning with your peaks. With a baseline, the program has to earn its next round of funding. Without one, any improvement can't be told apart from noise, and any failure can be explained away.

What This Looks Like in Practice

The heat map that never left the deck

A university commissions a maturity assessment based on its HERM capability map. Forty-one capabilities are scored. The work is genuinely good: a rigorous rubric, wide-ranging interviews, defensible scores. The roadmap recommends raising every capability below Level 3 up to Level 3 within three years, in order of score, lowest first.

Eighteen months later, two improvement projects are under way, both in back-office capabilities that scored lowest. The heat map hasn't been updated. And the strategy, which commits the institution to distinctive work-integrated learning, isn't mentioned anywhere in the improvement portfolio. The capability that carries that strategy, employer partnership management, scored a two and sits eleventh in the queue, behind records management. Its current level is two, and its required level was never worked out.

Somewhere in the third year of that queue is a student who chose this institution for the placement it promised her, and who will graduate without one. The capability that finds placements ran on two overworked coordinators and a spreadsheet, while the improvement money went to records management. She is what a badly drawn contour costs. Nothing on the heat map shows her.

The fix runs through Define, not through re-scoring, and it needs a sponsor before it needs a workshop. The provost, whose strategy the roadmap is quietly failing, calls the working session and owns its decisions. The session works through the Strategic Choice Cascade and identifies the four capabilities the institution's way of winning actually depends on. Their targets are set from the strategy, not the model, and two of them need to exceed the sector norm. The session then goes through the rest of the map with the opposite question: which capabilities need less than the roadmap assumed? Three plateaus turn out to be duplicated across faculties, which raises a consolidation decision no one had put on the table. The innovation-facing capabilities become valleys, with explicit decisions to protect them from process, and dates to review those decisions.

The queue is re-sorted, from "lowest score first" to "furthest from the strategically required level, weighted by importance." Employer partnership management moves from eleventh to first. Two planned improvement projects are cancelled, because those capabilities are already good enough for what the strategy asks of them, something no one previously had grounds to say. On the new roadmap they become deliberate twos, with current equal to required by design and the reasoning on record. The politics are real. The owners of the cancelled projects had been promised investment, and the session where the contour overruled the queue was not a comfortable one.

The mechanics matter as much as the logic. A promised improvement is a governance commitment, so the re-sorted queue goes back to the steering group that approved the original roadmap, on the provost's recommendation, because only the body that made a commitment can undo it. The contour gets a named owner and a standing place in the annual planning cycle. And the assessment finally produces what it was paid for: a reallocation.

The program that deployed its way past the capability

The National Programme for IT (NPfIT), launched by the English NHS in 2002, is the clearest public record of deployment being mistaken for capability on a national scale.

Its goal was integrated electronic care records, bought centrally in what was then the largest civilian IT program in the world. It assumed the capability would follow the technology: roll out the systems, and clinicians would soon be using shared records to deliver safer, better-coordinated care. That didn't happen, because deployment was the only layer being governed. The people element (engaging clinicians) and the process element (huge local variation in how clinical work was done) were treated as change-management footnotes, and progress was reported in contracts signed and systems delivered. The real capability question, whether a clinician in one setting could reliably see and use a record created in another, was never asked at governance level. That unasked question is the information element, which the benefits realization pillar describes as the last to be tested and the first to fail in live use.

The program was dismantled in 2011. Two years later, the Public Accounts Committee called it one of the worst and most expensive contracting fiascos in the history of the public sector. Its costs were then estimated at £9.8 billion and still rising, against just £3.7 billion of benefits identified to March 2012, roughly half of what had been spent.

Readers of the benefits realisation pillar will recognise the echo of Phoenix. Both programs had green dashboards, and both dashboards were answering the wrong layer's question. Phoenix made a strategic commitment based on an unverified account of capability. NPfIT is the same failure one layer down: a capability case built as a technology case, with one element of a four-element system mistaken for the whole. In terms of the Three Numbers, the claimed current level was high and the validated level far lower, and the gap only became clear as the systems reached the people meant to use them.

Healthcare, with its eyes open

Healthcare has taken maturity discipline further than any other sector, and it works as the positive example precisely because it also supplies the warnings.

The HIMSS staged models, led by the Electronic Medical Record Adoption Model (EMRAM), score a hospital from Stage 0 to Stage 7 against a vendor-neutral roadmap. Funders are also starting to attach money to maturity. Germany's hospital modernisation program funds digital projects, measures hospitals' digital maturity, and penalises those that fail to implement required digital services. NHS England runs a national digital maturity assessment to guide its investment. Maturity has moved on from being an assessment exercise to being a strategic lever, and higher education's regulators and funders could plausibly go the same way. That's a forward-looking reason to build the discipline before it's imposed on you.

The warning comes from inside the same sector. Healthcare researchers have criticised EMRAM for focusing almost exclusively on technological functionality rather than human and organisational capabilities. This piece calls that failure the Infrastructure Trap: maturity models that equate maturity with technology adoption and underweight the human and organisational capabilities that actually determine results. In the terms used across these articles, the Infrastructure Trap is Measurement Theatre's twin in the Develop phase: evidence of deployment promoted to evidence of capability, without anything actually performing better. NPfIT is what the trap costs at scale. The lesson isn't "adopt EMRAM for universities." It's the pattern, with the warning built in: a shared map, scoring backed by outcome evidence, targets drawn from strategy, and performance, never deployment, as the thing being scored.

The regional health authority case in the Design4 pillar shows the whole discipline building on itself. Walking a value stream revealed where capability handoffs broke down, an integration gap no maturity score would have caught. The Four Ares re-anchored investment to patient outcomes. And each governance cycle updated the picture faster than the last. Maturity gave that organisation the vocabulary for what to fix; the cycle showed it where fixing would pay off.

The contour isn't just a higher education tool. A bank working from BIAN's capability overlay might find its payments plateau duplicated across three product lines (a consolidation decision waiting to be made), its way of winning resting on two data capabilities that must exceed the peer norm, and a deliberate valley around an embedded-finance experiment that heavier process would kill. Different map, same walk.

The Question Above the Ladder

One question has sat underneath everything in this piece, and no maturity model asks it: how mature is the process that decides how mature your capabilities need to be?

Apply the scale to itself. An organisation whose contour was drawn once, by consultants, and then filed away has an ad hoc way of deciding. It's a Level 1 organisation, whatever its capability scores say. Now take an organisation where working out targets, validating them, and redrawing the contour all happen on a governance calendar, with a named owner and decisions on record. That organisation is more mature than its peers even if half its map sits at deliberate twos, because maturity was never about how tall the bars are. It's about whether anyone governs the relationship between them.

That is what adaptability, the third assessment dimension, really measures across the whole map. It's also what the shift to AI is testing right now, as so many organisations find themselves stuck in endless pilots that never become operations. The full argument deserves its own page: How Mature Is the Process That Decides?

The short version: the maturity level was never the product. The product is a lasting ability to turn whatever arrives next into working capability. Your strategy depends on that ability every time it asks for something new, and redrawing the contour each cycle is how the ability keeps growing.

Go Deeper

You now know how to read the numbers: the Three Numbers, where the required level comes from, the features of the contour, and the question above the ladder. What you don't have yet is fluency with the map itself. The working session in the case study moves quickly because someone in the room understands HERM's capability model well enough to translate between its vocabulary and each executive's language. Without that fluency, the session turns into a debate about definitions instead of producing a contour.

Building the Common Language develops exactly that skill: fluency with reference models, using HERM as the working example, and the discipline of making a shared vocabulary speak in terms each audience understands.

Closing the Strategy-Execution Gap covers the other half of the discipline: the Strategic Choice Cascade that sets the targets, the heat map and gap classification, and the governance rhythm that keeps the contour current. Setting the contour and holding onto it are different skills. The second one gets tested in the first funding round after the queue is re-sorted, in a room where every incentive pulls toward restoring the old order. The course's governance material is designed for exactly that moment.

If the diagnostic showed that your roadmap is flat, the cascade course is where your targets will come from. If the targets exist but conversations about the map keep collapsing into arguments about vocabulary, the reference model course fills that gap, and Core Means Two Things on Your Capability Map names the most common of those arguments before it starts.

Frequently Asked Questions

The Deliberate Two

The heat map on your wall right now probably contains both kinds of two. One of them is a crisis shown in the same colour as a choice.

The practitioners who get value from capability maturity aren't the ones with better rubrics. They're the ones who brought the strategy into the room, set the targets before defending the scores, and then held firm on the contour in the meeting where it cancelled work someone had been promised. Seeing the difference between the two kinds of two is the skill. Holding that line, in front of the owner whose improvement project has just become a deliberate two, is the practice.

You'll know the work has landed the first time you point at a two in a steering committee and everyone in the room understands it's there on purpose. That moment is the visible sign. The less visible asset behind it is the process that produced the reasoning: an organisation that can now decide, on a regular schedule and with evidence, how mature anything needs to be. That isn't a scoring skill. It's an anchoring skill, and it's the one that the next assessment, the next funding round, and the next wave of technology will all put to the test.

Start on Monday morning. Open the improvement roadmap, find the flattest stretch of targets on it, and ask who chose them. If no one can give you the sentence that explains why, you've found your starting point.

Continue Learning

The evidence base: The State of Business Capability Modelling, the companion research report: 99 coded postings, 11 tool vendors, and 20 reference models on what the market actually does with capability maps.

Sibling pillars: Design4 sets out the four-phase cycle this pillar's maturity question attaches to at every stage. Benefits realization is the Layer 2 discipline this contour feeds, the account a strategic benefit draws on.

In the cluster: How Mature Is the Process That Decides? takes the question above the ladder and runs it as its own argument. Core Means Two Things on Your Capability Map names the vocabulary fight before it starts. Why Didn't Anyone See the Enrollment Cliff Coming? shows a target nobody recalibrated, in a sector living the terrain shift now. The Capability Target Nobody Revisited and Capability Maturity Has an Expiry Date are the same failure seen from two directions: whether a correctly set target is still the right one, and whether a capability that reached its target is still standing there.

If you're building a contour, The Maturity Contour Worksheet is the companion template.

Building the Common Language and Closing the Strategy-Execution Gap teach the two halves of holding a contour: reading the map fluently, and deriving and governing the targets on it.