Selecting Products
Top 5 Technology Selection Pitfalls
by Tony Byrne
01-Jul-2005

Buying major software applications can be stressful. The impact of your choice will reverberate across your company, and switching costs can become prohibitive. Yet, it can seem hard to know in advance whether you're picking the right solution.
CMS Watch technology reports can help you sort out the suitability of different vendors for your needs, but purchasing enterprise software and related services represents a true process. The good news is that many organizations fall victim to a predictable -- and avoidable -- set of pitfalls. Herewith are my top 5 technology selection pitfalls, along with some advice for avoiding them.
Pitfall #1: Creating a 1-dimensional selection team
The traditional divide between IT and Marketing -- or IT and "Business" -- is much discussed and famously joked about.
You probably recognize the phenomenon: Business has the budget and picks a tool without adequately consulting IT, or IT is given sole responsibility for finding the right vendor and doesn't adequately involve Business, or Business simply won't participate.
In my experience, the best software selection teams are multidisciplinary. Depending on the size of your organization, that team should include:
- System / Database Administrator
- Developer
- Enterprise Architect
- Content Contributors (ideally more than one)
- Editor
- MarCom Manager
- Sales Exec
- Finance Manager
- Librarian and/or Information Architect
- Plus other functional specialists as appropriate (e.g. HR manager for an Intranet).
Sometimes the Marketing-IT divide is overplayed. Just as frequently the real problem is that a single business unit is tasked with selecting a system for the entire enterprise, and presumes that their choice will flex for all. "If it works for us, it should work for everyone else."
This can stem from a rational desire to apply existing investments in a particular solution more broadly across the enterprise. However, if different business units did not participate in vendor selection in the first place, the chances of the solution natively meeting their needs drops precipitously.
The key word there is natively. With ample time and money you can abuse software to get it to do many things it was never intended to do. But it will be painful for all concerned. Better to involve representative business units from the start if you wish to scale a pilot project enterprise-wide.
Pitfall #2:. Becoming slaves to spreadsheets
Spreadsheets can be useful tools product selections -- as long as you employ them judiciously. Over reliance on long spreadsheets can lead you down the wrong path. This typically happens in two places -- RFPs and vendor scoring.
In RFPs, it is tempting to try to challenge vendors with long lists of desired features and attributes. Here's a secret: vendors have seen all your requirements before, and I assure you that they have very attractive answers.
One of your rows might say, "Supports the Firefox browser." Nearly every vendor will check the box. They dare not: for all they know, Firefox support could be the one key requirement that will nix them before they can even meet you! What they don't tell you is that their user interface in Firefox remains crude and barely-functioning. So keep your Excel checklists to the bare essentials (such as operating system compatibility), and if you want to see how vendors really differ, don't ask, "do you," but rather, "how do you."
The reason to keep checklist items to a bare minimum is that you want to focus on developing real scenarios that vendors can respond to and your cross-enterprise team can test in a hands-on way. James Robertson's CMS Requirements Toolkit contains a very useful discussion of scenarios. The CMS Report also has sample scenarios.
Many selection teams also use spreadsheets to determine finalists by applying weights to criteria, scoring how bidders perform, then adding up the math. Some government procurements require this type of approach. Try to be more flexible. For one thing, selection team members will emerge from the competition with favorites, and they frequently reverse-engineer the equations before entering scores to give their preferred vendor a high total. This seems sneaky, but it also signals a need to uncover and discuss why members possess "gut" instincts about particular vendors.
If you must, just use the numeric scores to arrive at 3 finalists, then talk it through, then test the top solutions again if you need more data (see next point). Give special credence to the opinions of employees who will have to use the system to complete their daily work. If they don't like it, they won't use it.
Pitfall #3: Failing to test the proposed solutions
Buying software without trying it out is frequently compared unfavorably to purchasing automobiles. "Would you buy a car without test-driving it first?"
Indeed, technology selection teams often assume they have to make a decision based on written proposals and inevitably thin, generic demos. The fear of making a bad choice with incomplete information creates tremendous stress. Buyers become suspicious, and it sets up a conflictual process from the beginning. (As Master Yoda counsels, "Fear leads to anger. Anger leads to hate. Hate leads to suffering.") If you are going to make a major investment in technology, then it behooves you to test at least two finalists against important usage scenarios for a limited amount of time, before committing to a solution.
At its best, the test phase becomes a cooperative search for understanding how a particular tool fits your environment. At its worst, it will uncover the difficulty of working with outside suppliers under the press of a deadline. In other words, it will be like a real implementation, after which you can sign a contract with much greater knowledge and confidence.
Pitfall #4: Focusing too much attention on the product -- and not enough on the vendor
Testing products is important, but typically your relationship with the winning vendor will have a greater influence on your long-term success. It is hard to quantify effective relationships, so here again a spreadsheet will fail you. Just remember that your relationship with the software sales team will drift away just as sure as rose petals in autumn, while your relationship with the vendor's services and support staff will endure year-round. Make judgments accordingly.
All companies have personalities. Software companies (and open-source projects) have strong personalities. One vendor might excel at core software engineering while the other focuses on customer-driven feature development. One vendor promotes a large and active consulting arm; another works primarily through local systems integrators. (Recognizing the increasing importance of corporate "fit" over features, we have spent more time on plumbing vendor tendencies in CMS Watch reports.) There is no ideal model -- the best vendor is the one that works best for you.
Pitfall #5: Negotiating a win-lose deal
No buyer wants to be on the losing end of the deal, and you should negotiate for a fair price. But when vendors lose, it can hurt the buyer too. This is especially the case when a buyer tries to negotiate a vendor down an entire pricing tier because they simply can't afford the vendor's entry-level fees. (Or, sometimes a short-sighted vendor sales team will troll for smaller-than-typical customers.) This puts the customer among the vendor's least profitable and hence least desirable customers, and sets up both parties for future conflict. Try to find vendors where you are an ideal customer -- not too big, but more importantly, you're not too small.
Alternatively, an aggressive salesperson can oversell with products you don't really need or aren't prepared to deploy. They win and you lose -- but in this case it is not like buying a car, because you will have an ongoing relationship with the vendor and ultimately you'll come to recognize your raw deal. While a strong vendor will work to make you whole, it can poison the relationship. Ultimately, it's your responsibility to understand what you're buying and how you're going to use it to help your business in the near term.
Good luck! Please let me know how it turns out for you.