Response to 50 Tips

James Martin, an attorney in St. Petersburg, Florida has an article on his website regarding 50 tips for writing contracts that stay out of court.  Most of the suggestions are good… a few are a little dated.  This is my response to the dated things on his list:

3.  Ask your client for a similar contract. Huh?  If your client has a similar contract, they probably don’t really need you.  Now, I’m not advocating reinvention of the wheel.  If there’s a pre-existing solution to the problem, by all means, use it.  But I’m guessing that someone’s coming to you to draft the agreement because you have the skills.  More importantly, however, is that their template/sample probably contains a LOT of issues.  So it’s usually 110% easier to start from scratch (or from your form) and customize it to your client’s specific needs.

4.  Check the form books and treatises for a contract form. and  5.  Buy forms on disk or CD-ROM. I don’t know who first created form books, but they’re not as good as one might think… and they’re not necessarily battle tested, either.  You’d be better off getting a template from someone else you know if you don’t know where to start.  There are exceptions, of course, but still – be careful (see the second part of my advice for #3 above).

6.  Don’t let your client sign a letter of intent without this wording. Actually, my advice is to NEVER sign a letter of intent, regardless of the wording.  As I’ve said before, a Letter of Intent is usually just a poorly written contract.  Don’t get caught up in that mess.

9.  Identify the parties by nicknames. This isn’t a hard-and-fast rule.  Use nicknames only if it actually makes things easier to draft AND read.  Be careful about using descriptive terms as nicknames (customer, vendor, consultant, etc) because other forms of that word could appear in the agreement.  Use the “Find” feature of your word processor to discover if this is true.

12.  Include recitals to provide background. I know a lot of people love these.  But I hate them.  I hate reading them and I hate writing them.  On the other hand, for complex deals where the agreement could apply to many different things and you want to be clear on what the contract is really covering, this is the place.  But for a standard software agreement, the place to list the products is in a product schedule… that way you can use the same license and only add additional product schedules w/o having to amend the agreement itself to modify some “Now therefore, the parties agree to license Word Processing application.” type of language.

17.  Title it “Contract.” Actually, the better advice is to simply make sure that it doesn’t say “proposal” or some other transient contract type (like “letter”).  Granted, I like document titles “Software Licensing Agreement” or “Amendment to Master Services Agreement”.  But putting “Contract” in bold at the top of the first page is silly and WAY outdated.

24.  Write number as both words and numerals: ten (10). I agree with Ken Adams on this one.  Use the standard rules for numbers: words for zero through ten and numerals for 11 on up.

25.  When you write “including” consider adding “but not limited to.” Not worth adding.  Ever.

26.  Don’t rely on rules of grammar. WHAT!?!?! OK.  Look.  Use plain English wherever possible.  Write clearly.  Using superior grammatical skills.  If you don’t have such skills, don’t draft contracts.

29.  Be consistent in grammar and punctuation. Well, at least Mr. Martin shows consistency in his inconsistency regarding grammar.

30.  Consider including choice of law, venue selection, and attorneys fee clauses. Consider?  Absolutely include choice of law and attorney’s fee clauses (though in some cases attorney’s fees won’t ever be granted… but it doesn’t hurt to ask).  On the other hand, you’ll almost NEVER get venue if the other side understands it well enough to ask for a different location.  But if you’re both in the same location, it never hurts to add it in to make sure you won’t be dragged out of state.

32.  Define a word by capitalizing it and putting it in quotes. and 33.  Define words when first used. No and No.  Define words in a definitions section up front.  Unless you only have an average of one defined term per section.  Then you can define “in line”.  Otherwise it just gets too ornery to try to make sure you define the term the FIRST time you use it.  This is especially true when definitions end up getting used in the definition of other defined terms.

34.  Explain technical terms and concepts. If you’re using terms that laypeople can understand, the only technical terms that should appear should be in a statement of work or other descriptive document regarding the work.  As such, it should be written so as to be understandable by the people that have to abide by the contract.  Judges and lawyers can find technical people to explain technical terms.  The only time you should explain technical terms is if there’s a reasonable disagreement in the technically-educated community as to the usage of the term.

35.  All contracts should come with a cover letter. Not necessary.  If your contract is so difficult as to not be able to understand how to sign it, you’ve got a problem.  The best thing I’ve seen so far?  “Sign Here” tape flags that you put on the side of the document they’re supposed to sign for each signature line.  Then paperclip your business card to the front with a post-it note attached thanking them for their help and asking them to sign and return one of the two originals.

38.  Use your word processor’s spelling and grammar checker. Yes, but don’t rely on it.  Two, to, too, toe.  Their, there, they’re.  Through, thorough.  Notice anything?  They are all real words and spelled correctly.  Spell checker isn’t going to flag any of these.  Grammar checker is no better: “A parakeet is not a bluebird.” is grammatically correct.  But if you intended to say that a parakeet isn’t blue, the prior sentence is not correct but won’t be flagged.

42.  Save the drafts as multiple files on your computer. Yes, but not how it was recommended.  Unfortunately, using periods in your filename is still problematic for some operating systems.  Weird abbreviations for drafts, comparisons, etc are also hard to decipher.  Instead, try this:  “filename vX date initials.doc”.  So if you have a file called MasterService and it’s the 4th iteration being saved on September 29, 2009 by Jeffrey I. Gordon, the filename would be:  “MasterService v4 092909jig.doc”  Why do I do it this way?  Well: a) it keeps the files in draft order in virtually all file systems (Windows, Mac, Linux); b) it notes which version it is (saves on confusion about which document is the latest); c) notes the date it was created; d) notes who created the draft.  Sometimes I’ll substitute my company’s TLA instead of my name… but usually, I like my initials better to let me know that I was the author of that version of the document.  When I get the last version that becomes the final, I change my initials to FINAL – so the name would now be: “MasterService v10 101509FINAL.doc”.  This lets me know that v10 was the final and which version was signed.

44.  Print the contract on 24 pound bond paper instead of 20 pound copier paper. Not worth the cost of paper.  Especially if you want the other side to sign first – ask them to print two originals, sign both and send to you… you can’t control the paper it’s printed on.  Besides, if you’re using a contract management system, you’re going to scan and forever more look only at the digital version, so the paper is irrelevant and not worth the added expense.

47.  Initial every page of the contract. Wholly unnecessary unless you don’t trust the other side and you’re signing first.  But as I’ve said before, if you don’t trust the other side, you shouldn’t be doing the deal in the first place.

48.  Identify the parties and witnesses who sign by providing blank lines below their signature lines for their printed names and addresses. and 50.  Add a notary clause that complies with the notary law. Witnesses and notaries aren’t necessary unless required by law for the specific type of contract you’re closing (usually for real property, but I’m not sure it’s required for any other type… anyone know for sure?).  Many businesses have a notary on staff, but unless the document is required to be signed “under seal”, this also is usually not a requirement and is an added expense to some (and added time/effort for everyone).

On Acceptance Testing…

My car needed an oil change today.  It’s been about 5 months, 6,000 miles and while I know I can push it that far, it was finally time for me to get it done.  I thought about doing it myself and decided that Jiffy Lube would more efficiently meet my needs.  But I always feel a little weird about oil change places – they show a long list of things that they supposedly check… but unless I stand out there hovering in the bay, I don’t feel confident that they’ve actually completed the work.

Today I didn’t hover, I was reading e-mails.  When they called my name to pay, they quickly read off the list of things they checked and reviewing the computer screen, I asked the guy behind the counter: “Did you check the engine coolant level?”  With a slight hesitation, he replied “Yes.”

I paid, took my keys and walked out to my car.  Deciding to check the coolant level, I popped the hood and looked.  Sure enough, the fluid was below the line marked “Fill”.  I walked back inside and told the same employee that I thought that the fluid wasn’t checked and could he come confirm.  He looked a little shocked, walked out to the car and confirmed that the fluid was low.  He apologized and made some sort of excuse about the shop being busy and that my question during check-out didn’t raise any red flags – that he figured I’d asked them to check it and that his employees did (apparently, he was the manager).  I said it was no big deal, but that I would like it topped off.

[OK.  If you haven’t already figured it out, this story parallels many services-type engagements from the IT world.  You pick a provider when you realize you don’t want to do it yourself, you “order” a set of services… and at the end, you are presented with a completion check-list and asked to pay.  What services providers don’t want prior to payment is anything conceptually equivalent to an Acceptance Test.  They want payment first and then resolution of any “defects” under their services warranty provisions (if any).  This way, they have control of the money and can book the revenue as earned.

But don’t let their desire to avoid Acceptance Testing sway you… and don’t fall into the trap I did today and pay first.  What happened next was predictable and I should have seen it coming.]

The manager then said, “well, we normally charge for topping off the coolant.”

Oh.  Alright, I thought, whatever… just get my car finished and get me on my way. “How much does that cost?”, I asked.

“Five dollars.”

Thank god my negotiation-sense kicked back in … and I just stood there silent for a few beats too many.

“But because of the confusion, I’ll take care of it.”, he continued.

I smiled and said “Thank you.”

While he was retrieving the coolant I scanned the engine compartment and realized that the large rubber gasket between the hood and the firewall had completely come off and was just laying across the engine!  Holy cow.  I was really glad I popped the hood today – this piece of rubber, which probably came off during the oil change and was simply overlooked due to its matching blackness to everything else under the hood, could have gotten wound into various belts, heated and set afire or fallen down to the road and lost.  It was a no-brainer fix to simply push it back onto the car’s frame – but catching it was the biggie.

The same is true for many acceptance testing issues – the no-brainer is to look for them at the right time (preferably before payment).  Don’t get suckered into someone else’s process (they moved my Jeep out of the repair bay and into the parking lot (keys in it and running) as “customer service” perk.  But it’s meant also to get you off the lot before you notice anything wrong (where they can attempt to reasonably say that the problem happened outside their control).

One again, learn from my mistakes.  🙂

Jeff Gordon on Supply Excellence

Justin Fogarty from Supply Excellence e-mailed last week and asked me (and some others as well) about what we thought would be the biggest supply chain risks in a recovery.  He was kind enough to think that my response on “Instant Amnesia” warranted a guest post on Supply Excellence.  Thanks to Justin for the opportunity!

The Value of Testimonials

If you’ve not seen the latest CarFax commercials, they’re pretty funny.  Essentially, the buyer wants to see the CarFax report and the seller doesn’t want to give it to them.  Here’s my favorite:

Yet, as enterprise software buyers asking for references, this is essentially what we’re accepting from the vendor – a note from the prior owner.

Several years ago, I started to put together a list of folks I’d rather talk with and I’d love to hear your suggestions as well.  These include:

• customers who never finished implementation (for any reason)
• customers who discontinued maintenance in the last 12-24 months (I want to know the number as a percentage of total customers and I want names/contact details)
• customers who are similar in size of implementation to me, but who had exceeded planned implementation time

As a customer myself, I would never hesitate to serve as a reference under these circumstances.  Would you?

Why RFP’s Suck for Both Sides

RFPs suck for both sides of the equation. Bidders hate responding to them and the requesting organization hates reviewing them.

Why?

Well, because they’re time consuming… and each side believes that the other side is: 1) Only spending enough time to barely glean the financials off the top; 2) Inserting default language from prior RFPs which may or may not have relevance to the current project; and 3) Only doing this to appease some misguided sense of a “strategic sourcing process”.  These assumptions are all 100% true:

1. Using RFPs correctly can be a valuable part of a strategic sourcing process.  But generally speaking, they’re hastily assembled, from a template, and sent out without consideration as to who will get them.
2. Responses almost always arrive at the last possible moment – not because they’re the product of countless hours of taxing effort and meticulous drafting – but because they’re tossed in a drawer and forgotten until the last possible moment.
3. Reviews ARE hastily done… with receiving “teams” designated to score RFPs by section but having no real training as to how to do it properly (usually because they didn’t spend enough time working on a requirements document for the project to begin with).

How do I know this?  Well, it’s easy, really.  After a decade of using them, I long ago learned to monitor the Word document’s properties for the RFP itself.  It’s where I’ve asked responses to come electronically, so I can see EXACTLY how much time has been spent editing the document.  Do I really think that it only takes an hour of editing to respond to one?  Ha.  Only if it’s a copy-paste job.

But I’d wondered what bidders were doing to monitor our review.  Now I know.  And I think it’s an excellent smack-down.  Reviewers SHOULD be held accountable for the efforts they ask others to expend on their behalf.  As time-consuming processes go, you should at least be willing to put in the effort to review something that you’ve asked someone else to create.  Oh, and by all means should you have LIMITED the number of potential respondents long before sending out the document package.

By the way, all of the food, drink and alcohol provided by these various agencies sure smacks of impropriety to me.  NEVER send a reviewing organization ANYTHING until after the deal has been signed… and then you’d better comply with that organization’s gift policy or you should expect to get it back.

 

What You See is NOT Always What You Get

Several months ago, I posted the backwards paragraph to demonstrate the immense power of the brain to fill in gaps or to make sense out of the nonsensical.  Understanding this brain functionality is important when you’re trying to communicate with others because of this difference between reality and perception.

But it’s not just words (the parietal lobe) but also the occipital lobe (colors and shapes) that can create this distortion.

So, what does all of this really have to do with contracts?  Well, besides communicating with others, the problem I’ve seen in the recent past has been an increase in the number of missing words in contract templates.  Now, I’m not talking about significant words – “liability” isn’t absent, for example.  It’s an article of speech – an “an”, “a”, “the”, etc – that’s forgotten… or a word improperly capitalized.  And your brain simply fills in the gap(s).

Of course, it might not be a big deal.  But can you see that there is a difference between “the Services” (with a defined term), a service, or a Service?  The Services could mean a group of behaviors, “a service” could simply be a single service component of the Services… or it could be a service separate and apart from any of the services.  Which means that “a Service” could be one of several behaviors, but not all of them.  The key here is learning to read in a different mode.  Similar to the difference in reading a contract compared to reading a fiction novel, copy editing is a completely different style designed to produce a different result.  Mastery of these different styles will help you become a better contract drafter and reviewer.

Delivering Perfection

In thousands of meetings over the years, I’ve been privvy to a very common conversation.  It’s a discussion of deliverables – what is needed, what is wanted, how much money is available to pay for the needs/wants, who can create the best solution, etcetera.  Regardless of the actual nature of the deliverable, the basics are always the same:  We want what we want, when we want it, at the least total cost.  The end result, however, varies widely on a huge number of factors.  One of them is the quality of the “spec” – the document describing what’s being created; and another is the quality of the group performing the work.

The deliverable is never perfect.  At some point in the process, either the vendor makes errors or the buyer doesn’t adequately describe what they want (or consider all of the various contingencies).  The net result is payment for something that doesn’t do what you hoped it would do – or going over budget for the fix.  So how do you deliver perfection?

Well, the folks who write the software that runs NASA’s Space Shuttle have it about right.  It’s a four-part process that keeps their code running virtually bug free for the last 20 years, and like the Five Fundamental Skills for Effective Negotiation, it’s not (pardon the pun) rocket science:

1. The product is only as good as the plan for the product.
2. The best teamwork is a healthy rivalry.
3. The database is the software base.
4. Don’t just fix mistakes – fix whatever permitted the mistake in the first place.

This is a fascinating story about a group of 260 people working normal hours and achieving extraordinary results (the last 11 versions of the software have only had a total of 17 errors).  Equaly important from a stats perspective are the specs.  For the current application (420,000 lines of code – for comparison’s sake: WindowsXP has 40,000,000 and MacOSX has 86,000,000), the current spec is 40,000 pages long.

Now, granted, many of the projects your teams are working on aren’t operating systems.  But how many of you have seen a spec document that’s even more than 100 pages?  How about 50?  Very few.  In fact, I am used to seeing spec documents of less than 5 pages – 10 at most.  It’s no wonder that there are errors.

I also don’t believe that many of us will be effective in getting our development teams to change, either.  But if they only got a little better, the cost savings would be immense.  So share the article with them from a human interest perspective (ie: don’t push an agenda).  The worst that happens is you start a dialog.

WhichDraft.com Document Assembly Tool

I’ve recently been focused on the wealth of new contract management tools that have been released since January 2009.  We started with a tool to help you manage the finished product, then a tool to help you redline your documents.  The missing product for this trinity is one for document assembly.  WhichDraft makes a huge step to closing this gaping hole.

The WhichDraft tool is based on the concept that templates, while useful as a starting point, need to be modified based on a situational analysis of the deal.  They have created several forms (almost 80 of them!) to start from, and then use the wizard concept to guide the end-user through the customization of the form for the particular deal at issue.  If they don’t have the form you need or want, you can even create a free account and develop your own forms and wizard-ize them, too.  If you’re familiar with the old DealManager tool from CMSI and/or Procuri, WhichDraft will be 100% intuitive – but this isn’t your parent’s DealManager too, either.

The simple elegance (combined with its $0.00 cost) of this solution makes it an obviously useful tool to add to your contract management aresenal, especially for those folks who don’t have easy access to someone skilled in contract drafting.  I also see great potential for a contract or legal department’s creation of their own repository of custom templates with options built-in for the various legal-language swap-outs that are already legal-department approved.

Of course there are some weaknesses – the most important (and one common to any document assembly tool) being that templates used with this system have to be written in a way that makes language-swap possible.  The limitation of the current WhichDraft wizard process appears to be that a single question is tied only to a single paragraph/section of the contract.  So if you want to pull out ALL of the services-related language in the deal, you’d actually have to create a services-less template because a single question in the wizard couldn’t remove all of the associated language throughout the contract.  This isn’t a tool-killer, as some people love having clean templates in a variety of formats – and WhichDraft’s templates are already built in this manner.  But this could limit people intending to upload their own templates into the tool.

I also advise caution in using WhichDraft’s template language as a default starting point for any deal.  They’ve structured dozens of basic templates, but again, your contracts or legal department might have drastically different language interpretations, desires or phrasing.  So if you already have template documents, make sure that you log-in to the system to create your own WhichDraft templates.  Additionally, in talking with WhichDraft’s co-founder, Jason Mark Anderman, he fully supports WhichDraft’s use as a productivity enhancer, not as lawyer-replacement, recognizing the inherent risk of using any template as a one-size-fits-all solution (even with wizard capabilities).

Overall, WhichDraft makes a great leap forward in terms of usability, availability and flexibility.  I expect future versions of this tool will simply add onto its existing strengths and gradually wear down its weaknesses, too.  Thanks to WhichDraft for providing the contracting community with such a wonderful tool!

 

On the Fastrack, June 19, 2009

I’ve mentioned before that there are a lot of great comics out today that, every once and awhile, touch on contracts and/or negotiation topics. On the Fastrack is another:

(Click on it to see it full-sized.)

How to… redline

When you’re about to enter a contract negotiation, and assuming you’ve not been successful in using your templates, the first step is to review and redline the agreement.  This How-To is intended to teach you the obvious (and not-so-obvious) skills of redlining.

1. Ordinarily, I suggest a quick once-over.  This is a perusal designed to see if the major sections of the contract are present.  Using a checklist like the Software License Risk Matrix will help you verify that all of the headlines are covered.  Not all contracts will contain the same sections, of course, and just because a contract has a stated Header doesn’t mean that the language in that section actually matches the Header’s description.
2. For any “missing” sections of the agreement that you would like to insert, create new sections in an appropriate place (as you read an agreement, you typically have a feel for where certain sections will need to go.  You’ll also have to make adjustments based on numbering schemes or sub-numbering schemes to match the original – so watch the blind copy-pasting.
3. Now, hopefully you’ve got the contract in Microsoft Word (or other word processing format) to facilitate an easy redline.  Enable Word’s “Track Changes” feature via the Tools menu.  Advanced users will also note that you can quickly turn Track Changes on and off via the green-light at the bottom of that document’s window next to the “TRK”.  If the other side has sent you a document via PDF and refuses or is otherwise unable to send you a Word version, use the free service at www.pdftoword.com run by the great folks at NitroPDF.  This service will convert your PDF almost flawlessly and e-mail you a converted Word file.
4. Read each section carefully.  Start with the definitions and make sure that all defined terms have a definition (many times this isn’t the case).  Now march your way through the agreement.
5. Where you do not like particular language, the Track Changes feature allows you to “delete” the language – but instead of actually removing the offending words, it changes the color and puts a strike-out line through the deleted language.
6. On the flip-side, when you insert language, Track Changes will insert your new words in the same color as the deleted text, only this time is underlined.
7. Where possible, suggest new language that you’d prefer to be in the agreement rather than just strike-out the language you find troublesome.  This will provide a great basis for a negotiation.  If you simply delete language, I would assume that you simply want the language removed and nothing else added.  When this is the case, I will sometimes make a note to tell the other negotiator why I made a particular change:  “[JeffNote:  I don’t believe I should have to indemnify you for this.]”  This call-out makes it easier on the other reader to accept or reject your change, as your explanation might be all that’s needed for them to accept your modification.
8. Then, when you’re the recipient of a redlined document, your first task is to review the changes to see if any of them are acceptable without discussion.  If so, simply right-click on the change and select “Accept Deletion” or “Accept Insertion” from the pop-up menu.  HOWEVER, DO NOT SIMPLY REJECT CHANGES!  This would create a presumption on your part that you shouldn’t make without talking to the other side first.  Rather, leave unacceptable changes in redline format as open for discussion.
9. As the second reviewer (and the presumptive owner of the original), you might feel some initial pain at making any changes at all to your template.  Remember, however, that you’d do the same thing to someone else’s template.  Additionally, while I’m sure you wrote your template with every conceivable situation in mind, there might be a situation you didn’t conceive.  In other words, give the redline a chance.  Read it with the intent to accept as many changes as you possibly can.  This is a negotiation, afterall.
10. If you need to suggest language back to the first reviewer, Track Changes anticipates this and will (unless you make changes to the Preferences settings) automatically assign each individual reviewer a different color.  If you place your pointer over a particular change, Word will tell you the name (as set in Word’s preferences) of the editor for that change and the date/time of the change.  If your name doesn’t appear on changes, make sure that you’ve entered your name in the preferences settings and you’ve also unchecked the box that has Word remove the name of the reviewer as part of its security process.
11. So now you have a document that should have fewer redlines than when the first person was done, might have some additional redlines from the document’s original author and the document is now ready for negotiation.
12. Set aside plenty of time for negotiation – rushing is to neither party’s benefit.  You do not have to make it through the entire contract in a single session.
13. Once pleasantries are out of the way, discuss who will be the document owner (I typically volunteer… it keeps me alert and I feel much better about how the changes are completed).
14. During the negotiation, systematically review the agreement from the top on down.  Continue to make any new additions or deletions in redline.  But accept/reject prior changes as agreed during the negotiation.  Thus, when done, you’ve got a document that ONLY has points of contention or new language changes still in redline.  In rare cases, in a trusting relationship, you might agree to make “blackline” changes.  If so, never breach that trust.
15. OK, so after a few back and forth discussions, you should have resolved all open issues.  Take one more quick review to look for any open issues.  Use Track Changes to see if there are any unseen remaining edits (use the “Next Change” button to see if there are any you missed).
16. What you’re left with is a blackline document – everything’s in black and white.  GREAT JOB!
17. If you’ve got to do a redline by hand, here are a few additional suggestions:  a) Don’t.  Seriously.  Scan and use PDFtoWord.  b) But if you have to, learn to write very small in the margins with tiny arrows indicating where new language would go.  c) Actually strike through (with a single line) each word you don’t like.  d) Don’t waste time handwriting in entire new sections.  Just note what new ones are necessary – add new language electronically later.  e) If you must, create a separate document and create an amendment document where you describe each deletion and/or insertion.  Again, this method is HIGHLY outdated, but some organizations just can’t seem to get away from it.

Once you’re done, I sometimes also recommend using a tool called DeltaView (or even Word’s own Document Compare feature) to compare the original against the finished product.  This helps you check all of the redlines that were actually agreed upon and gives you a level of comfort that neither party tried to sneak in a change the other party didn’t accept.  However, unless I have reason to believe that the other party isn’t trustworthy, I typically have been diligent enough through each turn of the document to not require this final step.

All that’s left now is execution and managing post-contract obligations.  But that’s another day.