Learning how to review a contract is the same as learning how to draft a contract: you have to know what to say and how to say it clearly and concisely.
Of course, when you’re drafting, you’re in control, and you have a copy-and-paste starting point that you got from somewhere, so you can appear that you know what you’re doing. By contrast, when you review, someone else is in control, and you have to be prepared for whatever comes your way. But any illusion of control that comes from copy-and-pasting a first draft falls away once negotiations start. Whether you’re drafting or reviewing, you have to know your stuff.
Nevertheless, in my course Drafting Clearer Contracts: Masterclass, I’ve elected, for two reasons, to dedicate session 7 (out of 8) to reviewing contracts. First, I want participants to get a sense of how you have to adjust your expectations regarding clear contract language. You’re not trying to turn the other side’s draft into a thing of beauty, so you focus on that which can cause confusion, and you ignore everything else. Learning what that means in practice comes with experience.
And second, observing how someone reviews the other side’s draft gives you a good opportunity to learn that you shouldn’t fall into the novice’s trap of treating the draft you’re reviewing as a closed universe. What isn’t in the draft might be more important than what’s in it.
So for session 7, I’ve asked participants to read my ACC Docket article (with Michael Fleming) on reviewing contracts (here). I also ask them to look at my annotated PDF of the Salesforce master subscription agreement, with comments from the perspective of a potential Salesforce customer (here). For purposes of reviewing contracts, I’ve not seen an analysis like it.
And this week I added to the mix, just for Masterclass, a form confidentiality agreement from a vendor (of course it was terrible). After the session, I made available the version with my comments regarding deal points and drafting. I’ve noodled with confidentiality agreements over the years, so I was able to flag a fair number of deal issues, including some of those discussed in these blog posts.
Ultimately, as with everything in Masterclass, it’s not my job to force-feed knowledge to participants. Instead, I do my best to act as a facilitator and curator, leaving them to do the work. The idea is that in session 7, we talk about some of the issues I identified in the Salesforce contract and the confidentiality agreement. To encourage participants to speak more, I contemplate for the next session 7 asking everyone to note before session 7 five things about the confidentiality agreement that they think are problematic or that they have questions about.
Session 7 just aims to get people thinking along the right lines. Where do you go from there? Well, the how-to-say-it part is straightforward: stick with MSCD and tune out everything else. By contrast, the what-to-say part requires that you piece together deal knowledge, magpie like, from wherever you find it. That’s inefficient and annoying, and you have to be wary of people recycling dysfunctional conventional wisdom. Maybe someday we’ll do it better.
For more about Drafting Clearer Contracts: Masterclass, go here. The next series starts on Wednesday, 3 August 2022.
I’m obliged to use AIA form contracts. I struggle to review and revise them. No section paragraph headings. Replete with non-contractual language, ambiguity, internal conflict, repetition, vague terms, inconsistent use of defined terms or no defined terms, use of internal section references instead of defined terms. . . akin to a repository of Adams’ style manual violations. And yet, astonishingly, they’re largely considered de riguere in design/construction. Any suggestions for how to approach a review like this? Can you please help them?
Hi Brian. I recently had occasion to read an AIA contract. I might write something about it.
I would very much like the A/E/C industry to apply MSCD to their standard documents – and most companies adopt the AIA (EJDCD, others) language and provisions in their custom and manuscript contracts. A lot of The AIA family of documents have a long history – the AIA publishes a Case Citator going back to 1888. This aids in the “predictability” in the interpretation of provisions and terms contained in the documents (good). But mutual understanding and intent (contracts 101) by the parties and those administering through better drafting should be primary goal. The AIA (and all the construction industry family of documents – EJCDC, DBIA, ConsensusDocs) are the product of committee (and process of compromise) of legal representatives from all facets of the A/E/C industry. In modern times, these documents are usually revisited and updated on approximately 10 year cycle, to reflect changes in society, technology, insurance, industry practice, and applicable law. The common law and statutory construct of A/E/C law is similar but varies in some significant ways state to state. A “contract” that tries to be all things for all parties, and projects (size, technology) for all jurisdictions is usually not great for any single project. Getting a copy of the MSCD into the hands of each committee member would be first step. Note that many of these committee members do NOT utilize these standard documents, but instead draft manuscript contracts for their own use and clients. These non-industry-standard contracts, prepared by attorneys for each participant, have become more poorly and poorly drafted over last 10 years. Owners bring their custom contracts to the prime contractors (or design professionals), prime contractors bring their custom contracts to their subcontractors (or subconsultants). Subcontractors bring their custom Purchase Order forms to their suppliers. Flowing down applicable terms through supply chain is a nightmare. Depending on where you look, the A/E/C industry contributes to approximately 1/3 of the US GDP, and their is a lot of litigation, much about interpreting the contract(s) – some of which are the AIA documents (AIA Citator). Greater adoption of MSCD guidance would greatly benefit the industry.
Here’s some flavor. Just one sentence I pulled from an AIA contract :
It is recognized, however, that neither the Architect nor the Owner has control over the cost of labor, materials or equipment; the Contractor’s methods of determining bid prices; or competitive bidding, market or negotiating conditions.
I went through the PDF commentary of the Salesforce.com agreement ready to learn. As an attorney focused on technology agreements (both on the vendor and customer side) the commentary was disappointing.
For instance:
Item 7, “Content” where the definition says Content is provided “as more fully described in the Documentation” the commentary states “This sort of reference is unorthodox. Let the documents speak for themselves.” References to Documentation in technology agreements is not unorthodox (assuming that’s what the commentary is saying, it’s not clear to me). Technology is complex and changes frequently. Because of that many, many issues are covered by references to the Documentation to allow for flexibility as technology changes or because of technology limitations that need to bind the customer but that aren’t appropriate to put in the main agreement. For instance, version X.8 won’t be or work like version X.7 and the Documentation, which is usually as complex and dynamic as the technology, reflects that.
Instead, if the commentary is claiming that the order form should have all the necessary information about the Services, that is also disappointing. There is a link to the Documentation just a bit below the “Content” definition. Go ahead and open it. Look at the Documentation. Is it sensible to include all the Documentation so that the order “speaks for itself”? (The answer is No).
Item 21, the “SFDC Personnel” definition is covered with the comment “What does this cover? And how might SFDC not be liable for conduct by its representatives?” Perhaps I misunderstood the commentary, but it seems critical of the language where SFDC agrees to be responsible for its employees and contractors. If so, that is, in my opinion, a bad take. Customers buying technology / technology services often insist on language very similar to this. If you are SFDC, why not cut them off at the pass so that you get language that you are willing to accept without all the extra baggage procurement would add?
There are several other comments that can be answered in the same way: Procurement bloats up documents because they are looking for particular language or issues to be addressed and do so in a way that is not acceptable to the vendor. If a vendor checks off particular boxes ahead of time, they can often avoid procurement bloat and unacceptable terms. So is it necessary? Only if the vendor wants to get deals done.
Item 7, Section 3.4, “internal business purposes” is covered with the comment “It’s not clear what this means.” Frankly, to a certain degree, that’s the point. If a vendor tries to describe use rights with more clarity, customer’s (rightly) looks for ways the clear definition won’t work for them and painful fights over phrasing ensue. This usually turns into a briar patch where nothing that the vendor offers is good enough for the customer, but the customer’s language gobbles up rights the vendor has no intent to grant for commercial reasons or legal reasons or both. The wording here, “internal business purposes”, is language that both vendor and procurement teams seem to have settled on as close enough and is, in my experience, found frequently in technology agreements. Both sides look at it and generally feel comfortable that it has the rights (for the customer) and the limitations (for the vendor) each side feels like they need. Is the phrase beautiful and clear? No. Does it significantly resolve 95% of the practical issues around use? Yes.
Unfortunately, the commentary seems to be chock full of items like the above (I gave up on this after a certain amount of frustration). I’d recommend you get someone who is focused on the sales side of technology agreements to add their view if you want this to be a truly useful document.
Exciting post, Ken! Contract review is a vital management technique for ensuring that your contracts accurately represent your understanding and agreement with the parties’ purpose and expectations. To efficiently examine a contract, three actions must be taken. Step 1: Determine what you anticipate and want from the contract. Step 2: Go over the action portions of the contract to ensure that the transaction conditions are appropriately documented. Step 3: Go through the remainder of the contract (everything) to ensure everything else is in line with your expectations.
I got an e-mail from someone asking “how much would you charge to overlook a contract?” I refrained from the wise-guy response