You’ve decided your organisation needs a new technology solution. Whether it’s to help you manage events, content, people or whatever… it really doesn’t matter.
What does matter is that you need to make sure the solution you buy is a good fit for your organisation.
Traditionally, that will be done by creating a Request for Proposal (RFP). The solution supplier will then write a response, which answers all your questions, in a way that the supplier hopes will sell their solution to you.
Then you’d gather some people to review the responses, score the answers, and identify a preferred supplier. After that it’s just a matter of agreeing the terms of the contract…
It sounds simple and straightforward. The trouble is, this process really doesn’t work. At least, not as well as you might hope.
Both the supplier and the buyer organisations are working in the dark. The suppliers are making assumptions galore as they answer the questions - often without really knowing much about how your organisation ticks, and what you really need. And you, the buyer, are buying something that you’re hoping, without much evidence, will work in your particular situation.
All those assumptions and guesswork are very likely to come back to bite you during the implementation phase of your procurement project.
Many organisations are starting to adopt a more successful procurement process, known as “competitive dialogue”. It’s a way to iterate towards a solution that will work for both the buyer and the supplier.
When I help organisations to purchase technology solutions, I use my own flavour of the competitive dialogue process:
Requirements analysis
Normally I would begin this phase with a workshop to:
- identify the core functional and non-functional requirements
- prioritise those requirements, probably using the MoSCoW methodology (see: https://en.wikipedia.org/wiki/MoSCoW_method). This would help to identify what is essential for the short term, and what can come later.
- identify a set of scenarios which the suppliers will need to demonstrate during the selection process to ensure the system can model the real world requirements
RFP design
The Request for Proposal would consist of a document with the following headings:
- Current state
- Business requirements, aspirations and timescales
- Functional requirements
- Non-functional requirements (eg. accessibility, security, data protection, maintenance, support)
- Company requirements (eg. references, accreditations, financial status, project management methodology)
- Scenarios
- Cost model
- Competitive dialogue process
Long listing
Having understood the requirements, whilst writing the RFP document, now is the time to identify the suppliers to whom you will send the RFP (assuming this is allowed to be a closed tender).
Selection
A typical competitive dialogue process would be as follows:
- Stage 1: online presentation/demo (based on the scenarios provided) + Q&A
- Stage 2 (probably a week or so later): revised online presentation + Q&A
- Stage 3 (another week or so): final submission
- Stage 4: face-to-face meeting with implementation team
After each stage, the procurement team may choose to remove one or more suppliers from the list of those invited to the next stage.
Deep dive
I would normally expect any buying organisation to undertake an extensive Deep Dive into each of the invited systems that reach Stage 3. This will ensure that the decision is made based on hands-on experience.
The Deep Dive would involve spending a significant amount of time testing the system against the requirements.
Posted: 11 March 2018
Tags: Supplier selection