.::::REINER ARTICLES::::.

Software Sourcing Strategies

| back to articles |

What Buyers Need to Know About Negotiating Software Agreements

Best bet for buyers heading into negotiations with software suppliers: Know the software application and how it impacts the business process. So says Ditka Reiner, president of Reiner Associates, San Rafael, Calif., ditka@reinerassociates.com and a speaker at this year's annual conference of Caucus the association of high-technology acquisition professionals held recently in Washington, D.C.

As Reiner sees it, when corporate purchasing managers play a leading role in developing specifications for software the organization is buying, they "will be more comfortable in negotiations with suppliers. This will be to their advantage." Reiner, who works with organizations to help hone their negotiating skills, believes that purchasing should work together with IT (information technology) and business unit managers to develop the organization's requirements for software. To be successful, "both must have the same objective."

Then, purchasing must begin its work on researching both the product and potential suppliers, seeking answers to such questions as: Are there alternative products or is the organization captive? (Many IT organizations tend to believe that they are captive, says Reiner.) What do other customers say? How good is the supplier at development? How is their support during installation? What happens once the installation is complete? Specifically, purchasing needs to conduct an extensive check of the supplier's background. "If available, get an audited copy of last year's financial statement," suggests Reiner. "Have your financial group review the statement and rate it."

Evaluating the software itself is important to the organization and there are two ways to do this, which is determined through the negotiation process. The first is through an evaluation-only license; the second, a license agreement with a test clause. "Demonstrations mean nothing," Reiner told the standing-room-only crowd that gathered for her presentation. "Purchasing needs to make clear test, acceptance, and rejection criteria" when negotiating an evaluation-only license. What's more, buyers should specify supplier support requirements and be realistic about the time needed to evaluate the software. However, most users prefer to negotiate a license agreement with a test clause. It is a one-time involvement that admittedly does take more time. For this method, buyers should specify "a clear out."

Licensing the software

In licensing the software, Reiner stresses again that purchasing managers need to understand the business and functionality of the software being acquired. Purchasing should have a good grasp on licensing terms. Does the organization need a perpetual license or will a monthly or yearly license suffice? Purchasing needs to ensure that the organization is protected in the event of a merger or acquisition. Perhaps the most important term in the agreement is the word "user." Termination criteria must be clear as well.

For a critical application, supplier support and service capability must be spelled out, says Reiner. Also important: precisely defined requirements for disaster recovery and testing and training.

Ask the supplier for all documentation (user manuals, system guides, report layouts, etc.) Make sure users conduct a detailed review and communicate their approval. Hook acceptance and performance to specifications. It's important for purchasing to work with users and the supplier to provide deliverables and delivery dates. Align payments to timely delivery. Reiner suggests 50%/50% or 25%/75%.

Getting down to the nitty-gritty, Reiner says that purchasing needs to pay particular attention to the issue of source code, something an organization must have in case the supplier's business fails. And, buyers need to think about additional modules. Who will pay for them? In negotiations, purchasing should ensure that the organization receives the modules at the same discount as the original software.

Other issues Reiner touched upon in her presentation: acceptance testing, warranty, and maintenance.

Acceptance testing should begin upon successful implementation. The test should be mapped to specifications. And, there needs to be a time frame for resolution, with the user having capability to reject. Generally, payment and refunds are tied to acceptance. Upon acceptance, the warranty begins. In negotiations, determine the length of the warranty. It is tied to the organization's specs. When it ends, maintenance begins. Maintenance should cover at least two versions of the software, says Reiner. The supplier provides support of customized modules, and upgrades and fixes at no additional cost. There is a cap on increases.

For more information on Caucus, becoming a member, local chapter meetings, and the annual conference, visit the group's Web site at www.caucusnet.com or call 407-740-0700.