After a long and tedious formal RFP process you have finally selected a lead vendor. You sat through multiple demos and have confirmed references in hand, yet apprehension sets in when it is time to sign on the dotted line. You may find yourself asking, “Does the vendor have a clear understanding of our core requirements and demonstrate exactly how they would support all the components critical to our business?” or “Did we ever get a clear answer on how the vendor planned to solve for A, B or C?”
A proof of concept (POC) is utilized as a means to validate the feasibility of system capabilities and functionality on a small scale, and can be a very useful tool to get a level of comfort that the vendor can deliver the critical components needed to satisfy priority requirements before committing to enter into a contract . Unfortunately, the efficacy of a POC is often not understood until issues or gaps occur well into implementation. A poorly executed POC could result in wasted time and money, implementation delays, scope creep, strained vendor/provider relationships, or even a failed implementation.
Effective planning and communication are instrumental in executing a successful POC. When planning a POC, it is important to allocate enough time and resources to gather and communicate the required information at the appropriate level of detail. This not only promotes a mutual understanding of expectations going into the POC, it also ensures alignment on the anticipated outcome.
Over the years, I have been involved in the execution of dozens of POCs and have ironed out the steps that I’ve found lay the groundwork for POC success (see other great blogs on the topic from Mike Walker and Colleen Devine). Here are the steps I follow for every POC:
An effective POC starts with a clear list of objectives which are understood and agreed upon by both parties. What are you looking to get out of the POC? What functionality or capabilities would you like to see demonstrated? Think about use cases and be as specific as possible to ensure questions cannot be interpreted in multiple ways. Use your own terminology when framing questions and note differences once discussed with the vendor/provider. As mentioned above, the intent of a POC is to validate a sampling, not the entire system, therefore your objectives need to be targeted around what is most important and/or causes the most concern.
Work with the vendor/provider to ensure alignment on the data required to support the use case/questions. What data is needed, how much and over what period? Is history required? Where will the data be sourced from and how will it be provided? Are reports needed? If so, what data set is required and what are the output expectations?
Success criteria needs to be achievable within the POC timeline, with the resources assigned. What does the vendor/provider need to exhibit to deem the POC a success? What are the deal breakers? At the very least, this is the minimum that needs to be demonstrated to proceed with implementation.
It is almost a certainty that there will be a point in a POC where the vendor/provider seems to have the required capabilities, but you do not feel you have necessarily seen it proved out. This is where it is crucial to ask questions to validate the vendor/provider understands what is being requested of them. Ask to see the same capability with additional data, a different data set or across different processing days. Ask where data is coming from, how it is being calculated and what controls are in place. You do not need to know every detail happening behind the scenes, but you do need to ask enough questions to ensure you are comfortable with what is being demonstrated.
By taking the time to identify why you are doing the POC, what you are trying to accomplish and for what purpose, you can build out a plan for a more effective and comprehensive exercise. As each of the above components is defined, initiate discussions with the vendor/provider to ensure continued alignment on expectations both leading up to, and throughout, the POC. With a clearly defined plan, well thought out approach and ongoing communication, you will be able to get the most out of your proof of concept and therefore be in a better position to make a go/no go decision to proceed with implementation.