KanBo Perspective

The Centres of Excellence Problem

Large organizations do not have a Centre of Excellence. They have five or six, competing for the same specialists and depending on each other without a shared plan. The speed of the enterprise is set by the coordination between them — and that layer is almost never instrumented.

The bargain a CoE makes

A Centre of Excellence exists because some capability is too scarce, too specialised or too consequential to leave scattered across business units. Rather than every unit hiring its own half-competent data engineer, the organization concentrates the capability, raises the standard, and lends it out.

It is a good bargain and it usually works at first. Standards improve. Duplication falls. Career paths appear for specialists who were previously the only one of their kind in a division. The organization gets a place to put its hardest problems.

The bargain has a condition attached, though, and the condition is rarely written down: a CoE only works if the capability it concentrates can be allocated intelligently. Concentrate scarce people and then allocate them badly, and you have built a queue with a nice name.

There is never only one

Here is the part most discussion of CoEs ignores. In a large organization there is never a single Centre of Excellence. There is a portfolio of them, arrived at over a decade, each created by a different sponsor answering a different pressure.

A Data or Analytics CoE. A Cloud or Platform CoE. An Automation or RPA CoE. A Cybersecurity CoE. A Process Excellence or Lean function. A Project Management Office that behaves like a delivery CoE whatever it is called. An ERP competence centre. A Quality or Regulatory CoE in regulated industries. Engineering CoEs in manufacturing. And, arriving now in almost every enterprise, an AI CoE.

Each was set up correctly. Each has its own charter, intake process, delivery method, capacity spreadsheet and definition of done. Each reports to a different executive. And none of them was designed with the others in mind, because each was designed as the Centre of Excellence for its domain.

That is the structural situation this article is about. Not what a CoE should do — there is plenty written about that — but what happens when there are six of them in one organization, drawing on overlapping people and depending on each other to deliver anything of consequence.

The four failures that appear at two

One CoE has a capacity problem. Two or more have a coordination problem, and it shows up in four specific ways.

They compete for the same people, invisibly. A senior data engineer is wanted by the Data CoE for a migration, by the AI CoE for a use case, and by the Cloud CoE for a platform build. Each of the three sees its own claim on that person. None sees the other two. The conflict is discovered when someone is late, and it is resolved by seniority or by volume rather than by priority.

They depend on each other without a shared plan. An AI use case needs data engineering from one CoE, a landing zone from another, a security review from a third, and a process change from a fourth. Each of the four plans independently, each is individually reasonable, and the initiative takes the sum of four queues rather than the length of the longest one.

They describe the same capability in incompatible language. The same engineer is “Data Engineering, Level 3” in one CoE’s spreadsheet, “Senior Data Engineer” in another’s, and “Databricks — advanced” in a third’s. Capacity cannot be summed, skills cannot be searched across the organization, and nobody can answer how much of a given capability the enterprise actually has.

They report in units nobody can add up. One reports utilization against billable hours, another against project count, a third against a maturity model. The group executive asking a reasonable question — what is our real capacity for AI delivery next year — receives three answers that cannot be combined.

None of these is a failure of any individual CoE. Each CoE is optimising locally and doing it well. The failure is that nothing sits between them.

The commons underneath

The specialist pool is a commons, and it behaves like one.

Garrett Hardin’s formulation is the familiar one: when a shared resource is open to independent users each acting rationally in their own interest, the resource is depleted even though depletion serves nobody. Each CoE, entirely reasonably, secures the people it needs for the work it has been asked to deliver. The aggregate is a handful of individuals who appear on six plans, and a bench nobody can see.

The usual corporate response to a commons problem is to centralise — a resourcing committee, a weekly allocation meeting, a single intake funnel for everything. This reliably fails, because it puts allocation decisions in the hands of people who do not understand the work, and adds weeks to every request.

Elinor Ostrom’s Nobel-recognised work is the more useful half of this argument. Studying commons that did not collapse, she found they were governed neither by central command nor by nothing, but by clear boundaries, rules matched to local conditions, visible information about who was drawing what, and the ability of the participants to shape the rules themselves.

Translated: the CoEs do not need a central allocator. They need to be able to see each other’s claims on the same people, in the same units, and to negotiate.

The other half of the bargain

There is a second product a Centre of Excellence makes, and it is the one most CoEs discover by accident rather than design: people.

The pattern is familiar to anyone who has run one. You recruit or develop specialists, they do good work for two or three years, and then they leave — not out of the organization, but into it. They become an operations manager, a supply chain lead, a delivery head in a business unit. From inside the CoE this looks like attrition and is usually treated as a problem to be reduced.

Some of the most durable improvement functions in large industrial groups reached the opposite conclusion. They stopped treating themselves as internal consultancies with a retention problem and started treating themselves as something closer to a university: bring people in, teach them the method properly, have them practise it as internal consultants on real projects, and then deliberately place them into line roles across the group. The departure is the deliverable.

Two things follow, and both matter for how a CoE is designed.

It is the only reliable way to make a method survive its champions. A capability that lives inside a central team disappears when that team is reorganised, defunded, or when three enthusiasts move on. A capability distributed into thirty line managers who have practised it does not. The same logic that argues for putting work context into a system rather than into people’s heads argues for putting capability into the organization rather than into a department.

And it reframes the commons problem. The previous section described rationing scarce capability. This describes manufacturing more of it. A CoE that only allocates is a queue with a nice name; a CoE that also produces trained people is enlarging the pool it draws on. Those are different institutions with different success measures, and most CoE charters only mention the first.

The practical difficulty is that neither the training nor the transfer is visible in any system. Who has actually been taught what, to what level, verified by whom, and when does that certification lapse? Where did they go, and does the business unit that now has them know what they can do? In most organizations the answer sits in a coordinator’s spreadsheet and degrades from the day it is written.

This is where a shared skills vocabulary stops being administrative. A skill carries an ordered set of levels the organization defines itself. Each assignment on a person carries its confidence — self-declared, manager-verified or system-inferred — and its validity dates. That makes a training programme’s output countable: how many people across the group have been verified at a given level, where they now sit, and which certifications are about to expire. Job rotation becomes something the organization can see and plan, rather than something the CoE quietly regrets.

Where the enterprise actually queues

Eliyahu Goldratt’s argument about constraints applies almost embarrassingly well here. The throughput of a system is set by its bottleneck. Improvements anywhere else are local efficiency, not output. And the bottleneck moves, so the useful question is never “are we efficient” but “where is the constraint now”.

In most large organizations pursuing a transformation agenda, the constraint is not budget, strategy or executive attention. It is a small number of named people inside two or three CoEs, and the queues in front of them. An enterprise can approve twenty AI use cases and possess the data engineering capacity to deliver four. The other sixteen do not fail; they wait, quietly, while everyone reports green.

The consequence for anyone running or sponsoring a CoE is uncomfortable but clarifying. Your CoE’s own throughput is not the thing to optimise. The enterprise’s throughput is set by whichever CoE is currently the constraint, and by how much time work spends moving between them. Both of those are coordination problems, and neither is visible in any individual CoE’s reporting.

What has to be shared, and what must not be

The instinct after reading the above is to harmonise everything. Resist it, because that is the other way this fails, and it fails more expensively.

CoEs are different on purpose. A Quality CoE in a regulated manufacturer works under documentation obligations an Automation CoE does not have. A Cloud CoE’s delivery rhythm has nothing useful in common with a Process Excellence function’s improvement cycles. Forcing a common delivery method on all of them destroys the thing that made each effective, and produces what standardisation programmes always produce: a compliant central process, and a real process that everyone runs alongside it.

The shared layer has to be thin and structural. In practice it is five things:

The identity of people, so a specialist is one person across every CoE rather than a row in each of six spreadsheets

A common skills vocabulary, so capability can be counted and searched across the organization

Capacity in common units, so claims on the same person can be seen together

Dependencies between CoEs, expressed as links rather than as assumptions

A shared meaning for progress, so that each CoE’s own stages still roll up to something comparable

Everything else — intake criteria, delivery method, stage names, review cadence, documentation standards, tooling within the domain — stays local, and should.

What KanBo provides: one substrate, several CoEs

What the above describes is a coordination substrate: one place where the structural facts live, while each CoE keeps its own way of working on top of it. That is what KanBo is — a work coordination and resource management platform adopted at organization level, with several CoEs running inside one governed environment rather than one tool per function.

It is worth being concrete about the mechanisms rather than describing the ambition.

Each CoE runs its own spaces, with its own vocabulary. A space is the permissioned container a CoE, a programme or an engagement runs in. Each space defines its own stages in its own words — and every stage is assigned one of five types: Information, Not started, In progress, Completed, Cancelled. That single mechanism is what allows an Automation CoE to run “Assessed → Built → In production” and a Quality CoE to run something entirely different, while a group-level view of progress across both remains exact. Local vocabulary is never taken away; shared meaning is never inferred.

People are one record across all of them. In KanBo a specialist exists once, with their work schedule, their part-time pattern including alternating even and odd weeks, their leave, and the public holidays of their location. Capacity is computed from those rather than typed in. And when a day is unavailable, the reason is reported — a non-working day, a location holiday, personal leave, being outside a contract window, or already being overallocated. Six CoEs looking at the same person see the same availability, and the same reasons.

Skills are a shared vocabulary with real metadata. A skill carries an ordered set of levels that the organization defines itself, so “Novice / Practitioner / Expert” or a one-to-five ladder both work and both compare numerically. Each assignment on a person carries its confidence — self-declared, manager-verified or system-inferred — and validity dates. A certification that lapses stops counting automatically. This is the single most valuable thing to share between CoEs, because it is the only way to answer how much of a capability the enterprise actually holds.

Cost stays separate from capacity. Resource Management permissions are distinct from space permissions, and finance is its own permission area, so CoE leads can plan and allocate without seeing rates. Human and non-human resources are separately controlled as well, which matters where a CoE schedules equipment or test environments alongside people.

Demand before names, across all of them

The mechanism that makes multi-CoE capacity planning possible is the separation of demand from assignment, and in KanBo it has a name: the planned role.

A planned role is a real object on a piece of work: the capability required, how many resources of that profile, how much effort, over which dates — with nobody named. Its state moves from unassigned to partially assigned to assigned as people are matched to it, and it can be marked not feasible.

This sounds like a modelling detail and it is the whole argument. When each CoE expresses its demand as planned roles rather than as names, three things become possible that were not before.

Aggregate demand on a capability becomes visible. Not “who wants Anna” but “how much senior data engineering does this organization need in Q3, across every CoE that has asked for it.” That is the number nobody currently has.

Pipeline stops distorting the picture. Work that has been requested but not approved can be held as provisional demand rather than as a commitment, so prospective claims from three CoEs stay visible in the capacity picture without consuming committed capacity or blocking anyone. The alternative — each CoE informally reserving people against work that may never happen — is how benches become invisible.

Staffing decisions become defensible. Candidates for a planned role are ranked on skill fit, availability and preference, and each result carries its reasoning: which required skills matched, the required level against the actual level, what was exceeded, what failed, and how capacity was covered. Someone missing a required skill is not returned at all. When two CoEs want the same person, the conversation is about explicit trade-offs rather than about who escalated hardest — and the person not selected can be told why.

And allocation is modelled as a negotiation rather than an instruction. A request for capacity can be proposed, accepted or rejected, and whether approval is required is a setting per space. That is the correct model for a multi-CoE organization, where the CoE needs the capacity and somebody else owns it.

Dependencies between CoEs are real objects

The second half of the problem is the handoffs, and it is solved by the same principle: make the implicit thing explicit.

In KanBo, card relations work across spaces, so a piece of work owned by the Data CoE can be recorded as the predecessor of a piece of work owned by the AI CoE. That is not a note in a plan; it is a link, and when a date moves the conflict surfaces rather than being discovered in a steering meeting three weeks later. Where an allocation sits beneath work whose dates have changed, the allocation is marked invalid rather than drifting silently out of alignment.

Blockers are managed objects with a name, a reason and a responsible owner, and they can be defined once and reused across the organization. This is the mechanism that turns the most common complaint in a multi-CoE enterprise into something actionable. “We’re waiting on the platform team” is a sentence repeated in six different steering committees, in six different forms, by people who do not know they are describing the same obstacle. Defined once as a named blocker, it becomes countable: how often it occurs, what it holds up, whose decision would remove it.

That count is the argument a CoE lead needs in front of an executive committee, and it is currently unavailable to almost all of them.

The AI CoE makes this urgent

Every structural problem described so far has existed for years and been tolerated. What has changed is that the newest CoE is the most dependent on the others.

An AI CoE cannot deliver anything alone. A single use case typically needs data engineering from the Data CoE, infrastructure from the Cloud or Platform CoE, a security and privacy review, a process redesign so the output actually changes a decision, and a business unit willing to change how it works. The AI CoE owns none of those and depends on all of them.

Which means the throughput of the AI agenda — currently the most visible item on most executive committees — is not a function of the AI CoE’s capability at all. It is a function of the coordination between five functions, and of whether the constraint among them is visible.

This is the unglamorous reason many AI portfolios stall while every individual team reports progress. Nobody is failing. The work is queueing in the gaps between organizations that each plan independently, and no instrument exists that shows the queue.

What agents change, and what they do not

A word on the thing every CoE is currently being asked about.

An AI agent connected to KanBo over MCP — under a delegated identity holding exactly the permissions of the person it works for — can do a substantial amount of the coordination work that currently consumes CoE leads. What changed this week across eleven engagements. What is blocked and on whom. Which planned roles are still unassigned with three weeks to go. Which commitments made in January have neither moved nor been cancelled. That is collection and correlation across a large surface, done in minutes, interrupting nobody.

What it does not change is the shape of the problem. An agent reasons over what is written down. If demand lives in six spreadsheets with incompatible skill names, the agent inherits the mess and reports it fluently. Every argument in this article is a precondition for the agent being useful, not an alternative to it.

The order is worth stating plainly, because most organizations attempt it in reverse. Make the structural facts explicit first. Add the agent second.

Honest limits

The shared layer is a political negotiation before it is a technical one. A common skills vocabulary means several CoEs giving up their own. That conversation is worth having deliberately rather than discovering halfway through an implementation.

Visible competition for people is uncomfortable. Making aggregate demand visible means someone finds out their initiative is fourth in line. That is better than finding out in September, but it is not painless, and the executive sponsor should expect it rather than be surprised by it.

Capacity data does not create capacity. Seeing precisely that you are short eleven weeks of senior data engineering does not produce eleven weeks. It moves the conversation from dispute to decision, which is genuinely valuable and is not the same as solving the problem.

And measurement becomes a target eventually. The first time utilization figures are used to judge a CoE lead rather than to inform a decision, the figures start being managed. Goodhart’s law is a prediction, not a caution. Use this data to find out where the organization is stuck; the moment it becomes a performance instrument it stops being either.

How to start

Not with all six CoEs, and not with a taxonomy project. Put two of them in KanBo and give it a quarter.

Take the two CoEs that most often block each other. In most organizations that pair is obvious within thirty seconds of asking. Usually one of them is the Data or Platform function.

Express one quarter of demand as planned roles in both. Capability, quantity, effort, dates, no names. This is the step that feels like documentation and is the one that changes the conversation, because for the first time the two CoEs are describing demand in the same units.

Agree a skills vocabulary for the overlap only. Not the whole organization’s taxonomy — just the capabilities both CoEs actually compete for. That is usually a list of six to ten, not sixty.

Record the dependencies between the two as links, including the ones that currently live in a programme manager’s head.

Name the three recurring obstacles that appear in both CoEs’ steering meetings, with an owner each.

Then look at what you have after a quarter: aggregate demand on the shared capabilities, dependency conflicts surfaced rather than discovered, and a countable list of what actually blocks the pair. That is enough evidence to decide whether the third CoE should join, and enough to make the case to whoever will have to approve it.

FAQ

Is this an argument for merging our Centres of Excellence?

No, and merging usually makes it worse. CoEs are specialised for good reasons and a merged super-function inherits every domain’s obligations while serving none of them well. The argument is for a thin shared layer — people, skills, capacity, dependencies, and a shared meaning for progress — underneath CoEs that stay distinct.

We already have a resource management tool. Why is this different?

Two reasons. First, most resource tools model assignment rather than demand: they record who is on what, not what capability is needed before anyone is named, which is where multi-CoE planning actually happens. Second, they sit beside the tool where the work runs, so the plan and the work disagree within a fortnight. In KanBo the engagement and its resourcing are the same record under the same permissions — work coordination and resource management in one platform rather than two that have to be reconciled.

Our CoEs use different delivery methods. Does this force them onto one?

No, and it is designed not to. Each space defines its own stages in its own language; each stage is assigned one of five shared types, which is what allows aggregation without harmonisation. The shared layer is structural, not methodological.

How do we handle CoEs serving different legal entities?

Resources belong to a subsidiary, so multi-company groups are modelled directly rather than by convention, and views can be filtered to a subsidiary. Rates can be attached per business unit or engagement, so the same role is recharged differently without duplicating the role.

Who owns the shared layer?

Someone has to, and it is usually neither the largest CoE nor a new central function. The workable pattern is a small governance group with representation from each CoE, owning only the thin layer — skills vocabulary, status types, the rules of allocation — with each CoE retaining everything else. That is the Ostrom answer rather than the central-committee answer, and it is the one that survives.

Doesn’t a CoE inevitably hoard talent?

It does if its only measure is its own delivery throughput, because under that measure losing a trained specialist is pure loss. The correction is to treat trained people placed into line roles as a deliverable rather than as attrition, and to make that output visible — who was trained, to what verified level, and where they went. A CoE measured on both delivery and capability distribution behaves very differently from one measured on delivery alone.

What is the first sign this is working?

Two CoEs stop discovering the same conflict at different times. When the Data CoE and the AI CoE are looking at the same dependency on the same day, the coordination layer has begun to exist.

Written by KanBo. We build the work coordination and resource management platform described here, which makes this an argument we have an interest in. The structural claims — that a large organization has several CoEs, that they compete for the same specialists, and that the enterprise’s throughput is set by the coordination between them — are worth testing against your own organization before testing any product against them.