by Tim Nuckles

   This article was originally published in The Productivity Institute (PI) Newsletter

Part One – Recommendations for Leveling the Software Negotiations Playing Field
Part Two - Future Proofing Contracts by Maximizing Flexibility 
Part Three – The Software Maintenance Game 

PART THREE – The Software Maintenance Game 

As we all know, there’s a lot of buzz these days about inflated maintenance charges.  Frankly, I think users of commercial software are moving beyond frustration and on to anger, and reading articles about the 85% profit margin that Oracle enjoys on its maintenance fees, for example, only fuels the fire.

In addition to introducing flexibility on maintenance terms (Part 2), software buyers should keep the following points in mind when negotiating maintenance terms and options.

First, there’s the notion that a chunk of software may be entirely new to a buying organization, but the software itself may be old.  Buyers need to gauge where a software product is in its lifecycle, and react to maintenance options accordingly.  Naturally, if the software has a grey beard, there probably won’t be another major release.  So, why pay for something that you’re never going to receive?

Second, most of my clients pay maintenance on most of their applications, but they rarely install updates (everything works fine for them and they don’t want to risk an adverse event that might result from installing an update).  This makes no sense to me (the paying for maintenance part).  If your organization never installs updates, then why ever sign on for maintenance at time of acquisition?  The same is true if you updated for some time period, but haven’t in recent years.  Drop the maintenance!  You may not be eligible for support at some point after going naked on maintenance, but that is not an issue for many organizations, especially for mature deployments.

Third, software buyers need to stop being angry about maintenance costs and doing nothing about it, in my opinion.  Some new concepts are gaining traction and may eventually change the nature of software maintenance permanently.  But software buyers must start demanding alternative maintenance options in order for these new concepts to take hold.

One new concept is “reverse maintenance”, and the notion is this.  Instead of paying up front for something that I may never receive (or not want if I do receive it), why can’t I pay later for the something; that is, when I receive it and if I want it?  Seems fairer to me, and it would actually incent software vendors to create and improve their products.  Under the current model, software vendors take in the same amount of maintenance fees regardless of whether they deliver anything (of value) in return.

The other new concept is “pay for performance”, and one version of it works like this.  You pay your maintenance fees up front, but you are entitled to reimbursement depending on what your vendor actually produced during the prior maintenance revenue period.  One obvious shortcoming of this approach is that it incents your software vendor to produce something during a maintenance revenue period, but not necessarily something that is of value to users.  Should the reimbursement metric be based on volume of stuff produced, value of stuff produced, or both?  If value figures into the equation, how are we to measure value?

In all events, software buyers want and deserve better (more realistic) maintenance options.  If software vendors don’t respond with a better maintenance model, more and more software buyers will opt for no maintenance—whether at time of acquisition, or perhaps sooner in an application’s lifecycle.

Just to clarify, when a software buyer chooses not to buy maintenance at time of acquisition, or should a buyer attempt a reverse maintenance or similar concept, the buyer can expect to pay a higher license fee.  This is to be expected, and it will vary across acquisitions, but the hike in the license fee will usually be much less than the sum of (normal) annual maintenance fees paid out over the life of the application. 

Timothy Nuckles is the principal in Nuckles Technology Law Firm, a business law firm specializing in information technology transactions that offers a process-driven approach for the acquisition of commercial information technology products and services.  You can learn more about him at www.nuckleslaw.com.

by Tim Nuckles

   This article was originally published in The Productivity Institute (PI) Newsletter

Part One – Recommendations for Leveling the Software Negotiations Playing Field
Part Two - Future Proofing Contracts by Maximizing Flexibility
Part Three – The Software Maintenance Game 

Part Two – Future Proofing Contracts by Maximizing Flexibility

Flexibility is a really important issue within software deals, and one that is under-appreciated by software buyers, in my opinion.  Among even my more sophisticated clients (those having been through relatively more deals over time), on flexibility issues I often hear, “That’s a great idea, and quite honestly, that has never occurred to me.”  Flexibility issues simply are not on the minds of most software buyers.
 
So, what are we talking about in terms of flexibility within a software deal?  Well, for me, flexibility centers mainly around expense items, license and service fees (maintenance and support).  The goal is to create as much flexibility as possible for things like the base license structure, user license structure, and maintenance and support options.
 
For example, instead of checking the “single server” box in a schedule to denote the base license structure, and then checking the box for “100 to 300 users” to denote the tiered user license structure, and calling it done, we can accomplish a lot more.  These should be regarded merely as the choices made at time of purchase.  We want to create ability in the buyer to switch among all base and user license options available now, as well as those made available by the software vendor in the future, at any time and without penalty.  In other words, this should not be, and does not have to be, a one-time, live-with-it-forever selection.  Let’s call this side of the flexibility ledger the “buyer options” side.
 
The other side of the flexibility ledger is called “vendor obligations”.  These are affirmative duties we create for the software vendor, and they feed into the buyer options and drive toward cost containment.  For example, we want a software vendor to tell us whenever it introduces a new base or user license structure (or associated fee structure) during the life of deployment (because that may be the thriftier choice for us going forward).  The new license or fee structure should be made known to us, on the one hand, and made available to us without a penalty for switching over to it, on the other.  “We’re tiered now, but we want to be on that new Flexi-Seat option.”
 
Flexibility within software deals serves many purposes for software buyers, but cost containment is probably the main goal.  On cost containment specifically, a strong and meaningful “most favored nations” provision (MFNP), and one that ties back to all flexibility issues, is critical.  Have you ever known anyone who, if they managed to get one into their software deal, has ever benefitted from or enforced a traditional (impotent) MFNP?  Personally, I do not.  There’s a lot of hay that can be made with this type of provision, and software buyers need to start to realize that.  Think of an MFNP as the mirror image of a vendor’s audit rights.  Upon the occurrence of each license and compliance audit, you as a buyer get to do your MFNP audit, part of which requires your vendor to certify that you have gotten at least as good a deal as the best deal made available to the vendor’s new and deployed users over the last revenue period, and if not, it’s payback time.  Now, isn’t that a refreshing idea?
 
As a software buyer, you want to give yourself rights and avoid what I call the “Cable TV syndrome”, where a new neighbor moves in, and you find she is paying less than a third of what you pay for the same Cable TV channel selection.  And you have been a loyal cable subscriber for 8 years!  That angers you, and software buyers are angered when they find out others are paying a third of what they pay for the same software.  You may not have much ability to negotiate terms with your Cable TV provider before you sign on as a customer, but you have lots of ability to negotiate terms with your software vendor before you sign on as a customer. 

Timothy Nuckles is the principal in Nuckles Technology Law Firm, a business law firm specializing in information technology transactions that offers a process-driven approach for the acquisition of commercial information technology products and services.  You can learn more about him at www.nuckleslaw.com.

by Tim Nuckles

   This article was originally published in The Productivity Institute (PI) Newsletter

Part One – Recommendations for Leveling the Software Negotiations Playing Field
Part Two - Future Proofing Contracts by Maximizing Flexibility
Part Three – The Software Maintenance Game 

Part One – Recommendations for Leveling the Software Negotiations Playing Field

Most buyers of commercial software products usually negotiate from their software vendor’s standard form of EULA and Maintenance Agreement (embedded or stand-alone), whose terms inevitably are terribly vendor-biased and devoid of any buyer protections.  They start negotiations by attempting to “neutralize” the various vendor-biased provisions, without giving any thought to what should be their true end game (addressing their own needs, their expense preferences, elements of risk, etc.).  The fact is, the vendor’s terms are typically so vendor-biased that neutralizing them is not of much value to the buyer.  For any term, the vendor’s starting point was so extreme that, even after bargaining down somewhat, the vendor is still in a dandy position, and the buyer is not.  Sadly, most buyers stop negotiations after this impotent neutralizing exercise and consummate their deal with a vendor, without even attempting to add in buyer-favorable terms and protections.  Stated another way, buyers usually negotiate from what one might call a “defensive” posture, when they ought to be on the “offensive”, affirmatively and assertively bargaining for terms that serve and protect their interests.
 
So, my first general recommendation to buyers of commercial software is to break out of their habitual neutralize-the-terms routine.  These exercises take a lot of time (for both sides), and they produce actually very little or no benefit to buyers.
 
My second general recommendation to buyers is to stop regarding themselves as the disadvantaged party in a software deal, and to start regarding themselves as the advantaged party.  There are several dimensions to this notion, but first and foremost is a very fundamental recognition:  buyers have dollars to spend on software, and software vendors want their money.  Right out of the gate, this is a position of strength, not weakness.
 
When buyers drop unproductive habits and routines, and start to approach software negotiations as empowered (not disadvantaged) buyers, a new world of possibilities is available to them.  There’s a lot of material that we could discuss within this , but here’s a quick example.  Buyers should figure out what terms are important for all of their software acquisitions, and actually draft their own versions of those terms.  License grant, indemnification provisions, warranties, and so on.  Then, those terms need to be introduced early in the acquisition (procurement) process.
 
In my practice, for example, I have a standard Software License Agreement (SLA) that I use for enterprise app’s and major app’s.  It’s not a terribly buyer-biased SLA (that would be counter-productive), but it does contain tons of buyer-favorable terms and protections.  In the enterprise and major app’s arena anyway, vendors will often agree to work from my paper instead of their own.  My paper gets introduced at the RFP stage, such that my client can base its buying decision on a vendor’s appetite for our presented terms, as opposed to selecting a vendor and then beginning negotiations on terms.  This is better from a buying decision perspective (it’s much harder to win terms and conditions from a vendor after they know “they’re it,” the chosen vendor), and it also greatly reduces negotiation cycle times.  When this approach has been used, and a vendor is selected, there simply aren’t many terms left to negotiate.
 
Another approach, one often used by public sector software buyers here in the U.S., is to basically attach naked terms to an RFP (as opposed to a full-blown agreement).  Under this approach, the buyer is saying, “Should we strike a deal, these terms must be part of our deal.  We don’t care necessarily where they appear in your contracts, but they have to be in there, and your other terms cannot conflict with them.”  I use this approach with clients, public or private sector, when I’m not able to introduce one or more full agreements (usually occurs because of the uniqueness of a particular deal).
 
Timothy Nuckles is the principal in Nuckles Technology Law Firm, a business law firm specializing in information technology transactions that offers a process-driven approach for the acquisition of commercial information technology products and services.  You can learn more about him at www.nuckleslaw.com.