A capability map published nine months ago is quoted in every strategy deck. Each level-3 capability lists between four and eleven supporting systems and no system supports only one capability. The last two quarters of funding decisions contradict the map's own priorities. The two capabilities the strategy calls differentiating are both rated mature. What is the diagnosis?

The first three things I would look at

1. The provenance of the capability names. Ask who wrote them and what was on the screen next to them. A map built from interviews with business owners reads differently from one built from an application inventory, and the difference is visible in the vocabulary: "supplier content ingestion" is a system, "agree what we sell and at what price" is a capability.
2. The fan-out in both directions. Many systems per capability is normal. Many capabilities per system, for every system, is the tell: it means the boundaries were drawn where the data happens to sit today.
3. The two capabilities the strategy calls differentiating. Both rated mature is a strong signal, because a differentiating capability that is genuinely mature would already be winning.

The diagnosis

The map was reverse-engineered from the system estate, so it describes what exists and inherits its boundaries from it. That makes it incapable of the one job a capability map has: to say that the business needs something it is not currently organised to do. The maturity ratings are the proof, because they were almost certainly derived from how well the supporting systems work, not from how well the business performs the outcome.

The test that settles it in one question: if every system were replaced next year, would any capability name change? In a sound map, none would. In an inverted map, most would.

Travel-supplier aggregation in the mould of Expedia shows the failure sharply: an inventory-derived map produces one capability per supplier integration, while the business's actual capability is "present a comparable priced offer across suppliers", which no single integration performs and which the map therefore never names or funds.

Why the other options fail

• Decomposed one level too shallow. A real and common problem, and it produces a different symptom: capabilities so broad that every one maps to the whole estate and nobody can own one. Here the capabilities are specific enough to list four to eleven systems each, so granularity is not the binding fault. It would be the right diagnosis if the map had twelve boxes and each belonged to a whole division.
• No maturity overlay. This is the right answer when a map is never used at all, which is not what is happening: the map is being quoted and it has ratings. An overlay on an inverted map makes the wrong conclusion more persuasive, not less.
• No owner since publication. Staleness would show as missing recent systems and renamed teams. It does not explain ratings that contradict the strategy on day one, and appointing an owner to maintain an inverted map buys nothing.

The fix, in order

1. Rebuild the top two levels from outcomes, with business owners and without the inventory in the room. Two workshops and a week of drafting, not a quarter.
2. Re-rate maturity against outcome evidence — first-time resolution, unit cost per transaction, lead time to change a rule — rather than against system health.
3. Reattach systems afterwards as an overlay, so the map stays independent of the estate. Keep the mapping many-to-many and resist tidying it; the messiness is information about coupling.
4. Publish the two capabilities where importance is high and maturity is low, with a number attached to each. That list, not the map, is the artefact that changes funding.

When this is the wrong answer

When the organisation is small enough to hold in one head. For a company of 60 people with nine systems, a one-page memo naming the three things the business must get good at this year beats any capability model, and it is written in an afternoon. Capability mapping earns its cost when ownership is spread across enough teams that nobody can see the whole, typically several hundred people upward.

It is also the wrong answer when the real problem is that the strategy is not decided. A map cannot resolve disagreement about what is differentiating; it only makes the disagreement legible. If two executives would rate the same capability differently, fix that first, or the map will be rebuilt around whoever reviews it last.