Drafting Big, Complex Statements of Work

In contracts about complex services, the hardest terms to draft appear in statements of work. SoW’s for large projects demand long lists of duties from the vendor. And usually they’re interwoven with supporting tasks from the customer and its other suppliers, along with countless contingencies, assumptions, and exceptions. Putting all those pieces into an effective contract document challenges the best drafters. The result is often hundreds of pages of baffling mess. Yet the path to good drafting is simple: write outcome-driven descriptions. In other words, describe the technology the vendor will create or run or both, and then stop typing.

Task-Driven and Outcome-Driven SoW’s

drafting statements of work

You can describe IT services in two ways. My book, The Tech Contracts Handbook, calls them “task-driven descriptions” and “outcome-driven descriptions.” (See 2nd Ed., Chapter I.F.) Task-driven descriptions outline the vendor’s tasks but don’t say what those tasks are supposed to achieve. For instance, “Vendor shall provide 10 consultants 40 hours per week to assist Customer with system integration.” That description leaves out requirements for the outcome of the work: the “integration.” Or, “Vendor shall provide technical support by telephone during Business Hours.” Again, the outcome isn’t listed: the goal of the tech support. Task-driven descriptions work best when the vendor provides bodies — people — with no little or no responsibility for the outcome of their work.

Outcome-driven descriptions describe vendor’s work product. “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 (in Attachment A in our example). The description leaves out language about how the vendor achieves the outcome. In other words, 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 the various project components 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. (That also creates a good structure for milestone payment terms.)

Outcome-Driven Descriptions in Complex SoW’s

hard, math-driven statements of work

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 — would lead to a long, unwieldy document. Attempts to describe those details inevitably generate terms that ultimately don’t make sense. Plus, 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 and understand the disconnect between SoW and project. Finally, outcome-driven descriptions give vendors the chance to make more money, at no cost to the customer. If the SoW doesn’t specify how the job’s supposed to get done, the vendor can switch to more efficient and less expensive methods as it discovers them, increasing its margins.

Few complex SoW’s 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. But your complex SoW’s will be most effective if they focus on the outcome — on specifications for the technology to be built or run — and minimize restrictions on how.

[minti_divider style=”1″ icon=”” margin=”60px 0px 60px 0px”]

Notes:

David Tollen is the founder of Tech Contracts Academy and our primary trainer. He is an attorney and also the founder of Sycamore Legal, P.C., a boutique IT, IP, and privacy law firm in San Francisco. His practice focuses on those same topics, and he also serves as an expert witness in litigation about software licenses, cloud computing agreements, and other IT contracts.

© 2018, 2020 by Tech Contracts Academy, LLC. All rights reserved.

Thank you to Pixabay.com for great, free stock photos!

Share the Post:

Related Posts