One of the biggest challenges that companies in AEC face is change management. Specifically when these changes deal with introducing new technology. We’re often asked by customers how other clients have incorporated emerging technology into their workflows and how they can develop a POC or “proof of concept” for VR.
While individual cases can be different, below we've identified and outlined a few proven key strategies behind some very successful POCs.
At IrisVR we ask every customer at the beginning of a POC: What problem are you trying to solve - and why? In forming a POC you never want to lose sight of this original question and answer. Whether you are building a 100 story superstructure, or a one bedroom home, laying a concrete foundation is often one of the most critical steps. Without a solid foundation, the rest of the project can prove to be disastrous.
For a successful POC, this is no different. For it to be successful, you always need to remember why you’re here in the first place. Are you looking for a better way to visualize your BIM Model? WHY? What are the flaws with traditional methods? What do you see as challenges to the program? Why are they there? How can you overcome those challenges? What is your desired state?
Let’s start with an example. Imagine you are looking at a solution to improve design review and coordination for a large healthcare project. You will first need to identify the shortcomings of current workflows and processes. For example, you may find that you need to incorporate a true 1:1 scale and provide a more immersive experience than traditional design review solutions offer.
As the project lead and tech evangelist - you are the driving force of change within your organization, so it’s your job to show the value of these new methods, and to prove it. For any POC to work, the proof must be quantifiable. This leads us to our next step: Goal Setting/Success Criteria
A common goal for a large number of companies during design coordination is reducing the number of RFI’s. At IrisVR we encourage our clients to take it further with S.M.A.R.T. (Specific, Measureable, Achievable, Realistic, and Time Bound) goals.
Specific: Have answers to the specifics of questions like - Who is the point person for the Mutual Success Plan (we will dive into this in depth in part two of this series), what is the success criteria, where and on which project will the software and hardware be deployed, and why - specifically, are you running the pilot program?
Measurable: There needs to be a way to quantify these goals. Saying 'I want to reduce RFIs is a great start, but getting specific with saying a 10% reduction in RFIs is better, because it aims to put a value on ROI, and gives concrete talking points when speaking to internal decision makers.
Achievable: Make your goals challenging, but not so challenging that they are impossible to meet. Reducing RFI’s by 25% would be a great target to try and meet - a marked improvement and something that would save a ton of time/budget throughout the project.
Relevant: Related to the POC itself, meeting demands of clients or overcoming current internal or project pain points. This is where there is some variability, let our team know if you’d like help refining this or any other aspect of your S.M.A.R.T goals.
Time-Bound: Establish either a specific date, or tie goals into a specific stage of project completion. Examples of this could be a due date like December 15th, or at 60% completion, or by the end of Fall.
I want to reduce the total number of RFI’s on this hospital project by 25% by June of 2021. I’m going to achieve this by carefully documenting the number of RFI’s submitted and comparing them to RFI’s submitted on our last 10 healthcare projects of similar size/scope.
Part II of this series on designing, project planning, conducting, empowering participants, and acting on a successful POC is now available, click below to keep reading.