I should begin by saying that this post does not reflect any experience I've had working here at UVic. But at certain other earlier and unspecified points during my career I've had the misfortune to participate in software procurement processes that can best be described by the title of this post. And the software I'm talking about here are enterprise applications that had a major impact on the working lives of many people in an organization.
Because enterprise applications have such a far-reaching impact, making the call what system to buy is not usually the province of a single person. Typically a committee is struck. This is right and fair; you need to give all the stakeholders a place at the table so they can at least have some input into the decision. This committee will draft requirements, which will then be formally written up as an RFP. Vendors will respond to the RFP; their responses will be evaluated by the committee and the winning vendor (presumably the one whose product best meets the requirements) will be awarded a contract.
So far so good. Except that evaluating enterprise software is hard. It's hard to think up all of your requirements in advance, hard to weight those requirements appropriately, hard to find a product that will meet all your requirements, and really hard to get all the stakeholders to agree that, yes, this particular product really is the best available option.
So what happens instead is that, sometimes, people try to circumvent the process. And a very common way of doing that is to look at what other, similar organizations have done in the same area and do what they did. So, for example, if you have a requirement for a system that creates blog posts without human intervention, you might look around to see what organizations similar to your own have recently implemented in that area, to kind of narrow the playing field a bit. There's nothing wrong with that, of course, it's called an environmental scan and it is in fact simply part of due diligence.
Danger arises though when the environmental scan becomes the sum total of due diligence. In other words, when one or more influential members of the selection committee start arguing that we should implement Spewmatic 3000 because [big prestigious organizations] A, B, and C implemented it, look out. The often unstated argument is that since A, B, and C have already evaluated and acquired the software, we can kind of piggyback on their work and assume the rest of the due diligence process (the messy, hard, time-consuming part) has already been done. And anyhow, they're big and prestigious, so they must know what they're doing. For obvious reasons, this is a pretty attractive assumption.
The problem with that assumption is of course that it is entirely possible that A, B, and C have also circumvented the process in the same way, by piggybacking on the decisions of [even bigger and more prestigious] organizations E and F, who in turn based their decision on [the leader in the field] G, whose senior manager had a really good lunch with the vendor's sales rep that time.
The herd instinct is strong, but we need to resist it. This isn't easy. In addition to the attraction of avoiding a lot of process, there's the safety in numbers factor: if you stick with the herd and it turns out the decision was wrong, well a lot of other people made the same mistake. You're a lot more exposed if you zig when most others zag.
But however painful it may be, organizations have a responsibility to critically evaluate the systems that they buy, and not simply base their decisions on what everyone else is doing. Bad enterprise software can have serious repercussions on organizational effectiveness, and widely implemented it can drag down a whole sector. It's not redundant effort, even if it sometimes feels like it. Effective markets depend on individual customers doing their own product analysis.
Right now I'm concerned that so many of our cognate libraries appear to be implementing vendor-hosted library management systems, without seriously thinking through the risks and problems that might result down the line, like lock-in, escalating costs, and eventual stagnation. I don't think nearly enough discussion of the potential negatives is happening in our professional literature or anywhere else. This concerns me; if we're going to jump off that particular cliff, we should at least be jumping with our eyes open.