I’ve been involved in software selection for 18 years, both as a buyer and as a consultant helping buyers find the right product for their needs. I’ve seen CIOs make snap decisions with little to no process, and RFPs that go on forever with no decision ever being made. I’ve seen organizations get tremendous value from their software platform, as well as organizations that spend millions of dollars and never end up using it.
And while the many intangible factors in any software buying decision makes it difficult to generalize about what makes the optimal software selection at any organization, there are some things to do and some to avoid that, in general, give you a higher likelihood of getting value from the software you eventually purchase.
Know Your Information Source
An overwhelming volume of information is available today about software products and the needs they answer (e.g., end-point protection, workflow, document management, etc.) — too much information, really. It’s easy to get lost in the dozens or even hundreds of data sources you can find when selecting software.
Step one in cutting through the noise is to understand the kinds of sources that provide data on software products.
- The vendors themselves — Information about product lines and their stated capabilities and functionality. Take with a grain of salt: this will rarely give you the real deal about what the software can and can’t do.
- Forrester and Gartner — Useful only for understanding the high-level corporate vision of a software vendor and their overall corporate financial soundness. Good for buying stock, not useful for selecting software unless you literally know nothing about the main players in a domain and need to get a list of folks to reach out to.
- Other analysts — These fall into two camps: those who are pure analysts and do nothing else and those that do delivery work and also are analysts. The latter can provide a good view into what’s happening on the ground with a given software vendor or domain.
- Your peers — The gold standard. Hearing what others in your shoes have experienced is the single most valuable data point you can have when selecting software.
Related Article: 'The Right Way to Select Technology': A Resource for Years to Come
Whether you believe that software companies are well meaning and try their best to deliver what they promise or that they’re snake oil salesmen who will say whatever they have to to get a deal, it’s wise to be skeptical of their claims, because even the best laid plans for a product can go wrong. And whether you believe a given analyst is preaching the gospel truth or is a paid shill for this or that software company, you are the one who will ultimately purchase the software and have to get value — and whatever so and so said will be irrelevant.
My firm, Doculabs’ advice is to take every statement from a software vendor or analyst firm (including us) and assume the worst: maybe not that it’s 100 percent wrong, but that it’s only 33 percent correct. How does that change the decision you’re making? What risks are now on the table and how would you mitigate them?
If it turns out you were wrong and the claims, advice, insights, etc. were correct, no harm, no foul. But if your skepticism is well founded, you’ll be eyes wide open and in a better position to succeed despite it.
Skip the RFP
Let’s just come right out and say it: RFPs are a terrible way to select a vendor of anything, and software is no exception. Here’s why: typically, they’re nothing more than a kitchen sink list of features and functionality (which vendors always answer “yes” to), a series of time consuming demos with a 2:1 ratio of sales people to clients, spouting on about marketechture followed by a demo of boilerplate capabilities. At the end of which, you pick a “winner” and only then really get to know what they can and can’t deliver — at which point, it’s too late to change course.
My company has helped clients with hundreds of RFPs (and I’ve been involved in a few dozen) and the result is nearly always less optimal than it could have been. We’ll turn to some ways to make the RFP process more effective, but my colleague Tom Roberts shares some good advice here.
If You Go for the RFP, At Least Ask 'How?'
Most RFPs have a long Excel spreadsheet with questions about what the software can deliver with responses that range between yes or no. As I mentioned earlier, I’ve yet to see a software vendor answer “no” to anything. Of course they'll say they can do it. One quick win to improve the process is to add two columns: one for “how," i.e., out of the box, configuration, custom code, third party solution, etc.; and one for “how often have you delivered this,” i.e., we theoretically can do it, we have done it some, we do it all the time.
It seems simple and obvious, but the RFPs I’ve seen where this is part of the evaluation tend to result in better decision-making — hard to fudge an answer about capabilities when you have to get specific.
Another RFP Tip: Add Usage Scenarios
In addition to asking for clarification on how a software vendor delivers a capability (and how often they’ve done it), framing your requirements around usage scenarios (rather than a laundry list of functionality) is very effective.
For example, if you’re looking for software to store documents related to the vendor management ERP module you own, lay out the key processes your end users do day to day that the solution would support. For example, receiving an invoice, checking it against a purchase order/master services agreement, and then either paying or going back to the vendor for more information/clarification. Doesn’t have to be a Six Sigma, LEAN process mapping exercise, but more at the standard operating procedure level: what are the steps they need to do to do their job?
Then, instead of answers to a set of high level yes/no functionality questions, you will have your vendors 1) affirm they can support this scenario and 2) show how they do so in a demo if they reach that point in the selection process. And while their demo to address the scenario won’t be ready for prime time if you buy them, you’ll have a really good idea how close they can get before you make your decision.
Related Article: Selecting a Search Vendor: Crafting a Request for Information
Evaluate How They Sell
There's a saying "how you sell is how you solve." It’s true: how a firm treats you during the sales process is an accurate indicator of how well they’ll deliver for you if you hire them. Or put another way, you will never be treated better than when they’re trying to sell you. So if you’re uncertain about them as a firm or about how you’re being treated before you sign on the dotted line, pause — because it’s downhill from here, my friend.
Having said that, pay attention to how they interact with you and comport themselves during the sales process. Some red flags:
- More sales people than customers in a meeting.
- Sales team members on their phones or doing other work in the meetings.
- Inability to go “off book” and deviate from their slides or agenda to make the meeting valuable.
- High-pressure sales tactics (e.g., pushing for an end of quarter signature with deep discounts that expire if you don’t sign).
I’m not naïve, I get it: software firms are often publicly traded and have made promises to Wall Street about performance, but ultimately, if that’s their North Star and they’re willing to sour the relationship to stick to it, you need to think long and hard about whether they’re a good partner or not.
Don’t Let Perfect Be the Enemy of Good
Anyone who’s been in corporate IT for any length of time will tell you, a “B-" software product implemented “A+” is better than an “A+” software product implemented in a “B-" fashion. Yet, all too often we forget this and look for the software product that will meet 100 percent of our needs.
Here's the truth: no software meets 100 percent of our needs. I always say, software will — in the best case — meet 75 percent of your needs. So flip the script and think about what 25 percent of missed needs can you live with? That’s the real test of a fit for purpose software product. And if that means you get less than what was your ultimate list of requirements, but you get stuff done, that’s better than dragging the decision out over 12 months, 18 months — or never making it at all.
It Will Never Be a Perfect Process
As I said at the top, every organization is different and every software decision is, of course, unique. But hopefully the advice I’ve given here helps you think about how you could do things better the next time you have to select software and helps your organization realize more value for the time and money they spend.