Review this. A capability map decomposed to four levels - 380 boxes - each carrying an owner name, a maturity score of 1 to 5, a red/amber/green status and links to supporting systems. It took 7 months and two contractors. In the year since publication it has been used once, to answer whether the two business units duplicate capabilities. What would you remove, what would you change, and what would you leave alone?

What is actually required

One question was asked of this artefact in a year, and it was answered. The map is not useless; it is roughly ten times larger than the question needed, and the surplus is what makes it impossible to keep true.

Depth is the whole issue. Levels 1 and 2 of a capability model — typically 8 to 12 top-level capabilities decomposing into 40 to 70 — describe what a business does and change every few years, when the business model changes. Level 3 starts to describe how the work is organised. Level 4 is process, and process is re-cut at every reorganisation, which in most companies is annual. A 380-box map therefore has a maintenance cost driven by its deepest layer: re-validating 380 boxes at 15 to 20 minutes each is 95 to 125 hours of interviews, and that is before anyone disputes a score.

What I would remove and why it is safe to

• The maturity score. A 1-to-5 rating with no defined evidence is an opinion with a number printed on it, and it invites the one conversation that destroys these artefacts: an owner arguing that their capability is a 4. Nothing was decided by 380 scores in a year.
• The RAG status. Same defect, less information, and it goes stale faster. Anything amber for 12 months is decoration.
• Levels 3 and 4 everywhere they were not needed. Keep depth only under the capabilities where a live decision needs it, which is usually two or three branches. Delete the rest rather than marking it out of date, because a map half-maintained is worse than a small one: readers cannot tell which half.
• The owner field at level 4, where it names whoever attended the workshop rather than an accountable person.

The one change that matters

Replace the scores with numbers the organisation already has. Annual run cost per capability, incident count in the last 12 months, and the change lead time for work touching it. Those three come from the finance system, the incident tracker and the delivery pipeline, so they refresh without interviews and they are arguable only on the facts. A capability with £2.4m of run cost and 9 incidents is a conversation; a capability at maturity 2 is a disagreement.

What I would leave alone even though it looks odd

The capability-to-system links stay, including the messy many-to-many ones. That mapping is what answered the duplication question, and it is the only part of the artefact that could not be reconstructed from an org chart. Keep the untidiness too: a capability supported by four systems is exactly the finding worth having.

How I would argue this in the review

Not as a criticism of the work. The frame is the decision the map must support in the next quarter, and whether each field earns its refresh cost against that decision. A capability map is a lens, not an inventory, and a lens is judged by what you can see through it. Offer the trade explicitly: cut to roughly 60 boxes plus three deep branches, add three measured columns, and commit to a refresh in a week of effort per year rather than 7 months of contractors.

When this is the wrong answer

In a regulated estate where a supervisor requires a documented mapping from business services to supporting systems, the depth and the completeness are the deliverable, and trimming to 60 boxes fails an examination. The test is whether an external party has to be able to trace it. If so, keep the full decomposition, fund it as a compliance artefact, and build the small decision lens separately rather than pretending one document is both.