Like policy processing, the creation of a policy administration system is not linear. The worst thing a carrier can do when scoping a policy admin replacement project is divide it into dozens of small pieces, work each to completion, then try to fit them together. When it comes to building the technology to support policy admin, this traditional approach for complex problem solving is rarely useful; the requirements are simply too interrelated for it to work.

What can you do about it? When selecting a policy administration solution make sure it is architected with iterative, agile processes at its core, allowing users to interact with the system as they define the requirements. This process allows subtle refinements to be incorporated as the system is built, rather than at a more costly time down the line.

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

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

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

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

The overarching reality is that the most important system requirement is the one you haven't thought of yet. It is inevitable that over the life of the system, as well as, during the project, business needs will shift.  Product specifications and options change. Distribution methods evolve and expand. And inorganic growth through mergers and acquisitions necessitates adjustments throughout the policy admin system. A system built without these possibilities in mind can cause opportunities to be lost or squandered.

What can you do about it? Be certain that the policy administration solution you select was designed to embrace product evolution to allow and support changing structures – even ones that haven't been thought of yet.

Deadly Sin No. 4: Failing to recognize the impact of rule definition on system performance and maintainability

Over the years, it has become very clear that consideration needs to be given up front to the classes of rules that are required to support the uniquely complex demands of policy administration. Experience has taught us that multiple rules must be used alone or in combination to provide high performance and maintainable support for complex requirements.

Configuring rules requires the same higher-level thought as coding. If a solution only supports a single rule type, it's likely to perform poorly in the real world, as it forces every situation into the same paradigm. The complex requirements of a policy administration system necessitate multiple rule mechanisms for multiple situations.

What can you do about it? Make sure that your policy admin solution accommodates different types of rule processing situations with different rule constructs, including special processing. It should easily support broadly specified rules that need to be applied and evaluated quickly, as well as fine-grained rules that need to allow for a high degree of specificity.

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

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

What can you do about it? Make sure the policy administration solution you select was engineered with comprehensive integration architecture in mind allowing for seamless integration with any other internal or external systems through configuration – not coding. With the right vendor and solution, carriers can leverage outside systems and services to improve underwriting profitability and enhance customer experience.

Deadly Sin No. 6: Failing to anticipate a rules governance mechanism for managing changes

Rule changes are often predicated on other rule changes. But sometimes the order in which they are introduced needs to be changed while one or more are in flight. This fact has created endless bottlenecks in the development and evolution of traditional policy admin systems.

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

What can you do about it? Make sure your configurable and flexible policy administration solution is architected to support multi-threaded development and full traceability of all the changes. If it's not architected to support this, than even the most powerful and flexibly policy admin solution can be negated.

Deadly Sin No. 7: Failing to expect the unexpected

In the past, policy administration systems were developed based on a carrier's requirements at a specific point in time. These requirements were given to developers, who then worked to put the system into production. Typically, little thought was given to how often and in what ways these requirements might change over time.

Of course, change happens.  It could be a regulatory edict, the desire to limit exposure by suspending a particular product, an adjustment to the UI or switching third-party data service providers. It's impossible to fully predict what's coming in the future. And because traditional policy admin systems aren't equipped to easily accommodate change—both major adjustments and minor tweaks—initiatives can be handicapped.

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