Most capability centres do not fail. They flatten.
The build goes fine. The entity gets incorporated, the floor gets fitted out, the first eighty people join. Two years later the centre is the same size it was, doing the same work, and nobody at headquarters can say what it is for any more.
BCG looked at this in 2025 and found that only 8% of capability centres had advanced significantly across innovation, market advantage and efficiency. Zinnov’s maturity data says something similar from a different angle: just 5% reach the top tier, and 13% never leave the bottom one.
That is not a build problem. It is a design problem, and it starts much earlier than anyone looks.
Why a checklist does not help
The usual response is a checklist. Have you picked a city? Have you hired a site leader? Have you signed the lease?
Checklists find missing items. They do not find wrong sequences — and almost every stalled centre we can find evidence for is a sequencing failure rather than an omission. The lease was signed before the org chart existed. The knowledge transfer happened before the receiving team was hired. The site leader inherited a design they had no part in making.
So we built the model differently. Not a list of things to have, but a structured account of everything that goes wrong, arranged by what depends on what.
Five layers, ten domains, forty-seven issues
The model has five layers. Each depends on the one above it.
Layer 1 — Mandate. Why the centre exists and whether it should. Two domains: strategic intent, and the business case. Ten issues, including the one that starts most failures — location decided before capability. Cost pressure arrives as a number from the CFO, so the question becomes “should we open in India” before anyone has asked “what capability do we need, and where should it live”. A centre staffed to a headcount target owns no outcome. It becomes a body shop, and everybody involved knew that was a risk and nobody wrote it down.
Layer 2 — Foundation. The legal, financial and physical container. Entity, tax and regulatory; location and site. Nine issues. Expensive to get wrong, but reversible. This is the layer everybody plans for, because it has deadlines attached.
Layer 3 — Capability. The people, the work and the knowledge. Leadership and org design, talent, work transition. Sixteen issues — the largest layer, because it is where most of the money goes and most of the value leaks. Leadership density delayed lives here: senior hires cost more, so they get pushed right, and nine months later you have a room full of juniors with nobody to learn from.
Layer 4 — Operation. How it runs, and how it connects to the parent. Governance and integration; technology, data and security. Ten issues. This is where undefined day-two accountability sits — everyone plans the launch, nobody plans the Monday after.
Layer 5 — Value. Whether it compounds or flattens. One domain, five issues, and this is where the year-three plateau finally becomes visible. By the time it shows up here, it was caused three layers up.
Each of the forty-seven issues is defined the same way: what it is, why it happens, what failure looks like, the warning signs, and the mitigation. If a domain has no defined failure mode, it is not a domain. If an issue cannot be scored, it does not belong in the model.
The scoring, and the rule that makes it useful
Every issue scores one to five.
- 1 — Absent. Nobody has asked the question.
- 2 — Ad hoc. One person holds the answer. Nothing is written down.
- 3 — Defined. A document exists. It is not applied consistently.
- 4 — Managed. Documented, owned by a named role, and measured.
- 5 — Compounding. Measured — and the measurement changed a decision last quarter.
The gap between four and five is the one that matters. Most centres that “have a dashboard” are a four. A five means the dashboard moved something.
But the scores on their own would still flatter people. So the model adds one rule:
A domain cannot score more than one point above the lowest score in the layers it depends on.
A centre with excellent tooling and no named executive sponsor does not get a five for technology. It gets capped.
This rule is the whole point. Without it, a diagnostic rewards organisations that bought good vendors and never answered the first question — which describes most stalled centres precisely. They score well on foundation and operation, badly on mandate, and the average hides it.
With the cap applied, the report says something a leadership team can act on: your technology problem is actually a mandate problem, and here is the chain that connects them.
What this looks like in practice
Three examples of a dependency chain, each one real in shape if not in detail.
The centre that cannot hire seniors. Talent scores 2. The obvious reading is a recruitment problem — better agencies, higher offers. The chain says otherwise: strategic intent scores 2 because the mandate still says “support” rather than “own”, so the roles are written as support roles, so senior people read the job description and decline. Fixing the recruiter changes nothing.
The centre that cannot prove its savings. Value scores 1. Finance wants to know where the money went. The chain runs back to the business case, where the pre-transition baseline was never frozen and the retained organisation at headquarters was never redesigned. Two teams now do one job and the saving was real but is unprovable.
The centre whose quality dropped after transition. Work transition scores 2. It looks like a training issue. The chain says knowledge transfer was gated on the calendar rather than on receiving-team readiness — the sessions ran on schedule into seats that had been filled the week before. The knowledge went in and straight back out again.
In each case the visible symptom sits in a lower layer than the cause. That is not a coincidence. It is what the dependency rule is for.
The point of a model built before a solution
We built this before we designed anything we sell. That order matters, and it is worth saying why.
A framework built after an offer tends to describe the offer. It finds problems the seller happens to solve. Built first, it describes the problem honestly — including the parts nobody can help with, and including the answer “do not build this”.
It also does three jobs at once. It is the instrument we assess with. It is the answer when a buyer asks how do you know what to look for. And it is reusable — the structure carries to the next problem even though the content does not.
A competitor working from a checklist cannot reconstruct it afterwards. That is the test of whether a framework is real.
Where to start
If you run a capability centre, or you are about to build one, the useful first question is not what are we missing. It is what are we assuming, and which layer is it in.
Score your own mandate layer honestly, before anything else. If strategic intent and the business case are both threes or below, nothing you do in the layers beneath them will hold.
Iksula helps retail and consumer brands move commerce operations into a capability centre they own. The 47-issue model above is the diagnostic instrument behind our Commerce Capability Center assessment — five to six weeks, fixed scope, fixed price, and it can conclude that you should not build.
Sources: BCG, Rewriting the Global Capability Center Playbook, June 2025 · Zinnov–nasscom India GCC Landscape 2026 · Everest Group commentary on GCC set-up partnerships.
