Two shifts landed together this year. Skills England's first Annual Skills Report found that demand across priority sectors is expected to grow by around a quarter over the next decade, equivalent to an additional 1.8 million workers, and it identified rapid AI adoption as one of the five challenges the skills system has to answer (GOV.UK). At the same time, the standard of proof for calling a technical team ready has moved away from attendance at training and towards demonstrated competence in the work itself. An organisation loses the option of hiring its way out of a readiness gap, while those that measure properly avoid the far larger cost of discovering that gap after go-live.
Consider the common failure: A readiness pack contains forty pages of completion logs, but no one has observed a single worker perform the job in that room. The decision is made based on the strength of the pack. Six weeks later the same group meets again to work out why the first shift on the new system escalated everything it could not classify.
The sequence below replaces the pack, and the order is important: an early step fixes what the later ones are counting.
Readiness applies to a group, a task, a place and a time.
Technical staff readiness is not a trait within an individual. Four elements must be identified together: the team, the defined task, the environment where that task executes, and the time. Changing any one of the four variables changes the result.
System maturity and human competency move together too. A system is unable to operate at a level of sophistication beyond the procedural readiness of the staff operating it, which is why a strong engineer can look weak on a newly commissioned system and strong on a mature one, with no change to the engineer.
The practical consequence is a test you can apply to any premise handed to you. Phrase it so that a stranger could check it. Ready, on its own, fails that test.
Define the group before you total the people
The second step defines the people included in the application. Define the scope by the work itself; the organisational chart is a poor guide to who does the task. If the task is carried out by operators, contractors and a vendor's support desk, all three are part of the group, and a readiness figure covering only the permanent operators provides no information about the task.
Spartakus Technologies makes a comparable separation in operational readiness. Operational readiness evaluates if an organisation is able to operate a new facility or system safely and efficiently from its first day, a question distinct from whether the project which built it is complete (Spartakus Technologies). Two questions, two populations, two reports.
Set the standards for proof before the proof is received
You now decide what will serve as evidence. Two kinds of evidence carry most of the weight for technical staff:
- Evidence produced within the work itself, documented by a staff member who did not deliver the training.
- Evidence of how the employee acts when the work fails, as well as when it succeeds.
Competency assessment supplies the objective evidence that a worker performs a task correctly and consistently, and it does so through direct observation, practical assessment or documented performance review. The organisation has an assumption where evidence should be. The method must also match the maturity of the system being operated, because one schedule applied everywhere will test unsuitable areas at both ends.
List the requirements first because they limit what can be asserted later. Rules written after the results arrive will fit the results.
National survey figures show certain facts but not others
National data is useful for setting expectations and close to useless for certifying a team, and it is worth being precise about which is which.
Skillsoft's 2025 Global Skills Intelligence Survey, reported by IT Brief, found that one in ten of the HR and learning professionals surveyed were fully confident their employees held the skills needed to meet business goals over the following year or two, and that in the United Kingdom AI skills were identified as the largest single gap (IT Brief). The same survey found that a fifth of UK talent overstate their technical skills, and that fewer than one in five organisations use regular skills assessments to measure whether development work has had any effect. Keep that overstatement figure. Self-assessment should not be the main proof for any readiness case you intend to defend if it is the norm.
The Employer Skills Survey 2024, published by the Department for Education and Skills England and built on interviews with 22,712 employers, found that 12 per cent of employers had at least one member of staff judged not fully proficient, equivalent to 4.0 per cent of the workforce (Employer Skills Survey 2024). Cornerstone's research, reported by Channel Life, found that 63 per cent of UK executives believed their workforce was unprepared for change while 45 per cent of employees reported lacking the support and resources to adapt, that where 77 per cent of employers thought their workforce received adequate training 40 per cent of employees agreed, and that 51 per cent of employees did not believe their employer tracked skills effectively (Channel Life). The CIPD's skills factsheet reports that up to a third of UK workers will need to reskill within five years, and that one in ten workers say they lack all the skills needed to do their job effectively (CIPD).
Read together, these establish that the problem is common, that employer and employee judgements diverge sharply, and that self-report is unreliable. None of them is a readiness check for your team. Quoting them into a go-live decision confuses a population statistic with a piece of evidence.
Tools are compared on what they grade and what they accept
Every tool has a blind spot. The question is whether its blind spot is the factor your decision depends on.
| Instrument | What it grades | What it accepts as evidence | What it leaves unanswered |
|---|---|---|---|
| Training completion record | Attendance and exposure | Registers, course completions, e-learning logs | Whether the person can perform the task |
| Self or manager rating | Perceived confidence | Questionnaire, appraisal conversation | Whether the perception is accurate |
| Knowledge or certification test | Recall and recognition | Exam results, certificate | Performance under real conditions and real pressure |
| Supervised observation in live work | Performance on the actual task | Assessor record, work output, deviation log | Performance outside the observed conditions |
| Post-go-live monitoring | Sustained performance | Ticket volumes, error rates, rework | Cause, unless paired with observation |
A knowledge test is unable to answer a question about behaviour under load. Observation in one site does not answer a question about a second site. Monitoring does not explain why the figures changed. Select the tool whose gap is furthest from the decision, and state in the report which gap you are accepting.
Set the threshold from the decision, and name its owner
A threshold is a value that belongs to a decision, and every decision has an owner. The staff member who suffers the effect of a mistake is the officer authorised to define the criteria that must be met before the choice is made. A benchmark answers a different question because a benchmark represents a population.
A usable threshold defines the task, the condition and the time. The table below sets three ways of writing one against what each can carry.
| How the threshold is written | What it fixes | What a reader can still not check |
|---|---|---|
| Staff are trained | That training took place | Whether anyone can perform the task |
| The team is ready | Nothing | Who is in the team, at what work, in what place, by when |
| Every member of the on-call rota completes a failover unassisted on the live system before the end of the quarter | The population, the task, the condition and the date | Whether the assessor was independent of the training |
The third row is the shape to aim for, and the last column is the reason the threshold has to be written down by the owner and dated before the assessment starts. A threshold chosen after the results arrive will be chosen to fit them.
Run the evaluation on the work itself
A classroom observation shows what a teacher is able to do in a classroom. Strong proof is produced where the work is done, on the equipment the team will use, under the conditions the team will meet.
Sampling determines the value of the result. One operator observed on a quiet day says very little about a rota. Sample across the shifts, across the failure modes the design team considers most likely, and across the handover points, because handover is where readiness tends to fail first.
The assessor needs a defined relationship to the team. A log made by the trainer invites the challenge it will not survive, because that trainer has an interest in the training having worked. An external assessor, briefed on the evidence criteria and the threshold, produces a report that is valid. If no such employee is available, the report says who assessed and what else that employee does.
Every observation produces a log of what happened, including the parts that did not go to plan. The deviation log is the most useful document the exercise produces, because it lists the conditions the team has not yet met.
What the finished evaluation has to say
An evaluation is incomplete if an external reviewer is unable to verify the results. The document identifies the group, the piece of work, the environment and the time. It states the threshold that was applied and the user who set it. It cites the evidence and identifies the assessor's relationship to the training that preceded it. It records the blind spot the tool leaves, and the reason that blind spot is away from the decision. It states the conditions under which the fact ceases to be true, such as a change of system version, a change of shift pattern or the departure of a specific individual.
A premise containing all of that is still only as good as its time. Staff move, systems get patched, and an environment that was stable in March can be under change in June. Perform the evaluation again when the system changes, and log beforehand which changes trigger the re-evaluation.
None of this makes a team ready. It makes the fact verifiable, and a verifiable fact is the only result an evaluation can provide to the decision maker.
