Skip to content

Glossary

Statement of work

The document defining what an outside firm will deliver and by when, which is what a later disagreement gets settled against.

In plain terms

The written answer to what exactly you are paying for. Everything before it is a conversation, and conversations are remembered differently by the two people who had them, which is the entire reason the document exists.

01

Why it matters

Because AI projects are unusually easy to describe in ways that sound specific and are not. Improving how a team handles enquiries, or making internal knowledge easier to find, are recognisable goals and neither says what will exist at the end, so a document written in that register cannot settle a disagreement about whether the work was completed.

02

How it works

Deliverables and activities are different things, and confusing them is the commonest fault. A configured system, a written handover and a trained group are things that either exist or do not; workshops held and support provided are descriptions of effort, and effort can be delivered in full while leaving nothing behind.

Acceptance is the clause that decides everything and is the one most often vague. Who decides the work is finished, against what, and how long they have to say so: without those three, completion becomes a matter of opinion at exactly the moment the two parties have started disagreeing.

What the buyer has to provide belongs in it too. Access to systems, decisions within a stated time, people available to be trained: these are the commonest cause of a project running late, and a document silent about them makes the delay look like the supplier's fault when it frequently is not.

AI work has a specific difficulty about the standard being met. Quality is a judgement rather than a threshold, so the useful version defines the evaluation rather than the outcome: this set of cases, judged by these people, against this description of a good answer, agreed before the work starts rather than argued after it.

Change is normal in this category and the document should expect it. A project that learns something in its first fortnight ought to change, and a statement of work with no path for that either blocks the improvement or gets quietly ignored, which leaves the organisation with a signed document describing a project nobody is running.

Two ways to write the same line

Two ways to write the same lineThe left-hand column is not dishonest and it is what most documents contain, because it is how the work is genuinely described in the conversation that precedes them. Somebody says they will run workshops and provide support, and they mean it, and they do it. The difficulty arrives months later when the buyer feels the project did not land and the supplier can demonstrate that every line was performed, and both are correct. Nothing on the left is falsifiable, so nothing on the left can settle it. Rewriting to the right-hand column costs one drafting session and changes what the money is buying, from a quantity of effort to a set of things that will exist. It has a second effect worth having, which is that the conversation needed to write the right-hand column is the useful conversation anyway: agreeing which twelve people, which cases, and who accepts the summary forces both sides to discover early where they had different pictures. That discovery is cheap in a drafting session and expensive at the end of a project.ActivityRun discovery workshops.Provide configuration support.Deliver user training.DeliverableA written summary, accepted bythe sponsor.A configured system passing theagreed cases.Twelve named people trained,with materials left behind.Every line on the left can beperformed in full while leavingthe organisation with nothing itcan point at. Every line on theright either exists at the endor does not, which is the onlyproperty that makes a disputeresolvable.
The left-hand column is not dishonest and it is what most documents contain, because it is how the work is genuinely described in the conversation that precedes them. Somebody says they will run workshops and provide support, and they mean it, and they do it. The difficulty arrives months later when the buyer feels the project did not land and the supplier can demonstrate that every line was performed, and both are correct. Nothing on the left is falsifiable, so nothing on the left can settle it. Rewriting to the right-hand column costs one drafting session and changes what the money is buying, from a quantity of effort to a set of things that will exist. It has a second effect worth having, which is that the conversation needed to write the right-hand column is the useful conversation anyway: agreeing which twelve people, which cases, and who accepts the summary forces both sides to discover early where they had different pictures. That discovery is cheap in a drafting session and expensive at the end of a project.
03

Seen in the wild

  • Defining an assistant rollout as a configured deployment and a trained group rather than as workshops delivered.

    ChatGPT
  • Agreeing the evaluation set for a search deployment before the work starts rather than after.

    Glean
  • Naming which systems the buyer must give access to, and by when, for an automation build.

    Make
04

Common misconceptions

People assume

A detailed scope is the important part.

In fact

Acceptance is. A long scope with no statement of who decides the work is complete, against what, and within what period leaves the only contested question unanswered, and that question only arises once both sides have stopped agreeing.

People assume

It is the supplier's document.

In fact

It binds both sides, and the buyer's obligations are the half most often left out. Access, decisions and people are what projects actually wait on, and a document that omits them turns a shared delay into an apparent supplier failure.

05

Questions

What is the single most valuable clause?
Acceptance. Naming who signs off, what they are judging against and how long they have converts completion from an opinion into a process, and it is worth more than any amount of additional detail in the scope section above it.
How do you write one for work whose quality is a judgement?
By defining the judgement rather than the outcome. Agreeing the cases to be tested, who evaluates them and what a good answer looks like, all before the work begins, turns an argument about quality into a procedure both sides already accepted.
Should it allow for the project changing?
It should assume it will. Work in this category routinely learns something early that makes the original plan wrong, and a document with no route for that either prevents the improvement or gets ignored, which leaves a signed description of a project nobody is actually running.
06

Key takeaways

  • Deliverables exist or do not; activities can be completed leaving nothing behind.
  • Acceptance is the clause that settles the only contested question.
  • The buyer's obligations belong in it, because projects wait on them.
  • Where quality is a judgement, define the judgement before starting.
08

Tools that use this

  • ChatGPT

    A configured deployment and a trained group, not workshops delivered.

  • Glean

    Agreeing the evaluation set before the work rather than after.

  • Make

    Naming which systems the buyer must open, and by when.

Last checked August 2026

All glossary terms