The first framework I ever built was, on paper, the better one.
It had a proper maturity model, five scoring dimensions, weighted criteria, a color scheme that survived three rounds of review, and a definitions appendix I was quietly proud of. I presented it. People nodded in the way people nod when they have another meeting in four minutes. Somebody said it was comprehensive, which I took as a compliment at the time and have since learned to read as a warning. It went into the shared drive.
As far as I know, nobody opened it again.
The second one was scrappier, uglier, and had roughly half the intellectual content. It's now used by five different functions, and I've watched people I've never spoken to reference it in meetings I wasn't invited to, which is the only real measure of adoption I've ever trusted.
I've spent a fair amount of time since then trying to work out what actually separated the two, because at the time I assumed it was luck or timing. It wasn't, and the difference turns out to be fairly unglamorous.
The thing nobody tells you about frameworks
A framework isn't a thinking tool. Or rather, it is, but that isn't why it gets adopted or abandoned.
A framework is a piece of infrastructure that has to survive contact with people who did not build it, do not care about it, and are already busy. That's the whole test. Everything else, the elegance of the model, the completeness of the taxonomy, the quality of the underlying thinking, is upstream of that test and doesn't help you pass it.
My first framework failed because I built it to be correct. My second one worked because, mostly by accident, I built it to be used. Those are genuinely different design goals and they pull in opposite directions more often than you'd like.
What the second one actually was
The problem was ordinary enough. We had risk assessments happening across several functions, and every function was doing it differently. Underwriting had a mental model that lived largely in the heads of three experienced people. Claims had a spreadsheet. Operations had a spreadsheet as well, which was different, and which nobody could remember the origin of. Compliance had a process document that described a process nobody was following. And when leadership asked a perfectly reasonable question, something like "where is our concentration of exposure worst right now," it took about two weeks and four arguments to produce an answer that everybody hedged.
None of this is unusual. This is roughly the natural state of an industry that, as I've argued before, is the most under-digitised corner of insurance, where enormous amounts of consequential work still run on spreadsheets, email chains, and individual memory.
What I built was, honestly, not sophisticated. A common set of risk categories that all five functions could recognize, a scoring approach simple enough that people could apply it without training, and a way of recording not just the score but the reasoning behind it. That last part turned out to matter more than everything else combined, and I'll come back to it.
The first version fit on one page. Not because I was practicing restraint, but because I ran out of time before a meeting.
Why it stuck, as far as I can tell
Looking back, four things made the difference, and none of them were about the quality of the model.
It started as something working, not something described. I didn't present the framework. I built a rough version, populated it with real data from two functions, and walked into the room with something people could argue with. That distinction sounds small and it isn't. When you present a concept, the feedback you get is polite and abstract, because nobody can hold an abstraction firmly enough to object to it. When you show something populated with their actual risks, scored, with their names on it, the reaction is immediate and often uncomfortable, and that discomfort is the useful part. Within twenty minutes someone from claims told me my third category was wrong in a way I hadn't considered. He was right. That's a conversation I would never have had from a slide.
This is the same instinct I wrote about when I said I'd rather be a business analyst who builds than one who only specs. You don't actually know what you're building until you build a version of it and let people push back on the thing itself rather than your description of it.
It cost less to use than to avoid. This is the brutal one. Every framework competes against the status quo, and the status quo is free, familiar, and already running. If using your framework takes more effort than the workaround it replaces, it loses. Not because people are lazy, but because they're rationally allocating attention under time pressure.
My first framework required about forty minutes per assessment. The second took maybe eight, and for two of the functions it was actually faster than what they'd been doing, because it replaced a spreadsheet nobody could reconcile. That was the moment adoption stopped being something I had to push. Once a thing is cheaper than the alternative, it spreads on its own and you can stop selling it.
It produced something people needed anyway. Nobody adopts a framework for the framework's sake. They adopt it because it hands them something they were already going to have to produce. In this case, the output fed directly into a quarterly report that three of the five functions had to submit regardless. The framework wasn't extra work sitting alongside the real work. It was a shortcut through the real work, and it happened to standardize the thinking along the way.
If your framework's only output is insight, it will die. Insight is lovely and nobody's deadline depends on it.
It recorded why, not just what. Here's the part I'd argue matters most, and it's the part I got right for reasons that have everything to do with the domain I work in.
Every assessment captured the reasoning behind the score, not just the score itself. Who assessed it, when, on what basis, and what would have to change for the rating to move. It added maybe ninety seconds per assessment and it's the single feature that has kept the thing alive for years.
Because scores go stale, and the moment somebody looks at a rating from eleven months ago and can't reconstruct why it was set that way, the whole apparatus becomes decorative. People stop trusting it. And once they stop trusting it, they quietly resume doing whatever they were doing before, while continuing to fill in your form so as not to cause offence, which is the worst possible outcome because now you have a dead framework that looks alive.
I've written elsewhere that the hardest part of a reinsurance platform isn't the maths, it's the data lineage, that these systems are really machines for defensible memory, and that the dangerous number is never the obviously wrong one but the right-looking one nobody can trace. That lesson came from platform work, but it turned out to apply just as cleanly to a one-page internal framework. Anything that produces a number and can't explain where the number came from will eventually be ignored, and it will deserve to be.
The failure mode I keep seeing
Most frameworks that die don't die from being wrong. They die from being complete.
Completeness is seductive because it feels like rigour. You add the edge case, then the sub-category, then the weighting to handle the situation where two categories overlap, and each addition is individually defensible. The trouble is that every one of them raises the cost of use, and the cost of use is the only variable that actually determines whether the thing survives.
I've come to think a framework should be embarrassingly simple at launch and allowed to grow only where reality forces it. My second framework has picked up two extra categories in the time it's been running, both because someone found a real gap, and both times the addition was earned. The first framework had all of that on day one, priced into the design before anyone had used it, which meant every ounce of that sophistication was pure cost with no demonstrated benefit.
There's a related trap worth naming, which is that the person who builds the framework is the worst possible judge of how hard it is to use. You know the definitions. You know why category three exists. You've internalized the edge cases. Everyone else is meeting it cold on a Tuesday afternoon with nineteen other things on their mind, and if it takes them more than a few minutes to work out what to do, they will do something else instead and not mention it to you.
Why any of this matters more now, not less
I wrote recently that GenAI won't replace underwriters, it'll replace the analysts who refuse to use it, and the argument there was about the difference between work where the output is the product and work where the output is only the residue of a judgement.
Frameworks sit right on that line, and it's worth understanding which side yours is on.
You can generate a risk-assessment framework in about ninety seconds now. It'll have the maturity model, the five dimensions, the weighted criteria, the definitions appendix. It'll look a great deal like my first one, which nobody used. The document was never the hard part, and it certainly isn't the hard part now.
What doesn't come out of a model is knowing that claims will abandon anything that takes longer than ten minutes, that underwriting will only trust a category structure that maps to how they already think about exposure, that the framework has to plug into the quarterly report or it won't survive its second quarter, and that recording the reasoning is worth more than adding a fourth scoring dimension. That knowledge is unglamorous and it's local and it's earned by being in the building and paying attention to what people actually do rather than what they say in workshops.
The framework was never the deliverable. It was the visible residue of about three years of noticing how people in that particular organization actually behave when nobody's watching.
What I'd tell someone starting one
Build a rough version and get it in front of people while it's still bad enough to argue with. Make it cheaper to use than whatever it's replacing, and if you can't, stop and redesign it, because no amount of executive sponsorship will fix that. Attach it to something people already have to produce. Capture reasoning, not just conclusions. Launch it simpler than you think is responsible, and let reality tell you what to add.
And then accept that you'll only really know if it worked when you hear somebody in a meeting you weren't invited to refer to it as though it had always been there, without mentioning your name, which is exactly how it should feel. That's what adoption actually looks like. It's not applause. It's the quiet moment when the thing stops being yours.