For many organizations, a good deal is defined at the bargaining table: Did you get the price concessions you wanted? Did you get service add-ons thrown in for free? Are extra features included in the base package? Yes? Well, then it’s a good deal.
Software vendors love this line of thinking. It’s lazy and it prevents scrutiny.
Seasoned negotiators, on the other hand, evaluate deals the way scouts evaluate pro sports drafts. Despite all of the report cards papers and magazines bandied about, you can’t evaluate the success of a draft until well after the fact. Everything else is guesswork and hot air.
The same is true with software vendor contracts. Yet, even well into a contract, do you know how to evaluate whether or not you’re getting a good deal? IT contracts can be so complex that unless the software vendor is delivering an obviously shoddy product or is blatantly falling short on customer service, it’s difficult to judge the deal’s relative worth.
Most of us simply don’t have the time to rethink each and every deal. What’s done is done. Think about your personal life. How often have you thought that you were getting ripped off for mobile phone service, broadband, car insurance, etc.? What did you do?
If you’re like most people, you waited until the contract was up to worry about it. I’m no exception. I keep meaning to shop around for a better car insurance deal, but that shopping keeps getting pushed to the bottom of my to-do list. End result: I’ve re-upped several times at the last minute because I’ve yet to prioritize getting a better deal.
But it’s not a simple matter of procrastination. There’s also the fact that I may spend time looking for a better deal only to end up no better off. Unless my premiums are sky high (which they aren’t) or the insurance company fails to deliver on a claim (which it hasn’t) how do I know whether or not I’m getting a bad deal?
Of course car insurance doesn’t usually carry a multimillion dollar price tag or maintenance fee so that’s where my analogy ends. For you, here are seven symptoms of a bad deal to help you weigh the relative value of your existing contracts:
1. Limited pricing models (limited to you, that is) – Large vendors have many pricing schemes, and the sheer complexity of them makes it nearly impossible to know which is best for you.
Jonathan C. Scott, Partner at Scott & Scott, a business and technology law firm, has represented companies in financial services and insurance that were stuck with a poor pricing model. “We determined that the component parts that made up the vendor’s pricing — a combination of fixed monthly charges, add-on fees and yearly escalators — while good for the vendor, were not aligned with the way the client used those services,” Scott said.
Scott renegotiated the pricing model, better matching it to his client’s business needs. The end result was a 56% savings, or roughly an $8 million projected savings over the life of the new contract.
As you would expect, software vendors typically offer up the pricing models that guarantee them the highest revenues. That doesn’t mean you should just accept them. The best way to gain insight into pricing structures is through your peers. Otherwise, you may have to sharpen your sleuthing skills.
While most customer references given you to by the vendor will be prohibited from disclosing price specifics, you should be able to ask for details on how their pricing models work. And if you can’t find one that works for you, propose your own.
2. Eyebrow-raising discounts – If your vendor delivers quarter-end discounts, you’re happy, right? Maybe you shouldn’t be, advises Leon Thomas, CEO, Jelecos, an IT services and consulting firm based out of Omaha, NE. “The quarter-end discount is often an affirmation that you weren’t getting the best price to begin with.”
3. One-sided terms – While many one-sided terms, such as unilateral indemnification clauses, often fail to stand up in court, others like exorbitant early termination fees are nearly impossible to escape. One-sided terms should serve as a red flag, warning you that other terms in the contract may not have your best interests in mind.
4. Unsupported configuration clauses – Many software vendors structure their contracts so that any changes to their software or systems results in a loss of support and the invalidation of warranties. It’s one thing if the software won’t work if you make certain changes; it’s another if the vendor is simply trying to lock you into an expensive proprietary platform.
At Jelecos, Thomas was in the process of upgrading the company’s security systems. The vendor, however, required them to purchase new hardware even though the actual security product was software-based. “They marked the third-party hardware up and enjoyed high margins reselling another vendor’s equipment,” Thomas said.
The way around this for Jelecos was to run a pilot on Jelecos’ existing infrastructure to ensure the vendor that this configuration would meet the security vendor’s own benchmarks. It did, and Jelecos avoided purchasing unnecessary hardware.
5. Data lock/vendor lock – Piggybacking on the concept of unsupported configurations is the concept of vendor lock. It’s a common complaint in tech circles, and fighting vendor lock is one of the clarion calls of the open-source movement. Another common tech complaint focuses on data silos. Applications that don’t share information limit their value. However, a lesser-known issue is that many apps do more than form silos.
According to John Locke, founder of Freelock Computing, a provider of open-source Web development solutions for SMBs, if it’s easy to put data into a system, but nearly impossible to get it out, you should be concerned that you’ve been roped into a bad deal. You should worry that you’ll be stuck with this deal for years to come or risk losing your data.
6. Unresponsive customer service – This one practically goes without saying, but since companies routinely tout “great customer service” as a competitive advantage, whether they deliver on that promise or not, it’s important to remember the old cold-war mantra of, “Trust but verify”.
7. Vendor obsesses over requirements documents – “As a vendor, I think the way contracts have been done in IT has been messed up for quite a while,” said Locke. “The single biggest problem is a requirements document. It can be used by vendors to under-deliver, or by customers to extract unnecessary work, or by either side as a stick to beat the other.”
The major problem with the requirements document is that it’s an artifact from another industry, construction, that doesn’t translate well to IT. “Lots of software concepts and terms come from construction: hacking, builds, project management methodologies, resource management, and more,” Locke noted. However, when it comes to IT, the chore of defining requirements is often a bigger job than actually implementing them. Moreover, IT software isn’t build out of bricks and mortar, meaning that it’s much simpler to change on the fly.
The permanence of buildings and the high expense of making changes well into the project is largely why requirements documents exist in the first place and neither of those factors applies to IT.
Jeff Vance is a freelance writer and the founder of Sandstorm Media, a writing and marketing services firm focused on emerging technology trends. If you have ideas for future stories, contact him at [email protected] or visit Sandstorm Media.