Requirements- Stepping Stone to Success

Here’s a thing I have learned after watching enough insurance IT projects go sideways -

It is never the technology that kills them.Its the requirements !! Or more accurately — the lack of real, messy, argument-inducing requirements.

And yeah, I know the irony. Insurance companies literally exist to assess risk and document everything. But when it comes to building the systems that actually run their business? Suddenly nobody wants to do the hard work or make it messy.

A story about two characters

Let me give you a real example —

I was on a project a few years back — mid-sized carrier, lots of legacy systems, the usual. A business analyst comes to me and says, “We need to increase this field from 10 characters to 12.”

Simple, right?

Except that field — a policy reference code — flowed through:

· A policy admin system written in the late 90s (nobody left who fully understands it)

· A claims platform from an acquisition three years ago

· A data warehouse with ETL jobs that break if you breathe on them wrong

· A rating engine run by a third-party vendor

· A regulatory report that goes to three different states

· And two external partners ingesting a fixed-width file

That “two character change” turned into a six-month nightmare. We had to renegotiate file specs with partners. We had to patch the ETL jobs. We found out the rating engine truncated silently — so policies were pricing wrong for weeks before anyone noticed.

All because nobody asked: “What touches this field?”

The real Problem

Most organizations treat requirements like a shopping list. Someone says “I want this,” and you go build it.

But here’s what actually happens: a single requirement is a flashlight. And your architecture is a dark room you’ve been walking around in for years, telling yourself you know where everything is.

That field length change? It exposed that nobody had ever mapped data lineage for that policy code. Nobody knew which system was the source of truth. Nobody had ever asked, “What happens if this is null?” because it had never been null — until a new integration started sending nulls.

And suddenly you’re in UAT, and things are failing, and everyone’s looking at each other like, “How did we not see this coming?”

Why requirements actually fail

Here’s the pattern I see over and over:

Teams ask for requirements. They document them. They get sign-off. Everyone feels good.

But they didn’t ask the right questions.

Questions like:

· “Who actually owns this data? No, not ‘the business’ — which person, which system?”

· “What’s the exception path? Because the happy path is lying to us.”

· “Which system is authoritative? Because right now we have three.”

· “What downstream process breaks if this value changes?”

These are not technical questions. They are political questions. They are architectural questions. And people avoid them because they are uncomfortable and they slow down the kickoff meeting.

But skipping them doesn’t save time. It just moves the explosion to UAT, or worse — production.

The Roadmap Problem

Insurance companies love roadmaps. Gantt charts. Timelines with pretty colors.But most roadmaps are just wishlists wearing a suit.

A real roadmap — and I mean one that actually works — isn’t a list of dates. It’s a story that connects:

· What the business actually needs (not what they said they need)

· What your systems can actually do (not what you wish they could do)

· Where your data comes from and where it goes

· What your partners expect (which you probably haven’t validated in two years)

Without that, requirements become random. And then architecture becomes accidental. And that’s how you end up with five policy admin systems and a data warehouse that nobody trusts.

What actually works

I don’t have a perfect solution. But here’s what I’ve seen work more often than not:

1. Treat every requirement like it might break something. Even the small ones. Especially the small ones.

2. Get comfortable asking “why?” Not to be the show stopper or a real trouble maker— because there’s always an assumption hiding underneath the first answer.

3. Map your data before you write a single user story. Just do it. It’s boring. It takes time. It will save a lot of long nights!

4. Shared glossary with partners, or don’t bother integrating. If you can’t agree on what “effective date” means, the project is already on a spinning timeline.

5. Your roadmap is a living document. That PDF you created in January? It’s wrong by March. Update it or throw it out.

At the end of the day, insurance IT projects fail because the organization doesn’t actually understand itself. Not fully. Not where it counts.

Requirements aren’t paperwork. They’re the only tool you have to discover your own architecture before it discovers you — usually in the worst way possible.

Get them right, and everything gets easier.

Get them wrong? That two-character change is waiting for you.