Book a Demo

Scaling VR Training Across Multiple Plants: What Breaks Between One Site and Ten

Rishab Kapur
Rishab Kapur
8 September 2026
Scaling VR Training Across Multiple Plants: What Breaks Between One Site and Ten

"Almost every VR training programme works at the first site. The interesting question is what happens at the fourth.

A single-site pilot has advantages that are easy to miss. The people who built it are nearby. The champion is on the floor every day. The scenarios were built with the operators who will use them. Problems get fixed by walking over to someone.

None of that survives the move to ten sites. The champion is now a corporate function with a travel budget. The scenarios were built around one plant's equipment, and the other nine have different layouts, different machines and different procedures. Local training teams have their own ways of doing things and no particular reason to adopt someone else's.

Programmes stall here more often than they stall at the pilot. The failure is not technical. It is a design problem that should have been solved before the pilot ran.

Key takeaways

  • Scaling failures are organisational and structural, not technical.
  • Design content as a core plus site-specific variants rather than rebuilding per plant.
  • Local ownership decides adoption, so build it in early rather than mandating from the centre.
  • Standardise assessment criteria even where environments differ, or cross-site comparison becomes meaningless.
  • Plan governance for content updates before you have forty modules across ten sites.

Content architecture is the decision that determines everything

The single most consequential choice is how content is structured, and it needs to be made before the pilot rather than after.

Fully generic content is fast to deploy and cheap to maintain. It teaches principles in a representative environment. It also transfers weakly, because operators recognise immediately that this is not their plant, and the psychological distance undermines the whole advantage of VR.

Fully site-specific content transfers strongly and costs a great deal. Ten plants means ten builds, ten maintenance streams, and a change to a common procedure means ten updates.

A core plus variants architecture is what works at scale. Build the procedure, the assessment logic, the interaction model and the decision points once. Then vary the environment, the equipment models, the layout and the site-specific procedural details per plant.

Roughly, this means seventy to eighty percent of the build is shared and twenty to thirty percent is local. A new site becomes an environment and configuration exercise rather than a new development project, which changes both cost and timeline substantially.

To make this work, the pilot must be built with the architecture in mind. A pilot built as a one-off, hardcoded to one plant, cannot be retrofitted into a platform without significant rework. This is the most expensive mistake in multi-site VR programmes and it is made routinely.

Standardise the assessment, localise the environment

There is a real tension between local relevance and group-level comparability, and it resolves cleanly if you separate the two layers.

The environment should be local. Operators should recognise their equipment and their layout.

The assessment should be identical. The same competency criteria, the same scoring logic, the same pass threshold, the same critical failure conditions. If site A judges LOTO competency differently from site B, the group has no basis for comparing safety performance, and the data that made VR attractive in the first place becomes noise.

Where procedures genuinely differ between sites, that is worth examining directly. Sometimes there is a good engineering reason. Often it is historical drift, and the process of building standardised training exposes it. Several organisations have found that harmonising procedures was a larger benefit than the training itself.

Local ownership beats central mandate

A corporate function can require sites to deploy VR training. It cannot make them use it well.

The pattern that works is to identify a local owner at each site early, involve them in scenario validation for their plant, and give them enough control that the programme feels like theirs. Local subject matter experts should review and sign off the content for their site. Their equipment, their procedures, their names on it.

This has a second benefit. Local SMEs catch errors that a central team cannot. A procedure that is written one way and performed another. A guard that was modified two years ago. A hazard specific to that plant's layout. Content that has been through local validation is more accurate and, more importantly, is defended locally when someone questions it.

The sites that resist hardest are usually the ones that were told rather than asked. Sequencing the rollout so that early adopters succeed visibly, and letting other sites see the results, works better than a directive.

Rollout sequence

The instinct is to start with the largest site or the one with the worst safety record. Neither is usually right.

Start where the conditions favour success. A site with an engaged EHS lead, reasonable IT support, a training need that is genuinely urgent, and leadership that will make time for it. The purpose of the first two sites is to produce evidence and to shake out the deployment process, not to fix the hardest problem.

Then expand in waves rather than all at once. Each wave should be small enough that the central team can support it properly, and spaced so that lessons from one wave inform the next. Sites in wave three benefit from a deployment playbook that did not exist during wave one.

Document that playbook as you go: hardware setup, network requirements, room configuration, facilitator briefing, scheduling templates, communication material and troubleshooting. By wave three this should let a site deploy largely independently.

Governance for content that does not stand still

Procedures change. Equipment is replaced. Regulations update. Incidents generate new training requirements.

With one module at one site, updates are informal. With forty modules across ten sites, you need a defined process, and organisations that skip this end up with content that has quietly diverged from the actual procedure. Training that teaches an outdated procedure is worse than no training.

Decide who can request a change, who approves it, how urgent safety-critical updates are handled, how often content is reviewed on a scheduled basis, and how version control and deployment work across the estate. Tie content review into management of change, so that a procedural change automatically triggers a review of the training that teaches it.

Measurement across a portfolio

Group-level reporting is where multi-site VR earns its place with senior leadership, and it requires a small number of consistent metrics.

Coverage, meaning the percentage of the required population trained and current, by site. Competency, meaning assessment performance by site and by module. Time to competency for new hires. And correlation with the safety and quality indicators the organisation already tracks.

The value of consistency is comparison. When one site's operators consistently underperform on a specific module step, that is a finding with an owner and an action. When every site fails the same step, the problem is the procedure, the equipment or the training design, and it has just been identified across the whole group at once.

Frequently asked questions

How much does a new site cost once the core content exists?
Substantially less than the first build, typically a fraction of it, because only the environment and site-specific configuration change. The exact figure depends on how different the site's equipment and layout are.

Should every site have its own headsets?
Generally yes for sustained programmes, because travel and scheduling otherwise limit usage. Shared pools work for low-frequency, high-complexity modules delivered at a central training centre.

What if our sites use genuinely different equipment?
Then the environment layer differs and the procedural core may too. This is a content architecture question worth resolving early, and it often reveals opportunities to standardise equipment specification as well.

How do we prevent local teams from ignoring the programme?
Local ownership, visible early wins, and metrics that leadership actually reviews. Mandates without any of those three tend not to survive contact with a production schedule.

If you are planning a multi-site rollout and want the content architecture designed for it from the start, EDIIIE can work through the structure before development begins."