How Life Insurance Companies Can Use the PMO to Improve Outcomes of Agile Projects

The Agile approach used in software development helps projects respond to unpredictability.

What? Unpredictability?

Life insurance companies are founded on predictability! How can Agile work at insurance companies, the reigning rulers of predictability?

In an informal examination of multiple large life insurance provider websites, the following key words were found (multiple times/places):

• Preserve
• Long tradition
• Security
• Base for building
• Permanent
• Fixed
• Deeply committed
• Dependable

So how can we, as project managers and program managers, fuse the “traditional” insurance corporate cultures with Agile projects that are based on evolving, iterating and changing?

A PMO initiative can help manage the point where predictability has to meet unpredictability, and blend as peacefully as possible in the project world:

• Work with project teams and vendors to ensure agile terms, practices and goals are understood and met
• Instill a level of commitment for agile projects that meet and align with overall project goals
• Help set up or enhance proper Agile governance for projects and vendors
• Assure that all integration points between multiple projects are identified, efficient and manageable
• Perform ongoing scope analysis while adhering to the Agile philosophy of shifting and reprioritizing as necessary
• Initiate risk analysis and align with the Agile methodology
• Provide long term, short term or interim leadership in overall project work and Agile core competencies
• Supplement resources to help with project and business area gaps
• Guide project managers, sponsors and stakeholders throughout the agile process and provide ownership and stability with this methodology
• Keep a balance of traditional project reporting and documentation while managing everyday Agile shifts and changes

As daunting as it may be for “old school” companies, exposure to Agile projects is inevitable. Managing Agile in a predictable way allows insurance companies to understand what it will take to adapt to the Agile project mindset and advocate the change.

Product Innovation vs Product Complication: The “one minute strategy” syndrome

When is product innovation a hindrance?

When it is innovation for innovation sake?

Let’s look at a company known for innovation and great products –Google; they have it right – or do they? It seems to me that product companies have teams that create wonderful new products, (Gmail, Google Maps) and you eagerly await the next one…what is the issue with that you say? The issue is these teams seem to stay with a product and tweak it and tweak it and feature enrich it until it ends up worse with each release. The age old maintainability and reliability over complication leads to poor usability.

These days, more often than not your hear the street complaining about the latest version-“Why did they remove select all?”; ”The search on the new version is awful, where is my old search?”; “Why are they auto filtering my email? If I wanted it in that folder I would have set a rule up…” – all complaints due to playing with the old rather than innovating the new.

Let’s look for a moment to the Insurance market – remember years ago when “time to market” was big? What did they do? Tweak the PAS systems to the point you can set up a new product in three days – to what gain? You cannot create and file a product in that time so why be able to get the PAS updated so fast? And why do they continue to invest in that feature?

Tweaking an old PAS leads to less reliability and increased maintenance; shortening the lifespan and forcing large injections of capital to replace – Why? Why not invest the short term dollars in enabling your enterprise to grow, facilitate change. The new breed of PAS systems are built on real components, with disconnected services and messaging – the Component Architecture.

More and more vendors are building tools based on such an architecture, removing the heavy integration and allowing the evolution of an enterprise component by component. No more breaking the old by adding the new, instead a simpler, proven method of extending or replacing the old without the integration and conversion nightmares of the past.

Why do I say product extension and feature tweaking is a “one minute strategy”? Because just like most Enterprise Roadmaps we see today, this development and innovation model lack thought and lacks a strategic vision. Instead of taking a moment to right the ship and steer a course into calmer water, these strategies propagate tactical solutions that never reach to the nub of the issue. We do not all have $50M to spend to keep replacing so we need an alternative, a different mode and that mode is to embrace the new architecture, get ready for it and then be able to accelerate change.

So next time you look at your product or your enterprise, try to think out of the box and stop trying to make a steering wheel better – it is round and it works…..look for ways to integrate it better….allowing future growth and expansion without the growing pains.

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.