The two timelines
Every ERP project has two timelines. The first is the one in the proposal — the neat Gantt chart with the confident go-live date that helped them win your business. The second is the one you actually live through, which is longer, messier, and full of discoveries nobody put on the chart. The gap between them is not bad luck. It is structural: the proposal timeline was built to sell, and the real timeline is built out of your actual business.
Here is how the proposal timeline gets made. The vendor estimates the work under ideal conditions: your data is clean, your team makes decisions in days not weeks, nobody gets pulled into quarter-end close, the integrations behave, and nothing unexpected surfaces in discovery. Every one of those assumptions is false in a real project, and the vendor knows it. But the vendor with the honest twelve-week timeline loses to the vendor with the optimistic eight-week timeline, so the market punishes honesty. You are not buying a lie so much as participating in a system where the truth does not win deals.
Where the weeks actually go
When a project runs long, the overrun almost never comes from the software. It comes from five places, and four of them are yours, not the vendor's.
First, decisions. Every implementation has twenty to fifty decisions that only you can make: chart of accounts structure, approval workflows, pricing rules, warehouse logic. Each one waits on someone in your company who has a day job. A decision that takes the vendor an hour to implement takes your team two weeks to make, because it needs three people to agree and they are all busy. Multiply that by thirty decisions and you have added two months. This is the single biggest source of timeline slip, and it never appears on the vendor's chart.
Second, data. The migration always takes longer than quoted, because the quote assumed clean data and your data is not clean. Cleaning customer masters, deduplicating vendors, reconciling open balances — this is your team's work or work you pay the vendor to do, and either way it was underestimated.
Third, scope discovery. The requirements gathered before signing were high-level. The real requirements surface during configuration, when someone says "oh, we also need the system to handle consignment stock" and nobody priced that. Each discovery is small. Twenty of them are not.
Fourth, testing and rework. The first round of user testing always surfaces things that need to change. That is what testing is for. But the timeline usually budgets one round, and real projects need two or three.
The padding game
Vendors do pad estimates — but not the way people think. The padding is not a lie; it is usually in the wrong places. A task the vendor knows takes three days gets quoted at a week, because they have been burned before by the client's two-week decision delay sitting inside their three-day task. The padding protects the vendor's margin, not your timeline. When the work goes smoothly, the vendor banks the difference. When it does not, the padding evaporates and you are still late.
The tell is vagueness. "Configuration: 3 weeks" tells you nothing. Three weeks of what, by whom, dependent on which decisions from you? A padded estimate hides behind big buckets. An honest estimate breaks into pieces small enough to argue with: "Item master configuration: 2 days, dependent on unit-of-measure decisions from your operations lead by March 3." You can hold someone to the second version. The first version is where timelines go to die.
Watch for these specific red flags. Milestones with no owner — "data migration complete" with no name next to it. Dependencies on your team with no dates — "pending client decisions" as a line item with no deadline is a blank check for delay. A testing phase measured in days instead of rounds — "one week of testing" means whatever fits in the week, not whatever the system needs. And the biggest one: a go-live date announced before discovery is finished. If they set the date before they understand your business, the date is marketing.
The real math
Here is a simple model that gets you closer to the truth than any proposal. Take the vendor's timeline and split it into vendor work and your work. Vendor work — installation, base configuration, standard training — is usually estimated fairly; vendors know their own speed. Your work — decisions, data cleanup, testing, change management — is where the estimate falls apart, because the vendor cannot see inside your organization.
For your side, take their estimate and double it. Not because your team is slow, but because your team has jobs. A task quoted at five days of elapsed time assumes five days of attention. Your controller giving the project two hours a day turns five days into three weeks. That is not dysfunction; it is reality. Plan for it.
Then add the unknowns explicitly instead of hiding them. Every project has three to five things nobody can estimate yet — the integration with the legacy system nobody documented, the EDI spec the big customer has not sent, the warehouse process that lives in one person's head. List them, assign each a time box, and put them on the timeline as named risks with owners. A timeline with visible unknowns is honest. A timeline without them is fiction.
Finally, convert the timeline from dates to milestones. "Go-live June 1" is a wish. "Go-live happens two weeks after successful completion of round-two testing, data reconciliation sign-off, and training completion" is a plan. Tie vendor payments to milestones, not dates — thirty percent at design sign-off, thirty at testing complete, the rest at go-live. A vendor paid by milestone has an incentive to finish things. A vendor paid by date has an incentive to declare things finished.
What to ask before you sign
Four questions cut through every timeline fiction. One: "Show me the last three projects of this size — what was the quoted timeline and what was the actual go-live date?" Honest vendors answer this. Evasive vendors tell you every project is different, which is true and also beside the point.
Two: "Which parts of this timeline depend on my team, and what exactly do you need from us by when?" Get the dependency list in writing. This is the document that prevents the "we were waiting on you" conversation.
Three: "What happens to the timeline when we discover new requirements mid-project?" You want a change process with written approval and re-estimated dates — not a shrug and a longer invoice.
Frequently asked questions
Why do implementation partners quote timelines they can't hit?
Because the honest timeline loses the deal. The market rewards the optimistic quote, so vendors quote the best case and manage the overrun later. It is structural, not personal — which is why you protect yourself with milestones and payment terms instead of hoping for honesty.
How do I know if a timeline is realistic?
Break it into pieces. Any phase quoted as a single bucket ("configuration: 4 weeks") without named tasks, owners, and dependencies is a guess. Realistic timelines name who does what by when, list what they need from you, and show the unknowns instead of hiding them.
What should I do when the project starts slipping?
Find out which of the five slip sources it is — decisions, data, scope discovery, testing, or your calendar — because each has a different fix. Decision delays need escalation to whoever can say yes. Data problems need dedicated cleanup time. Scope discovery needs the change process. Do not accept a revised date without a revised plan; a new date with the same plan just moves the disappointment.
Should I put timeline penalties in the contract?
Milestone-based payments work better than penalties. Penalties create adversarial dynamics and vendors price them in. Holding twenty to thirty percent of the fee until go-live and stabilization gives you leverage without the lawyers. The vendor who knows the last check depends on a working system manages the timeline like it matters.
