Category Archives: process

Individual Evergreen Clauses

Fred Stutzman over at Unit Structures laments the issue of individual auto-renewing agreements (like those of any kind of subscription you may sign onto).  He’s rightfully upset about his individual circumstance, and even without reading the specifics of the ZipCar agreement (I’m sure there is one somewhere), the basic business practice is the issue – auto-renewing agreements, especially subscriptions, are problematic.

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.

Putting you on Notice

The concept of notice seems fairly simple.  In advance of a particular date, usually by some multiple of 30 days, a party is required to send the other party a letter (“notice”) of their intent to take some form of action.  Notice can be required for extending or terminating an agreement, asking for price increases or decreases, a desire to perform an audit, or any number of other contractual possibilities.  Notice usually comes in two parts – the date by which notice must be provided and the form in which notice must be given.  Let’s start with the format first.

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 500s Track of the Software Licensing Education Series is now available

Designed for the busy or on-the-go professional, the Software Licensing Education Series (SLES) is video-based training on the complete gamut of software licensing topics. Presented in a college-course level format, with topics increasing in complexity and building upon prior lessons, the SLES allows an audio-visual learner another way to gain knowledge on licensing topics.  Each video is approximately 20-30 minutes in length, so each Track contains about 2 hours of expert instruction in core software licensing topics (note that the 500s Track is only about 1.5 hours since it’s only 3 videos)!

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!

Understanding (Your) Technology

Ken Adams recently posted about the destruction of confidential information that would otherwise be found on backup media. Beyond the discussion of suitable contract language is a conversation about a contract professionals’ understanding of the technology about which you’re drafting contracts.

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.

Zen and Art of Service Levels (with apologies to Robert Pirsig and Eugen Herrigel)

“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!

Software Licensing Education Series – 300s Track Now Available!

Designed for the busy or on-the-go professional, the Software Licensing Education Series (SLES) is video-based training on the complete gamut of software licensing topics. Presented in a college-course level format, with topics increasing in complexity and building upon prior lessons, the SLES allows an audio-visual learner another way to gain knowledge on licensing topics.  Each video is approximately 20-30 minutes in length, so each Track contains about 2 hours of expert instruction in core software licensing topics!

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.

CIA’s Approach to Problem Solving

Banner, a marketing agency in the UK, recently posted the Phoenix List*, a list of the questions used by the CIA when trying to solve a problem.  Banner was approaching it from a marketing perspective, but these same questions can be used to solve a contracts or negotiation problem, as well.

(*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. 😉 )


If you’ve never heard of TED, you should check it out!  (If you’ve gone to TED, please let me know.)

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!

Creating the Batphone

One of the most common stumbling blocks most contracts people encounter is simply getting their business folks to come to them for help.  In a great article from the Wisconsin Technology Network, Mark Foley lists 10 questions a business person should ask themselves to find out whether they should go get contracts assistance in a technology acquisition.  Mark’s triage review happens a little late in the process and the comment from Erik Phelps drives that point home – earlier involvement can lead to better deals.

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