I had an interesting conversation over a few beers with a technology vendor at ELAG2013; the at times animated and amusing conversation was fun and I appreciate people spending their time on explaining things to me. What surprised me was the way the conversation quickly turned to the vendor-customer relationship, and more specifically how vendors expect customers to behave in this relationship. I don’t say that this is typical, but I rather suspect that vendors generally do have similar views at a general level.
The vendor explicitly stated that they expected customers to provide product input in order to build a product that will work for the user. The vendor expected a level of input that required technical expertise in software systems architecture and general programming concepts, even to the level that they would expect direct input into how the system should actually work (not just behave, but work).
There are two ways of viewing this, which I will exemplify by analogy:
- Firstly, you’re in the market for a new car, and the vendor asks you what car you want.
- The secondly, you are an airline company in the market for a fleet of new planes, the vendor asks what kind of plane you want.
If you’re in the market for a car, you specify things like:
- space for three adults/child car seats in the back
- lots of space in the boot/trunk
- reasonably powerful engine
- low emissions
If you’re in the market for a fleet of planes, you specify things like:
- emissions levels according to regulations
- compliance to standards
- physical tolerances
- standard seating arrangements
- passenger/fuel economy
Note that while they are similar specifications, they are quite different in quality, and that while you can buy consumer end software in the same way as a car, you will struggle to buy any “enterprise” system like that.
Consider situations where so-called off-the-shelf systems are acquired: it is only in exceptional circumstances that these systems initially respond to expectation, in the majority of cases they need bodging to get them to work. Note that by bodging, I mean actually changes to the implementation and the daft stuff end users need to do in order to get the system to even grudgingly enter their workflows. Another matter is how these systems perform in their lifecycle…
In general, software vendors have very much moved away from the concept of off-the-shelf and towards *aaS (X as a service), which entails that the customer knows what they’re doing in general, and not just what they want to get done. On the other side, the benefits of this open development approach can be huge. But, the details of the specification are of immense importance. In order for software acquisition to function properly in an *aaS reality, we need to see competent technical leaders empowered not to do people management, but to acquire the systems for use in your institution.
On the whole, I don’t believe that many sectors are up to this, and the library sector is indeed not unique here, because typically the person sitting in the meetings for the customer side has been the person with the mandate to purchase, whereas this is rarely given to a person able to spec and understand a spec adequately.
Without providing technical leads with the opportunity to follow the specification at a contractual level, vendors are doomed to sell products to customers who just don’t understand why they don’t match up to expectations. Both parties need to be represented not by the traditional salesperson-manager constellation, but by experts within the domain of the product.