Every policy a carrier issues, every claim it pays, and every rate it files with a regulator ultimately runs through software. That means that any time the business wants to change something — whether that means launching a new product or adjusting an underwriting rule — it becomes a software problem.
However, the problem is almost never writing the code. Today’s tools have made software development teams able to act more quickly than ever. What slows them down is understanding how the system they’re about to change actually works.
Gartner estimates that legacy maintenance consumes 70-80% of insurance IT budgets, leaving little room for innovation. Much of that maintenance goes beyond keeping systems running. It’s devoted to understanding what goes into those systems: tracing rating logic across platforms, reconstructing endorsement rules, and working out why a decades-old business rule exists before anyone is willing to touch it.
The distance between the knowledge within an organization and its ability to locate and apply that knowledge is the “understanding gap”, and most carriers have one.
Six Signs of an Understanding Gap
An understanding gap rarely announces itself directly. Instead, it shows up as friction that teams have learned to treat as the normal cost of doing business, such as projects that overrun or changes that stall for reasons no one can name.
The six signs below are the most common ways an understanding gap surfaces inside a property and casualty (P&C) carrier. Each one traces back to the same root cause: the knowledge exists, but it isn’t connected to the people who need it.
Sign One: Every Modernization Project Starts With Months of Archaeology
When a carrier sets out to replace a legacy policy administration system or claims platform, the project rarely begins with design. It begins with discovery. Before a single requirement is written, teams have to reconstruct how the current system behaves: which rating rules are in force, how endorsements flow downstream, and why certain logic was built the way it was.
That work can consume months without producing a new capability; it simply recovers what the organization used to know. When most of a modernization timeline goes toward understanding the old system rather than building the new one, the project has quietly become a knowledge-recovery effort, and the technology was never the real obstacle.
Sign Two: Critical Knowledge Depends on One or Two People
In many carriers, the real documentation for a critical system lives in someone’s head. A veteran analyst knows why the rating engine handles a class of business the way it does. An engineer understands the batch job feeding billing well enough to fix it when it breaks at two in the morning.
Such critical knowledge is deep and hard-won, but it is also almost entirely uncaptured. While those people are present, everything works, and dependencies stay invisible. When they leave, however, problems emerge. A carrier that cannot explain one of its own system without a specific person in the room is always one departure away from a major understanding gap.
Sign Three: A “Simple” Change Takes Far Longer Than Anyone Expects
Let’s say someone requests what sounds like a minor adjustment, such as adding a field to a policy form or changing how a fee is calculated. The estimate comes back in weeks instead of days, and the reason is not the coding. Before making the change, the team has to trace where the logic lives, what downstream systems consume it, and what might break if it moves. The modification may take an afternoon; understanding the blast radius takes the rest of the sprint.
When the effort to understand a change consistently dwarfs the effort to implement it, the understanding gap is showing up as a scheduling problem, and adding developers or tooling will not close it.
Sign Four: Documentation Describes a System That No Longer Exists
Most carriers have documentation, but few teams trust it. Requirements written during the last transformation captured the system as it was designed, not as it evolved through years of patches, workarounds, and rules added under deadline pressure.
So teams in this situation usually do the rational thing and stop relying on the documentation, instead going straight to the source code or to the one person who might remember. That erosion of trust is itself a sign of an understanding gap. The knowledge may still exist on the page, but its connection to reality has decayed. Once that link breaks, the artifact stops functioning as memory and becomes something closer to folklore.
Sign Five: No One Can Trace a Claim From End to End
Ask how a claim moves through the organization, from first notice of loss to final payment, and the answer usually arrives in fragments. The intake team knows its piece. Adjudication knows its own. Payments, fraud, subrogation, and document generation each hold a portion.
What no one holds is the whole picture, because the capability spans dozens of systems, several vendors, and a handful of manual steps that never made it into any diagram. The individual systems are well understood. The capability connecting them is not, and that missing end-to-end view is a defining feature of the understanding gap.
Sign Six: Business Rules Are Buried, and No One Remembers Why
When a state revises a filing requirement or a carrier expands into a new line, the first question is deceptively hard: Where do the affected rules actually live? Years of underwriting logic, rate factors, and eligibility conditions sit embedded in code and configuration, often with the original reasoning long forgotten. Teams can see what a rule does but not why it exists, which makes changing it risky — and removing it even riskier.
When a routine regulatory or product change forces a scramble to locate and decode rules the organization wrote itself, the understanding gap has reached the layer where the business logic lives.
In every sign above, the knowledge the organization needs already exists somewhere, but it sits fragmented across systems, documents, and people, waiting to be reassembled by hand every time something changes. That understanding gap explains why decades of better tools and faster pipelines have not made software delivery feel meaningfully easier. The systems may keep improving, but the way carriers preserve organizational knowledge have not kept up.
From Rediscovery to Continuous Understanding
For most of the history of software delivery, preserving knowledge was expensive enough that rebuilding it on every project was the only practical option. That is changing. Modern approaches, increasingly assisted by AI, make it possible to keep understanding connected as systems evolve: linking business rules to the code that enforces them, keeping documentation tied to reality, and turning day-to-day operations into a continuous record of how a capability actually behaves.
Application management, long treated as the end of the delivery line, is becoming one of the richest sources of that living knowledge. Carriers that treat understanding as an asset to be maintained, rather than a cost to be repaid on every project, will spend less time rediscovering their own systems and more time improving them.
Closing the understanding gap starts with rethinking delivery around capabilities rather than isolated projects. To learn more, read ValueMomentum’s whitepaper, “A Shift from Project-Centric to Product-Centric Delivery” and explore how that shift takes shape and what it takes to build the foundation for it.
