As a technology lawyer, I am often asked by clients to review the statements of work that accompany the technology contract that I have drafted. Unlike some of my colleagues, I consider SOW review to be a critical part of the legal process.
While I don’t pretend to be a technical genius, and I always seek critical input from the client’s business and technical teams, I firmly believe that lawyers can add significant value to the technology transaction by reviewing and critiquing SOWs. As most of us are naturally detailed-oriented and picky, we excel at finding those “gotchas” buried in the SOW that may have eluded our clients, who are rushing to meet deadlines and close deals by quarter end to obtain pricing discounts dangled out by vendors. If acting for a vendor, we can ensure that our clients clearly articulate their responsibilities to avoid deal misunderstandings and possible litigation.
The following are five common errors that I have observed when reviewing SOWs.
1. Referencing an incorrect legal agreement
It sounds obvious, but as SOWs are made pursuant to a signed technology contract, it is absolutely critical to ensure that the SOW correctly references the appropriate underlying signed legal agreement. This is easily one of the most common mistakes that I see, whether because the SOW writers may not be working with the vendor’s legal counsel or because they reuse SOW templates or forget that they are not using their own standard form agreement but rather the client’s vendor of record document (if dealing with a government entity, for example) or other negotiated document. I am aware of at least one major telco that always forgets that the master services agreement currently in place with my client is not their standard technology contract available on their portal but rather a document that they inherited when they purchased the original vendor’s business that happens to contain completely different (and more favourable) terms than their current vanilla contract. It’s critical to ensure the correct legal agreement is incorporated by reference in the SOW, not necessarily the first legal agreement that the vendor happens to include in the SOW. Needless to say, once one figures out the correct legal agreement to be referenced, it should also be the lawyer’s job to ensure that the SOW drafters are using the appropriately defined legal and other terms from the executed contract rather than create contradictions, as will be discussed below.
2. Spurious (or contradictory) legal language
It’s absolutely amazing the business and legal terms that some vendors try to sneak into their SOWs. Some unscrupulous vendors attempt to use their SOWs to completely rewrite critical parts of their signed technology contracts. Alternatively, some vendors may just be clueless/ignorant when the client had negotiated more favourable terms in their executed agreement or in a predecessor agreement that was inherited by the successor vendor (not unusual given all the mergers and acquisitions of smaller tech providers). Eagle-eyed lawyers should watch out for language that attempts to subvert negotiated pricing and payment terms (i.e., the prices in the SOW that are only valid for a limited period of time and that may change after 90 days or are otherwise subject to vendor approval) and other critical clauses that may vary from the signed legal agreement, including acceptance criteria (i.e., deemed acceptance), significant disclaimers of liability, liquidated damages language for early termination/penalty clauses, hierarchy of legal documents, ownership of deliverables/documentation, etc.
3. Overly broad assumptions
Some clients insist that SOWs not contain any assumptions, which can be used by some vendors to limit or otherwise disclaim their responsibilities under the project. While it’s fair for a vendor to list certain assumptions, such as the availability of required client resources to review deliverables, meet certain project responsibilities and provide necessary feedback/approvals to the vendor, these sections of SOWs must be read very carefully so that they don’t serve to completely undercut the vendor’s performance requirements. I recently saw one that read: “The Service Provider understands the Client would like to adopt Service Provider’s functionality as much as possible with necessary configurations. Whereas configurations may not meet business requirements, the Client will review and/or tailor its business requirements based on Service Provider’s solution.” Really? Not so much.
4. Failing to get the payment terms right
How and when does the vendor expect to be paid for the provision of the services/deliverables? Is the project a fixed-fee arrangement or strictly time and materials? Is payment tied to meeting certain milestones/passing specific acceptance tests? Are fees based on the use of onshore v. offshore resources? Are the fees provided just estimates? Do any fees listed remain fixed during the term of the SOW or are they subject to change (for example, because of currency fluctuations) and if so, based on what criteria? What about travel expenses, including lodging, meals and other related criteria? Can the vendor claim any stranded costs for purchased equipment, software licenses, third-party hosting, governance services, etc., following SOW termination, depending on the nature of the termination? If the client wants to make changes to the SOW, how will payment be handled in the change control process, i.e., will the vendor require payment before even scoping proposed changes to the project? It’s absolutely critical that all elements of the payment terms be carefully delineated in the SOW to avoid major confusion and the need for amendments to the SOW.
5. Clarity! Clarity! Clarity!
Perhaps one of the biggest challenges is that clients tend to leave the preparation of the SOWs to the vendor or budget insufficient time for their preparation, given stringent deal timelines. A well-written SOW for a large project can take months to draft (and negotiate), exceeding 50 or more pages in length. At the most basic, the statement of work should set out the key elements of the project, including project overview/scope, list of deliverables/services to be provided, project timeline/schedule, payment terms, responsibilities of the parties, any additional commercial terms, performance requirements/functional specifications, methodologies, service levels and possibly assumptions/dependencies. If not already included in the base technology agreement, the parties may also want to include acceptance criteria/test strategies, change management provisions, governance and escalation/dispute resolution language.
Some vendors cut corners and adopt either very minimalist approaches to their SOWs (five pages, including cover and signing pages) or use such vague language that it is difficult to really understand the scope of what the parties are actually doing. Acronyms abound, words are randomly capitalized, tasks are described in two- or three-word sentences and all meaning is lost. I am never a big fan of vague descriptions such as “Define scope of foundational elements.” Or better yet, “Planning & Alignment.” The SOW must be clearly written and properly articulate the parties’ business expectations. If you don’t understand which party is doing what, when, how, for how much and why, then it’s likely that a judge wouldn’t either.
SOW review should be part of every lawyer’s job in a tech transaction, whether in-house or outside counsel, if given the opportunity.
