When organisations follow their corporate strategy, they may wish to develop a capability that they don't have at present. This capability could be grown organically, or it can be acquired. Acquisition could be achieved by buying another company which already has this business value stream, or by purchasing a best-in-class product or solution which is then integrated into the current operation and run by the company's own staff.
Sometimes, the desire to achieve a particular business outcome requires lateral thought and an investigation of the 'art of the possible'. Knowing what options are available will inform further exploration, and may well result in one or more tranches of work to explore viability and potential. As clarity emerges, the requirement becomes firmer, and action may be taken towards selecting the right partners and executing on the strategy.
Three steps are key to this process - the RFI or request for information, the RFP or request for proposal and the RFQ or request for quote (also known as an ITT - invitation to treat).
Request for Information
An RFI is a preliminary document to get general information from potential vendors. It is often produced as a result of a Market Sweep, an exercise to confirm likely vendor categories (for example Banking Platform or Call Centre Management or Advertising Management) and to confirm that the current roster of vendors actually lists a reasonable set of companies who are thought to have a plausible product or service in this space.
In order to inform the Market Sweep and the RFI, it is good practice for the project team to first produce a trinity of high-level documents which confirm the business need: High-Level Requirements, High-Level Business Context & High-Level Technology Context. Requirements are captured from diverse sources and formally documented, categorised and prioritised. The high-level business model and architecture is used to guide the project team as to the commercial intent and to brief stakeholders. The high-level technology model and architecture sets out the current and target systems, integrations and infrastructure needed to visualise how data flows internally and externally, and is used to identify the legacy and new systems which may be part of the solution.
The RFI will typically state the business’ general challenges and give vendors the opportunity to explain their offerings with a broad scope. RFIs are fact-finding documents which ask open-ended questions to allow the vendor set to fully explain their offerings. Finally the RFI will ask the prospective vendor to confirm that they would like to take part in any future RFP step, if selected and at their own cost.
Each RFI response may set out how a particular vendor would fulfil a need or solve a problem. This often includes explaining their position in the marketplace, how they license their product or services, and what costs should be expected from their services. RFI responses are often the result of an initial contact with potential suppliers and are not a promise of future business. Nevertheless each vendor is expected to commit to participation at their own risk.
An RFI response evaluation will summarise all the replies. Given the open nature of the inquiry at this stage, this summary document will be flexible in structure. Nevertheless it will indicate vendor suitability to be taken forward to the RFP stage on broad criteria and a simple yes/no decision.
It is possible that the RFI process does not yield a satisfactory long-list of possible vendors or partners, or that the 'art of the possible' requires further investigation. In either of these cases it is acceptable to take time-out to pursue the answers needed and then repeat some or all of the RFI process.
Request for Proposal
An RFP is a document that a company sends to vendors on the long list, to get an overview of offerings and costs for a specific service.
In order to be able to evaluate responses from competing vendors, it is essential that the RFP is set out in a structured manner and that the vendors are given clear instruction on how to respond, and in what format.
It is good practice to create the evaluation process, the question weightings and a suitable scoring mechanism before the RFP is finalised and sent out. That way the evaluation can be dry-run with dummy data and any tweaks to the response format can be made before publication.
The main content of the RFP is a set of questions, based on the major functional and non-functional requirements. The questions should be a levelled set, grouped for easier evaluation, and invite a quantitative response, with space for a qualitative explanation. The vendors' ability to answer these questions is key to their progression to the next stage.
Potential vendors should be asked questions such as
- What steps will you take to control costs during this process?
- What risks can you foresee in this project?
- What steps will you take to be regulatory compliant?
- What will your approach to implementation be?
The RFP document should also include sections for response on company size, turnover, clients, ultimate ownership, and explain the response requirement, including format and time to respond. The vendor should again be asked to confirm that they are willing to participate in the process at their own cost. Vendors will also want to know future steps in the process and when they will be able to book sales revenue if they win.
The RFP is sent to agreed contact points within each organisation. Check that the RFP has been received and confirm the ability of each vendor to respond within timescale.
It is normal to allow 48 hours after receipt for the vendors to submit questions of clarification, with the answers copied to all recipients.
Then wait for the responses to come back. It may seem like a good idea to get the RFP out in the week before Christmas, so that the responses are on your desk in the first week of January, or the week before that particular Industry's Annual Conference, but you may find that what is returned is a more cursory response than you were hoping for. Better to pick a time - if you can - when the vendors can give your response their full attention.
Whilst waiting for the vendors to respond, if not already done, now is the time to create an RFP Evaluation Procedure Guide for internal use, and to confirm the internal response evaluators' diary sessions.
Response Evaluation
On the appointed day, the RFP Responses come back. If a specific cut-off time has been set then it should be adhered to.
Formally log each artefact received, and confirm receipt of responses from each Vendor.
Allocate the material received to the appropriate member of the review team to read and score, and then pass on.
As each reviewer is ready, collate their feedback and scores. If reviewers have unplanned business-as-usual work thrust upon them, then it can be helpful to intercede on their behalf.
Record and weight the scores on the master spreadsheet.
When all of the feedback and scores have been captured, then it is good practice to hold a Levelling Meeting to ensure consistency of understanding across all the review team members. If necessary, team members may adjust their scores, based on new understanding. By extension, it may become apparent that a particular question or group of questions should have its weighting increased or decreased. Any decision of this nature should be minuted to provide an audit trail.
The same meeting may continue to sit to identify any material weakness in a particular response. Optionally, and depending on the agreed process, it may be sensible to offer that vendor the option to correct their submission. Again, any decision of this nature should be minuted to provide an audit trail.
After discussion, the individual evaluators' scores and any adjustments are fed back into the evaluation model and the vendors are ranked, based on score, and, separately, on cost.
This final ranking is sense checked and then a qualitative summary of the responses is prepared which presents the findings, in context and with supporting commentary.
At this point the relevant Steering Group or the Execs are made aware of the conclusions to date, and the proposal to downselect the long list to a preferred vendor is made. The solution may require more than one vendor, but each is chosen for their separate capability.
Downselection
Now that a clear view of the capabilities of different vendors exists with regard to the high-level requirements, the next step is to downselect to a minimum set of vendors so that a Proof of Concept may be performed and commercial negotiation may begin.
To get to that minimum set, if they are not immediately apparent from the RFP scoring and ranking process, then there may first be a shortlist of candidates to whom further questions will be asked, and those responses validated.
At this stage it may be appropriate to undertake a site visit to a vendor customer. Bear in mind that the vendor will choose a customer amenable to such a visit, and this will probably be a good example of what a good implementation looks like. No harm in that, but it will likely only confirm what you hope to see.
For greater confidence in downselecting one or more vendors capable of performing a Proof of Concept that actually does prove a concept, further work should be done by the evaluation team:
Detailed Requirements Capture. The high-level requirements should be taken a level of detail lower. Capturing the detailed requirements should be started in good time.
Understand the Data. This workstream will understand and document the data structure, as is particularly relevant to the likely solution, informed by the high-level Business Context and the high-level Technology Context deliverables, produced earlier. This includes the start and end points of transaction flows across the integration points between internal and external systems. It will also surface any particular data supply needs, and regulatory and compliance needs in different jurisdictions. Any data migration from legacy systems will also be identified.
Understand the Integrations. This workstream will identify all integration points and document the integration and security architectures. It will also cover the need for a mechanism to link cloud-based solutions securely to on-premise systems and/or other cloud-based solutions. It will consider how to retire any system that becomes redundant.
With the information above to hand, a single vendor - or a minimum set if the imagined solution is an ecosystem of vendor products and services - is chosen to go forward to Proof of Concept. They are formally notified of their new status and invited to participate in a Proof of Concept and to begin commercial and legal agreement on t&cs. Back-up vendors are also notified and asked to stand by in case an original choice falls away.
Proof of Concept
The aim is to build a limited instance of the imagined solution, linking technology and business procedure. E2E paths through the concept are scripted and tested, and proven to work. The work is funded by the vendors.
The expected outcomes are:
- making sure that the preferred vendor’s product maps onto the detailed requirements and works as expected, and
- that data passes through all relevant integration paths.
A target organisation model is needed to understand the establishment roles and responsibilities, so that the correct personas can be created to make the PoC more realistic. The amount of work involved will depend on the ambition of the initiative - changing part of existing operations is simpler than setting up a new capability from scratch.
The proof of concept will be run – as far as possible – in an environment that will prove that selected use cases can be successfully completed, and that associated data starts and ends where it should. Test drivers and stubs may be used to mimic actual interfaces. The outcome will be a statement on the fitness-for-purpose of each vendor product.
Identify Gaps and Workarounds
Assuming that all vendors’ products and/or services have emerged from the Proof of Concept, the final evaluation exercise is to identify gaps to the detailed requirements and then agree workarounds with the likely operational stakeholders. The user experience will be confirmed, and operational behavioural stated / changes identified.
Request for Quote
An RFQ, or request for quotation, takes the RFP further and invites confirmation of the cost of the exact specifications which the company requires. Subsequent to the Proof of Concept the vendor (or vendors) should have a clear view of the solution needed, as well as the likely ease of dealing with the company, so it should be a short step for them to commit to a price. The status of preferred vendor gives some vendors confidence, but it is theirs to lose at this stage.
Nevertheless, this is the time to get Procurement and Legal involved in the commercial negotiation. It is often best to entirely hand over negotiation to them, so that good relationships are maintained with the evaluation/project team.
Note that as a result of the Gap/Workaround step, or indeed other reasons, there may need to be confirmation / pricing / agreement of any enabling services which may be provided by internal or other external resource.
Create the Business Case. In parallel to the commercial negotiation, the costs and benefits, if not already known, will be captured and subjected to a financial analysis. This will provide a feedback loop to the commercial negotiation and input to the creation of the investment case.
It may be presumed that a high-level business case for the imagined solution already exists, but this workpackage can add considerable detail.
Present for Approval
With much of the work now done or awaiting conclusion, the recommended solution can be fully documented in anticipation of presentation for approval. The final business and technical solution will be described to the level of detail judged necessary to fully inform the project stakeholders, and to allow an objective decision to be made to recommend it to the Investment Board.
An implementation plan will be prepared which will include all major workstreams of product implementation, technical integrations, data cleansing and migration and business operational readiness.
The various outcomes from the work to date will be summarised into an investment proposal, created to present to the Investment Board
If the evaluation and selection steps outlined above have been undertaken with sincerity and diligence, and a planned and costed implementation has been prepared, the Investment Board might reasonably be expected to give approval to proceed.
At this point the organisation can start preparing to implement the chosen solution. But that is a different story.
A note on vendor feedback
When feedback is given to vendors who have not been successful - at any stage of the process - then they will appreciate as full an account as possible of the good aspects of their response, and to know where they dipped below expectation or need.
Vendor Bid Managers will have had to make representation within their own organisations to access staff time and other resources, and the opportunity will be on their sales system, so any loss will be hard for them to accept; they will need a plausible explanation to share with their people.
Any sense that they were not treated fairly will be made known. Depending on how the feedback is phrased, and how open you leave the door, a counter-response may be received. This may or may not be welcome, so think through how it should be treated.
A note on desirable vendor traits
Cost is not just about accepting the lowest bid, it’s the total cost of ownership, including time saved and costs avoided. The solution offered needs to dovetail into the whole benefit case.
Character is knowing that your chosen vendor has a reputation that they are proud of and are keen to protect. If both parties align then a bond builds.
Capability is about having faith in the vendor to do the right thing, even when you are not standing over them. Not only can they deliver what is required, but they share and live your company values.
Communication is knowing that the vendor has been transparent in their dealing with you, clear in their messages and timely in their responses.
Did you choose the vendor who matched the traits above?