When the VR Project Brief Is the First Obstacle

The original plan: digitizing the chaos

The company runs intensive training schools, eight straight hours over two days, for clients with high sanitary-risk operations. Their VR plan was the one any of us would imagine: buy twenty headsets, put one on every participant, immerse them in a virtual environment, and let them "live" the training. The implicit promise was irresistible: if the technology is immersive, the learning will be immersive. If it is new, it will be memorable. If it is expensive, it must work.

It is exactly the pattern I see repeat itself at mid-sized companies. We buy software, hardware and platforms the way people buy aspirin at a drugstore: no diagnosis, no understanding of the real pain, assuming the generic dose will cure whatever it is. The result is predictable. Frankenstein stacks of licenses nobody uses. E-learning platforms with fifteen percent completion rates. CRMs turned into passive databases. And now, more and more, virtual reality, artificial intelligence in training and "digital transformation" projects that are basically theater: the digitization of chaos instead of the resolution of chaos.

The question almost nobody asks before signing is the only one that matters: what concrete problem am I solving, and is the tool I am about to buy the best way to solve it? Instead we ask things like "is it innovative?", "will it look good in the quarterly report?", "what are the competitors doing?". They are legitimate questions, but none of them is the diagnostic question.

Why I did not accept the brief

When the meeting came, I had two paths. One was to take the brief literally, twenty headsets, mass immersive training, quote it, deliver it, invoice it. The other was to start asking uncomfortable questions and put the account at risk. I chose the second because I had already seen how the first movie ends, too many times.

How long is your training? Eight hours. How many people? Twenty. Have you seen what happens when one person uses virtual reality surrounded by nineteen people who cannot see what she sees? I explained, with real cases, including executives who have refused to put on a headset out of embarrassment, that virtual reality is an illustration tool that one person uses at a time. One person puts it on, the rest watch on a screen, and the pedagogical value lives on the shared screen more than in putting everyone into immersion at once; when several devices really are needed, the challenge becomes how to control multiple VR headsets in a single session.

From there, the project was rebuilt live, at that same table. We forgot the twenty headsets. We went down to two or three. Eight hours of immersion would have been disastrous, so the training became short blocks, almost micro-experiences, integrated at surgical moments of the course. A gamified module of one minute, three at most, to spot errors in a virtual environment, with one person wearing the headset while the rest of the group watches the screen and shouts "to the right!", "down!". A second experience, with no interaction, purely to "transport" the group to an exemplary facility they could otherwise never visit due to operational restrictions. And, optionally, a 360-degree video designed for trade shows and expos, separate from the training.

The project went from being an expensive black box with promised immersive magic to being a tool articulated across three distinct uses, each with a specific, measurable purpose.

Why I stopped believing "the customer is always right"

Here is the uncomfortable part. If the client had signed with the first VR vendor, the one that was furthest along, the one that already had a quote, the one following the brief to the letter, the project would have failed, and the responsibility would have been shared. That vendor would have billed, delivered what was asked, and left the client with twenty headsets, a frustrated team, and an internal case study on "why virtual reality does not work for training". They would have gotten everything technical right and missed the only thing that mattered.

In technology projects, the client is almost never right about the how. Sometimes not even about the what. What they do have, and this is valuable, is clarity about the business problem: I need my people to remember more, make fewer mistakes, and find the training memorable. That part is sacred and, as a vendor, I must not touch it. But the how, which technology, which architecture, which implementation methodology, is my territory, and the client who imposes the how is paying to do their own project badly.

The vendor who only obeys becomes an accomplice. They charge for executing, but by executing a poorly diagnosed idea badly, they accelerate the failure and take their cut of the budget before the damage becomes visible. The industry is full of these accomplices because obeying is easier than diagnosing, and diagnosing sometimes means losing the sale. I told the client, literally, that if he wanted a long VR experience I would build it for him, I was not going to refuse, but I warned him he was going to lose his audience. That sentence costs money. It also builds reputation.

What this means for anyone buying a VR project

Three lessons, none of them about virtual reality. All of them about how technology gets bought and sold.

First: the diagnosis is worth more than the tool. This company spent weeks refining a quote before discovering, in a single conversation, that the premise was wrong at the root. The cost of not diagnosing in time includes the money of the failed project and, above all, the opportunity cost of the six or twelve months it takes you to realize you bought wrong.

Second: the best vendor is the one willing to lose your account before accepting a project that is going to fail. It sounds logical, and it is still rare. When you find one, you will pay more for the conversation and less for the delivery, and that proportion is exactly what it should be in any serious technology project. If you are evaluating options, I wrote an honest guide to choosing a VR company in Mexico with the criteria I would use myself.

Third, and this is the most painful one: if your internal team is not willing to let a vendor question the original idea, you are hiring an executor instead of a partner. Executors are cheap in the short term and extremely expensive in the long run. The client in this story had the maturity to listen, to change their mind in that same meeting, to say the conversation had completely changed their perspective. That maturity is what separates real digital transformation projects from the ones that end up as expensive theater.

What will transform that company is an honest conversation about what virtual reality is for and what it is not for. That conversation, frankly, needed no goggles, just someone willing to tell the client they were about to make a mistake. If you want that conversation for your project, even if it ends with us telling you not to do it, let's start it here.

Frequently asked questions

What should a VR project brief include?

The problem before the tool: what the person has to learn or do, how many people and in how much time, which error you want to prevent and how the result will be measured. With that, the vendor can propose the format. A brief that starts with the number of headsets has already chosen the solution before the diagnosis.

How many headsets do I need for group training?

Fewer than people usually think. In a group session, VR works as an illustration tool: one person wears the headset while the rest follow the experience on a shared screen. In the case this article describes, the plan went from twenty headsets to two or three, with one- to three-minute modules built into the course.

What if the vendor quotes the brief without asking questions?

Get a second opinion before signing. A vendor that quotes the brief as it arrives, without asking what problem it solves or how it will be measured, is selling headsets and development hours. The one that questions the premise risks the sale so the project works.