De-Risking an Enterprise Software Purchase
There are a lot of exciting things happening in legal technology, and you have finally made the case to start taking advantage of them. Whether you are ready to replace broken, clunky, or arcane systems or upgrade from a manual process, this is sure to be an exciting time. You are looking to engage long term with a new vendor and solution, so it’s important to make sure it’s a good fit. To help you validate this, you may want to do a proof of concept.
A proof of concept serves a few purposes. First, it allows you to validate that the system does what you were told it does. Second, it lets your users actually use the software, giving you a good idea of what your future usability and adoption will look like. Third, and perhaps most importantly, it lets you get to know your vendor.
While a proof of concept is often a great way to go, not all are created equal. To ensure you get the most out of your proof of concept, this article will explore the four critical phases:
- Internal Preparation
- Vendor Engagement
- The Proof of Concept
- Transition to Implementation
Internal Preparation
Remember, your goal with this is to find a software that is a good fit for your organization, so you have to begin with that in mind. Who in your company will this purchase affect, and to what degree? Consider who will be the day-to-day users, who will have ultimate responsibility for it from a functional and budgetary point of view, and who may need to support it. Making sure you have stakeholders from those different contingencies early on will align the groups and prevent speed bumps later on.
Now, why are you starting a purchase process for this? Make sure your business problem is well understood by your stakeholders, and that you have a defined scope for the project. For example, a project that is designed to reduce spend by bringing small cases in house might look very different from one that is designed to move all discovery from managed services to in-house.
Once you have defined your scope, you’ll have an idea of how difficult the change management and decision-making processes will be in the project. If you’re making massive changes, you may want to consider leveraging an in house change management team if you have them, or perhaps an expert consultant. Keep in mind that software vendors are generally experts in their software, not your business specifically. The vendor can often provide a lot of best practices and information as it relates to the parts of a business they frequently touch, but a consultant can get further into your specific requirements, designs, and processes. If you are going to engage a consultant, bringing them into the project early can reap significant benefits, as they can assist with designing the actual requirements to ensure they will suit your current and future needs.
Understanding your requirements is perhaps the most important part of this phase. You cannot be successful with your project if you don’t know what success looks like.
Listen to your stakeholders. The first items they talk about are the ones that are top of mind because they are frequent issues, but ask questions to understand not just current challenges, but opportunities for improvement. Design your requirements as items that are tangible and measurable. If you can’t measure it, again, it’s going to be hard to say whether or not it was a success. In this requirements list, identify its priority as well. You don’t need a strict ranking of importance (though some companies do choose to be this granular) but you should at a minimum know what your nice to haves are versus your must haves. Talk with your technical stakeholders during this process and make sure you have accounted for any technical or architectural requirements.
Now that you understand what you need, map out the rest of the process. It’s crucial to think about the project as a whole if you want to understand your timing. By when do you want to have a purchase made? If it’s 3 months from now, and your contracting process takes a month post-proof of concept, then you need to make sure you’re moving quickly enough that you can be done with the proof of concept itself within the next 2 months. This is also your decision point for whether or not you actually need to do a proof of concept. Is your requirements list a list you can validate in demonstrations and conversations with the vendor? If so, you can probably accelerate the project and get the software implemented faster.
Finally for this phase, remember that this is a time commitment. It’s not just the vendor assigning resources, your team will need to as well. Make sure stakeholders are prepared to devote some time, energy, and mental space during a testing period. Consider any technical resources as well as team members who may be in other departments, as this planning lets you avoid surprises or delays.
Vendor Engagement
Now that you have all the details of your project determined, it’s time to start the search for the right vendor. Chances are you already have a good understanding of the top vendors in the space, so augment that knowledge with a little research to catch the ones you might have missed, and send out your Request for Proposal (RFP). If you already have your top vendors in mind, you can skip the RFP process and move straight into demonstrations. Consider your network here, and ask people around you what systems they use, what they like, and what they don’t. Asking questions like what the vendor could have done better, and also what the company could have done better will help you learn from others’ experience.
This could be a whole separate paper, but at a minimum, your RFP should include the overall problem you’re trying to solve, the scope of the project, the timeline for the project, and your list of functional and technical requirements. Getting a Non-Disclosure Agreement (NDA) in place early in this stage will ensure that the vendor is able to provide you with all the technical information and audit reporting as part of their response. This is also a great place to ask about data ownership, maintenance, deletion assurances, and pricing.
Once you have received the RFP responses, take your semi-finalists into the demos stage. Depending on the complexity of your organization, you may be able to get everything you need from a vendor’s standard demos. If you have a large volume or lots of complexity, consider requesting demos of specific, real world use cases and scenarios. During these, make sure you ask a lot of questions! The more you understand the better you will be able to gauge fit.
The Proof of Concept
By the time you are at the proof of concept phase, you should be narrowed down to either your top potential vendor of choice, or your top 2-3. This is great, because the fewer vendors you need to conduct the full proof of concept with, the less time and resources you’ll need to devote to it.
First, consider the time you need to test all of your criteria. Most companies are able to get through testing all necessary workflows and functional requirements within a day or two, which makes scheduling and carving out time much more straightforward than more flexible open-ended testing periods. A short timeline also helps make sure your stakeholders are engaged the full duration of testing, and also helps keep you on track with your timing for the overall project.
Use as much “real” data as possible. For legal hold projects, provide your standard hold language and questionnaires, so that you can see exactly how YOUR data will look in the system. For review projects, vendors will always have sample sets for you to use, but using those might not give you the full picture. Consider unique, legacy, or specialized document types you might deal with, and leverage a data set that will allow you to test these.
Leave room in your testing for “hard” requirements such as those technical and functional must haves that you have identified, but also “soft” requirements. Find a way for users to rate the look, feel, and ease of use of the software, as well as the vendor themselves. Making sure the people, culture, and overall business are aligned to yours will help facilitate a smooth implementation and business relationship.
Focus on the software, not the integrations between it and existing systems. Including integrations as part of the proof of concept scope tends to add a lot of unnecessary time and resourcing. Most integrations tend to be relatively common and straightforward, so try to validate these through references as opposed to hands on testing.
You are nearing your decision now, so it’s a great time to level set on next steps. Communicate to the vendor what comes next. If it’s a technical or architectural review, a heads up will allow them to start compiling the necessary documentation. From the vendor, you should expect details about how the ongoing partnership works, and what implementation and data migration timelines look like, as well as ongoing maintenance, updates, and support.
Transition to Implementation
It is not the outcome anyone wants, but remember that not all proof of concepts end in a selection. That’s okay. It’s better to fail fast then make the wrong decision and suffer through the ramifications of that for years to come. If you haven’t found the right fit, or the organization is not ready to change in this area, you may need to cancel or delay the project. If this happens, make sure you keep all the records from this process, so that you can leverage work done when you’re ready to move forward.
The best possible outcome of a successful proof of concept is a quick decision that allows you to move to implementation. The faster you are able to move on from the pilot phase to actual implementation, the less knowledge will be lost across both your internal team and the vendor team.
Make sure internally and on the vendor side you are memorializing work that has already been done, and make sure training is part of the process to set you up for success.
Finally, celebrate! It takes a lot of time and energy to get to this point, so take a moment to reflect and have pride in what you’ve been able to accomplish.
Jennifer Bantelman
Senior Director, Solutions Engineering
Jennifer is a technologist focused on strategy, customer experience, workflow, process improvement, and product in the legal tech industry. She has worked in software and technology for over a decade, and holds an M.A. in Strategic Communication. She currently leads Solutions Engineering at Zapproved, where she ensures product feature functionality and technical capabilities are designed and implemented in ways that solve real world problems. Jennifer is a speaker and content contributor on a variety of technology, data preservation and ediscovery issues, and is the Chair of the PREX Conference.
