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.
Questions we hear often
How long does it take to build a skills framework?
In a large organisation, typically more than a year. The work includes defining a taxonomy of several hundred skills, setting proficiency levels, mapping skills to roles, and assessing people against the result. The duration is the problem: roles mapped early in the project have often changed by the time it ends.
Why do skills frameworks become outdated so quickly?
Because the method assumes jobs hold still long enough to be described, and they no longer do. A framework reviewed every three years was a reasonable approximation when roles changed at that pace. Today roles are rewritten faster than the review cycle of the framework meant to describe them.
What is the difference between a skills taxonomy and a skills framework?
A skills taxonomy is the vocabulary: the list of skills, how they are named and defined, and how they relate. A framework adds proficiency levels and maps skills to roles. The taxonomy is relatively stable; the mapping and the assessment of who can do what change much faster.
Can AI automate skills mapping?
Yes, and the major HR platforms now infer skills from job history, project assignments and tool usage. This changes how quickly the record can be populated and refreshed. It does not change what the record is: a description of a state, which still has to be acted on somewhere else.
What is a skills gap analysis?
It compares the skills an organisation has against the skills its roles require, and identifies the difference. The analysis is only useful if something closes the gap and something re-measures afterwards to confirm it closed — which is the step most skills programmes leave out.
How often should a skills framework be updated?
Any fixed review cycle is the wrong answer to this question, because the answer ages continuously rather than on a schedule. The more useful question is how old the picture will be on the day someone needs it, which points toward continuous measurement rather than a periodic refresh.
