Category Archives: contract management

This Week on The Web 2009-09-06

The things that happened around the web this week – maybe you already read about them, maybe you need to again.

I also realized that many of you might have no idea what you’re seeing below.  Sorry.  These are “tweets”, 140 maximum character messages sent via Twitter.  Within the Twitterverse individual users follow others and have followers (think of it like overlapping Venn diagram circles).  To read a tweet, you have to wade through a bit of jargon used to make the most of the 140 character limitation.  “RT” for example, is shorthand for “Re-tweet” and the @____ is the username of some other individual on Twitter.  Combined together, then, “RT @_____” means that someone else wrote a tweet that I found important and I now want to forward along to my followers.  The URL’s are then also shortened by shortening services like bit.ly to make the most of the character limitation, too.  Lastly, you might see “hash” identifiers “#______” which are ways to tag tweets of a particular flavor for easy searching later and “<” which means that I am commenting on what came before it.

Advertisements

Brittle Contracts

David Dobrin (of The Applicator fame) wrote recently on the topic of brittle applications.  He defines a brittle application as “one that doesn’t work unless a lot of disparate conditions are met.”  In thinking about his description of MS-Word, I was struck by the concept that many contracts I encounter are brittle as well.

To illustrate my point, think about the last contract you reviewed.  Did it have a definition section?  How about references to external documents (a spec list, a set of documentation, a “missing” Exhibit or Appendix)?  Was it full of cross-references or have noticeable gaps (such as missing language for standard terms)?  Was the contract obviously written for a different type of product or service?  In all of these situations, I believe you have a brittle contract.

Contracts are “incorporated” documents.  This means that all of the various sections have to work and play together to form a cohesive end-product.  When you’ve identified gaps, errors or problems, these mistakes can cause cascading failures throughout the entire agreement.  A poorly-defined term, for example, could ripple through the contract, causing errors in judgment regarding expectations, or could even create legal problems with regards to intellectual property.  In other words, the poorly-defined term doesn’t hurt itself, it hurts the entire document.

The same is true for commonly overlooked sections on subjects such as term, termination and scope.  When a lack of attention results in an incomplete picture of the relationship, the net impact can be extremely detrimental (ever had a perpetually-renewing contract for poor services that was hard to get out of because termination was only for breach, yet the services weren’t defined well enough to hold the vendor to performance standards? I have.).

You can also look at brittle contracts from another perspective, one my friend D.C. Toedt might appreciate.  D.C. seems to love language portability – drafting contract sections that can be used in a plug-and-play format to craft the appropriate document (you should check out some of his work in his clause library).  This type of drafting is a part of the holy grail of contracting – the complete automation of the contract creation process based on a wizard-style interface which asks questions and assembles an appropriate finished product from such a library of contract clauses.

The inherent problem with document assembly is brittleness – that you insert a clause into the agreement that has to properly “work” with all of the other sections.  If the clause has a faulty cross-reference, for example, the contract breaks.  On the flip-side, however, document assembly fixes one of the aforementioned brittleness issue with current contracts – having a completely appropriate document for the specific product or service being offered under the agreement.

So… how brittle are your contracts (especially your templates)?

This Week on The Web 2009-08-30

The things that happened around the web this week – maybe you already read about them, maybe you need to again.

I also realized that many of you might have no idea what you’re seeing below.  Sorry.  These are “tweets”, 140 maximum character messages sent via Twitter.  Within the Twitterverse individual users follow others and have followers (think of it like overlapping Venn diagram circles).  To read a tweet, you have to wade through a bit of jargon used to make the most of the 140 character limitation.  “RT” for example, is shorthand for “Re-tweet” and the @____ is the username of some other individual on Twitter.  Combined together, then, “RT @_____” means that someone else wrote a tweet that I found important and I now want to forward along to my followers.  The URL’s are then also shortened by shortening services like bit.ly to make the most of the character limitation, too.  Lastly, you might see “hash” identifiers “#______” which are ways to tag tweets of a particular flavor for easy searching later.

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!

This Week on The Web 2009-08-23

The things that happened around the web this week – maybe you already read about them, maybe you need to again:

This Week on The Web 2009-08-16

The things that happened around the web this week – maybe you already read about them, maybe you need to again:

Confidentiality Exclusions versus Disclosures

When dealing with confidential information, one of the key areas of concern is where information that would otherwise be considered confidential loses its protection.  In most contracts, there are four situations where confidential information ceases to be confidential information and can be released.  Information that:

  • was in the public domain prior to, at the time of, or subsequently to disclosure;
  • was in the lawful possession by recipient prior to disclosure and was not already covered by a confidentiality provision;
  • is subsequently acquired by recipient through lawful means from a third party who is not under an obligation of confidentiality; or,
  • is subsequently developed by recipient without use of or reference to the confidential information.

For these four items, information that was confidential now is not.

There’s a fifth reason which would allow for disclosure, but I argue, shouldn’t change the nature of the information from confidential to non-confidential: disclosure pursuant to court order or legal process.

In this fifth scenario, we’re talking about a situation where a court of competent jurisdiction orders the release of information, usually to the court, as part of a judicial (or extra-judicial, like arbitration) process.  The information is going to be disclosed because of it’s probative value – that simply because it’s confidential doesn’t mean that the court shouldn’t consider it as part of whatever is the subject of the litigation.

But that doesn’t mean that I want that information to change status to non-confidential information.  Rather, what I want is to keep that information confidential even AFTER the judicial review.  This is possible through the use of protective orders and other legal procedures.  But if your contracts say that a judicial process will change the information’s status to non-confidential, a single well-strategized lawsuit can unintentionally release a lot of otherwise-confidential information into the public domain.

The best way to handle this is to make sure that your confidentiality provisions clearly segment release of confidential information pursuant to a court order from the other four reasons by which confidential information becomes non-confidential.  Additionally, include language that requires the disclosing party (the one responding to the court order) to:

  1. Notify the owner of the confidential information that such court order is being pursued/followed/responded to.
  2. Reasonably assist the owner of the confidential information in obtaining any available legal protections.
  3. Only disclose the specific confidential information requested by the court order (not just hand over everything).