Digital transformation in banking: How not to fail

Despite the best intentions, we have seen multiple carefully planned digital transformation projects fail. This happens even when the procurement procedures are carefully planned, and the bidding processes are designed to yield appropriate yet cost-effective choices. 

The most common reason for this can be summarised by the saying “the devil is in the details”. Issues that once appeared minor, begin piling up and contribute to more substantial issues. Eventually they cause delays, additional work, and increased costs, as the schedule and budget start to slip. 

How can banks avoid this, and what makes a successful project?

In the cross-roads of IT & business

There seems to be two constants that surface as explanations for client satisfaction: having experienced people with open minds and acknowledging and embracing different types of approaches. In the world of banking, things may seem quite similar on the surface, as all banks must adhere to the same regulations, but in reality, their IT systems can vary significantly.

Taking this into account, the difference between a successful and an unsuccessful project is often one person – the “someone from IT”. Typically, this person is experienced, IT-oriented but with an understanding of the business and inspired by the opportunity to learn new things.

What seems to produce especially good results is the way that this person embraces the new solution as-is, wants to understand it and convinces colleagues to build processes around it. 

In the absence of an actual internal expert, an experienced, neutral third party – typically a service integrator – can also do the trick, providing they have experience in similar transformation projects and know the technology. 

Shifting focus to the back office 

Many of the package solutions in the market were originally designed for a specific environment and to serve a certain purpose. Trying to implement such a solution into another model may not be straightforward, since even though the selection processes aim to spot differences and potential issues beforehand, it’s impossible to spot every single one.

One of the main problems is that the requirements are often set by the end users of an existing system. The idea is respectable, but people are often used to certain routines and want to duplicate similar requirements for the new solution. Changing the user interface or behaviour is often much easier than changing the logic in the back office, which tends to be much more expensive. These back-end related tasks, however, were rarely in the spotlight until they became showstoppers.

Since many projects will face issues, the key is how to deal with them. When issues arise during the project, two things will become important: Is there room in the budget and what is the relationship with the supplier? 

Invest in a proper Proof of Concept 

Good management relationships are especially valuable when discussing budget issues, but some issues are more difficult to solve than others. When they concern the core of a package solution, the only way forward might be to change surrounding systems or business processes. It will be a tough exercise for the supplier and even harder for the bank.  

RFI and RFP processes are often based on paper exercises. The buyer presents detailed questions and requirements, and the supplier answers them. It’s a labour heavy task, but it’s possible to spot potential gaps. Let’s assume a heavy RFP questionnaire can cover 80% of the details. What to do with the remaining 20%? There are roughly two choices: leave them for the project or run a thorough Proof of Concept (PoC).  

Launching a new medicine without going through proper laboratory tests is not only risky but also irresponsible. Similarly, starting a larger project without a Proof of Concept (PoC) can have detrimental consequences. A PoC serves as a crucial step in the project lifecycle, allowing stakeholders to assess the feasibility and viability of the proposed solution. 

By investing the time and resources into a proper PoC, organizations can significantly increase the chances of a successful project outcome and avoid costly mistakes. That's why a proper PoC should be designed as part of the RFP process itself. 

To summarise: 

• Too much focus is placed on the user experience: users are flexible and can change their routines when guided properly.
• More emphasis should be placed on back-office tasks such as accounting.
• Letting issues pile up suffocates change management.
• Trying to please every single requirement suffocates projects.
• Don’t simply hope for the best but instead prepare for issues that will most likely appear.
• Find your IT expert – they will be your best asset in the future after the project ends.
• Unless you own a crystal ball, be prepared for change. 
  
  

Written by:
Tommi Hinkkala
Senior Sales Manager at Siili

Tommi Hinkkala is Senior Partner and Sales Manager at Siili Solutions, where he is building an ecosystem of best partners and identifying solutions for banks and other financial institutions. Prior joining Siili, Tommi  has an experience of two decades in banking and Finance and picked up experience in Tieto, Sampo Group, Worldline, Temenos and Mambu during which he helped numerous customers in the Nordics and Northern Europe.