The plan

A nine-month project fails in one of two ways: because everything is built until the last day and then tested in a few, or because the scope keeps moving during stabilisation. This plan rules out both.

What shapes the calendar

Every month ends with a delivery. A working version is deployed to your staging environment. There is no month without a delivery.

Your staging environment opens at the end of M2, not at month 6. Your teams work on it continuously, on fictitious data, for the whole duration of the project.

Security comes before the end. Tooled audit and configuration review at month 5, with a dated remediation plan — so that fixes have time to be made and re-tested before go-live.

So does load. Performance tests at month 5, at three times the volume communicated at framing.

Requests frozen on the 15th of month 5. No new request is accepted after that date, whatever its outcome.

Month 6 opens no new work. It completes reporting — screens that read off a ledger validated at month 2 — then carries fixes, acceptance testing, training and opening. It is the project's reserve, the only kind of margin that does not dissolve under calendar pressure.

Month by month

The milestones that release a payment

Three of the four milestones release an instalment, alongside the one paid on signature: J1 at month 2, J2 at month 4, then go-live at month 6. A milestone is not a date — it is a list of numbered criteria, run in your presence, on your environment, with your test data.

What makes this calendar achievable

Six partner modules reduced to one configured module. The operation, commission and posting logic is written and tested once instead of six times.

Scope frozen and signed at framing. This removes the main cause of drift: the continuous redefinition of expected depth.

Configuration rather than development. Rate cards, thresholds, charts of accounts, labels and roles are data entered by your administrators.

Beyond V1