Statement of Work (SoW)

A Statement of Work sits underneath the master agreement and answers the practical questions: what is being built, by when, against which acceptance criteria, with which assumptions, and what happens when reality drifts from the plan. The clauses that earn their keep are acceptance criteria, change-control, assumptions, and IP assignment — vague versions of any of these are where disputes start.

The trade-off is tightness. A tight SoW ships on plan but generates a change request for every drift, which slows the work and sours the relationship if requirements were never as stable as the document pretended. A loose SoW is flexible but slips silently: scope grows, the date stays, and quality is the thing that gives. The rule of thumb is to make the SoW only as tight as the requirements are genuinely stable.

When the work is well-defined — a migration, an integration, a clearly specified feature — a fixed SoW is the right shape. When the work is exploratory or the product is still finding its form, time and materials or a dedicated development team under a lightweight SoW will get you there with less friction. The mistake is forcing a tight fixed-scope SoW onto discovery work, then spending the engagement arguing about change requests instead of building the product.