Statement of Work (SOW)

A statement of work is the document that describes a specific piece of paid work: what will be delivered, who does it, on what schedule, at what price, and how everyone will know it is finished. It usually sits under a master services agreement, which carries the legal terms that do not change, so each new project needs only a short SOW rather than a fresh negotiation of liability and confidentiality. Its centre of gravity is the deliverables list. A deliverable is a thing that can be handed over and inspected — a migrated dataset, a configured environment, a set of integrations, a trained group of administrators. Anything phrased as an activity rather than an artefact tends to be the source of the eventual dispute, because "support the integration" has no moment at which it is done, while "the integration passes these named test cases" does. Acceptance criteria are the other half of that. Write down what the buyer will check, how long they have to check it, and what happens if it fails: a defined remediation window, then a second review, then a remedy. Without that, acceptance defaults to whoever loses patience first, which is usually the party that has already paid. Assumptions and dependencies deserve their own section because they are where the schedule quietly lives. A vendor's timeline almost always assumes access to systems, availability of your subject-matter experts, data supplied in a particular shape, and decisions returned within a certain number of days. Naming them makes it explicit that a slipped deadline may belong to the buyer, which is a more useful conversation than the one that starts after the date has passed. For AI implementation work, three items are worth writing down that generic templates omit. What data the vendor needs from you, in what form, and who prepares it — data readiness is the usual cause of an overrunning project. What the quality bar is, expressed as an agreed measurement on an agreed set of cases, rather than as a promise of accuracy. And what happens to models, prompts, configurations and evaluation sets at the end: whether they are yours, and in what portable form you receive them. Change control closes the loop. Scope moves in every project, and a SOW that cannot absorb change generates either unpaid work or an argument. A one-page change-order process, with a named approver on each side and a rule that changes are priced before they are started, keeps the original document trustworthy instead of turning it into a historical curiosity by the third week.