I've watched enough implementations go sideways to notice they rarely fail the way the postmortem says they did. The postmortem blames the platform, the vendor, or the timeline. But the failure was usually visible months earlier, in a decision that felt reasonable at the time. Here are four of those decisions, and the warning sign that gives each one away.
1. The all-at-once cutover
The plan is a single go-live date. Everything moves at once — all users, all data, all processes — because phasing "takes longer" and the business wants to be done. It feels decisive. It is actually a bet that nothing will go wrong on the one day you've guaranteed everyone is watching.
Warning sign: there's a go-live date but no rollback plan. Ask "what do we do if it's not working at noon on day one?" If the answer is "it will be working," you don't have a plan, you have a hope.
The lesson: phase it. A pilot group, a parallel run, a reversible first step. The goal isn't to avoid problems — it's to find them while they're small and survivable.
2. Scope by accretion
The requirements document only ever grows. Every stakeholder adds their must-have, nobody removes anything, and "while we're in there" becomes the most expensive phrase in the project. No single addition looks unreasonable. The sum is a system that does everything adequately and nothing well, six months late.
Warning sign: there's no list of what you're explicitly not doing. A scope with no out-of-scope section isn't a scope.
The lesson: name the non-goals out loud and defend them. The discipline isn't saying yes to good ideas; it's saying "not in this phase" to good ideas, in writing, with a place for them to live later.
3. The data nobody owned
IT treats the migration as a technical task — move the records, map the fields, done. The business assumes the data is "IT's system," so nobody from operations owns whether it's actually correct. Garbage gets carried forward faithfully, and the new platform inherits every bad habit of the old one, now harder to fix because it's "new."
Warning sign: when you ask who signs off that the migrated data is right, the room goes quiet, or everyone points at IT.
The lesson: data quality is a business responsibility with an IT assist, never the reverse. Name a business owner for each major data domain before the migration, not after the complaints.
4. The knowledge that lived in one head
One consultant or one internal expert holds how it all fits together. Documentation is "after go-live" work, which means it never happens, because after go-live is the next project. Then that person rolls off, takes a new role, or simply gets too busy — and the system becomes a black box you pay to have reopened every time something changes.
Warning sign: only one person can answer how a given process actually works end to end.
The lesson: knowledge transfer is a deliverable with a due date inside the engagement, not a promise for later. If it isn't written down before the expert leaves, it doesn't exist.
The common thread
None of these are technical failures. The platform usually works. The failures are organizational — decisions about phasing, scope, ownership, and knowledge that got made by default because making them deliberately felt like friction. The friction was the point. The implementations that hold up are the ones where someone was willing to be the friction early, when it was cheap.
You don't need to predict the specific disaster.
You need to notice the four warning signs, because the disaster always arrives through one of those four doors.
Plant Floor to Cloud goes out every Tuesday.
Lived through an implementation that went sideways? Reply — the lessons travel, and I read every one.