The buyer's playbook stages 04
What your partner owes you, phase by phase
The client-side view of an implementation: the deliverable at the end of each phase, who signs it, what done should mean, and how payment ought to be attached to it.
After this stage: A phase plan where every stage ends in something you can inspect, refuse or sign.
A project without phase deliverables is a project you cannot inspect. Months pass, everyone reports good progress, and the first honest look at the system happens during testing — far too late to change anything cheaply.
The fix is simple: every phase ends with something real that you review and sign.
The seven phases and what you get
| Phase | What you should receive | Who signs | What “done” means |
|---|---|---|---|
| Discovery | Written description of how your processes actually run, with volumes | Process owners | Your own people recognise their work in it |
| Fit-gap | The matrix: every requirement marked standard, configuration, custom or process change, with days | Decision owner | Every requirement has a verdict and a number |
| Configure & build | A working staging system, demonstrated on your data | Process owners | You clicked through it yourself, not watched a demo |
| Data migration | Staging loaded with your real master data and opening balances | Data owner + your accountant | Balances reconcile to your existing books |
| UAT & training | Test results by requirement, and trained users | Process owners | Your team ran their real month on staging |
| Go-live | Production system, cut-over log, rollback plan | Sponsor | The business is working on it, and old system is read-only |
| Hypercare | Fixed issues, handover pack, documentation | Decision owner | You could run without the partner if you had to |
Attach payment to deliverables
The single most effective contract term available to you. Payment stages should follow accepted deliverables, not dates on a calendar.
A workable shape:
- On signature — enough to start, commonly 20–30%
- On accepted fit-gap — the analysis is real work and deserves paying for
- On accepted staging demonstration
- On accepted UAT
- On go-live
- A retention of 10–15%, released after hypercare
The retention matters more than the percentages. It is what keeps a partner engaged through the unglamorous weeks after go-live, when the interesting work is over and the real problems appear.
What good sign-off looks like
Sign-off is not a formality and it is not permission to stop asking questions. It means: we looked at this, it does what was agreed, and we accept it as the base for the next phase.
Rules worth keeping:
- One named signer per deliverable. Committees do not sign; they discuss.
- A review window in the contract. Five working days is normal. Without one, the partner is blocked by your diary and will say so, fairly.
- Refusal must be specific. “Not happy with it” is not refusable feedback. “Requirements FIN-014 and SAL-021 are not demonstrated” is.
- Write down what you accepted knowing it was imperfect. Deliberate compromises are fine. Forgotten compromises turn into disputes.
What you owe the partner
Phase gates run both ways, and most delays in Odoo projects are client-side.
- Answer questions within an agreed time. A partner blocked on a decision is still being paid.
- Provide data when promised, in the agreed format.
- Release your testers for the days you committed.
- Send one voice. Contradictory instructions from two departments will stop progress faster than any technical problem.
- Sign or refuse within the review window.
A good partner will log delays caused by you. That is not hostility; it is what protects both sides when the date moves.
When a phase slips
Ask three questions, in this order:
- What exactly is not finished? By requirement ID, not “the sales module”.
- What caused it? Underestimation, a change, a decision waiting on you, or something discovered.
- What does it do to the go-live date?
Then choose one of the three levers — move the date, cut scope, or add resource. Accepting a promise to catch up later is not a fourth option, and it is the one most projects take.
The document to insist on
Ask for a one-page status report every two weeks, containing:
PHASE .................. current phase, planned end date
REQUIREMENTS ........... done ..... / total ..... (by ID)
CHANGE REQUESTS ........ raised ..... approved ..... days added .....
BLOCKED ON CLIENT ...... item, who owns it, since when
RISKS .................. what could still go wrong
NEXT DELIVERABLE ....... what, and when you will see itIf your partner cannot produce this, they are not tracking the project by requirement, which means nobody can tell you what is finished. That is worth knowing in month one rather than month five.