The gap is not the technology, it is the readiness

Every week I sit in a room where someone asks whether the tools are good enough yet. It is the wrong question. The tools are already further along than most of the organizations asking about them, and that distance is not a technical problem. It is an organizational one.

The pattern repeats. A company buys licences, announces an initiative, runs a workshop, and six weeks later usage has collapsed to three enthusiasts who were going to use it anyway. Nothing about the model failed. What failed was that nobody rewrote a single process, nobody changed what gets reviewed or rewarded, and nobody gave people permission to do the work differently.

Readiness, in practice, is boring and specific. Who owns the decision to change a workflow. What data people are allowed to put into a tool, written down in one page instead of implied by fear. Which weekly task is now expected to take twenty minutes instead of two hours, and who checks that it does. What happens when the output is wrong, because it will be.

The teams that get somewhere start from a task, not from a tool. They pick one thing that is done repeatedly, slowly and visibly: a report, a proposal, a set of tender documents, a support queue. They rebuild that one thing end to end with the new tooling in the loop, measure it honestly, and only then move on. That is unglamorous and it works.

The teams that go nowhere start from a strategy document. It reads well, it names four pillars, it gets presented once, and it changes nothing about anyone's Tuesday.

There is a regional layer to this too. In this part of Europe the constraint is rarely money and it is not talent. It is the absence of internal examples. People adopt what they have seen a colleague do, not what they read about a company in San Francisco. So the highest-leverage thing you can do inside an organization here is to produce one credible internal example, with names attached, and let it travel.

If I had to write the readiness test as questions, it would be five of them. Can you name the person who is allowed to change how a task is done, without a committee. Is there one page telling people what data may and may not leave the building. Is there a single task where the new expectation is written down as a number, in minutes or in items per day. Does someone review the output before it reaches a client, and do they have time budgeted for it. And when the tool is wrong, does anything happen other than an email thread. An organization that answers all five has more readiness than one with a budget three times the size.

The failure mode I see most often is the pilot that was designed to succeed. A friendly team, a task nobody depends on, a demo at the end. It produces a slide and no knowledge. A pilot worth running is uncomfortable: pick a task that matters, involve the people who will resent the change, and agree in advance what result would make you stop.

There is also a question of who does this work. It rarely belongs to IT, and it never belongs to a consultant alone. It belongs to whoever owns the outcome of the process, with someone technical close enough to answer questions in the same week they are asked. When that pairing is missing, the initiative becomes procurement, and procurement produces licences, not change.

My working conclusion after two years of doing this in programs, meetups, and conference rooms: stop evaluating models and start evaluating your own capacity to change a process. The first is a weekend of reading. The second is the actual work, and it is the only part that compounds.

If you are somewhere in the middle of this, I am interested in what specifically got stuck. Most of what I know about readiness came from people telling me where their own attempt stalled.