Deciding whether to update your insurance company’s legacy information system is the business equivalent of determining whether or not you want to replace the failing transmission in your otherwise reliable, 10-year-old car with 200,000 miles on the odometer.
Will that one-time expense squeeze out several years and miles of happy motoring? Or is this transmission the first thing to go in a string of failing parts, each with its daunting repair bill?
This second in our series about legacy systems provides a framework for companies to repair or replace decisions about their legacy insurance systems.
Ignoring Fintech Change can be Costly
Across industries, the rate of technical change, especially for digital innovation, continues to accelerate. Interestingly, advancements in fintech (financial technology) seem to be supercharged. That’s ironic since the financial services industry tends to adopt new technologies more slowly than other businesses.
The mandate for tech improvement comes from multiple stakeholders
- Customers demand increased digital services and integrated physical and digital experiences.
- Employees often choose an employer based on tech tools that allow them to successfully meet customer needs and avoid tedious, repetitive, and mindless work.
- Emerging competitors introduce new tech-enabled products and delivery methodologies that allow them to capture business from long-time industry leaders.
- Shareholders demand superior returns from new tech-enabled revenue streams and expense-reducing automation.
Those tempting opportunities often lead to the knee-jerk decision to jump into a system replacement project. And that might be the right decision, but before pulling the trigger, you’ll want to research the option of a system modernization project.
System Modernization vs. System Replacement
Suppose you can deliver stakeholder-satisfying results and wring a few more years out of the substantial investment you’ve made in your current system. In that case, system modernization may be a better option than system replacement – or at least, better for now.
Digging deeper into a modernization project involves asking some hard questions:
- What is the size of the gap between where we are and where we want to be?
- What is our organization’s appetite for change?
- Is our team prepared and capable?
- Do we have the necessary infrastructure and tech toolset?
Evaluate Your Legacy System
If you’re ready to have the “should we consider a system modernization project?” discussion, working through this list of considerations is the first step in your evaluation.
Infrastructure Reliability
Many legacy systems run on older platforms. That factor alone can make a potential modernization project impractical.
- Is the current network and hardware infrastructure reliable and financially desirable for the same length of time that you anticipate a modernization project would buy you?
- Is the platform easily repairable?
- Are maintenance contracts still available and affordable?
- Does the system crash frequently? Is it sufficiently speedy in terms of data entry?
- Do nightly, weekly, or monthly processes run reliably and within an acceptable timeframe?
Infrastructure Support
Many businesses opt for easily scalable, platform-as-a-service infrastructures. For many, that has translated into reduced costs and an ability to easily right-size their platforms based on business fluctuations and market growth or contraction. If those are your competitors, they will enjoy a strategic advantage while you will not.
- If your systems are in-house, are you OK with continuing to be in the IT infrastructure business?
- What are the actual costs of managing the current system?
- What are the related expenses, such as downtime?
Software Support
- Is the software infrastructure (operating system and development language) still supported?
- Is it difficult for you (if the software was developed in-house) or your software provider (if it’s a purchased package) to find developers who know the language?
- Is the language still taught in computer science curriculums?
- Does the software platform lend itself to easy updates?
- Is it easily compatible with other software platforms allowing you to integrate solutions from other languages?
- Does the software vendor still release new versions with new capabilities, or is the product headed toward extinction?
- Does the software vendor have sufficient resources to document, write, integrate, and test the software upgrades you need?
- If you plan on writing your software to modify your purchased system, does your license agreement allow that?
- Will internal modifications void your service contract with a software vendor?
- Are there system modules that haven’t been touched for years?
- What is your confidence level in the accuracy of either external or internal documentation in the code itself that will enable new developers to understand how the software works and its structure?
Evaluating Previous Projects
There’s much to learn from the past and your institutional knowledge of previous system projects.
- What has been the success of other recently introduced system changes?
- Have recently added capabilities launched on time and within budget?
- Did new capabilities work as designed?
- Did the rest of the system work without interruption?
- If there was a disruption during the implementation, are you ready for a steady diet of disruptions as you roll out complicated and far-reaching changes?
Evaluating Policies and Procedures
These may involve compliance, workflow, and other operational factors. You will have to go through this process regardless of your decision about the system.
- Are you prepared to make operational and policy changes to reach the new business objectives?
- Can you alter the system enough to get the needed gains in functionality and productivity?
- If the flow of work in the original design differs significantly from the planned workflow, can you manipulate the software enough to make it deliver the new functionality? Can you “make a silk purse from a sow’s ear”?
Determining Needs
Installing edit checks that stop users from entering alpha characters in a field where you only want numeric is very different than adding an online payment portal for one of your business units. If you tend to be a “gold plating” organization needing to fix everything, modernization may not be the best path.
- What is the nature of the changes you want to make?
- What functionality do you need?
- What functionality do you want?
What Comes After Next
See the future, define what it looks like, and add KPIs to track progress and measure success.
How will you know the modernization project was a success? As Stephen Covey reminded us, “Begin with the end in mind.”- Can you identify success metrics in the project to know you’ve achieved your desired business results?
- What exactly does this modernization project buy you?
- How many more years can you reap benefits from the original investment in your current IT infrastructure?
- What skills are needed to prepare for the next significant system change?
- What staffing resources will be necessary with a new system?
- When do these steps need to begin?
- Where will you gather intelligence to determine the trajectory of fintech so that you know what you will do next when this reprieve is over?
Project Leadership
Complex projects require a multi-disciplined leader with the time and skill to manage and motivate staff. Managing a project requires a different skill set than managing a department or division. These questions may help you understand why 70% of complex projects fail:
Do you or does someone on your team have the capacity and expertise to initiate and manage this modernization project?- Do you have experience writing technical specifications and requirements?
- Can you or your team communicate business requirements and technical specifications to instill confidence and understanding in stakeholders?
- Can you create a shared vision and shared conversations between the groups to facilitate collaborative problem-solving?
- Can you provide resources for business users to connect the dots between their problems and possible solutions and for the developer group to understand business drivers?
- Do team members also have time to handle the obligations of their “day jobs” while contributing meaningfully to a system modernization project?
- Does your organization have the strength to push through a project without destroying relationships between people who must work together after completing the project?
Finally, no matter how gifted and committed each team member assigned to the project may be, there’s a good likelihood that the project will take longer and cost more than you planned. Users never provide perfect requirements, and developers never write perfect code.
Determining Next Steps
Depending on detailed answers from the gauntlet of questions, there are more decisions to evaluate. These are options to consider as you lean toward keeping your legacy system.
System Refactoring
Think of refactoring as putting a rebuilt engine in your car. In your legacy system, you swap out old modules or code sections with new modules or sections of code. Depending on your goals, and other factors, refactoring may add new features, improve features, or increase speed and efficiency.
Refactoring requires full regression testing to identify unexpected impacts from the changes. Also, every single transaction must process through the new code without error. All the data must remain in the right place, whether in a database field or a report.
Blackboxing
This system change involves “outsourcing” system functionality to a third party. Blackboxing routes an existing task in your software environment to a new component that offers you little control.
For example, one goal may be to cease the in-house printing of bills and entry of customer payments. A blackbox solution involves the legacy system sending billing information to a third-party servicer that handles emailing or mailing bills, sending payment reminders, and receiving payments. The service provider then sends payment transactions back to the legacy system.
Whiteboxing
Purchasing a whitebox solution adds new functionality to your legacy system. Think of it like an extension. One plug-in solution for an insurance company might be a document management utility that manages the printing and archiving of policy documents such as declaration pages, insurance cards, applications, and more. Instead of devoting development resources to document redesign, you purchase software for that task.
Unlike blackbox solutions, you control how the software works within your system.
Proceed with Caution
Suppose you choose to build upon your existing hardware and software platforms. In that case, you’re implicitly stating that the underlying tech and methodology can bear the added “weight” of your new capabilities. Suppose the current system is a solid performer. In that case, the underlying hardware and software life expectancy are workable, and there are ample internal or external resources for support and development; this can be a sensible way to wring more years out of your existing tech investment.
Successful Projects Begin With Alignment
There’s no simple answer to the do-nothing, repair, or replace decision. It’s different for every organization.
Many factors weigh into the decision – people, market and competitive factors, technology, economics, and more. Any one of them can tip the balance.
A crucial step in the journey involves aligning the organization around strategic, operational, and customer-facing results. That puts everyone on the same side of the equation and reduces negative behaviors.
How Experienced Project Consultants Help
Even for the most clear-headed organization, this might be a decision you don’t want to make without help. It’s natural for people to protect their turf, resist change, and hoard information. These behaviors appear as discussions begin with difficult questions. Including an objective consultant to guide the conversation and project might be beneficial.
Give all stakeholders a voice. Invite optimists, cheerleaders, dissenters, and skeptics.
Construct an objective reality by synthesizing everything you hear. If you’re going to engage third-party providers, create a framework to check for cultural alignment and technical expertise.
Then you’ll be ready to push ahead with clarity and make a good decision on this crucial business journey.
TAC4 provides independent project leadership, including vendor selection and management. Our Projenomics® approach leads to 100% success. Contact us.