Plenty of Room for Improvement: My Critique of IBM’s New Two-Page Cloud-Services Contract (Updated with PDFs Containing the Comments)

Via a regular source of my Twitter leads, @ronfriedmann, I learned of this article in Corporate Counsel by Sue Reisinger about how a team at IBM “earned international recognition for taking dozens of pages of complex contracts for cloud services and reducing them to a simple, two-page document.”

Assuming that you get rid of the dead wood, make appropriate trade-offs, and don’t lose anything vital, shorter is good. Apparently the response has been positive. Indeed, the new contract resulted in IBM’s being named a finalist in IACCM’s Innovation Awards, in the operational improvement category.

The article quotes the head of the IBM team as saying that the new contract uses “concise, plain language.” Doubtless it’s more concise and plainer than what came before, but there’s plenty of room for improvement. How much room? [Updated December 29, 2014: At the request of @tieguy, I created PDFs that includes all the comments. Go here for a PDF with the comments on separate pages; go here for a PDF with connector lines between the comments and the related text, but with smaller text as a result.] Go here to see my annotated PDF. Thanks to dozens of comments, it’s awash with fluorescence. (To read my comments, you’ll have to download the PDF and open it with whatever PDF-reading software you prefer. In the comments, “MSCD” refers to the third edition of A Manual of Style for Contract Drafting.)

My comments address a full range of issues, many of them minor, some less so. The minor stuff is fair game, for two reasons. First, the IBM team built something new, so expediency didn’t come into it—nothing prevented them from using only the clearest language. And second, get enough minor stuff wrong in a contract and you waste the reader’s time and attention.

One general comment that isn’t reflected in my annotations: The IBM contract refers to IBM as “IBM” (mostly) and the customer as “you.” It also uses will (mostly) to express obligations, rather than shall. Those are legitimate choices, but they’re ones that I’d be reluctant to make. Dispensing with shall allows drafters to congratulate themselves on their modernity, but it comes at a price—it muddies the categories of contract language. (That’s something I describe in this article.) And sure enough, the categories of contract language are handled haphazardly in the IBM contract. (If you use shall, you pretty much have to refer to the parties using the third person.)

What conclusion do I suggest you draw from my markup? That contract language is specialized—it’s best left to specialists. Knowing your company’s transactions doesn’t make you a specialist. And many years of being steeped in traditional contract language doesn’t make you a specialist. You become a specialist only by making a concerted and disciplined attempt to familiarize yourself with the building blocks of contract language, the good and the not-so-good.

If you’re not a specialist, you’re a dilettante. Those responsible for IBM’s new cloud services contract are presumably knowledgeable, enthusiastic, and hard-working, but when it comes to contract language, the shortcomings in the new contract suggest that they’re dilettantes. That’s to be expected. In fact, the contracts ecosystem would work better if contract language were left in the hands of a limited number of “legal knowledge engineers” (to use Susskind’s clunky but apt phrase) working closely with those who have a broader understanding of the business and legal issues. [Updated December 21, 2014: Elaborating on a point he makes in this post on his blog, in an email to me Tim Cummins suggested that nothing mandates using “legal” in the phrase “legal knowledge engineer.” I agree: that’s something I discuss in this 2011 post.]

Some of you might be wondering why the heck I go through this sort of exercise. I do it because only through constant public scrutiny do we stand a chance of improving general standards for contract language. Anything that offers itself as an advance in contract drafting is an obvious candidate for this sort of scrutiny. And besides, I enjoy picking over contract language.

I’m not trying to pillory anyone. I sent the appropriate person at IBM two polite LinkedIn messages mentioning that I had reviewed their contract and asking whether they would be interested in chatting with me about my comments. I didn’t receive a reply, so the obvious next option was to post my analysis on this blog.

By the way, please consider my markup a think piece and a work in progress. I devoted a couple of hours to it, and if I were to look at it again in a few weeks, I’d doubtless make changes. And I didn’t think about broader deal issues.

[Updated December 23, 2014: You can find some discussion about this post in this discussion on the LinkedIn Contract & Commercial Management group.]

About the author

Ken Adams is the leading authority on how to say clearly whatever you want to say in a contract. He’s author of A Manual of Style for Contract Drafting, and he offers online and in-person training around the world. He’s also chief content officer of LegalSifter, Inc., a company that combines artificial intelligence and expertise to assist with review of contracts.