P & C Technology Blog

Things Are Really...........Yellow.

I got an email on Friday from a regular reader and respondent telling me that he wanted to post a deep and witty follow up to another reader’s post only to encounter a SNAFU on the blog site.  I had two immediate responses.  The first was: “OhMiGod, I hope he doesn’t think I can actually fix this.” Just because I write this blog and it has the word “technology” in it’s title doesn’t mean I can DO anything practical in the technology space.  Those days are long gone.  If you know what //SYSIN DD * means give me a call and we’ll talk about the good old days.  The second reaction was: “I wonder how many folks who use the term SNAFU actually know where it comes from and what it means.”  As with many terms in popular use SNAFU is no longer used as it was originally meant.  To most of us a “SNAFU” is a problem, error or misstep, which is not exactly what the term started out as.

I used to have a boss who refused to listen to or participate in conversations which were laced with “alphabet soup”.  His contention was that he had spent too long in the military and that the part of his brain which stored mnemonics was permanently overloaded and he couldn’t store any more.  He told me what SNAFU meant; and TARFU and FUBAR.  For those of you of a delicate disposition let’s make it clear before we go any further, the “F” in each of these mnemonics is the same F that you find in the “F word”.  These were three mnemonics which we were allowed to use in discussing the status of our projects.  Think of them as the equivalents of the now ubiquitous Green, Yellow, Red status indicators.  They are in turn “Situation Normal, All F*%$ed Up”, “Things Are Really F*%$ed Up” and “F*%$ed Up Beyond All Repair”. 

Now the interesting thing to me is that having grown up professionally with these salty, military mnemonics and having learned later in life the more “professional”, genteel and visually pleasing Green, Yellow, Red status formulation I find that they are subject to the same law which governs projects and human nature.  Which is this: if you are running a project it is hard after the first few weeks to give it a Green (SNAFU) status.  Why?  Because Green draws unwanted attention.   How many projects are there where everything is on schedule and where there are no major issues or inhibitors?  Is it Green because you are trying deliberately to look good, or because you are incompetent and have failed to see the Yellows and even the Reds lurking in the project’s shadows?  Green looks really nice on plants; it is dangerous on project status reports.  What about Red?  Are you really willing to confess that things are FUBAR?  FUBAR is pretty much the end of the line.  FUBAR gets even more attention than SNAFU.  The danger with a project Red status is that the project is going to be shut down, or you are going to get all kinds of “help” which you certainly don’t want and probably isn’t very useful anyway.  So, you cannot, while there is any realistic hope of project rescue, cry FUBAR.

What is left?  Good old TARFU.  TARFU (Yellow) is safe.  TARFU recognizes that this project, like all projects, has its challenges but that they are contained and are being addressed.  TARFU allows the senior management to ask some good, insightful questions and to offer advice and counsel and to leave the status meeting feeling like they have contributed and you have learned.  TARFU isn’t like SNAFU, which scares the senior management because they don’t know what you must be missing; or even worse, FUBAR, which requires that they do something which might hurt bonuses, reputations or even careers.  Those of us who have been in a project which went FUBAR don’t want to repeat the experience.  So, FUBAR is where we end up if a TARFU status strains all boundaries of credulity.  The ongoing debate concerning Iraq is a prime example of TARFU versus FUBAR.  The President, General Petraeus and Secretary Gates want to convince us that Iraq is TARFU.  Most of the Democrats and some Republicans are convinced that Iraq is FUBAR, was always FUBAR and can only stop being FUBAR by withdrawing the troops (shutting down the project).

I’d be interested in any data that you may have to support or contest the following assertions:

·                    most projects which have a status of Green (SNAFU) are in early phases

·                    most projects are Yellow (TARFU) for most of their lifecycle

·                    most projects that go Red (FUBAR) are shut down, rather than returning to Yellow (TARFU).

As always, please let me know what you think, assuming that I get the SNAFU fixed that started this off in the first place.

Choose a Number between One and Thirteen

High on the wish list of most P&C CIOs is the fond hope that one day they may have only one (or even two or three) policy administration system(s) to support, rather than……..you fill in the blank.  The record I have been able to verify so far is THIRTEEN policy administration systems in the same carrier.   To be fair, it is a very big and diverse carrier with all kinds of niche companies writing all sorts of business, but THIRTEEN?  How can this happen, what are the implications and how can it be solved?

Well, here at some of the main reasons this unwelcome situation can arise:

·                     Acquisition:  when one carrier acquires another it also acquires an IT infrastructure.  Seldom is the IT department given the time and money to consolidate the acquired company’s book of business onto the acquiring company’s systems.  Repeat this process several times over the years and suddenly you have a maintenance nightmare on your hands.

·                     Niche markets and regulatory fiat:  even if you are an automobile carrier only, if you write in Massachusetts there is a better than 50% that you don’t support that book of business on the same platform as all the other states.  Similarly so with automobile substandard and residual markets as well as wind pools and earthquake authorities.  Then there is the biggest niche of all, Workers Compensation, which is commonly supported by a separate and specialized PAS.

·                     IT cannot respond:  I hate to admit it but this is all too often the driver when a business wants to rapidly enter a new market only to find that the IT dept cannot get to their request for……..again, you fill in the blank.  So the business folks go off and find a point solution to get them up and running and of course the point solution never goes away.

·                     Software vendors only support personal or commercial lines but not both: this has traditionally been true and remains so to a significant degree today.  Many multi-line carriers have separate PAS for personal lines and commercial lines.

If you are managing in a multi-PAS environment here are at least some of the headaches you must deal with:

·                     One system change request may have to be made in more than one PAS, leading to duplicate work and the potential for differing results across systems

·                     Juggling multiple vendor contracts and maintenance release schedules

·                     Supporting code written in several different languages – Java, VB, .Net, Cobol and accessing different databases which also must be supported – Oracle, SQL, DBII.  Not only does this create redundant costs it also leads to false specializations where only certain programmers can work on certain systems, which ultimately reduces the depth of support.

·                     New software assets – claims, billing, document management – must be integrated with multiple PAS, again creating duplicate work, cost and risk.

So, what is to be done to resolve or avoid these issues?  Not surprisingly the answer is “nothing which is easy”.  If the solution were easy the problem would not be so prevalent.  But there are data points which provide for more positive analysis:

·                     Vendors are building new PAS software which is more flexible and configurable than prior generations and which can in principle support a wide range of business types.  While it is still early days these newer vendors are in the process of deploying PAS systems in both personal and commercial environments with significant success.

·                     More carriers are at least pausing to assess the long term implications of multiple PAS environments before assuming that the default is the only answer.  One celebrated instance was the massive system consolidation which occurred at St Paul Travelers following the merger of those two major players about 4-5 years ago.  And there are less celebrated yet equally informative cases – at least one CIO who reads this blog has led such an arduous journey.

·                     Better tools are now available for data mapping and conversion, reducing the pain of one major aspect of the consolidation.

But the goal remains hard to achieve and often must be undertaken as a “stealth project”, for example, where several current policy systems are replaced by the implementation of a new one.  The project which is sold to senior management is not to consolidate the PAS systems but to implement the new one. 

Then finally the question arises as to whether or not having one PAS is either realistic or a “good” thing:

·                     One potentially troublesome aspect of PAS consolidation is that the more lines of business being supported the more the system is subject to ongoing changes which are generated by business and regulatory requirements and which must be made in the same set of code and tested in the same harnesses.  The frequency of changes generated in a 50 state multi-line PAS creates its own set of headaches.

·                     Realistically the decision to consolidate often results in a common platform strategy for the major lines of business, as measured by premium volumes, while the smaller and/or more niche products remain on their current platforms.

·                     Finally of course nothing happens without business users making this arduous journey with the IT staff and often times a business unit will simply refuse to travel.

So, what can we conclude?  That when it comes to the number of PAS, less is certainly better than more, but also that two or even three may be better than one.   Oh, and THIRTEEN is definitely way out of bounds!