A Statement of Work turns a signed relationship into a defined engagement. The usual construction is a master services agreement (MSA) holding the legal ground rules once — liability, IP, confidentiality, payment terms — with a separate SOW per engagement describing the work itself. New project, new SOW, no renegotiating the legal frame.
What a usable SOW pins down:
- Scope — and explicit exclusions. What is out matters more than what is in; exclusions are where disputes go to die quietly.
- Deliverables with acceptance criteria — what "done" means, who confirms it, and within how many days.
- Timeline and milestones, if payment or deadlines hang on them.
- Team and billing — the model (time and materials, retainer, fixed price), rates or the fixed amount, currency, invoicing cadence.
- Assumptions and dependencies — client-side access, decisions, environments; a missed assumption is a legitimate change request, not a free overrun.
- The change procedure — how scope moves and who signs.
The test is simple: if the billing model, the rate and "what does done mean" can't be answered from the SOW alone, it isn't finished — and delivery will re-answer them later, from memory, under pressure.
In Helia, there is no contract repository, but a project card mirrors the SOW's operational facts — billing model, rate or flat amount, currency, dates, customer and delivery manager — and those fields are exactly what capacity plans and generated invoices then run on, so the SOW's numbers and the billed numbers stay one and the same.