When the time is right to introduce or replace a key part of your treasury technology or to establish a major new banking or service relationship, the selection process can be demanding. Treasury Today considers a key part of any major project: the Request for Proposal.

Regardless of the driver for change, sometimes the choices available to treasurers when selecting new technology or service relationships can be bewildering, particularly when considering a complex proposition such as a treasury management system (TMS) or a multi-country banking partner. The difficulty often lies in the fact that the differences between offerings may be subtle but nonetheless important to the success or otherwise of the outcome.

In such a case, a well-managed request for proposal (RFP) can be a valuable tool in helping to ease the selection process whilst the drafting process can potentially alert treasury to any other issues that should now also be addressed. A good choice at this stage may well obviate the need for yet another project down the line.

In essence, a RFP is the governing document that contains all the key business requirements based around the new solution that treasury is looking to implement. The importance of developing a document that will allow treasury to obtain the information it needs to make an informed decision cannot be overstated.

Requirements definition

No matter where a RFP is carried out in the world, a coherent and managed requirements definition is essential beforehand. This is the foundation stone of the entire project and may call upon input from other functions within the business to highlight some of their specific requirements and to give an indication as to how any new system or process will affect others up and downstream.

However, it should be understood from the outset that a degree of flexibility on the part of both client and vendor (used in this context to mean technology vendor, bank or other service provider) is desirable as to the means of arrival at the final destination because as the project progresses new ideas are often revealed. In a complex treasury setup, a fully-scoped project may not even be possible until the core functions have been implemented and the ancillary requirements become apparent. There may also be the need for a discretionary trade-off where the lack of a certain aspect may be outweighed by the presence of another more important one. A suitably researched and worded RFP may go some way to revealing the preparedness of the vendor to accommodate the client in this respect.

Project manage

The consultation process, though hugely beneficial in the long term, will run the risk of developing ‘scope creep’ (continuously adding to it) unless from the outset there is a coherent and simple project definition, a means of deflecting unnecessary diversions, and of taking firm and intelligent decisions. Scope creep can confuse and confound the end-result and add substantially to the final cost. For this reason, the backing of a project sponsor (in the form of an executive with higher status than anyone else involved with the project) and a strong project manager (PM) are essential.

The importance of developing a document that will allow treasury to obtain the information it needs to make an informed decision cannot be overstated.

However, scope creep should not be confused with the controlled and planned modification of the project in the light of acquiring more detailed understanding of the capabilities of the technology. This can add new benefits that had not been previously thought of – but even here the change process must be managed.

Consider your initial options

Deciding which vendors to approach will involve some background research. Using publications such as Treasury Today, talking to other treasurers and having preliminary discussions with vendors at conferences and exhibitions will all provide valuable initial insight. It may even be prudent to send out your basic requirements definition to a wider panel of vendors, in the form of a request for information (RFI) first. A RFI is a high-level call for product information that can at least put you in the right ball-park regarding which vendors have suitable offerings.

Having created a long-list of potential candidates (and this may include half a dozen or more), building a RFP can provide structure to the selection process, enabling you to focus only on the most appropriate offerings.

Building a RFP

It is vital from the treasurer’s point of view to ensure that the same document is issued to each prospective supplier and that it conveys precisely and clearly what is required, according to the circumstances underpinning the project. A complex treasury will probably generate a larger RFP document and this should be broken down into manageable sections for the benefit of the vendors and for your own team when it comes to assessing the responses.

The actual layout of the RFP can vary but be aware of the importance of laying it out clearly, with a logical progression between each section, and giving sufficient space for suppliers to respond if it is intended to be a physical document. And just as it is possible to fail to explain your needs clearly, or to provide too little information for the vendors to be able to respond in depth, it is also possible to over-burden suppliers with information; providing an in-depth view of the group’s entire business operations may not be required if it is only relevant to the project to offer a view of the structure of treasury and where it sits within that operation.

Incorporating functionality

A major part of building the RFP concerns functionality. This is where the work that went into creating the requirements definition comes into play: the requirements definition states what you want so that when translated into the RFP it enables the treasurer to assess which vendor is best placed to deliver. But whilst some RFP responses may call for a simple ‘yes’ or ‘no’ answer, others may need more in-depth explanations of how certain functions are supported and processed and, if it is a technology project, how this relates to the way in which your treasury operates (including its connectivity with third parties, such as banks and/or SWIFT).

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 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.