Computer Software Acquisition - Issues & Best Practices

Author(s):

Michael D. Feldman, A.P.P.
Michael D. Feldman, A.P.P., Vice President - Corporate Technology, J.P. Morgan, New York, NY 10260, 212/235-5367, feldman_michael@jpmorgan.com.

83rd Annual International Conference Proceedings - 1998 

Abstract. Modern commerce would not be possible were it not for the vital functions provided by computer software. Buying a software product, however, is intrinsically unlike buying most other types of products and services. Add to this, interdependence factors involving the hardware and the other software products that will coexist on the same "box", a constant state of rapid technological change and a whole host of other considerations, and the result is a degree of technological complexity that most purchasing professionals are ill equipped to handle. Yet in many instances, purchasing professionals are expected to not only acquire software for use by the Purchasing Department, but for the enterprise as a whole. Selecting and purchasing software in a cost effective manner requires the combined skillsets of the professional technologist and the purchasing professional. However, few purchasing professionals are cross-trained in technology, and conversely, few technologists possess the knowledge and discipline of the purchasing professional which are key to getting a good deal. In this session, a broad range of practical topics will be examined through the combined optics of the purchasing professional and the technologist, including: the life-cycle of software as it affects cost, choosing the best vendor/product combination, negotiating with software suppliers effectively, pricing considerations, and a discussion of how software license agreements can get you into trouble and how they can keep you out of trouble.

The Nature Of Software. There are two important points to be made here. First, irrespective of how software is usually marketed to, and conceptualized by, a purchaser, it never seems to do everything it is supposed to do. It is unusual and a real "win" if a software product meets 80% of a purchaser's requirements and expectations. It is the purchaser's responsibility to know what these requirements are, and not depend upon the supplier to define them. After all, would you ask your hairstylist if you need a haircut, or your mechanic if you need a tune-up? When the supplier defines the requirements, there is almost always (coincidentally?) only a single product that seems to fill the bill. By the same token, the purchaser's requirements and expectations must be tempered by what is technologically feasible and available. Additionally, the purchaser must: 1) become familiar with the product's features; 2) understand in detail the hardware/software environment in which the product will run; 3) have an understanding of his/her firm's technology architecture/infrastructure (current and planned); and 4) have an understanding of trends and directions within the technology industry. A significant portion of this information sits squarely in the technologists' realm.

Second, unlike the other products one buys, a software product does not constitute a physical asset in any sense of the word. There are no tangible raw materials that are required for its manufacture. A software product (which includes a software program, or programs, and the supportive documentation describing the system) is an expression of a set of ideas, and as such, is classified as intellectual property. As with other forms of intellectual property such as songs, movies and books, software products are protected by domestic and international copyright laws. Hence, to be precise, one does not actually buy a software product. Rather, one acquires a license to use a software product, and the allowable scope of use of the product is defined in, and limited by, the terms and conditions contained in a software license agreement (SLA). It would be accurate to say that in essence, one buys contractual terms and conditions. The SLA may be a negotiated (or non-negotiated) legal agreement executed by the customer and the supplier, or it can be what is referred to as a shrink wrap agreement. A shrink wrap agreement is the supplier's form agreement typically printed on the package containing the program diskettes. The customer ostensibly "agrees" to the terms and conditions of the shrink wrap agreement by the act of opening the package. The only physical assets which the customer owns outright are the diskettes themselves, which are viewed as being apart and separate from the software program(s) they contain. It has become possible to acquire software by downloading it directly from certain software suppliers via the Internet. As part of the ordering process, the SLA is almost always displayed on the customer's workstation, and then a button must be clicked acknowledging acceptance of the agreement's terms and conditions before the download will take place.

To actually buy a commercial software product, which is something software companies commonly do to enlarge their product lines, would require purchasing the intellectual property rights (IP rights) to that product. This would obviously be significantly more expensive than merely purchasing the right to use the particular software product, but gives the purchaser the unrestricted (and usually exclusive) right to do anything at all with the software. There are two related points worth mentioning here in connection with IP rights. First, when you contract with an individual or a consulting firm to write specialized software to your specifications, you need to be very careful about who actually owns the intellectual property rights to the software. While Agreements for Professional Services are outside the scope of this session, you will under normal circumstances want to own the IP rights to the "work product" and the agreement needs to specify that. Second, when purchasing commercial software through a reseller, understand that the reseller does not hold the IP rights; it merely has the right to sell you the software and may have little or no authority to negotiate scope of use issues with you.

Software License Agreements (SLAs). As noted above, when a purchaser acquires a license to use a particular software product, the manner in which the software can be legitimately used (i.e., scope of use) is defined by the SLA. The terms and conditions contained in the SLA determine the extent to which the purchaser is likely to get into trouble or stay out of it in the long run. In general, one should assume that if the agreement does not specify that the purchaser has a particular right, then the purchaser does not have it. For example, an SLA might state that for a particular fee, two copies of a particular software program may be used by the ABC Company on the 29th floor of 129 Main Street, on a certain type of hardware platform using a particular operating system. If this is the current environment at the ABC Company this might seem reasonable to a purchaser. After all, the intended use of the software is fully and accurately described. However, what happens if the 29th floor is to be renovated, and the users of the software must relocate to the 30th floor? Is this a problem? At the very least, it's certainly a potential problem and potential problems tend to become real ones. That is, unless the agreement specifies that the software may be relocated at the purchaser's discretion. In the example above, and in the absence of the purchaser's stated right to relocate the software, the supplier could take the position that moving the software to another floor would be a breach of the agreement. Note that if you make additional copies of the software, except as specifically permitted under the terms of the SLA, you are likewise breaching the agreement not to mention committing an illegal act.

Almost all SLAs will define the consequences for breaches of the agreement, which can include cancellation of the software license without any provision for a refund, the payment of liquidated damages, etc. The supplier will have other open avenues as well, including the ability to seek injunctive relief from the courts and to litigate. As software is intellectual property enjoying statutory protection, the use of software in the absence of a license agreement, or beyond the authorized scope of use where there is a license agreement, can constitute an infringement of copyright. Copyright infringement is illegal and carries the exposure of criminal and civil penalties. In actual practice, resolving this type of situation is not usually a problem assuming the purchaser accepts the adage that anything that can be solved by writing a check is an expense, not a problem.

The best general strategy is to ensure that an SLA not only fully meets your current requirements, but takes into account all likely future scenarios. Easier said than done, but there you have it. Envisioning future scenarios requires knowledge of the plans of the business units who will be using the software, plans made by the IT Department regarding changes to the firm's technology infrastructure, and trends and directions within the technology industry itself. Even then, there is always a measure of uncertainty and risk. Never make assumptions about scope of use issues - it is not a matter of common sense and nothing should be considered obvious. If you want to be able to use software in a given way, make sure that the SLA provides for this intended use, specifically. That is, at least to the extent you can gain the appropriate concessions from the supplier during the course of the negotiation. This means that letters from the supplier, oral representations made by the sales representative, etc., that contain concessions or terms that are important to you need to be included in the SLA. In the example above, there is no problem if you are certain that the users of the software will never move from the 29th floor (and the users never do). But what happens if in our example, the ABC Company is bought by the XYZ Company, an event that for argument's sake could never have been foreseen? Since the SLA specifies that the ABC Company holds the license, doesn't it make sense that the XYZ Company should be able to make use of the software as if it were the ABC Company? So it might seem, but if the agreement does not contain a suitable assignment clause which enables transfer of the license to the XYZ Company, the supplier could take the position that the XYZ Company is not licensed to use the software and must purchase a license. Alternatively, what would be the result if the user desires to change or upgrade the hardware and operating system (usually a matter of when, not if) after acquiring the software product? Essentially nothing, as long as the SLA contains suitable language - should it not contain such language, the software supplier may well demand additional fees for enlarging your scope of use.

When defining scope of use requirements in conjunction with SLAs, realize that your requirements can be viewed from multiple perspectives. Take all perspectives into account in order to build the most effective and comprehensive scope of use language. To illustrate, is your ultimate goal just to acquire a particular software package, run it at one or more particular locations, on one or more particular hardware/software platforms, or is your goal to enable individuals within your company to process work more efficiently and accurately? To achieve the latter (the result) requires the former (the components), but by the same token, don't allow the former to restrict the latter - be sure there is sufficient flexibility in the SLA so that this doesn't happen. Understand where the true value lies. It does not boil down to where you run the software, on what computer, under what operating system, etc. These considerations are not the same as your true need and don't intrinsically add value. Helping individuals and your firm process work more effectively is where the true value lies. This is what your firm is really paying for and this is what it should get.

It is quite beyond the scope of this session to discuss the form and content of SLAs in depth. There are three additional points, though, that are worth making. First, a discussion of SLAs would not be complete without mentioning the desirability of building your own SLA template and insisting that it be used for software acquisitions. This is, in fact, a best practice. It is in the supplier's interest to make the scope of use as narrow as possible to maximize potential revenue opportunities through time, and disclaim warranties to limit the expense of rectifying "alleged" problems. It is in your best interest to make scope of use and warranties as broad as necessary to ensure that your requirements, as you conceptualize them in their entirety, are met without having to make additional payments somewhere down the road. A contract is a mechanism for allocating and managing risk, and as such, one finds that supplier agreements tend to saddle the customer with a disproportionate amount of risk. The purpose of having your own form agreement is to reallocate the risk in a manner more acceptable to your firm, to include terms and conditions that are important to you, and to ensure that you do not have to "reinvent the wheel" every time you purchase a software package. Shrink wrap agreements, mentioned earlier, are nothing more than suppliers' form agreements, and there is no reason why you cannot negotiate the use of your own form agreement given a large enough purchase. Commercial seminars and templates are readily available for those desiring to learn the art of building and negotiating effective software license agreements. It is extremely important to understand that such efforts should be in addition to, not in lieu of, having access to and the assistance of competent legal counsel knowledgeable in computer law. The second point concerns language. SLAs should be written in plain unambiguous English. Beware of words and phrases, sometimes called "weasel" or "wiggle" words, that are imprecise, and which are used in a manner such that what they describe can't be objectively measured. Contrast "the software will execute substantially in accordance with the documentation" to "the software will execute in accordance with the documentation." The first phrase is encountered in virtually every supplier form SLA, and is represented by suppliers as being reasonable. How much protection does this representation actually give the buyer? Well, hopefully it is obvious that the degree of protection the customer receives is totally dependent upon whatever definition the supplier ascribes to the word "substantially." To establish a frame of reference, consider whether it would be desirable to purchase a car that steers in a "substantially" straight line. The third and final point concerns establishing an expected level of software performance and quality in the SLA, and also establishing that the supplier will pay a remedy to the customer if the expected level is not met. Incidentally, the degree of supplier reluctance to contractual remedies is a good barometer of whether the supplier will meet the performance/quality criteria documented in the SLA. A supplier with confidence in its products and personnel will seldom refuse to put a reasonable remedy provision in an SLA.

The Value Equation. "Total Cost of Ownership" (TCO) is a concept that describes the aggregate cost of acquiring a software product including, but not limited to, the following component costs: research and testing costs prior to purchase; cost of negotiating the SLA; software license fees; support/maintenance/installation fees paid to the supplier; support/maintenance/installation costs for work performed internally by the customer's staff; training costs; and the cost decommissioning the software product at the end of its lifecycle. Many individuals mistakenly believe that acquiring a software product at some predefined level of discount equates to a good deal. This is not necessarily the case as: 1) the software might be significantly overpriced to begin with; and/or 2) the other component costs (i.e., support, etc.) might be excessive such that the overall deal is substandard. TCO measures the overall effectiveness of a particular deal. The best vendor/product combination is the one with the lowest TCO, and where the software meets the functional requirements of the purchaser at an acceptable level.

Beware of getting deals which are too good. First, every supplier is entitled to a reasonable profit. Second, that being said, a supplier that is willing to settle for insufficient profit from your firm will likely do the same for other firms. Given that supplier stability is of critical importance when buying a software product, a supplier not making sufficient profit will probably not be in business long. Should this happen, you will in all probability need to walk away from your investment since it is no longer supported, and acquire another product that is supported.

The question of how much to pay for a particular product is often difficult to answer, although much less so when the product is a well known commodity item such as a word processing program. Obviously, you need to know the allowable scope of use before you can evaluate a supplier's offer. Software suppliers do not want you to know that manufacturing software, once it is written, is almost without cost. That is why many suppliers, while certainly willing to take as much profit as customers will give them, are open to negotiating discounts when selling a product. Any shortfall in the sales representative's meeting his/her sales quota for the period would seem as pertinent a factor in the setting of price as any other. In contrast, these same suppliers tend to be hard-nosed, but not by any means immovable, when negotiating the price of maintenance and support, their long term revenue stream which funds their cost of doing business and research and development. Looking at per seat pricing within the context of TCO can help provide the measure of value a particular price represents.

Negotiations. The two issues here are people and process. This is an area where the individual skill sets of the technologist and the purchasing professional are vital, but at the same time, are quite different. In general, the purchasing professional will have more experience in the area of negotiating with suppliers and general contracting, but will lack the technological background necessary to achieve the best possible deal in terms of TCO and "fit" with the firm's existing technology infrastructure. In contrast, the technologist will probably be much better informed as to the technological risks and exposures that need to be addressed in the SLA. Technologists, generally speaking though, may be more concerned about the software product's technical features, and less concerned in regard to contractual terms and conditions, price, and the stability and viability of the supplier. Technologists, as a group, also tend to be more concerned with the perceived tenor of the relationship with the supplier and are therefore more susceptible to being manipulated by the supplier. Since it is technology that is being acquired, they may well have a vested interest in getting the technology in-house regardless of the terms. In many organizations, either the Purchasing Department or the IT Department usually takes the lead in one or more areas of software procurement, with minimal involvement of the other area. This is anything but ideal. Experience has shown that the most effective deals obtain when the individual negotiating on behalf of the purchaser possesses both skillsets at the expert level. In the absence of individuals who possess this dual expertise, it is important that the purchasing professional and the technologist work together closely as a team.

One potential approach to building this type of multifaceted expertise in-house begins with identifying one or more of the firm's senior technologists having responsibility for technology procurement, or if there aren't any, at least those having an interest in that area. Such individuals, encouraged or assigned to work actively with the Purchasing Department on a variety of technology procurement projects, will have the opportunity to gain a working knowledge of the purchasing professional's world view. Depending upon the size of the organization, its requirements, and the career aspirations of the individual(s) involved, this might be either a full-time or a part-time responsibility. NAPM's program of study in preparation for the A.P.P. examinations is an excellent means of filling gaps in the knowledge of those technologists working in partnership with the Purchasing Department.

In terms of process, RFPs are an effective formal means of negotiation and are recommended for any significant software purchase. (Depending upon the circumstances, their use may be mandatory for governmental entities.) The availability of competition will always be one's best ally in terms of getting a good deal. Remember that writing software in-house and not buying anything are two alternatives that provide competition. The most common mistake people make is allowing a supplier to think that there is no competition, whether through intentional or unintentional overt statements or by implication. In such case, the supplier has no motivation to make concessions to the purchaser in terms of price, scope of use, etc. When RFPs are used, they assist the purchaser in selecting "finalists" rather than a "winner." Accordingly, the winner is the supplier who gives the purchaser the best value, and in doing so, is the finalist that executes the SLA. Building a comprehensive RFP from scratch, however, is often an expensive process that may not be cost effective when the software product is relatively inexpensive. This threshold can be lowered, and this is a best practice, by developing an RFP template. The variables will be a description of the requirement(s), the individuals to contact, and the schedule, all of which should be relatively easy to construct in contrast to building an entire RFP. As with the SLA template, competent legal counsel should assist in building the RFP template, or at a minimum, review it once it is complete. The SLA template should always be included as part of the RFP template, and supplier responses should be required to specify those areas of your SLA considered problem areas. Given that the SLA is the essence of the transaction, you should know prior to finalist selection which suppliers come closest to accepting your pro forma terms and conditions. If your SLA template is balanced and reasonable, suppliers should normally have few problems with it. Your RFP template should specifically state that it is not an acceptable response for a supplier to substitute their SLA template in lieu of identifying the issues that they have with yours.

Know The Supplier. Knowing your supplier is a well accepted tenet of the purchasing profession. However, software suppliers not yet well established constitute a particular source of risk to the software purchaser. A significant number of such suppliers fielding new products (which may, in fact, be excellent from a technical perspective), where there is already a pre-existing market leader for that type of product, often do not capture enough of the market in the long run to stay in business. Customers who have purchased software from such companies that ultimately fail cannot obtain needed support and upgrades, and almost always end up replacing the products with others that are more mainstream.

Conclusion. The information provided during this session should be viewed more as the tip of the proverbial iceberg than as a definitive work on the subject. The procurement of software is clearly a specialized area. As in other pursuits demanding multifunctional expertise, truly qualified individuals will in all likelihood be expensive, relatively speaking. Bear in mind, though, that given today's technology costs, mistakes can be even more expensive by orders of magnitude.


Back to Top