Don't let contractors define their own deliverables. Negotiating detailed statements of work reduces project delays, cost overruns and even the likelihood of failure. The success of most technology-related projects involving a contractor turns on an effective Statement of Work (SOW). SOWs typically define and clarify project requirements and are created as additions to professional services agreements. Usually they include a detailed description of the services to be provided, deliverables, milestones, payment terms, service levels, acceptance criteria, specifications and due dates. Yet most of these critical documents are poorly written, subjecting companies to excessive and unnecessary risk—including cost overruns, delays, and even project failure. Courts have made it clear that the vendor is responsible only for delivering items expressly identified in the SOW. They dont have to do anything you didn’t ask for in the contract. Some recent trends in how vendors approach the contract process have exacerbated this problem, but there are steps you can take to exert more control. Resist Sales Pressure The time allocated to draft SOWs is decreasing; often a vendor offers a special deal if the contract is signed immediately or by some arbitrary date. In the face of such sales tactics, customers frequently defer drafting the SOW until after a contract is signed. But at that point, you have little leverage in negotiations and you face mounting pressure to start the project. CIOs should make every effort to negotiate a complete SOW at the same time as the service agreement. However, if circumstances make that impossible, the agreement should include terms that ensure the customer doesnt have to pay, and may cancel the agreement without further obligation, if an acceptable SOW cannot be agreed upon later. Further, a realistic deadline for completing the SOW should be included in the agreement. This way, CIOs still have the necessary leverage to negotiate a favorable SOW after the contract is signed. This bargaining power is particularly important in software license agreements, where a customer may be required to pay license fees while hashing out the SOW. Define your requirements Another alarming trend is the use of the vendors proposal as the SOW. The vendor typically prepares a proposal for the scope of work to be performed—it’s a marketing document, with only an overview or outline of the services. Usually it isnt written as a contract and it tends to contain material that isnt appropriate in a SOW. Furthermore, these documents frequently do not describe essentials such as the specific services to be provided, cost breakdowns (as opposed to general price information), acceptance criteria and due dates. Nonetheless, many proposals include legal terms and signature lines designed to make the document a binding contract—putting you at risk. Another misstep is using templates from vendors to draft the SOW. Although such templates can provide a useful framework, too often they are turned into the final document without incorporating the unique requirements of the deal or the customers specifications. In addition, vendor forms are frequently replete with terms that are favorable to them rather than those that help you: goals instead of obligations, and estimates instead of firm prices, for example. Such terms dilute the vendors obligations. Drafting your own SOW language and negotiating with the vendor protects you from scope creep, delays and price increases. Watch their language Vendors frequently insert legal language into SOWs that conflicts with—and may make unenforceable—the terms of the services agreement. For example, vendors tend to insert new limitations of liability, disclaimers of warranties and provisions relating to intellectual property ownership into SOWs. These terms seldom help you and often redefine key provisions in the original agreement that the vendor wants to dilute or override. Dont let this happen: Except in rare circumstances, once the services agreement has been negotiated, the legal terms should be fixed and uniformly applicable to all SOWs. Otherwise you open the door to contract renegotiation every time you consider a new SOW. You can protect yourself further by adding language to the services contract that favors its terms over any conflicting language in SOWs, purchase orders or other documents. A Solid Foundation Drafting effective SOWs involves preparation, careful attention to detail, and a clear understanding of the business goals and requirements of the project. In addition to avoiding the pitfalls described above, the following steps provide the foundation for drafting effective SOWs: Include an overview section at the beginning of each SOW providing a brief, plain-English explanation of what the vendor is expected to do and deliver. This explanation should be written clearly, so that someone who is not involved with the project but who is generally familiar with technology could understand the services and deliverables the vendor is providing. Include a project plan with a clear schedule for all deliverables and tasks. Don’t refer to deadlines as estimates, and don’t calculate dates from the beginning of the project without clearly defining the date of that beginning. Remove or limit lists of contingencies on the vendors performance, and carefully check the vendors assumptions about your companys performance. Most of the contingencies are very general, creating an out for the vendor if the customer doesnt meet its obligations and allowing the vendor to charge additional fees. Define your own obligations and performance as precisely as possible. Avoid references to sales documents such as proposals or RFPs. These documents may contain legal terms that could conflict with the services agreement. When specific content in these documents is relevant to the project, it should be revised and incorporated directly into the SOW. Ensure the language in the SOW conforms to the services agreement. This means making sure terms defined in the services agreement are also used in the SOW. For example, SOWs tend to refer to work to be performed while services agreements frequently use the term services, and specify what the services are. Using different terms in the SOW creates confusion and may dilute a vendors obligations. Consider breaking complex SOWs into several smaller, discrete SOWs. When necessary, a limited scoping SOW may be used to better define the requirements for a later SOW. For instance, you may want your vendor to perform an assessment to better understand your systems before you commit to a software implementation SOW. Scoping SOWs may also be useful if you want to change how payments are structured, such as converting a time-and-materials assignment into a fixed-fee engagement. By allocating sufficient time to draft clear and detailed SOWs, and by using your own language as the basis for negotiation, you can dramatically reduce potential disputes with vendors, more effectively control costs, and ensure that projects stay on track. Matthew Karlyn is senior counsel and Michael Overly is a partner with Foley and Lardner. Related content Opinion How can CIOs protect Personal Identifiable Information (PII) for a new class of data consumers? Enterprises and data owners must ensure customer data privacy while training their machine learning models. Let us learn how. By Yash Mehta Mar 22, 2023 10 mins Data Privacy Data Science Machine Learning News ServiceNow continues workflow platform expansion with Utah release The company also doubles down on its customer success automation efforts, but bucks the trend by omitting GPT. By Peter Sayer Mar 22, 2023 7 mins CIO Build Automation Enterprise Architecture BrandPost Don’t buy into the hype of network observability to realize digital transformation success Just collect the right data and follow it to where it leads you. By Jeremy Rossbach, Chief Technical Evangelist, Broadcom Mar 22, 2023 3 mins Networking Feature How culture and strategic partnerships help fuel transformation Marc Hale, CTO for AIA New Zealand, recently spoke with Cathy O’Sullivan, editor for CIO New Zealand, about navigating the complexities of digital transformation, and focusing on culture to enable healthier outcomes for customers. By CIO staff Mar 22, 2023 7 mins CTO Digital Transformation Change Management Podcasts Videos Resources Events SUBSCRIBE TO OUR NEWSLETTER From our editors straight to your inbox Get started by entering your email address below. Please enter a valid email address Subscribe