Many organisations have looked at, are starting to or are well down the road of integrating immersive experiences and solutions within their everyday work processes and pipelines and it’s something we are often asked about or go through with our clients and partners. So we thought it best to help reduce initial conversations, confusion, time and therefore everyone’s money, to create a single point of reference to cover the majority of the steps and details around the best practice approach for your organisation.
We will cover what we see as the four main stages, as Make Real calls it, the 4D Approach, and dive into each stage in more depth, looking at what the purpose of each stage is, who should be involved, what the expected outcomes are and highlight a few pitfalls and gotchas along the way. If you view the whole process as a journey of adventure and discovery, you will find everyone involved will be more actively engaged and overall you will have greater success and results, than if treated as a black box exercise.
Once you have read through the guide, aside from using emerging technologies and creation tools that may be new and unfamiliar, you will see projects are operated like any other software development process, either with a waterfall or agile project methodology (typically the latter), and have some of the same processes and pitfalls too.
Make Real operates with a 4D Approach: Discover > Design > Develop > Deploy
The aim of the discover phase is to define, gather and engage with all relevant stakeholders, agree what the learning outcomes or business objectives are to be addressed, set administrative requirements like budget, timelines, payment schedules and expected deliverables. Finally, the xR (VR or AR, device platform specifics) hardware target for deployment and requirements around ensuring smooth rollout.
GOTCHA! Do not lead the solution by the technology, let the technology decisions fall out of the solution. The desire to create something with VR or AR just to tick an innovation box, or because of competitor behaviour, leads to poorly performing solutions. Their success metrics and measurement cannot be clearly defined, which will lead to lower impact and disappointed stakeholders, resulting in less adoption across the organisation.
Workshops within the discover phase will allow you to answer the main question “Why?” are you looking to integrate or enhance an existing process or programme with immersive technologies, defining and validating the use case specific to your organisation or departmental needs. Workshops are also a good time to introduce some examples of immersive technologies and existing content experiences to all stakeholders, to ensure everyone understands the possibilities and limitations of what is available today. Be prepared for an opening of the floodgates of ideas once people get it with immersive technologies though. Remember to fall back to that original question, “Why?”
We recommend starting small and iterating upwards after deploying and running a successful pilot. This reduces initial budget requirements, scope and failure points, making all stakeholders more comfortable about signing-off and agreeing to an acceptable budget to begin with. Once the outcomes have been measured and objectives assessed for having been met or not, a larger scope of works and budget is more easy to swallow with confidence.
We have created a series of handy templates for workshop session project canvases for you to use as a basis for extracting and drawing out that information that will help form the shape of the solution.
Stakeholder engagement early on is critical to any project success, especially when looking to introduce new technology into an organisation. The exact roles and departments to involve will vary from project to project, depending upon who the intended end users are but below is a fairly common, recommended list of people to involve:
Whilst it is likely each stakeholder will have their own desires for the outcomes based upon their departmental requirements or perceived weight or seniority of decision-making, it is crucial to remain focused on the learning outcomes and business objectives that are to be addressed by the intended solution, constructively and objectively assessing use cases appropriately. However it is important to determine the chain of command and define who is responsible for review, sign-off and being point of contact as necessary.
The purpose of the workshops with stakeholders is to reach an agreed scope of works that is feasible within the timeframes and budget allocated to the project. Whilst this shouldn’t mean design has begun, the breadth of the content, topics, length, type, formats and high-level details can be agreed to refer back to once design and development is underway. This enables the creation team to remain within the guidelines of what is achievable, in terms of effort against timelines and budgets available.
This in turn will form the basis of the plan and schedule which payment and invoice milestones and deliverables can be allocated against, as a check and balance review period to ensure the agreed projects and outcomes are on-track for final sign-off and deployment.
Immersive technologies can then be investigated and decided upon, defining which types and manufacturers are fit for purpose, as well as allowing the IT / IS and Procurement teams to check integration and deployment requirements. They will likely have a number of questions about hardware ownership, data privacy and security, device access control, app deployment and interoperability within the organisation network. The main manufacturers all have their own data security and privacy polices, enterprise warranty and support agreements and device management platform EULAs. We have listed the main ones available online at the bottom of this article.
The main factors influencing hardware choice derive from how the user will interact with the content and the type of content required to meet the objectives and outcomes. Will they be seated or standing? Will they experience the content alone or with others? Do they need to be able to reference real-world assets or space? Do they need to track their hands or have virtual hand representation? Do they need to move around the real-world space or even if standing, will they be fairly stationary? Will the content be 360º film or computer-generated visuals? Other factors come down to scale; how many users will there be in a session? What is the target reach (number of people over a given time)?
GOTCHA! Some content vendors operate a walled-garden approach to the provision of immersive technology solutions and will try to restrict organisations from being able to install content from other vendors within the ecosystem. Always be sure to read the small-print around what you can and cannot do with the hardware you are paying for. Enterprise organisations should be free to pick and choose apps from a range of vendors to install onto immersive devices, to ensure wider adoption and greater ROI from those initial purchases.
You might want to set aside a small amount of time and budget to carry out some exploratory R&D at this stage, just to sense check what you are scoping out is feasible with the available technologies, software toolkits and importantly, overall budget, timescales and quality expectations. This is especially important when the design could require incorporation of new development environments or tools, beyond what has been validated as effective or compatible previously. This could also be carried out in the design phase too.
Finally, look ahead to deployment and the end user, ensuring that they have been defined and factored into the timelines, allowing for sessions to train the trainer, carry out integration and user testing to confirm everything operates as expected before the big day of launch or first-time use at any sense of scale.
Following on from the discover phase, the scope of works output from which feeds directly into the design phase, where what will be developed is shaped and honed, for review by the stakeholders. The design phase will produce a number of outputs, that will then feed into the develop phase accordingly.
At this stage, much of the effort will be carried out by the content vendor team, assuming you have opted to work with an external organisation to create your immersive experience, or your internal L&D team, likely supported by the innovation, R&D and technical teams and associated SMEs. However the need for communication, knowledge sharing and reviews means that key stakeholders should expect to be involved during this stage too.
There are many facets to design, likely incorporating a number of roles and people, including the learning-, interaction-, systems-, graphic- and UX designers. They will create the structure of the content, textually and visually as well as defining the user journey and how they will flow through the experience. Do not forget the data that needs to be gathered throughout the experience, to feed into the user feedback and metrics reporting functionality.
Some of these roles and responsibilities can be broken down further depending upon project requirements and will have further outputs, such as narrative scripts, branching logic, VO actor scripts and film shoot call sheets, and story- or moodboards to start to convey the sense of feeling what the experience will look like and be like for the end user.
GOTCHA! The ‘Half Life Alyx Effect’ – someone on the team has likely played this (albeit critically acclaimed, fantastic) game and is likely prone to overcomplicating and expecting too much from every interaction with every object within the environment. Have to remember that the game cost many millions of dollars to create by a team of hundreds, most likely far higher in both senses than your project budget and timelines allow. Remember K.I.S.S (Keep It Simple, Stupid) design, especially as with all new technologies, you are likely going to be placing users in their first experience and you do not want to overwhelm them.
It is also very sensible to involve the technical development team as this stage, the ones who will be coding and bringing the design to life, since they will be able to confirm whether the proposed design is possible with the known development environment and tools, and that the level of effort required to create the design is within expectations of the budget and timeframes.
The key output will be a master document, or series of documents, that will define every aspect of the design of the experience, from start to finish, including key interactions and outcomes, wireframes for user interface, data schema, content logic and all relevant aspects necessary to provide the development team with all the information they need to begin creation, reducing as much uncertainty or aspects that could be left to interpretation.
GOTCHA! Sometimes a design on paper just doesn’t correlate to a meaningful immersive interaction or outcome. Incorporate paper prototypes or even some 3D prototyping software tools for the more contentious designs, to root these potential pitfalls out before you burn precious development time trying to solve them.
At the end of this stage, the stakeholder review will confirm that the proposed design meets the scope and expectations of the organisation, in relation to learning outcomes, business objectives and engagement, whilst being achievable within the agreed budget and timeframes. This is also a good time to sense check the design and define what counts as scope creep or a change request, to ensure that everyone is clear should these project gremlins arise during development. Setting aside a small contingency budget helps rapidly alleviate these issues should they arise, without causing too much interruption and halting proceedings.
Typically the main weight of the project budget, the develop phase can begin once all stakeholders are agreed that the design meets the scope and can be achieved within the budget and timeframes. The first task will be taking the design documentation and breaking it down into chunks of effort or specific tasks, so that the road to the top of the mountain can be visualised through a series of manageable steps and interconnected parts. Here the hierarchy and relationships can be defined into a schedule, outlining order and dependencies to structure the priorities and estimates of effort.
Another key task is to prepare the development environment to delineate the clear process from what is in progress, to staging builds for review and test, ready to be deployed into the live environment. Some of the deployment hardware budget spend may be called upon during development to prepare and enable progress from alpha to beta to release candidate builds for review and then final versions of the content experience for deployment.
GOTCHA! It sounds obvious but make sure your staging and live environments are mirrored – there is nothing worse than everything working fine on staging and being pushed to live for launch and everything falls over, ceases to function correctly or even at all.
Reviews have been mentioned a few times already, and the key stakeholders will need to be available for these during development at the specific review periods, as agreed during the discover phase. Whilst many agile projects are broken down into two week sprints, with a functioning deliverable at the end of each sprint expected, for efficiencies of time, it makes sense to still plan sprints and development towards reviews round alpha, beta and release candidate builds for all key stakeholders only. Furthermore, set strict guidelines around times to carry out reviews and provide feedback, and how many rounds of feedback are acceptable. It’s always better to receive all feedback at once rather than in dribs and drabs. Similarly, define how feedback should be categorised and prioritised to ensure high impact, high priority is given more time than fluffy nice-to-haves.
Many organisations will have their own definitions or understanding of these terms but it should be understood that an alpha build is likely structurally complete end-to-end but will include a lot of placeholder content, especially if involving film, 3D assets and voiceover. This stage is designed to ensure that the overall structure of the experience is as expected and that key interactions invoke reactions and outcomes as designed.
Moving towards beta will see more final content added, removing placeholder elements as the rest of the development team beyond the coders complete their tasks. At this point, everything should be in place end-to-end but without polish. Polish, testing and bug hunting (although these occur prior to this stage too) can really focus on turning an experience into a quality outcome that the whole team is proud of, ready to tie a bow on it as the release candidate; good enough for the end users to engage with, or importantly be submitted to app stores if this is one of the requirements.
Whilst most of the world now operates digitally and the need for hard deadlines of when data had to be burned to disc for production and packaged into boxes are long gone, for efficiencies sake (and time and cost), the stage between release candidate and final should focus on preparation for deployment and not a time to add items from the wishlist as last-minute, nice-to-have extras.
GOTCHA! Make sure everyone understands the development phase terms and expectations for each stage are set from the outset. Nothing slows a review process down quicker than having to handle irrelevant feedback because the reviewer isn’t clear on what to expect to see. Provide a list of build notes outlining what they should and should not expect to see within the build to be reviewed.
Around the time of beta and release candidate builds being available, it is a good opportunity to start testing deployment integration requirements with the IT / IS teams, to ensure compatibility and operation is as expected, rather than finding any nasty surprises during deployment. This could include software package requirements, either with manifests, schemas and structure, or validating environment restrictions and requirements as defined during the discover phase are met.
Depending upon the project and end hardware environment, it may be necessary to ensure the development team are working with or have access to a “minimum specification” system during development, or a range of agreed supported devices. Whilst many development aspects are enhanced and optimised by the fastest and greatest hardware known or available within reason, stability of technical performance is paramount for immersive experiences and no-one wants to hear, “Well, it works fine on my machine!” after launch.
GOTCHA! Development environments and tool options can move pretty fast within the world of immersive technologies, with interim builds and versions offering new features and ways of working, which on paper sound great but in reality, may add more bugs and effort than what the resulting outcome is worth. It’s often viable sticking to known limitations or fixed environments like LTS (Long Term Support) versions so that the development team can work within a stable setup. This also makes future updates and patches a more straightforward process without having to second-guess which features have been removed or amended since deployment.
Developing to a known, or closed set of devices removes some of the potential issues that arise in this situation, allowing optimisation to focus on a known capability matrix. However some experiences are deployed to environments beyond the control of the developers and a wide range of devices could be used to experience the content, providing a wide range of potential compatibility and performance issues experienced by the end user. Typically with tight control by IT / IS departments, this is usually less of a factor with enterprise deployments.
Getting deployment right is crucial to overall project success – all the effort of discovery, design and development is for nothing if deployment is mishandled. This takes preparation and practice, many content vendors have gained a lot of experience with deploying immersive technologies so be wary of those who have little to no visible prior evidence of knowledge and case studies available.
Deployment is more than just taking ownership of a number of boxes of technology and applications and being left to get on with it. Whilst the key stakeholders will all still likely need to be involved, there are certain sub-phases where you can optimise everyone’s time and effort.
First and foremost, the procurement and IT / IS teams will be engaged to take ownership and control of the hardware devices and software experience application/s. Many organisations have device management systems and over the past couple of years, the manufacturers of immersive hardware have worked hard to provide compatibility with these, or their own systems to integrate into the procedures. Hopefully you will have been able to carry out some preliminary tests during development around beta and/or release candidate build stages, so nothing nasty will rear its head but delays at this stage could greatly impact launch, especially if fixed dates around organisation events are involved.
Depending upon how the final content is due to be delivered, metrics tracked and outcomes reported, plugging the data and experiences into an LMS or LRS will be required too. Whether it be SCORM or xAPI standards based, testing to ensure content is launched, tracked and learner outcomes are validated is required to ensure smooth day-to-day operation. Check all primary and secondary channels of communication between the content and the backend and make sure enterprise organisation data policies do not restrict these.
Again depending upon the nature of the experience, allow time for setup and configuration of all the devices. Immersive data can weigh-in heavily on networks and storage, taking time to syncronise across or copy to each device. Be aware of how much data has to be handled in advance and prepare appropriate time to setup all devices before they are needed.
GOTCHA! Don’t leave your hardware purchases to the last minute – due to COVID-19 lockdowns and the rising popularity within enterprise for immersive technologies, there will likely be a lead time between registering interest, purchase and delivery of devices. Make sure you are speaking to your procurement team as early as possible so that all purchase accounts and admin has been completed and device received before the deployment phase is due to begin. Content vendors are often ISV Partners with many of the manufacturers, so they will likely be able to guide, expedite and assist with getting things done efficiently.
The development team should work with the end user group, which could include the L&D team, trainers and facilitators to provide sufficient guides for setup, operation and troubleshooting. A premium service would be to offer and undertake a ‘train the trainer’ day or session, to ensure everyone is fully capable of handling the new hardware, from the nuances of using VR and AR devices, to running and operating the immersive experiences. It is critical that the end user is empowered to concentrate fully on the experience itself, so the technology becomes invisible, not impeding or impacting the outcomes incorrectly.
A gold standard service would be to enable physical support by the vendor during the first live session or event to be on hand for troubleshooting and emergency expertise. Ultimately it should be a momentous day of celebration for all the key stakeholders, who are able to bathe in the glow of victory having successfully completed and delivered the project, so it’s nice to have everyone together for a positive outcome.
GOTCHA! Don’t let that last minute gotcha getcha on the big day. If budget allows, have a couple of spare devices prepared and ready to rapidly swap out with any malfunctioning equipment to continue smooth operations and make you look that extra bit super prepared for every eventuality. In all likelihood you won’t need it and with a successful deployment under your belt, you can incorporate it into the scale-up programme without incurring extra costs.
Of course each project, organisation and deployment is unique, with their own challenges, requirements and desired outcomes, so there is no one size fits all process to follow. We have listed a number of common themes and considerations throughout the four main phases of an immersive experience being integrated into an enterprise organisation. There are likely specific areas, outputs or processes we have not included, glossed over or are not relevant to your particular organisation. However we feel this will give you a good enough overview to get you going, providing a series of key pointers and things to consider and remember as you set out on your immersive journey.
If you want to read more about enterprise use cases and real world examples of integrating immersive technologies within organisations, we recommend the following two books:
Reality Check – How Immersive Technologies Can Transform Your Business – Jeremy Dalton
The Immersive Reality Revolution – T. P. Ffiske
If you really want to go down the rabbit hole of immersive technology across a broader range of use cases, here’s a handy list of 44! books to get your head buried in.
If you’ve done enough reading for now and want to speak to someone (from a content vendor with over 100 immersive experiences of all types, shapes and sizes of budget deployed into a range of enterprise organisations successfully,) drop us an email via the form below and one of the team will be in touch shortly.
HP Reverb G2
Product Page: https://www8.hp.com/us/en/vr/reverb-g2-vr-headset.html
Future Product: https://www8.hp.com/us/en/vr/reverb-g2-vr-headset-omnicept-edition.html
Product FAW Page: https://h20195.www2.hp.com/v2/getpdf.aspx/4AA7-5433ENW.pdf
HTC Vive Enterprise
Product Page: https://enterprise.vive.com/uk/product/
Enterprise Warranty & Support: https://enterprise.vive.com/uk/legal/
Oculus for Business
Product Page: https://business.oculus.com/products/
Enterprise Use Agreement: https://business.oculus.com/legal/enterprise-use-agreement/
Commercial Terms: https://www.oculus.com/legal/oculus-commercial-terms/
Enterprise Warranty & Support: https://business.oculus.com/legal/warranty-info/
Workplace Privacy Disclosure: https://business.oculus.com/legal/enterprise-privacy-disclosure/?locale=en_US
PICO Interactive Enterprise
Product Page: https://www.pico-interactive.com/us/tob_overview.html
Enterprise Warranty & Support: https://www.pico-interactive.com/us/terms/user_terms.html
Varjo Enterprise
Product Page: https://varjo.com/products/
Enterprise Warranty & Support: https://varjo.com/legal/
Microsoft HoloLens 2
Product Page: https://www.microsoft.com/en-gb/hololens/buy
Magic Leap
Product Page: https://www.magicleap.com/en-us/enterprise/solutions
We’re always happy to talk to you about how immersive technologies can engage your employees and customers. If you have a learning objective in mind, or simply want to know more about emerging technologies like VR, AR, or AI, send us a message and we’ll get back to you as soon as we can.