This week’s musings on tech contracts…
The SoW for a large IT development project generally features a long list of duties for the vendor. But the customer usually has tasks too, often woven in among the vendor’s duties and making up a list almost as long. Big SoWs also generally include a series of assumptions and contingencies. The result: a baffling maze of text.
How do we navigate this maze? For complex technology SoWs, write outcome-driven descriptions of professional services, not task-drive descriptions. That strategy works particularly well for agile software development, but it’s a good fit for nearly all complex IT SoWs.
In other words, focus on the goal of the SoW. In most cases, that’s the technology the vendor will create, implement, repair, or manage. Describe that technology – e.g., “the System” – and then write: “Vendor shall design and deliver the System according to the specifications in this SoW.” Or, “Vendor shall maintain the System so that it functions materially according to the specifications in this SoW.”
All other language is secondary and should spend some time on the chopping block. Include details about how the job will get done – task-driven language – only to the extent absolutely necessary. And separate those terms from the SoW’s main body: the outcome-driven language.
Two Ways to Describe Professional Services
You can describe IT services in two ways. In my book, The Tech Contracts Handbook (Part I.E), I call them “task-driven” and “outcome-driven” descriptions.
Task-Driven Descriptions
Task-driven descriptions outline the vendor’s tasks but don’t say what they’re supposed to achieve. For instance, “Vendor shall provide 10 consultants 40 hours per week to assist Customer with system integration.” That leaves out requirements for the outcome: what the “integration” should look like when done. Or, “Vendor shall provide technical support by telephone during Business Hours.” Again, the outcome isn’t listed.
Task-driven descriptions work best for projects without easily defined outcomes, like tech support. They also work when the vendor provides bodies – people – with no little or no responsibility for the outcome of their work.
Outcome-Driven Descriptions
Outcome-driven descriptions, on the other hand, describe the vendor’s work product. For example (and expanding on the language suggested above): “Vendor shall develop the system described on Attachment A (Specifications), provide it to Customer on or before the Target Go-Live Date, and maintain it so that it operates according to Attachment A.” The heart of an SoW like that is the specifications: the technical and functional requirements for the technology.
An outcome-driven description leaves out terms about how the vendor achieves the outcome. The SoW has few or no requirements about coordinating subcontractors, numbers or skills of staff, choice or price of resources, etc.
An outcome-driven SoW might even leave out details about the timeline for the work, with no time-related requirements except a go-live deadline. So long as the vendor hits that final deadline, it can move its various tasks forward at whatever pace it sees fit. But multiple timelines can work even better, with work divided into deliverables, each with its own due date. That gives you several outcome-driven descriptions, each with its own deliverable and milestone deadline.
Navigating the Complex SoW Maze
Most large, complex statements of work include both task-driven and outcome-driven descriptions, and that’s hard to avoid. But I recommend focusing on outcome-driven descriptions as much as possible.
Outcome-driven descriptions work because the details left out – how the vendor will build or run the system – matter less than the outcome. And they’d lead to a long, unwieldy document. Also, complex projects tend to evolve. So an SoW with detailed “how” requirements would have to be amended over and over, assuming the parties even notice the disconnect between SoW and project.
Outcome-driven descriptions also give the vendor the chance to make more money at no cost to the customer. If the SoW doesn’t specify how the job is supposed to get done, the vendor can switch to more efficient and less expensive methods as it discovers them, increasing its margins.
A Really Good Fit for Agile Software Development
Outcome-driven descriptions work particularly well for agile projects, where the parties don’t know most of the project’s details at the start. Vendors sometimes argue that agile projects should have no technology descriptions, since the tech is TBD, but that’s wrong. Agile projects maximize flexibility, but they still need to produce whatever it is that the customer needs. The solution: light, short high-level technical specs, or possibly functional specs, describing the customer’s needed system from 10,000 feet.
From there, the SoW might have a few details about managing sprints – task-driven descriptions – but it would say little more.
The Task-Driven Stuff Does Have a Place
Few complex SoWs rely entirely on outcome-driven descriptions. Usually, you need a few “how” details, addressing topics like governance and integration with the customer’s existing suppliers and technology. Those task-drven descriptions have their place, but they work best, and read best, if you separate them from the outcome, in separate sections.
That should cut down on confusion and focus the drafters and future readers on what matters most: the outcome.
You can learn more about drafting specifications, SoWs, and other technical terms in course 2 of The Tech Contracts Master Class™ (available on-demand). Also, on September 4, 2025, I’m teaching a live webinar called Statements of Work and Specifications: Drafting and Negotiating. I hope to see you there. And please check out our other IT contract trainings (available for individuals and teams, live or on-demand).
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 ACTION ON ANY SUGGESTION IN THIS ARTICLE, YOU SHOULD CONSULT A QUALIFIED ATTORNEY REGARDING YOUR SPECIFIC MATTER OR NEED.
© 2025 by Tech Contracts Academy, LLC. All rights reserved.