The insurance industry loves a good project. We define scope, set timelines, allocate budgets, and march toward a finish line. It’s how we’ve always done things. But we’re in the middle of hyper-accelerating technological change, and our usual go-to processes are failing to keep pace.

The Project Management Body of Knowledge defines a project as a discrete effort with a defined beginning and end. That framing made sense when technology moved slowly; it didn’t matter that by the time you completed a five-year modernization initiative; you were delivering something you’d conceived of half a decade ago. However, that’s practically an epoch these days. 

So, you’ve spent your $30 million, endured massive business disruption, and now you’re looking at your shiny new platform thinking, “We’re done, right? That’s it?” But no, you’re nearly five years behind.

What AI implementation, or other time-saving capabilities, have zoomed into your competitor’s hand while you were heads-down implementing yesterday’s vision?

We all know the rate of technological change has outpaced our planning horizons. Moore’s Law, which posits that tech gets more powerful and less costly every two years, feels quaint at this point. We’re not talking about 18-month cycles anymore. We’re talking about capabilities that reshape expectations quarterly. And yet we keep launching three-to-five-year transformation programs as if the world will hold still.

It won’t.

The Destination Mindset Trap

When we talk about “modernization journeys” or “digital transformation,” the language itself betrays us. A journey implies a destination. You’re going someplace specific, and your ETA is set. But technological evolution isn’t a destination. It’s a direction. You never get there. You’re constantly on the move.

The old destination mindset not only fails to keep pace, but that failure itself creates a cascade of other problems. Organizations make massive capital investments that accounting then tells them must last four-, five-, or seven years to justify the depreciation schedule. Finance starts dictating technology lifecycles based on GAAP requirements rather than business reality. And executives start measuring success by whether they “completed” the project, not whether they’re continuously delivering value.

The subscription economy is a perfect example of the larger environment insurance organizations are operating in. When you’re paying annual fees rather than making large upfront license purchases, the financial pressure to squeeze years of life out of a platform diminishes. But the mindset shift needs to go deeper than how we account for software.

“Componentize” Everything

Consider the ways we approach core systems. Policy administration, claims, and billing are the three pillars of insurance technology. A project that intends to replace any one of them wholesale will prove to be a death sentence for any CIO. Among other things, such projects tend to be obscenely expensive. A mental model forms: “We’ll bloody ourselves for five years, and then we’d better live with the result for a long time because nobody wants to go through that again.”

But what if we stopped thinking about replacing policy administration systems and started thinking about replacing components of them? 

Instead of embarking on a massive overhaul every five years, we embrace continuous evolution, refreshing a component every 12 months.

Forget your ETA; think of technological changes as a shift in architecture. 

The availability of componentized technology makes this possible now in ways it wasn’t before. API-oriented architecture, modular design, and point solutions plug into ecosystems. We’re past the era of buying the IBM monolith. Think of how audio equipment evolved: nobody buys integrated stereo racks anymore. You buy bespoke pieces and connect them. Computing went the same way — screens separated from processing units, components became interchangeable.

Insurance technology can take its cue from this, if we design for it deliberately.

The Case for Continuous Evolution

This probably sounds terrifying to anyone in the C-suite. “Wait, we’re doing this constantly?” That sounds endlessly expensive and chaotic.

Actually, it’s the opposite.

Talk to your CIO about cost predictability. If you ask them to forecast a capital expenditure over three years — with no clarity on talent availability, ecosystem changes, or market shifts — they’re going to struggle. But they can give you high confidence estimates on what you’ll spend over twelve months on well scoped out and defined components. Shorter cycles mean dramatically better cost visibility.

Then there’s change fatigue. 

When you go live with a massive new core system, you’re asking the entire organization to completely change how they process business all at once. The organizational strain is immense. But when you’re continuously updating smaller components that affect different people in different parts of the organization for only portions of their workflow, the change becomes digestible. You’re filling potholes, not rebuilding highways.

And risk? The average CIO tenure is about three-and-a-half to four years. That’s not a coincidence. It aligns with the timeline of the massive projects they stake their careers on — projects that very rarely succeed when measured against time, scope, and budget. Smaller, more frequent initiatives carry dramatically less execution risk because the scope is more defined. The unknowns are contained; and, therefore, so are the consequences of any single failure.

Four Patterns for the Continuum Model

Moving from projects to continuums requires four fundamental shifts in how you operate.

First, define explicit lifecycles. Every technology component should have a predetermined expiration date — not an assumption that you’ll use it until it breaks. An API that operates in a fast-moving space might have an 18-month lifecycle. A more stable application component might get 24 months. But nothing ships without a lifecycle tag. You’re not waiting for someone to tell you something is obsolete; you’re planning for that obsolescence from day one.

I borrow this thinking from aerospace. If you’re a pilot, you don’t wait for a midair engine failure. Instead, the manufacturer requires a full engine rebuild or replacement every 1200 hours.  You’re not doing it because the engine failed; you’re preempting failure — and that cost gets built in the total cost of ownership.

Second, create trigger-based reviews. Don’t wait for lifecycle expiration to evaluate your technology. Build triggers that initiate review when business conditions change, when new capabilities emerge in the market, or when performance thresholds get crossed.

Third, implement a modernization calendar. Visualization matters. When you can see on an actual calendar which components are coming up for refresh, you can plan capacity, sequence dependencies, and avoid bottlenecks. This is how clear, operational scheduling replaces outmoded abstract planning.

Fourth, dedicate capacity to continuous evolution. This one is critical. You need actual resources e.g., people, budget, time — allocated to the ongoing lifecycle work. If modernization only happens when you can spare people from “real” projects, it won’t happen. The lifecycle work is real work.

The Business Velocity Imperative

It’s about business velocity. When your product VP tells you that a competitor just launched a new capability and you need to respond, how fast can you move?

In a monolithic environment, the response is often, “We’re not fast enough.” You don’t have what you need. You can go buy it, but integration will take a year, and that’s unacceptable.

By contrast, in a modular, continually evolving environment, you can acquire a new capability and have it plugged in within months. The architecture is designed for change. The organization is accustomed to change. The governance supports change. So, you’re not asking people to do something extraordinary. You’re asking them to do what they already do.

Where We Are — And Where We’re Going

I won’t pretend the industry is ready to fully embrace this tomorrow. We’re probably five to ten years from widespread adoption. There are cultural shifts required as well as generational changes in leadership that will have to happen first. And, in most cases, organizations are still carrying depreciating investments on their balance sheets that constrain what’s possible.

But the opportunity does exist right now for organizations that find themselves at an inflection point. If you’re facing a major re-architecture decision anyway, if your core systems are reaching end-of-life and you have to build something new — you have a choice. You can replicate the old approach with new technology. Or you can deliberately design for componentization, define lifecycle maps, create trigger-based reviews, implement a modernization calendar, and dedicate resources to continuous evolution.

One path leads to another five-year slog culminating in something that’s already aging. The other leads to an operating model that can actually keep pace with the world.

Everything is falling apart, you might say. What an unfortunate situation.

Or… everything is falling apart. What a great time to reinvent how we do things.