Zanders Project Management Framework

At the birth of any project, it is crucial to determine the most suitable project management framework by which the treasury objectives can be achieved. Whether the focus is on TMS implementation, treasury transformation or risk management, the grand challenge remains – to ensure the highest quality of the delivered outcome while understanding the realistic timelines and resources. In this article we shed a light on the implications of project management methodologies and address its main concepts and viewpoints, accompanied by experiences from past treasury projects.

In recent years, big corporates have been strategically cherry-picking elements from various methodologies, as there is no one-size-fits-all. At Zanders, our treasury project experience has given us an in-depth knowledge in this area. Based on this knowledge, and depending on several variables – project complexity, resource maturity, culture, and scope – we advise our clients on the best project management methodology to apply to a specific treasury project.

We have observed that when it comes to choosing the project management methodology for a new treasury project, most corporates tend to choose what is applied internally or on previous projects. This leverages the internal skillsets and maturity around that framework. But is this really the right way to choose?

Shifting from traditional methodologies

As the environment that businesses operate in is undergoing a rapid and profound change, the applicability and relevance of the traditional project management methodologies have been called in to question. In the spirit of becoming responsive to unforeseen events, companies sensed the urgency to seek methods that are geared to rapid delivery and with the ability to respond to change quickly.

Embracing agile

The agile management framework aims to enhance project delivery by maximizing team productivity, while minimizing the waste inherent in redundant meetings, repetitive planning or excessive documentation. Unlike the traditional command and control-style management, which follows a linear approach, the core of agile methodology lies in a continuous reaction to a change rather than following a fixed plan.

This type of framework is mostly applied in an environment where the problem to be solved is complex, its solution is non-linear as it has many unknowns, and the project requirements will most likely change during the lifetime of the project as the target is on a constant move.

The illustration of an agile process (figured above) portrays certain similarities to the waterfall approach, in the sense of breaking the entire project in to several phases. However, while these phases in the waterfall approach are sequential, the activities in agile methodology can be run in parallel.

Agile principles promote changing requirements and sustainable development, and deliver working software frequently which can add value sooner. However, from a treasury perspective, you often cannot go live in pieces/functionalities since it increases risk or, when a requirement comes late in process, teams might not have the resources or availability to support the new requirement, creating delivery risk.

Evolving Agile and its forms

Having described the key principles of agile methodology, it is vital to state that over the years it has become a rather broad umbrella-term that covers various concepts that abide by the main agile values and principles.

One of the most popular agile forms is the Kanban approach, the uniqueness of which lies in the visualization of the workflow by building a so-called (digital) Kanban board. Scrum is another project management framework that can be used to manage iterative and incremental projects of all types. The Product Owner works with the team to identify and prioritize system functionality by creating a Product Backlog, with an estimation of software delivery by the functional teams. Once a Sprint has been delivered, the Product Backlog is analyzed and reprioritized, and the next set of deliverables is selected for the next Sprint. Lean framework focuses on delivering value to the customer through effective value-added analysis. Lean development eliminates waste by asking users to select only the truly valuable features for a system, prioritize the features selected, and then work on delivering them in small batches.

Waterfall methodologies – old but good

Even though agile methodologies are now widely accepted and rising in popularity, certain types of projects benefit from highly planned and predictive frameworks. The core of this management style lies in its sequential design process, meaning that an upcoming phase cannot begin until the previous one is formally closed. Waterfall methodologies are characterized by a high level of governance, where documentation plays a crucial role. This makes it easier to track the progress and manage the project scope in general. Projects that highly benefit from this methodology are characterized by their ability to define the fixed-end requirements up-front and are relatively smaller in size. For a project to move to the next phase, all current documentation must be approved by all the involved project managers. The excessive documentation ensures that the team members are familiar with the requirements of the coming phase.

Depending on the scope of the project, this progressive method breaks down the workload into several discrete steps, as shown here:

Project Team Structures

There are also differences between the project structures and the roles used in the two presented frameworks.

In waterfall, the common roles – outside of delivery or the functional team – to support and monitor the project plan are the project managers (depending on the size of the project there can be one or many, creating a project management office (PMO) structure) and a program director. In agile, the role structure is more intricate and complex. Again, this depends on the size of the treasury project.

As stated previously, agile project management relies heavily on collaborative processes. In this sense, a project manager is not required to have a central control, but rather appointing the right people to right tasks, increasing cross-functional collaboration, and removing impediments to progress. The main roles differ from the waterfall approach and can be labelled as Scrum master, Agile coach and Product owner.

Whatever the chosen approach is for a treasury project, one structure is normally seen in both – the steering committee. In more complex and bigger treasury projects (with greater impact and risk to the organization) sometimes a second structure or layer on top of the steering committee (called governance board) is needed. The objective of each one differs.

The Project Steering Committee is a decision-making structure within the project governance structure that consists of top managers (for example, the leads of each treasury area involved directly in the project) and decision makers who provide strategic direction and policy guidance to the project team and other stakeholders. They also:

• Monitor progress against the project management plan.
• Define, review and monitor value delivered to the business and business case.
• Review and approve changes made to project resource plan, schedules, and scope. This normally depends on the materiality of the changes.
• Review and approve project deliverables.
• Resolve conflicts between stakeholders.

The Governance Board, when needed, is more strategical by nature. For example, in treasury projects they are normally represented by the treasurer, CFO, and CEO. Some of the responsibilities are to:

• Monitor and help unblock major risks and potential project challenges.
• Keep updated and understand broader impacts coming out from the project delivery.
• Provide insights and solutions around external factors that might impact the treasury project (e.g. business strategic changes, regulatory frameworks, resourcing changes).

Other structures might be needed to be designed or implemented to support project delivery. More focused groups require different knowledge and expertise. Again, no one solution fits all and it depends on the scope and complexity of the treasury project.

The key decision factors that should be considered when selecting the project structure are:

Roles and responsibilities: Clearly define all roles and responsibilities for each project structure. That will drive planning and will clearly define who should do what. A lack of clarity will create project risks.

Size and expertise: Based on roles and responsibilities, and using a clear RAPID or RACI matrix, define the composition of these structures. There should not be a lot of overlap in terms of people in the structure. In most cases ‘less is more’ if expertise and experience is ensured.

The treasury project scope, complexity and deliverables should drive these structures. Like in the organizational structure of a company, a project should follow the same principles. A pyramid structure should be applied (not an inverted one) in which the functional (hands-on) team should be bigger than other structures.

Is a hybrid model desirable? Our conclusion

While it is known that all methodologies ultimately accomplish the same goal, choosing the most suitable framework is a critical success factor as it determines how the objectives are accomplished. Nowadays, we see that a lot of organizations are embracing a hybrid approach instead of putting all their hopes into one method.

Depending on the circumstances of the treasury project, you might find yourself in a situation where you employ the waterfall approach at the very beginning of the project. This creates a better structure for planning, ensures a common understanding of the project objectives and creates a reasonable timeline of the project. When it comes to the execution of the project, however, it becomes apparent that there needs to be space for some flexibility and early business engagement, as the project happens to be in a dynamic environment. Hence, it becomes beneficial to leverage an agile approach. Such project adapts a “structured agile” methodology, where the planning is done in the traditional way of management, while the execution implements some agile articles.