In contracts about complicated services, the hardest terms to draft appear in statements of work. SoWs 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 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 SoWs
You can describe IT services in two ways. They’re often called “task-driven descriptions” and “outcome-driven descriptions.” 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 a statement of work 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 timelines, other than go-live deadlines — though that’s not necessary. (You can break specifications into a series of deliverables due at different times. That gives you several outcome-driven descriptions, each with its own milestone deadline.)
Outcome-driven descriptions in complex SoWs
Most statements of work include both task-driven and outcome-driven descriptions. But for complex projects, use 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 turn out not to 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 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 is supposed to get done, the vendor can switch to more efficient and less expensive methods as it discovers them, increasing its margins.
Few complex SoWs rely entirely on outcome-driven descriptions. Usually, you need a few “how” details, addressing topics like governance and integration with existing customer suppliers and technology. But your complex SoWs 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.
ABOUT THE AUTHOR - David Tollen is the author of The The Tech Contracts Handbook (ABA Publishing 2015) and the founder of Tech Contracts Academy, where he provides training on drafting and negotiating information technology contracts. Those trainings include workshops on statement of work drafting, particularly on outcome-driven descriptions. 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 software licensing, cloud computing agreements, and other IT contracts, and he also serves as an expert witness in litigation about those same agreements.
For more on managing complex projects, see the writings of Robert Prieto of Strategic Program Management, LLC — including Theory of Management of Large, Complex Projects (Construction Management Association of America 2015).
© 2018-2019 by Tech Contracts Academy, LLC. All rights reserved.
Art and photo credits: Pixabay.com.