Somewhere in your organisation, a project is running. Someone senior asked a question — what are our people actually capable of, and what will they need next — and the honest answer was that nobody knew. So a project was opened. There is a budget, a steering committee, probably a consultancy.
The work is real. Interviews across departments. A taxonomy of several hundred skills, named and defined so that the same word means the same thing in manufacturing and in commercial. Proficiency levels, so that "advanced" is not an opinion. Skills attached to roles, at the right level. Then assessment: self-evaluation, manager review, and the long reconciliation of the two, because they disagree constantly. Then governance — who owns this, who updates it, on what cycle.
In a large organisation, that is well over a year of work.
And here is the uncomfortable part. When it is finished, some of it will already be wrong.
Not because it was done badly. Because the roles mapped early in the project have changed by the time the project ends, and the taxonomy was written before anyone knew what those roles would become.
The assumption nobody states
Every skills mapping methodology rests on an unstated premise: that jobs hold still long enough to be described.
That premise held for a long time. A competency framework reviewed every three years was a reasonable approximation of reality, because reality moved at roughly that pace. The method was not wrong. It was well matched to its conditions.
The conditions changed. Roles are now being rewritten faster than the review cycle of the framework meant to describe them — not in exotic functions, but in finance, in quality, in regulatory affairs, in sales. What a regulatory affairs specialist needs to know today is not what the same job required three years ago, and it is not what it will require in two.
This produces a specific and demoralising experience, and it is the one we hear most often from the people running these projects: the sense of never catching up. Not that the work is too hard. That it does not converge.
The standard we apply to capital
No chief financial officer would present a nine-month-old balance sheet as the current position, and no board would accept it. Finance is not a project that produces a picture and stops — it runs continuously, and it can answer on demand. We hold capital to that standard. We hold capability to the opposite one.
The problem is not the framework. It is that nothing closes the loop.
This is the part worth sitting with, because it determines whether the next attempt works any better than the last.
The instinct, when a skills mapping exercise ages badly, is to conclude that the exercise was flawed — the taxonomy was too granular, or not granular enough, the assessment method was too soft, the consultancy did not understand the business. So the next attempt is better designed, and it ages the same way, because the ageing has nothing to do with quality.
The second instinct is to automate it. Infer skills from job history, from project assignments, from the tools people use. This is a real improvement, and the major HR platforms now do it. It changes how quickly the record can be populated and refreshed — a picture every quarter rather than every eighteen months.
But a faster picture is still a picture. Whether the skills sit in a spreadsheet or in a well-maintained database, whether they were entered by hand or inferred automatically, the record describes a state. It does not act on it.
And acting on it happens somewhere else entirely. The gap is identified in one system; the learning that might close it lives in another; and nothing carries the result back. Nobody re-measures to find out whether the gap actually closed. The record ages, someone notices, and the refresh cycle starts again.
That is the loop that does not close, and it is why better frameworks and faster inference both help without solving the problem. What is needed is a process with no completion date: measure capability, notice where the gap has opened, close it, then measure again to confirm it closed. The output is not a framework. It is a current answer, available on the day the question is asked.
It is worth being clear that this is not what existing systems were designed for. A learning management system was built to distribute content and record who completed it. Distribution is not measurement, and adding measurement to a distribution system is not a feature you bolt on. It is an architecture.
What this changes in practice
None of this argues against skills frameworks. A taxonomy is still necessary — you cannot measure a gap without a shared vocabulary for what is being measured.
What it argues against is treating the framework as the deliverable. Three practical consequences follow.
Build the taxonomy to be revised, not to be finished. If revision is a workshop cycle, it will happen once and then stop. If revision is continuous and low-effort, the framework stays alive.
Separate the vocabulary from the assessment. The taxonomy is relatively stable; the assessment of who can do what is not, and it needs to refresh on a completely different rhythm. Projects that couple them tightly are the ones that go stale fastest.
Ask what happens after the gap is identified. This is the question most skills programmes answer last and should answer first. If the answer is a report that goes to someone else, the loop is already open.
The question, in five years
We think that by 2030, a company will answer "what can our people do, and what will they need to do next?" with the same confidence it answers what is in its accounts — not because someone ran a better project, but because the question stopped being a project.
Until then, the more useful question for anyone running a skills mapping exercise is not whether the framework is good. It is how old the answer will be on the day someone needs it.
