How We Reduced Client Go-Live Time from 14 Weeks to 6 Weeks

Our first ERP implementation went live 16 weeks after kick-off. Our eighth went live in 5.5 weeks. Same type of client (mid-sized manufacturer), similar scope, similar team size.

The improvement didn't come from working faster or cutting corners. It came from understanding where time was actually going — and most of it was going to waiting.

Where the 14 weeks went

When we mapped our first few project timelines in detail, the distribution was not what we expected:

We were spending 38% of project calendar time actually building software. The rest was process overhead — waiting for approvals, waiting for data, waiting for decisions that could have been made in advance.

Change 1: Pre-engagement discovery becomes mandatory

Our first implementations started with a kick-off meeting and a requirements document. The first two weeks of the project were spent figuring out what we were actually building.

We moved discovery to before the contract signature. We now conduct a paid two-week discovery phase that produces a specification document, data migration assessment, and integration requirements list. The project contract is for delivery against that specification.

Impact: eliminated the "discovery happens during development" anti-pattern that caused us to rework early code when we learned things mid-project. Saved 2–3 weeks on a typical 14-week project.

Change 2: Decision log with pre-assigned owners

On every project, there are 40–80 decisions that need to be made by the client: configuration choices, workflow preferences, report formats, access control hierarchies. In our early projects, these decisions came up organically during development and waited for the relevant person to be available and responsive.

We now create a decision log at the start of every project, identifying all foreseeable decisions, assigning an owner on the client side, and setting a deadline for each. Decisions that aren't made by deadline default to our recommendation. This change alone reduced client-waiting time by 40%.

Change 3: Data migration starts week one, not week eight

In early projects, data migration was sequenced after development: first build the system, then migrate data into it. This meant data migration work was always happening in the final weeks of the project, under pressure, discovering problems too late to address properly.

We now run data migration in parallel with development from week one. The client sends us their data extracts in week one. We profile them, identify quality issues, and start cleaning and transforming while the team is building the receiving system. By the time the system is ready to receive data, the data is ready to go in.

Impact: reduced the data migration phase from 4–6 weeks sequential to 1–2 weeks at project end (validation and final load). Saved 3–4 weeks on a typical project.

Change 4: Environment parity from day one

We used to run development on local machines, then deploy to a staging environment, then deploy to production — three environments, each slightly different. Bugs that only appeared in production were a significant source of go-live delays.

We moved to containerised environments (Docker) that are identical across development, staging, and production. We also moved to continuous deployment pipelines: every merge to main automatically deploys to staging, and production deploys are one-click. This reduced environment-related bugs and the time to fix them.

Change 5: Go-live criteria defined in week one

In early projects, "go-live readiness" was a subjective judgment made near the end of the project — often involving a tense conversation about whether the remaining bugs were blockers. This created uncertainty and extended timelines.

We now define go-live criteria in week one: the specific list of features that must work correctly, the performance benchmarks that must be met, the data validation checks that must pass. Go-live is a binary checklist, not a judgment call.