Tech buyers often think they can’t have tight acceptance terms for projects with undefined deliverables. In agile software development and other exploratory projects, the parties don’t know what deliverables will do when they sign. So, the SoW can’t include specifications or acceptance tests … or so the argument goes.

But that’s not right. You can add specs and acceptance tests to a project like that – in two ways.

(1) Write highly functional specifications, with little or no technical detail.

After all, it’s not like the vendor can build anything it wants. It still has to create software or other tech addressing the customer’s needs. So express those needs in very general specs. And then add acceptance terms saying the customer doesn’t have to accept if the deliverables don’t materially fit those specs.

But we can do even better:

(2) Make Deliverables Serve as Specifications.

If phase 1 is testing and exploration, for instance, its deliverable IS the specification for technology to be produced in phase 2. The “specs” for phase 1 are high level, functional descriptions of the technology the customer needs. And the vendor’s first deliverable is a more detailed, more technical set of specifications built on top of those original functional specs.

The SoW can provide that, once that phase 1 deliverable is accepted, it becomes the specifications for phase 2, where the vendor actually delivers the software. And the customer accepts that software/tech deliverable if it materially fits those phase 2 specs.

Where specifications are a moving target, consider this sample clause (from The Tech Contracts Handbook (3^rd ed.), Part II(A)):

            Specifications as a Deliverable

Provider shall draft technical specifications for the Software on or before ______ [date], and such technical specifications shall be materially consistent with the requirements of Attachment A of this Agreement (High-Level Specifications). Upon acceptance of the proposed technical specifications pursuant to Section __ (Acceptance of Deliverables), they shall become the Software’s “Technical Specifications,” and Provider shall design the Software so that it materially complies with such Technical Specifications.

To Learn More:

• We talk more about this in in The Tech Contracts Handbook (3^rd ed.) (Part II(A)).
• And you can find this and more sample clauses from The Handbook (free) at our website, here:  https://www.techcontracts.com/clauses-overview/general-clauses/#clauses-menu.
• For more discussion of “outcome-driven” specifications in SoWs, please see: https://www.techcontracts.com/2025/02/06/outcome-driven-descriptions-in-big-complex-sows/
• Finally, for a deeper dive into these topics (and a lot more about information technology contracts), consider joining The Tech Contracts Master Class™. More information and enrollment is available here: https://courses.techcontracts.com/p/the-tech-contracts-master-class-4-course-series-2.

© 2026 by Tech Contracts Academy® LLC. All rights reserved.

THIS ARTICLE IS NOT LEGAL ADVICE. IT IS GENERAL IN NATURE AND MAY NOT BE SUFFICIENT FOR A SPECIFIC CONTRACTUAL, TECHNOLOGICAL, OR LEGAL PROBLEM OR DISPUTE, AND IT IS NOT PROVIDED WITH ANY GUARANTEE, WARRANTY, OR REPRESENTATION. LEGAL SITUATIONS VARY, SO BEFORE ACTING ON ANY SUGGESTION IN THIS ARTICLE, YOU SHOULD CONSULT A QUALIFIED ATTORNEY REGARDING YOUR SPECIFIC MATTER OR NEED.