Product Selection – a wonderful opportunity to get it wrong

One of the things that I find fascinating is the strange way that most companies set about selecting a product. I admit that the overblown selection procedures of the consultancy heydays in the 80s were over kill but the scant regard given to this process today is bordering on the criminal.

One of my friends has been engaged in the selection and installation of an asset and IT inventory management solution for a major company in the UK for most of the last year. The inability of the enterprise to do this vital activity in anything like a satisfactory fashion has now led him to resign and look for work elsewhere.

Their first reaction was to tell him to use a product which they got for free as a consequence of buying some other monitoring software. It took them some three months to identify why it was free, it basically was inadequate for the job. All attempts to then get a proper project established with requirements and constraints identified up front was objected to for a further period before some of the major suppliers such as Microsoft and Oracle starting to point out that they had major concerns about the ability of this company to securely manage the assets provided to them. But even then the solution which was proposed by most senior managers and the architects was very low key for such a serious subject, being the use of some form of detection agent feeding an Access database.

Another team that I have worked with were looking at the problem of scheduling resources in the face of the conflicting demands being placed on IT by a fast growing business when the need for cost control meant that additional resource was not going to be readily available. Although the process started off correctly with workshops being held to identify the elements of the process that needed to be understood and the product mapped to, management were soon having product demos and completely ignoring understanding their own requirements whilst being dazzled by the functions of the third party’s solution.

What this shows is that software selection remains a dark art, which is often not understood by those charged with the task. Although products available today are generally very capable it is also true that in a heavily commoditised market products are developed with different slants and that unless time is taken to understand your own processes and therefore your own needs it is very possible to find yourself buying a product which although generally excellent you will find difficult to use and less than optimal in providing the expected business benefits.

The process for making a sensible selection of software is not unduly onerous. You have to understand what you want it to do, you need to understand which of your business processes will need to interface with the software and therefore drive the selection at a functional level. You have to be able to understand your technical constraints and look for products which will meet them.

Just as with bespoke projects where I feel that there are major problems because we fail to initiate projects correctly, so with commercial off the shelf software—it is the up front activities that we tend to get wrong. We are so determined to get a quick win that we rush when we should be fast and precise and we make mistakes which could be avoided with a little more care.