 |
Resources » Newsletter Archive » Preparing to Negotiate a Well-Rounded Contract Newsletter Archive
Preparing to Negotiate a Well-Rounded Contract
July 2009
In our last newsletter, we reviewed the importance of Vendor Due Diligence in selecting a solution for your institution. Once this process is complete and you have settled on the solution, it is time to start preparing to negotiate the contract.
If you have properly handled the due diligence phase of the vendor selection process, you should have a couple lists that will be essential to the contract negotiation. The first list is comprised of the items that are important to you and your institution. These were the driving factors that initiated the search for a solution. Sometimes these items are not fresh in your memory after many functional presentations, technical reviews, site visits and conference calls, but they are essential to ensuring the original motivation and business case is in tact. The second list is essentially a pros and cons sheet of the final vendors. Characteristics such as features, implementation resources, financial health, trends, past customer experience, etc. should be noted and scored.
As you begin to prepare for the contract negotiation, you should always ask yourself three basic questions. What are we buying? From whom are we buying it? How much is it worth? Answering these questions in detail is vital to the contract process.
What are we buying?
The first question seems rather straightforward, but this is where the biggest disconnect often happens. Your understanding of what you are buying and the vendor’s understanding are often very different. From the vendor’s perspective, it is very simple. They think you are buying the “WhizBang 1.0” system that has been packaged by the marketing and sales team in brochures, product descriptions, PowerPoint presentations, functional demo, etc. The product, as they see it, has been defined by them and will be clear to anyone in their organization that sees the product name listed on the contract. The features, capabilities, service levels, implementation timeframes, resources required etc., has all been predetermined based upon their definition of what the WhizBang 1.0 product is or isn’t.
From your perspective, you’re not buying WhizBang 1.0, you are buying a solution that delivers specific functionality and value to your organization. Whether it’s named WhizBang 1.0 or LegacyJunk 9.0 is not your concern. You are trying to solve a particular set of issues that your institution identified that initiated your search for a solution. The “what” you are buying is not defined by a product name, but rather a set of descriptors.
As an example, let’s say that you are having problems with your current Business Online Banking Solution. Your current solution has the following issues:
1. It is built on legacy technology that is expensive and resources for supporting it are hard to find.
2. The system has unacceptable downtime to you or your customers' service level.
3. The vendor is always late with promised upgrades and fixes causing you to lose credibility with your customers.
4. The functionality is lacking and is placing you at a competitive disadvantage with other institutions that have a better offering.
This is what caused you to embark on this mission in the first place. Therefore, the solutions to these issues should be your definition of what you are buying. You are not buying WhizBang 1.0, you are buying a solution that:
1. Is built on recent technology and resources to support are plentiful.
2. Has an established uptime of XX%.
3. Has a track record of on-time delivery for fixes and upgrades.
4. It meets or exceeds your functional requirements.
Although the definitions above leave much room for interpretation, we suggest you define these as finitely as possible. These are your definitions of “what” you are buying and it is imperative that you are able to define it this way in your contract. The functionality, delivery and acceptability of the solution should be defined by your requirements, not the vendor’s product brochures.
From whom are we buying it?
Now that you defined "what" you are buying, it is time to evaluate from "whom" you are buying it. If you have followed the suggestions from last months’ article in Vendor Due Diligence, you should have a list of pros and cons regarding your vendor of choice. This list should be the result from your interaction with the vendor, product demonstration, customer site visits, reference calls, financial statements and any other information you have learned about the vendor. Some of the characteristics you should know about the vendor include: company longevity, current financial health, current sales trends, history of implementations, history of support, etc.. There won’t be any vendor that has a spotless record, but you should have been able to get a sense of their strengths and weaknesses. If you can’t list any weaknesses, then STOP! You’ve missed something. As stated in last month’s article, if they didn’t have weaknesses, they wouldn’t have any competition. Better to find out now, so you can account for the risk in the contract.
Listing a vendor’s weakness is not for the purpose of beating them over the head with it. The primary reason is so that you can reconcile those weaknesses to your definition of "what" you are buying. For instance, if you find out that the vendor has a history of issues with “significant downtime” and you have identified “minimal downtime” as a key descriptor to what you are buying, you will need to incorporate specific terms in the contract that address this issue. Another example that we have encountered was a vendor who had a reputation for releasing a new “module” every time they increased functionality. The significance was that customers had to purchase new modules, while upgrades to current licensed modules were included in their maintenance agreement. While this vendor’s history of innovative functionality was what made them attractive by placing their customers at a competitive advantage, the vendor had a history of "nickel and diming" their customers with new "modules" in order to maintain that advantage. Through some creative contract language, we were able to account for that risk.
Whether it is a young company that does not have a proven track record or an old stalwart that seems to have lost their innovative edge, each vendor brings with them their own set of risks. The more thoroughly you have documented and discussed these risks, the more prepared you will be for the contract negotiation process.
How much is it worth?
Finally, we come to the price. Notice how it is last, not first. This is by design and unfortunately is the exact opposite of how many clients approach the process. Don’t get me wrong, price is important, because if you can’t afford it, then nothing else means much. However, the solutions that were out of your price range should be eliminated before you reach this stage of the process.
In determining the "worth" of the solution, you must determine two things, the value to your organization and the current market value of the solution you are buying. The lesser of these two is the absolute most you should be willing to spend. Determining the worth of the solution is best done with a business case. Hopefully, this is something that was already completed before you started the vendor due diligence process. The combination of tangible vs. intangible and objective vs. subjective costs and benefits should have been factored in to create a value range for the solution.
A common mistake made by clients in determining this value is their current costs for the solution they will be replacing. This cost is no doubt factored into your budget, but that does not necessarily indicate it's value to your institution. With ever changing market conditions and paradigms, solutions that were contracted for in years past may have a far less present day value to your business model. Take check processing for example. In the mid to late 90’s, check processing and imaging were significant costs to institutions. The benefit of the new solutions that optimized float, reduced operators via automated CAR/LAR technology and created a competitive advantage by offering images to customers in their statements, online and on CD-ROM, was a tremendous value to institutions. However, times have changed. For the most part, the cost savings have been realized, the competitive advantage is gone. This has led to a commoditization of that market. But I assure you that there are many clients still paying software maintenance of over 20% based on the price, or “worth”, of the solution when they initially contracted for it many years ago. What’s worse is that there are typically automatic maintenance increases built into their contract of 5% or more. This means they have budgeted increasing cost in a solution that is providing less value year after year. Don’t make the mistake of assuming that the solution is worth at least $XX dollars because that is currently what you are spending.
This brings us to the second factor in determining worth, the current market value. Assuming you took the steps of sending out an RFP to multiple vendors, you will have a fairly good sense for what the current market is for the solution you are buying. However, don’t be fooled by the initial pricing you receive in a response. Many vendors still hold on to old pricing models from years past. Sometimes this is done out of a refusal to admit their solutions have been commoditized or because many current customers would not appreciate seeing a big decrease in the list price of a solution they just signed a 5-year contract on.
The only way to really know the current market value is to be privy to the price on the contracts that have been signed. When a solution is fairly new, many vendors hold their prices or discount very little, maybe 10%. However, as the solutions become commoditized and the market becomes more saturated with competitors that have “caught up”, vendors will begin to discount more steeply, say 20-40%. Someone looking at a price on an RFP response from 2 or 3 years ago may not find much difference at all from a current RFP quote, but the difference is in what the vendor will truly sell it for. This is very important from a competitive perspective. If your costs to offer specific products or functionality to your customers are 20% higher than your competitor’s costs, you are at a disadvantage. The best way to get this information is by either finding out from the vendor’s recent customers, which can be difficult because many are your competitors, or by engaging a knowledgeable consulting firm like Catalyst Consulting Group.
Ready, Set, Go!
Once you have answered these questions and feel comfortable that everyone understands the "WHAT", "WHOM" and "WORTH", you are ready to enter the contract negotiation process. The relevant parties, methods and order of events are all important components to this next phase that we will cover next issue.
|