Greg Goelkel, Solution Consultant

Purchasing new technology, an already complex process, is exacerbated by the thousands of offerings currently on the market. To overcome this challenge, many organizations execute a proof of concept (POC) during the purchasing evaluation. A POC tests how the technology in consideration integrates with an existing environment. The process gives organizations confidence to adopt new technology and/or fair warning as to what challenges must be solved before implementation.

Think of a POC like test driving a car. A car is a significant financial decision for many of us, just as implementing new technology is for an organization. You wouldn’t necessarily show up at a car dealership and make a spontaneous purchase without first testing the car. The same is true for organizations looking to buy procurement technology.

The advent of SaaS has enabled technology buyers to apply this same test drive approach in their purchasing decision through POC evaluations. Many organizations have noted the POC was the moment that provided the clarity they needed to pull the trigger on a purchase. However, it’s important to note that if the POC is not closely managed, it can be misleading and a false indicator of success.

Procurement and IT teams should keep a few key considerations in mind when executing and evaluating a POC to reap the full benefit:

  • Clearly define the concept you are trying to prove. It may sound obvious, but it’s worth articulating. You won’t get very far if you don’t know what you’re trying to prove. Comfort and navigation are both key considerations in driving a car and using a technology, and technology users, much like drivers, need to prioritize long-term use, not just short-term satisfaction. The overarching goal is to select a technology that satisfies diverse users, can be used across multiple business units and meets financial goals over the lifetime of the vendor relationship. You also need to be sure the solution considers everyday life and can handle the constantly changing requirements of your organization.
  • Determine how to measure success. Determining how to measure success during the POC is probably the most important element of any POC test. Success in a POC is no different than any other evaluation process: a clear set of quantifiable criteria needs to be set based on stakeholder input. This will bring clear results that can be communicated both internally and externally. It is also important to avoid falling into the trap of evaluating a set of standard scenarios to quantify results — success needs to be measured against real world everyday examples in your organization.
  • Allow users free time in the application. It is important for users to have off-road access during the POC for their own inspection and usage. To fully test an application and see if it will be successful and solve the needs of the organization, users need to experience it in their own environment on a day-to-day basis. Simply testing for ease of use doesn’t tell you if the solution will increase adoption, use and value. The team needs to manipulate the technology on their own terms and see how it can directly solve their unique problems. This helps make adoption and implementation more efficient and effective, and clarifies the value of the platform to the organization.

While POCs provide immense value during the purchase process, companies shouldn’t rely on them exclusively. Buyers should view a POC as a complement to a wider test of solutions to increase adoption, use and value.