Try Before You Buy, With A Proof Of Concept

When well executed, a POC is a win-win for all involved, ensuring that the right expectations are set at the onset of the client-vendor relationship, which is critically important in the long-term success of any technology initiative. Once it is determined that a POC will be part of the evaluation process, the following five steps may prove beneficial.

Step 1: Develop a manageable short list of possible vendors/solutions.

For the insurer considering a "buy vs. build" approach for their software solution, working through the myriad existing software vendors can often be overwhelming.

To make the process more manageable, a laundry list of the high-level business and technical requirements should be developed. Business requirements may include such items as lines of business to support and whether you need black box rating or full policy processing.

Technical requirements may include the technical platform(s) the buyer is willing to consider, whether or not the solution needs to be Web-based, and if it needs to integrate with existing solutions.

After the first round of eliminations, an RFI (request for information) should be issued to the remaining vendors and product demonstrations should be scheduled. Oftentimes, the initial demonstration can be conducted via a Web-based approach, providing an informal forum where the buyer can evaluate the technology with the vendor from a remote location.

With the RFI and overview demo completed, the buyer should have a good vendor short list to begin an in-depth evaluation and analysis.

Step 2: Define a comprehensive specification.

While the RFI may have answered general questions pertaining to the initiative, buyers should take the time to document their requirements in detail. Included in the detailed requirements document would be product requirements (for example setting up and maintaining a product, calculations or rules) and requirements for workflow, including the workflow for different user types and product transaction behavior.

Buyers can then select a subset of the requirements to be used for the POC, making sure some of those test requirements are complex enough to validate the solutions depth and breadth of functionality and its flexibility to support some of the more challenging scenarios. For buyers who are looking for a solution that is both tactical and strategic, the solution should support a broad range of requirements (rules, lines of business).

The POC test scenarios should be provided to each vendor simultaneously, allowing an even playing field and providing the time for all vendors to review and deliver the test build.

Step 3: Manage the vendor finalists and set expectations of test and selection criteria.

Communication is the cornerstone of any good relationship with a vendor, and managing expectations on both sides (vendor and buyer) eliminates uncertainty during the process and keeps both parties focused on the same objectives. Good communication also relieves the buyer from many unnecessary and annoying vendor calls.

During the POC, the vendor is committed to getting the buyer all the required information and delivering the POC build on time. If additional information is required during the process, the buyer should be willing and able to quickly provide the information.

Giving as much attention to the communication and relationship during the evaluation period is just as important as the technical and functional fit of the software solution. After all, once the POC is completed, the buyer/vendor relationship is going to be an important part of the project's success.

Step 4: Test a variety of "what if" conditions during the POC.

An adequate delivery and a thorough POC will require time. As part of the POC, the vendor should review how the build was developed and demonstrate how they have addressed all of the buyer's requirements. The buyer should be prepared to challenge the vendor with questions on the details of the build process, what effort was required, and what portions may have been particularly challenging.

The requirements provided to the vendor are hopefully incorporated into the build, but what would happen if the requirements should change, as they will in the life of the actual project?

During the POC, the vendor should be prepared to test a variety of "what if" scenarios, representing typical changes that users would request. This process provides both the buyer and the vendor with insight into the effort and additional costs associated with change requests that might occur during the implementation project. Some changes may be done on-site, while others may need to be done at the vendor site.

Regardless of when and where the changes are made, a dialogue as to the methodology for change implementation should take place, including any anticipated resource requirements and associated costs.

Step 5: Ensure compatibility and integration with the current technology environment.

The POC process provides a buyer with a clear picture of the capabilities of the vendor product and, just as important, the limitations. Once the POC is completed, there is typically more work to do before a final decision is made.

Often, there will be legacy systems or other components that need to communicate with the new solution. In this situation, an integration test should be conducted to ensure a technological fit. Similar to the POC requirements, a series of integration tests should be defined to ensure successful communication between the technologies. In some instances, the buyer may need to use a middleware component or develop additional custom code to ensure successful interaction between the differing technologies.

At the conclusion of the POC process, all parties will have the same understanding of requirements, how well the vendor solution performs, and the software's strengths and weaknesses. In addition, working as a team through the POC should serve as the foundation of the good relationship and quality communications required for a long-term and successful partnership.

Wendy Corman is the business development officer of Duck Creek Technologies Inc., a provider of tools that support Web-based insurance technologies. She can be reached at wendycorman@duckcreektech.com.

Reproduced from National Underwriter Edition, September 23, 2004. Copyright 2004 by The National Underwriter Company in the serial publication. All rights reserved.Copyright in this article as an independent work may be held by the author.