The contract decides the scope, the dates, the service levels and who owns what on a technology project, often before the design is finished. Delivery and architecture teams should read the signed agreement before they design, compare it with the plan, and raise every mismatch while it is still a planning conversation.
On most technology projects there is a design document that everyone has read. It has diagrams, it has been through review, and the architects can defend every line of it.
There is another document that shapes the project at least as much, and almost nobody on the delivery side has read it. It is the contract.
What does the contract decide on a technology project?
When a project goes wrong, the architecture review usually happens after the fact. The contract review almost never does. That is strange, because the contract has already made a lot of the decisions the team thinks it is still making.
It decides the scope: what is in, what is out, and what counts as a change. It decides the dates: which milestones are fixed, which ones trigger payments and which ones carry penalties. It decides the service levels: response times, availability targets and how they are measured. It decides who owns what: which party provides the environment, the data, the access and the approvals.
Each of those is an architecture decision in disguise. An availability target of 99.9% measured monthly is a design constraint. A payment milestone tied to “go-live” defines what go-live has to mean. A clause that makes the customer responsible for data quality changes how you plan the migration.
How do the contract and the design drift apart?
The pattern is familiar. The sales team and the customer agree a contract. The delivery team receives a statement of work, or a summary of one. The architects receive requirements. Somewhere in that chain, details fall out.
A milestone date that was negotiated hard becomes “target date” in the project plan. A dependency on the customer becomes an assumption nobody writes down. A support obligation that starts at handover is not in anyone’s resource plan. The design is technically right and contractually wrong.
Then the project hits the gap. The team is working to the design. The customer is working to the contract. Both are right by their own document, and the first real conversation about it happens during an escalation.
What should delivery teams check in the contract?
None of this needs a lawyer. It needs someone on the delivery side to read the signed agreement early and ask plain questions.
- What exactly are we committed to deliver, and by when?
- Which milestones are tied to payment, and how is each one accepted?
- What does the customer have to provide, and what happens if they don’t?
- How are the service levels measured, and from when do they apply?
- What is a change, who approves it and who pays for it?
- What happens at the end: renewal, handover or exit?
Then compare the answers with the design and the plan. Every mismatch is either a risk to manage or a conversation to have now, while it is still a planning discussion and not a dispute.
Make it one document set
The best projects I have worked on treat the contract, the statement of work, the design and the plan as one set of documents that have to agree with each other. When one changes, someone checks the others.
That sounds like process. In practice it is a single hour early on, with the right people in the room and the signed agreement on the screen. It is the cheapest risk review a project will ever get.
If you are about to start a project and nobody on the delivery team has read the contract, start there. The design will be better for it, and so will the relationship with the customer.
The same gap shows up before signature, when proposals are compared on price alone (why the cheaper proposal usually costs more in year two), and after go-live, when recovery plans are tested against the wrong scenario (most DR plans are tested against the wrong failure).