2) How many company business re-sources are typical and what type of resource are they?

Company business resources have two key responsibilities: the first is to define the functional requirements for the system and the second is to validate that, when delivered, the system does what was requested. These two key functions require somewhat different resources.

First, defining system requirements needs the input of company-trusted subject-matter experts (SMEs) who know their domain thoroughly and can also represent future state requirements on behalf of the company.

These people are often expert users or key supervisory staff in the business operating units. Enough SMEs are required to cover all the key domains that will be affected by the project. For a policy system replacement that includes underwriting, policy service, and marketing. If the carrier writes a broad range of business, SMEs will be required to represent the specifics of key lines of business.

Part time expertise will be required from accounting, claims, compliance, and other business areas secondarily affected by the project.

The second key task—validating and verifying the accuracy and completeness of the new system's behavior—requires some overlapping skills and project involvement to maintain continuity in the planning and overall definition of testing criteria.

Then a small army of business analysts (BA) and quality assurance  analysts (QA) are required to undertake the painstaking work of testing the complexities of the new system. For what is considered a “typical” implementation a carrier may need five to 10 core SMEs and a like number of non-core SMEs; and between 10 and 20 BA and QA resources.

3) Why should a carrier consider a system integrator in this type of an install?

A third party system integrator (SI) may provide skills and resources to the project that are not available either in-house or from the software vendor.

System integrators come in different shapes and sizes. Some offer complete project management and oversight of all project resources including the software vendor and in-house staff.

This classic SI role is usually found on large and complex projects where the SI's prior knowledge of similar projects, project methodology, and discipline provides a major risk mitigator for the carrier. The other common SI role is that of staff augmentation where specific resources are provided to the project under the control of the in-house staff.

Both roles have their place but obviously an SI costs money and adds a management layer to the project so the carrier should first make a realistic assessment of software vendor and in-house capabilities and capacities before considering an SI.

4) Generally speaking, are software vendors good at implementations?

The vendor community is getting better at implementations as is the carrier community.

However, some vendors have good implementation track records and others do not. So the important message for the carrier is to find out how good the vendor they are interested in doing business with is at implementation.

This is best done by talking with as many existing clients as possible. Implementation success does not just mean going live; it also means being on time and budget and creating high customer-satisfaction ratings when it is completed.

5) What methodology works best for policy implementations, waterfall or agile? Explain the benefits of one over another.

The consensus is that fewer legacy system replacements fail than used to be the case. There are several reasons for this.

One reason is the adoption by an increasing number of vendors of the agile project methodology. Agile is a response to some obvious difficulties with the traditional waterfall methodology. Waterfall assumes a static environment, while agile assumes and allows for changes.

The time between users defining requirements and seeing a working system is months in the waterfall environment but weeks for agile.

The definition of requirements used in following a waterfall approach usually happens on pieces of paper, but in agile, users see the system every 30 days and therefore get a much better sense of how the finished system will look and behave.

For these reasons—with all else considered equal—agile is a superior way to develop and implement software. As a final comment it is no coincidence that the vendors of highly configurable systems use agile.

Given agile's 30-day delivery cycle, the system being delivered needs to be capable of delivering meaningful functionality with that frequency.

6) How do you plan a roll out: big bang or gradual?

A roll out plan must reflect the business drivers that funded the project in the first place. However, often those drivers will conflict with the project management principle of minimizing risk.

Risk minimization dictates that a gradual and controlled rollout follows a restricted pilot rollout, usually in low volume geographies and lines of business. But if the business needs to go live immediately with the system in a high-volume, high-profile market, then the project team must do what it can to support the business while controlling risk.

7) How do you plan change control, change that the new system has on the organization?

This is an area of the project which is not always recognized and hasn't been done well.

Carriers implement new systems because they favorably impact business processes, job functions and content, and timing and operational metrics so these types of changes should be planned.

The basic steps are to analyze system impacts, redesign processes and functions, communicate and train for change, and deploy a model office environment where trainers and advocates can be trained to roll out the system.

8) When should a carrier consider conversion of old data, and how much data should be converted?

This is another business driver versus project risk question. Getting the policy data out of the existing legacy system and into the new system requires data mapping, data cleansing, transformation, loading, and tracking. There are two basic methods for insurers to implement a conversion project: at renewal and in-force.

An at-renewal conversion is less risky but takes longer and an in-force conversion is the opposite. Few carriers choose the in-force route although it would be better from the business users' standpoint (assuming that it works flawlessly).

The biggest issues with an in-force conversion are that any differences between premium calculations in the old and new systems will throw the carriers finances out of balance; and secondly any errors that creep through happen in the whole book of business, or that chunk of policies which are converted en masse. For these reasons most carriers choose the at-renewal method.

On the issue of how much data, the minimum is the prior term policy image. The grey area is previous policy terms and expired policies. Whether policy history should be converted depends on the data objectives of the new system and the extent to which policy history is stored elsewhere, such as in a data warehouse.

9) What benefits have you seen clients realize (immediately) after implementing a new policy system?

This question is of course the most important and should be considered long and hard before the project is undertaken.

My favorite paraphrase is: “Why does the carrier want to do this risky and expensive project?” The best answer to this is somewhat circular in nature: The carrier should receive the benefits that were used to justify the system replacement in the first place.

These benefits usually fall into three categories: improved underwriting, operational efficiencies, and improved customer satisfaction. Improved underwriting can result from better rating (pricing) and better risk selection (loss avoidance).

Operational efficiencies may be found in reduced cycle times, straight-through processing, reduced manual administration tasks, and reduced training. Better service (both to agents and insureds)—as measured by faster, more accurate, and more complete service delivery—results in higher customer satisfaction ratings.  TD

George Grieve is CEO for CastleBay Consulting. Previously a CIO and still an acting consultant, he has spent much of the past 25 years with property/casualty insurers, assisting them in the search, selection, negotiation, and implementation of mission-critical, core insurance processing systems. He can be reached at 512-329-2619.

The content of “Shop Talk” is the responsibility of the author. Views and opinions are those of the author and do not necessarily represent those of Tech Decisions.