NET(net), Inc.


This Week on The Web 2009-09-20 by jigordon
September 20, 2009, 9:32 am
Filed under: copyright, document assembly, negotiation, revenue recognition, TWoTW

These are the discussions that happened around the web this week – maybe you already read about them, maybe you need to again.  Come join the party on twitter (follow me here and you’ll participate in the conversation live.)

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.



Brittle Contracts by jigordon
September 2, 2009, 9:32 am
Filed under: contract format, document assembly

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



Forms and Templates by jigordon
July 23, 2009, 9:32 am
Filed under: document assembly, templates

There are a lot of people pushing for contract process automation.  Ken Adams, famously known for his contract style manual, has been on this bandwagon for some time now.  Others are close behind – all trying to find ways to automate the parts of the contracting process that can be automated.

While I’m a big fan of gadgets and tools, and yes, even templates, I worry a bit about what is being offered by way of these various forms companies.  Recently, I wrote about WhichDraft – a good service with templates that (while I didn’t review all of them) seem to at least have been written by someone with knowledge of what is supposed to go in them.  On the other hand, I see hundreds of software developers looking online to find a sample agreement that they can crib for their own use.

I’ve tried time and again to express to these developers (and my fellow contracts professionals) that templates are all well and good – if you wrote them yourself or if you know and/or trust the author.  If, however, you’re simply grabbing whatever you can find – or using a pay service who doesn’t put the author’s name on the template, you might want to think twice. [In fact, I recently inquired of one such company and they wouldn’t even respond.]



WhichDraft.com Document Assembly Tool by jigordon
June 30, 2009, 9:32 am
Filed under: document assembly, process

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!