A couple weeks ago the following tweet was sent my way by @UtterlyMacabre:
Many IT Ks have an “assumptions” section that functions like a disclaimer. What category of contract language would you call this?
Shortly thereafter, @UtterlyMacabre disappeared from the Twitterverse. Too bad, because I thought that was a clever question.
Before disappearing, @UtterlyMacabre steered me to two statements of work (here and here) that did indeed contain a set of assumptions (at sections 3.6 and 2.2, respectively). But statements of work can be a hodge-podge of contract-type language mixed in with technical writing, and that’s the case with these two examples.
With pure categories-of-contract-language analysis in mind, I searched on EDGAR for instances of assumes that, as in “Acme assumes that WidgetCo will supply ….” I didn’t find a single one—the first 300 hits I looked at were non-contract flotsam and jetsam that had found its way onto EDGAR.
I’m relieved that I didn’t find any contract-language examples, because to assume the existence of something is a feature of analysis, and contracts ain’t about analysis. Instead of assuming that WidgetCo will supply something, you make it WidgetCo’s obligation to do so, or you make it a condition that it do so. Clear consequences flow from that; that’s not the case if you assume the existence of something.
Ken:
I have seen these a lot. They are very typical of statements of work written by information technology personnel and their mode of writing is appropriate for their context. It is appropriate for their context because their role is strictly constrained. The business people say, “Here are the inputs you will have. Here are the outputs we want. Define the project to make that happen.” When they do so, they start with the inputs as assumptions. They are often not privy to any decisions — if any have been made — about what would happen if those assumptions were false.
But it would still be bad to put that statement of work into the contract. The potential falsity of those assumptions is what makes bad. This is usually beyond their scope, so they can’t tell you what would happen. Typically, a business person needs to sort it out into at least the following buckets:
1. Assumptions that should really be expressed as a party’s obligation.
2. Assumptions that should really be expressed as a party’s obligation, but that party has barganining power, so it will only be expressed as a condition on the other party’s performance.
3. Assumptions that should really be expressed as a condition on a party’s performance.
4. Assumptions that only affect the timing of performance, so delays should excuse delays in performance to some degree.
5. Assumptions where the falsity so undermines the entire purpose of the project that the parties need a termination right.
6. Assumptions that only affect the amount of work to be performed, so the falsity of the assumption should result in greater compensation paid for the performance.
7. Assumptions where the falisty triggers some legal duty that the parties can accommodate, but need contractual language to accommodate.
There are probably many others.
Assumptions sections are a treasure trove of unresolved potential problems for lawyers schooled in your analysis of types of contractual language.
Chris
That’s very useful to know.
Chris’s taxonomy is a wonderful refresher course in why lawyers should look carefully at SOWs, which many bypass on the grounds that “it’s just technical stuff.”
Most SOWs camp on to professional service agreements, and it would be helpful to have the concept of assumptions in the SOW described and the consequences of the failure of different types of assumptions stated. This is truly contractual stuff that shouldn’t be left to the technical types who produce SOWs, and therefore shouldn’t really appear in the SOW at all.
SOW Assumptions: Where the rubber meets the road. I wholeheartedly support Chris’ analysis of what “Assumptions” in agreements (professional services, consulting engagements, letter engagements, statements of work, etc.) really mean. The assumption litany can be explained in one sentence: “Please let us do our job in the way we originally discussed and contemplated.” Of course this is a broad statement and realistically is not something that parties can use in their agreement. But the gist of the “Assumptions” (and to a large degree, the “in-scope” and “out of scope” sections of these documents) is to set a fence around the requested task or series of tasks. Over time, and after getting burned on delays, price, staffing, changes, etc., service providers have evolved the simple statement of “let me do my job” into this rote list “designed” to protect the quoted price for the service. At this point I could probably list from memory the standard assumptions provisions that large tech companies like EMC, IBM, HP, Oracle, etc. enumerate in all engagement documents. The drafting is not elegant and it’s not entirely clear how to evaluate failed assumptions in a possible breach situation, but re-inventing this wheel has a very pragmatic hurdle: namely, how does a tech attorney justify the time spent (both in-house and outside counsel are cost centers) forcing the technical teams to walk through each assumption to clarify, revise, find a better home for it, etc.?
Service Agreements pose an interesting quandary for the attorney charged with efficiency and quality drafting. Businesses hire service providers to fill a need that the organization is either ill-equipped or ill-suited to handle themselves or for projects that are one-time expenses. Sure, there’s a big “duh” – but here is the point: most departments, supervisors, employees, etc. have vague job descriptions and functions that make up what it/they are supposed to do each day. It’s not contractual. Tasks get completed, projects get completed, and so on. When you hire a service provider, simply articulating the goals and hoping that the deadline is met is not the way most companies do business. So lawyers and technical teams are supposed to put words to these tasks and prevent surprising consequences. But they must do it quickly, painlessly, and in such a way that doesn’t add to the overall budget. Furthermore, the odds of the document rising to a litigious or potentially litigious situation is low. Instead, I see these provisions (both artfully and in-artfully drafted) referenced when the project has veered off track and the business teams have to renegotiate. And by “referenced”, I mean when they are assigning blame to each side for messing something up or missing a deadline . . .
I’m not aiming for an apologia on the drafting of statements of work in general – but pondering the forces that stand in the way of a better document. What is the best way to marry clarity and efficiency in something that cannot be reduced to boilerplate?
I certainly have no simple solution to offer. But if something is worth saying, it’s worth saying using the appropriate category of contract language. You do it once, and thereafter people understand better what the deal is and things proceed more smoothly. At least that’s the theory!
Currently “negotiating” with a large multi national property maintenance company on the wording in our agreement. They have left out a lot without too much thought to show their client cost saving. When work outside the agreement needs to be done we have an email stating “we made the assumption” for parts cost mark up.
They have a comprehensive contract with their client and have given out less than comprehensive sub contracts. Interesting times. I’m assuming it can’t keep going this way for long.