The Story Most Technology Purchases Follow
It starts with a vendor demo. The software looks genuinely impressive. It solves a real problem, or at least it appears to. The decision is made, sometimes after due diligence and sometimes after a compelling lunch. The contract is signed.
Then comes scoping—a phase that, when compressed or skipped entirely, becomes the first place the project starts to unravel. The vendor knows the product. Nobody yet knows how it will interact with the actual operations of this specific business. When that discovery work is rushed, the implementation team finds the gaps on the clock, at the vendor's billing rate.
Implementation begins. It is harder than expected. The vendor's support team is helpful but generic; they know their product, not your operations. The configuration takes longer than quoted. A few key staff members are skeptical, and their skepticism proves quietly contagious. After some months, usage data shows that adoption peaked in week three and has been declining ever since. The business has found a way to work around the new system, just as it worked around the old one.
Twelve months later, the software is technically live. Almost no one uses it the way it was intended. The problem it was purchased to solve has not materially improved. And the business is now evaluating whether to invest in a different platform that promises to do what this one should have done.
This is not a rare scenario. It is the default outcome of technology investment in established small and medium-sized businesses. The scale varies. The pattern does not.
The Four Failure Modes
Fifteen years of watching organizations succeed and fail at technology adoption has produced a clear taxonomy of what goes wrong. These are not isolated causes. They usually appear together, in the same organization, in the same technology project. Research from McKinsey & Company consistently finds that roughly 70% of large-scale change programs fail to achieve their stated goals, with people-side failures as the primary cause. The Prosci research body is more specific: projects with excellent change management are six times more likely to meet their objectives than those with poor change management.
What is striking about this list is that none of these four failures have anything to do with the technology itself. The software could be excellent. The vendor could be responsive and competent. And the project would still fail, because the failure modes are organizational, not technical.
Why AI Makes This Worse, Not Better
The current moment in business technology is worth examining carefully, because the pressure to adopt AI tools is unusually intense. Every business owner is being told, through a steady stream of vendor pitches, industry publications, and peer conversations, that they are falling behind if they have not already adopted AI in some meaningful way.
This pressure accelerates the failure modes described above. Decisions get made on shorter timescales, with less operational grounding, because the fear of being left behind overrides the discipline of sequencing the work correctly. The same pattern that produced twenty years of underperforming ERP implementations and a decade of failed CRM projects is now producing a wave of AI tool purchases that will quietly underperform in exactly the same ways.
This is not an argument against AI adoption. There are genuine, significant productivity gains available to businesses that adopt the right tools in the right sequence with a real change management plan. The argument is simply that the technology is the easy part. The organizational change is hard, and it requires the same disciplines that every successful transformation has always required: a stable operational foundation, clear ownership, a deliberate human change plan, and a defined measure of success.
What Actually Makes Technology Adoption Stick
The organizations that successfully adopt technology, and sustain that adoption over time, share a set of practices that have nothing to do with which specific technology they chose.
They sequence the work correctly. Before any technology is introduced, the processes it will affect are documented, stable, and understood. Adoption is planned as a change to a known and stable system, not an improvement to a chaotic one. This often means doing operational work before the technology project begins: work that is less exciting than a vendor demo but more important to the outcome.
They appoint a real owner. Not a nominal project manager, but someone with genuine authority over the change, accountability for the outcome, and enough organizational credibility to drive adoption through resistance. In a $2M to $5M business, that person is almost always the operator—there is no one else with the authority. The project will rise or fall on whether they can carve out the sustained attention it requires alongside everything else the business demands of them. In a $5M to $20M business, it may be the owner or a senior manager, but that person needs genuine authority, not just nominal responsibility for the file.
They build a deliberate adoption plan for the people, not just the technology. This means understanding where resistance will come from and why, designing the rollout sequence to build early wins, identifying internal champions who can model the new behaviour, and communicating the purpose of the change in terms that are meaningful to the people being asked to change their working habits.
They define success before they begin. Not "we will implement the software" but "after six months, these three specific outcomes will be measurably different." With a clear success definition, there is a basis for honest evaluation, course correction, and, eventually, genuine accountability for the result.
What I Have Seen in Practice
Early in my career I was tasked with running a procurement transformation at a mid-sized organization. The technical recommendation was straightforward: replace a paper-based process with a digital one. The economics were obvious. The logic was airtight.
What I did not anticipate was the Director of Procurement. He had built the existing process. He understood it better than anyone, and he saw the project as a threat to his department's relevance. Every meeting included a new objection. The timeline slipped. Morale on the project team dropped.
What eventually turned it around was not a better argument. It was understanding what he actually cared about — which was not the process itself but the standing of his team. Once the project was framed as building his team's capability rather than replacing it, he became the most effective champion we had. He shepherded the organization into a fully digital workflow, and the efficiency gains were significant.
I don't think about that project often—but I do think about it when I think about change management. I had been practicing the discipline before most people were calling it one. The technical answer was available on day one. The organizational answer took months to find, and it was the one that determined whether the project succeeded. That is the dynamic I am describing when I say technology adoption is 20% technical and 80% human.
A Note on AI Specifically
The practical implication for businesses considering AI adoption is this: the question "which AI tool should we use?" is premature. The prior questions are: which processes are stable enough to improve? Where does the team currently struggle, and would technology genuinely help? Who will own this, and what does their accountability look like? What would success mean, specifically, and how would we measure it?
A business that answers those questions first, and then evaluates technology options through that lens, will make a fundamentally different set of decisions than one that starts with a vendor demo and works backwards. The former is building an organizational capability. The latter is buying a subscription.
The good news is that the organizational discipline required to adopt technology well is the same discipline that makes a business more profitable, more exit-ready, and more resilient to whatever technology cycle comes next. It is not a special capability for technology projects. It is simply good operational management, applied to the current moment.
