Why treasury projects can fail
In the modern treasury landscape, projects are always complex, regardless of scope and size. Even a small project like a SaaS cash flow forecast system implementation is complex if we take into account that the business, regulatory and technical landscape is constantly evolving and that in most cases business resources cannot fully dedicate their time to projects. In today’s world, project teams also need to respond to change quickly and deliver value as soon as possible, both to the project and to business stakeholders. The challenge is to do that while also being in control of timelines, budget, scope, and – most importantly – creating quality and value to treasury and the business.
As described in project management theory, a project is typically constrained by three elements. This is called the triple constraint, iron triangle or project triangle. The three elements are scope, time, and cost. This theory is project management methodology agnostic. It does not matter whether the project is delivered from a waterfall or agile approach; if any of these elements are changed, something else must change.
The theory of the project management triangle is true, but far too simple. Reality differs; only working with these three variables is a limitation when the aim is to deliver a project that also meets the quality criteria defined by the business. In that case, you also need to consider other variables that we will highlight in this article, as these will impact delivered quality, as well as scope, timelines, and cost.
Variables to consider for a successful project
Based on our experience, we know that all these variables will change and need to be adjusted during any project. However, these changes (to scope, timelines or cost) should come from evolving business requirements, a changing landscape and the additional value that they can bring to the business – and not due to a wrong project approach, or variables, processes and structures that were incorrectly or insufficiently defined at the start of the project.
What we see is that most projects are not delivered within the defined scope, time, and cost, due to incorrect project planning, lack of the right project structure or skillsets, and an unclear approach – and not because business is evolving.
So, how can we use this to manage projects effectively? We know, after all, that conditions inevitably change.
In most cases, the variables in a treasury project don’t change in the core functional area. Implementation teams (whether they are strategical, tactical, or operational) usually have a high level of treasury expertise. They speak the same language as the business and that helps to structure the scope, project, and delivery. The right business engagement allows you to keep the efforts, timelines, scope and cost under control.
Typically, it is other areas outside of treasury functional delivery that undermine delivery within timelines, scope, and cost. There are several reasons for this, including these key factors:
- Lack of a detailed approach defined at the start of the project
- Lack of time and focus given to these areas throughout the project
- Lack of a right skillset (both external and internal) allocated to the project and specific areas
Which are the areas that undermine delivery within timelines, scope, and cost? We call these ‘support areas’ to the functional treasury delivery team. Since they are considered support areas, most of the time there is a lack of focus or lack of treasury skilled people to define the right approach at an early stage.
These support areas are:
- Project management
- Business and change management
- Data management
- Infrastructure and integration
The way that it should work, theoretically, is that these areas support the core treasury delivery. Apart from making sure that their own deliverables support the overall functional delivery, their tasks should take the workload and pressure away from the core team and leaving it to the business to focus on priority items and risk areas.
What happens in practice is that, due to the reasons mentioned above (i.e. not using the right skillsets and an incorrect detailed approach defined for each of these areas), instead of taking off the pressure or workload from the core team, these areas require more time and put more pressure in the core functional team, requiring the time and focus of the key people to be shared across high and low priority and risk areas.
Questions you need to ask
Are all the deliverables critical to a successful project? Project empire-building happens in some projects, so review and prioritize deliverables. Non-critical deliverables will impact cost, timelines, and quality, shifting project focus and resources.
Therefore, at the start of a project, we always need to ask ourselves:
- Do we have the right approach for each project area (core functional, project management, etc.)?
- Is the approach based on similar projects, with a similar landscape, scope and complexity?
- Is the approach defined by someone with treasury skills and experience?
An ERP implementation is not the same as a treasury system implementation, since the data required, the processes and risk areas differ. Integration-wise, counterparties involved in treasury system projects differ in terms of file formatting and content, where security and encryption is key. From a testing perspective: how can you prioritize test activities if you don’t know the difference between trade settlement and trade capture?
The same applies to non-system related projects. A treasury transformation project does not require data to be loaded into a new treasury management system, however required reporting (project management dashboards) or stakeholder mapping and management differ from a non-treasury non system related project.
An agnostic approach and agnostic skillsets do not really work. The triangle comes into play when something affects one of its variables. For example, if we need to produce more reports for project management, or have more non-critical deliverables while the time frame is too short to deliver all, the project will likely need more resources, or perhaps a scope reduction. Either way, it will certainly impact quality.
Why do projects succeed?
All successful projects have things in common, and these are incorporated in our implementation framework, for areas like data, testing, project management, business change.
This article is the first of a series on implementation projects. In the next parts, we will start delving into each one of the areas mentioned, sharing our insights and explaining the right approach to impact costs, timelines and scope with changes that will increase the delivered quality and value for the business and that are coming from evolving business requirements with a clear ROI.