John Pettit co-founded Adaptik and is president and CEO ofthe company.

Replacing a policy administration system is one of the mostimportant and difficult tasks an insurance carrier will undertake.When projects reach this magnitude, insurers need to recognize thepitfalls and how to deal with them.

To offer assistance in that area, here are, in no particularorder, the Seven Deadly Sins of Policy Administration.

Deadly Sin No. 1: Treating policy administration like aset of unrelated business requirements

Like policy processing, the creation of a policy administrationsystem is not linear. The worst thing a carrier can do when scopinga policy admin replacement project is divide it into dozens ofsmall pieces, work each to completion, then try to fit themtogether. When it comes to building the technology to supportpolicy admin, this traditional approach for complex problem solvingis rarely useful; the requirements are simply too interrelated forit to work.

What can you do about it? When selecting apolicy administration solution make sure it is architected withiterative, agile processes at its core, allowing users to interactwith the system as they define the requirements. This processallows subtle refinements to be incorporated as the system isbuilt, rather than at a more costly time down the line.

Deadly Sin No. 2: Designing a solution from within thecontext of a single product

As a way to control scope, it's common for carriers to focus thedevelopment of an entire policy administration solution on theneeds of a core product. The assumption is that focusing on asingle product will provide a base understanding for other productsand reduce development time. However, as products are added, theproblems with this "top-down" approach become apparent. Wedging newproducts into unnatural paradigms creates costly inefficiencies forthe development team and, in some cases, the end-user. Expensivecoding, recoding and testing efforts are often required to refinethe user experience, which prevents the carrier from leveraging thefull capabilities afforded by the original design of thesolution.

What can you do about it? Take a bottom-upapproach. Make sure your policy admin solution is built on afoundation of flexibility and adaptability, rather than a singlecore product. Such a broad-based approach makes the future additionof products and functionality a simple matter of configuration,rather than an expensive, time-consuming process.

Deadly Sin No. 3: Assuming you've designed the entiretyof the product

The overarching reality is that the most important systemrequirement is the one you haven't thought of yet. It is inevitablethat over the life of the system, as well as, during the project,business needs will shift.  Product specifications andoptions change. Distribution methods evolve and expand. Andinorganic growth through mergers and acquisitions necessitatesadjustments throughout the policy admin system. A system builtwithout these possibilities in mind can cause opportunities to belost or squandered.

What can you do about it? Be certain that thepolicy administration solution you select was designed to embraceproduct evolution to allow and support changing structures – evenones that haven't been thought of yet.

Deadly Sin No. 4: Failing to recognizethe impact of rule definition on system performance andmaintainability

Over the years, it has become very clear that considerationneeds to be given up front to the classes of rules that arerequired to support the uniquely complex demands of policyadministration. Experience has taught us that multiple rules mustbe used alone or in combination to provide high performance andmaintainable support for complex requirements.

Configuring rules requires the same higher-level thought ascoding. If a solution only supports a single rule type, it's likelyto perform poorly in the real world, as it forces every situationinto the same paradigm. The complex requirements of a policyadministration system necessitate multiple rule mechanisms formultiple situations.

What can you do about it? Make sure that yourpolicy admin solution accommodates different types of ruleprocessing situations with different rule constructs, includingspecial processing. It should easily support broadly specifiedrules that need to be applied and evaluated quickly, as well asfine-grained rules that need to allow for a high degree ofspecificity.

Deadly Sin No. 5: Failing to anticipate the evolvinglandscape of solutions

From predictive modeling systems to advanced forms, rating,underwriting and billing engines, to structured and unstructuredthird party data, the external services and data available toP&C carriers have never been better.  But, there is acatch, with traditional policy administration systems, it'sextremely difficult to integrate with outside systems and on top ofthat, it's also very costly. It can cost carriers as much as$250,000 each time their current policy administration system needsto be modified to connect to another system. Unfortunately that'snot the end of it, such integrations are typicallyversion-specific; they need to be re-written every time a piece ofsoftware is upgraded. The result is major on-going coding projectscosting the carrier millions.

What can you do about it? Make sure the policyadministration solution you select was engineered withcomprehensive integration architecture in mind allowing forseamless integration with any other internal or external systemsthrough configuration – not coding. With the right vendor andsolution, carriers can leverage outside systems and services toimprove underwriting profitability and enhance customerexperience.

Deadly Sin No. 6: Failing toanticipate a rules governance mechanism for managingchanges

Rule changes are often predicated on other rule changes. Butsometimes the order in which they are introduced needs to bechanged while one or more are in flight. This fact has createdendless bottlenecks in the development and evolution of traditionalpolicy admin systems.

Of course, simply moving to a flexible and configurable systemdoesn't automatically allow a carrier to clear such hurdles. Poorrules management capabilities in a modern system can also result inbottlenecks and hidden costs. Without a proper governance body andthe supporting rule versioning tools, product initiatives willinevitably need to be single-threaded, affecting the ROI of thesystem as a whole.

What can you do about it? Make sure yourconfigurable and flexible policy administration solution isarchitected to support multi-threaded development and fulltraceability of all the changes. If it's not architected to supportthis, than even the most powerful and flexibly policy adminsolution can be negated.

Deadly Sin No. 7: Failing to expect theunexpected

In the past, policy administration systems were developed basedon a carrier's requirements at a specific point in time. Theserequirements were given to developers, who then worked to put thesystem into production. Typically, little thought was given to howoften and in what ways these requirements might change overtime.

Of course, change happens.  It could be a regulatoryedict, the desire to limit exposure by suspending a particularproduct, an adjustment to the UI or switching third-party dataservice providers. It's impossible to fully predict what's comingin the future. And because traditional policy admin systems aren'tequipped to easily accommodate change—both major adjustments andminor tweaks—initiatives can be handicapped.

What can you do about it? Make sure your policyadministration solution is architected to react to common andunplanned changes in a timely and cost-effective way.