They can practice something difficult, expensive, dangerous, or impossible to reproduce in the real world. That part of VR has been demonstrated over and over again.
The harder question comes afterwards.
Can you actually use it?
- Not once.
- Not for a pilot.
- Not when the champion who brought it into the organization is standing beside the headset making sure everything works.
Can you use it repeatedly, predictably and economically, across hundreds or thousands of learners, for years?
That is a very different question.
A successful VR program that almost failed
Sean Peterson of Johnson & Johnson MedTech has recently been documenting what he calls the Enterprise VR Journey to Scale.
It is worth reading because this is not the story of a failed VR experiment. It is almost the opposite.
The program began with what Peterson describes as a VR champion who believed immersive technology could add value as an educational tool. A vendor helped with the hardware, management and custom content. The pilot succeeded. More funding followed.
Then came the mandate every successful pilot hopes to receive:
Scale it.
J&J selected a vendor capable of providing essentially the entire VR environment, including content creation, platform services, identity management, analytics, multiplayer and more.
And they scaled rapidly.
Peterson says the program produced dozens of surgical simulations and expanded into more than 50 countries in only a few years.
The feedback was very good.
But scale began exposing something the demo could not.
The login process was cumbersome. Analytics needed improvement. LMS integration became important. Content production took too long. Requested platform features sat on roadmaps.
Eventually, the problem became larger than individual features.
J&J had built an extraordinarily successful VR program, but important parts of that program were dependent upon a proprietary architecture they did not control.
Peterson describes one of the conclusions particularly well. Content could no longer remain tied to a proprietary platform.
He calls the distinction the difference between leasing your VR program and owning it.
That is an important sentence, and mimics a sentiment I have been voicing for some time.
We recently heard a remarkably similar concern
Sensible-VR was recently approached by one of Japan's major automotive manufacturers.
- They are exploring VR for learning and training.
- They have seen impressive systems.
- They have seen impressive demonstrations.
And they are asking exactly the questions they should be asking.
- What happens after the demo?
- What does this look like when it becomes an everyday learning system?
- What needs to be connected?
- Is there a privacy cost with certain devices?
- How are the next experiences created?
- What happens when the platform changes?
- What happens when the hardware updates and/or is made redundant?
- What happens when a supplier changes direction?
- What does it cost to keep all of this working (TCO, Total Cost of Ownership)?
And perhaps most importantly:
Who ultimately controls the learning system?
Those questions sound remarkably similar to the ones being asked inside one of the world's largest healthcare companies.
That should tell us something.
A junior high school and a multinational corporation may have more in common than we think
It is tempting to think these are completely different markets.
One organization may have a global technology team, a large training department and operations spanning dozens of countries.
The other may have Mrs. Applebaum standing in front of 30 thirteen-year-olds with 40 minutes before the bell rings.
Yet many of the problems are exactly the same.
- Someone has to get the equipment ready.
- Someone has to manage accounts.
- Someone has to manage the network.
- Someone has to distribute content.
- Someone has to troubleshoot.
- Someone has to charge the devices.
- Someone has to understand the platform.
- Someone has to deal with software changes.
- Someone has to replace hardware.
- Someone has to maintain the relationship between the content, the hardware and the platform.
- And somebody is paying for all of it.
The scale may be dramatically different. The problem is not.
The demo is not the system
This distinction matters enormously.
The VR experience is what the learner sees inside the headset.
The VR system is everything required to make that experience appear when it is needed.
Those are not the same thing.
A wonderful ten-minute learning experience can sit on top of an extraordinarily complicated delivery system.
And complication has a habit of remaining invisible during demonstrations.
A demonstration normally has:
- prepared hardware
- working connectivity
- learning modules downloaded to the device for the demo (when in fact they are not that readily available in actual use)
- the correct accounts
- charged batteries
- technical people nearby
- no competing classroom priorities
- no requirement to repeat the process several times every day, with a variety of content
Then the product enters the real world, and that is where architecture matters.
Success can actually expose the problem
There is an interesting lesson in the J&J story. Their challenge did not emerge because people rejected VR. It emerged because people rightfully wanted more of it.
- More learners.
- More countries.
- More simulations.
- More functionality.
- More integration.
Success put weight on the architecture, which eventually had to carry that weight.
This is something every organization considering VR should understand before buying anything.
The right question is not simply, “Does this VR experience work?”
It is:
What has to continue working around it for the next five years?
That question changes procurement dramatically.
The usual solution is “more”
When organizations encounter these problems, the technology industry's instinct is often to add another layer.
- Add device management.
- Add cloud services.
- Add analytics.
- Add another integration.
- Add more accounts.
- Add an LMS connection.
- Add remote viewing.
- Add another administrator.
- Add another dashboard.
Some of those things may be justified. A global medical training program may genuinely require capabilities that a classroom does not. A manufacturing company may need functionality that a school never will.
But sometimes another layer of cost and complexity, like MDM (mobile device management), is an admission rather than a solution. It’s an admission that a device made for one purpose, like gaming, is not adequately proficient at other core tasks, like managing learning content, and pushing scores to an LMS.
That is precisely the point.
The question should not be:
What can we add?
It should be:
What does this learning objective actually require?
Because every additional component has a cost.
- Sometimes that cost is money.
- Sometimes it is IT time.
- Sometimes it is teacher or trainer time.
- Sometimes it is complexity.
- Sometimes it is privacy.
- Sometimes it is dependency.
And sometimes it is simply another thing that can stop the learner from learning.
One answer is modularity
Peterson and his colleagues eventually concluded that the obvious alternatives were both problematic.
Moving to another all-in-one vendor risked recreating the same dependency.
Building everything internally would provide control, but would require substantial permanent development capability, including engineers, artists, QA, and other specialists.
So, they began looking for a third path.
- Why should the content creator have to own the platform?
- Why should the platform also control identity?
- Why should the same supplier necessarily provide analytics?
- Why should content have to remain locked to one proprietary environment?
That thinking led toward a more modular architecture. It makes enormous sense.
But there is another question worth asking before assembling all of those pieces.
How many pieces do we need at all?
Sometimes the best architecture is the architecture you remove
This has been fundamental to the development of Sensible-VR.
We did not begin by asking how many features could be placed around VR.
We began by asking what was actually necessary for learning.
That has led us to make choices that can initially look unusual.
- Offline-first operation.
- The privacy of a non-gaming architecture.
- Individual learning rather than mandatory multiplayer.
- Minimal infrastructure.
- No requirement for continuous cloud connectivity.
- No dependence upon social features.
- No front-facing camera.
- A system designed to be usable by the least technical teacher or trainer, rather than merely impressive to the most technical one.
These are not attempts to make VR less capable. They are attempts to remove everything that stands between the learner and the reason VR was introduced in the first place.
Learning is learning
Sensible-VR was never intended to be simply a classroom solution.
Our guiding principle has always been:
Learning is learning, whether in the classroom, the boardroom, or on the factory floor.
- The learner changes.
- The subject changes.
- The organization changes.
- The consequences change.
But many of the fundamentals do not.
People need access to appropriate learning at the moment it is useful. The technology should help make that happen. It should not become the activity around which the organization must reorganize itself.
A junior high school should not need a technology specialist standing beside every VR session. Neither should a manufacturing company.
A teacher should not need to become a headset administrator. Neither should a corporate trainer.
And neither one should discover three years later that the learning assets they believed they had purchased are inseparable from an architecture they no longer want.
We may have been asking the wrong VR question
For years, the industry has spent enormous effort demonstrating that VR can be effective for learning.
That work matters. But perhaps that question has now become too narrow.
The next stage of VR adoption requires us to ask something harder:
Can the system delivering the learning survive success?
- Can it survive hundreds of users?
- Thousands?
- A change of teacher?
- A change of trainer?
- A change of IT staff?
- A change in hardware?
- A change in supplier?
- Five years?
- Ten?
If the answer is yes, then at what cost? Run it through the Cost Calculator.
If the answer is no, then an extraordinary VR experience may still be built upon a poor learning system. And that is a terrible waste.
Because VR genuinely has too much to offer to be squandered.
The immersive learning industry does not need better demonstrations nearly as much as it needs better foundations.
The VR experience is not the VR system.
It is time we started evaluating both.
Sources
Sean Peterson, Johnson & Johnson MedTech
Enterprise VR Journey to Scale, “The Well Worn Path”
Peterson describes the original VR champion, successful pilot, vendor-led architecture, RFP process and the friction encountered as the program scaled.
Sean Peterson, Johnson & Johnson MedTech
Enterprise VR Journey to Scale, Post #3: Scale 1.0
Peterson describes the production of dozens of surgical simulations, expansion into more than 50 countries, and challenges involving login, analytics, LMS integration, content-production speed and platform development.
Sean Peterson, Johnson & Johnson MedTech
Enterprise VR Journey to Scale, Post #4: Two Paths
Peterson discusses the choice between another integrated vendor and bringing development in-house, the requirement that content no longer remain tied to a proprietary platform, and the search for a modular third path.
