What to demand before you sign

The first article was about the signs of a programme already in trouble. The second was about what to do once you have seen them. This one is about the stage before either applies — the proposal on your desk, the contract you are about to sign, and the handful of terms that decide whether the warning signs in the first article can ever be hidden from you.

This is written for build and delivery engagements: bespoke development, or a major platform implementation where you are commissioning work rather than subscribing to finished software. It is not a legal checklist, and I am not a lawyer. It is the short list of terms that matter, what each one is really for, and what a vendor’s reaction to it tells you. Your lawyer settles the exact wording and the exact numbers for your jurisdiction. Your job is to know what to ask for, and to read the room when you do.

Across all five, the pattern is the same: the term itself is ordinary, and the vendor’s resistance to it is the information.

Access to the backlog, not just the status report

Most contracts promise reporting — monthly updates, RAG indicators, milestone summaries. That is not transparency. That is a performance, and the first article explained how a green status report stays green long after the work has gone red.

What you want instead is read-only access to the system the delivery team actually uses: the backlog, the board, the sprint plan. Not a tidied export prepared for you. The live tool. With it, you can see what is being worked on, what is blocked, and how long items have sat in one column without moving. That is the single term that makes watermelon reporting structurally impossible.

Vendors push back, and the objections are predictable. Our backlog holds confidential work for other clients — so ask for a view filtered to your project. It would overwhelm non-technical stakeholders — which usually means they would rather you didn’t see how the work really moves. We’re Agile, the backlog changes constantly — which is exactly why you want to watch it change. A vendor who still refuses after every reasonable accommodation is telling you they are not confident you would like what you saw. That is worth knowing before you sign, not after.

Payment tied to delivery, not to the calendar

The usual structure is time-based: a slice on signature, a slice at the “midpoint,” a slice at go-live. The problem is that the midpoint is a date, not an achievement. If nothing has shipped by then, you have still paid most of the contract.

The alternative is to tie payments to demonstrable delivery — specific functionality, completed, tested, and accepted. “Front-end phase complete” is still a calendar date wearing a deliverable’s clothes. “User registration, login, and password reset live on staging and signed off by your technical lead” is something you can verify before the invoice is paid. You do not need to dictate the schedule of payments in the contract yourself; you need to establish the principle that money follows accepted work, and let your lawyer shape the mechanism.

Vendors resist this because it moves risk onto them, which is the entire point. A vendor confident in their delivery will accept the principle and negotiate only the definition of each milestone. A vendor who argues for vague milestones, or for payment on dates regardless of output, is telling you they do not trust their own ability to deliver.

Audit rights you would actually use

Most contracts already grant audit rights, and almost nobody exercises them, which means they are not real. “The client may audit the vendor’s performance on reasonable notice” is unenforceable in practice — “reasonable” and “performance” are undefined, and the vendor is betting you will never spend the time to test it.

A usable version is specific about four things: how often you can audit, what the audit can cover, how quickly the vendor has to respond, and who pays. The shape worth asking for is an audit available at least annually and after any serious failure; scope that reaches delivery metrics, resourcing, and any subcontractor touching your data; a response within a defined, short window; and costs you carry unless the audit finds material non-compliance, in which case the vendor does. Hand those four dimensions to your lawyer and let them set the precise figures.

Vendors will negotiate every one of those down, and that is normal. What is not normal is refusing the principle, or trying to carve delivery practices out of scope. A vendor who will not let you verify what their status reports claim does not expect those claims to survive a look.

Exit terms you could actually use

Every contract has a termination clause. Most are built to make leaving expensive or procedurally exhausting — written to reassure your lawyer, not to give you a real way out if the vendor stops performing.

A usable exit has three parts. You can end the contract for cause if the vendor commits a material breach, with a short window for them to fix it first. You can end it for convenience, on notice, paying for work genuinely completed plus a fair wind-down. And on the way out you take everything you have paid for: the completed work, the source code, the documentation, and the IP. Your lawyer fixes the notice periods and the fee band; you make sure all three parts are present.

The convenience exit is where judgement matters most. A firm that has staffed a dedicated team for you carries real cost when you leave early, and a wind-down fee can be honest cost recovery rather than a lock-in. The way to tell them apart is to ask for the basis. A vendor protecting against genuine cost will walk you through it. A vendor building in lock-in will resist breaking the number down at all. The tell is not the percentage. It is whether they will show you how they got to it.

Scope with acceptance criteria, not a vision statement

The statement of work in most contracts is written in strategy language: “a customer-facing portal to improve engagement and streamline operations.” That is a vision, not a scope. It tells you nothing about what “done” looks like, so every later argument about whether something was included becomes a negotiation you are not equipped to win.

Enforceable scope fixes two things and leaves one open. It fixes the outcome — the portal does these specific jobs — and it fixes the acceptance bar — these named people verify it, against these criteria, before it counts as delivered. What it deliberately leaves open is how the vendor gets there. That distinction is what keeps this compatible with genuine iterative delivery: the team can change its approach, its sequencing, even its technical design as it learns, as long as the agreed outcome and the agreed acceptance bar do not move. “We’ll figure it out as we go” is not Agile. Iterating freely toward a fixed, verifiable result is.

A vendor who wants to recommend better solutions mid-build can do exactly that through a change process written into the contract. A vendor who resists any acceptance criteria at all wants room to define success after the fact. That flexibility protects them, not you.

---

These terms are mostly standard. The leverage to ask for them is at its highest before the vendor knows you want the engagement. After that, every concession costs something.