Trials and Transformations: Test Driving Multi-Factor Authentication and Zero Trust Solutions
Does this sound familiar? “It’s just a trial. I have plenty of time. I’ll get to it when I get to it.” I’ve heard these things from my team in the past, and I hear them more now, given today’s culture of try before you buy. But then the trial’s over. The time’s gone. Then the team didn’t get to it, and it doesn’t happen.
How to Get The Most Out of Your Trial
If you are ready to learn how multi-factor authentication can prevent stolen stolen credentials and passwords from accessing the network 99.9% of the time, then you are ready to start your journey to zero trust.
This article tackles that head-on by sharing what I’ve seen work for trials and proof-of-concepts. It sounds intuitive, but the point of a trial or a POC is to prove the feasibility of a solution or the feasibility of a critical aspect of a solution. Typically when we are engaged in a trail you are trying to answer questions similar to the ones below:
Will this technology meet our specific use cases and unique needs?
Does the product perform as advertised?
How does the solution compare?
Will it provide intangible benefits, like improving productivity or a new way of doing things?
What will it take to get the solution in, up, and operational?
Answering these questions takes work before the trial, during, and afterwards. Running a POC is a project in and of itself. Let’s look at some winning practices.
Before the Trial
Involve people. We’ll want our champion and business stakeholders, of course. We’ll also need to loop in the IT team for support, and purchasing to understand their process. It is counterintuitive, but, we also need to include naysayers. Knowing and addressing concerns early on in the pilot strengthens the resulting business case.
Be specific. Pilot projects which understand the mindset of our stakeholders and document specific use cases succeed. Include quantitative measures such as time to setup, time to authenticate. Also, consider quantitative measures like ease of use and ease of administration. Finally, even though this is a technology pilot, be sure to include how this change supports the broader organization’s strategy and goals. Create an evaluation sheet with these considerations.
Schedule it. Every pilot I’ve seen run into trouble had one thing in common: not dedicating time to run the pilot like a project. If possible, get a project manager assigned. Plan the proof of concept, the technical environment, and the testing. Run the use cases, the evaluation sheet, and the plan by the people involved. Getting buy-in on the approach early on increases the support we’ll have on the final decision.
During the Trial
Take it for a test run. Stay focused on the defined use cases and success criteria. Set it up, integrate it, kick the tires, and take it for a test drive. Work through a complete use case and get any specific questions answered. There are a couple things to look out for here. First, keep the scope tight and be careful not to let the excitement carry us away from the plan. It’s not easy to do especially when we get into the details. Second, keep an eye on the clock. A month pilot, for example, should wrap up the initial testing in the first week or two.
Check in with the team. After spending a week or two running it through its paces, present back to the core team. Show a test case to our stakeholders and make sure the approach is resonating. In a separate meeting, bring in our secret weapon: the naysayers. Find out what concerns and questions they have early. Gather the feedback to evolve the approach and the story. It’s hard, but keep the evaluation criteria front of mind during these conversations to make a decision supported by the data.
Finish strong. With the final couple weeks of a month-long pilot, retest any use cases and answer any questions raised during the check-in. This is a good time to engage the vendor to get additional information and clarify any points. Begin preparing the final report out. We need to tell the story about how the pilot fits in the organization’s broader context, answers the technical need, and satisfies the use cases. Run it by a small set of the people involved to get early feedback.
After the Trial
Present the pilot. If not dedicating time to run the pilot like a project is the number one factor in pilots going sideways, the number two factor I’ve seen is not presenting the results. Seems odd, right? We’ve spent several weeks planning and executing on the pilot, only to fumble. But it makes sense in the broader context. Doing the work is fun. Presenting, for many of us, is less so. Moreover, operational concerns and the growing to-do list often gets in the way. Don’t let this happen. Find our best speaker, give them our best slide template (or borrow one from someone who successfully presents business cases), and schedule it. Establish the business reason, explain the evaluation and success criteria, and tell the story. Having run this by others during the pilot, we’ll be prepared to answer most questions that come up.
Decide on the direction. Gaining buy-in on the approach at the beginning simplifies gaining support for the decision at the end. Combining the data-driven approach of objective and subjective considerations with the storytelling makes for a more compelling presentation. If we clearly understood the problem we’re trying to solve, and have found the right tool for the job, the decision should be easy, right? Well. Not so fast. We think of pilots as Option A versus Option B. But in reality, it may be A versus B versus doing nothing. Be prepared to spend time running the decision to ground, getting IT and purchasing involved, and turning the decision into action.
Implement and execute. SaaS means Software-as-a-Service not Shelfware-as-a-Service. So there’s one final step in the pilot process. That step is actually applying the SaaS to the use case. To do this, we need three things. First, we need a clear hand-off between the person owning the pilot and the person owning the implementation. This means sharing what we’ve learned from the pilot, including not only about the tool, but also about the stakeholders and all the people involved. Second, we need a tighter partnership with the customer success team. And finally, we need a good plan.
Final Thoughts
The transition from trial to implementation to transformation should be seamless and smooth. This is even more critical when we are deploying security solutions across an organization. Regardless of whether we are going through a regular buying motion, or purchasing to address an emergency situation the vendor we work with needs to be there to provide support and have the tools and processes in place to help us be successful.
In this article, I’ve shared what I’ve done to succeed when planning, executing, and finishing a proof of concept. Make it about the business. Include people, not only champions but also naysayers. Be specific in our use cases and our success criteria. Do the work and tell the story. Finally, work to make the decision the right decision, by working to ensure the product delivers on our promise. In today’s culture of try before you buy, remember, it’s our team’s approach that produces results.
Try Duo For Free
Now you know how to make the most of it, try our free 30-day trial and see how easy it is to get started with Duo and secure your workforce, from anywhere and on any device.
