From maturity scores to blockers: turning an assessment into action

The moment after a maturity assessment is where most of them fail. The heatmap is ready, the steering group nods at the red cells, and then the programme goes back to its plan. Three months later the next round shows much the same picture, and people start to wonder why they bothered answering.

The fix is not a better assessment. It is a habit: every low score gets a decision, and every decision has an owner.

Three possible decisions

When a capability scores low for a unit, there are only three honest responses:

1. Raise a blocker. Something specific is in the way, someone will remove it, and there is a date.
2. Accept it for now. The capability matters, but not in this phase. Write that down, with the reason and when you will look again.
3. Rule it out of scope. The capability doesn't apply to this unit. A back-office team may never need on-demand deployment. Record that too, so the cell stops attracting attention.

What matters is that no low score is left without one of the three. A heatmap full of unexplained low cells tells people the programme isn't really looking.

Write blockers about what's in the way, not about the score

"Ownership is at level 1" is a score, not a blocker. Nobody can work on it.

A good blocker names the thing that, if it changed, would let the score move:

Weak	Better
Improve process documentation	No single current version of the order-to-cash process exists; three teams use their own
Ownership is low	Nobody owns the hand-off between credit control and collections
Raise measurement maturity	Days sales outstanding (DSO) isn't reported weekly, so problems surface at month end
Get better at automation	The three-way match in procure to pay is done by hand in a spreadsheet

Each of these is specific enough that someone could say, "That's done." It is also specific enough that you can check, at the next round, whether removing it made a difference.

Ownership that means something

A blocker needs a named owner: a person, not a team or a role. That person needs the authority, or the access to it, to make the change.

Two patterns work well:

• Unit-level blockers (an isolated low cell) belong to the unit lead or process owner. They can usually be fixed within the unit.
• Programme-level blockers (the same capability weak across many units) belong to someone on the programme, often a workstream lead. No single unit can fix a missing tool or policy.

Give every blocker a due date, even a rough one. A blocker without a date is a wish.

Read the heatmap for priorities

Not every low cell deserves a blocker straight away. The pattern on the heatmap tells you where to start.

A low column. When the same capability is weak in most units, the cause is almost always shared: missing tooling, a policy that gets in the way, a skill nobody was trained in. One programme-level blocker can lift a whole column. These are usually the highest-leverage items you have.

A low row. When one unit is weak across most capabilities, a list of twelve blockers won't help. The issue is usually capacity, leadership or how much change the unit has been asked to absorb. Have a conversation with the unit lead before raising anything.

Isolated cells. A single weak capability in an otherwise healthy unit is often the quickest win. It is also good for momentum, because people see a score move.

Wide spread. Where respondents in a unit disagree sharply about a capability, don't raise a blocker yet. Find out why first. The disagreement often is the blocker: the practice exists for some people and not others.

Limit what's open

It is tempting to raise a blocker for every red cell. Resist it. A unit with nine open blockers effectively has none, because none of them gets attention.

Keep one to three open blockers per unit, and a short list at programme level. When one closes, the next takes its place. This is the same idea as limiting work in progress on any delivery board, and it works for the same reasons.

Make it visible

Blockers get worked when people can see them. Put the board in front of the people who can unblock them:

• Review open programme-level blockers at every steering meeting. Spend the time on what's stuck, not on what's on track.
• Give unit leads a view of their own blockers, without having to ask the PMO for a report.
• Show sponsors the heatmap and the board together, so a red cell and the work to fix it are seen side by side.

If the programme already keeps a RAID log, link the two rather than running parallel lists. Export blockers into the log, or reference the blocker from the RAID item, so there is one place to look.

Close the loop at the next round

Re-assessment is where the method earns its keep. When the next round comes in, look at every blocker that was closed:

• The score moved. The diagnosis was right and the fix worked. Say so, publicly. It is the best possible argument for answering the next questionnaire honestly.
• The score didn't move. Either the change hasn't landed in practice yet, or the blocker wasn't the real cause. Both are worth knowing. Talk to the unit and raise a better blocker.
• The score moved without a blocker. Something else changed, perhaps a new hire or another initiative. Find out what, because it may work elsewhere too.

Over a few rounds, this turns the assessment from a measurement exercise into a feedback loop. Scores point to blockers, blockers get worked, and the next round shows whether it helped.

In short

• Give every low score a decision: a blocker, a deliberate acceptance, or out of scope.
• Write blockers about what's in the way, specific enough to be done.
• Name a person as owner, and set a date.
• Use the heatmap's pattern to prioritise: columns first, rows by conversation, cells for quick wins.
• Keep few blockers open, and make them visible.
• Check every closed blocker against the next round.