A habit that costs nothing. When a transformation plan arrives with one capability map per division, do not read the maps. Read across them. Put a finger on every initiative appearing on more than one and write that short list on a separate page. That list, not the strategy on the front cover, is what the programme is about to buy more than once.
The clearest example I have on file sits in the appendix of a digital blueprint written for a global staffing and HR services group. Three maps, one each for marketing, sales and customer service. Each lays out that division's own capability structure, with the digital initiatives meant to raise revenue there pinned onto the cells, and each carries the same closing note: these were to be delivered as machine learning or deep learning work rather than ordinary systems work. The pages describe themselves as illustrative. They are a design rather than a record of anything built, which is why they are still worth reading.
Read one at a time, the maps are competent planning. Read across, they are a duplication estimate.
What a repeated pin actually is
A capability map is a good instrument. It gets an argument off vendor slides and onto the buyer's own picture of the business. The trouble is not the map. It is the plural.
Draw one map per division and you have asked three groups of people the same question in three separate rooms. They answer alike, because the underlying business is one business: the same person is a lead to sales, an audience to marketing and a ticket to service, and every division reaches for the same few things to reach them. So the pins recur. And when three independent teams land on the same initiative, the reflex in the room is relief. Look, alignment. The divisions agree.
They do not agree. They coincide. Agreement is a decision somebody made about who builds the thing and who uses it. Coincidence is three budget owners with three delivery teams and three sets of dates, each holding a paper that says their division needs a customer application. Nothing in the format forces that conversation, and if it does not happen before the funding round it happens much later as an integration project with a worse name.
The map answers what this division needs. It has no cell for the question that matters at portfolio level, which is how many times the organisation intends to build that.
The block that got printed twice
The sharpest instance is not a recurring pin. It is a whole region of the map.
One block of five capabilities, the commercial middle where pricing and lead handling sit, appears in full on both the marketing map and the sales map. Same cells, same initiatives, same wording. A reader going in order sees it once, then again later, and reads the second as that division's plan. Side by side it is one plan reproduced, and the only real question is which division owns it.
That question sits above both sponsors and below the group strategy, so nothing in the format asks it. The block simply stands on both pages, reading on each as that division's own core rather than as the overlap between two.
The centre already knew
This plan is not naive about shared capability. It is naive about where shared capability gets funded.
The same document sets a single readiness check across the whole group, covering the technical ground the initiatives all stand on: how systems integrate, how data is handled and governed, what the analytics capability can carry. That check is scoped once, and the step written straight after it is one prioritised list of gaps. The initiative maps are drawn three times.
So the plan already knows the layer underneath is shared. It has one structure for that layer and another for everything sitting on it, and the boundary between them is in the wrong place. A customer-facing application, a way of turning public channel activity into usable signal, one set of tooling for staff working off a phone: those are not division-specific initiatives that happen to recur. They belong with integration and data governance, in the layer counted once. They ended up in the layer counted three times, because each arrives attached to a business outcome, and anything attached to a business outcome gets filed under the division that wants it.
- Three
- capability maps, one each for marketing, sales and customer service
- One
- readiness check, scoped once for the whole group
- Five
- capabilities in the commercial block, printed on two maps
- Illustrative
- the blueprint's own word for these pages
Buying it once is a different question from building it three times
A second appendix shows what happens when the shared question does get asked properly. It evaluates buying a ready-made platform for the industry-specific parts of the estate, honestly in both directions. For: specialised functionality is difficult and expensive to develop and maintain in-house, proven features shorten the trial and error, and money not spent building goes into service. Against: bought features are not distinctive, standard workflows fit a business only approximately, and wiring it into existing systems is a larger job than it looks.
That decision could be argued on the merits, once, only because the capability was treated as one capability. Ask the same question three times and each division answers from its own workflow requirements, and each concludes, correctly for itself, that the standard product does not quite fit. Three local nos add up to a group yes to building, and nobody ever made that decision.
A capability that appears on one map is a project. The same capability on three maps is either a shared platform or three of them, and nobody chooses which by drawing the maps one at a time.
The version of this landing on my desk now
The vocabulary has moved and the shape has not.
Take the portfolios I am reading this quarter. Marketing wants a copilot over its content and campaign history, sales wants one over accounts and past deals, service wants one over tickets and knowledge articles. Three sponsors, three cases, three sensible outcomes. Underneath all three sit the same three things: a retrieval layer with a vector store over largely overlapping documents, one description of who the customer is that the answers have to be right about, and an evaluation set saying what a good answer looks like before anyone ships.
Those are the repeated pins, and they get built once per division unless somebody lays the plans side by side, because each arrives inside a case about something else. The retrieval layer is in nobody's business case. It is the invisible half of three of them.
Getting this wrong costs more than it did in the mobile round, because the shared items need continuous care. A vector store is kept current rather than finished, so three of them means three ingestion paths and three lineage stories over the same documents. The evaluation set is worse. It is the most expensive artefact in the build, the only one requiring people who know the work to sit and label what right looks like, and its worth comes from being the single scoreboard everything is measured on. Three divisional evaluation sets are one asset divided by three at three times the price. That is also where the habit stops being merely wasteful: what makes an early, carefully scoped autonomous experiment safe to run is a shared definition of an acceptable answer, and you cannot govern three of those.
The regulatory direction points the same way. The European rules are agreed in outline and not yet enforceable, so nobody is being audited yet, but the shape is clear enough to plan on: documentation, lineage and evidence of testing, per system.
What we would do instead
None of this needs a new instrument, which is the awkward part, because it means the fix is available to anyone willing to do an afternoon of clerical work.
Lay every divisional plan on one surface before any of them is funded, and count. Take each initiative appearing more than once off the divisional maps and put it on a shared list with one named owner, one delivery team and one budget line, and let the divisions be its first users rather than its builders. Decide buy or build once per shared item, at group level, so three local misfits cannot quietly add up to a decision to build. Keep the ranked readiness gaps and the shared list on the same page, because they are the same layer and only the format separated them. Then let each division keep what is genuinely its own, which is less than it brought.
That is the opening block of a RealAI Platform engagement, and it is why we ask to see every divisional plan at once rather than the best one first. The count takes an afternoon. The decision it forces is the one nobody further down the process is placed to make.
Drawn from the digital capability appendix of a transformation blueprint written for a global staffing and HR services group: three divisional capability maps with their pinned initiatives, the group-level readiness check beside them, and a separate evaluation of buying an industry platform. Those pages describe themselves as illustrative: a design put forward ahead of a funding decision, not a record of anything delivered. Reading the recurring pins as a duplication estimate is ours.
“A capability that appears on one map is a project. The same capability on three maps is either a shared platform or three of them, and nobody chooses which by drawing the maps one at a time.”
Get in touch
Put RealAI’s applied-AI team on your hardest data problem.
We help enterprises move from pilots to production: sovereign models, governed data, and agents you can audit. Start with a value-first assessment.