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.

by Timothy Nuckles

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

When we think of product warranties, we tend to think of things like an automobile warranty.  You buy a new car, and the manufacturer warrants that it will fix manufacturing defects for four years or 48,000 miles, whichever comes first, at no charge to you.  We all know what the warranty means, what the typical limitations are (e.g., normal wear and tear), and most of us have personal experience with making an auto warranty claim.

When it comes to software, however, the notion of a warranty is less clear to most.  If you have ever read a software license, you know its warranty provision is long and wordy, many paragraphs appear in all cap’s (presumably to call attention to their special importance), and there is actually very little the vendor warrants.  Normally a vendor will warrant only that its software “will perform substantially in accordance with its Documentation.”  The remainder of the long warranty provision is devoted to establishing numerous exceptions and disclaimers to the already stingy grant of warranty.

This type of software warranty provision was born at the beginning of our “software era,” when it was common for vendors to sell software that was still truly “in development.”  Also, the platforms running software at the time were unstable.  Under these circumstances, software vendors found it necessary to limit their exposure to warranty claims and consequential damages (“our software is not perfect, it may or may not do what you want it to do, and in all events, we’re not liable if our software causes your system to crash and you lose data, productivity and profits”).

Obviously, things are much different now.  Within any software market segment today there are lots of competent vendors, and the increased competition (some call it “commoditization” of the software industry) has pretty much eliminated poor state of development at time of sale (Microsoft Vista aside).  Technology platforms are also more robust and stable.  All of these positive developments would suggest that software vendors could loosen up a bit and start offering more and better warranties for their products.  Yet, the standard software warranty has not changed a bit.

Although software vendors could (comfortably) offer better warranties these days, they have no real incentive to do so.  As long as the industry sticks with the same archaic and vacuous warranty provision, there is really no incentive for a given software vendor to offer anything more.  The fact is, if you want more, you have to ask for it.  And when you ask for more, be prepared to negotiate for it.

I have two bits of advice for you.  First, stop thinking of software warranty provisions as being off-limits and non-negotiable.  Just like every other contract provision, software warranty provisions are negotiable.

Second, start thinking of software warranties in broader terms.  There are many aspects of your software purchases that are appropriate for your vendors to warrant, but they are usually overlooked by most buyers.

For example, consider integration issues.  If you have been led to believe a software package is “fully integrated” with the ubiquitous SoftCo Communicator application—whether from reading a sales brochure, listening to sales pitches, or whatever—and this integration is important to you, then ask your software vendor to warrant its integration with this other product.  More specifically, ask the vendor to warrant integration with your particular version and configuration of SoftCo Communicator.

As another example, consider sales materials in general.  Do you want your software vendor to acknowledge that you relied upon its sales materials in making your buying decision, and to warrant that the sales materials are accurate and do not contain any misrepresentations?  Should the sales materials be incorporated into your License Agreement?

What about use cases and demos?  Are there aspects of either that stood out to your project team?  Could and should these aspects be converted to warranties?

These are but a few examples.  There are literally dozens of buyer-favorable warranty elements that should attach to any software purchase.  You simply have to think about what is important to you—what will lower your risk, give you more and stronger rights, and in general, give you greater comfort.

Remember, too, that for every special warranty element you seek, think about an appropriate remedy for its breach.  Software vendors will often attempt to limit their liability to buy-back of their software (which is often enough), but think about going for more in special cases.  For example, if your software vendor will be extending or customizing its software for you to some degree, you should think about recovery of service fees incurred up to the point where you hit the brick wall (breach of warranty).

Whether and to what extent you get your enhanced warranty requests reduced to writing will be largely up to you and your negotiating ability.  When a particular request is met with strong resistance from your vendor, there is usually a good reason.  You did not get your SoftCo Communicator integration warranty, but you know why.  The state of integration was overstated, and most important, overstated in ways that are especially important to you.  You did not get the warranty, but you now have better information about an important aspect of your buying decision—information that might not have come to light had you not taken an expansive approach to software warranties.

Timothy Nuckles is a procurement attorney and consultant who 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 Timothy Nuckles

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

(This is the second part of a two part article.  Part 1 of this article discussed several of the most-often cited reasons for not using an RFx process for information technology acquisitions and the realized benefits it offers.  Part 2 continues that discussion.)

Technology vendors no longer respond to RFIs or RFPs.

Situation:  Your organization has used an RFx process for technology acquisitions in the past, but with a low vendor response rate.  You have concluded that the RFx process is no longer meaningful for technology acquisitions, or at the very least, not worth your time or expenditure of resources.

Solution:  Accept the fact that the RFx process is not flawed for technology acquisitions, but that your approach to the process may be flawed.

Except for public sector procurement, which is constrained by statute and regulation, the traditional one-shot, cover-the-world RFx process is out of vogue in most commercial contexts, including IT.  These RFIs and RFPs take forever to develop, and it takes vendors forever to respond to them.  Quality (busy) vendors and consultants, the very ones you want to attract to your project, simply may not have time to respond to this type of RFx process.

Stop thinking of the RFx process in “binary” and polar terms:  all or nothing; jumbo RFP or no RFP; large one-step process, or no process; and so on.  Instead, think of the RFx process as a continuum, with a broad range of available scale and complexity.  What you might typically think of as a major one- or two-step process can be broken down into a greater number of smaller steps, each of which is more manageable and can be accomplished in short order.  There are numerous options along the RFx continuum, and one or some combination of options will be most appropriate for your particular technology project.

Too many options and too many decision points.

Situation:  You are facing a complex technology project, and you are overwhelmed by vendor choices and the decisions you must make relative to your project- and environment-specific needs.  It is simply too difficult to construct a meaningful RFx campaign for such a project.

Solution:  Realize that numerous vendor options and project decisions points constitute reasons to use an RFx process, not reasons to exclude the process.  If you are facing a difficult or complex project, do not go it alone.  Solicit help from vendors and consultants you may ultimately hire to finish your project.  They are not going to plan your project for you (at least not for free), but they will be willing to give you lots of good information on the chance that they may be awarded all or a part of your project.  They will know how others with a similar need are proceeding, and they will likely know in advance some of the challenges to success that you are facing.  You can use an initial RFI to open dialogue with vendors and consultants, and maybe issue a subsequent RFI or two to a smaller subset.

Also, consider that an RFx process has a way of structuring your complex project and adding clarity to its various elements.  If you have not thought out something carefully, chances are good that you cannot reduce it to writing.  Eventually you will have to communicate your project needs and preferences to vendors or consultants, and just how will you do that?  Divide and conquer is the approach taken by most project teams, and the outputs from a divide-and-conquer approach usually transfer comfortably to your RFx process.  It is usually just a matter of assembling the various bits and pieces that will emerge from your planning process anyway, and then organizing them into an intelligible whole.   

Timothy Nuckles is a procurement attorney and consultant who 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 Timothy Nuckles

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

(This is the first part of a two part article)

Most buyers of commercial information technology products and services do not use any formalized RFx process—Request for Information (RFI), Request for Proposal (RFP), or Request for Quote (RFQ)—for their technology acquisitions.  Ironically, they appreciate the value of the information produced by an RFx process and the competitive bidding environment the process facilitates.  They use an RFx process for most of their non-IT acquisitions, but IT is the exception.

Following are the most-often cited reasons for not using an RFx process for information technology acquisitions.  Although there is a nubbin of validity to each, these reasons are mostly excuses for not using some version of the best tool available to acquire information technology products and services.

We do not have enough time to conduct an RFx process.

Situation:  Your stakeholders are clamoring for some new application or functionality, your planning process took longer than anyone imagined, and now you are under the gun to get your project started.  You are ready to buy some software or consulting services, or both, and you simply do not have the time to conduct an RFx process.

Solution:  Avoid the time trap with three techniques.

Plan to include an RFx process.  Instead of treating an RFx process as little more than an afterthought—a valuable process, time permitting—build the process into your project plan and allow reasonable time for its execution.  It seems so obvious, yet so many organizations do not do this.  Then, when time runs short, their RFx process gets eliminated or short-schrifted, which usually means dollars and unallocated risk are left on the table.

Overlap processes.  Realize that information technology project planning and procurement do not have to be separate and distinct processes.  You need not complete one before you begin the other.  By combining or overlapping these two processes, you give yourself more time for a meaningful RFx process.  In fact, there is often appreciable value to starting an RFI process while your planning process is ongoing.  Reaching out to potential vendor candidates (true market segment experts) with an RFI during your planning process can produce information that is invaluable to your planning process itself, creating a planning-procurement feedback loop.  An RFI might well produce information that is critical to your tactical and strategic decision making, and it is much better to have this information in the early stages of your project.       

Layered approach.  Let go of the notion that your RFIs and RFPs have to be comprehensive, one-shot, cover-the-world documents—your one and only opportunity to interface with potential vendors and consultants.  By definition, these documents take a long time to produce, and for many other reasons, they are usually not the optimal choice.  Instead, embrace the notion that your RFIs and RFPs can be “living” documents, with each subject to later adjustment and refinement.  Instead of requesting a comprehensive set of information and detail from a large number of vendor candidates, you can break your RFx process down into smaller chunks that are more easily digestible by vendor candidates.  Your goal is to request the most detailed information from only the most qualified vendor candidates, and only the most qualified vendor candidates have to prepare additional detail.  By using a layered approach to your RFx process you will save time and increase vendor response rates.   

We already know what vendor we want to use, so why waste time with an RFx process?

Situation:  Your IT project team scopes out a new project, does a good deal of planning, and with funding still available, it is time for vendor selection.  The selection process is simple because your project team has already identified its preferred vendor, and you set about negotiating with that single vendor.

Solution:  Whether friend-of-friend referral or presumed market segment leader, avoid the temptation to source from a single IT vendor or consultant.

First, It is not easy to win price concessions and buyer-favorable terms and conditions from a vendor when the vendor knows “they’re it”—the preferred vendor, the only vendor in the running.  Competition in the technology sector has increased dramatically, and technology vendors have developed a keen instinct for assessing their bargaining position in a given setting.  When you sole source, you are clearly disadvantaged.

Second, your project team’s assumptions about its preferred vendor might not be entirely valid.  Is this one vendor truly the best for your needs?  Is it the only vendor who can meet your needs?  An RFx process is a cheap way to test assumptions and uncover other valuable information. 

Instead of contacting the single vendor directly for an informal quote—or however you might initiate contact—it is usually better to issue an RFI or RFP to the single vendor. The RFx will give structure to the acquisition process and subsequent negotiations, and it will create at least the pretense of a competitive bidding scenario in the mind of your preferred vendor.  Then, logically, if you are going to create this project-specific RFP for the one vendor, you might as well send it to other vendors as well, thereby creating a real competitive bidding process.  You have nothing to lose, and everything to gain.

Again, your RFx process does not have to be long and protracted, and indeed, you may ultimately select the vendor who was preferred from the outset.  However, now you will have positioned yourself to receive better pricing and other buyer-favorable terms and conditions from this vendor, in a compressed time frame, and all because of the competitive bidding element of your approach.  Your chosen vendor will have earned its preferred status through your RFx process.

(In part 2 of this article, I will continue this discussion of common excuses why businesses do not use the RFx process for technology acquisition and several of its benefits.)

Timothy Nuckles is a procurement attorney and consultant who 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 .