Why do Carriers feel the need to turn to Analysts for key decisions such as PAS replacement?

I have been pondering this more and more – I mean the sell prop seems so good at the onset. An Analyst firm is agnostic, so we are lead to believe, they spend every waking moment researching the exact topic, they do countless rfps and they promise to be right by your side all the way to….that’s the nub isn’t it, to the end of the selection. So let’s not even think about the fact they do not have to live with the decision let us really focus on the value prop.

So we look to an analyst because all they do is research topics like PAS replacement or legacy moderization, and that seems to me to be yet another problem — if you never actually go through the whole process how can you truly have a full understanding? I am not talking about asking carriers and CIOs about lessons learned; I am talking about learning them for yourself and having the key knowledge to really know how the “theory” reacts in the “real world”.Let’s take a fun example – if you decided one morning to reenact William Tell with modern weapons, who would you want to take the shot……shall we review the candidates?

Candidate 1) A man that analyzes weapons every second of every day, he knows every single moving part, the exact interactions, the kick, the muzzle velocities, heck he even talks to sharp shooters about the guns longevity, it’s reliability and confidence….seems to be the perfect candidate – he knows everything with the one exception of ever actually aiming and pulling a trigger.

Candidate 2) A US Army Ranger sharp shooter, he knows all he needs to know about the weapon, he may not know the exact rifling pattern but he does not need to he has something different; he knows exactly how the weapon reacts, the wind, the elevation and air pressure, the distance and drop of flight – he knows where the bullet will end up in the real world, not on paper.

So forget the original question – let’s have a new one – you are an Insurance CIO with an apple on your head and a lot to lose, who takes the shot at the apple? Who do you choose? Interesting thought…….

Technical Debt – Managing near term technical “borrowing” to prevent bankruptcy

In my recent client engagements, I’ve discovered that increased flexibility (in product development / deployment, mobile capabilities, back office integration, etc.) is still top of mind. But, as organizations weigh options for meeting their specific business needs, tailored, custom build efforts may be required when system replacements or refacing/modernizing front ends fail to meet long term business objectives.

Often times, proposed modifications are defined to bolster existing systems as a short term, quick win solution, until a more permanent solution can be afforded.Carriers who elect to undertake custom build efforts in-house are faced with balancing the following resource challenges:

1. Retaining full-time resources with sufficient expertise in both initial custom development and ongoing maintenance efforts.
2. Enlisting external consultants who have both System Development Life Cycle (SDLC) expertise and significant industry expertise.

Either approach drives the carrier to consider the cost of ensuring quality design and development practices against tight budgets and competing business priorities.

Although a quick fix enhancement may seem to be the cheapest route, a Software Productivity Research study from 2010 found that a patch is only less expensive through the early rounds of coding. After that, it is significantly cheaper to code — and significantly more cost effective to maintain — for the longer term solution.

Most concerning is the tendency for organizations to prioritize the short term objective without fully considering the potential long term ramifications.  I can see the value of targeted modifications to existing systems for a short term, short expected lifecycle goal.  However, it seems that regardless of the intended short term lifecycle for these “Band-Aids,” the modifications are exercised years longer than planned.  The term “technical debt” has been top of mind in many discussions I’ve had recently, where we face the challenge of helping carriers fully scrutinize their options and understand the consequences of their decisions. Carriers performing more internal development need to understand that any short cuts made for an immediate patch MUST be structurally reworked in order to repay the technical debt instigated to get the fix up and running.

For example, in one instance, an organization has been weighing options to achieve a business goal given several unknown future factors.  Options included expanding an internal system – which evolved through bolt-on requests and had become a critical system – or building these capabilities within a new system.  The technical debt factor was paramount in this case, as the expected lifecycle of the selected solution weighed in heavily.  Given the uncertain future state, a short term solution may work for a year or two, but the probability of a three+ year expectancy drives a far more strategic approach.  Any short term patches made to the existing system would become exponentially more costly to support as the system remains in use.

This doesn’t mean that there can’t be quick fixes applied to meet an immediate need, but carriers should look beyond the next quarter and evaluate their debt repayment plan before making the decision to implement a quick fix.  Nearly every carrier I’ve worked with has an internal system that grew to be a critical platform and now requires full time business and IT resources purely for maintenance alone.  As the cost to maintain such a system grows, so does the cost to replace it. Carriers must consider the true long term benefits and ramifications of their development efforts and make strategically sound decisions to meet both short term needs and long term business goals.

Star Trek: The Next Generation Policy Administration Insight from Scottie

Cheese Log Star Date 9/14/2011…..

“She cannae take any more, Captain, that’s all she’s got. The core cannae take any more stress.”

The Cheeseship Enterprise Crew

This is the ever-present line when Captain Kirk would yet again request Scottie to do the unimaginable and provide more power from the warp core. Believe it or not, this is the guide to Policy Administration for all Comic-Con attendees and other extreme fans who like to dress in Star Trek costumes for their weekend barbecues.

However, where is this all leading? Well, why did Kirk always call upon Scottie? Because Scottie had nothing else to do in the show and was supposed to be a main character?   Or more likely, because it’s common to look to the very core of the Enterprise to solve all of our issues?

In hundreds of years, when the USS Enterprise exists, will we always look to the core of our enterprise for the only solution? It has dawned on me that over time, Policy Administration systems and the need for additional functionality or performance have caused people to rush the conclusion that the PAS must be replaced. Most often these decisions are made without the proper planning and expertise to consider the entire enterprise, nay even the universe of solutions outside your enterprise that may either avert the need for such a project or indeed “buy significant time.”

Enterprise planning and the must-do precursor to a successful PAS project is oft overlooked with two major issues arising

• The Policy Admin replacement may not be the best idea for your enterprise at this time
• If Policy Admin replacement is the correct path then considerable Enterprise modernization and improvements abound as “low hanging fruit” to the project, oft overlooked and left to rot

So before you call on Scottie and shout at him for more and more or before you decide to buy the new Romulan warp core, I suggest you take a step back to see if, in fact, the Enterprise has other solutions to get you where you need to go. If not, make sure you take full advantage of the upgrade.
Cheese Out.

Is Legacy Modernization Just Procrastination?

There is no doubt that replacement of core systems for insurers has been very popular over the past six years or so.  With the advancements in technology enabling vendors to provide solutions that are configurable, and more easily maintained with “plug and play” technologies that can be upgraded by less technical resources, insurers are taking advantage and moving in to new lines of business and new territories, expanding their footprint.  It allows many small and mid-size insurers to better compete with the leviathans who once staved off competition due to their enormous IT staffs.

But many of these insurers have been in business for scores of years, and have successfully relied on their older technology.  Does the advancement in technology along with ubiquitous connectivity mean that the mainframes and older technology systems just have to go?  Does just refacing the green screens with new web-based user interfaces mean that the carriers that do so are just procrastinating and putting off the inevitable?

A recent blog in Tech Digest posed that question to which I would reply, “Why?  If it ain’t broke, don’t fix it.”  With the horrible economy, many people who need a bigger house aren’t dumping the one they have and buying another, they simply add-on.  The core systems within a carrier are very similar.  If the system you have now works well for its use and if you want to expand in to new lines, you don’t need to rip out that old system and pay for an expensive funeral, just add-on and integrate.  This will start your company down the path to more flexibility which can be supported by a system that is specifically designed to bring all your information into one place – Policy360 based on CRM.

Utilizing a system designed to bring data together from multiple sources allows you to keep your existing technology, leverage the capabilities of new systems, and present and manage that information in a much more accessible and user friendly manner.

Is plastic surgery on your legacy systems really just putting off the inevitable?  Or is presenting a fresh look that sees into the future allowing you to keep costs down while expanding service and capabilities.

He said, She Said” – An excellent Dating game perhaps but not a strategy for Policy Admin Replacement

Yes I realize it may actually not be the best dating game concept; while it does provide some hilarious moments the last thing we need is a repeat of some 70’s concept that shows us how some couples know so little about each other. However, all too often it seems that the “relationship” between Carrier and Vendor can fall quickly into this mold.

More than any other question, I am asked:

“Why have so many of these complex projects have failed, and what are the main reasons to plan against?”

Most people have the industry standard answers but let’s cut through that and get to the nub of it – relationship.

Now do not get me wrong, fabulous planning and clear well defined requirements are a must but without a doubt, in a multi-year project it is the relationship that buys us more value.

So, what does that make me right about now? I guess I could be the “Hitch” of the Insurance world; just here to try and assist in the art of keeping a relationship healthy – okay so we may not see wedding bells but we will see success stories abound with future reference clients and projects coming in on time.

Let’s talk frankly about what I mean; it is about expectations and reactions to the bumps in the road that inevitably WILL occur. There is no way to avoid them and anyone saying they have a proven turn-key solution should be shown the door. For some reason most vendors refuse to discuss the reality of the situation – my take, let’s set out with the knowledge we will hit issues and work out how we will manage them, not just via a Change Control process or clear management but through good communication channels and openness.

Communication is so critical and both Carrier and Vendor are guilty of “hiding” the truths – for example, Vendors behind on delivery seem to wait until the last second when there is no mitigation approach to raise the hand to the issue. Why would anyone think that is the right approach? It is because over the years we have all shot the messenger. The reaction to such a delay or issue should be one of resolution and joint effort, asking the question “Can we find a way to not increase costs and timeline? Is there a creative solution?” Putting the shoe on the other foot we so often see Carriers resources get pulled in several directions, with current production issues or indeed new product development that trumps the project but more often than not, the resource constraints are not adequately communicated to the vendor. This can cause the vendor to hit hold ups and delivery constraints which circle back around to the first point until there is the cataclysmic “He said, She Said” blame game.

Every issue has a resolution, and if raised early we can normally find a creative method of shifting work phases, re-prioritizing deliverable or targeting additional resource allocation in the short-term – whatever it may be there are ways to solve most of the hurdles we will face if we do not stand there throwing the wedding china around.

Just like any relationship it is all about give and take; everyone has to be willing to bend and “eat a little” – when an issue arises, do not shoot the messenger, work together and find the best way to resolve it. No one and I mean no one wins the war, if you try to “win” the battle.

So next time you hit that point, instead of wondering how to bury it or how to find an “out”, think what “hitch” would advise you to do……and communicate.

The Real Reason Policy Administration System Implementations Fail

Insurance company technology environments are in a state of flux and renewal, and progress has been slow and tough going. The only reason progress has not stopped completely is due to the fact that the need for change is so overwhelmingly apparent that it compels action. The reasons for change are so well understood by industry leaders that they barely warrant mention, but for completeness sake they include: the need to respond to rapidly changing insurance markets and regularly requirements, aging work force, aging and obsolescent technology, and the cost of organizational inefficiencies. The real reason Policy Administration System (PAS) implementations fail isn’t the “why,” it isn’t even the “how” or the monetary “cost,” it’s that the process of change is so difficult for these organizations that reluctance is almost equal to the need.

 

Insurance companies are typically both structurally unprepared from an IT governance perspective, and culturally unprepared from an organizational change maturity perspective. Under the current short-term driven reality that is overwhelmingly directing insurance industry efforts, staff in insurance companies are not ready to make a major changes needed because they do not truly understand, in any substantive way, the real urgency or benefit of proceeding down that path in terms of their own self-interest. These problems are certainly not unique to insurance companies. They are manifest in most organizations with well-entrenched process-driven bureaucracies. Paradoxically, to thrive in these organizations a person must become well-entrenched, which is the antithesis of change. However to survive in the long-term, insurance companies must change, which is the antithesis of entrenchment. That is both the paradox and the key challenge for PAS implementation efforts in insurance companies.

Now, this “change-is-hard” counter-balance certainly plays into the “how” and “cost” factors, but the point is that companies come up with a myriad of excellent plans for PAS implementations and spend millions of dollars over initial cost estimates and still fail. And even if they succeed, the results fall short of expectations, sometimes significantly so. Therefore the “why,” “how” and “cost” are window dressing on PAS implementation efforts.

The postmortems of such effort often focus on the “how” and “cost”; as if the insurance company in question just had a better implementation plan or had better execution or spent just a few more dollars things would have been different. And many times there is wisdom in such observations and assessments, but they often skip over the elephant in the room: a PAS implementation is a gut wrenching contest of wills between the status quo and change, which no implementation plan or amount of money can mitigate enough to matter to the people living through it.

Therefore one must acknowledge that there is personal capital involved that is high enough in a project like a PAS implementation to force individuals at all levels of the company to inadvertently, and without forethought or malice, act against the best interest of the company and/or their self interest. There are people in a typical insurance company who have been there 20 to 30 years, who have spent a lot of time and effort building the workarounds the new PAS is intended to “fix,” who have little interest learning a whole new process while maintaining the old process all things being equal, and who make the “perfect” the enemy of the “good” out of an ethical sense of due diligence. These typical change management issues can be overcome. The methods for doing so are numerous and well documented, but regardless these change management issues create one heck of a headwind on a project as large and complex as a PAS implementation and require a hefty long-term personal commitment from leaders and staff alike.

The inherent difficulty in PAS implementation projects it should be a fundamental wake-up call to the insurance company leadership and supporting staff since so many insurance companies are going to be forced to undertake such a project or go out of business. So before contemplating any movement toward PAS implementation effort, leaders and staff members in insurance companies need to significantly re-think leadership roles in the transformation. Insurance companies need its leadership and the staff to become more self-aware of these cultural challenges so that they can steel themselves to the massive amount of personal capital it will take to pull this off. Once that is done (or well on its way) the insurance company can then focus on the “how” and the “cost” (in dollars), which in the end are the easy parts of a PAS implementation.

Project Management for Policy Administration System Replacements: Art or Science

As anyone can tell you, project management is a key cornerstone to the successful completion of any project, but for extraordinary projects, like Policy Administration System Replacement projects, a more sophisticated level of project management is needed. But what does a more sophisticated level project management look like? The myriad of project management disciplines and methodologies out there can give the impression that complex projects require a project management approach that is more scientific and systematic, when in actuality, the more complex the project the less systematic project management gets. This is a counter-intuitive notion, since one would naturally think the more complex the project (i.e., Policy Administration System Replacement project) the greater the need for a systematic project management approach to make sure nothing is missed. This is not to say the project management disciplines and methodologies out there offer no value on a Policy Administration System Replacement project, because they most certainly do.  However, when managing a Policy Administration System Replacement a project manager should always keep in mind that those methodologies and tools are merely a starting point (i.e. the “canvas”) for that masterpiece that is successfully managing an endeavor of significant size and complexity in practice.

When practicing the art of project management, there are a number of tactics that should be adhered to, particularly on a Policy Administration System Replacement project, which you are not going to find in the PMBOK. These tactics are not hard-and-fast rules in terms of execution, but are more fluid. What do I mean?  Well let me provide 4 examples of what I mean:

1. Don’t Fall into the Form-Over-Substance Trap – I have seen project managers that can pull together very detailed and comprehensive project plans, create one hell of a status report, capture every risk and issue on a log, and follow whatever management methodology selected for a project to the tee and yet the project fails. In the project postmortem, there are many reasons for a project failure, but in my experience the majority comes down to management. Adherence to project management dogma over substance is a project killer and focusing too much on the paper work rather than results of what really matters does no one any good. Bottom-Line: Use project management methodology and tools as a starting point only and never mistake project administration for project management, because they are not the same thing. So not only should managers not be afraid to deviate from methodology, if they can see how it could provide additional value to the project team and/or the client, a manager should look for opportunities to do so since staying on the strait-and-narrow will bread rigidity that will ultimately doom the project when it does come time to decisively change direction. The art of this approach is in the notion that managers need to know when to let, that which truly does not matter, go when there is a need to focus on critical issues. Reschedule/skip that regularly scheduled meeting, don’t obsess about missing that status report submittal, if the project plan doesn’t get update for a few days that is ok.  Those things are not project management; project management is about knowing when those things don’t matter in light of the overall project goals.
2. Pay Attention to Your Instinct –  Missing a due date on a project plan, having an identified risk go into red status, being alarmed by the number of bugs being logged  on a just release build of the system code; these are not the primary indicators that there is a project issue. A project manager on a Policy Administration System Replacement project should intuitively know about these issues well before those types of indicators manifest themselves in the normal project management documentation.  It is counter to the way many talk about/view project management, but in Policy Administration System Replacement projects, project managers need to place just as much reliance on the gut than the head in many situations given that they almost never have all the detailed information at hand.  If a project manager is blind-sided by any of these happenings (and yes it will happened at least once on the project), then chances are the project manager is discounting the intuition side of the equation.  If it doesn’t feel right then it is probably not right. Trust that feeling on a Policy Administration System Replacement project and start to take action. In all likelihood it could end up saving the project.
3. Get On A One-On-One Level – Policy Administration System Replacement projects are large undertakings, involving many people from across locations, organizations, departments, and disciplines; not to mention walks of life. Often it is tough, if not a practical impossibility, to meet all team members face-to-face or talk one-on-one at least once, let alone regularly.  And the advice that, even despite these typically challenges, the project manager should try to meet all the all team members face-to-face or talk one-on-one at least once during the project is not revolutionary, but what I am trying to get at here is that there is another level that needs to be reached. To manage a Policy Administration System Replacement project the “one-on-one talk” is a key strategy for successful project management. The one-on-one conversation is where managers can get key pieces of information, but it is not something best achieved in an overly procedural manner. Picking out a few key people on the project t and scheduling a recurring one-on-one conference call will not do. With that approach it will not take long for the feedback to become obligatory and stale. Sometimes you get your best results when the person does not know when the project manager is going to call to get a status or inquire about their feelings on how the project is going. Also the “key people” you need to talk to are not always the people in the key project roles. A project manager on a Policy Administration System Replacement project will need to figure out who and when to call; that is the art of the process. The one-on-one conversation should be informal, but these types of discussion should be a common occurrence regardless of project status or stage. The one-on-one conversations a manager has on the Policy Administration System Replacement is often more important than the regularly schedule status and team meetings that are a staple of all projects (big and small).
4. Listen More Then You Talk At Status Meetings – On a Policy Administration System Replacement project it is a practical impossibility for the project manager to read every email, be up-to-speed on what everyone is working on and the status of the applicable tasks all the time, which is why the art of listening gets a special place in the management of a Policy Administration System Replacement project.  And I don’t necessarily mean listen to the specifics of each team member report, because, while the technical/operational details of a report is of course important, how a team member gives their report is often more important. You can get technical status details in an email, but you can’t get other details that are perhaps more telling, like: body language, pauses, voice inflections, etc. These tell-tale-signs indicate whether a team member really knows what their assignment is, how it is progressing, are they disengaged from the project, etc.  This information will help the project manager determine who he/she needs to follow up with outside the team meeting and who is on track and therefore need less oversight in the short-term. If managers ignore this type of involuntary feedback, they could miss personnel/ operational task issues that could result in level project issues if not address.

There are of course more non-traditional tactics employed in the management of a Policy Administration System Replacement project, but the main point is to try to shift the thinking that the key successful project management of a Policy Administration System Replacement is a greater adherence to methodology and tools. Project management is an art as well as a science and the Policy Administration System Replacement project requires at least an equal measure of both to be successful.

PAS Replacement – Planning and Forethought: Worth their weight in gold

As the economy continues to sluggishly creep up the road to recovery, firms have varying notions for how to best position themselves for success when the market changes.  As noted in a recent survey by SMA (Strategy Meets Action) of 28 insurance executives, one of the top ten imperatives for insurance companies in 2010 is enabling a “fast path for new product development.”  This objective, of course, is constrained by the systems that support the current product offerings, and these systems inevitably arise as the roadblock to achieving the business objective. 

Tightly coupled with this objective of quicker time to market on product offerings is the inevitable need to increase efficiencies in current key business systems.  Whether by enabling communications between disparate systems for a more holistic view of the insured, or simply working to decrease the endless sea of manual, paper-based processes, there are several related steps that should be considered from a competitive advantage standpoint; but we’ll get to that topic another day. 

Within a single organization, multiple policy admin systems have likely been deployed – each with the best of intentions to streamline operations, allow for enhanced product offerings, consolidate numerous existing platforms…  all of these are typical scenarios in the companies we’ve worked with.  The challenges come when companies realize that a nine month time to market for a new product offering won’t position them well in the competitive landscape.  Whether that turnaround involves a highly skilled back office implementation team, or slamming the product into the current system, updating a myriad of sprinkled interfaces to just to get it out the door, the reality still exists – the systems just can’t compete. 

In response to this realization, we’ve had many discussions with companies who are looking to replace or consolidate their policy admin systems, and have experienced significant pain in the past in trying to do so.  The foremost suggestion I’d offer relates to the stage that is consistently undervalued and poorly positioned:  planning.  It’s critical to realize the importance of adequate planning before you go down any path.  We’ve seen time and again organizations who short change the planning and requirements process thinking that they have it under control.  Companies who say they haven’t had any problems to date and things are running smoothly likely have limited or no visibility into the actual state of progress, deliverables, and budget on any of these replacement projects, which all surface at the 11^th hour when everything turns from “green to red.” 

When it comes to implementation and delivery, these companies find massive divergence between their expectations and the pending solution due to lack of preparation and planning.  I won’t even get into the pitfalls we continually encounter in the requirements gathering and definition process; again, a topic for another day.  But simple questions like, “Has the business case been defined and executive sponsorship obtained?”, or “What is your initial rollout strategy?” must be answered, and agreed to before you even start the package selection process. 

You have to ask the question: What were you looking for in a new system?  Look at your competitive landscape, and focus on what makes your company unique (hopefully in a positive way), and provides you a competitive advantage in your space.  As you embark upon the package selection process, there are many platforms that may have flashy, robust functionality (as the vendors will be more than happy to demo  when you get to that stage of the process), but you need to focus keenly on the specific functionalities that will enhance your organization’s differentiating factors, and look under the covers.  Whether you’re doing the vendor selection yourself or with assistance from a consulting firm, be sure to dig deeper on the key requirements you’ve noted, and ensure the demos meet *your* critical scenarios to avoid purchasing a flashy platform that fails to meet your needs.  When all is said and done and your peers ask how the current system is working (if you’re fortunate enough to get it up and running), while it may be lovely to have the newest flashy system, if it doesn’t meet the original business objective and enable your key differentiating factors, it might as well be a Fisher Price play set.