Why a 40-Person Distributor's ERP Rollout Slipped Six Months
The project plan called for a four-month implementation: kickoff in January, go-live by the end of April. The company was a 40-person industrial distributor moving off QuickBooks and a set of shared spreadsheets onto a mid-market ERP system. They went live in October instead, six months late, after burning through the entire implementation budget and most of a contingency fund nobody expected to need.
Nothing about this project was unusual. It's close to the median outcome for mid-market ERP rollouts, which is exactly why it's worth walking through in detail rather than treating it as a cautionary extreme.
Month one: the data migration scope was wrong from day one
The kickoff meeting estimated data migration at three weeks: export customers, vendors, open invoices, and current inventory counts from QuickBooks and the spreadsheets, map them to the new system's fields, load and validate. Nobody had actually audited the source data before setting that estimate.
When the implementation team pulled the customer list, they found 1,140 customer records, of which roughly 300 were duplicates created over eleven years by different sales reps entering the same company under slightly different names. Inventory counts in the spreadsheets hadn't matched a physical count in over a year. Three weeks became eleven.
This is the single most predictable failure point in ERP projects, and it's avoidable: run a data audit before the project plan is finalized, not after the project starts. A half-day spent pulling record counts, checking for duplicates, and spot-checking a sample against physical reality tells you whether "three weeks" is realistic or fiction. Vendors and implementation partners rarely push for this upfront, because it's not billable in the way configuration work is, and finding it themselves later is more profitable for a partner billing hourly.
Month three: nobody owned the decision to say no to customization
The sales team wanted the new system's quote screen to match the exact layout of their old spreadsheet template, down to a specific discount-calculation order that the legacy spreadsheet used because of a formula quirk from 2016 that nobody remembered the original reason for. The implementation partner quoted 60 hours of custom development to replicate it.
Nobody at the distributor had the authority — or the willingness — to tell the sales team no. The project sponsor was the CFO, who wasn't in the room for that conversation, and the implementation project manager treated every customization request as a scope item to quote rather than a decision to push back on. Sixty hours became four separate customization requests across different departments, each following the same pattern, adding roughly nine weeks combined.
The fix here isn't "never customize." Some customization is legitimate — industries with genuine regulatory or operational requirements the standard system doesn't cover need it. The fix is having one person, ideally the executive sponsor, with explicit authority to ask "does this need to work exactly like the old system, or does it need to produce the same result," and to say no to the first when the answer is the second. Standard system behavior that's merely unfamiliar isn't the same as standard system behavior that's actually wrong for the business.
Month five: training got compressed to make up time
Once the project was visibly behind schedule, the natural instinct was to protect the go-live date by cutting the thing that seemed most flexible: training. Planned two-day department-by-department training sessions got compressed into half-day overview sessions, run three weeks before go-live instead of the week before, so by the time the system went live most users had forgotten half of what they'd seen.
The result showed up immediately in transaction accuracy. In the first month post-go-live, the AP team miscoded 23% of vendor invoices to the wrong GL account, not because the system was confusing, but because the training session covering GL coding had been cut from ninety minutes to fifteen, three weeks before anyone actually needed to use it. Fixing miscoded transactions after the fact took longer than the training would have.
Training compressed under schedule pressure is one of the most common places projects quietly transfer cost from "before go-live, visible in the project budget" to "after go-live, invisible, absorbed as ongoing inefficiency." It's cheaper in a spreadsheet and much more expensive in reality.
Month two: the schedule slip never got re-baselined
When data migration ran eight weeks over its original three-week estimate, the project plan technically should have been rebuilt around the new reality — a revised go-live date, a revised budget, a revised communication to the executive team about what changed and why. Instead, the implementation partner absorbed the slip into "catching up" language in the weekly status report, and the original April go-live date stayed on every internal calendar and every department head's planning assumptions for another six weeks before anyone formally acknowledged it wasn't happening.
This matters because a project that's quietly behind schedule but still claiming to be on track makes worse decisions than one that's honestly behind. Departments kept planning around an April cutover — scheduling their own staff training, holding off on hiring a temp for the transition period, telling customers about a system change that wasn't coming. When the real go-live date finally got acknowledged in month four, all of that secondary planning had to be redone on short notice, which is its own hidden cost that never showed up in the project budget line.
The fix is procedural, not heroic: any schedule slip beyond roughly 15% of a phase's planned duration should trigger a mandatory re-baseline — a real conversation with the executive sponsor about the new date, the new budget impact, and what changes for other departments, communicated formally rather than absorbed quietly into optimistic status-report language.
A monthly health check that would have caught this early
None of the failures above required hindsight to see coming — they were visible in real time to anyone looking at the right five questions. A project sponsor who ran this check monthly, starting in month one, would have caught the distributor's slide by month two instead of month six:
- Is the current phase's actual progress within 15% of the planned timeline? If not, that's a re-baseline trigger, not a footnote in a status report.
- How many customization or configuration requests came in this month, and were any of them declined? Zero declines across multiple months is itself a warning sign that nobody's pushing back on scope.
- Has the data audit actually happened, with real numbers, or is the migration estimate still based on an assumption made at kickoff?
- Is the training schedule still intact, or has it already been compressed once to protect the go-live date?
- What percentage of the contingency budget is already spent, and at what rate relative to how much of the project timeline remains?
At the distributor, an honest answer to just the first and fourth questions in month two — the data migration was already four weeks over, and training hadn't been touched yet — would have surfaced the eventual outcome five months before it actually became undeniable. The information existed. Nobody had a standing structure requiring anyone to look at it and say so out loud.
What would have kept this on a four-month timeline
- A data audit before the project plan was finalized, not discovered during migration week one.
- A single named decision-maker with authority to reject customization requests, present in scoping conversations, not a project manager quoting every request as billable hours.
- Training scheduled in the week immediately before go-live, treated as fixed scope rather than the first thing cut when the schedule slips.
- A contingency budget set at 25-30% of the base implementation cost, planned for from the start rather than negotiated under pressure once overruns were already happening.
None of these are exotic project management techniques. They're the difference between a project plan built on assumptions and one built on an actual look at the data, the org chart, and the calendar. The six-month slip at this distributor cost roughly 70% more than the original implementation budget — most of it avoidable, and almost all of it traceable back to decisions made or skipped in the first month.