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).

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.  Follow me on Twitter if you want up-to-the-minute information on contracting, licensing, negotiation and the law.

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. 

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.  Follow me on Twitter if you want up-to-the-minute information on contracting, licensing, negotiation and the law.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.  Follow me on Twitter if you want up-to-the-minute information on contracting, licensing, negotiation and the law.

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?

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.  Follow me on Twitter if you want up-to-the-minute information on contracting, licensing, negotiation and the law.

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.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.  Follow me on Twitter if you want up-to-the-minute information on contracting, licensing, negotiation and the law.

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.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

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.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

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!

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

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

The current economic situation is encouraging many organizations to reconsider their current contractual relationships. Contact me before your opponent does to find out how to make the most of your renegotiations. The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

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.

The current economic situation is encouraging many organizations to reconsider their current contractual relationships.  Contact me before your opponent does to find out how to make the most of your renegotiations.  The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

So what then of larger contracts of the evergreen sort?  The software maintenance renewals?  The never-ending services subscriptions?  The truth is that subscriptions are a benefit to both buyers and sellers – the trick is knowing what you’ve agreed to and how to get out cleanly when you are no longer interested.  Thus, as with almost every other contract term we discuss, renewal clauses are important post-contract terms to watch.

There are 4 parts to your basic renewal term:  mechanism of renewal (auto vs notice), length of renewal, cost of renewal and termination notice period.  Unfortunately, most contracts don’t put all of these things into one section and they try to use brevity in hopes that renewals will just “happen”.  Rather, make sure that each of these four areas is not only agreeable, but actually what you intend.

Mechanism – as we were just talking about evergreen clauses, the mechanism of renewal is the distinction between an automatic renewal (it’s continually green, like a pine tree) and one which requires some form of affirmation to renew.  As I mentioned in the term and termination discussion we had a week or so ago, the issue isn’t whether you allow it to auto-renew or not, the issue is whether you can TRACK it’s auto-renewing nature.  If a customer doesn’t have the ability to track these things, it’s better to have the contract terminate – the vendor will ALWAYS come knocking to get you to renew.

Length (term) – If you allow for an auto-renewal, I always suggest a relatively short term (about 1 year).  This is a reasonable time frame in which business decisions can be made, plans can change, etcetera.  Anything longer and you might find yourself stuck with a contract you don’t want – anything less and you’ll spend more time worrying about the renewals than in getting real work completed.

Cost – Agreeing to auto-renewing contracts should come with a price-break.  You should either have a continuation of the prior-years’ fees, or a SLIGHT increase based on the average increase in the cost of doing business.  In other words, the customer benefits from agreeing to the risk of auto-renewal.  On the other hand, customers should be prepared to negotiate cost increases if the contract no longer auto-renews.  (Actually, the customer used to always get a cost-increase-limiter on renewals… now this distinction seems to be taking root.  Pay attention.)  Oh, and if there’s NO renewal at all, the customer should not be surprised to see potentially large jumps in cost if they try to restart the services after some lapse/gap in service.

Termination period – Last, but not least, even with an auto-renewing agreement, there should be some amout of notice by which a party can terminate an evergreen contract.  As stated before, it’s usually some increment of 30 days – with longer periods of notice required for longer initial terms or larger-dollar deals.  As a buyer, I typically do not want my vendor to be able to terminate – even outside the notice period – because I want them to keep providing me service so long as I want it.  This is probably one of very few areas where I have felt justified in asking for such lop-sided terms.  Because what I don’t want is a situation where I’m willing to continue paying for service, but the vendor decides that they simply don’t like me anymore.  The only time I want a vendor to be able to terminate is if I don’t live up to my contractual obligations (such as paying ontime).

Oh, and as Frank unfortunately discovered, make sure there aren’t any other potential gotcha’s buried in the deal which would make termination difficult.

The current economic situation is encouraging many organizations to reconsider their current contractual relationships.  Contact me before your opponent does to find out how to make the most of your renegotiations.  The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

In almost all cases, notice must be provided in writing.  This is important as it creates a permanent record.  It’s quite hard to track down a conversation, obviously, but a letter or an e-mail can easily be later referenced to show that notice was actually given on time.  But what about the means of transmitting the writing.  I just said it could come via letter or e-mail – that should seem self-explanatory.  But the truth is that there are still arguments over the method by which it’s sent.  US Postal Service, UPS, FedEx, e-mail, fax … these are all methods you can currently use.  If both parties have access to the method, then it would at least seem reasonable that such a method could be used.  In 2009, it’s no longer a real excuse to say that you don’t “check your e-mail” on a regular basis.

But what’s the main difference between these transmission modes?  Yup, time.  On average, a letter sent via the USPS is going to take 2-5 days to reach its destination when sent and received in the continental US – longer if international.  UPS and FedEx now offer ground service of the same length of time (so it’s a little cheaper to use), but in the “old days”, the bonus for using couriers was that you had second-day or next-day delivery.  And, of course, fax and e-mail are virtually instantaneous.  This is why you still see notice language in contracts that talks about the “effective date” or “deemed delivery date” of the notice – that you can reasonably expect that one party will have received the notice in a given amount of time given a specific transmission mode.

Why is this important?  Well, that gets us to the second part of notice – the notice date.  Again, the obvious purpose of notice is to provide the other party advanced warning that a party intends to take some form of action.  If you’re a vendor and you want to terminate a contract, for example, the customer might need to find a new service provider.  Giving them the advanced notice means that they might have enough time to find a new provider so as to effect a smooth transition without service interruption.  If you send notice close to the notice date, it’s conceivable, depending on the transmission mode, that an entire week could be lost during transmission.  So where most contracts will talk about the “deemed delivery date” of the notice, it’s important to also watch the effective date.

More specifically, pay attention to notice dates as it relates to headaches that may be caused by receipt of notice.  The bigger the potential headache (or more work involved to deal with the effect of notice), the longer the notice period should be.  For most contracts, notice for termination is going to be about 30 days.  Notice for an intent to audit is going to be 5-10 business days.  But for multi-year, large service contracts, it’s not unreasonable to have notice requirements 6-12 months in advance of termination.

If and when you receive notice from the other side, please remember to actually take action and tell the various internal stakeholders that notice was received.  If you’re the contracts person for your organization, make sure that you’ve provided a quick instruction sheet to your business owners on what to do with contracts-related communications (ie: give a copy immediately to you).  Granted, if you have a contract management system you’ll already know these event dates are coming up and you’ll be talking with your business owners in advance… but if you don’t, and a notice letter arrives, you may need to encourage action on their part.

Lastly, remember that notice periods are contractual requirements and that missing a notice opportunity can have dire consequences.  Invariably, long notice periods are missed on multi-year, seven-figure renewals.  This is another reason to always think twice about long-term renewal periods on agreements… and the effect than an evergreen clause can have on your organization.  My personal recommendation is to never have agreements more than 3-5 years in initial length, with renewal periods of more than 1 or 2 years.  I still like the long notice periods and I use a contract management system that gives me advanced notice of notice.  So if I have a 12/31 termination date, with a six month notice period (6/30), then my contract management system can give me an e-mail reminder any amount of time I want prior to 6/30 (usually 45-60 days).  That way, I have plenty of time to talk with my business owner about renewal or termination.

What’s in your contract?

The current economic situation is encouraging many organizations to reconsider their current contractual relationships.  Contact me before your opponent does to find out how to make the most of your renegotiations.  The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

The 500 Track videos include:
SLES 501 – RFx Planning and Creation
SLES 502 – RFx Release and Response
SLES 503 – RFx Evaluation and Bidder Selection

For a limited time, each track is offered for $150.  That’s an entire software licensing conference – a 9.5 hours of training, for less than 1/3rd the cost of comparable options!  Act now to receive this very special pricing offer.

Videos are formatted for a computer or portable video player (such as an iPod) and consist of a slide-show format with voice-over instruction, so you can even learn just by listening!

The current economic situation is encouraging many organizations to reconsider their current contractual relationships.  Contact me before your opponent does to find out how to make the most of your renegotiations.  The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

The long and short of it is that you need to have a passing understanding of the technologies involved in any contract you’re reviewing. Why? Well first, it’s a requirement of the Five Fundamental Skills for Effective Negotiation (Information Gathering).  Second, assume for the moment that you are going to replace your network infrastructure from one manufacturer to another (these things happen more frequently than you’d imagine). To replace the existing technologies wouldn’t make sense without some amount of upgrades and network re-architecture (replacing old hubs with switches, etc). So the new vendor is offering a swap – hub for hub, switch for switch. Sounds good, right?

Before I tell you if it’s a good deal, what do you know about hubs and switches? Do you know how they work? Hmmm… that might not matter. It would help, however, to know how the devices are constructed. Hubs and Switches are physical devices that connect pieces of networks together. To do this, they have ports on them that accept ethernet cables… lots and lots of them. In other words, the value of a hub or a switch is not based only on whether it’s a hub or a switch (switches are more expensive), but on how many ports it has. So in this particular situation, you don’t just want a like-for-like swap, but also a port-for-port swap, otherwise, you could be giving up money without even knowing it.

Now, this issue also comes into play when you’re negotiating with smaller software vendors (called mISV’s – micro Independent Software Vendors) who sometimes sell software of a smaller dollar amount.  The mISV is quite sensitive to the costs, time and effort needed to work through their license agreement.  In fact, there’s a discussion going on right now over at Joel Spolsky’s Business of Software discussion boards on this very topic.  The mISV’s see the attempt at negotiation as costly and potentially harmful and their reaction is to tell the negotiator that no changes are allowed (they even use EULAs as a way to say it’s a non-modifiable form).

If you’ve taken the time to understand the product/service, there’s a chance that you won’t have to make a sweeping amount of changes to the document.  So, for example, if the product is a small desktop-based (non-networked) product, that doesn’t use ANY network resources (no internet access, for example).  Then I can relax my standards just a bit because now, if the product breaks, the likelihood of it taking down our network in the process is smaller.  So rather than lots of changes to their EULA, I will work with my legal and business folks to agree to only make two changes to the document:  1) Insert a warranty for exactly what the product does/not do – ie: no network access, doesn’t transmit anything, wholly desktop contained, etc; 2) Make the mISV liable for damages only if they breach this warranty.

In this way, I’ve lowered our risk, and I’ve only really made it risky for a deceitful mISV.

Oh, and while you hopefully have a subject matter expert hanging around to help you… you can’t count on them understanding the language enough to know to even ADVISE you of this issue. Because chances are they will make two fatal errors: 1) They believe what the vendor tells them, and 2) Absent blind faith in the vendor, they will also believe that technical people are all on the same page and that it’s only LOGICAL that the swap would be port-for-port.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

“The aim of Zen practice is to discover [this] Buddha-nature within each person, through meditation and mindfulness of daily experiences. Zen practitioners believe that this provides new perspectives and insights on existence, which ultimately lead to enlightenment.” –Wikipedia

As silly as it sounds, the way to master service levels is to draft them over and over.  Yeah, this is the same way to get better at anything, contracts especially.  But service levels are a little special.  I think it’s because they’re going the way of the Dodo.  As few people ask for them, even fewer know to even think about them.  It’s the same cycle that increases the quality of service levels – just in reverse.  Pirsig’s book was focused on trying to define “quality” and in the end, he settled upon a mix of rationality and romanticism.

I said before that service levels have to be SMART: Specific, Measurable, Attainable, Relevant, Time-Bound.  We’ll blend the rationality and romanticism as we go.

Specific – Service levels start with an understanding of the exact quantities of some metric.  This could really be anything, but tempered with the next quality, you have to be able to count it.  Typically, we start with things that are time-related: uptimes and downtimes, repair times and fix times.  Rationality wins here almost every day (the truly romantic notion is that service levels aren’t needed at all because everything’s going to work out as planned) – these things are really easy to measure… and frankly, ease of measurement is necessary because the folks who will be monitoring the service levels aren’t really interested in tracking them.  But why not be a little romantic, too?  Pick something unique about the particular situation.  Maybe you’re licensing software that processes transactions (so you’d count the transactions processed), or maybe you’ve hired an outsourcer to answer your support calls and service levels could be managed based on the number of successful versus unsuccessful customer service resolutions.

Measurable – This might seem obvious, but you’ve got to be able to measure what it is you’re going to base any metrics upon.  Just counting isn’t necessarily enough.  Rather, you might need to be able to track start/stop times/days (and then do the math to calculate the difference).  If the calculation is manual, you also need people who can keep track.  This, perhaps, is the most problematic part of any service level management… as the folks who want the benefits of the service level (usually managers) are not the people watching the clock or experiencing the outages first-hand (the staff).  So unless the staff has some sort of reason to monitor the metric accordingly, none of this is going to matter.

Attainable – I promised you before that the Myth of the Nines would come back into your life, and here it is.  The simple truth is that Five-9 availability is a pipe dream.  5.26 minutes of downtime a year.  Just think about how long your average PC takes to power-cycle.  Servers are typically a little longer.  Even with redundant systems, backups, high-availability resources and every other techincal resource… it’s just not reasonable.  Notice I didn’t say that it was impossible.  It’s 100% possible.  You can have 100% availability.  The issue is cost.  No one ever wants to PAY for that kind of availability.  Not even your most demanding customers.  Wanna’ test this theory?  Price it out from your vendor(s) (as it’ll take more than one to keep even a single service up 24/7/365) and ask your most demanding customer if they’ll pay for the ENTIRE service themselves (since that’s the real cost to get it).  Let me know if they’re willing to do it, because I have a bridge or two to sell them.  Seriously, I’m not trying to be facetious.  I’m a pretty demanding customer myself, but even I know and understand financial limits.

Relevant – Tied to measurable and specific is that each of your service level metrics be relevant to whatever service you’re receiving/providing.  So if you’ve chosen to measure successful versus unsuccessful customer service resolutions, but it’s not tied to the behavior of the service provider, that’s not a relevant metric.  The provider doesn’t have any control over what is being measured, even with perfect behavior.  So where is their incentive to work towards meeting the metrics (or agreeing to them in the first place)?

Time-Bound – Service levels are limited to time.  At first, this sounds quite limiting, but we’re not talking about time in terms of the length of the relationship (service levels should extend for the entire length of the relationship).  Rather, the time we’re talking about here is the time frame in which each metric will be measured.  So, perhaps you’re watching uptime on a daily basis… or the number of widgets produced in a week… or the number of successful service calls completed in a year… or the average length of time it takes to fix a problem of a given severity level over the span of a quarter.

OK, so now that you’ve considered all five requirements, you should have one or more appropriate service levels.  If you still need some ideas, check back with me for the next installment.  Meanwhile, if you have some ideas for inclusion in the next installment, send them along!

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

The 300 Track videos include:
SLES 301 – Warranties
SLES 302 – Indemnification
SLES 303 – Limitation of Liability
SLES 304 – Services Issues 1

(400s-500s Tracks are currently in production and will be released shortly!)

Videos are formatted for a computer or portable video player (such as an iPod) and consist of a slide-show format with voice-over instruction, so you can even learn just by listening!

As promised, purchasers of the Second Edition of the Software Licensing Handbook are eligible for a discount on the purchase of a Track from the SLES.  When redeeming your free Software License Risk Matrix, you’ll receive a coupon code for the SLES via e-mail.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

(*Being the child of the 80s that I am, I would like to believe that this was a creation of the Phoenix Foundation… better known as MacGyver‘s employer. )

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

Anyways, TED’s an annual conference designed to bring the best thinkers together from the entire world to solve some of the world’s most pressing problems.  These folks are encouraged to speak with the other TED attendees for 18 minutes.  Then the TED Prize is awarded to three individuals as a way to grant their “one wish to change the world”.  You can check out their videos on the TED site to see some of the speeches that have been given over the years.  Pretty awesome.

Victoria Pynchon, author of the Settle It Now Negotiation Blog put pen to paper today to ask why there isn’t a LegalTED – a conference focused on finding new and innovative ways to not only resolve disputes, but also prevent them from happening.  I commented to her that I’d had the same idea for awhile now, but I simply didn’t know how to express it the way she did.

If you’re reading my blog, chances are that you spend a significant portion of your day trying to resolve disputes (real or perceived).  You waste time on repetition of the same tasks over and over (between different parties, sure, but the same task nonetheless)… and you fight many of the same battles in seemingly endless succession.  Isn’t it time to find a better way to get the job done?

Head on over to Victoria’s site and contact her through the comments to let her know if you’re interested in helping out.  It’s gonna’ take some work to get this off the ground – not the least of which is trying to get TED interested in allowing us to piggy back off their success (so if anyone knows the folks at TED and can connect us, that would be great).

I look forward to working with you on finding new ways to solve our old (and tired) problems!

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.

So how do you get your business owner(s) to call you?  How do you create the red Batphone from their desks to yours to alert you to every new deal that’s coming down the pipe?

Well, Batman responded to the Batphone (and Commissioner Gordon called) using the same rules you should:

1.  Speed.  You’ve got to be quick.  Batman picked up that phone within seconds.  Turnaround time for initial contact should be less than 8 business hours.  Seriously – you can call someone back (yes, CALL them, not e-mail) in less than a day.

2.  Triage.  Deals should be ranked for importance and severity.  Learn to let the little things go.  Commissioner Gordon didn’t call Batman for every petty thing his police could handle and you shouldn’t be doing every purchase order.  There is a hierarchy of purchasing tasks – and dollars and company impact are key to understanding that risk.

3.  Trust.  Your business folks have to trust you.  Which means that you have to be honest with them.  If they think you’re slowing things down just to get a word or two into the contract, that’s going to tick them off.  In one of the Batman movies (the one with Val Kilmer and Nicole Kidman), the phone was replaced with the Batsignal – the giant light.  In one scene, Nicole had the hots for Batman and used it to lure him to the rooftop to seduce him.  Batman reminded Nicole that it wasn’t a dating signal.

4.  Value.  This one’s not as easy, but you have to get a few wins in early.  Which means that if you’re just starting out, you need to prove that you know what you’re doing.  If Batman didn’t actually save a life or two, the trust and value component of his vigilantism would drop.  Even if the police wanted to use him, they couldn’t because he’d just look like a raving lunatic in a cape.  While contracts people don’t have capes (well, I don’t… do you?) – we have the tendency to be seen as lunatics.  We push for intangibles that very few people understand thoroughly.  So we have to eventually (hopefully quickly) show value.

5.  Process.  You have to teach your business owners the process you want them to follow.  Don’t assume they know your name or e-mail address… or where you sit.  SHOW THEM.  Develop a process flow to teach them when to call, what you’re doing and how everything fits together.

Oh, one last thing:

6.  Give them the Batphone.  Batman, both on TV and in the movies, gave the city the way to get in touch.  HE covered the costs, so to speak, of making contact simple.  Today, that means asking your telecom folks to help you get a dedicated “contracts line”  – an easier to remember phone number.  If your department has an acronym, see if it’s 3 or 4 letters and find out if the number equivalent is available.  Or ask for a repeating digit (like x1111).  If you have an internal phone extension system, there are a lot of opportunities.

Get a dedicated e-mail address (two or three, actually).  contracts@____.com ; vendors@____.com ; etc.  They can be aliases to e-mail lists to make sure that everyone on your team gets the message if someone calls – even if it’s just you.  Give out contracts@ to your internal folks.  Give out vendors@ for generic things from your vendors (like for insurance certificates and on your templates for a notice address).

Do you have anything else you do to get your business folks to come to you for help?  Let us know in the comments or start a forum topic.

The Licensing Handbook Blog is the companion site to the Software Licensing Handbook. Covering licensing topics on a regular basis, Jeffrey Gordon attempts to offer advice, add humor and sometimes even a bit of wit to a practice that most people find abhorrent – namely, reading a contract from start to finish.