Post-mortems on failed ERP and CRM implementations almost always find a technical cause, because a technical cause is easier to write down and easier to fix on the next project. The actual cause, in the projects I’ve been called in to unwind, is almost never technical. It’s who was allowed to say no, and when.
The pattern repeats closely enough across sectors that it’s worth naming plainly, because naming it is most of the fix.
The failure that isn’t technical
Nobody owned the decision to say no to a customisation request. Every individual customisation, requested by a department that has a genuine, reasonable business need, looks justified in isolation. Nobody in the room approving it is thinking about the fortieth customisation, only the one currently on the table. The system that emerges eighteen months later is not the platform anyone selected — it’s a bespoke system wearing the vendor’s logo, upgrade-resistant and unrecognisable against the vendor’s own documentation, because no single person was ever accountable for protecting the platform’s coherence against the accumulated weight of individually reasonable requests.
Free · 4 minutes
Is your engineering team shipping safely, or quietly accumulating risk?
Fourteen questions on how work gets from idea to production — cadence, testing, rollback, and the key-person risk in your delivery. Banded finding on screen, full sheet by email.
Process was never actually decided before the system went live. “We’ll configure it to match how we currently work” sounds sensible and is usually the root of the problem, because how you currently work frequently includes workarounds for a previous system’s specific limitations — workarounds that made sense as adaptations to that system’s flaws and make no sense at all once encoded permanently into a new one. The project team configures the new platform to faithfully replicate the old system’s scar tissue, and wonders eighteen months later why the new system feels exactly as constrained as the one it replaced.
The data migration was treated as a technical task instead of a decision-making one. Migrating data from an old system to a new one forces genuine business decisions — what does “active customer” mean, which of three conflicting historical definitions of a core entity is now the correct one, what happens to records that don’t cleanly map to the new structure. Handed to an implementation team as a technical extract-transform-load exercise, those decisions get made by whoever is doing the migration, under deadline pressure, without the business context to make them well — and the business inherits definitions nobody with actual authority ever consciously chose.
Training addressed the interface and never addressed the change in how decisions get made. A new platform frequently changes who approves what, who sees what, and who is accountable for what — not just how buttons are clicked. Training that covers navigation and skips the change in decision rights produces a workforce that can operate the software and doesn’t understand, or trust, the new process it’s meant to support. The support tickets that follow get diagnosed as a training gap. They’re usually a governance gap wearing a training complaint’s clothes.
Why this keeps recurring despite better project management
Every one of these failure modes can coexist with excellent technical execution, on-time delivery, and a project manager who did everything the methodology asked. That’s precisely why it keeps recurring: project management discipline addresses timeline and technical risk well. It rarely has a mandate to say no to a business stakeholder’s customisation request, rarely has the authority to insist a process decision gets made explicitly before configuration starts, and rarely owns the data-migration decisions that quietly become permanent the moment they’re made under deadline pressure by whoever happened to be running the migration script.
The actual fix is unglamorous and precedes any platform selection: decide who has the authority to say no to scope creep before the project starts, decide the process — deliberately, not by default inheritance from the old system — before configuration begins, and treat the data migration as the business decision it is, with the right people in the room, rather than delegating it entirely to whoever is most comfortable with the migration tooling.
This is the same principle behind why the obligation has to be named before the tool is chosen, applied to internal process rather than external regulation. Decide what the system has to be able to do and who owns that decision before a single configuration screen is opened, and most of this failure pattern simply has nowhere to take root.
None of this shows up in a vendor’s implementation methodology, because none of it is the vendor’s job to enforce. A vendor is contracted to configure the platform to the specification it’s given. If the specification itself was never decided by anyone with the authority to decide it, the vendor will faithfully implement that absence — on time, on budget, and unable to produce a working system, because nobody asked them to build one. That’s a governance failure wearing a vendor’s invoice.
If a live implementation is already showing these symptoms — accumulating customisations nobody owns, a migration that quietly encoded old decisions as new ones — that’s recoverable, but it’s easier the earlier it’s caught. A technology control assessment can diagnose exactly which of these four failure modes is actually in play.
Looking at an acquisition, supplier, or major project?
The greatest risks are rarely visible in the executive summary. The Sixteen Pillars framework surfaces the technology risks that diligence usually misses.