Phased delivery with formal acceptance: how a project actually runs

Phased delivery with formal acceptance is the only mechanism we know of that lets a client know, at any moment, what is finished and what is not. It replaces the impossible question — "how is the project going?" — with a verifiable one: which batches have been accepted, and which test cases are still open on the current one?

The rhythm: two-week sprints, contractual milestones

Two timescales coexist, and confusing them is the first source of misunderstanding. The sprint is an internal working rhythm: two weeks, a demo at the end, no contractual commitment attached. The milestone is a contractual event: one complete functional batch, an acceptance run, a signed report, and a portion of the scope definitively closed. A milestone usually spans two to four sprints.

What formal acceptance actually means

"Acceptance" does not mean the client watches a screen and says it looks fine. It is a written procedure, prepared before the batch is built, and executed by the people who will actually use the tool.

1. An acceptance script is written when the batch is scoped: the list of cases to test, expressed in business language, each with its expected result.
2. A dedicated acceptance environment is provided, loaded with your own anonymised production data — not a demo data set.
3. Your users run the cases one by one and record, for each: compliant, non-compliant, or compliant with a comment.
4. Non-compliances are classified together as blocking or minor. Blocking items are fixed before signature; minor ones become dated reservations.
5. The report is signed by someone authorised to commit the organisation. It lists the cases passed, the reservations and their correction deadline.
6. Signature triggers three things: the batch is deemed compliant, the milestone invoice is issued, and that part of the scope is closed to further debate.

The client's role: an available, empowered business owner

No batching scheme works without someone on the client side able to answer and to decide. It is the condition most often underestimated at signature, and the first cause of drift when it is not met. The business owner does not need to be technical; they need to be legitimate.

• Available: roughly half a day a week in steady state, more during acceptance phases.
• Empowered to arbitrate: able to push a request to the next batch, or rule that an edge case will not be handled, without convening a board.
• Holder of the real rules: the person who knows why one supplier has had derogatory treatment since 2019, not only what the official procedure says.
• Able to mobilise testers: acceptance is run by users, not by the business owner alone and not by us.
• A single point of arbitration: four stakeholders producing three contradictory opinions cost more than any change order.

Where that condition cannot be met — a small permanent team, a management absorbed by operations — it is better said at scoping, and the batching adapted: smaller batches, spaced further apart, with shorter acceptance runs. A project sized for the client's real availability moves faster than an ambitious one waiting on answers.

Operations keep running during the build

A rebuild never lands on empty ground. While we build, the organisation keeps working: revenue declarations come in, approval agreements are renewed, the annual statement falls due on its date. The legacy system therefore has to stay operational until the new one has proved itself on the process concerned.

1. 1

   Order the batches by pain, not by architecture

   The first batch tackles the process whose current cost is easiest to measure — often the rebate calculation or the declarations. A first batch that is technically necessary but invisible to users burns the project's credit.

2. 2

   Run the new system alongside the old

   On financially sensitive processes, the first live campaign runs twice: in the legacy tool and in the new one. You only switch once the two results reconcile.

3. 3

   Switch over by user population

   A pilot group of members or staff moves first, on a reduced scope. The rest follow once the usage frictions are fixed.

4. 4

   Decommission the old system explicitly

   The shutdown date is decided and announced, not endured. As long as no date is set, both tools coexist indefinitely and double entry becomes permanent.

The criterion that governs the whole plan

That constraint outranks all the others, and it is checked batch by batch at scoping: if the current batch slipped by two months, which business deadline would be missed? When the answer is "an annual deadline that cannot be moved", the batch is re-cut or shifted outside the critical window. It is also what keeps the plan negotiable until the last moment: the order of batches serves the organisation's calendar, not the other way round.

MEKANO is a Lyon-based development studio. Working this way, we delivered the full rebuild of the management system of a Lyon buying group of more than 60 member companies — member and supplier portals, approval workflows, revenue declarations, a year-end rebate engine and document management — at a fixed price, in successive batches, in Go, React and PostgreSQL.