The statement of work is where most service-contract disputes start. The master agreement tends to get all the lawyer attention, but the SOW is where the operational details live, and operational details are where the trouble lives too. A good SOW does not just describe a transaction. It controls how the relationship plays out when something inevitably goes sideways.
This was the focus of a How to Contract webinar hosted by Laura Frederick and featuring Marybeth Stramaglia, a fractional in-house counsel with more than two decades of in-house experience across tech, manufacturing, software, and aerospace, and Akiva Miller, an in-house lawyer who has spent most of his career on the vendor side of B2B SaaS and software contracts. Both have lived through the disputes that bad SOWs create, which made the conversation grounded and practical instead of theoretical.
The discussion covered the four areas where SOWs most often break down. Scope description and the value of a clear exclusions list. Choosing the pricing structure that actually fits the work. Why most "assumptions" are really obligations or dependencies in disguise. And what makes milestones and schedules enforceable rather than aspirational. The panel also worked through change order processes, time and materials caps, rework, order of precedence between the MSA and SOW, and how to keep the delivery team informed about what the contract actually says.
Here are our top ten takeaways from the speakers' comments during the webinar:
Treat the SOW as the document where disputes actually live. The master agreement gets the attention, but the SOW is where mismatched expectations and operational gaps show up. Get into the orbit of the SOW before it is final. Do not let it land on the legal desk at the eleventh hour with two days to sign. The cost of being late is not theoretical.
Keep an exclusions list at the end of every SOW. A short section that names the ancillary items specifically out of scope. Marybeth's practice was to add this as a standard section. It does not have to be long, but it has to exist. The list anchors the change order conversation when something gets requested late and gives the team a clear answer when the inevitable late-stage "could you also do" question arrives.
Spell out acceptance criteria with a measurable standard. "Acceptable" is not a standard. Acceptance criteria need to point to a specification, a function, or a performance threshold that can be measured. Without that, every dispute becomes an unwinnable argument about whether the work was good enough. The schedule unwinds along with the argument, because the downstream dates depend on acceptance happening on time.
Match the pricing structure to the work, not to your default form. Fixed fee for known, repeatable work. Time and materials for genuinely uncertain or long-running engagements. Hybrid for managed services where some work is quantifiable and some is ancillary. The structure should fit the risk profile of the deal. Default forms make life easier but often misallocate risk.
Cap time and materials and require a stop-and-notify. The T&M risk is the runaway tab. A cap by itself is not enough because it just shifts the awkward conversation to the cap moment. Pair the cap with a stop-and-notify requirement so the vendor cannot quietly burn through hours and surprise the customer at month end. That preserves the relationship along with the budget.
Convert assumptions into obligations or dependencies. Most things drafted as assumptions are actually somebody's job. Drafting them as obligations gives you a breach if they are missed. If "obligation" is too hard for the relationship, frame it as a dependency with named consequences like excusable delay, price adjustment, or cancellation. The legal effect is similar, the optics are softer.
Lay out milestones in a table that includes rework time. Milestone, acceptance criteria, acceptance timeline, rework timeline, all in one place. Sloppy milestone boundaries where the tail of one milestone bleeds into the next create disputes about what was due when. Treat the schedule as a master project plan and make sure rework does not cascade through the downstream dates. A miss for rework is a different event than a miss for non-delivery, and the schedule should reflect that.
Strike "time is of the essence" and write in the consequence. Time is of the essence has a specific legal meaning that can elevate a missed deadline to an essential breach. That is rarely what either side actually wants. Spell out the consequence the parties have agreed to. A vendor delay shifts payment. A customer delay keeps invoicing on track. Do not import a doctrine you would not have asked for by name.
Build a real change order process. Never agree to agree. Any SOW of any complexity needs a defined change control mechanism. It does not have to be elaborate. Two project leads exchanging signed emails can be enough. But the structure must exist. "Agree to agree" fails the moment the parties actually disagree, which is exactly when you need the process to work.
Summarize the MSA and SOW for the delivery team after signing. Delivery teams do not read master agreements. After signing, send the project manager and key team members a short summary of the terms that will actually affect their work. AI tools draft these summaries well enough as a starting point. The summary closes the "we did not know" defense before it has a chance to appear.
Subscribe to Stay in the Loop
If you found this useful, our weekly newsletter brings these recaps and previews of upcoming How to Contract webinars straight to your inbox. Subscribe now to keep these insights showing up wherever you read your email.
