Best Practices for a Vendor Proof-of-Concept

Insurers who have been through the arduous process of whittling a long list of policy admin system vendors down to a short list, and then whittling a short list of vendors down to an even shorter list, often ask us how they can be sure they’ve made the right choice before investing potentially millions of dollars and multiple years in their decision. Engaging in an extended proof-of-concept is one way to test out a vendor, but it needs to be done the right way if it is going to truly demonstrate the system’s value. For a proof-of-concept to be successful, you need to make sure that you’re testing enough functionality, but also to keep it limited so that the goals are realistic. While Celent regularly works with insurers to define the scope and requirements of proofs-of-concept, in this post I’d like to talk about some of the more intangible factors for success. There are two ways to approach a vendor proof-of-concept, depending on whether you have selected one vendor and are putting them through a final test, or if you are still comparing multiple vendors and therefore have two proofs-of-concept going on at the same time. You’re better off if you can work with one vendor, as you can take the tests to a deeper level and have your resources focus exclusively on making it a success. You should consider installing the vendor’s system in your own data center, even if some of the development work they do during the POC is at their own site. It’s crucial to dedicate a full resource from your staff to be involved with the entire POC, ideally doing some of the modeling or integration work. It doesn’t help you if the vendor goes away for a month and returns with a finished model and tells you that it was “easy to do.” You need to understand exactly what kind of work is involved, how difficult it will be to manage once the vendor is no longer consulting with you, and how much time it will take to train business users on the system. In terms of duration, I’ve seen proofs-of-concept take anywhere from two weeks to three months. Any longer than three months and it’s no longer a proof-of-concept, but just a normal implementation with an “escape clause.” With one vendor, you should schedule the proof-of-concept phase for at least two months, but plan the work so that whatever you do can be put towards the true implementation if and when you choose to continue. Finally--especially if you are working with a single vendor--Celent is in favor of paying a fair price for the proof-of-concept phase. Paid proofs-of-concept are more successful. Committing money as well as resources signifies to the vendor that there is true involvement from the client, and it positions you to dedicate true resources. An unpaid POC is like playing poker without having to pay the ante. You might start off interested in the game but you won’t care as much about your cards. The reality is that a proof-of-concept won’t be successful without both the carrier and vendor working together, regardless of how strong a solution the vendor offers.