How to use a maturity scale in a transformation programme

Most transformation programmes reach a point where someone asks, "Is this actually working?" Milestones say what was delivered. They rarely say whether the teams and processes being changed are any better at what the programme set out to improve.

A maturity scale answers that question, provided it is used as a diagnostic rather than a report card. This guide covers how to set one up inside a programme, what to measure, and how to read the results without fooling yourself.

What a maturity scale is for

A maturity scale describes a capability at a few ordered levels, from "ad hoc and dependent on individuals" to "measured and continuously improved". Assessing a team or process against it tells you where that unit sits today.

That sounds like a grade, and that is the trap. The value is not the number. It is three things the number helps you see:

• Where effort will pay off. A process at level 1 on ownership and level 4 on tooling needs an owner, not another system.
• Where the programme is uneven. One team racing ahead while three others stall is a different problem from everyone moving slowly.
• Whether things are changing. The same scale, applied to the same unit a quarter later, shows movement that milestone reports can't.

The scale is ordinal. Level 4 is better than level 2, but it isn't "twice as mature". Treat the levels as positions on a path, not quantities to add up.

Start from the outcome, not the model

It is tempting to pick a well-known model and apply it whole. Generic models are a good starting point. CMMI's five levels (Initial, Managed, Defined, Quantitatively Managed and Optimizing) have shaped how a generation of organisations talks about maturity. But a model only helps if its capabilities are the ones your transformation is trying to change.

Write down the two or three outcomes the programme exists to deliver, such as faster month-end close, fewer handoffs between sales and delivery, or teams releasing without a change board. Then ask which capabilities have to improve for those outcomes to happen. Those are the capabilities your scale should cover. Everything else is noise that lengthens the questionnaire.

Choose your units

A maturity score belongs to something. Decide what that something is before you write a single question.

Teams suit transformations about ways of working: agile adoption, DevOps, a new operating model. People answer for their own team, and the team can act on the result.

Business processes suit transformations about how work flows: order to cash, procure to pay, onboarding. A process crosses teams, so the people answering should come from each stage of it.

Keep units small enough that one person could plausibly own improving them. "Finance" is too big to own. "Record to report" is not. Assessing the whole organisation as a single unit produces an average that nobody can act on.

Pick a scale people can apply consistently

Four or five levels is enough for most programmes. More levels feel precise but make it harder for two people to agree on which one applies.

Describe each level in terms people can observe, not adjectives:

Level	Vague	Observable
1	Immature	Depends on who is doing it; no shared description of the process
3	Defined	Documented and followed across the unit; exceptions have a route
5	Optimised	Measured against targets, and changes are made from the evidence

If you score with questions rather than by picking a level directly, which is more reliable when many people answer, set a threshold for each level on the resulting score. For example, 0–20% is level 1 and 20–40% is level 2. Then check the thresholds against a unit you know well (see Designing a maturity model people will trust).

Set a baseline

The first round of assessment is your baseline, and it is worth getting right.

Ask more than one person per unit. Three to eight respondents per unit is a practical range. One respondent gives you an opinion. Several give you a picture, and their disagreement is information in its own right.

Mix roles. For a process, include someone from each stage. For a team, include the lead and the people doing the work. Leads tend to rate practices that exist on paper; the people doing the work rate what actually happens.

Make it safe to be honest. If people fear the result will be used against their team, scores drift upwards and the baseline is useless. Say plainly what the results will and won't be used for, before anyone answers.

Decide: self-assessment or facilitated? Self-assessment scales across many units and gets more candid answers. Facilitated sessions surface the reasons behind the scores. Many programmes self-assess widely, then facilitate a conversation with the units whose results are lowest or most divided.

Read the results

Look at three things, in this order.

The pattern across units. Lay units against capabilities in a heatmap. A low column is a capability weak everywhere: usually a programme-level cause such as missing tooling, policy or skills. A low row is a unit struggling across the board, often a capacity or leadership issue. Isolated low cells are local and usually the quickest to fix.

The spread within a unit. If one respondent scores a capability at 10% and another at 80%, the average of 45% describes nobody. A wide spread often means the practice exists in one part of the unit and not another, or that people understand the question differently. Either way, it's worth a conversation before you act on the number.

The level, last. Only once you understand the pattern and the spread does the level itself mean much.

Turn scores into action

An assessment that isn't followed by named action breeds cynicism. People will notice that they answered thirty questions and nothing changed.

The simplest discipline is this: every low score gets a decision. That decision is either a blocker with an owner and a date, a deliberate choice to accept it for now, or a judgement that the capability is out of scope for this unit. From maturity scores to blockers covers how to write blockers that actually get worked.

Re-assess on a rhythm

Re-assess every eight to twelve weeks, or at the end of each programme phase. More often than that and there is too little time for blockers to land. Less often and the programme drifts without feedback.

Keep the model stable between rounds. If you change a question halfway through, you can no longer tell whether a score moved because the unit improved or because the question changed. Make model changes between phases, and keep each round tied to the version it was asked against.

When you compare rounds, compare like with like: the same unit, the same capabilities, and ideally a similar group of respondents.

Mistakes to avoid

• League tables. Ranking teams by maturity score turns a diagnostic into a target, and scores inflate to match. Goodhart's law is usually paraphrased as "when a measure becomes a target, it ceases to be a good measure". It applies with full force here.
• Setting the level as the goal. "Everyone at level 3 by Q2" invites box-ticking. Set goals on the outcomes, and use the scale to find out what is in the way.
• Too many questions. Past fifteen minutes, answers get careless. Twenty to thirty well-chosen questions usually beat sixty.
• Averaging away disagreement. Always look at the spread before the mean.
• Scoring without acting. If you are not prepared to act on low scores, don't ask the questions.

A checklist

1. Name the outcomes the programme exists to deliver.
2. Choose capabilities that drive those outcomes.
3. Choose units small enough for one person to own.
4. Describe four or five levels in observable terms.
5. Baseline with several respondents per unit, from mixed roles.
6. Read the pattern, then the spread, then the level.
7. Give every low score a decision.
8. Re-assess on a fixed rhythm with a stable model.