Every implementation proposal includes a timeline slide — discovery, design, build, test, train, go-live, each phase a clean block of weeks stacked neatly one after another. It's a reasonable planning tool. It's also almost never exactly how the project actually unfolds, and going in expecting a straight line is part of why timeline slippage feels like a crisis instead of a normal, manageable part of the process.
Here's what a realistic implementation timeline actually looks like, phase by phase, including where it genuinely tends to compress or stretch.
Discovery: Usually Runs Longer Than Planned, for a Good Reason
Discovery is where your actual business processes get documented in enough detail to configure the system around them — and it's common for this phase to surface requirements nobody had written down before, simply because nobody had ever been asked to describe the process end to end. This isn't scope creep. It's the discovery phase doing its job. A timeline that doesn't budget flexibility here is a timeline built on the assumption that your business is simpler than it actually is.
Data Migration: The Phase Most Often Underestimated
Data migration frequently gets treated as a background task running quietly alongside other phases, when in practice it's often the most labor-intensive part of the entire project. Legacy data quality issues — duplicate customers, incomplete vendor records, inconsistent item numbering — routinely surface here for the first time, and resolving them takes real time that a generic timeline template doesn't account for.
Configuration and Build: Where Real Progress Happens Predictably
This is usually the most stable, predictable phase — the technical configuration work generally proceeds close to plan, provided discovery was thorough. This is also exactly why weak discovery causes problems later: a configuration decision made on incomplete requirements often needs to be revisited once testing surfaces the gap, pushing rework into a phase that was supposed to be straightforward execution.
Testing: Where Reality Meets the Plan
User acceptance testing is where discovery gaps and data migration issues both surface at once, often for the first time together. This is a normal, healthy part of the process — testing exists specifically to catch these things before go-live, not after. A timeline that treats testing as a quick formality rather than a genuine discovery-and-fix cycle is setting up for a rushed, risky go-live instead of a controlled one.
Training: Frequently Compressed When Other Phases Run Long
When earlier phases take longer than planned, training is often the phase that gets compressed to protect the go-live date — a understandable but costly tradeoff. Under-trained users are the single most common cause of slow, frustrating adoption in the weeks immediately following go-live, and the cost of that friction usually exceeds whatever time was saved by shortening training.
Go-Live and Stabilization: Rarely a Single Day
Go-live itself is a specific date, but stabilization — the period where real-world usage surfaces issues testing didn't catch — typically runs 30 to 90 days afterward. A realistic timeline treats this as a genuine project phase with its own support plan, not as "the project is done, minor issues excluded."
What This Means for Setting Expectations
None of this means timelines are meaningless or that delays are always acceptable. It means a realistic timeline builds in deliberate flexibility around discovery and testing specifically — the two phases most likely to surface genuine, necessary work — rather than treating every phase as equally fixed. A partner who presents a timeline with zero acknowledged risk anywhere in it is either unusually confident or hasn't run enough of these to know where they typically stretch.