The selection of business software is a fairly involved procedure. Unlike many tangible items an organization might procure (office equipment, machinery, vehicles etc.), software is largely intangible and the suppliers have a great advantage – they know what their technology can do, whereas you do not. This takes the form of an exaggerated information asymmetry, and the failure rates of many business software projects bears testament to the difficulties involved.
As if this was not bad enough most businesses are riddled with politics and barely disguised self-interest. It is not uncommon for a particular technology and supplier to be selected simply to enhance a career. The most extreme example of this is a side agreement between a supplier and an internal sponsor.
In many organizations these difficulties are side-lined by simply selecting a market leader. The reasoning is simple enough – the crowd tends to get it right, and so follow the crowd. This may be true in some areas of life (although I can’t think of any), but it certainly isn’t true where software is concerned. Most large software suppliers spend the vast majority of their revenue on sales and marketing – typically between 60% and 70% – and maybe more. The suppliers who tend to succeed are those who spend most, and are most adept at marketing – not those with the best technology or most experience.
Before embarking on the selection process it is really very important to establish whether an impartial effort can be made. Here are the questions you need to ask:
- Why is the technology needed? Is there a real need or is this simply participation in a technology fashion?
- Who is pushing for the technology and why?
- Who is involved in the selection? Are both business and technical people involved?
- Has a high level sponsor already decided on a supplier, and using the selection process simply as a means of legitimising a bias?
If it is clear that the selection process is already biased then it might not be possible to go through a rational selection process, and such an exercise will probably be futile. What follows in this article will be irrelevant.
Requirements – Known and Unknown
The first thing to do is obviously establish what is required of a software system. It sounds simple enough, but in reality it is far from straightforward. Different people will have different and possibly conflicting requirements, and so they need to be prioritized by someone who is not emotionally tangled up in the process. For many organizations the process is half done once a list of requirements is drawn up. The other half of the process is speaking with suppliers on the capabilities of their technology. Unfortunately suppliers tend to exaggerate and even tell downright lies (most technology suppliers are constantly engaged in litigation where customers feel they have been misled – the customer rarely wins because suppliers are very good at small print – so read the small print).
If this is the process in your organization then I have to tell you it is woefully inadequate. Here is why. Even if it were possible to get people to say what they actually need, rather than what they believe they need, no one can predict the future and so what might be needed in six months down the track is largely unknown. A merger or acquisition, a new line of business, new management and so on will undoubtedly change what you need from a software system. This is why the most important feature of software is not what it can do, but how it can be extended to do new things – extensibility. This manifests in many ways – the ability to connect with other systems, to create new functionality, to scale to accommodate growth – and so on. Some software systems are very open in this respect, others are closed, and deliberately so. Most suppliers of proprietary technology want to generate revenue from new features, and so they don’t want users building it for themselves or scaling out to accommodate greater workloads.
So the key message here is the need to create a balance between satisfying immediate needs (if they can indeed be actually established) and selecting software that will grow as the organization changes and grows. Unless this is done it is likely that an organization will select software that, as the saying goes, will leave the organization up a creek without a paddle, in fairly short order. The supplier will then want to charge for paddles.