According to information technology research firm Gartner, between 50 and 75 percent of IT projects fail. We've written a number of
articles offering guidance for achieving better outcomes through the solution selection and implementation processes, but there is one trap we haven't addressed—and we see clients succumb to it all the time.
Price Clouds Everything
Consider the Canadian government's recent Phoenix payroll software debacle. They elected to have a payroll system custom developed by IBM and have had nothing but problems with it. According to one assessment:
"... the Harper government put so much emphasis on saving money that it undermined efforts to ensure that the system would function well...instead of saving the government 70 million Canadian dollars this year, as promised,
Phoenix has cost the government an extra $50 million (about USD$ 37 million),
including $6 million in additional fees paid to IBM to fix it."
When participating in an IT system evaluation, if you find your team leaning toward the low-cost choice instead of the high-value solution, beware. No one wants to pay more for something than they need to. In government in particular, you may even have the obligation to choose the low-cost solution. This default preference/requirement is understood by IT solutions sales representatives and is often relied upon to accelerate the sales cycle and "close the deal." Even if you're not being exploited by sales teams, the Phoenix case shows how this low-cost bias can lead to dysfunction. Here are two questions to ask yourself to avoid a bad deal when considering the "cheap" IT solution:
1) Is it truly cheaper?
In one respect it is obvious; if the number at the bottom of the RFP response or quote is lower, then it's the less expensive option. While technically true, that is only a valuable assessment if you are comparing apples to apples. Before you look at the price, you need to know whether you'd be getting the same thing for the money.
With an intangible product like software, it can be difficult to ensure you're making an apples-to-apples comparison. If you bought the Chevette above based solely on the price, you could be stuck with the wrong car if acceleration and top speed are necessary features. Alternatively, you might decide you do not need a Corvette, that a Chevette will do. The point is, they have different features and capabilities, and comparing the two options based solely on price obscures those differences.
2) Why is it cheaper?
There's no such thing as a free lunch.
- Milton Friedman
You've assessed the options based on fit. Then you calculated ROI. The cheaper solution comes out on top. What now?
RECOMMENDATION: Treat the low-cost solution with extreme suspicion. This is your warning sign to bolster your due diligence. We recently watched one "low-cost" vendor in the reporting automation industry cease operations and advise their existing clients that they are on their own. For some of these folks, this happened while they were implementing the software.
The Action Plan: 7 Steps to Better Due Diligence
- Double-check fit-assessment. If you have any doubt, have the low-cost vendors re-demo the product to confirm it meets your needs.
- Double-check standard pricing variables:
- Modules/features
- Number of users
- Number of people being trained
- Duration and extent of support period
These are all variables that might account for significantly reduced cost. Remember, you want to compare apples to apples. Also, recall that skimping here may cause cost overruns later when you determine you did need more training or support.
- Assess the vendor track record. How many clients do they have? How many times have they solved the problem(s) you have? Ask about failed implementations and what caused them to fail. Be suspicious of anyone who says they don't have any.
- Closely assess their implementation team. Does the vendor have in-depth knowledge of not only the tool but your business process? Have they been "on your side of the table"? Have they been an HR manager or comptroller or auditor or finance officer and done the tasks that their tool addresses?
- Contact numerous clients that are currently using their product. Spot check the specific features you are counting on using to see if the reference is using them. We have seen vendors provide references that did not even use the product being evaluated! If the vendor can not provide an extensive list of clients who use the product, or they do not have extensive experience solving your exact issue, determine whether your organization is prepared to be a guinea pig. We have seen numerous organizations stuck in limbo for years while their vendor tries to build what was promised.
- Go back to the expensive vendor(s) and ask why they are so expensive. Do they charge a premium because on their brand? Did they consider something the others didn't? Was there an error in one of the pricing variables (point 2 above)?
- Assess the low-cost vendor's stability. One way to do this is to consider their financial health, if possible.
- If the company is publicly traded, have they ever shown a profit? Do their financial statements look like those of a stable, successful company? If the vendor provides their software as a service (SAAS), there may be other considerations for evaluating performance. You can find some interesting articles on SAAS performance here and here.
- If the company is not publicly traded, it can be hard to perform this analysis, and you may need to rely more heavily on steps 1–6 above.
It's a good idea to follow these steps even when there is no major pricing disparity. They become absolutely essential when you're presented with what seems like a sweetheart deal, and you want to avoid the cheap solution trap.