A program plan holds when you build it backward from a go-live you can defend, not forward from a date someone wished for. Start with a realistic stable go-live, then work back through cutover, testing, build, design, and readiness, pricing each phase as a range rather than a fixed count of weeks. In programs we have seen, a tier 1 program needs about 36 months from the decision to a stable go-live. A plan built forward from a start date almost always underprices the three items that run late every time: data, testing, and cutover.
The phases and what each must produce
An ERP program moves through six phases, and each phase is defined by what it has to produce, not by the time it takes. A phase that ends without its output has not ended, whatever the calendar says. Judge progress by the produced and accepted output, because a phase declared complete on a date but short of its output is the most common way a plan starts to slip quietly.
Planning and readiness produces the agreed scope, the list of entities and countries in the first wave, a data quality baseline, and a decision on how far the business will accept the standard system rather than change it. Design produces the signed process designs, the configuration decisions, and the list of integrations and custom code the program will actually build. Build and configure produces the configured system, the integrations, the custom code, and the first data load programs. Test produces a system that has passed at least three full data mock loads and an end-to-end cycle the business has accepted. Cutover produces the live system, with the data moved and reconciled and a tested way back. The first weeks after go-live produce a stable close and a defect list worked down to a level the business agreed in advance.
How long each phase takes and what moves it
The honest answer to "how long" is a range, because the same phase takes very different times in different programs. Four things move every range. Scope is the first: more processes and more custom code lengthen design, build, and test together. The number of legal entities and countries is the second, because each one adds data, local rules, and a separate cutover to rehearse. Data quality is the third, and it is usually the one that surprises people. The degree of standardisation is the fourth: a program that accepts the standard system moves faster than one that rebuilds the old system inside the new one.
The table below gives each phase its output and the factors that stretch it. Read the drivers, not a week count, because the same phase can run short in a single-entity program and long in a twelve-country one.
| Phase | What it must produce | What moves its duration |
|---|---|---|
| Planning and readiness | Agreed scope, entity and country list, data quality baseline, standardisation decision | Number of entities and countries, how contested the scope is |
| Design | Signed process designs, configuration decisions, integration and custom-code list | Scope, degree of standardisation, number of business units to align |
| Build and configure | Configured system, integrations, custom code, first load programs | Count of integrations and custom objects, build team size |
| Test | At least three full data mock loads, an accepted end-to-end cycle | Data quality, number of integrations, defect find-and-fix rate |
| Cutover | Live system, data moved and reconciled, a tested way back | Number of entities, cutover window length, dual-run choice |
| First weeks after go-live | Stable close, defect list worked down to the agreed level | Readiness at go-live, volume of open defects carried in |
The critical path items that decide the date
Most of a program plan is not on the critical path. A handful of items are, and they decide the go-live date almost on their own. Build the plan around these and the rest tends to fit.
Data migration and cleanup is first. You cannot test on data you have not loaded, and you cannot load data that is not clean, so data cleanup sits in front of almost everything and is routinely started too late. Integration build is second, because end-to-end testing cannot run until the integrations that carry data between systems are built and connected. Test cycles are third, and the plan should carry at least three full data mock loads, each one moving the full data set into the new system so the load programs, the volumes, and the reconciliation are proven before cutover, not during it. Cutover rehearsals are fourth: the cutover is run in full at least twice against the clock, so the go-live weekend executes a rehearsed sequence rather than a first attempt.
A plan that treats any of these four as a line to fill in later is a plan that will move. They are the program.
Dependencies decide the order
The phases do not overlap freely, because a few hard dependencies set the order and a plan that ignores them produces rework instead of progress.
Design must be signed before build starts in earnest. Building against a design the business has not accepted means building twice, and the second build is the one that eats the contingency. Data must be clean before test, because testing on dirty data produces defects that are really data problems, which hides the real defects and wastes a test cycle. Integrations gate end-to-end testing: until the integrations are built and connected, you can test parts of the system but not the flow across it, and the flow across it is where the expensive defects hide. Sequence the plan so each of these is satisfied before the dependent work starts, and show the dependency on the plan so no one quietly starts the next phase early.
Contingency priced as burn times the months you might slip
Contingency is not a percentage someone adds for comfort. Price it as your monthly burn times the number of months the program might realistically slip. The burn is real: the integrator fees, the internal team held on the program, the extended maintenance on the old system, and the cost of the old and new systems running together during dual-run.
Take a program burning about $1.2M a month across SI fees, internal team, and the old system kept alive. If the honest view is that data and testing could push the date two to four months, the contingency to carry is about $2.4M to $4.8M, held as a named line and released only against produced outputs. Stating it this way does two things. It makes the cost of a slip visible to the people who control scope, and it stops the contingency being spent quietly on scope that was never approved. A plan with no priced slip is a plan that assumes nothing will run late, and in an ERP program something always does.
Use the plan to hold the integrator accountable
A plan is also the instrument that holds the SI (systems integrator) to its work, but only if payments are gated to produced and accepted outputs rather than to dates or effort. An integrator paid on the calendar has no reason to care whether the output is real; one paid on accepted output does.
Tie each payment to a phase output the business has tested and accepted. Design is accepted when the process designs are signed, not when the design phase reaches its planned end date. A test milestone is paid when a full data mock load has run and reconciled, not when the test window closes. Cutover readiness is paid when the rehearsal has run clean against the clock. Hold a retention, 10 to 20% of the fee, behind the final acceptance so the last defects actually close. Written this way, the plan and the contract point at the same outputs, and the integrator is paid for a working system rather than for elapsed time. The companion guide on negotiating ERP contracts sets out the acceptance and retention terms in full.