Why AI projects die in week three, and what adoption work actually looks like

The failure is quiet. Nobody announces that they have stopped using the new system. Usage just decays, and by the time anyone looks, the old process is back and the budget is spent. The system may work exactly as designed. It failed anyway, because the habits, ownership, and rules around it were never changed.

What week three looks like

It looks like this. One person reverts because the system got something wrong once, and nobody told them that was expected in the first month. Another was never trained properly and is faster the old way. A manager, under pressure, asks for the old spreadsheet because that is the format they know, and the team obliges — so the old process is being maintained alongside the new one. Within a quarter the new system is a tab nobody opens.

None of those people did anything unreasonable. Each was responding to the incentives in front of them.

Why training alone does not hold

A one-hour demo teaches people where the buttons are. It does not change what their manager asks for, what they are measured on, who owns the process now, or what to do when the system is wrong. Those four things decide whether the new way survives contact with a busy Tuesday, and a demo touches none of them.

The four things that have to line up

• An owner. One named person who is responsible for the process as it now runs — not the tool, the process. If the old spreadsheet had an owner and the new system does not, the spreadsheet wins.
• The workflow. The new system has to be at least as fast as the old way for the person using it, or it has to be the only way. A new step that is slower and optional is a step nobody takes.
• Rules. What may go into the tool, what must be reviewed before it leaves the business, and what to do when the output is wrong. Short, written, and specific to the task.
• Measurement. Actual usage, from the system, checked regularly enough that decay is visible while it can still be fixed.

What adoption work actually is

It starts with finding out why people are not using the thing — by asking them, not by assuming. The reasons are usually specific and usually fixable: it was slower, it was wrong once, nobody explained the exceptions, the manager wanted the old format.

Then it is role-specific training built around each person's real tasks, with their own examples, including examples of the system being wrong so they know what wrong looks like. It is a short written policy. It is a review step placed where the cost of an error is high. It is a way to see usage, and a follow-up a few weeks after go-live, because that is when the real problems surface.

It is, in other words, ordinary operational work. It is not a change-management framework, and a small business does not need one.

The manager problem

The single most common cause of a shadow process is a manager who keeps asking for the old output. Not from malice; from habit and from pressure. Adoption work has to include that person. If the report now comes from the new system, the manager has to accept it in that form, and someone has to tell them so.

The question people are actually asking

Behind a lot of slow adoption is a question nobody has answered out loud: is this going to replace me? People do not trust vague reassurance, and they are right not to. What they need to know is what is changing, what is not, how their work will be judged now, and where their judgment still matters. If leadership is in fact planning to reduce headcount, that has to be said plainly, because it changes the work and people will find out anyway.

When the problem is the software

Sometimes the diagnosis comes back and the answer is that the system is not good enough. It is slower than the old way, or wrong too often, or built for a process that does not match how the work happens. Training a team to tolerate a bad system is not adoption work; it is a cover-up. The right move is to fix the build, shrink the rollout, or retire the tool.

How to tell whether adoption is real

• Usage data from the system, not self-report.
• Correct use — people using it for what it is for, with the review step actually happening.
• No shadow process. The old spreadsheet is gone, not merely discouraged.
• Exceptions flowing to the right person and getting handled.