This article is the final article in a three-part series on starting your Policy Administration System modernization project the right way.
How to Kick-Start Policy Administration System Modernization: Part 1
How to Kick-Start Policy Administration System Modernization: Part 2
How to Kick-Start Policy Administration System Modernization: Part 3
In this installment we identify pitfalls and opportunities to watch out for as you move from evaluation to ultimate approval of your project, based on our 25 years’ experience in the industry.
From evaluation to project approval #
Identifying your company’s modernization project requirements and then finding suitable vendors through an RFI/RFP process is only half the battle in preparing to modernize. The next steps in the vendor selection process are critical. In this phase, you need to pivot from information gathering to confirming that the vendor you will eventually work with can actually deliver on their promises.
Failure to prove that your chosen vendor has a solid implementation history creates risk that your policy administration system modernization will suffer delays, implementation problems or budget overruns. In the worst cases, even overall project failure is not unheard of.
To avoid that fate, take advantage of what we have learned working on these types of core insurance modernization projects over the last twenty-five years—starting with evaluating vendor capabilities.
Step 1: Effectively evaluate software and implementation capabilities #
After the RFP process is complete, the next step in your selection process is to evaluate potential vendors’ software and their ability to implement it. In this step the goal is to validate and verify the answers in the vendor’s proposal.
To make this step worthwhile, it’s important to prepare a list of questions for their previous clients that probe into the vendor’s ability to deliver on what they claim to be able to do.
You’ll want to know:
- What was their relationship like?
- What they were like to work with? Did they send an experienced team?
- Did they stay on budget and meet all deadlines?
- Was their implementation plan well thought out to cover all the bases and provide contingencies?
- Did they deliver on all responsibilities at or above expectations?
Many companies don’t even ask about implementation capabilities. That can inject risk into your project because, even if you bought the best insurance software, a poor implementation will cause your project to fail. Make sure to ask about the implementation team’s capabilities, expertise and success ratings. And, make sure to evaluate a potential vendor’s data migration capabilities and tools in order to mitigate the risks of data loss or corruption during the migration to the new system.
Ask for concrete examples where possible. Probe to uncover unexpected challenges that may have arisen during the client’s project. Why did they happen? How did the vendor respond?
These conversations should go beyond mere reference checks. They are your best chance to see what has been implemented for real, versus what the vendor says they can do. It’s best to confirm vendor claims at this stage before you so that you can be sure of their capabilities before engaging in the more intensive later steps in the selection process.
This is your chance to validate if the vendors still in the running are good long-term partners who can deliver what you need and eliminate any who don’t live up to their advance billing—before Proof of Concept.
Spoiler alert: You may have your new platform for as long as you had the legacy systems #
In our experience, one of the most important aspects of effective vendor selection is often overlooked. Companies judge vendors based on how they will meet the needs of today. But they should be looking at whether or not a potential solution has the best chance of still being useful and relevant in 20 years.
Keep in mind that many of the legacy systems you are looking to replace have probably been around for 30 years or more—replacement policy administration solutions should be considered against a similar time horizon.
And that means looking beyond just what you need today and considering things like:
- How strong and flexible is the platform?
- How stable and large is the development team?
- Is the support adequate to meet future needs?
- Is the vendor able to be a strong partner in maintaining and developing the system over the entire length of its lifecycle?
Get the most from vendor demos #
Once software and implementation capabilities have been evaluated, the next step is to invite potential vendors to present demonstrations of their platform in action. But not just any demos.
The best way to get the most out of vendor demos is for you to outline the scenario you want them to follow. This forces them to do some work to prepare for a scenario which is unique to your situation, rather than whatever would be most advantageous to them. Not only do you get a better insight into what they can do and how they do it, you also get a read on how serious they are about the opportunity based on how much work they put into the demo.
Tip: Conduct separate IT and Business demos #
A lot of the modernization work we do has the express goal of uniting business and IT—enabling them to work more efficiently and effectively in collaboration. So why separate the two camps during demos?
At this stage of the process, the company is starting to get into the details important to their side of the business. IT demos are technical and deal with a lot of criteria that are not important to the business units. They need their own forum to evaluate technology and vendor capability. An IT specific demo is the best way for them to reassure themselves that the criteria important to them will be met. IT buy-in to the ultimate vendor choice will rely on their confidence that tech is supported, security will not be an issue, and that IT resources won’t be strained.
Similarly, you want your business leaders and teams to take ownership of the project. The last thing you need is for them to raise objections later in the selection process, or even during the project itself, because they didn’t have a chance to address all their concerns. Keeping the IT and Business demos separate at this stage prevents the meeting from getting strangled by a thicket of technical questions not relevant to the business side.
Design the best Proof of Concept #
Following the demo phase of the process, the best practice for vendor selection is to engage two finalists in a Proof of Concept (PoC). In this stage, companies ask vendors to create a solution that proves they can meet the project goals.
Here, you have a choice to make in terms of whether you ask both finalists to complete the PoC. Although conducting two POCs can be time consuming and more expensive, it will decrease the risk of making a larger mistake during implementation. It basically gives you a ‘go-to’ option (the vendor you feel is the absolute best choice) and a ‘fallback’ option (one you can rely on to step in and perform well if the first vendor fails at any point).
On the other hand, conducting multiple POCs with different vendors at the same time can be counterproductive. If the carrier team cannot focus on more than one initiative at the same time, then it’s best to start with one vendor PoC, fallback to a second vendor only if the POC fails.
Tip: Manage the scope of the PoC #
Just as we discussed in the RFI/RFP stage, companies often make a critical mistake by asking too much from the vendor. In the RFP, the problem was asking too many questions, creating unnecessary work for everyone. In this case, the issue is that companies create a brief for the PoC that would, in essence, require the vendor to complete almost the entire project. That’s too big an ask for the vendor and creates high demands on your own company before the actual project has even been approved.
A better solution is to define three key functionalities you expect the vendor to be able to deliver with minimal development or configuration. Make these proof points specific to your particular products—for example, “premium calculation for my ACME SIUL policies” or “Generate underwriting requirements according to my grid.”
To see how the vendor performs when stretched, also ask them to provide three functionalities that you believe they don’t currently have. This enables you to see how the vendor performs when faced with having to perform custom work or more complex configuration.
Tip: Pay vendors to complete your POC #
If you are able to pay vendors for the work they do at the POC stage, they won’t have any excuses for not completing parts of the task or not executing well. As a rule of thumb, POCs may cost 1-2% of the total project cost—so, $100-200k on a 10-million-dollar project, per vendor.
Obtain project approval #
The last step in the vendor selection process is to obtain final approval for your modernization project. The level of approval needed for your project will vary depending the size of the project and your company. Because modernization projects can involve millions of dollars in investment over several years, multiple levels of management are usually required to sign-off, including the board of directors.
When creating the business case for your modernization project, make sure to consider all aspects of the proposed solution— everything from costs and timing, to data migration implications, to the long-term stability of the platform and the vendor. Take into account both ‘hard’ measures like costs, projected savings and potential revenue increases. But, also pay attention to the intangibles, like the benefits of putting control in the hands of the business lines and reducing their dependency on IT to make product changes.
(We will examine how to build a business case for modernization in our upcoming eBook. Subscribe below and we’ll let you know when it is released).
Tip: Build a compelling business case that anticipates likely concerns #
In many cases, companies underestimate the difficulty of successfully getting the needed approvals. The number of intangibles involved can make it difficult to build a case that is compelling enough for management. The fact that insurance is by definition an industry built on mitigating risk, only makes the situation harder. Because of this, management’s default stance is usually to avoid introducing risk due to significant spending, disrupting daily operations for an extended period and or migrating critical data. That makes building a winning case more difficult—but not impossible.
Because of this, management’s default stance is usually to avoid introducing risk due to significant spending, disrupting daily operations for an extended period and or migrating critical data. That makes building a winning case more difficult—but not impossible.
To make the approval process easier, make sure to anticipate the concerns management may have during your selection process. Look for vendors who have solutions that offset known risks. Ask the vendor to participate in the presentations to management during the approval process. They should be able to speak to how they eliminate risk and help quantify the benefits of the new platform.
Wrap up #
Choosing the right vendor for your modernization project doesn’t have to be a risky endeavor. Use the tips based on our 25 years of experience in modernization to streamline your process and avoid potential pitfalls. If you design and carry out your kick-off, RFP, evaluation and approval steps correctly, you will not only save time and effort, but ultimately make a better decision on the right vendor/partner.
The quality of your vendor selection process will determine the quality of your modernization project. Picking the right partner for the right reasons, will help ensure that your project meets your clearly defined objectives, on time and on budget.
