Software Selection–An Overview of the Tall Nails(c) Process
A video called The Vital Importance of Software Selection to the Enterprise by Gabriel Gheorghiu, available on Technology Evaluation Centers, inspired me to describe a few powerful adjustments to the RFP / Demo / Negotiate / Implement process. I have a white paper about Tall Nails© in the works, but meanwhile, I’d like to get some ideas out there.
Do your business-value homework first
It seems obvious, but it’s indeed critical to start with your own requirements. What will remove constraints on your present business processes, or enable whole new ones? Vendors will gladly help, but your “requirements” might come to resemble their product’s feature set. But will those make you money? Only you can know that, so do your homework.
Evaluate the partners at the same time as the vendors and the software
Mr. Gheorghiu makes an excellent and often-overlooked point: most software you select and purchase (license) will be installed, configured, loaded with data, perhaps customized, and put in service by one of the vendor’s partners. It’s common practice to select the vendor and software and then, weary and worn from that process, accept the vendor’s recommended partner. I suggest evaluating partners and vendors together. Unless there are critical features (Tall Nails©) lacking, I would rather have an awesome partner and the second-best software.
Focus on the Tall Nails©
I agree with Mr. Gheorghiu that demos are critical, and that you must provide a script to see what you need to see. He suggests designing the script around the high-priority requirements. I take that one step further. Design the script around those particular high-priority requirements that not every system is almost sure to satisfy—what I call the Tall Nails©.
Another good piece of advice, and I can’t remember where I heard it (thank you, whoever you are!) is focus your evaluation, especially demo scripts, on business processes, not just features. Write out scenarios. Provide your own data. Ask to see how the features work together to support that process, and be prepared to learn from the vendors and partners. They may have things that are better than you imagined! Your business-driven requirements homework will have prepared your minds to know those when you see them.
Don’t Overload the Vendors and Partners
This occurred to me when a vendor flew in four people for an early presentation of their software. I thought, “If they do this with every prospects, that’s a lot of cost-of-sales, and the people who actually buy have to cover that for all of the others who didn’t.“ It’s tempting to look at pre-sales as “free consulting.” But someone pays for it—those who actually buy their software.
It’s also tempting to make vendors jump through serious hoops during the RFP process. Tightly constrain their responses, ask everything you can think of, and give them a very short window in which to respond. You want to find out who’s hungry and responsive, right? Well, yes, but what you really want is the strongest software and best implementation, not the world-record RFP-response-writers.
By all means ask the tough questions that you need to make a good decision, but don’t make them jump through unnecessary hoops. What if the best candidate for your solution is not even in the running?
Start the Change Process at the Same Time
New software systems change processes. The payoff doesn’t come when the new software goes live. It comes when it’s in effective use, opening a new sales channel, or increasing throughput and decreasing error rates on a process that makes you money. Get the organization involved, early, in the process of change. Present the vision of a better future for the people that will benefit. Address the concerns of those whose jobs will get harder, or be eliminated, and make them whole. Even though you can’t give them details, make sure training and support know what’s coming.
I highly recommend Fearless Change by Manns and Rising.
Finally, Get Help (You Will Eventually, Regardless)
Big companies are selecting software all the time, so they have the people and the know-how (I hope you’ve gotten some good ideas all the same). But they still might need extra heads and hands to avoid skimping, and an outsider’s objectivity to help mitigate the effect of politics (personal preferences that don’t benefit the organization).
Small companies face an even greater challenge, because software selection might be something they only do every three to five years. Proportionally, the investment (and risk) might be even larger. Plus, with a smaller staff, there’s just less slack in the system to take on the extra work of developing requirements, screening vendors, setting up demos, interviewing and evaluating partners, closing the deal, and overseeing the implementation and process changes. That assumes a small organization even has the know-how on staff to do all these things, even if they had the time!
So, get help. If you don’t get help with your software selection and implementation now, you’ll wind up getting help for your stress-related illness or troubled relationships resulting from an insane project later!