Close Close
Sign In
Newsletters
Popular Financial Topics Discover relevant content from across the suite of ALM legal publications From the Industry More content from ThinkAdvisor and select sponsors Investment Advisor Issue Gallery Read digital editions of Investment Advisor Magazine Tax Facts Get clear, current, and reliable answers to pressing tax questions
Luminaries Awards
Podcast Center Video Center Webcasts Resource Center Events
About ThinkAdvisor Contact Us Advertise With Us Asset & Logo Licensing Sitemap Terms of Service Privacy Policy Copyright © 2024 ALM Global, LLC. All Rights Reserved.
ThinkAdvisor

Technology > Marketing Technology

Try Before You Buy, With A Proof Of Concept

By Wendy Corman

X
Your article was successfully shared with the contacts you provided.

Following a 5-step process can prove beneficial for purchasers

Before investing a company’s precious IT dollars in new technology solutions, buyers should proceed with caution and perform due diligence through a proof of concept (POC) with their vendor finalists.

By investing a little time and effort to ensure that the technology (and the vendor) will meet the company’s needs, buyers are better able to mitigate any associated risk and make the most informed decision. In addition, vendors will have the opportunity to demonstrate that what they are selling is indeed what the buyer will receive upon contract, in regard to both products and services.

Essentially, this ‘try before you buy’ POC approach enables the buyer to evaluate the technology, the solution and the ability of the vendor to partner effectively with the organization–all critical elements to a successful technology/software implementation.

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 its software solution, working through the myriad of existing software vendors often can 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.

This high-level list of requirements will assist in narrowing the vendors into a manageable list.

After the first round of eliminations, an RFI should be issued to the remaining vendors and overview product demonstrations should be scheduled. Often, 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–a cost- and time-effective process for both.

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. Whether or not the buyer is considering a POC, the more specifics that can be provided to the vendor, the better the vendor can demonstrate its solution “fit” for the target environment.

Included in the detailed requirements document would be product requirements (e.g., 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 then can 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 solution’s 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, they should be looking for a solution that supports 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 provide the information quickly, respecting the vendor’s resources and its time.

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 ongoing 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 it has 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 onsite, 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.

A POC process is invaluable for both the buyer and the vendor. 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.

When it comes to selecting a new technology solution, the saying “a penny wise, and a pound foolish” might apply. In the long run, taking the time to conduct a thorough POC will most likely save time, money and a lot of aggravation.

Wendy Corman is the business development officer of Duck Creek Technologies, Inc., a provider of tools-based technology to support Web-based insurance technologies. She can be reached at [email protected].

NOT FOR REPRINT

© 2024 ALM Global, LLC, All Rights Reserved. Request academic re-use from www.copyright.com. All other uses, submit a request to [email protected]. For more information visit Asset & Logo Licensing.