Godzilla with an itch - Banks' issues with Technology

That itch, damn it is frustrating and annoying but still can’t get rid of that itch, it's there, right there.

As the folklore goes it is said that when Godzilla gets an itch at his back he generates lightning to tickle his back and get rid of that itch, but with age, the power to create that strong lightning diminishes and it needs a giant flying dinosaur to scratch its back.

I would like to extend this analogy to corporate culture where Godzilla can be the big banks AND financial institutions, and the itch is to bring something new to the market or to shake the culture to keep things edgy, and the giant flying dinosaurs are the McKinseys or Accentures of the world who would help these companies scratch that itch.

The Itch will keep them awake at nights, but just enough that they won’t go crazy, but still, that itch remains. Dinosaurs keep finding inefficient processes, closed thinking, broken workflows, non-responsive staff and even a need to shake the mindset, but some itches will last longer. Driving Agile in the organizations is one of these itches that keeps coming up in discussions.

Banks do realize this is a problem. After investing huge amounts of money and committing to the cause, the change is happening very slowly, sometimes even unnoticeably slowly. It's not that the Agile movement isn’t progressing. We’ve seen tangible benefits from the new product cycles and things are picking up, but the gaps in the whole process are glaring.

New Engine in a Vintage Classic

Organizational agility is more than tech adoption of Agile methodologies and shifting the Fixed mindset to growth mindset for Product development. Organizations have to move from Project thinking to Product thinking as well, and that comes with the whole restructuring of PMO organization within the company.

Today all the support structures in the company are created to assist PMO and projects to perform at a traceable and trackable lifecycle. Right from the planning, to budgeting, to the allocation of funds, to Capex & Opex classification of work and even maintaining P&Ls as per the annual financial cycles to assist in identifying the profitability of the projects and IT effort put in. These are established processes and it took them decades to mature and become reliable and repeatable in the organizations.

Organizations try to transform the tech side of processes into Agile while keeping the rest of the support structure in a Projects model. We all know how different Agile sprints or Kanban streams are in respect of planning for an annual cycle. We are letting market forces decide where the product roadmap will lead to, but we still try to control it with a lasso of controlling finances for the project teams.

It is just a game of Money honey!!!

Instead of just blaming the current organizational flaws around making a product within a Projects setup, I want to put an argument in favor of the current organizational setups too. Even though the companies had a project organization, the outcomes were Applications with a fixed lifecycle of 5-10 years with cost invested in CapEx expected to depreciate in that timeframe.

Many of these Applications undergo feature enhancements and extended lifecycles, then what is so different between these applications and the Product Development we talk about these days. I understand this will trigger the classic Project vs Product management debate and we know the basic facts that both hold their different benefits and shortcomings.

The major part that is impacting current case is the mindset and the skill difference of the personnel involved in building and managing these Products. Project Manager running a project to build an Application and then handing it over to a BAU manager used to be a process that was filled with agonizing short and inadequate transition times.

In the current Product setup, the same manager is supposed to build and support the application throughout its lifecycle. Keeping organizational attrition aside this is a fantastic idea because now project manager will not be handing over the ownership to someone else and then washing his hands off the responsibilities of fixing the bugs. He/she will have to own it in entirety.

But the issue of Finance management still remains. The classic Change The Bank (CTB) and Run The Bank (RTB) approach for budget split needs to change to support a full Product lifecycle for these applications. Depreciation model will have to be revamped as well to support this change.

Proposed changes may lead to IT expenditure showing a bump of 4-5% just to absorb this new approach. Are the companies ready for this shock? Would they be able to explain this to their stakeholders? Would CFO be willing to bite the bullet only time will tell?

A few courageous CFOs may have to make the change in the way we budget these new products and bring the industry into a new era. Or am I just being overly optimistic?