FEATURED POST

The #1 barrier to adopting XR

By: David Francis clock-icon 2 Min
David Francis calendar25 June 2019 clock-icon 3 Min

It is common-place for an organization that wants to start an XR project to either go to an external agency or to develop a capability in-house as a limited-scope proof-of-concept (PoC). The motivation for that is that it is difficult to go beyond the "cool demo”, until you know in some detail what you need to do and how XR will benefit your organisation. So, the only way to get the answers is to run a PoC.

The problem with this approach is that scope of the exercise either hasn’t been fully considered, or it is extremely restricted simply because it is a PoC. Getting buy-in from the senior leadership is difficult as you are trying to get approval for something that hasn’t been tried and tested. Therefore, the budget is usually only sufficient for the one use-case that is within the scope of PoC. Of course, I have identified these as negatives, but if there is a likelihood that the PoC will not lead onto something bigger, or might fail, then this is the best and most pragmatic approach, isn’t it? But, what if it doesn’t fail?

It doesn’t have to be this way. There are now technologies and technology partners that can help develop the business case. The technology doesn’t have to be suitable for that one-off PoC. But, if you develop in isolation (i.e. in-house or with a creative agency) then it probably will be.

One of the largest problems of using this technology is getting the 3D content into XR in the first place. There are lots of importers on the market that are transactional (i.e. they do conversions one at a time manually), which for a PoC may be fine, but this isn’t scalable. If, for example, your use-case is manufacturing, then you don’t want to be manually importing 3D CAD assemblies every time something changes. You’ll need a scalable, automated process. And, there is absolutely nothing wrong with identifying this as a must-have requirement right from the start. Just having some isolated data in XR will not adequately prove that your solution is fit-for-purpose; you’ll only be testing that one aspect.

So, you need to really understand why you think you need XR; what is the value to your business and how would you implement it if you weren’t doing “just a PoC”? In fact, if you don’t do this, then your PoC isn’t really valid. Often, we are so keen to get our project started, that we skip past these steps, and even reduce the scope in order to get just enough money to be able to “have a go” with exciting new technology. You must resist the urge to do this, as whilst this may get your project off the starting block, it will not do you any favors further downstream.

In order to prove the value, you must adequately specify your project to prove the value of all of the requirements. If to achieve the business value you require regular 3D data changes, then specify itIf you require a collaborative experience, then you must specify it.  Additionally, you must also consider the output device; these things change regularly, with new devices popping up on the market every few weeks, so make sure you specify a device agnostic approach...

This may also be of interest: Exploring the Cognitive Gap and the potential of XR technologies. 

Subscribe to Blog

New call-to-action

Leave A Comment

Comment():

YOU MAY ALSO LIKE

The #1 barrier to adopting XR

By:   28, Oct 2019   2 min

There are many perceived barriers to adopting XR technologies. Many articles exist talking about developing the use case or getting the business case ...

The reality of AR, MR, VR and XR

By:   28, Aug 2019   4 min

We all know that the Tech, Engineering and Manufacturing industries are full of acronyms, jargon and terminology. And for those who aren’t in the ...

Creating technical debt

By:   09, Jul 2019   4 min

Following on from my last blog on "going beyond the cool demo", here are some thoughts around creating technical debt. It is incredibly encouraging ...