It is Saturday, 10:00 in the morning. You are holding your steaming cup of coffee in your left hand, while your right hand flies over the keyboard of your laptop and finally hammers the enter key. The online banking maintenance page slowly loads, emblazoned in red letters on the screen is:
“Due to maintenance work, our online banking is temporarily unavailable.”
With a quiet curse, you close your laptop and wonder why the IT department of a bank cannot ensure online access, underestimating the complexity of the banking IT world.
Many Projects and Even More Requirements
At the same time, a dozen IT specialists are busy rolling out a release on the majority of the bank’s 50 software systems. This roll-out is the last step of a release cycle shaped by time, quality and cost pressures. This includes the planning, design, development and testing of new features over a period of four to six months, taking into account the complex dependencies between the systems involved, such as core banking software, online banking, reporting, output management or balance sheet accounting.
The complexity of the requirements for IT projects in the area of financial services is steadily increasing. Already during the conceptual phase, the armies of IT and other departments collide with each other, fighting over the functional scope of the innovations in a difficult battle. IT focuses on operational security: The software should be simple, low-risk, with low maintenance costs. The departments lead the sharp cutting-edge of efficiency: the software should cover all requirements, the number of clicks in the call center must be reduced, and if the latest legal requirements are not met in the smallest detail, there will be penalties or license withdrawal by the regulatory authorities. The battle will usually result in losses on both sides. Afterwards, there is loud wailing because of the suffering of those who now have to write concepts and test cases in addition to the day-to-day tasks. Additionally, the budget is not enough, saving is necessary. As directed by upper management, of course.
In addition to this somewhat exaggerated collision of interests within the bank, the complexity is further increased by other factors:
Compliance pressure has risen sharply in recent years. This is due to the increasing internationalization of payment transactions (SEPA, SWIFT), a drastic increase in regulation and data transparency (FATCA, CRS, automated tax deductions) and new data protection requirements.
The pressure to modernize IT is high. Existing systems are often several decades old, maintenance becomes unsustainably expensive, knowledge owners “die out”. New software products are to be fully customized, which requires even more effort:
Recently, Deutsche Bank spent € 1 billion on the introduction of SAP.
The digitalization of the banking world increases customer turnover. Through new identity procedures and mobile banking, bank changes are accomplished with a few clicks. New products and campaigns are intended to increase customer loyalty. In turn, this is made possible by IT.
Especially in the case of Corporate banks, “additional requirements” come with project specifications from the parent company: new branding, corporate identity, cross-divisional offers and data warehousing.
These requirements lead to the scheduling of two to four IT-wide roll-outs per year. A large part of the project tasks – in addition to external ones – involve the bank staff in the back office. Conception, discussion of the solution, planning and acceptance tests must be carried out parallel to the day-to-day business. The result: overloading of employees, short-term reduction of the scope of functions, quality losses in project and daily business.
Does it have to be that way? No, it doesn’t.
Portfolio Management as a Solution
The PPM Trilemma
While project management and test management software is widely used in the banking sector, the logical first step, the planning and management of the project portfolio based on the available resource capacities, is often neglected.
Project management only allows you to manage the effect of wrong decisions.
This is usually associated with increased pressure on project staff as well as negative development of quality and budget.
The PPM trilemma shows the dependencies of the individual factors. The implementation of all projects “in time, quality and budget” can only be achieved by means of a sufficient planning of the project portfolio. Such planning must be based on the requirements and conditions, i.e., an ongoing shaping process must take place, including the priority of individual projects as well as the availability of budget and resources and, last but not least, the situational development of the individual projects. The following figure illustrates a PPM process:
As in project management, the planning and shaping of a project portfolio requires the help of specialized software products, which allow complex project landscapes and organizational structures to be displayed, while at the same time allowing the portfolio to be evaluated and processed. PPM software must answer the following questions:
Which projects are planned or implemented?
What is the priority of the individual project?
What capacities can be used to what extent?
Are the resources planned according to their competences and the project priorities?
Which projects can be implemented with the given resources capacity?
What are the options for resolving project and resource conflicts?
What are the dependencies to other projects?
It is crucial to ensure an understanding of the portfolio situation through transparency and ease of use, and to enable the users to develop alternative scenarios with just a few clicks.
The Way to Effective Portfolio Management in Financial Services
The implementation of a suitable process to ensure the targeted flow of information within the
company is just as important, but often more difficult, than simply selecting the right tool. How do the necessary data come into the PPM software? How are both new project ideas and status information from ongoing projects merged and prioritized? How can the measures for portfolio optimization obtained on the basis of scenarios be brought to a vote and ultimately adopted as the new plan?
These decisions pose a number of challenges for the PPM managers, also in the context of political structures within the company. Transparent portfolio management requires clear decisions regarding the prioritization of projects and reveals optimization potential in the planning process. This transparency is not desired by everyone.
Furthermore, the introduction of an effective PPM process requires at least minor organizational changes with regard to related activities, roles and votes. The connecting element is the anchoring of the PPM software along the PPM process. The more the tool is used in each step of the process, the higher the quality and up-to-date the data will be, and the greater the transparency of decisions as well as the quality and speed of problem solving.
Experience shows that portfolio management is successful when a top-down approach is followed. The design of the portfolio based on corporate strategy ensures that the important and correct projects are given priority. The remaining capacities can then be distributed in favor of subordinate projects. Therefore, the mere management of the portfolio, which typically results from a bottom-up planning approach as a result of a “survival of the fittest” competition of individual projects, deviates from an active portfolio design.
Top-down portfolio planning
Strategic fit and priorization
The right and strategic projects “in quality, time and budget”
Bottom-up portfolio planning
Management of conflicts and shortages
Battle of projects
Ideally, this leads to a focus on quality rather than quantity – and thus fewer maintenance notifications. So that on future Saturdays, your coffee never falls from your hand again.