(Image source: prettysleepy1.)
So, you’re an insurance carrier or distributor and you need a new software solution. Compensation management will be used for the purpose of this discussion, but it could easily be policy management, claims, billing, or any other core application critical to running your business.
What are the first steps? Whom do you talk to? A web search will bring up a myriad of vendors and some sites like Capterra will attempt to list them all and give you some selection guidance; however, unless key vendor customers have gone to the site, made recommendations, and rated the solution fairly, you probably won’t get anything valuable from this exercise. You might see a reference from “Kathy A—comp analyst” from an unknown company who said the software was “difficult to use.” Does anyone know anything about “Kathy A”? Did she attend the system training offered? Was she involved in setting up the solution or system rules? Possibly not, so this type of recommendation has the potential to be highly misleading.
Industry Analysts, Personal Contacts and SIs
A better starting point might be industry analysts, but you need to be careful about the choices you make there as well. For example, Gartner is well known for their Magic Quadrants and Hype Cycles, but unfortunately, they don’t take a vertical industry focus for commissions. They do this because vendors need to sell their products across three or more core verticals to be considered in their vendor evaluations. Specialist vendors with deep expertise in a vertical industry like insurance can’t make the Gartner evaluation list regardless of how successful they are. It is better to look at analysts who focus more on your industry vertical. Celent and Novarica have analysts dedicated to the insurance space with deep knowledge of key vendors.
Another point of reference would be the advisory arm of large systems integrators such as Deloitte, PwC, Cognizant, EY, and others with experience implementing the solution you are looking for. There are also specialist consulting organizations that implement certain products in the insurance industry. These external advisory organizations typically provide strategic advice and implement software solutions from multiple vendors. These organizations can provide great insight into the complexities, advantages, and disadvantages of one solution over another.
Finally, there is one source of advice that shouldn’t be ignored: your industry and personal networks. Reach out to the people you know and ask for advice. See if you can engage in discussions on who they evaluated, why they made their final selection, and their implementation experience with the vendor and chosen solution.
Let’s assume you have a short-list of potential vendors. What comes next? Traditional methodology suggests the release of an RFI (Request for Information) followed by an RFP (Request for Proposal) that is normally followed by a vendor shoot-out of features and functions. This is a tried and tested approach, but one that unfortunately wastes a lot of time and resources and doesn’t really lead to a better selection, just a well-documented one.
It is highly unlikely that a vendor will be eliminated after evaluation of an RFI because all vendors will be able to answer your questions and put a fairly decent spin on their capabilities. Vendors can provide solid responses to RFI questions about annual revenue, staffing, methodology, customer references, etc. All vendors will put forward their best references and highlight the value of their methodologies, so no real differentiators there. A small vendor with a stellar reputation is rarely eliminated in an RFI, so are these questions truly helpful in determining your selection? Probably not, so many organizations pass this step and go straight to RFP.
Some organizations go to great lengths to release a comprehensive RFP. The RFP typically documents all the features and functions you have currently, along with the additional elements required in a new solution. This information is gathered by internal meetings or surveys of staff over many months and compiled into a large document for vendor distribution. The document will include sections on system security, detailed functional requirements, technical requirements, implementation methodology, and more. Hundreds and sometimes thousands of questions are used to help you differentiate the potential vendors.
So, let’s get to the big issue with the RFP process, expose some vendor secrets, and explain why it is largely a waste of time. When it comes to the way the vendor answers questions, it is all a matter of vendor interpretation, and there’s nothing you can do about it regardless of how clever you think you are being with your RFP questions. An example of this is the question “Can your system calculate retro-active payments?” with response categories including: (a) Out of box; (b) Requires some configuration; (c) Requires heavy configuration; (d) Requires customization; (e) Not available. Clever, you think. The vendor must declare the degree of fit with the requirement and explain how much effort is required to configure the functionality during implementation. Now let’s put our vendor hat on and look at the logic that can be used to answer the question, “Do we meet the Out of Box requirement?“ Well, provided the customer can provide us with a set of separate transactions identified as retro, the retro period is only one month. The calculation is straight premium multiplied by a flat percentage, and it only impacts the current agent on the policy. No problem—the vendor thinks—we have this out of box functionality, so we’ll give it a big “(a) Out of box” response. What the question does not ask is, “What is required to do a retroactive calculation going back 18 months and re-distributing commissions or clawing back any commissions paid from everyone involved in the deal?” It’s not just about whether the function exists; the questions should clarify the limitations of the function, steps involved in doing it, and the degree of difficulty involved in using it.
I don’t want to disparage any vendor. I have worked with many over the years and most are highly ethical. However, experience suggests no vendor is going to admit at the RFP stage that they have a function that is extremely limited or has a high degree of difficulty to use. If they can check the box based on how the question was asked, they will check it. So how can you truly evaluate vendors without an RFP to separate them? Price is the last thing you want to use as elimination criteria at this stage. A solution with a high price-point is usually highly developed, and theoretically, should deliver a far greater degree of useful functionality in the first phase of your implementation project than one where most functions require heavy configuration. The “under developed system” vendor will likely take the position that the customer requirement is far more complex than stated in the RFP, so a scope change request is required at an additional cost. Beware if you go down the RFP track and think you have your requirements defined accurately.
The other issue with an RFP is that you’re documenting your current system. Your current system was probably developed over a decade ago, with processes largely developed around the restrictions of available technology at the time. Do you really want to ask vendors to implement their shiny new solution and configure it to replicate all the functional dyslexia you have currently, or is it time to take a fresh look at everything you’re doing and see if there’s a better way? I would hope you would agree with the latter, and a bit of medical advice might be prudent. With a serious issue, let’s not make the dangerous decision to self-diagnose; it’s time to get some professional advice.
A Better Approach
In my experience, having been engaged in hundreds of these evaluations over the years, a better and more valuable approach is as follows:
Bring in a third-party external advisor that has seen the issue in many organizations, has a team of experienced consultants in the field, and has been engaged in delivering state of the art solutions to customers with a similar profile to your own organization. Most likely, this will be one of the large systems integrator firms or specialist consulting organizations mentioned earlier. This alone will narrow the field to two to three vendors the advisors know can deliver and save you from wasting time on vendors that really shouldn’t be in the mix, regardless of how well they’re connected with your CEO.
A series of workshops will allow the external advisors to map your current state technology and processes end-to-end and make recommendations for potential change with future state technology and process maps. For example, the commissions process should not just be reviewed from the time an extract from the policy or billing system hits the commission system. This process should be reviewed from the point at which an agent submits a policy application to the time the agent accepts the commission payment calculations, year-to-date commissions and associated performance reports. The evaluation should also cover any branches or extensions of the process, such as how terminations or vesting are handled. The process should consider the way the agent writes business, submits information, and wants to receive information, as well as the commission process and results that may feed multiple downstream systems.
Having developed a roadmap for potentially improving the end-to-end process, the organization should focus on areas that have significant impact on the process, introduce high risk, or involve a high degree of complexity or manual intervention. These are the areas you want to focus on and develop end-to-end scenarios for your vendors to discuss and demonstrate to you. Not only will you be able to see the functionality, but you will be able to see how easy or difficult it is to perform your most complex processes. These end-to-end scenarios will naturally incorporate hundreds of individual functional points that are essential to the vendor’s ability to deliver the scenarios and generate expected results. The scenarios can also include configuration sections where the vendor is required to show how they configured the solution to meet the requirements, exposing their configuration tools and methods. Please allow enough time for a seriously deep evaluation. Two to three hours is not enough for a complex solution that you will want to live with for at least the next 10 years. Give each vendor a full day, or two to three days depending on the scenarios that have been developed. The deeper you go with a smaller group of vendors, the better your decision will be.
The external advisors who helped you develop these scenarios can also be engaged to evaluate the vendor presentation of their solutions and demonstrations and offer their expert advice on the most appropriate solution. They can often spot when a vendor has skimmed over the surface of a function they don’t want to discuss because it might expose a potential weakness. Remember, they have probably seen this vendor present a dozen times or more, so they usually have a good handle on what they can or can’t do. This process helps you to get to the best solutions quickly and effectively and will eliminate the need to have your internal resources gather thousands of functional points typically seen in RFPs that are open to vendor interpretation.
Having short-listed your potential vendors after scenario-based demonstrations, you can then issue the security, technical, and financial requirements for responses, and request a proposal based on delivery of the scenarios demonstrated, knowing each of the scenarios included hundreds of functional elements.
In most cases a clear winner will be easily identified, but in the case where the selection is close, you can then defer to the customer references, technical capabilities, company stability, and of course, pricing for the solution. You can also reference implementation and post-implementation services and compare them over a three to five- year time frame.
The cost savings from not going through the traditional RFI and RFP process should easily justify the benefits of engaging a third party to run this type of evaluation, and usually results in critical process improvement that rarely comes out of the traditional model.
Selecting an Implementation Partner
The final decision to make is selecting a vendor to implement the solution. Often the vendor will have a complete team or recommend specific systems integrators. My advice is to utilize the expertise of the organization that helped you develop the future state and guided you through the selection, even if it is just an ongoing advisory role or to assist with project checkpoints. You will find most advisory firms have strong program management teams and implementation services that may compliment your vendor team and reduce a significant amount of the burden on your internal staff. In some cases, you may want to put the implementation services out for a separate bid to ensure no favoritism is directed towards a particular organization. This also helps to satisfy internal audit requirements in some organizations.
The RFI/RFP process can work, but typically you’ll get to your selection faster with more confidence and deeper understanding of the capabilities of your vendors by engaging the right expertise and driving through a scenario-based process. In the age of Agile project delivery, this “agile” selection process approach will deliver great benefits over the more traditional approach.
Complex Software Implementations Can Take A Village—Here’s Why