WHEN I.T. GETS IT

When financial services organisations find themselves under pressure to reduce costs or improve customer service, IT is their normal ‘go-to’ solution. Yet the results are consistently underwhelming.

It is common for IT systems to be delivered late, go over budget, be de-scoped and, perhaps worst of all, when finally installed make the job of serving customers harder. As the recent system failures at RBS and HSBC demonstrate , IT changes can paralyse even the least complicated of customer transactions, paying money in and out. It’s fair to say that customers’ experience of financial services is dominated by how the IT works, whether through direct interaction online or via agents all too often telling us ‘Computer says No!’.

Not surprisingly, the most vocal champions of IT-led change are those with a vested interest in IT being used as widely as possible. Whether development and support activities are provided by internal IT/digital departments or, as is more common these days, external outsourcers, both need large budget allocations to stay in business.

The amounts involved are hardly trivial. According to research by Celent published in Computer Weekly (12/2/15), European banks spent £41bn on IT in 2014, rising to £42.23bn in 2015 and £46bn in 2017. It’s easy to see how IT budgets in individual institutions can run into the hundreds of millions and why every major financial services outfit has a highly paid Chief Information Officer or Chief Digital Officer on the board to be accountable for the spend.

Are these huge capital and salary spends justified? Or is there a way of ‘doing IT’ that achieves better results at lower cost? According to our clients, the answers are respectively a resounding ‘No’ and ‘Yes’.

When IT ‘gets’ the better way of doing IT, the normal IT/operations dynamic is transformed, making possible results beyond anything the parties would dare to expect. This is because, when all the mumbo-jumbo and hype is stripped away, the real issues facing IT in financial services are:

• Working out what the function should be doing

• Establishing its real purpose

• Learning how to do IT better and better IT

• Creating better ways to judge how well the first two have been achieved.

Leaders in IT who focus on finding answers to these questions are thin on the ground, but their numbers are beginning to grow as they start to see the sense in changing the way they determine ‘what to do’. They recognise that traditional approaches have not served them, their organisations or, most importantly, their customers well. Whether the task is project activity to create new platforms or making changes to existing ones, the typical process of business-case submission, change request, business and technical analysis followed by specification and ‘gating’ steps to release development and implementation funds is at the heart of IT failures.

This is the process promulgated by the organisations with most to lose if there were changes, i.e. the major IT hardware, software and service suppliers – and the process makes perfect sense if you accept the assumption that operations people are capable of articulating what will improve service to customers and that IT people can translate what they hear into workable solutions. Working to a specification does serve a purpose in that it gives IT suppliers, whether internal or external, a get-out-of-jail-free card in the form of ‘We delivered what you asked for’ – but in all other respects the assumption is flawed.

Is there a more productive way of applying IT? We think there is. When people in IT are willing to look at the system outside-in, from the customer’s point of view, using the Vanguard Method, they discover a different perspective on the source of change within the organisation. They learn that their purpose is not to deliver IT, hardware and code, but to add value to ‘the work’, that is, make it work better for the customer. They learn, often to their dismay, that the measures they have been working to – ‘delivery on time’, within budget and to specification – are paradoxically locking them into an unhelpful paradigm that is actually costing their organisation millions.

The first step in achieving this change in perspective occurs when IT staff begin to understand how ‘the work’ works for the customer. To do this, they need to spend time in the work with people who deal with customer demands and in places where customer’s ‘digital’ demands end up when they are inadequately met. This analysis, or ‘check’, will allow them to see how and how well the current IT delivery model works from the customer and user perspective.

They can then take an objective view of how they interact with the rest of the organisation and how well that relationship is working, knowledge that helps them redefine how IT should work with, and add value to, the core departments handling customer demand. It becomes a joint activity with people in the operation, with a focus on collaborative learning.

During this initial phase, the IT department of one of our clients learned it had separate lists of overlapping IT change requests and project specifications from different lines of business. The requirement to give customers valuations on their products was duplicated on each list and would have formed a part of the development work undertaken on the different projects. The IT department was aligned and structured according to the different lines of business, so different people in IT were responsible for managing the departmental and product-based lists. The functionally-derived lists hid common demands from view. When the people undertaking the study looked at the lists from the customer’s ‘outside-in’ perspective, they could see common themes and requests.

In another client, the IT team took change requests and project specifications back to the operational owners to get their view on how the proposed solutions would help deliver value for customers and how the benefits would be measured. It soon became obvious that few of the projects would help frontline staff deliver what customers wanted. Discovering that no one in the operation can clearly explain how any of your proposed IT solutions will benefit customers can be a sobering and salutary experience.

So from a starting assumption that, of course, the current method delivers what operations needs, it is a relatively short step to people being willing to give up their current method in order to learn how to do better things with IT.

There is only one way to do that, and it is by direct engagement of IT people with those who actually do ‘the work’. The result is an attitudinal change in which IT no longer views itself as a stand-alone department remote from and waiting for ‘orders’ from those on the front line. Instead the focus is on adding value to and creating value for ‘real’ customers.

There have been many attempts to improve conventional IT delivery models. The latest great white hopes are approaches known as ‘Agile’ and ‘Lean Startup’, which as their names suggest attempt to speed up and streamline the traditional model. But there are potential problems with both, since neither automatically starts from an outside-in analysis of predictable demand from the customer’s point of view. What Agile lacks and Lean Startup ignores is a means of establishing whether what is being worked on helps to improve the core business. Smaller specifications delivered more quickly is not a fundamentally different thing for IT to do.

To ‘get’ this – to avoid having IT working on the wrong problems – the first essential is to resist the temptation to start with a ‘specification’ step and instead to replace it with an ‘understand’ step. Understanding the ‘what and why’ of current performance as seen by customers is crucial, since it provides everything IT needs to see what isn’t required.

Most financial services organisations have invested heavily in workflow management systems to log, scan, sort, batch, queue, allocate and measure work and worker activity. These tasks tend to be highly valued by management but, paradoxically, are often a major cause of failure demand. When ‘the work’ is studied using the Vanguard Method, the impact of workflow systems and how they make things worse for customers and frontline staff becomes immediately obvious. Listening to or reading what customers ask for at major points of contact (contact centre, helpdesk, sales support) reveals how other IT systems also disrupt flow and in so doing cause the customer problems, resulting even more failure demand that is then logged, sorted, batched, queued and allocated. It is not uncommon for this Kafkaesque cycle to go through many iterations before a simple request is resolved.

Having learned what not to do, IT people, alongside people in the operation, need to identify what is required to improve the customer experience without the aid of IT. The temptation to jump in at this stage can be extremely difficult for IT to resist. But the rule is that redesign must take place before any IT development is undertaken. This avoids building unnecessary functionality into the new platform and eliminates any ambiguity surrounding the respective roles of IT and people in the redesign.

So rather than creating a workflow system to manage the tasks associated with resolving issues for customers – the normal solution – IT might simply need to design out failure demand (‘demand caused by a failure to do something or do something right for the customer’) by improving brokers’ access to existing systems. The result is IT ‘pulled’ by the customer, through the redesigned work into a simple, elegant solution that is both great value and is greatly valued. ‘Understand – improve – pull IT’, replaces ‘specify –create – deliver – iterate’, as in the Agile model.

To judge how its work adds value to the users, IT needs to adopt purpose-related measures designed by people in the front line to help them ‘improve’ the experience for the customer. For example, if what matters to customers is how long it takes to settle an insurance claim, IT will judge a change or system against the operational criterion of end-to-end time. As traditional targets and goals are replaced by measures reflecting the experience of customers, IT can clearly see the impact of its interventions on the wider business.

IT is simple. At its heart it is just bits and bytes, ones and zeros. Financial products are simple too, just records held in accounts with algorithms applied to increase or decrease rates of return or take away or add to a balance. The real complexity, and potential competitive advantage, lie in how financial services organisations interact with their customers and what matters to them. In that sense, IT’s most important function is to not get in the way of customers pulling what matters to them from the organisation in the most timely and most efficient fashion. That’s not too much to ask for, is it?

---

maarten.goedee@vanguardconsult.co.uk

Read similar articles in Edition One of The Vanguard Periodical: The Vanguard Method in Financial Services. Download it here