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.