In addition to pure functionality, a key objective for a technology project is to configure sets of functionalities into workflows that fulfil the project’s business process objectives. This is where ‘how’ questions can help, as the buyer needs to understand how effectively the solution can automate a specific treasury activity. Be aware that open questions may be necessary to unearth how a supplier intends to meet some complex, potentially deal-breaking issues, but too many open questions will push the analysis phase into overdrive, making it difficult to draw accurate and fair comparisons between vendors.
In all cases, the questions set out in the RFP have to be considered – and tested – carefully, to see if they are understandable, unambiguous, and likely to yield the answers sought. You are, after all, asking for and should expect more than just a cut-and-paste response from the vendor.
When asking about the implementation process it is necessary not just to pose questions but also to state a host of facts to assist the vendor. The fact list may include points relating to the intended timescale, how many users, locations, functionality required in each location, how satellite units are structured within the company, the existing system configuration (listing current systems and what needs to be integrated up and downstream), and any manual interventions.
It may be appropriate to provide a proposed technical integration plan for the new solution. Certainly any integration and reporting requirements should be defined in sufficient detail to avoid ambiguity, to enable vendors to have a sufficient understanding of the implementation scope to propose the implementation effort accurately.
In seeking a vendor’s thoughts on these matters it is necessary to secure from it a raft of reciprocal information such as how it intends to piece together an implementation team (size and structure and who will be involved, for example), what it proposes in terms of ongoing support (technical and staff training) and maintenance (with details and sample copies of SLAs and so on). In essence, you need to embrace the whole service of the product in one document.
It may be that treasury knows what it wants but does not know how to achieve it; the level of detail in the RFP can be used to provide vendors with the opportunity to deliver a creative response, mindful that it is not good form for companies to use it as a free consultancy service. It is also worth noting that unless the RFP conveys precisely what is required, the pricing is likely to be inaccurate; resist adding elements merely out of curiosity or as a demonstration of your depth of knowledge (it does happen) as these will frustrate a genuine comparison.
Whilst some aspects of treasury may be commercially sensitive, it should be borne in mind that conveying sufficient detail for a vendor to be able to provide the most appropriate response is beneficial to all parties, both in terms of getting the best solution and in getting the job done in the most efficient manner. It is important to realise too that RFPs that are the product of multiple departments are prone to duplication of questions. Care should be taken to remove any such instances from the final document. Read the whole document before sending it: a final sanity check will ensure it is fit for purpose.
When it comes to distributing the RFP, by all means send it to all those vendors that closely meet your requirements, but always bear in mind that the more vendors the RFP is sent to, the more analysis you will have to do when the responses come back. Typically a shortlist of three or four will be called upon to respond (and be aware that some vendors may fail to respond: it is unprofessional but it happens).
Making a judgement
A RFP response should give a clear demonstration of a vendor’s capacity to add value and differentiate itself from the others. Over and above what is sought by treasury, a good RFP response may also provide relevant supplementary answers. In any case, read all submissions carefully and if something is not clear ask the vendor to clarify.
The information you receive will have to be compared on an equal footing. Depending upon factors such as project complexity and the number of vendors approached, a well-crafted set of questions should enable the project team to consolidate answers on a single spreadsheet set up to allow a quick view of scores for each aspect. However, before scoring responses, it is common practice to ‘weight’ each section and component according to the relative value the team places on it. This ensures that the overall score reflects those values, and that the outcome is not unduly influenced by an aspect of lesser importance.
The weighting process must be discussed beforehand. The process is arbitrary and therefore must have direction from the project manager to avoid endless re-working. Resist the temptation to adjust weightings until you get the answer you want as this voids the entire exercise.
The degree to which scoring is broken down within each component will depend upon time available and the relative importance of that component. Deep questioning and subsequent scoring of the minutiae of a certain function will in theory better reflect the view of that function. Whilst this may be appropriate for some aspects, doing this for every component will generate unnecessary extra work. In the end, the decision may come down to which vendor team you feel most in tune with, or even the best price, but a good RFP will provide most of the technical and service information to be able to take such a decision comfortably.