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.

Equally you may require that the system is scalable, able to grow with the business but does that mean handling more users, more records, less downtime for bulk processing or all of the above. Until this brief exists, there is not much point in starting the process of supplier selection.

With a clear brief based on what the software must deliver, i.e. not a specification of features; you can probably prioritise the benefits required or rank them as essential, desirable or ‘would be nice’.

Now, I would suggest you should send it out to as wide a range of potential suppliers as you like, clearly stating that they must indicate which deliverables their existing product can already demonstrably match. No time wasters please!

From the responses it will be easily possible to draw up a shortlist of candidate suppliers based on those that already have a proven product that most nearly matches the requirements that you have specified. You could even specify when you issue the brief that a less than 80% match will not be considered and that references will be taken up.

Now you can invite the chosen few to come and show how easily and quickly their product can be adapted, and at what price, to meet your specific needs not already covered by their existing specification.

As you already have a high degree of matching, the question of development should be addressed by looking at the nature of the programming of the software to see if additional features are a start from scratch or modifications.

This process should have a number of benefits. The buying process is shorter, with less wasted time by buyer and seller.

By briefing deliverables rather than features you allow for innovative responses. By seeking closest match from existing software you can widen the field of candidate suppliers and keep customising, and related costs, to a minimum.

Pilot introductions should be quicker and may allow the already proven elements of the software to be installed while customising is being carried out. Above all it is a more efficient and cost effective means of selecting a software partner rather than a supplier.

Nick Rowley is managing director of customer service specialists Oceanus .

What does a good customer look like?
Managing customer expectations with technology and common sense