Not all resource booking and meeting management software will meet the needs of your company. That’s why it’s important to do a proof of concept (POC) in order to determine how software will function in your organization.
A proof of concept, also known as a proof of principle, is a partial solution that involves a small number of users. The objective of a POC is to determine whether software satisfies certain requirements and to test the vendor’s claims. It entails setting up the software in-house to run on your machines and in your environment to ensure that it functions as expected. It’s no different from taking a car for a test drive before you buy it. Here are 5 steps to performing a successful proof of concept.
Perhaps you are performing a POC to test for the product’s usability, compatibility with existing servers, or resolution of a business-critical issue that affects your organization. Before contacting vendors and performing a POC, outline business requirements by seeking input from those on your team who will use or be affected by the software and document the requirements of your environment.
Define success metrics and the timeframe in which they should be achieved. If multiple stakeholders are involved, they likely have different success criteria. Make the rounds and talk with stakeholders to gather their expectations and create a single success criteria checklist.
After defining business requirements, research the vendors in the space and then contact them to find out if they have deployed their solutions in a similar environment. Ask them about how often they update their software and whether they offer support around the clock.
To ensure a successful POC, there needs to be more than a single sponsor of the project. At a minimum, the core team of stakeholders should include the following members:
Build a dedicated environment for testing. It can be a scaled-down version of your environment that functions similarly to your production environment. Dedicate resources to testing and installing the software for a certain number of days. Work with the vendor to review your test plan and ensure that you’re not missing anything.
A software vendor may expect to receive a sales order right after a POC, while it could take several months to get the buy-in needed to support a purchase order in your organization. Alternatively, you might be planning to perform additional POCs with other vendors before making your final decision. To build trust, agree on the next steps for both your organization and the software vendor. This will help to set clear expectations, as well as improve planning and resource prioritization for both parties.
Document how your lab environment is configured, in addition to documenting installation steps, test results, and findings and recommendations. Well-written documentation will make it easy for other teams to replicate the environment, as well as justify why certain decisions were made during the POC.
Product demos and sales presentations can only go so far—they are conducted in a safe, canned environment that the vendor provides and are often narrowly focused. To see how a product will perform in a real-world environment and get hands-on experience with the software, try doing a proof of concept. Performing a proof of concept will also allow you to evaluate the quality of a vendor’s technical support.
If you’re interested in doing a proof of concept with Add-On Products, please contact us to get started!