Only Thought Required
March 30, 2009
Some 10 years ago, a colleague at the small consulting firm where I worked “brought over” a sample requirements document and selection process from the large consulting firm where he had worked. They were pretty bad then, hopeless now, but the amazing thing is that they’re still being used. You can find copies (authors’ names removed) on the Internet.
You all know what they look like. You use them. If you’re just buying an application or replacing an application or maybe adding an extension, you score up the candidates based on a spreadsheet, giving due weight to the quality of service, the viability of the company, the price, and, of course, a long list of functional requirements. The company with the highest score wins.
Bunk, bunk, bunk, bunk, bunk.
First of all, the process overwhelmingly favors the large companies, like SAP and Oracle, because the companies are more “viable,” and the service organization is nominally bigger.
But it isn’t that that kills me. It’s the functionality requirements. You see–and this has been true for 20 years now–most of the functionality requirements don’t matter. The only things that matter are what you might call, “Derailers,” that is, bits of functionality without which your operations are derailed.
Let me give you a couple of examples. Years ago, Avon wanted to buy SSA and did. Avon, as you probably know, sends out a circular with a list of items and prices some 15 times a year. With every circular, the price changes. So unless you could vary the prices depending on which circular you ordered from, you had nothing. SSA couldn’t, and that’s what Avon bought. They put some astronomical amount of money into “customizing” the application, but it didn’t work. The project was derailed.
With any application purchase, those derailers are what matter. Sometimes there are 5; sometimes there are 10. But unless the app you’re buying can do all of them correctly, don’t even bother to buy them.
Unfortunately, the standard way of buying apps masks this simple fact completely. Most of the time, the requirements are long, but nowhere near detailed enough. So by the time a weary group is asking a vendor to demo what matters, they rarely get down to whether the functionality actually works the way it must. At Avon, for instance, all they asked about was “price lists;” they never asked whether the price lists could be attached to a circular.
Worse, even if you figure out that the derailer doesn’t work, the weighting methods that are always used can sometimes lead you to ignore the problem. The fact that the vendor does do 6 of 7 things or 25 of 26 things or 131 of 135 things makes you ignore the fact that IT DOESN’T DO WHAT MATTERS.
What is required instead of requirements documents? Thought. All you have to do is figure out what the derailers are. Then gauge the competitors only on that.