In contracts about complicated 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, 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 surprisingly 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
You can describe IT services in two ways. My book, The Tech Contracts Handbook, calls them “task-driven descriptions” and “outcome-driven descriptions.” (See 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 a statement of work like that is the specifications: the technical and functional requirements for the technology. 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, except 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 SoW’s
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’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 existing customer 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.