There is a headset in a cupboard in your building. Eighteen months ago it was the most exciting thing in the company. Nobody can tell you exactly when people stopped using it.
I have watched this happen from three sides. As a researcher who studies why people feel present — or nauseous — in virtual environments. As an engineer who used to lead teams shipping software. And as a co-founder of a VR studio that had to make immersive products people actually returned to.
The pattern is remarkably consistent, and it is almost never what the post-mortem says it was.
The post-mortem says the technology wasn't ready. The headsets were heavy, the tracking drifted, the software was clunky, we were too early. It's a comfortable conclusion, because it means nobody made a bad decision — the future simply hadn't arrived yet.
The evidence says something much less comfortable.
What actually blocks XR, according to the people doing it
A 2026 study of industrial XR readiness interviewed seventeen experts across automotive, healthcare and energy — a mix of adopters, technology developers and systems integrators. It asked them what stops immersive projects from reaching production.
Organisational and change-management barriers were named by fifteen of seventeen. Financial and ROI-measurement barriers by twelve. User resistance by eight.
Technology came last. Seven of seventeen.
The authors put it plainly: "organisational and financial barriers, not technological limitations, constitute the binding constraints." Their headline claim is that the overwhelming majority of industrial XR projects end up in a kind of permanent waiting room — technically successful, strategically stranded. (That specific figure comes from a small qualitative sample, so I'd treat it as what practitioners report rather than a measured rate. The barrier rankings are the robust part, and they are damning enough.)
Sit with the implication for a moment, because it reframes the entire purchasing decision.
If the binding constraint is organisational, buying more engineering cannot fix it. And an XR development studio is, by definition, engineering you are buying.
This is not a criticism of XR studios. Many are excellent at what they do. It is a mismatch problem: you have a scoping, measurement and change problem, and the market's default answer is to sell you a build. So you buy a build, it works exactly as specified, and it still dies — because the thing that was going to kill it was never in the specification.
Failure one: you started from the capability, not the problem
Most XR programmes begin with a sentence like "we should look at what VR could do for us." It sounds responsible. It is actually backwards, and it is the single most reliable predictor of a stalled pilot.
Starting from the capability means you go looking for a place to apply it. You will always find one — there is no process in any organisation that cannot be rendered in 3D. But "this works in VR" and "this is better in VR" are entirely different claims, and the pilot is usually only ever asked to prove the first.
The problem-first version starts somewhere unglamorous: a number that is wrong. Induction takes eleven weeks and we need seven. Nine percent of new technicians fail the competency assessment first time. We fly two specialists to remote sites forty times a year. Now you have a target, a baseline, and a way to know whether anything changed — and XR either beats the alternatives at moving that number, or it doesn't.
The study's own top recommendation is exactly this: "problem-first scoping" over "capability-driven pilots."
Failure two: nobody agreed the number before the build
Twelve of seventeen experts named financial and ROI measurement as a barrier. In my experience this is rarely because the value isn't there. It's because nobody wrote down what they were measuring, so at renewal there is nothing to point at except enthusiasm.
Enthusiasm has a half-life of roughly one budget cycle.
You cannot retrofit a baseline. If you did not measure how long the task took, how often it was done wrong, or what the rework cost before the headsets arrived, then twelve months later you have anecdotes and a satisfaction survey. Everyone loved it. Nobody can prove it paid.
Search "VR training ROI" and you will find a great many calculators, almost all published by companies that sell VR training. Some of the underlying research is sound. But a number produced by a party with an interest in the answer is a starting hypothesis, not a business case. The only ROI figure that will survive a finance review is one measured in your building, against your baseline, on your people.
Failure three: the operational cliff
This is the one that ambushes even well-scoped projects, because nothing in the pilot phase warns you it is coming.
Five headsets in a meeting room and three hundred across nine sites are not the same product at different scales. They are different products.
In the pilot, one enthusiastic person owns the devices, charges them overnight, and fixes anything that breaks. Everyone signs in as the same demo account. The content is frozen, because it only has to work on demo day. The Wi-Fi is clean, nobody is wearing gloves, and the participants are volunteers who want it to succeed.
At rollout, the innovation team hands over to an operational team that did not choose this. Identity and permissions matter now, and so does hygiene on shared headsets. A procedure changes in month four and someone has to re-author the content — someone who may not exist. The plant floor has heat, glare, noise, PPE and Wi-Fi that was never designed for streaming. And the users are no longer volunteers; they're conscripts, and when the immersive tool adds friction they quietly revert to the laminated checklist that has worked for fifteen years.
Every one of those is an operating cost. Almost none of them appear in the quote you were given for the pilot. This is why so many programmes look affordable right up until the moment they become real.
Failure four: the failure mode nobody quotes you for
This is my own research area, and it is the one I find most consistently absent from enterprise XR business cases.
A systematic review of cybersickness in current-generation VR headsets reports that between 60% and 95% of participants experience some level of cybersickness during exposure, and that 6% to 12.9% end their session early. Symptoms usually clear within about fifteen minutes of taking the headset off — but there's a second effect that matters more for training: on re-immersion, symptoms can return "abruptly and severely."
Modern headsets are measurably better than the previous generation. That is a real and meaningful improvement. It is not a solved problem.
Now translate that into an operational sentence, which is how it will actually reach you:
Roughly one in ten of your workforce may be unable to complete a session. If the training is mandatory, that is a compliance gap with names attached to it.
And it compounds. The people who feel unwell once are the people who avoid the second session, become vocal internally, and turn a technology rollout into a workplace-relations problem. I have seen an otherwise well-built programme lose its internal sponsor over precisely this.
Here is the part that should be encouraging rather than alarming: nearly every driver of cybersickness is a design decision, taken months before anyone puts a headset on. How the user moves through the environment. Frame timing and dropped frames. Field of view. Session length. Cognitive workload during motion. Seated versus standing. Whether there is a comfort-optimised path for susceptible users at all.
Which means it is cheap to design around at scoping, and expensive to retrofit after rollout. Almost nobody scopes for it, because the people selling the build have no commercial reason to raise it, and the people buying don't know it's a category of risk.
Failure five: the ownership vacuum
Innovation teams are structurally rewarded for starting things. Very few are resourced to run them for five years.
So there is a moment — usually right after the pilot succeeds — when the project needs to move from the people who wanted it to the people who will live with it. If that handover has no named owner, no budget line and no place in anyone's objectives, the project doesn't get cancelled. Something worse happens: it just stops being anyone's problem, and it decays quietly until someone finds the headsets in a cupboard.
"Innovation" is not an owner. Neither is "IT." A person is an owner.
Eight questions to answer before you fund anything
If you take one thing from this article, take this. None of these questions are about headsets, and you can answer all eight in a workshop for the cost of about four hours of people's time.
Score yourself honestly. Seven or eight, and you have something worth scoping — a real problem, a named owner, and a way to prove whether it worked. Four to six, and you are not ready; spend a fortnight closing the gaps, which is dramatically cheaper than a pilot that stalls. Three or fewer, and the honest answer is that you are buying a demo.
Question eight is the one people skip and later wish they hadn't. Agree the kill criteria while everyone is still optimistic. Nobody has ever successfully defined "what result would make us stop" after a project has champions, sunk cost and a steering group.
Sometimes the right answer is: don't build it
I would rather say this in an article than in an invoice.
Immersion is expensive, and it earns its cost in a specific and fairly narrow set of conditions: when the real thing is dangerous (high-voltage work, confined space, emergency response), rare (the failure mode you must handle but only see once a decade), expensive to stage (shutting a line, flying a crew, building a rig), or impossible at scale (a thousand people cannot stand around one turbine).
If none of those apply, you are often buying attention rather than capability — and there are cheaper ways to buy attention. Sometimes the honest recommendation is a well-produced video, a 2D simulation, a redesigned checklist, or better on-the-job coaching. Sometimes it's a much narrower slice of XR than was proposed: AR remote assistance so one expert can support twenty sites, rather than a full VR training suite nobody asked for.
A vendor whose revenue depends on the answer being "build it" is not well placed to tell you this. That is not cynicism about vendors; it's just how incentives work. It is also precisely why the scoping question and the build question should not be answered by the same party.
What good actually looks like
The programmes I have seen survive contact with an organisation share a shape:
- A problem with a number and an owner, identified before any technology was chosen — and the owner is someone whose objectives that number sits in.
- A measured baseline, captured before the first headset arrives, however crude. Rough beats absent.
- Staged progression — proof of concept, then pilot, then programme, then platform — with explicit criteria to pass each gate, and permission to stop at any of them.
- IT and security as co-designers from day one, not as a gate you discover in month six.
- A human-factors plan: comfort testing before rollout, session lengths chosen deliberately, and a genuine equivalent path for anyone who cannot or will not use a headset.
- A content maintenance answer, in-house, before launch — because the procedure will change and content that can't be updated has an expiry date.
- Change management treated as a workstream with its own budget, not as an email sent the week of go-live.
Notice how little of that list is about technology. That's the point of the whole article.
Working with me
I'm Dr Yasas Sri Wickramasinghe. I hold a PhD in Human Interface Technology from the University of Canterbury and work as a researcher at the HIT Lab NZ, where my published work covers VR presence, cybersickness, and multiplayer location-based AR. Before academia I was a technical lead and senior software engineer, and I co-founded a VR studio that received Niantic Developer Fund backing. I teach this material at postgraduate level.
That combination is the useful part: enough research depth to evaluate human factors properly, and enough delivery experience to know what actually ships.
Where I help:
- Feasibility and scoping audit — vendor-neutral. Should this be built at all, what should it measure, and what will it cost to operate? Usually two to three weeks, and it either de-risks the investment or saves you the whole of it.
- Human factors and cybersickness evaluation — for pilots where people take the headset off, adoption is worse than expected, or you need comfort and accessibility validated before a rollout.
- Workshops and team training — bringing an internal team or an executive group up to a working understanding of what XR can and cannot do, so you can brief and challenge vendors properly.
- Design and build partnership — where you want research rigour embedded in delivery rather than bolted on afterwards.
If you have a stalled pilot, a business case you're not sure about, or a rollout where adoption is worse than expected, I'm happy to have a short conversation about it — including telling you if I don't think you need me.
📧 Email me directly · LinkedIn · Publications
Most useful thing to include in a first email: the problem you're trying to move, what stage you're at, and what has already been tried.
Frequently asked questions
Why do VR training pilots fail?
Rarely for technical reasons. In a 2026 study of industrial XR adoption, organisational and change-management barriers were named by 15 of 17 experts and financial or ROI-measurement barriers by 12, while technological barriers were named by only 7. The common causes are capability-driven rather than problem-driven scoping, no measured baseline so the value can't be proven at renewal, unbudgeted operating costs at scale, unaddressed human factors such as cybersickness, and no named owner after the innovation team hands over.
How do you measure ROI on VR or AR training?
Decide the metric and measure it before anything is built. Typical candidates are time-to-competency, first-time assessment pass rate, error or rework rate, incident frequency, travel and downtime cost, and instructor hours. Capture the current value as a baseline, define the improvement that would justify the investment, and agree who owns the number. ROI figures published by XR vendors are a useful hypothesis, but only a measurement in your own environment will survive finance scrutiny.
What causes cybersickness in VR training, and can it be prevented?
It arises largely from conflict between what the visual system reports and what the vestibular system feels, worsened by dropped frames and latency. Systematic review data on current-generation headsets reports 60–95% of users experiencing some level of it and 6–12.9% ending sessions early. It can be substantially reduced by design: choosing teleport or comfort locomotion over smooth movement, holding stable frame timing, limiting session length, reducing cognitive load during motion, allowing seated use, and providing an equivalent non-immersive path for susceptible users. These are scoping decisions, which is why they are cheap to make early and costly to retrofit.
Should we use AR or VR?
VR suits situations where the real environment is dangerous, rare, expensive to stage or impossible to access at scale — emergency response, high-voltage work, confined space entry. AR suits situations where the worker must stay in the real environment and needs information or expertise brought to them — remote assistance, guided assembly, inspection and maintenance. AR remote assistance is frequently the higher-return option because it reduces expert travel immediately and requires far less content production.
Is enterprise XR worth the investment in 2026?
For a well-chosen problem, often yes. For a poorly chosen one, reliably no — and the choice matters more than the technology. The conditions under which immersion earns its cost are specific: the real thing must be dangerous, rare, expensive to stage, or impossible at scale. If none apply, cheaper approaches usually deliver the same outcome.
Our pilot succeeded but never scaled. What now?
This is the most common situation in enterprise XR, and it is usually recoverable. Work backwards: was a baseline ever captured, does the outcome sit in a named person's objectives, and were operating costs — device management, identity, content maintenance, support — ever costed? A successful pilot that stalls is normally missing an owner and a measurement, not better technology.
Sources
- Exploring Organizational Readiness and Ecosystem Coordination for Industrial XR (2026) — expert interview study; barrier rankings and the problem-first scoping recommendation.
- Cybersickness in current-generation virtual reality head-mounted displays: systematic review and outlook, Virtual Reality — prevalence and withdrawal figures.
- Why Does Every XR Pilot Look Impressive but Fail to Scale? — practitioner account of the operational barriers at rollout.
Related reading on this blog: Why Most AR Games Fail (and How to Fix It) covers the same failure logic in consumer AR, and this piece on remote multiplayer AR describes the research the arguments above come from.
