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.

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.

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 11th 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.

Is your IT department the last to know?

Remember the last time you needed a real person to give you directions?  Some people provided milestones and markers, making it easy to find your way.  Others were a lot more vague and in the end, not very helpful.  How often did you end up completely on the other side of town, nowhere near where you wanted to be, and you had to go back and retrace your steps trying to figure out where you went wrong?  This only resulted in increasing your stress level and causing you to be late.  Such was was life before the wonderful technological advancement of auto GPS systems.

You’ve spent a lot of time selecting a vacation spot on the beach you’ve never been to before.  Your flight has arrived and you’ve picked up your rental car.  Now what?  How do you get to your final destination?  Do you just drive until you hit the coast and start searching?  No – you were also smart enough to plan and have a GPS to help you find your way.  Your final destination has been input and the course plotted.

crazy intersectionWith proper preparation, your IT department  can be like the GPS in your car — planning the best route to your destination, avoiding slowdowns and getting you to the beach by lunch.  However, if IT doesn’t have all the information to plot your company’s course, or is not given the information in a timely manner,  you can end up bogged down in traffic or taking the scenic route instead of the interstate, ruining your trip with frustration and disappointment.

Carrier IT departments need to have a firm understanding of where the business wants to go so they can design their target architecture in order to plan the best route to get there.  As you know from adjusting your car navigation system, the best route to your destination isn’t always the most direct, or the fastest.  Traffic jams of requirements documentation, technology learning ‘S’ curves, and poorly timed stop lights can make the most direct routes take the longest.

Management should not decide to venture into a new line of business, issue a policy, and drop the policy off with IT to enter into a non-existent system.  The result can only be chaos in a poorly planned and hurried repository saturated with wasted money and time. Without proper notification and planning, a carrier’s IT department becomes reactive instead of proactive, definitely limiting their capability to support the business and help the organization grow.  This dramatically increases the difficulty to introduce new lines of business and does not  improve your company’s ease of doing business for your agents and customers, pushing them further away.  Even the most strategic, brilliant, masterful business plan fails if you don’t have the technical infrastructure to support it.

By keeping IT part of the business planning process, they can help plot the best course and work with you to build a platform for the future that can support your growing organization.