Decisions of this type should not be made lightly; you could end up regretting them for a very long time.
If your organisation already has well defined internal procurement procedures and guidelines you will already have a roadmap of the necessary steps to ensure you make a considered, fair and effective decision. If you work for a small organisation, where such procedures are not often well defined then read on...
Software selection and procurement can be a tricky process. You need to be clear on the needs of your organisation and on the best way to achieve them. A crystal ball to enable future-proofing would also help, but until such devices are available, you need to ensure you use a selection process which will enable you to make the best decision with the time and resources available to you.
It is important that you have the collective backing of business representatives who are able to make effective and considered decisions on organisational priorities and it's important that you have a process which enables you to consider and compare products in a consistent way. All the activities of the software selection process then need to be documented to provide an ongoing record of the decisions made and the underlying reasoning.
Here is a simple guide, consisting of seven steps which should help you to make a considered and robust decision that will result in the selection of the best possible software product for your organisation:
Step 1: Set up a product selection committee
Membership of the product selection committee (PSC) should ensure representation from every stakeholder, firstly to ensure that all requirements are considered, and secondly to ensure that the process is unbiased, considered and fair.
If any stakeholder is reluctant to join the group, ensure you outline the implications of them not being involved: they will not have a say in the product selection process. This could result in a purchase which does not meet their needs, and ultimately could impact their area of the business.
Step 2: Verify / validate and sign-off the requirements specification
The first task of the PSC should be to verify the requirements specification document(s), which will usually include both functional and non-functional aspects of the system. This process could take various forms depending on the degree to which the requirements have already been elicited in order to produce the business case.
At a minimum a workshop should be arranged to walk through and confirm widespread understanding of the requirements and their resulting implications. Ensure all committee members are aware that they will be expected to sign-off the requirements at the end of this stage; this tends to focus the minds of the group members and encourages them to ensure that they have considered all their needs.
Step 3: Market survey; seeing what's out there
It is important that you are aware of the availability of the type of software product you intend to purchase. The industry is plagued with different meanings for the same term. If you've ever attempted to purchase a 'workflow' system you will be aware of the many varying interpretations of the word.
The best way to gain market knowledge is to get out an about and see what is available. Speak to contacts in other organisations, go to software conferences / exhibitions, search the internet, read industry journals. The right suppliers are unlikely to come to you by chance (have you ever received a well-timed sales call?) so make sure you have the best chance possible to meet potential suppliers.
Sometimes it's possible to obtain details of market leaders in industry sectors via official customer communities, for example local authorities openly share information about the software suppliers they are using.
Don't make too many distinctions on price at this stage. It will soon become clear which suppliers are potentially out of your range, this should be evident in the degree of functionality provided and your resulting assessment (see step 4).
As an outcome of this stage you should have a shortlist of suppliers which you feel are potentially worth considering. Establish a point of contact at each and have an initial discussion with them regarding your needs.
Send them a copy of your requirements documents (you may need to reword the document for external audiences) and ask them to provide informal feedback. I have found that this informal process can be useful for refining any terminology on the requirement documents to align with industry standards and to ensure consistent understanding across suppliers.
Step 4: Invitation to tender; formal assessment of the market
Provide a copy of the requirements specification to all potential suppliers. Be very clear on how you want them to respond. You should try to evaluate their response on a quantifiable scale, so design your invitation around this.
Be clear about which of your requirements are essential and which are 'nice to haves' and agree these priorities with the PSC. Add an appropriate weighting to each of the requirements (a scale of 1 to 4 is usually sufficient) and design a response assessment document in advance to ensure you have a set of processes which will encourage robust and consistent comparison.
Make sure you include factors in your scoring documents which highlight the softer characteristics of the suppliers in terms of their size, the number of employees, and their annual turnover.
These factors are important when you come to consider degrees of risk. A supplier may have the best product you could ever imagine, but if it only has four employees and has only been trading for six months the risk in terms of staff turnover and organisational stability is greater than that for a larger, more established organisation.
It will be clear from the supplier responses which ones truly aimed to understand and meet your needs, and which provided a standard response document. It's a good sign if an organisation makes contact to verify their understanding of your tender. It suggests they are thorough and keen to engage.
In summary: your evaluation of your suppliers should include a score sheet of functionality in response to your requirements documents; an assessment of the supplier and details of pricing. Beware of supplier responses which include a high degree of additional enhancements necessary to make to their product meet your requirements.
Remember that (usually) the reason you have opted to go for an off-the-shelf software product is because you want to benefit from an established product and reduce the risk of bespoke development.
All these factors should allow you to come up with a shortlist of potential suppliers which should be formally agreed with the PSC. Ensure there is open access the original responses from the suppliers to ensure transparency in the decision making process.
Step 5: Product demonstration; seeing is believing
Depending on the scale of the purchase, you are likely to want to see a demonstration of the product. All PSC members should be present and have defined roles when reviewing the various offerings. These should be based on specialisms and expertise, for example some could focus on the details of the supplier and prepare for questions which arose from the tender response.
Those of a technical background could focus on the system architecture and the implementation considerations. Ensure the PSC works effectively as a unit, using its skills and knowledge effectively to evaluate all aspects of a supplier's offering, as well as the supplier itself.
It’s important that each supplier is given the opportunity to demonstrate their product in a fair and consistent manner. I have seen many product demonstrations where a supplier seems to be able to win the audience over by demonstrating functionality which is not in the requirements specification.
It is important to ensure that your short-listed suppliers keep to the defined system features and that demonstration time is used effectively. A good way to approach this is to set them a task. Highlight areas of your requirements which you would like to see in the demonstration and provide a set of fictitious scenarios.
For example, assume you were purchasing a workflow system; you may want to provide examples of different types of business process; perhaps a form which needs to be completed by a user and then passed to a group of users for approval. Give the supplier enough information to ensure understanding of the example but try not to stifle creativity – outline the 'what', not the 'how'.
It is likely that the suppliers will approach the example in very different ways which will give insight into the experience of the supplier, how well the product is designed and how well established the functionality is.
It allows you to engage with the suppliers on a shared problem and will also allow you to get a first impression of what they would be like to work with. An established provider will be able to give examples of how such processes tend to work in the wider world outside of your organisation, highlighting experience they have gained from existing customers.
Ensure you consider the time put aside for the demonstration. For example if you allowed for a 90 minute presentation you may split it as follows:-
15 minutes for introduction to the supplier organisation
30 minutes general demo of the product
30 minutes on example scenario(s)
15 minutes for questions
Make the suppliers aware of the timings in advance. This will allow them to prepare effectively. If they begin to overrun make them aware and try to bring them back on track.
There is never unlimited time to make a decision; suppliers have to ensure they are able to demonstrate their system to you in an effective way in the time given. If you are clear and concise on how you want the demo to operate you will find it easier to compare the products in your assessment.
Never underestimate the potency of a well designed visual interface. Non-technical audiences often assume that visual elegance implies a well designed product under the bonnet. This is not necessarily the case.
The IT specialists in the PSC should be aware of this and advise accordingly. Your balanced evaluation of the product should obviously include consideration of any user interfaces, which will be backed-up with checks and measures on the underlying technology.
Step 6: Product selection, decision time
Having seen all the products short-listed, and assuming the PSC feel they have seen enough suitable suppliers to make a reasoned selection, it's time to decide which one to go for. Insist on evidence for the decision.
Your scoring document(s) from step four form the bases of further consideration during the product demonstration. Now you have seen the product and had a chance ask questions, revisit the scoring document and make (versioned) amendments as necessary. The PSC should then reconsider the documents and confirm the outcome presented.
This is likely to lead (hopefully) to lively discussion, where committee members will share their impressions of a product and often those presenting them. Beware of group influence. If you are in a position to chair the PSC, identify the influential members of the group and try to ensure they are not always the first to give their opinion.
Try to ensure everyone has a say; I find the best way to do this is to have a 20 minute session after each demonstration where each member of the committee talks to the rest of the group about their impressions before they have had their chance to discus it collectively.
Step 7: Building confidence: ensure all is as it seems
You wouldn't employee a member of staff without seeking references, would you? It's amazing how many purchases are made without talking to the supplier's existing customers first. The process of seeking references will (as with every step) vary according to the scale of your purchase.
Ask your chosen supplier to provide a list of at least 25 per cent of their customers. You may need to negotiate on this. Be aware that not all existing customers will agree to be reference sites, for various reasons.
You should insist on being provided with a set of reference sites for you to select from, rather than allowing the chosen supplier to select them and set them up for you. This ensures you are able to select the most appropriate customers and elements any element of bias.
The following-up of the reference can take any number of forms, at the simplest level it could be a telephone call, at the most thorough a visit to their site. Regardless of the method, ensure you go prepared with both closed and open questions derived from your scoring documents.
As mentioned earlier, one of the biggest fears when making a software purchase is the stability of the supplier. A useful way to gain insight into the financial stability of an organisation is to perform a Company House check which will provide access to the public accounts for (at a minimum) the last reporting period.
Such documents are not necessary particularly readable for the layman so it would be wise to engage the services of an accountant. They will be able to give you insight into the overall profitability and stability of the organisation.
If any part of this process raises questions you should take them back to the supplier and ask them to elaborate. Do not use profitability as a sole indicator of stability, an organisation undergoing long-term growth may not be profitable in the short -term.
Assuming your references and financial checks have not highlighted any areas of concern, you should now have sufficient confidence to proceed with your purchase.
You should now have a complete set of records highlighting the requirements, the company profiles, the response documents, scoring documents and references; you are ready to present your findings to your internal purchasing authority in the knowledge that you have considered the market, consulted effectively with the business, and verified the performance of the provider.
Dean Burnell MBCS CITP is an independent IT writer.
