It is impossible, as an innovator working in a bank, to avoid the realisation that no matter what you do, you are going to have to work closely with the information technology organisation. Day to day, this means having a relationship with technology professionals (even if you’re not in IT yourself) and recognising their unique outlook on the business of banking.

Specific innovations can either be made or broken by the IT folks. If they say something is too hard or too expensive, there is usually no recourse available. That is especially true for innovations which must touch primary bank infrastructures – the core banking system, channels such as the branch and Internet, or key back office systems.

On the other hand, winning over the IT organisation can usually grease the path of an innovation. Making IT an ally is a relationship investment well worthwhile. But IT organisations are prioritised quite differently to those which are concerned directly with doing business with customers. Understanding that prioritisation is exceedingly helpful when trying to win over the IT people so they will do things that are genuinely new.

The number one priority for most IT organisations in banks is ‘keeping the lights on’. For Chief Information Officers, this means running (the often antiquated) computer systems keeping transactions flowing is what they spend the lion’s share of their resources on.

Changes to systems are hated because they are another opportunity for something to go wrong. When a system fails, there are inevitably significant consequences. Imagine the situation where a core banking system goes dark at the height of the Christmas spending period: not only are multiple business lines inside the bank screaming, retailers being served by the bank are doing so as well.

Controlling change is a mantra for IT organisations in banks. Given the opportunity to avoid a change, most IT Chiefs will do so. Unfortunately, though, almost everything an innovator does is likely to need a system change. This presents the key dilemma for an innovation professional: how to represent a change (which will likely have small short term returns) in a way that avoids it being subordinated by changes which have significant and immediate benefits.

It has been estimated, worldwide, that up to 80% of IT budgets are spent on the task of keeping the lights on, a percentage that has been rising for some time. One of the main reasons is yesterday’s innovation, especially if it undertaken earlier relative to peers, is likely the legacy of today. Legacy systems in banks have a cost profile that increases over time, as key resources needed to maintain them become more scarce.

It is not atypical, for example, that a system which has been running an institution for decades will face a cost inflection point during the latter part of its lifecycle.

Possible reasons for this occurring are many-fold. Perhaps the hardware on which the system runs has been end-of-lifed, and the institution is reduced to scavenging parts on open markets (I know of several institutions who buy parts for old equipment on EBay because there is no other source available).

Another common reason is that individuals who have been associated with a system for decades are retiring from active service. Or perhaps the source code – the original human readable program statements forming the system – have been lost and are no longer able to be modified easily.

Whatever the reason, inevitably, computer systems become less and less transparent with age, and the risk to service levels increases. Talk to a CIO about a change to his core banking system, and there had better be a very good reason before an innovator will get much traction in the discussion.

The second priority for IT resources is almost always doing change mandated by various regulatory and compliance regimes in place. The body of regulatory pressures a typical bank must accommodate is huge and growing constantly. Regulatory changes are often expensive. For example, when Basel II compliance became an issue in the 95 countries that have indicated they will adopt it (by 2015), the IT system changes to support new capital adequacy regimes were massive.

These priorities are about sustaining existing revenues, not about creating new ones, which is the primary function of an institutional innovation function. The conflict between the goals of the two organisations can be a difficult thing to resolve at the best of times.

But there are further priorities in the IT organisation which can make things even harder.
After the CIO has dealt with regulatory changes mandated to his or her systems, the next priority will be servicing specific requests of major lines of business. There is never enough resource to do everything asked for, so inevitably, the CIO will choose to do work for those business units whose revenues are most significant to the institution over all.

Generally speaking, large business lines in banks will tend to make investments which are broad in scope. They will do this because the returns on those investments need to be significant in the overall scheme of the institution. Anything without material consequence will be de-prioritised in favour of such investments, even if their long term benefit is likely to be significant. For the IT organisation, this inevitably means projects will be large, complex in scope, and affect key systems in significant ways.

The CIO, faced with such ‘iconic’ projects, will undoubtedly do everything possible to ensure any possible risk can be eliminated. The consequences of failing to doing so are likely to be serious: future revenues are placed in jeopardy, not to mention the personal credibility issues that follow whenever something significant is delayed or fails. Steps taken at this point include cancelling anything ‘distracting’ to the projects delivering benefits to the core businesses.

The final thing a bank CIOs usually wants to achieve is cutting costs of existing information technology operations. After people, IT is generally one of the top expenses an institution incurs, so cost savings achieved here can have substantive bottom line benefits. Chief Executives, always looking for improvements in cost to income ratios place constant pressure on CIOs to examine every investment carefully, cutting back to the bone as much as possible.

All this drives behaviour which is the antithesis of what innovators need in order to accomplish their jobs. Experimentation is discouraged, since investments that do not go directly to the goals of the IT organisation are a luxury that can be cost controlled. Projects are strictly risk managed, and laden with process to ensure they remain on track (and most importantly) run as little chance as possible or going outside their mandated budgets.

Such investment monies as do exist are channelled towards rectifying critical issues that underfunding has left to ferment for years. And failure of any kind is frowned on. After all, there is no money to waste, even if such failures are instructive.

Is it any wonder, then, that innovation teams can often be seen by the IT organisation as internally divisive, hard to control, and best kept at arms-length for as long as possible? What else would you expect from two teams who priorities are this misaligned?

This is an excerpt from “Innovation and the Future Proof Bank” by James A Gardner, published with permission by John Wiley and Co. futureproofbank.com