Tactical Readiness for TMS

A popular discussion of treasury management system (TMS) strategy can be summarised as follows:

  • Preparing to implement a TMS begins with understanding your objectives, understanding what a TMS can and cannot offer you, and securing budget and executive sponsorship to undertake a project.
  • Deploy the right people in a team and collaborate to overcome silos. Schedule regular meetings, keep a pulse on emerging risks and measure success by a predefined scale before you begin. Implement escalation procedures and contingency plans to address risks if they emerge. Keep your goals in mind throughout.

These ‘plan ahead’ recommendations may seem cliché. That doesn’t diminish their wisdom, but the advice suffers from boundless scope. Implementation tactics require controllable scope to be effective.

Implementation, by nature, is a tactical activity that delicately balances on-going, in situ discovery of relevant details with sticking to the framework of an initial plan. But affording your implementers the flexibility to adapt, indeed encouraging them to be responsibly creative when the situation calls for it, is a key element of success. The purpose of this article is to stimulate thought about balancing preparation with responsible creativity.

Tactical Preparations: Assessing Needs

TMS projects typically begin the tactical phase with focused discovery of relevant details. Officially, this work puts boundaries around scope and produces descriptions of expected deliverables and opportunities. However implementation road warriors, who spend 50% or more of their time on site will tell you that discovery is an ongoing, continuous activity similar to assessing the landscape in the heat of battle. Let this guide your expectations.

The strategic level progress report will never give a full picture. This is not a sign of poor planning; it is a fact of every meaningful project that ought to be understood upfront. It is impossible to predict every snag and risk in advance. This should not prevent you from trying to a reasonable degree, but it also means holding off on the panic or punish button if you are a top level planner.

It shouldn’t be surprising that a smooth implementation depends on legwork done well in advance of actual implementation, stretching back to vendor market scans to see what’s possible, and understanding yourself and your own treasury operations first. The tactical preparation for any implementation begins with an assessment of needs well before a vendor is selected. At this phase, it is a common error to overlook the involved detail or to regard treasury operations as self-evident, particularly if non-core treasury staff or consultants will be responsible for most of the hands-on implementation work in modular areas of the TMS.

The mapping of treasury processes should contemplate three layers, particularly for higher complexity or widely distributed operations. The scope and complexity of TMS project goals will weigh heavily on the usefulness of each layer, but all implementations require the first layer.

Operations architecture
The top layer is an overall description of treasury operations architecture. This set of documents, not necessarily a rigid format or map, should include the current state of inputs, processes and outputs from treasury. If process re-engineering is contemplated (as opposed to simply automating today’s map), a separate future state document set should be prepared as well. A change plan bridges the two.

Although the treasury operations architecture document set can be drawn largely from operating manuals for specific job functions, the project purpose of this layer is a central reference for communications with executives, the project team, vendors, and other outside parties such as banks (on a need to know basis). It should be attuned to this purpose.

The top layer can be illustrated with box and flow diagrams without revealing the intimate financial details of an operation. This is an ideal tool for initially introducing technical resources and implementers to point-focused project responsibilities; it provides them with project context and explains high-level dependencies that rely on their specific areas of implementation. This is particularly useful for heading off ‘finish-to-start’ dependencies where an unfinished activity can forestall another that really needs the baton passed on before it starts running. For project managers, this layer is also useful for creating work breakdown structures that head off invalid work assumptions or inefficient methodologies that can emerge as an implementation proceeds. This is the tactic of divide and conquer.

Neglecting to detail complex areas, or assuming a TMS can solve what seems basic from a financial point of view, can be disastrous, making technical delivery of financially simple requirements difficult. For example, a manually accomplished cash position may have summary level variances that are hard to provide given a vendor solution’s data model. In this situation, what was done easily with Excel, and taken for granted because of a spreadsheet’s lengthy service and enhancements over many years, may be hard for one TMS to replicate but easy for another.

While this is obviously an issue that should have been resolved at vendor selection before implementation, an operations architecture layer highlights areas like this that need proactive drilldown in tactical planning. If a necessary trade-off is known in advance, and a conscious choice is made to go with a vendor weak in one area but strong in another, the weak area must still be implemented. Tactics for weak areas should be addressed as soon as the trade-off decision is made. Waiting does not do away with details.

Surprisingly, other work packages that initially appear as major challenges can turn out to be fast horses to carry you over the finish line. The idea behind a treasury operations architecture layer is to give good, clear context and a common vocabulary to everyone on the project. It also clears up what you need for the next layer.

Detailed requirements
This concept borrows a page from the software development industry, where investments in taking functionality to market require research into customer needs, technical cost analysis and product impact assessment. A TMS vendor’s product management must balance the value of certain functionality to clients with the cost of providing it, and the effort to make it work well with existing functionality, while not breaking existing functionality in technical or usability ways. Short of building your own system in-house (which shouldn’t always be off the table), detailed requirements for implementation will usually be much less comprehensive than detailed requirements for development.

Although it is rare to see full-blown TMS functional requirements on implementation projects, efforts should be made to pursue detail in financially complex areas, such as derivatives, intercompany portfolios or complex outputs for accounting. These should be known to the team before vendor selection, to ensure candidate solutions can meet requirements, and to gauge vendor staff comfort levels with the treasury areas at hand. It might even be useful to ask vendors if they have specialists in areas you know will require special attention as a result of your detailed requirements analysis.

The process of assembling requirements in detail often unearths cross-functional insights for team members. For example, it can offer illumination for financial IT staff who see treasury data all the time, but not the holistic business perspective of treasury. In my experience, this process is mostly incidental, and projects benefit from it without sensing it or measuring it.

Insight generation mostly happens through immersion and osmosis, but it can be accessed and enhanced proactively, by first gathering detailed requirements and then creating scenarios from these to test vendors.

Vendor scenarios
Without spending an inordinate amount of time with individual vendors, assessing their product and service capabilities cannot be perfect. This doesn’t rule out a concerted effort to find out as much as possible, but illustrates the balance between cost of assessment and depth of assessment. Representative test scenarios are an effective method to evaluate vendors on multiple dimensions.

From your treasury operations architecture and needs assessment documents, devise representative test scenarios. Vendors will display their basics and their best, but won’t voluntarily show you their challenges. Representative scenarios should be devised in paragraph and example form, to test vendors’ responses and responsiveness.

For instance, you may temporarily stump a vendor with a complex financial instrument question, but they may come back to you with a comprehensive answer a few days later – in a committal, written response supported by a brief technical description. Perhaps the functionality is missing, but they normally address it with an ugly workaround. If the vendor answers honestly, this suggests they are resourceful, even if the TMS itself is lacking a feature. Ask yourself if you can work with that.

Eliciting such a response tells you more about the vendor’s specific fit to your project than any brochure or request for proposal (RFP) could contemplate. Moreover, it shows how they could proceed during an implementation. Immediate answers are useful, but comprehensive answers are better, and will guide your assessment and interaction with the vendor. Scenarios are powerful testing tools.

Implementation Methodologies and Tactical Culture

Over and above differing project management cultures, even technical methodologies and tools applied in an implementation can vary, depending on what a corporate culture can accept and run with. Every implementer knows this. Projects can look alike at the strategic level, but no two will coincide exactly at the tactical level.

The tactical culture of a vendor or customer can even impact the tools used in an implementation. For example, there are scripted entry technologies that can be employed to transform existing spreadsheets into powerful import files. This sounds too good to pass up, and is, yet there is no commonplace use of it. Some vendors are reluctant to step outside of their own boxed technology; some customers are afraid to use technologies not already employed by their own IT departments. Vendors and customers may describe this as a general aversion to risk, but it often amounts to fear of technology. This is only one example of how culture impacts tactics.

Organisational culture determines much of what’s possible in a TMS implementation the same way it determines core strategic outcomes for any large company. For example, a culture of rigid functional silos will require implementers to drive the crossing of functions, while a more collaborative culture may instinctively provide a more informed technical context from the outset. On the flipside, rigid functional silos can deliver technical depth in specialist areas not otherwise possible. While this is not an endorsement of silos, accidental advantages can be leveraged for TMS implementations. The impact of culture on TMS implementation tactics is perhaps the most under-examined topic in our area, but unlocking it can produce insights to accelerate and improve TMS implementations.

From documentary preparedness to cultural analysis, tactics are a key component to a successful TMS selection and implementation. Tactical readiness will deliver your strategic intentions.

Henry Wong is speaking on the panel ‘A Roadmap to Fully Implementing and Utilising your Treasury Management System’ alongside Greg Haddock, vice president and treasurer, Restoration Hardware, and Kim Sipes, certified treasury professional (CTP), director of treasury, Duke Energy, at the AFP conference on Monday 15 October 13.30-14.45 in room B212.



Related reading