Treasury Today Country Profiles in association with Citi

In a decent proposal…

Lighthouse at dusk with searchlight beaming

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.

Checklist of RFP processes

  • Before starting on a major project, secure the support of a senior executive sponsor.

  • Appoint a strong project manager. Consider a third party for the role if no suitable internal candidate is available.

  • Always establish a requirements definition.

  • If an internal appointment is made, ensure they can remain objective. Consider having them dedicated to the role for the duration.

  • Factor in all resources likely to be required for the duration of the project.

  • Think carefully about which functions and individuals within the group should be involved in the consultation process. Document any agreements in advance.

  • Establish ‘rules of engagement’, allowing vendor-contact only with this liaison person (probably the project manager). Log all interaction. A single point of contact avoids confusion and conflicting information. This rule should be extended to cover the implementation process.

  • Ensure you clearly understand and have documented what your main issues are, why you are doing this and what you expect to achieve. Refer to this document often.

  • Be flexible regarding your plans and add a contingency allowance (for cost, time etc) for project expansion as awareness of the chosen solution increases.

  • Do not confuse beneficial project additions with unwanted scope creep.

  • Don’t change anything in the project plan without managing and documenting it.

  • Consider issuing a request for information (RFI).

  • When building a RFP keep asking if it conveys precisely and clearly what it is you require.

  • Ensure questions are clear, understandable and have been tested and proven as such.

  • Do not ask unnecessary or unreasonable questions.

  • If multiple departments are involved proper coordination and documentation is required at all times.

  • Ask open questions where detail is necessary and closed questions where a simple yes or no is sufficient. Remember that open questions are more difficult to compare.

  • Lay out the RFP clearly, in logical order and with sufficient room for a full response.

  • Complex requirements should be broken down into logical, manageable sections.

  • It is in your interest to provide sufficient information to enable the vendor to give the fullest answer possible.

  • Do not over-burden the supplier with unnecessary background information.

  • Read the final document before sending it to vendors to ensure it is fit for purpose.

  • Weight each question according to your own values and agree upon weightings before sending the RFP to suppliers. Resist the temptation to adjust weightings to get the answer you want.

  • Clear your mind of any bias for or against suppliers.

  • Don’t send it to too many vendors: it makes analysis difficult.

  • Read all responses carefully.

  • Look for added-value in vendor responses eg raising new but useful points.

  • Learn to distinguish between fact and sales talk.