Category Archives: process

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

Advertisements

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.