Skip to content

3 Tips to Keep your Policy Administration, Claims (or other large) Systems Implementation from Failing

April 22, 2013

Google ‘Policy Administration and Claims system implementations success rates’ and the results more than tell the real story.  After you scroll down the self-serving ‘studies’ and gushing customer write-ups supplied by consulting companies and vendors, real-world insights runs thinner than cheap wine.

Let’s first dimension the issues.  In P&C, Celent (an analyst firm) estimates 120 new Policy Administration implementations in 2013 and another 128 kicking off in 2014.  With an average price tag of $3M, per Tier 2-5 carrier per project, that’s $360M+ in total spend per year, plus the $100M+ a Tier 1 can spend.  Claims implementations are not much different and are often part of a larger transformation initiative since speed and ease of issuing the policy, and grief-free claims processing, both affect customer satisfaction, especially in Social Media where Millennials trust User Generated Experiences (UGE’s) more than brand promises, and nothing screams UGE like a claim.

In the P&C vertical, a frequently cited system implementation success rate is +/- 30% (we call it the ‘golden 30%’), and of that, about half fulfill their full, initial set of goals used to justify the initiative in the first place.  Putting some money behind the stats, over $250M is either wasted, or at best, marginally well spent.  Include Claims systems projects achieving less than planned results and the waste could even shock Washington.

Can this be avoided?  Rather than create another list of what can go wrong (the correct answer is “#$%*&^ everything”), here’s some food for thought based on our experiences on all major systems, including ERP, Claims and Policy Administration.

In the course of researching this posting to ensure I’m giving you sound input rather than truisms, I’ve read some ‘real insights’:

  • Pick the right vendor (sounds reasonable to me)
  • Make sure the consultants/implementors are experienced and competent (also sounds reasonable since the last time we hired incompetents it didn’t end up so well)
  • Make sure to use a strong PMO (since over 50% of PMOs are closed due to failure in their first years, that’s not encouraging. Should we add ‘PMO success’ as a potential risk for them to self-track?)
  • Stress interdepartmental cooperation and communication (when was the last time something was imposed on you and you blindly followed without saluting?)

And on and on…

To help bring some day-to-day insights into the conversation, here’s my contribution:

1 – Senior Management needs a realistic understanding of the current state of their IT organization

Most IT organizations have been gutted by either offshoring, which robs IT of its motivation or best talent (who leave for more committed companies), or by staff reductions.  In the former case, most in-depth architecture and code knowledge is in the hands of non-employees, 12 time zones away.  Remaining staff spends 90% of their time managing this offshore resource, not supplying technical competency.  Cost controls and status reports/emails replace technical thinking.  Project Management becomes a series of late night and early morning status calls, followed by Issues Logs and Status reports. Nothing much gets done except for an abundance of reporting.  IT’s SOP becomes CYA, and I actually heard a CIO tell a Global conference call based project review “I’m done being pressured into BS dates I know we can’t achieve, here’s the real situation”.  We were all relieved by the candor and reset our expectations accordingly.

For those companies choosing packaged software (almost all Tier 2-5’s and, now, some Tier 1 carriers as well), IT still plays a vital role in a PAS or Claims package implementation by supplying deep institutional knowledge of interfaces, externally facing portals, data models, data warehouses,  related BI tools, etc.  A&H carriers, for example, have extremely complex HIPAA driven rules regarding Protected Health Information, spanning patient identification, health status, payments and, adding complexity, who can view a claim and under what circumstances.  Our experience is for these complex rules to be hard coded into existing applications, making rule extraction for set-up in a packaged application’s external rules engine extremely difficult and time consuming, and requiring considerable IT resources. In addition, IT will have ongoing operations and configuration/change responsibilities, and so full knowledge transfer is necessary.

In our experience, using a hybrid model, run by the Business, staffed by IT with a consulting company or the vendor supplying just a few SMEs performing heavy-lifting during the early project stages, results in both a solid implementation and ongoing internal support capabilities.

2 – Understand what the Business needs and then take the build vs. buy decision.  Verify any vendor’s claim ‘we have optimized processes’ – it’s optimized for them, not necessarily for you.

Many industry analysts and whitepaper writers participate in ‘pay for play’ deals with the packaged software vendors, whereby a vendor pays a pretty substantial amount for the analyst firm to come over and review the package, check some references, express a point of view, etc.  They then resell this paid-for information as many times as they can, as well as incenting the listed vendors to buy self-promoting reprints.  Many large consulting firms, onshore and offshore, build business units with hundreds of billable resources dedicated to a particular vendor, and may receive a finder’s fee, as well. If using an outside consulting firm, ensure the Business Analysts are highly experienced and senior, catching nuances and differentiators, and are not high-margin template completers.   Particularly in the Tier 2-5 space, it is not unusual for a consulting company or a vendor’s Professional Services group, to sell with the A-Team, staff with the C-Team and then back-fill some B-players when you complain. These parties want to steer you towards what is best for them, and what is hopefully,  OK for you.

As Ronald Reagan said to Gorbachev, “trust but verify”.

Most evaluation templates are an exhaustive list of features, with some weighing, but these lists tend to be too high level, not capturing the process nuances describing your uniqueness.  We highly recommend mapping your 3-5 year Business-Side Strategic Plan to a set of end to end business processes, timing and data flows, and then derive your requirements.  Executing on the new process designs, either during set up or before (and not after) will produce the best operating ROI.

Building in-house can take several forms, but all should use the above mentioned business Business-side strategic plan based requirements.  We have seen an approach, particularly in Tier 2 and 3 companies, to leverage an incumbent vendor’s strong but dated package’s data model as the basis for future development, but the key is not just the data model, it’s empowering agility.  Wrapping legacy applications or adding new features to existing applications platforms, will most likely not produce results sufficient to justify the effort, and more importantly, it will most likely not justify the elapsed time. If your goal is extreme flexibility to 1 – take business off the street quickly, and/or 2 – respond quickly to market opening and opportunities, and/or 3 – adapt and respond to a new regulatory environment, then a new architecture is most likely required and the Business-side has to evaluate the cost of time as much as the proposed budget as it is not unusual for strategic IT projects to come in 3X over budget and 1.5-2X late, based on our experiences. Again, this has to reflect the Business-side strategic plan, otherwise, Management will have to plan based on how their processes and systems can deliver, which is backwards.

If a customer renews their policy 2X, they’re considered long-term (the most profitable category, obviously), but for most insureds, commercial or consumer, remaining a long-term customer is directly a result of how their claim is handled, and not their experience during the sales cycle with your friendly portal, app, agent or call center.  In this day of social media and broadcast media on speed, terrible experiences are transmitted globally in seconds.  For example, in NYC, after Sandy, there was a series of stories and Tweets, with business owners on camera, complaining about specific carriers of Business Interruption coverage disallowing claims since Con Ed, not the insured, suffered water damage.  Others complained about too long FNOL to settlement times.  Therefore, for Claims implementations and transformations, we highly recommend focusing equally on achieving the lowest possible processing costs with the end to end customer experience.  No portal or Mobile app can compensate for a connected consumer feeling they were mistreated due to (unbeknownst to them) systems inflexibility not allowing appropriate responses to unusual events.   Your technology direction will directly affect your ability to optimize the User Experience.

Optimizing the business processes is particularly beneficial in building a communications bridge and rapport between IT and the entire group of Business stakeholders, primarily to ensure there’s a common set of definitions and terms.  At project’s end, having been able to optimize processes to the Business’ strategic plans, break silos and align end-to-end flows  to maximize the long term relationship experience is the acid test of having chosen the correct vendor or approach.

3 – Turn your PMO into a Line function, plan for flexibility and delivery, not reporting

Many PMOs see the world as their being a sort of middleman, bridging the gaps between the Business and IT, focusing on reporting, scheduling meetings and issuing meeting minutes.  This form of PMO is not sufficiently empowered to run a program this complex.

Given the length of a significant IT program, a fixed 1000+ task plan in MS-Project is too inflexible to deal with the myriad of decisions and unknowns occurring on a daily basis.   While you need the end-goal and key dates since many key IT areas are tightly pre-booked for work (ex: testing, release schedules), planning should be focused into rolling 30 and 60 day detailed plans, with dovetailing into key gate dates in the future.

If possible, we would upgrade the PMO to the same status  as a General Contractor, responsible for the overall budget (and not just status reporting) and paying for results as described in the 30 and 90 day plans.  This also gives Senior Management ‘1 throat to choke’.

Ok, here’s the shameless plug, but at least I’m blatant about it.  We strongly suggest you have a senior Business-Side program manager added to the program daily leadership team, in addition to the vendor and IT project managers.  In addition to having real-time Business input into the hundreds of small decisions cumulatively affecting the end-product, this approach also ensures Senior Management has a true picture of program status, avoiding frustrations and comments, such as our having heard a very senior manager telling a room full of vendor, IT and business stakeholders “I no longer trust a single thing that woman tells me” (she was the IT-PMO leader who marginalized a weak Business-side parallel PMO).  This joint project management approach helps everyone since, in the 70% of cases where these projects are either shut down or heavily restructured, Senior Management’s loss of faith is the reoccurring triggering factor.

In recent studies, more than half of all business success today is based on agile product/market fit, recommendations, and posted customer experiences, and not advertising or features, deals or sales reps. Your new Claims or Policy Administration initiative, including process improvements, has to support this new paradigm. If it doesn’t, don’t be surprised if the Business-side forces the initiative into the failing 70%.

Richard Eichen is the Founder and Managing Principal of Return on Efficiency, LLC, and is one of their senior turnaround leaders/CROs, Program Rescue and Interim Executives with over 25 years’ experience reshaping companies, Operations, IT/Systems Integration and key initiatives. Return on Efficiency, LLC specializes in those companies and initiatives where technology is the primary means of service delivery and revenue creation.  He can be reached at


  1. williamryanx permalink

    The above mentioned tips given over policy administration systems seems like truly beneficial and if implemented in an appropriate manner, they will surely provide your desired output which will enable you gain huge amount of profits.

  2. These tips will really be beneficial for implementing in
    policy administration systems and it seems that they will provide more benefits if they are implemented in a right way.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: