Technology implementations fail in remarkably consistent ways. The specific systems change, the industries change, the organisations change. The failure modes do not.
That consistency is useful. It means the risks are knowable in advance, and knowable risks can be managed. Most technology implementations that run over time, over budget, and under deliver do so not because of bad luck but because of decisions made in the early stages of the project that were never revisited once the momentum built up.
Here is what goes wrong most often, and what to do about it.
The business case was built around features, not outcomes
The decision to invest in a new system is usually made on the basis of what the system can do. The demo is compelling. The feature set is impressive. The vendor's case studies are persuasive. What gets less attention is the specific outcomes the business is trying to achieve and how exactly the system will produce them.
This matters because a system that does a lot of things is not the same as a system that solves your problem. The gap between "this system has the capability" and "this system will produce the outcome we need, in the way our business actually works" is where most implementations start to struggle.
Before any implementation begins, the business case should be specific about what will be measurably different when the system is in place. Not what features will be available. What outcomes will be achieved, and how will you know they have been achieved.
The scope was agreed too quickly
Vendors have an incentive to get the contract signed. Internal sponsors have an incentive to get the project started. Both of these pressures push towards a scope that is agreed at a level of generality that feels sufficient but leaves significant ambiguity about what is actually included.
That ambiguity gets resolved during the implementation, usually in the form of scope changes, additional costs, and timeline extensions. The conversations about what was and was not included become adversarial. The relationship that needs to sustain a long implementation starts to fray.
The scope needs to be specific before the contract is signed. That means documenting not just the high-level outcomes but the specific processes, integrations, data migrations, configuration requirements and training that the implementation involves. Anything that is out of scope should be explicitly named as such, so there are no surprises later.
The wrong people were involved in the design
Technology implementations are often treated as IT projects. The technical team leads the requirements gathering. The vendor's implementation team does the configuration. The people who will use the system are consulted late, briefly, or not at all.
The result is a system that is technically correct and operationally awkward. The configuration reflects a generic understanding of the process rather than the specific way your team does the work. The workarounds and exceptions that the team manages every day have not been accounted for. The system works in theory and creates friction in practice.
The people who do the work need to be involved in the design of the system that will support it. Not as approvers at the end. As contributors throughout. They know things about how the work actually gets done that are not in any process document and will not surface unless someone asks.
Change management was treated as an afterthought
Most technology implementations budget carefully for the technical work: configuration, data migration, integration, testing. They budget poorly, or not at all, for the work of helping people change how they work.
The assumption is that if the system is good enough, adoption will follow. It rarely does. People have existing habits, existing tools they are comfortable with, and a rational tendency to revert to the old way of doing things when the new way is uncertain or inconvenient. Without deliberate effort to support the transition, the system goes live and usage stays low.
Change management is not a communications plan sent two weeks before go-live. It is a sustained program of engagement with the people affected, starting early in the project and continuing well after the system is live. It covers why the change is happening, what it means for the people doing the work, how they will be supported through the transition, and what happens when something is not working.
The go-live was treated as the finish line
Projects that are managed to go-live tend to fall apart after it. The implementation team moves on. The vendor's post-implementation support is less attentive than the pre-sale engagement was. The issues that surface in the first weeks of real use, and there are always issues, do not get the attention they need.
Go-live is not the end of the implementation. It is the start of the most critical period. The weeks immediately after go-live determine whether the investment pays off. Usage patterns are established. Workarounds either get addressed or become permanent. Confidence in the system is either built or eroded.
Plan for the post-go-live period as carefully as you plan for the implementation itself. Dedicated support in the first four to six weeks. A clear process for capturing and resolving issues. Regular check-ins with the people using the system. Measurement of whether the system is being used in the way it was intended.
What this means in practice
None of these failure modes are inevitable. They are predictable, which means they are preventable.
The work of avoiding them happens before the contract is signed: clear outcomes, specific scope, the right people involved, a realistic plan for change management, and a commitment to the period after go-live. That foundation does not guarantee a successful implementation, but its absence makes a difficult one significantly more likely.