You built the capability heat map. Financial management came out a Valley: efficient, not excellent, no more budget until something else changes. You walked the steering committee through the logic, and nobody argued.
Three weeks later, someone pulls up the sector reference model beside your heat map in a governance review, the Higher Education Reference Models (HERM), in this case, though any sector's version works the same way. There it is: Financial Management, filed under a block labelled Enabling Capabilities. Nobody argued about that one either. But two segments over, a different block is labelled Core Capabilities, and sitting inside it is Curriculum Design, the exact capability your own contour just called a Plateau this cycle, because this year's differentiation lives in employer partnerships, not curriculum.
Someone asks the obvious question. Didn't we just agree Curriculum Design wasn't core?
Nobody in that room is wrong. Your heat map is right. The reference model is right. The word sitting between them is doing two jobs, and nothing on either document tells you that.
Two Questions, One Word
A reference model's "core" answers a structural question: does this capability sit directly in a value chain, the sequence through which the institution actually delivers its mission, or does it run the institution generally? Curriculum Design sits inside Learning & Teaching. Every institution using HERM files it the same way, forever.
This isn't a quirk of one vendor's taxonomy. The Business Architecture Body of Knowledge (BIZBOK) draws the same line under its own name: a top tier of customer-facing capabilities, a bottom tier that keeps the business functioning behind the scenes. Different standards, but the same underlying axis.
Your heat map's "core" is answering a completely different question: given how you're choosing to win this year, how much does this capability deserve? That question has its own pedigree. Geoffrey Moore called it core versus context decades before anyone was drawing capability maps, and it was never about where something sits on an org chart or a reference model. It was always about where you've decided to be exceptional.
Neither question is wrong. They just aren't the same question, and English only gave us one word for both of them.
Why This Bites
Watch what happens when a capability moves. Business Intelligence and Reporting sits under Enabling on HERM, filed inside Information Management. It keeps the institution running; it doesn't belong to a value chain. But say your strategy this cycle depends on spotting which students are drifting before they fail: personalised support, at scale. Suddenly the capability the reference model quietly filed under supporting infrastructure is the one carrying your entire competitive claim. It's structurally Enabling and strategically a Peak, at the same time, and both labels are correct.
Curriculum Design runs the other way. Structurally Core, because every university designs curriculum and HERM says so. Strategically a Plateau this cycle, because your differentiation isn't there this year. You need it reliable, not exceptional, and the resources it would take to make it exceptional are better spent where your how-to-win actually lives.
A capability can be structurally core and strategically ordinary at the same time, and neither fact is wrong.
This isn't a higher-education quirk either. The same collision shows up wherever a sector reference model meets a strategy conversation. Financial management sits under Enabling or Supporting on nearly every capability model, in every sector. Strategically, it's a Valley for a hospital and a Peak for a bank, and the reference model has nothing to say about which, because it was never built to answer that question.
What to Do With This
Two moves, and neither costs you a rebuild.
First, when "core" comes up in a room and two documents seem to disagree, ask which question is actually being answered before you treat the disagreement as real. Most of the time it isn't a disagreement. It's two instruments measuring different things with the same label.
Second, keep the vocabularies separate on purpose. Let the reference model keep its own word (Core, Enabling, Supporting, whatever your model calls it) and give the strategic tier a name that can never be mistaken for the map. Peak, Plateau, Valley works because nobody has ever printed those words on a HERM poster. If your organisation is still using "core" for both jobs, that's the one thing worth fixing before your next capability conversation, and it's a rename, not a redesign.
| Axis | Question it answers | Changes when? |
|---|---|---|
| Map placement | Does this sit in a value chain, or does it run the institution? | Never. Fixed by the reference model. |
| Strategic tier | Given this strategy, how much does it deserve? | Every time the strategy changes. |
| Maturity | How well is it actually performed, versus how well it needs to be? | Continuously, on the assessment cycle. |
| Gap diagnosis | Once current falls short of required, what kind of problem is it? | Per finding. |
Four questions. One capability can answer all four differently, and every answer can be correct.
The practitioners worth listening to in that room aren't the ones with a better model. They're the ones who can tell you, before an argument starts, which question "core" is being asked to answer.
If your last two capability conversations disagreed about what "core" means, send this to whoever ran the earlier one.
This post draws on the Capability Maturity pillar and the reference-model literacy taught in Building the Common Language.