Devil in the (design) details

Treasury technology implementation

Devil in the (design) details

As a result of the increased demand for (real time) treasury data, in combination with an ever changing regulatory landscape, treasurers are looking to increase their visibility on liquidity and financial risks. Technology plays a crucial role in managing the increased complexity in treasury operations more efficiently to meet these goals. Hence, to strengthen control and visibility of treasury related activities throughout the company, many corporates aim to centralize and standardize their treasury activities as much as possible by deploying appropriate treasury technology. For example, by implementing a new TMS, upgrading their current TMS to the latest version or implement a specialized / add on functionality in a different best of breed system.

We have identified 7 steps to help corporates succeed in their transformational journey of implementing a new treasury technology solution. This article focuses on the first two steps of the 7-step approach (Project Preparation and the Blueprint phase). In our experience, these steps are often not given sufficient attention, in terms of time and resources, during the technology implementation process.

Figure 1: The 7 steps of Treasury Management System Implementation

1. Project Preparation: This step includes the project mobilization and preparation of the project initiation document covering project objectives, final scope, plan, approach, and team. Before embarking on the implementation project, the project manager should assure project sponsorship at senior management level, such as the CFO, corporate treasurer, or CIO.

a) Project objectives & Scope: The project’s objective and scope need to be documented in a detailed manner. The scope document should include organizational scope, process scope and interface scope. Further, it is essential to verify the functional scope; which processes are in scope and which are out of scope. Sometimes, a particular process could be in scope for the corporate sponsor, but out of scope for the vendor or implementation partner.

b) Governance Structure & Planning: A governance structure should be formed for a project of any size. A steering committee consisting of senior managers and decision makers is an element of the governance structure. This group of stakeholders are accountable for steering the project within budget, time, and deliverables.
Moreover, an agreement should be made on the roles & responsibilities and timelines. RACI (Responsible, Accountable, Consulted, Informed) is an excellent tool to define the roles and responsibilities within the project team. The timeline should be realistic considering the resource availability of both the implementation partner and the corporate.

c) Project Management:

  • Project Management Team: A project manager officer (PMO) or a group of PMO’s should be assigned depending on the size of the project. The PMO should ensure key stakeholders are available during the entire duration of the project. Further, ensure process owners are appointed and allocate key users to separate areas. A project management structure with a transparent escalation process should be established.
  • Project Management Methodology: The scope, complexity, and deliverables drive the decision on whether an agile, waterfall or hybrid type of project management methodology is applied. For more information on these models, please refer to this article.
  • Project Dependencies: A dependency criterion is a list of criteria that should be considered during the project, for example, dependency on technology licenses, availability of environment, selection and contract with a trading portal, IT freezes. If these dependencies are not listed, they could be overlooked during the later stages of the project and might potentially cause a delay if not arranged in time.
  • Communication Plan: A communication plan is recommended for stakeholders throughout the company to inform them of the changes, timelines, and work impact. The communication plan should include the following:
    • Centralized and easily accessible action & issue list.
    • Frequent stand-ups per team, regular Steering Committee meetings.
    • Involve representatives from all stakeholders (including IT and Finance).
    • Make formal change decisions before moving forward.
    • Ensure that separate lines of communication are created for each team (technical, business, KYC)
    • Start communication with external relevant stakeholders such as banks required for testing purposes and, for example, Swift Service Bureau at an early stage.

2. Business Blueprint: The design or the business blueprint phase is critical in any project. Our advice would be to dedicate sufficient time to this step. This phase includes preparing the System Blueprint document (as-is process & to-be process), functional and technical design documents. Before defining the to-be approach, it is essential to analyze the current process and determine how you would like the future process to look. First, a catalogue must be made of all your existing processes. Once this catalogue is made, the next step would be to prepare and deliver requirements gathering workshops with all the key stakeholders. The workshop would include discussing issues with the as-is process, highlighting potential risks, and signals possible improvements. Further, during this workshop, the project team should discuss the requirements expected to be fulfilled from the technology, including possible gaps required if the standard solution does not adhere to the requirements.

Once the project team has made these decisions and a consensus agreed upon, we propose to draft a decision form. It is an essential tool to outline the reasoning behind any decision made. The functional specification documents outline the process flow and provide an overview of the to-be process. It also includes mockups screens of the to-be implemented system to ensure the team is aligned and knows what to expect. The functional specifications would also consist of information RICEFWS: Reports, Interfaces, Conversions, Enhancements, Forms, Workflows if applicable. The technical specification consists of documentation on the gaps and interfaces that might have to be developed to fulfill the process requirements.

During this phase, segregation of duties between the various departments should be defined (Back office, front office), making it clear to the departments about the roles and responsibilities and enabling the IT team to ensure authorizations in the system are already set up. After the blueprint, functional and technical specification documents are finalized, the steering committee would need to provide their approval. Once this approval has been granted, you are all set to start with step 3, the realization phase.

To conclude, before the realization phase starts, preparation and design are essential to ensure no unexpected outcomes are encountered. Moreover, thorough scope and design documentation, preparation performed during step 1 and step 2 can help the treasury team handle treasury transformation like a pro.