Software vendors love this line of thinking. Its 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 cant evaluate the success of a draft until well after the fact. Everything else is guesswork and hot air.
Most of us simply dont have the time to rethink each and every deal. Whats 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 youre like most people, you waited until the contract was up to worry about it. Im 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: Ive re-upped several times at the last minute because Ive yet to prioritize getting a better deal.
But its not a simple matter of procrastination. Theres 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 arent) or the insurance company fails to deliver on a claim (which it hasnt) how do I know whether or not Im 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 vendors 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 clients 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 doesnt 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 cant find one that works for you, propose your own.
2. Eyebrow-raising discounts - If your vendor delivers quarter-end discounts, youre happy, right? Maybe you shouldnt 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 werent 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. Its one thing if the software wont work if you make certain changes; its 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 companys 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 vendors 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 vendors 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. Its 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 dont 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 its easy to put data into a system, but nearly impossible to get it out, you should be concerned that youve been roped into a bad deal. You should worry that youll 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, its 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 its an artifact from another industry, construction, that doesnt 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 isnt build out of bricks and mortar, meaning that its 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@example.com or visit Sandstorm Media.