Ask how long an ERP program takes and you will get a single number that means almost nothing, because it hides where the time goes and where it is lost. A benchmark that helps is one broken down by phase, because that is where a plan either holds or slips. The useful question is not "how many months" but "how many months in each phase, and which phase is the one we always underestimate".
The phases, and where the time goes
A program moves through selection, design, build, test, and cutover. The durations below are illustrative, for a mid-market program, and the proportion each phase takes is the part worth internalising.
| Phase | Illustrative share of elapsed time | Where it slips |
|---|---|---|
| Selection | 20% to 30% | Compressed to hit a start date, then repaid in the build |
| Design | 15% to 20% | Decisions deferred into the build phase |
| Build | 25% to 35% | Reopened designs and unplanned customisation |
| Test | 15% to 20% | Too few full-volume data loads before go-live |
| Cutover | 5% to 10% | Rehearsals skipped, so the first real run is live |
The phase to protect
If you protect one phase from compression, protect the design decisions that precede the build. The pattern behind most overruns is the same: a design is signed, the build starts, and then the design is reopened because a decision was never really made. Every reopened design is rework, and rework in the build phase is the most expensive rework there is.
Planning backward from a stable go-live
The milestone that matters is not go-live; it is a stable go-live, the point where the business is running normally on the new system. A plan that ends at cutover has stopped measuring at the moment the risk is highest. Set the date you need to be stable, add the phases back from there, and you will usually find the decision to start has to be made sooner than anyone expected.