Don't Try This At Home

Am I Blue?
As in any fledging industry, the first group of insurance software vendors had difficulty offering better quality, functionality, and cost than do-it-yourself products. Furthermore, throughout the 70s, 80s, and mid-90s, the technology architecture set was very stable, in any color, as long as it wasBlue.

Since high-level architectures were fixed and platform options limited, the required development expertise was relatively low and the skill sets quite consistent. And in case of any trouble, trusted helpers were only a phone call away. (You guessed itthey wore matching blue suits.)

Overwhelming Needs
The situation led to a broad and successful deployment of in-house applications. It also led to a do-it-yourself culture that took a strong hold in many IT organizations. Somewhat paradoxically, the more skilled an IT group was, the more this culture hardened, effectively shutting the doors on alternatives to in-house development.

However, what no in-house group could accomplish was to manage the growing application set long term. As the size and complexity of the application portfolio grew, companies found themselves unprepared to deal with the issues of long-term sustainability, adaptability, or price/performance.

Processes by which to manage long-term platform, product line, and innovation strategies within insurance IT organizations were (and still are) either nonexistent or skeletal at best. As more large players entered the technology arena, the skills and talent needed to manage all aspects of platforms, applications, and integration strategies and architectures became necessities that overwhelmed most of those organizations.
Most IT managers we talk to agree with this state of affairs. So, why do 45 percent still say wed rather do it in-house? One frequently quoted motive is the proliferation of stories about package failures. Scary stories. Stories that send shivers down a CIOs spine.

Behind the Door
Whats really behind that much-talked-about $50 million package implementation fiasco that got the CIO fired? It all boils down to recognizing and managing risks in three key phases of the application life cycle:
1. Product/vendor selection
2. Implementation/operation
3. Transition
I cant resist pointing out the irony in the fact that missteps in these three areas take place in insurance companiescompanies that know more than any others about managing risks.

The first phase in which organizations goof is the selection processa process that, at the high level, really is not that different from the underwriting process. Think of what happens in your company before a $1 million commercial risk goes on the books. A well-trained, well-equipped army of experts (underwriters, loss control specialists, etc.) diligently goes through the task of risk assessment before any decisions are made. Conversely, I have seen $20 million technology-product decisions made based on a fraction of such an effort. The typical reasons given for such decisions are no time or no money. $20 million! No money? For a $20 million risk, wouldnt you make time?

I probably could rest my case right here; but, unfortunately, the other phases bring examples of mistakes and misdemeanors that are just as intriguing.

During the second phase, both implementation and operations are prone to disasters due to similar factorsmainly, poor project management, over-customization, and the failure to establish a strong relationship with the vendor. This seems to be a rather trivial set of issues; yet, amazingly, many failures are caused by a plain lack of attention to such trivia.

There are two, perhaps not-so-obvious, pointers Id like to offer here. First of all, make sure your department acquires the rock-solid skills required to make your new application sing. That may mean hiring or using the vendors resources. Both growing your own or using the vendors can work well, especially if you negotiate favorable terms with the vendor. Remember through buying, you already have solved the most difficult technical issues: architecture and design. Therefore, technical resources are not your key challenge anymore. Instead of worrying about those resources unduly, reinvest in a solid set of business analysis skills. The users of your new technology will love to have people with whom they can intelligently interact.

The 19th Hole
Second, how often does your CEO or line-of-business executive play golf with the vendors CEO? Once a year? That should be your bare minimum. But dont stop there. Ideally, you should place yourself in a position from which you genuinely can influence the vendors strategies. Most vendors are more than willing to listen to you. If they aim to continue making sales, theyll welcome feedback and advice from you and your peers.
The least predictable set of challenges has to do with the third phase: product transition. In other words, the product (or the vendor) is dying and has to be either resuscitated or replaced. The reasons may vary: a new version of software for which the vendor wants an unreasonable ransom, a dramatic shift in business strategy that the product cant handle, the vendors bankruptcy, bad mergers, etc. There is no formula for how to manage this kind of risk. What you should do is take your time; get a ton of advice (including your legal departments); and while carefully considering your options, always engage the executive group or company board. Of course, in terms of risk mitigation, you should have undertaken due diligence in the selection phase: coding in escrow, change-of-control clauses, and so on. But the time for blame is later. Right now, you have to think damage control.

Thats What You Think
If you think thats an unusually high-risk scenario, think again. Disappearing code, undocumented functions, key staff departuresyour in-house applications provide you with very similar excitement daily!

Architectures, designs, and code sooner or later become outdated, regardless of who delivered them. The issues of dealing with a major legacy transition are the same, whether you have in-house or packaged systems.

OK, you might say, but dont we all know vendors over-promise and under-deliver? Yes, its human nature, especially when controls and discipline are lacking. And theres also the ROI card. Every company wants to see a return on technology investment as quickly as possible. Does it surprise you vendors will promise exactly that? I can only keep repeating after the Romans: caveat emptor.

While many technology applications can pay off quickly, only careful, in-depth analysis will reveal how much a given project can benefit a companys bottom line, and how fast.

Yes, some will argue certain circumstances make in-house development a preferred strategy: as in very large companies with their huge internal economies of scale. Or within the first/ fast movers whose new strategies must be executed so rapidly and so frequently that having only full control over technology changes will do. Perhaps. But only in the short run and within the context and scope of a strategic momentum that allows companies to perform an unusual set of heroics.

Can You Compete?
In the long run, regardless of their size, culture, or capabilities, insurance companies cannot compete with professional software houses. And even if they could, they should not. If they choose to buy, they will be rewarded through:

1. Lower risk. Todays technology is a very complex beast. While building applications used to be somewhat akin to building a cottage or a family house, it is now much more analogous to building an office (with all the planning consideration of plugging it into the existing city/neighborhood). Leave it to the pros. They have the ability to attract the best engineering talent, the commercially driven motivation to excel, and the skills to manage technology product life cycles.
2. Better focus. Since you left the most complex technology problems to the pros, you can turn your attention to the three areas from which you can gain the affection of your users: project management, business process improvements, and data quality. Please note in all three cases computer geeks need not apply. Rather, you will need people with deep insurance knowledge, proven business acumen, and polished communication skills. Not a bad trade-off, if you ask me.
3. Economies of current and future trends. As with any outsourcing model, through buying you are tapping into large pools of resources and capacities. In effect, that gives you an indirect ability to exploit economic shifts and trends. To illustrate: Did you know IBM Global Services is the fifth-largest employer in India? How much of that particular labor-cost-disparity trend does your company leverage? Can you do it at all? At what cost and risk?

As information technology moves toward the utility model, the argument about in-house ITs ability to provide a sustainable, competitive differentiation will be harder and harder to make. Do you know any insurance company that claims a competitive advantage because its built the best in-house telephone?

Marek Jakubik, a former CIO of Zurich Financial and Pitney Bowes, is a co-founder and managing director of the Insurance Technology Group. He can be reached at 416-214-3445 or marek.jakubik@insurancetg.com.