Here's The Deal

You thought getting users to agree on one BI tool was difficult? It's nothing compared to negotiating a BI software contract: and unfortunately, many companies read the fine print too late in the process. Fail to negotiate your license agreement well, and you'll end up with overpriced shelfware. Understand the finer points of your BI contract before signing, and you'll have an opportunity to negotiate better terms.

In this article, I'll discuss some of the critical points to remember as your organization looks ahead to 2005 and plans strategically important BI software selections. In short, my advice for arriving at a contract that suits both parties — the vendor and you, the customer — boils down to the following steps:

Show Me the Money!

Often, the BI software selection team is concerned with features and capabilities and has no budget responsibility. Budget constraints concern the CIO, project sponsor, or program manager who may not be as deeply involved in BI software selection. If BI software purchasing is like buying a car, I'd liken this disconnect to my shopping for a car with a blank check in hand. Well, of course, I'd go for the Mercedes sports coupe, but that hardly fits my budget!

So too with BI: The better the selection team understands its budget constraints, the better its members can assess the capabilities for which they are willing to pay a premium price. Communicating budget issues with the vendor can also pave the way to easier negotiations. The vendor better understands your constraints and can propose the products that will provide the most value.

Involve People Early

BI software license negotiations involve a variety of stakeholders. Table 1 lists common stakeholders; the composition will vary depending on the size and scope of the BI software purchase. For example, when you're negotiating a global, million-dollar BI license, the CIO is involved; however, when an individual business unit has its own BI budget and is buying a point solution, the stakeholders may include only the project sponsor and IT project manager.

In Table 1, note that stakeholders have drastically different objectives when it comes to BI purchases. In theory, everyone is united in selecting a BI tool that will help achieve the business goals; in reality, not all stakeholders are so magnanimous. If the purchasing department is measured on how big a discount it can negotiate with a vendor, it will want to buy from the more flexible vendor, especially if that vendor is already a supplier. If program managers are on tight budgets and don't understand the fundamental differences between different BI tools, they'll want the cheapest solution. Users, meanwhile, want the tool that will give them every feature they ever dreamed of; they rarely understand the full cost and support implications.

With all these different objectives, it's no wonder that sales cycles for larger purchases can take up to a year. To negotiate the best BI software purchase, involve key stakeholders early on in the selection process and ensure they're kept informed of major decisions. Note that the purchasing stakeholders aren't synonymous with the BI selection team. The purchasing stakeholders need to understand which criteria are important to the selection team and which products they're hoping to purchase — but only at a high level. It's unrealistic to think that all the stakeholders described in Table 1 can be deeply involved in the selection process. So it's up to the individual charged with moving the purchasing process forward to summarize key points and communicate with stakeholders effectively. If the project sponsor asks for the first time what an OLAP module is and why you need it on signing day — well, it's a bit late in the process.

Understand Product Pricing

When selecting a BI tool, companies tend to spend significant time trying to understand the features and functions but merely skim over pricing and packaging, which are equally complex. Often, the approach is to wait for a quote and negotiate from there. I recommend understanding pricing and packaging much earlier in the process, starting with the request for information (RFI). When submitting an RFI to vendors, be sure to ask them to indicate which product delivers a particular functionality and when additional costs kick in. Too often, vendors respond, "yes, yes, yes" to RFIs: and little did you know, the functionality you sought comes in a myriad of sometimes additional products.

No two vendors price their products the same way: nor do products generally provide like-for-like functionality, making cost comparisons a Sisyphean challenge. Customers, feeling nickel-and-dimed, balk when they find out too late in a negotiation that certain functionality costs extra.

In the past, Cognos has been criticized for this sort of posture. In response, the company has recently adopted role-based pricing. With this approach, business managers, for example, receive certain products such as ReportNet (for reporting) and Metrics Manager (for scorecards) that address their roles. The Business Objects product line had also become complex, offering an overwhelming number of choices. The company recently adopted the pricing policy used by the company it acquired in 2003, Crystal Decisions; Business Objects now bundles products that were previously licensed separately into professional or premium editions. Both vendor's approaches help ensure a customer gets an appropriate set of functionality with minimal surprises.

Just as vendors may price products on an individual versus package basis, so too will they differ in server- and user-based licensing.

Server-Based Licensing

Server-based pricing allows a company to buy a license regardless of the number of potential users on any given server. Many BI vendors will specify a license that assumes a certain number of CPUs per server. When the number of users on any one server threatens performance, a customer can buy an additional server license and distribute the load. Server-based licensing is simpler to administer than user-based pricing. However, it can be more expensive for smaller deployments.

It's hard to beat Microsoft's simplicity for server-based pricing. Reporting Services and Analysis Services are both included under the SQL Server license. There are no concerns about fees for platform changes (since it's only Windows) or additional client charges. In contrast, customers have been critical of MicroStrategy's approach to pricing in which the vendor charges based on server clock-speed, in addition to named users. In other words, if a customer upgrades from a 1GHz CPU to a 3GHz CPU to improve performance, license fees increase significantly.

Many vendors have different pricing policies for different server platforms, such as Windows, Unix, or Linux. If you want the flexibility to change platforms in the future, specify that in your initial contract. The vendor has less incentive to discount after you've signed an initial contract and already deployed to thousands of users. Also, if you plan to have a development, test, and production environment (you should!), specify it in the contract. Vendor approaches to development licenses range from no charge to full production pricing.

User-Based Pricing

BI vendors may charge a user fee in addition to or instead of server-based pricing. A user could be a named user or occasionally, a concurrent user. Business Objects' Crystal is one of the few BI products that can track the number of concurrent users for licensing purposes. Named user pricing is often preferable to server-based pricing for smaller deployments or when any given user may access multiple applications deployed across multiple servers (for example, a financial application and customer orders, both of which use the same BI tool). Named user licensing is also important for a minority of users who will have expanded capabilities. For example, companies may want to buy a named user license for 10 report authors but buy a server-based license for 1,000 report consumers.

As BI vendors have expanded ease, frequency, and the number of formats into which a report can be delivered (such as PDF and spreadsheets), many have introduced the concept of a "recipient" license. A recipient is a form of named user who may never log into the BI application but who receives reports generated by the BI application. At a recent TDWI conference, the class laughed when I explained recipient-based licensing. "So if my phone company sends me an e-bill generated from a BI tool, the phone company has to pay a recipient license for me? That's ridiculous!" exclaimed someone in the audience. There was a disgruntled pause before the same person asked, "Can the vendor track that?" (Most can't.)

Clearly, vendors need to capitalize on the improved functionality and additional formats into which BI tools can now deliver information, without losing revenue from named users. No BI vendor will remain viable if too many users who used to log into the BI application and paid for a BI license can now receive all their BI reports via email with no license fee. Yet, there comes a point at which the recipient concept gets ridiculous. As a customer, your concern is to understand the vendor's policy, ensure you can comply, and specify exceptions in the contract.

Maintenance and Support

When buying software, you're paying for current functionality. Maintenance generally includes bug fixes, software upgrades, and varying levels of support. Maintenance fees are often a percentage of your total license agreement ranging from 18 percent to 30 percent of either the list price or discounted price. Here, too, there is a lot of room for vendors to fudge and for customers to miss a strong negotiating position. If you fail to specify a term for which the maintenance rate applies, then next year, the vendor could increase the maintenance rate from say 18 percent of the discounted price to 25 percent of the list price. As a consequence, maintenance on an initial $400,000 BI purchase could leap from $57,000 a year to more than $100,000.

With maintenance and support incurring a sizable cost, you must include these items in the BI purchase budget. It would be shortsighted to think you can do without them. While some companies might argue that they'll never upgrade as often as the vendors release new software, if you fail to pay maintenance one year, you may have to renegotiate the entire contract if you decide in the future to upgrade. The only time I'd suggest not paying maintenance is if you have made the strategic decision to "sunset" a particular BI product. (If this is part of your plan, communicate this to your new BI vendor. The vendor may offer special pricing for replacing a competitive BI tool.)

Maintenance and support are good elements for negotiation because they seldom affect the salesperson's commission. Further, public companies are under constant pressure to show growth in license revenues, and thus are increasingly less flexible with discounts on license fees. Even if you can't negotiate better terms for maintenance, don't overlook opportunities to include support ranging from a certain number of days of consulting to access to training material and classes.

SAS, a privately held company, is one of the few BI vendors to offer a subscription approach to its software. Thus there's no split between software licensing and maintenance. Customers pay an annual subscription fee as long as they continue to use the software.

Develop Your Plan B

When you negotiate contract terms, having a Plan B will drastically improve your position. If your first-choice vendor knows it has you locked in because of unique capabilities that your company simply can't do without, the vendor has all the negotiating power. Expect to pay close to list. If you have two vendors on your short list, however, you can be more aggressive. Managers at a telecommunications company told me that they made the strategic decision to have two BI standards solely to ensure that their company had some negotiating power over both vendors.

Your Plan B doesn't always have to involve another vendor. It may be a matter of limiting or phasing in the number of users or product components to ensure you stay within budget. Having a Plan B is especially important if you're embarking on a new BI deployment. While vendors would like you to negotiate immediately for an enterprisewide standard, smart companies will phase in software incrementally and first ensure that the product and vendor support is what they expected. If you can specify phases in your contract, this will ensure that the vendor stays focused on your success and takes less of a hit-and-run sales approach. If your plan is ultimately to deploy the BI software as an enterprisewide standard, consider having the contract specify two phases and terms, for example:

Lastly, a Plan B may mean changing the timing of your purchase to match the vendor's quarter or year end. A decision maker at a high-tech company who had recently negotiated a contract told me, "We were very fortunate in that our vendor was coming up to its end of year. Generally, at end of period, salespeople are more apt to work with you in terms of discounting to make their numbers."

In this article, I've described four things you can do to develop a BI contract that better suits both you and the vendor. When negotiations become difficult, it's helpful to remember that, ultimately, both you and the vendor want the same thing: to enable your company to use BI products successfully.

Cindi Howson is the president of ASK, a BI consultancy. She teaches The Data Warehouse Institute (TDWI)'s "Evaluating BI Toolsets" and is the author of Intelligent Enterprise's recent BI Scorecard product review series.