Vendor Management: Write Statements of Work That Keep IT Projects on Track

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.

1 2 3 Page 1
Page 1 of 3
Download CIO's Roadmap Report: Data and analytics at scale