The project worked. The model passed every test, shipped on schedule, and does exactly what was promised. Six months later, almost no one is using it.
This is the failure that hides in plain sight, because nothing about it looks like failure. Every status report along the way was green. The build was real. The thing genuinely works. You can sit someone down, show them, and watch it do precisely what the business case said it would. And it sits there, while the people it was built for quietly go on doing the job the way they always have. No alarm goes off. No one files a report titled "we built it and they didn't come." The money was spent, the capability exists, and the return simply never shows up.
It is worth understanding why this happens, because the instinct is to treat it as a communication problem: people just don't know about the tool yet, or haven't been trained on it, or need another reminder from leadership. It is almost never that. The people know. They were trained. They got the email. They are choosing, every day, to work around a thing that works, and they are choosing it for reasons that make complete sense from where they sit.
The eighty percent no one budgets for
Here is the part that gets the accounting wrong from the start. The capability itself (the model, the build, the thing that passes the tests) was the easy part. Call it the first twenty percent of the real job.
The other eighty percent is getting people to actually change how they work: to reach for the new thing instead of the old one, to fold it into a day that already feels full, to give up a way of working that has served them well enough for years. That part is hard, slow, and deeply human, and it is routinely treated as if it will simply happen on its own the moment the tool becomes available. Build it and the using takes care of itself. It does not. The using is the harder eighty percent, and most plans budget for it as if it were a rounding error: a training session bolted onto the end, a launch email, a line in a deck about "driving adoption."
So the money and the attention pour into the part that was always going to work, and the part that actually decides whether any value comes back gets whatever is left over, which is usually nothing. The project is declared finished at exactly the moment the real work was supposed to begin. The build was the down payment. Adoption was the rest of the price, and no one set it aside.
People route around a working tool for rational reasons
When people go around a tool that works, it is tempting to read it as resistance to change, or laziness, or a failure to understand what's good for them. It is almost always none of those. It is a series of entirely rational decisions, and you can predict every one of them in advance if you look at the day from the user's chair instead of the dashboard.
The first reason is reliance. Someone tried the tool, it was confidently wrong once, and now they check everything it produces. And checking its work takes longer than just doing the work. A tool you have to verify isn't a shortcut; it's a second opinion you didn't ask for, layered on top of a task you still have to understand well enough to catch the mistakes. So the busy person does the sensible thing: they set it down and go back to the way that doesn't need babysitting. One bad answer, seen early, can cost you a user for good, not because the tool is usually wrong, but because they can no longer afford to assume it's right.
The second reason is fit. The tool was designed for the clean version of the job (the one on the slide), not the real one, with its exceptions and its workarounds and the three other systems people actually live in all day. Using it the intended way means breaking the real process to serve the official one, and the real process is the one that gets work out the door by Friday. Faced with a choice between the tool and the deadline, people choose the deadline every time, and they are right to. The tool asked them to do their job in a way that doesn't match how the job is actually done.
The third reason is incentive, and it is the one most often missed. The person whose day gets harder during the switch is frequently not the person who collects the benefit. You asked someone to absorb the friction of learning a new way of working (the slowdown, the mistakes, the relearning of something they were already fluent in) so that a number improves on a dashboard they will never see, for a goal that belongs to someone three levels up. Put it that plainly and the wonder isn't that they passed. The wonder is that anyone expected otherwise.
None of these is irrational. Each is a person correctly optimizing for the day they actually have to get through. The tool lost on the merits, in the only court that matters: the one where real people decide, every hour, what is worth reaching for.
This is not the trust question
It is worth drawing one clean line here, because this gets tangled with a different and equally real problem. Whether you can trust what the tool produces (whether its answers are sound, whether you can stand behind them, whether they hold up when someone asks how it got there) is a serious question, and it has its own answers. But it is not this question.
This one is simpler, and more human: will the people it was built for reach for it, or reach around it? A tool can be entirely trustworthy and still go unused, and a tool people love can be used long before anyone has settled whether it should be. The two problems travel together but they are not the same, and solving one does nothing for the other. You can prove the output is sound to the last decimal and still watch the thing gather dust, because soundness was never what people were weighing. They were weighing whether it made their Tuesday better. You can require that a tool be installed. You cannot require that it be used.
Adoption is the product, not a launch event
So here is the reframe that changes how you would run the whole thing, from the first day of planning rather than the last.
Adoption is not a launch event. It is not a training session, not a kickoff, not a memo. It is the product. A capability no one uses is worth precisely what a capability no one built is worth: nothing. Except this one cost more and let more people down on the way to nothing. Which means the work is not finished when the tool ships and the build team moves on. It is finished when the old way is gone, not because anyone banned it, but because no one wants it back. When reaching for the new thing has become the path of least resistance, and the workaround feels like the workaround: that is done. Anything short of that is a tool gathering dust somewhere in the org that someone will eventually be asked to explain in a budget review.
That reframe changes where the money goes, who is on the hook for it, and when you declare victory. It means budgeting for the eighty percent as if it were eighty percent. It means designing for the messy real job, not the clean demo of it, and earning the user's reliance one correct answer at a time instead of assuming it. It means making sure the person asked to change is also a person who benefits from changing, or not being surprised when they don't. And it means measuring the right thing: not whether the capability exists, but whether the people it was built for would now fight to keep it.
The question to take into the room
So before the next initiative gets celebrated for shipping, change what counts as done. You already measured whether it works. The harder question, the one that actually decides whether any of the money comes back, is the one most plans never ask:
Did anyone make sure the people you built it for would rather use it than not, and do the work to make that true?