Most upskilling programs are scoped the wrong way round. Someone reviews what is available, picks a reasonable-looking set of courses, and assigns people to them.
That produces a program shaped by a catalog rather than by the shortage it was meant to address. The alternative is slower to start and considerably faster to finish.
Start from the vacancy, not from the curriculum
The scoping question is not "what should our workforce learn". It is "which roles can we not fill, and what is the shortest honest path from someone we already employ to someone who can do that job".
Everything else follows from that. The roles determine the competence standard, the standard determines the content, and the gap between the standard and your existing workforce determines the sequence and the timeline.
A program scoped from a catalog trains people in what was available. A program scoped from a vacancy trains them in what is missing. Those are almost never the same set.
Before any of this, confirm the vacancies are actually a capability problem rather than a pay, process or conditions problem. That diagnostic is covered in a companion article and it takes about a week. Skipping it is the most expensive shortcut available.
Step one: name the roles
Not skill areas. Roles, with titles, headcount and dates.
"We need more automation capability" cannot be scoped. "We need four controls engineers on line three by Q3 next year, and two more when the second line commissions" can.
For each role, capture what the person does day to day, what they must be able to do unsupervised, what they need to recognise and escalate, which systems and equipment are specific to you, and whether any part of it is regulated.
That last item is not a formality. If the role requires a licence, a certification or a statutory competency, the program prepares people for that pathway and does not replace it, and the plan needs to show the credential route explicitly.
Step two: find who is one step away
This is the step most organisations cannot perform, because they do not know what their own workforce can do.
The record usually holds job titles and formal qualifications, which is a poor proxy. The maintenance technician who taught themselves PLC programming, the lab assistant with a half-finished bioinformatics qualification, the process operator who has been the informal expert on a piece of equipment for nine years, are all invisible to a system that stores titles.
Three ways to surface them, in ascending order of effort and value.
Ask the line managers. They usually know. It takes a short structured conversation per team and it is the cheapest thing in this article.
Open the program to self-nomination. People know what they have been teaching themselves, and self-selection into a demanding program is itself a signal worth having.
Assess against the standard. Once the competence standard exists, a short diagnostic tells you where people actually sit, which is frequently not where the org chart implies.
The output is a shortlist with a realistic distance for each person: one step, two steps, or not a candidate. Being honest in that third category is a kindness. Enrolling someone in a program they cannot complete wastes their time and damages the program's credibility with everyone watching.
Step three: define the standard before the content
Write down what a person who has completed this program can do, in terms someone could verify.
Not "understands industrial control systems". Something closer to: can configure and commission a PLC on this equipment class, can diagnose and resolve the common fault modes unsupervised, can read and modify the existing control logic, knows which conditions require escalation and to whom.
This does several things at once. It makes the program assessable, which is the subject of a companion article on measurement. It makes the content selection obvious, because anything not serving the standard is optional. And it forces the disagreement to the surface early, which matters, because the operations lead and the L&D lead frequently have different pictures of what "trained" means and normally discover this at the end.
Step four: decide what gets built with your own specialists
Roughly, program content divides in three.
The fundamentals, which are the same everywhere. Semiconductor physics, control theory, molecular biology, power systems. No reason to build these yourself.
The applied layer, which is field-specific but not company-specific. Wafer fab process steps, industrial automation practice, bioprocessing operations.
The specific layer, which is yours alone. Your equipment, your process windows, your quality system, your failure modes, your regulatory environment.
The third layer is where generic training fails, and it can only come from your own people. This is not a small ask: it means your senior specialists spend real hours on program design, and their time is the most expensive input in the whole project.
It is also the input that decides whether the program produces people who can do the job or people who have passed a course. Budget it properly rather than hoping it happens in spare time.
How programs get scoped with partners
Astra Trainer works across ten domains and ninety-one directions, from chip design and semiconductor manufacturing to bioprocessing, grid engineering, industrial automation and applied machine learning. Directions are programs rather than course lists: scoped, sequenced and staffed with the partner's own specialists.
The conversation starts with the roles, in the form described above. Name the positions you are hiring for and the tracks get mapped onto them, with the fundamentals and applied layers already built and the specific layer developed with your engineers. Partners commonly start with a pilot on a single direction before committing to a pipeline across domains. You can see the ten domains here.
Step five: sequence it, and be realistic about the timeline
Order the content so that each stage is usable on the job. This matters more for completion than almost anything else, because a learner who applies something in week two has a reason to continue into week three.
On timelines, the honest numbers are longer than the ones in the business case.
A single additional competence for someone already in an adjacent role can be weeks. A genuine role change, such as a maintenance technician to a controls engineer, is months. A fundamental transition into a new technical discipline is a year or more, and pretending otherwise produces a program that fails publicly at the point the first cohort is supposed to be deployable.
Build the deployment date backward from a realistic curve and, where you can, stage it: people become useful at intermediate points rather than all at once at the end.
Step six: secure the time before you secure the budget
The most common way a well-designed program dies is that the money was approved and the hours were not.
Executive sponsorship does not create time. The shift supervisor accountable for throughput will protect throughput, entirely rationally, unless training hours are visible in the number they are measured on.
So before the contract: agree how many minutes per day or per week, get it into the operational plan, and make it explicit in the manager's targets. If that conversation fails, the program will fail too, and finding out now is much cheaper than finding out in month four.
This is where lesson format becomes an operational question rather than a preference. Five minutes fits into a shift change. Two hours requires someone to cover a position. The first is a scheduling note and the second is a staffing decision, and programs built on the second need far more organisational commitment to survive.
Pilot design, and what a pilot is for
Most partners should start with one direction and a small cohort. A pilot exists to answer questions, so decide in advance which ones.
Does the time actually exist? The real answer, from real weeks, not from the plan.
Does the standard survive contact with the operation? Frequently the defined competence turns out to miss something the job requires, and you would rather learn that with eight people than eighty.
Where do people stall? There is usually a specific module where a cohort slows down, and it is usually fixable.
Does the specific layer hold up? Ask the first cohort what was missing when they tried to apply it.
Choose a cohort that is representative rather than the eight most motivated people available, because a pilot staffed entirely by enthusiasts tells you nothing about the rollout.
Three scoping decisions that reliably produce failure. Training a large group when only a few will have roles to move into, which produces qualified people with nowhere to go and an attrition problem you created. Setting a deployment date from the business case rather than from a competence curve. And approving budget without securing manager-level time, which is the single most common cause of a program that is bought, launched and quietly unfinished.
The questions that kill a bad program early
Ask these before signing anything. Each one has ended programs that should have ended.
What specific roles does this fill, and how many? No answer means the program is content-led.
What can a graduate do that they cannot do now, stated so someone could test it?
Who exactly are the candidates, by name? If the list does not exist, step two has not been done.
What happens to them when they finish? A role, a pay band, a progression. Without it you are training people for someone else's vacancy.
Which of our specialists is contributing to the build, and how many hours? If the answer is none, the specific layer is missing.
How many minutes per week, and has the line manager agreed to them?
What would tell us in eight weeks that this is not working? A program with no early failure signal will run to the end of its budget regardless of whether it is succeeding.
What to take from this
Scope backward from unfilled roles, named and counted, not forward from a catalog.
Find the people one step away, which usually requires asking managers rather than querying a system.
Write the competence standard before choosing content, in terms someone could verify.
Put your own specialists into the build and budget their hours honestly, because the company-specific layer is the part that decides whether graduates can do the job.
Secure the time before the budget. And run a pilot with a representative cohort, with the questions written down in advance.
Where should scoping start?
With named roles, headcount and dates. "More automation capability" cannot be scoped; "four controls engineers on line three by Q3" can.
How do we find internal candidates?
Ask line managers, open the program to self-nomination, and assess against the standard. HR records hold titles and formal qualifications, which miss most of what people have taught themselves.
How long does an upskilling program take?
An additional competence for someone in an adjacent role can be weeks. A genuine role change is months. A fundamental discipline transition is a year or more. Deployment dates set from the business case rather than a competence curve are the common failure.
Should we pilot first?
Almost always, with one direction, a representative cohort rather than the most motivated volunteers, and the questions you want answered written down before it starts.
How do programs get built with partners?
Fundamentals and applied layers already exist across ninety-one directions; the company-specific layer is built with your own specialists. Astra Trainer scopes from the roles you name, and you can see the ten domains here.