Why Your CoE Is Failing — And The One Thing That Fixes It

Centres of Excellence fail more often than they succeed. Not because the people inside them lack talent, and not because the organisations around them lack ambition. They fail because of a structural mistake made before the first hire, before the first governance document, before the first review meeting. A mistake so common it has become the default — and so consequential that almost everything else follows from it.

Understanding that mistake — and the alternative — is the difference between a CoE that elevates a delivery organisation and one that becomes its most expensive overhead.

The symptoms everyone sees — and the cause nobody names

When a CoE is struggling, the symptoms are usually visible. The CoE is technically brilliant but commercially disconnected. It publishes standards nobody reads. Delivery heads tolerate its presence in review meetings but privately consider it overhead. It gets bypassed when deadlines tighten. It measures activity — certifications earned, frameworks documented, training sessions delivered — and mistakes that activity for impact.

The presenting symptoms tend to cluster into recognisable patterns. Structurally: the CoE is positioned too far ahead of the delivery organisation around it, or tied too tightly to delivery operations and loses independence, or too loosely and loses relevance. It carries no genuine authority — existing at the preference of delivery heads who can route around it when convenient. In terms of people: it is staffed with technical champions who lack commercial acumen or real-world delivery experience. On purpose: it has no clarity of goals, no measures of current or future state, and no line of sight from its activities to the delivery organisation's performance.

The result is predictable. Delivery teams experience it as overhead. Finance treats it as a cost centre. Leadership tolerates it because dismantling it would be an admission of failure.

But underneath all of these symptoms, there is almost always one originating mistake. And it is not the one most people assume.

There is also a subtler failure mode that takes longer to surface. Even a well-intentioned CoE has a natural decay curve. It is stood up with energy and purpose during a period of growth or transformation. The founding team is sharp and motivated. The early wins are real. But somewhere along the way, the founding energy dissipates. The champions get pulled into delivery. What remains is the scaffolding — the review boards, the standards documents, the approval gates. The organisation still has a CoE. It just stopped being useful.

A CoE designed for a founding moment rather than continuous relevance will always end up here: a governance body where an innovation engine once stood.

The one thing: start outside the CoE

The CoEs that work share a common founding practice — and it has nothing to do with the CoE itself.

Before a single person is hired into the CoE. Before a single standard is written. Before any governance model or audit framework is designed. The right starting point is to map the delivery organisation's performance across the dimensions that actually matter: project margin, requirements quality, design quality, deliverable quality, tool and process maturity across the delivery lifecycle. Establish a current state baseline. Define what the target state looks like — not as a fixed destination, but as a rolling horizon the organisation is always moving toward, measured at regular intervals.

Then — and only then — build the CoE to close that gap.

This sounds straightforward. It is not common. What it means in practice is that the CoE's entire reason for existing is anchored to the delivery organisation's success, not to its own activity. Every decision the CoE makes — who to hire, what to build, where to focus — flows from a single question: does this make the delivery organisation more likely to succeed?

That is a fundamentally different identity from a rules-and-standards CoE. And identity, decided quietly at the founding moment, determines everything that follows.

What this looks like in practice: Pre-Engagement Alignment

The most effective expression of this philosophy in practice is something called a Pre-Engagement Alignment — a structured preparation ritual conducted by the CoE at the start of every engagement.

Not an audit. Not a gate. Not a compliance exercise. A ritual of preparation — the CoE working for the project team before the project team even starts.

What a pre-implementation analysis covers

1. What the scope actually contains — ensuring alignment before assumptions solidify into architecture
2. Anticipated risks and their mitigation plans — identified before they become crises
3. Skill readiness — whether the team has what the engagement actually requires
4. Reusable assets from past implementations that apply to this context
5. New reusable assets expected to be generated, and how they will be captured
6. Training needs and a plan — specific to this team and this engagement
7. The support the CoE will actively provide throughout the engagement
8. Review cadence and expectations at each milestone — agreed in advance, not imposed after the fact

The early resistance to this approach is predictable and should be expected. Delivery managers will say there is not enough time, that it adds process overhead, that it slows things down. That resistance is understandable — and it fades quickly when the value becomes concrete and undeniable.

A representative example of the kind of value this surfaces: an architect completes a full system design, and the CoE's design review identifies that the solution has not accounted for licensing constraints. That single conversation prevents months of rework that would otherwise surface only at deployment. No process document achieves that. Preparation does.

The authority question nobody discusses honestly

There is something else that distinguishes CoEs that work from those that do not — and most thought leadership on the topic avoids naming it directly.

A CoE without genuine authority is not a CoE. It is a suggestion box.

Nominal sponsorship — a senior leader who endorsed the CoE in principle — is not the same as operational authority. The distinction matters enormously. When the CoE's recommendations create friction with delivery heads, what happens? If the answer is negotiation, bypass, or quiet override, the authority structure is insufficient. The delivery organisation will quickly learn that CoE standards are optional. And once that lesson is learned, it is very difficult to unlearn.

The CoEs that achieve lasting impact have a clear, unambiguous authority structure from day one. Leadership backs CoE decisions — including when those decisions create discomfort. When quality and short-term margin come into tension, quality takes precedence, and that precedence is not subject to negotiation at the delivery level. Exceptions require deliberate escalation and remain rare.

This structure holds firm while the culture catches up. And the culture does catch up — typically within months, not years. Once delivery teams understand that the CoE is not going away, is not going to be overruled, and genuinely exists to help rather than police, resistance softens and a productive working relationship emerges.

The flywheel: how every project makes the whole organisation smarter

When a CoE is embedded in the delivery lifecycle — present at project initiation, present at weekly reviews, tracking maturity across every engagement — something begins to happen that compounds over time.

Each project feeds the CoE with knowledge, assets, and insight. The CoE feeds the next project with that accumulated intelligence. Each cycle, the delivery organisation gets measurably stronger. The reusable asset library grows. Risk anticipation improves. Skill gaps are identified and closed before they become delivery failures. This is not a linear improvement — it is a compounding one.

But the flywheel only works if the CoE is measuring the right things and trusted enough to act on what it sees. This is where the cross-portfolio view becomes uniquely valuable.

No individual delivery manager can see patterns across the full portfolio — they are living inside their own engagements. The CoE, by contrast, sits across all of them. This position, if used well, surfaces structural insights that no other function in the organisation can generate.

What a mature CoE can see — and act on

The patterns this cross-portfolio intelligence surfaces are ones every delivery organisation faces — but rarely has the visibility to diagnose. Three examples that consistently emerge in mature CoE environments:

None of these decisions could be made confidently — or even seen clearly — without the cross-portfolio intelligence that only a well-embedded CoE generates.

The trap of uniform rigour — and the value of contextual judgment

One of the most instructive refinements a CoE can make is moving away from a uniform audit framework — a fixed-point checklist applied identically to every engagement — toward variable weightage agreed with each project team during the Pre-Engagement Alignment.

The impulse toward uniformity is understandable. It feels like rigour. It looks like consistency. But not every project carries equal exposure across every dimension. A complex multi-cloud implementation has different risk characteristics than a focused single-cloud enhancement. Treating them identically creates compliance burden without creating value — and, critically, it signals to delivery teams that the CoE prioritises process over outcomes.

Shifting to contextual rigour — measuring what matters most in each specific engagement, agreed transparently in advance — earns more trust from delivery teams than any volume of standards documentation. It demonstrates that the CoE is capable of judgment, not just rule application.

The decision that determines everything

The CoEs that fail have a rules-and-standards identity. They believe their purpose is to define how things should be done and hold the organisation accountable to those definitions. That identity produces governance bodies — technically correct, operationally irrelevant, culturally resented.

The CoEs that work have a different identity. Their purpose is to make every person, every project, and every engagement more likely to succeed. The standards, the frameworks, the measurements — all of it is in service of that purpose, not an end in itself.

That decision — made before the first hire, before the first document, before the first governance meeting — determines everything that follows. It shapes who gets recruited, what gets measured, how the CoE shows up in a delivery review, and whether the organisation experiences it as a partner or an auditor.

What to do on Monday morning

If you lead a CoE or are about to build one, four things are worth doing before your next team meeting: