Monthly Archives: June 2009

WhichDraft.com Document Assembly Tool

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

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

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

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

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

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

 

Advertisement

Clear to Sell User Data

When Clear announced their intent to terminate operations, the big question was: “What’s going to happen to each users’ private data (things like, um, fingerprints and background checks)?”

Now we know.  They intend to SELL IT!  This is why I harp on making sure that you have the proper provisions in your contract(s) for confidentiality, indemnification, information security and limitation of liability

To Clear’s credit, they are saying that they’re going to continue to comply with their pre-existing privacy policy – and that the data can only be sold to another TSA-approved traveler program.  But what if that program is run by an organization you wouldn’t want to have your personal details?*

Interestingly enough, however, this violates the terms of that agreement (as it existed when I pulled it from flyclear.com on June 29, 2009) – boldings are mine:

3. ADDITIONAL LIMITATIONS ON APPLICANT AND MEMBER PERSONAL INFORMATION
A. We do not sell or give lists or compilations of the personal information of our members or applicants to any business or non-profit organization. We do not provide member or applicant personal information to any affiliated or non-affiliated organizations for marketing.
B. None of the information that we collect may be used for any purpose outside the operation and maintenance of the Clear Services.
C. We would only disclose personal information about members or applicants if required to do so by law or legal process.

The termination of operation might be considered a “legal process” – but the way the language is written, 3.C. would not be valid as a result of the company’s dissolution.  Thus, they’re limited to 3.A. – which clearly states that they won’t sell the information to “any business.”  I wonder what the chance is now that they’ll only sell it to someone who’s TSA-approved.

*Not that the government doesn’t now already have your information as a result of the background check.  I’m just sayin’.

Warranty Elephant

Even if you have the Novatus Contracts system, warranties for your one-off hardware purchases (software, too) are not easy to remember.  Typically, you don’t even get more than the warranty card that comes in the box.  When your hardware breaks, do you know what the warranty will cover?  Probably not.

Neither did the creators of Warranty Elephant.  This simple (and free) service allows you to record your purchases along with their associated warranties.  No more forgotten warranties, no more misplaced warranty documentation.  Granted, this system was developed for personal use, but here are a few commercial uses I’d find valuable:

  • fleet warranty management (ie: if you have a bunch of vehicles, reminders about when the transmission is about to come off warranty is helpful)
  • one-off hardware or volume hardware that doesn’t come with a more robust specific warranty (such as TVs/monitors, laptops, Aeron chairs)
  • items you used to think were cheaper to simply replace than to monkey around with warranty info (keyboards and mice)

Pricing Issues

In the contracting duality of terms and pricing, I spend the bulk of my time here talking about terms.  The reason is generally simple – terms are fairly common across contracts.  Pricing, on the other hand, appears deal-specific and too different to really discuss in detail.  I simply can’t tell you that a 30% discount is what you should be looking for all the time.  Sometimes 10% is good (for certain vendors) and sometimes 80% is good (for other vendors).  Without violating various confidentiality provisions – and without knowing other specifics about a particular deal (such as its size, duration, etc) – I’m a little boxed in.  But I did realize that there are a few things you can learn about pricing which will help you, regardless of which side of the fence you’re on.

First, you need to go read Joel Spolsky’s excellent article: “Camels and Rubber Duckies“.  This will give you the starting point for understanding how pricing should be created.  Eric Sink uses a similar breakdown to understand the economics of how software is priced.  Next, you need to understand the four basic ways software is licensed.  This article by Erik Keller from 2007 in Manufacturing Business Technology is a bit dated, but hits the fundamentals.  And even within the SaaS model (and, in fact, the traditional model), there are different metrics upon which the licenses can be measured.  Check out this optional article by Jason Rothbart from January 17, 2009’s ReadWriteWeb.

So armed with an understanding of how software is priced, we then need to move onto maintenance and support.  Let’s start with the basics from this 2006 Information Week article (still relevant data).  What we’ve got these days is a system in which we expect to pay a base fee for the license plus an annual support fee… or we pay the leasing/SaaS model of “license renewals” for each year of use.  Regardless of how you slice it, there’s an annual fee component to the deal.

Forgetting about the tax implications of mandatory maintenance in many jurisdictions, I instead want to focus on a very specific pricing issue – the increase. Yup, all of this build-up and what I really want to talk about is the language in your various license agreements and maintenance documents that allow for increases in license and/or maintenance fees year after year (you need to understand how license fees are created to really dive into increase language).  This is a hidden gem for vendors and is often overlooked by licensees, simply because people don’t think about its effect on price (because it’s an increase on future pricing and not today’s pricing, it’s sometimes not deemed relevant or worrisome).  I believe that license and maintenance fee increase language is dangerous at best and disastrous at worst.  Here’s why.

Assume for the moment that you’ve paid $1,000,000 for your license and that you have a 20% annual maintenance fee.  There’s no more “warranty grace period” so, interestingly enough, the vendor actually wants $1,200,000 that first year.  Well, to start, Vinnie Mirchandani over at deal architect will tell you that maintenance is overpriced.  I agree.  For $200,000, I would expect at least 1/5th the value of the license to come back to me that first year in maintenance and support.  In other words, is the software SO BAD that it requires 4,000 hours of support by a $50/hour technician for that year?  I hope not.  Or, alternatively, are you getting a 20% increase in features and functionality in the next release of the software that year?  My guess is that the answer to both questions is “no”.

So 20%, on its face, seems pretty unreasonable from the get-go (you can also just think about it in terms of re-licensing costs… do you want to have effectively paid to re-license the software in 5 years?).  Now let’s factor in the increase.  These range from 3-15% in most license templates today.  Even at 3%, that would equal a $6,000 increase in the $200,000 fee from Year 1 to Year 2 (at 15%, that increase would be $30,000).  The most common rationale given for increases is a cost-of-living (economic) excuse for the support people.  The second most common is the same argument, only this time, it’s the cost of goods and/or materials.  (My personal favorite counter argument is to agree that pricing should be tied to the economy, and then re-write the language so that “the pricing changes based on the CPI-U All-Items percentage for the prior year”.  This allows it to actually go down.  A savvy vendor won’t ever allow this.  But then their excuse evaporates, too.)  Thus, I’ve had to concede increases in many cases.  I’ve even said before that for 3-5 year deals, I try to get increases removed for the term of the agreement (it’s the trade-off for a long-term deal).

But what about increases not tied to the economy, rather the simple cost of doing business?  Should customers be saddled with the expenses related to having to change a product because the vendor’s industry is regulated by the government?  Should the end-user, mid-term on a contract, be expected to pay for changes resulting from something completely outside of the customer’s control?  I’m thinking specifically in the telecom industry (and others) – where federal regulations that result in fees typically find themselves trickled down to the customer.  I’ve said it before and I’ll say it again… the telecom vendors don’t have to pass along the fees.  They could pay them themselves.  But they don’t.  If you’ve ever seen a line-item for cost-recovery fees, that’s what we’re talking about.

So the question is – should you accept these pass-through fees?  Or, more specifically, should you accept increases in these pass-through fees?  I can understand that there is an economic argument (as above)… that it’s an increase in cost for something you thought was fixed or sunk before the contract was signed.  But isn’t it just a risk of doing business in any particular industry?  Don’t we, as automobile owners, for example, take the risk that gas prices are going to increase or that we may lose our jobs tomorrow?  And that if we decide to buy a car today, we accept those risks and have to deal with the consequences if the situations change?  Why should I have to protect not only myself, but also my vendors, from the risks (and costs) of doing business in their industry?

License Resale

Vinnie Mirchandani at deal architect pointed out a Ray Wang article on the resale of unused licenses.  My thoughts are in the comments on Ray’s article.  But generally speaking, regardless of what Ray suggests, you can’t do it in the US (or the rest of the Berne Convention countries) under most licenses which have express prohibitions against it (you can almost always contract away your rights).

And, even if you could, your organization probably doesn’t have tracking enough to make it possible – just remember that if you overuse your permitted license count, chances are there’s another provision in your license that allows the vendor to charge you (perhaps at non-discounted pricing) for the overage.

What I DO like about Ray’s suggestion is that idea that you should try to negotiate for a recapture of maintenance fees on unused licenses.  If you can’t resell them, the least you can do is take an annual count and only pay maintenance on the ones you’re using.  There is, of course, trouble with this thought, too – as there are some vendors that used to allow this (the last one I remember was Autodesk).  But the trouble is that you can get into a situation where you only upgrade SOME of your licenses to the current version because not all of them are currently covered by maintenance and the upgrades provided under such program.

 

ALI Approves the Principles of the Law of Software Contracts

As I mentioned a few weeks ago and now recently reported by Concurring Opinions, the American Law Institute recently approved the final version of the Principles of the Law of Software Contracts.

If any particular state adopts these rules, I will probably recommend what commenter Sean Hogle recommended – the addition of yet another disclaimer.

Interesting Tidbits

I’ve not done this before, but given that I just got off vacation and have an inbox that would scare most people, I thought a few tidbits of things passing my desk might be of interest to you:

The Ideological History of the Supreme Court of the United States

A White Paper on Insurance Coverage for Cyber Security Losses (e-mail required)

The Applicator on “Chiseling on Demand”

Thirty Interview Questions You Can’t Ask and Thirty Sneaky, Legal Alternatives to Get the Same Info (hat tip to D.C. Toedt)