The beauty parade works a bit like the process for getting a new terminal at Heathrow. You start with an identified need: more capacity, new software or new advertising strategy. You invite the “usual suspects” (current suppliers) and few others that you have heard of from colleagues or the media.
They come and do a credentials presentation on why they are the best people for the job. The field is narrowed and a specification issued to which they respond with their solution and an estimate of cost.
From here on it is downhill all the way. The proposals are not truly comparable and raise further questions, so there are a lot of debates and committee meetings, followed by a compromise selection.
The design work is done, then piloted. At this point, so much time has passed that the pilot shows that the original brief is no longer entirely valid, technology has evolved with more options available and the budget is no longer viable. More debate and committee meetings ensue and a new compromise between features and costs is agreed.
The project is delivered with or without the usual delays and cost overruns, is finally commissioned (hopefully successfully) and becomes operational – all too often just in time to start the whole process again.
Whether selecting software, an advertising agency or building a new terminal, we would all like to feel that we have examined all the options, from every angle and eventually chosen the best solution to suit our needs at the most competitive price.
In practice the ‘beauty parade’ approach often creates so much confusion that we stay with the supplier or brand with which we are familiar or lengthens the selection process to such a degree that the solution is no longer relevant because the requirement and/or the technology has evolved. We need to be better buyers with a better process for achieving what we want. So, if not the beauty parade, then what?
The process starts with identifying the need, and for the IT department deciding that the solution is software. It seems logical that the next step should be to draw up a brief.
Any marketing guru will tell you that what sells is ‘benefits’, what the product will do, rather than features; thus will not rust rather than stainless steel construction. A brief should work in the same way; what are you looking for the system to do, what problems should it solve – what benefits do you expect the new software to deliver?
By definition the brief should avoid generalisations on required features. Stating that it must have a ‘search engine’ is an easy box for the supplier to tick but if you really want information retrieval on spare parts quickly narrowed down by make, model, year of purchase and other parameters, then what you need is a particular type of information retrieval system.