Introducing AI is not an IT project: how SMEs run change processes that survive month three

In almost every AI rollout in a mid sized company there is a moment that decides whether it becomes routine or an anecdote. It rarely sits at the beginning. The start usually goes well because curiosity carries it. It is not the training session either. It sits around week ten, when the first demanding project phase hits and people have to decide whether to keep the new way of working or fall back into the old one they know by heart.

We see this with customers again and again, and the patterns are remarkably similar.

The first warning sign is that usage concentrates on a few people. If three out of thirty people generate eighty percent of activity, you do not have a rollout, you have enthusiasts. Enthusiasts are valuable, but they do not keep a system alive once they move to another project.

The second warning sign is that output is produced but never reused. Minutes nobody opens are more expensive than no minutes at all, because they create the appearance of order. So do not measure how much gets documented, measure how often documentation gets accessed.

The third warning sign is quiet workarounds. When teams keep their own notes in parallel, that is not convenience, it is a quality or trust problem. Usually something small is missing that nobody reported because it seemed too trivial.

What helps?

First, an unpopular insight: voluntary adoption works for tools, not for ways of working. If documentation is optional, the people who already do it well will document and the others will not. So keep the scope small but binding. Three meeting types that are always documented beat a recommendation covering everything.

Second, you need visible leadership. The most reliable effect we observe comes when management and department heads use the documentation themselves and refer to it in meetings. A sentence like "We already decided this in June, here is the reasoning" shifts acceptance more than any training, because it shows documentation has consequences. A proven approach is described in Building a conversation culture in 90 days.

Third, measure adoption with four numbers you can actually collect. What share of the defined meeting types exists as documentation. How many distinct people access documentation per month. How long it takes on average to close an open question from a meeting. And how many decisions from last quarter can be found again including their reasoning. These four say more than any satisfaction survey, because they measure behavior rather than opinion.

Fourth, expect setbacks and schedule the follow up. With customers we deliberately book a session in week twelve that covers one question only, namely what is annoying in daily use. The answers are almost always small and quickly fixable. If that session does not happen, small irritations turn into habits and habits turn into abandonment.

Finally, describe the benefit the way the people involved experience it. For a department head the benefit is not efficiency, it is knowing within ten minutes after a holiday what happened. For an engineer it is not answering the same question three times. For management it is that knowledge stays when a key employee leaves. What that knowledge loss actually costs is shown in brain drain in numbers and on our page about knowledge loss through employee turnover. Anyone who only talks about time savings argues past daily reality.

AI rollouts in mid sized companies are rarely a technology question and almost always a question of commitment. Separate the two and you waste less time comparing tools and gain it where the change actually happens. More on this in the topic hub Leadership and HR.