Focussing Development

The Gartner Group estimates that approximately 3.5% of an industry’s revenues are invested in information technology. For the property and casualty insurance industry in Canada, with about $22 billion in revenues, that means roughly $770 million will be spent on IT this year.

This, however, is not the whole picture as “investment” is an interpretive word. IT budgets for insurers are typically divided into 50% for maintenance (legacy systems, software upgrades, etc.) and 50% for new projects. Applying the math, this equals to about $400 million for new projects.

Today, it is fair to say that the insurance industry has become quite proficient at maintenance: insurers have found ways to get the most out of systems developed in the 1970s to1990s. There is, however, an increasing realization of these systems’ limitations. That is where new projects come in. And, this represents the real challenge for insurers. New applications could mean anything from responding quickly to a business unit need, creating an application for front-line distribution or automating underwriting rules. Most insurers would acknowledge that the time and resources spent on identifying, creating and actually producing new IT applications need major work

PROJECT PITFALLS

Why do new IT projects pose such a challenge? There are many possible answers. The issue may lie within a company’s IT architecture. It could be that new projects are not successfully integrated with existing technology and processes, or it may be simply that business users and IT staff are not working from “the same page”. Whatever the answer, the frustration with new applications is the main reason behind the buzzwords in IT today: “business metrics”, “gate review process”, “portfolio management”, “total value opportunity”, etc. However, it is all really about return on investment (ROI): “show me the results”.

Clearly, insurers are paying a lot more attention to how new projects are managed and executed. But, are they looking at IT development? Why is it that words such as “on time, on cost and on scope” are not heard often enough in project steering boardrooms? Are there flaws in the very process of developing technology applications for today’s business opportunities? We think so, and all you have to do is look at traditional methods of IT development to figure out why.

DEVELOPMENT PROCESS

Here is what the typical development process for new applications looks like at an insurance company. Business users identify specific needs or requirements, often related to efficiency, service or product issues. They put these needs into a standard English document and hand it off to the IT department. IT takes those needs, interprets them and develops a prototype that uses extensive (and often hard-coded) programming.

IT goes back to the business users in what we call “conference room pilots.” They discuss the prototype, see if the program actually matches the specific business requirements and figure out glitches in development. Inevitably, there are revisions, or even series of revisions, to the programming – a process known as “cycling” that can take anywhere from months to years. Finally, an application is ready for testing and pre-production, eventually going live. If an insurer is lucky, this process takes about a year.

The weaknesses of this traditional approach to application development are clear. The first is the amount of time it takes. Budgeting for new IT projects is typically allocated according to business priorities. If a business unit is waiting several months for an application on an urgent service issue, the process is not working. What also happens to the application when, a year later, the business requirements have changed? You guessed it: more cycling, more waiting.

The second disadvantage is how business and IT resources are used. Instead of spending time running the business, analysts are often huddled in conference rooms trying to figure out how an application can match their needs. Instead of moving forward with other new projects, IT is left speculating on business requirements and revising hard-coded programs.

The third weakness with traditional development techniques is the financial cost. It is difficult to tell how much extra money insurance companies are spending on prolonged application development. But, when you hear terms like “slippage” and “cost overruns”, it is usually related to new technology projects.

NEW THINKING

What if the process was drastically changed? Insurance companies have an opportunity to step back and look at both techniques and technology in application development. The methodology of how you create technology solutions ranges from analysis to definition to verification to production. If proper techniques are combined with modern technology, you have the proven potential for reduced times, fewer resources and lower costs for new applications.

We call this new process “definition driven development”, or simply “D3”. How does it work? It starts with the needs of the business user. One of the problems with defining business requirements in English is that the language is imprecise and ambiguous, therefore open to interpretation. You can imagine the complexity of trying to define a comprehensive requirement for a web front-end platform in this manner. So, instead of English, business units can use a model, or framework, that would represent their business needs in an objective and unambiguous manner. The definition process allows business users to define what they need in an application without having to worry about implementation and IT specifications.

This process of analyzing and defining the business requirement is done before IT programmers are even involved. Business users can define their requirements in terms that make sense to them. The definition will be in business terms or, simply put, what the business wants, not in implementation terms or how to execute the requirement. When IT staff does get involved in transforming the business definition to a working application, the process is much clearer and more intuitive. This model, or framework, can then be easily understood by IT people and derived quickly into a working application.

Once the working application is created, it can be tested or verified easily according to the business definition. In fact, since the definitions are in data formats, they can be checked quickly by business users for completeness and accuracy. This step eliminates much of the revisions and cycling associated with traditional development. There is a shortened window for pre-production and production, or actually going live with an application.

What’s the bottom line for insurers? The obvious benefit is reduced time. Definition driven development has been proven to put new projects and applications into production in weeks, as opposed to months or years.

It is not just time to production that improves. There is no programming involved in the definition stage per se: instead, it is a simulation process that clearly defines the business need and the necessary steps to developing an IT application. As such, the definition can be amended to reflect changes in business requirements. Just as importantly, since the requirements are defined without specific implementation code, they can be re-used to create many other applications in an insurance company.

Another advantage is that fewer human resources are needed in application development. Definition driven development can reduce the seemingly endless conference room pilot sessions and free up valuable time for both business and IT staff. And the bottom-line benefit is lower costs, which all business units and insurance companies like to see.

Today’s sharper focus on IT value justification is a welcome sign in the insurance industry. The question is: Will it really make a difference in how wisely companies spend their money and in the tangible results they see? No matter how great a business idea or IT application, if the development techniques and technology are not there, you will not get th e results.