When the time is right to introduce or replace a key part of your treasury technology, or to establish a major new banking relationship, the selection process can be daunting. Unless you know exactly what is required, issuing a request for proposal (RFP) may provide some valuable direction. What does it involve?

The technology and banking needs of a treasury vary from business to business and a one-size-fits-all solution for either does not exist. This means a choice will need to be made somewhere down the line when it comes to selecting for the first time or replacing a particular element. Regardless of the driver for change, sometimes these choices will be difficult, particularly when considering a complex proposition such as a Treasury Management System 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 project.

Some projects are built around a long-term strategic vision, in which case time to explore each facet may be afforded. Other decisions may need to be made under pressure in which case there is a risk of making a huge mistake or simply failing to take advantage of the opportunity to improve the workings of the treasury department.

In both cases, although the approach may be different, a well-managed RFP (Request for Proposal) can be a valuable tool in helping to ease the difficulties of the selection process whilst alerting treasury to any existing imperfections that should now be addressed. After all, a good choice now may well obviate the need for yet another project.

In the first of this two-part series, Treasury Today considers the requirements around building a technology RFP.

Requirements definition

Most treasury technology projects can be broken down into three parts: review; selection; and implementation. In this article we look at the first two constituents.

The review process is intended to establish a requirements definition: by analysing treasury processes and technology currently being used, and establishing what treasury wishes to achieve with the project, it is possible to make a broad outline of what is required and how treasury feels it may be achieved.

The requirements definition is the foundation stone of the project and its solidity will inform the success or otherwise of subsequent project phases. However, it should be understood that a degree of flexibility on the part of both client and vendor 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-worded RFP may go some way to revealing the preparedness of the vendor to accommodate the client.

A caveat on the corporate side to this call for flexibility is that it is not best practice to change core processes just because the chosen system cannot accommodate your needs. By the same token, customising the solution from the outset to meet your process requirements can also store up future trouble (customising is not to be confused with configuring; the latter will almost certainly be required to enable a solution to meet the specific needs of the business).

Teamwork

The value of undertaking a requirements definition cannot be overstated, but it may not be possible, or even desirable, to execute it in isolation. Depending on the nature of the project, it may call upon input from other functions within the business (including various finance and business units, procurement, internal audit and IT) to highlight some of their specific technical requirements. This will be necessary when the systems of these functions (such as accounts or credit control) already (or will) interface directly with the proposed treasury solution and will in any case give an indication as to how the new system will affect other technologies up and downstream. If there are other functions that have any input, get it written down at this point as it will stop problems later on. It is essential at this stage to cover all bases, thinking carefully who should be involved in the consultation process, who will be impacted by the project and who could or should benefit from the outcome.

Project manage

The consultation process, though hugely beneficial in the long run, will run the risk of developing so-called ‘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 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.

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.

Indeed, the PM should bring order to the process by planning the phases, defining roles, putting in place the right resources at the right time, and getting everything done in the right order. In doing so, the odds of missing something and having to go back to it later are greatly reduced. However, any changes to the structure put in place by the PM must themselves be managed and documented to maintain project integrity.

To be effective in the PM role, experience is highly desirable, particularly when it comes to change management (which must never be underestimated, particularly when it comes to dealing with office politics). Some firms choose to employ a consultant to take them through the entire process, from initial analysis to implementation. Whilst it may be desirable to employ an impartial third party who will not be subject to day-to-day operational distractions, it is entirely possible to select an individual internally, as long as they can remain objective – especially during the full-on implementation phase. If an internal project manager is chosen, it may be beneficial to have them dedicated to that role for the duration. Factoring in the resources needed therefore becomes part of the process.

Consider your initial options

By this stage, beyond confirming that there is a need to bring in new technology, you will have defined your exact goal, what is required of the solution to meet that goal, how the project may impact other parts of the business and what their requirements are, and then formed it all into a coherent requirements definition document. It is now time to consider possible solutions. The more effort put into this phase, the less time will be spent on unsuitable candidates.

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 an RFI (Request for Information). An 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 systems (and this may include half a dozen or more), building an RFP can provide structure to the selection process, enabling you to focus only on the most appropriate offerings. In doing so, although positive past experience is a valuable indicator, it is important to clear your mind of all bias against any supplier. However, whilst some companies have strict procurement rules to ensure fair competition at all times, if you know what you want (and if procurement will allow it), just buy it. After all, putting a vendor through a rigorous RFP process when the decision is a fait accompli is a waste of everyone’s time (a process referred to scathingly by vendors as ‘the beauty pageant’). To this must be added the notion that by going through the process, it may uncover ideas and product and vendor capacities that were not previously on the radar.

Building an RFP

The aim of an RFP is to garner in-depth and specific responses from a small group of vendors and tease out the differences between their systems which, on the surface, may all seem much the same. It may even form the basis of a contract between client and vendor although many vendors would naturally baulk at this suggestion, especially if their responses have not been written with the requisite legal precision (it may be useful to ask how the vendor’s RFP responses are reviewed and authorised internally).

It is vital from the treasurer’s point of view to ensure that the RFP conveys precisely and clearly what is required, according to the circumstances underlying 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 vendor and for your own team when it comes to assessing the results.

The actual layout of the RFP can vary but it is mostly bound by common sense; just 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.

In terms of content, despite attempts at creating a standard RFP form (the AFP in the US has made one available to its members) the disparate nature of the businesses and the varied treasury requirements of those issuing them means a fully-formed, off-the-shelf, one-size-fits-all document has yet to emerge.

There is a big difference in requirements between buying a TMS and an FX trading platform, for example, just as there is a big difference in the eventual deployments of these systems by each user. Whilst a standard form will deliver some efficiency advantages for vendors and corporates alike, copy and paste questions will not cover the specific issues that are important to each business and could induce standard responses which will serve only to take the project team a limited distance down the path towards individual project fulfilment.

So, whilst some aspects of treasury may resonate across the industry, an in-house banking structure, for example, is very specific to one company and simply asking if a platform supports it is rather meaningless; you need to be able to express in the document what that structure looks like (even using attached flowcharts and models) to be able to elicit a usable answer.

For now, as long as the same document is issued to each prospective supplier, then the need for standardisation is arguably limited anyway, the vital part stemming from the need to reflect the individual needs of the company in what is asked and how it is asked.

Indeed, 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. There is, however, no known research on the correlation between size of RFP and success of implementation!

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; all you have to do with the RFP is to ask the supplier if they can do it. But whilst some responses may call for a simple ‘yes’ or ‘no’ answer, some may need more in-depth explanations of how certain functions are supported and processed and how the software relates to the way in which your treasury operates (including its connectivity with third parties, such as banks).

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 system solution can automate a specific treasury.

The client may take this opportunity to make clear its position on certain contractual conditions such as payment being explicitly linked to tangible deliverables. Whilst being business-like is essential, it is important not to appear unreasonable – an adversarial RFP will yield little in the way of success.

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

This means 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 type of answers that you seek. You are, after all, asking for more than just a cut-and-paste response from the supplier.

When asking about the implementation process it is necessary not just to pose questions but also to state a host of facts. The list may include points relating to the intended timescale, how many users, locations, functionality required in each location and how satellite units are structured within the company, the existing system configuration (listing current systems and what needs to be integrated), and any manual interventions.

It may be appropriate to provide a proposed technical integration plan for the new platform. 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 skewed; certainly beware of adding elements merely out of curiosity or as a demonstration of your depth of knowledge (it does happen) as these will push the cost up.

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 that RFPs that are the product of multiple departments are prone to duplicate or even triplicate questions. Care should be taken to remove any such instances from the final document as they can reflect poorly on the buyer’s professionalism. Of course, this caveat does not apply to carefully constructed functional verifications, designed to check the vendors’ responses for consistency.

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 RPF is sent to, the more analysis you will have to do when the responses come back. Typically a short-list of three or four will be called upon to respond. It is not unheard of for vendors to not respond.

Making a judgement

The RFP responses should give a clear demonstration of each vendor’s capacity to add value and differentiate itself from the others. Over and above what is sought by the treasury team, a good RFP response will also provide answers to the questions and issues that haven’t even been raised. Read them all.

The information you receive back will have to be compared on an equal footing. Depending upon factors such as the complexity of the project and how many suppliers are 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 that is of lesser importance.

The weighting process must be discussed thoroughly by the project team. The process is arbitrary and therefore must have direction from the project manager to avoid endless re-working. Once scores are calculated it is advisable to resist the temptation to keep adjusting the weightings until you get the answer you want (in which case, the exercise will have been a waste of time).

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 a lot of extra work.

When applying scores, it may be useful for each reviewer on the team to give their own to each weighted component, creating a weighted average total. There are various methods of reaching a final score, but in any case the chosen model should be agreed upon before starting to assess responses, to avoid any confusion or disagreement. In the end, the decision may come down to which vendor team you feel most in tune with or even price, but the RFP will have provided most of the technical and service information to be able to take such a decision comfortably.

Once completed and the decision made, the choice then is whether to use the vendor’s contract or to draft your own, which opens up a whole new discussion; suffice to say at this point that the corporate treasury needs to find a balance between encouraging and compensating the vendor whilst still giving itself scope to manage the risks of the project and getting satisfactory delivery.

The RFP document may be used as a reminder of what is expected of the vendor once the implementation is underway. Where a TMS implementation is undertaken, the project should be seen as an opportunity to re-engineer inefficient and outdated processes. This possibility often only becomes clear after initial selection has been completed, and once a particular TMS’s capabilities are better understood. Although it will involve changing, and perhaps expanding the project to some degree, it should not be seen in the same negative light as scope creep. Such changes will, however, need proper control and management. This possibility should ideally be covered in a contingency allowance in the initial project plan.

Ultimately, if the RFP is treated as a functional document with a serious purpose, and the information contained within is sufficiently detailed, it should be beneficial to both the client and the vendor.

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 an internal appointment, ensure they can remain objective. Consider having them dedicated to the role for the duration.
• Factor in all resources likely to be required.
• Think carefully about which functions and individual within the group should be involved in the consultation process. Document any agreements with them 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 system increases.
• Do not confuse beneficial project additions with unwanted scope creep.
• Don’t change anything in the project plan without managing and documenting it first.
• Always establish a requirements definition.
• Undertake preliminary research (using Treasury Today resources, conferences, vendor websites, discussion with peer-group etc).
• Consider issuing a Request for Information (RFI).
• When building an RFP always ask 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.
• Some questions may be approached from different angles to test consistency of response.
• Beware of simply repeating questions (most likely if the RFP is the product of multiple departments). Proper coordination is required to maintain professionalism 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.
• Weight each question according to your own values.
• Agree upon weightings before sending the RFP to suppliers.
• 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.
• Resist the temptation to adjust weightings to get the answer you want.

In the next part we consider how to build an RFP for banking relationships.

Thanks to the following treasury consultants for offering their insight and experience:

• Kelvin Walton, Director, TreasuryWise
• Ken Lillie, Director, Lillie Associates
• Adrian Rodgers, Director, ARC Solutions
• Colin Jones, independent cash and treasury management consultant