Most VR training pilots follow the same arc. A team gets budget for a proof of concept, a studio builds a polished scenario, everyone puts on the headset at the demo, and the room is impressed. Six months later the headsets are in a drawer and the project is "under evaluation".
I've built training simulators for defense and healthcare, and the failed pilots I've seen up close never failed on the VR part. Tracking worked. The scenario looked good. People enjoyed it. The pilot stalled anyway, for reasons that were all decided before the first line of code.
The demo was the deliverable
A pilot built to impress at a demo optimizes for the wrong thing. It front-loads visual polish and scripts one perfect path through the scenario, because that's what shows well in a ten-minute session with a director watching.
But a rollout doesn't need one perfect path. It needs twenty mediocre trainees doing unexpected things, a way to add scenario variations without calling the studio back, and someone in the training department who can run a session without a technician in the room. None of that appears on a demo checklist, so none of it gets built.
Nobody owned the numbers
Ask what the pilot was supposed to prove and you'll usually hear "that VR training works". That's not a claim you can verify with a headset and goodwill.
The pilots that made it to a rollout had a boring metric attached from day one: time-to-competence against classroom training, error rates on a specific procedure, instructor hours saved per cohort. The data pipeline that captures those numbers (session logs, scores, completion states, exported somewhere a training manager actually looks) is unglamorous backend work. It's also the only thing that gets a second budget approved.
The content pipeline was an afterthought
One scenario is a demo. A training program is a library of scenarios that changes as procedures change. If every update means a new contract with the original studio, the cost per scenario stays fixed at "custom software project", and the program quietly dies at the second invoice.
The fix is architectural, not artistic: build the scenario logic as data, not as code. Configuration for room layouts, procedure steps, failure triggers, scoring rules. Then the second scenario costs a fraction of the first, and the tenth costs almost nothing.
What I'd check before building anything
- A named owner on the client side whose job improves if the rollout happens.
- One measurable claim the pilot must prove, agreed in writing, with the data capture to back it scoped into the build.
- A second-scenario plan: who authors it, with what tool, at what cost.
- A no-technician test: can a trainer run a full session alone by week two?
If a pilot can't answer these, the headset content doesn't matter yet. That conversation is uncomfortable at kickoff and much cheaper than having it at the post-mortem.