The honest answer has two numbers. First modules in production in three to five months; a full operational core in nine to fourteen, phase by phase. What follows is what happens inside those months, because the range is less useful than knowing which part is about to be compressed.
Phase 1 — Understand (four to eight weeks)
Someone from the delivery side on your floor, watching the work happen, before a module is proposed. Not interviews about the process — observation of it, because the workarounds are invisible to the people who have normalised them.
What comes out: process maps of the work as performed including exception paths, a written problem definition, requirements separated into legal constraints and habits, and profiling of a real data extract. Spikes run in parallel on the two or three assumptions carrying disproportionate risk — usually the legacy integration, the data condition, and any accuracy claim attached to automation.
This is the phase that gets cut, because it is the one with no software to show. Cutting it does not remove the work; it moves it into build, where being wrong costs a rebuilt module instead of a revised paragraph.
Phase 2 — Define (two to four weeks)
The blueprint: target architecture, the domain model in your vocabulary rather than the database's, module sequence with dependencies, and a costed plan. Written to be buildable by any competent firm.
The domain model deserves more attention than it usually gets. A system that calls things heats, batches and yields is adopted; one that calls them items, transactions and entities is fought. Adoption follows the software agreeing with the floor, and that agreement is decided here rather than in training.
Phase 3 — Build the first modules (three to five months to production)
Working software into a real environment every two weeks from the start. The first modules go live rather than waiting — which is what makes the programme reviewable, and what lets the sequence change when phase one teaches you something.
Sequencing that holds up: whichever process currently runs on a spreadsheet beside the existing system goes first. That spreadsheet is measured evidence of where the incumbent stopped fitting, and replacing it produces a benefit people feel immediately.
Running alongside the build rather than after it: data migration in dry runs. Each rehearsal produces a reconciliation report, and the discrepancies it surfaces are rules nobody had written down.
Phase 4 — Rollout (three to eight months, overlapping)
Remaining modules, site by site where there are several. This phase overlaps the previous one — the second module is built while the first is being adopted, which is the arrangement that keeps a fourteen-month programme from feeling like one.
Multi-site rollout has its own rhythm: the first site takes longest and teaches the most, the second validates that the learning transferred, and the rest follow a pattern. Organisations that roll out everywhere simultaneously to save time reliably lose it.
Phase 5 — Prove and operate
Parallel running where the module touches the ledger, with automatic daily reconciliation rather than sampling. Cutover rehearsed before the weekend it happens, with abort criteria agreed in advance — a rollback plan written on the night is not a plan.
Then hypercare with the architects who designed it rather than a separate support tier, and finally steady-state operation.
What actually moves the date
| Variable | Effect on timeline |
|---|---|
| Process variance | Largest single factor. More non-standard steps means more to design, build and test. |
| Integration count | Each two-way integration adds weeks, and the dependency is often another vendor's schedule rather than yours. |
| Data condition | Migration effort tracks data quality. Poor master data can add a full phase. |
| Decision latency | The most underestimated. A blueprint waiting three weeks for a decision has added three weeks. |
| Team size | Helps in build, barely helps in discovery, and does not help at all with decisions. |
The compression that does work
You can genuinely go faster by narrowing phase one — fewer modules, live sooner, more phases. That trades breadth for speed and keeps the quality of each module intact.
What does not work is compressing discovery or shortening the parallel run. Both feel like schedule savings and both convert directly into rework, usually at the point where rework is most expensive and most visible.