Category: News

Casino banking

Posted on by

Will Pyke, Vanguard Consulting

Sitting at a table on an early morning train to Manchester, I was intending to use the journey to do some work. That was before three smartly dressed, articulate young compatriots joined me and proceeded to order half-a-dozen cans of cider – which turned out to be their ‘work’ for the trip.

Wondering why the cider at 7am, I clocked that one of the three was wearing playing-card cufflinks. From that I assumed they’d spent the night in a casino and had a hard night battling the odds. I was right about the odds but wrong about the casino.

It turned out that my festive companions worked in the complaints-handling department of a major retail bank, based in Scotland. They were celebrating the end of their last day’s (or rather night’s) work for the week and were on their way home. High pay for anti-social hours enabled all three, who lived in England, to make the weekly commute to Scotland and still take home generous pay. Their motives for the lifestyle varied: one was saving a deposit for a house, another paying off student debt, the third living ‘the high life’.

Their job success hinged on completing three complaints cases a night. Over the course of the first three cans of cider they proceeded to compare notes on their standard methods for meeting the targets with the least possible effort.

How to meet targets 1

The favoured method involved getting to work before their supervisor to allocate themselves their first case for the night. This meant that when the boss arrived, they were already halfway through their (self-chosen) first case. Choosing easy assignments with minimum calculations enabled the three amigos to polish off their first cases while the boss was still occupied with her admin – allowing them to cherry-pick their second cases too. They could then let their boss allocate their final cases from the difficult pile, secure in the knowledge that they could finish even the toughest ones in the half of their shift remaining. By completing a ‘hard’ case every night, they’d be seen not only as diligent and efficient, but also as ‘team players’. Best of all, though, their strategy ensured they always hit the three-a-night target.

So where’s the harm, you may be thinking – a little gaming of the system, but the required work is getting done, isn’t it?  For sure, three cases are being performed. But productivity is being manipulated, so the figures are unreliable. Cherry-picking may mean that some cases are ignored altogether, while the relationship between manager and workers seems to have taken on a latent parent-child dimension.

More worrying is that I’ve observed similar behaviour – cherry-picking and other means of gaming the productivity numbers – in almost every organisation that employs activity targets (that is, targets based on measures of efficiency – service levels, number of rings to pick up a phone, hours or days to respond to a call – as opposed to overall effectiveness). The exceptions have displayed related but distinct dysfunctions.

How to meet targets 2

For example, in the bereavement-handling back office of a large retail bank – where the accounts and financial holdings of deceased customers are closed down or otherwise resolved at the request of surviving relatives – the staff were again working to an activity target: in this instance three ‘cases’ an hour. As in the complaints-handling example, the workers had worked out ways of achieving the target even though, in this case, the IT system prevented cherry-picking.  Instead, workers would send out letters requesting information already on file or clarifying points already understood, fulfilling their target but not the relatives’ wishes, and building a backlog of unfinished work in the department.

The frontline workers weren’t necessarily being insensitive. Under pressure of the 20 minutes a case, it was easy to miss that their branch-based colleagues had noted these details upstream. Newly hired staff on probation were under additional pressures, since failure to meet their target by the end of their induction meant they would not obtain permanent contracts.

In haste, volume targets were often met at the expense of quality. Most of the mistakes were small, but in the circumstances even minor errors such as continuing to send out a mortgage statement in joint names could be deeply upsetting – and customers often phoned in to say so.

Treating quality as a separate issue to the enforced productivity, different teams specified procedures for ‘error-proofing’ common mistakes and then inspected both the work of the workers and that of the checkers. The wasted effort was significant, while error rates remained unchanged over time as their underlying cause – haste – was ‘designed in’. In one of the most ironic features of the whole setup, quality and error rates were themselves subject to targets, with predictably perverse consequences.

The worker or the system?

The problem in these examples is assuming that the workers can be held exclusively accountable for their work. That is – in the complaints-handling example – assuming that a colleague completing fewer than three cases a night is incompetent or ‘shirking’, while a colleague who chalks up better than three is a ‘hero’. In this way performance is personalised, while many other explanations for differences in the quantity of work produced by individuals is ignored – for example, clarity of instructions, complexity of the complaint, number and nature of the product holdings, nature of the calculations for redress payments (where applicable), degree to which IT supports the work and the ease of accessing and using it, presence or absence of activity targets and degree of knowledge and skill of the worker (resulting in turn from selection and training processes of the organisation), and the motivation of the individual (linked as it may be to the hours of employment, nature of the work, environment and a myriad of personal factors).

The same assumption – that workers are the dominant factor in performance – is at the heart of forced-ranking (‘rank-and-yank’) performance-management systems, in which ‘lowest’ performing colleagues over a period are ‘managed out of the business’, in other words, fired.

Yet we know from the writings of W. Edwards Deming among other authors that performance variation between individuals in any team is governed by the system in which they work. In simple terms, people need three things to do a good job: information about what to do and how well they are doing it, equipment that is fit for purpose and simple to use, motivation undistorted by external incentives, and an interesting job to do. Where these elements are in place, the creativity of colleagues and managers can be brought to bear on improving work, rather than gaming it.

Don’t game the work: improve it

In such an environment our three amigos and their boss might jointly be working on improving the reliability and consistency of the redress calculations or the decision-making of colleagues, or eliminating the cause of the complaints in the first place. In the bereavement-centre example, colleagues and managers could work together to resolve cases in the most timely fashion, anticipate predictable follow-on requests from solicitors for tax deduction and interest payment certificates, and improve access of colleagues to ‘specialist’ product information that is not ordinarily accessible via the IT platform.

Without consideration of the system in which people work, ‘performance’ will likely be attributed to them. Even though they are well aware of many of the causes of performance variation, the primacy of activity measures – reflecting an underlying preoccupation with cost – and the rigidity of performance-management practices – reflecting a belief in the primacy of personal determinants of performance – mean that those individuals will do whatever it takes to survive in the system of work in which they find themselves, even if it means playing dice with productivity and the quality of the work.

All of which is to say that I didn’t get much work done on my way to Manchester. But I did have an interesting journey.

will.pyke@vanguardconsult.co.uk

Read similar articles in Edition One of The Vanguard Periodical: The Vanguard Method in Financial Services. Ask for your FREE hard copy or PDF.

When IT gets it

Posted on by

Maarten Goedee, Vanguard Consulting

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

The assumption presumption

Posted on by

Steve Thorne

Why do businesses make key decisions based on assumptions rather than actual data?

It is a question I find myself regularly asking, particularly when working with clients in the financial services sector. Commonplace as it is, the practice is misleading and inherently risky.

Dangerous assumptions

For example, a common assumption relates to service level agreements. The assumption is that the agreed service level equates to a good level of service, thus if the specified service level is being hit, performance must be good. Data on the achievement of service levels is almost always readily available.

However, when I ask for actual data on what customers predictably ask for, what matters to them and how well the system currently achieves it, it’s a different story. In fact I’ve yet to work with an organisation that could provide that information without an intensive exercise to collect it from scratch.

That’s alarming enough. Even more alarming and damaging is that when customers complain of poor service, the organisation frequently responds by arguing that it must be the customer’s problem – after all, the service level is being met so how could it be the organisation’s fault?

Another common operating assumption is that higher volumes will automatically translate into better results – for example, more outbound calls will result in increased sales or more arrears collected from customers in debt.

In these systems, data is readily available about activity – the ‘dialer spin rates’ (the number of calls made by automated dialer IT systems), how many times the phone is answered and such like. Yet tying together actual data about the type and frequency with which customers bought or if not why not, or the type and frequency with which customers paid and if not why not, often requires a whole new exercise to learn about these important levers for understanding and improving the system.

Assumptions vs data

How and why does this perilous over-reliance on assumptions arise?

One common response is that in a large and complex business real data is hard to collect and calculate. That may be true, but even so it should set alarm bells ringing. Shouldn’t the organisation be focused on learning how to capture and use actual data to make informed decisions, rather than presuming that untested assumptions are the right ones?

Another less obvious and more alarming possibility emerged from a conversation in which a friend relayed to me a question his science-student daughter had posed over dinner: ‘Dad, why is it that in the world of science most hypotheses are disproven, yet it seems from our discussions that most hypotheses in the business world somehow find a way of being proven’?

Good question.

Is there so much pressure in modern business to make the budget and hit the targets that organisations prioritise ‘proving’ hypotheses over doing the hard work of learning how to improve the real data? In other words, if the data suggests that the decision to use the assumption was wrong, the temptation is either to adjust the assumption or manipulate the system based on it to make the outcome come out right.

Thus, if the system is failing to hit the service-level target, the easiest solution is to adjust the service level or stop the clock. Or if the ‘abandon-rate’ target is not met, the temptation is to adjust the average handle time – and then be surprised that call volumes increase, because more and more customers call back to pursue problems that were not properly fixed the first time round.

Far from leading to better understanding and hence improvement of performance, this manipulation of the assumptions just serves to further sub-optimise the system.

Worse, the assumptions get translated into apparently objective ‘data’ which seemingly show the organisation achieving the goals it has set itself. As it is passed up the line, the fudged ‘data’ becomes the basis on which more and more management decisions are made.

This is dangerous territory, and much more common than might be expected.

Please don’t misunderstand me. I’m not saying that testing a hypothesis is not important or useful. Quite the contrary, it’s a fundamental principle for a learning organisation.

A better alternative

So what’s the alternative to proceeding by assumption?

The first priority is to get clear about the real purpose of the system, from the customer’s point of view (‘outside-in’, in Vanguard parlance). The second is to adopt measures that are directly linked to this purpose.

In the case of a claims-type system such as motor insurance, measures might include the end-to-end time, from the claimant’s point of view, it takes to fully settle a claim, and the type and frequency of barriers to settlement. In many cases settlement delays create extra costs (in additional need for hire cars, for instance), so linking these measures to the actual consequences for cost is crucial.
If measures are unrelated to purpose, they will not only not reveal how well the system is doing what it is supposed to do, they will create a new, de facto purpose that distorts and sub-optimises the system, as above.

Measures to connect actions with consequences

It is also essential to learn how to capture and use actual data to learn what your system can predictably achieve and the variation within it, usually involving capability charts (for more on this see the Guide to Creating Capability Charts).

This will suggest opportunities for action that can be tested and measured to understand the relationship between action taken and consequences for performance. It provides a scientific and systematic means for identifying ways to improve performance, by connecting actions with consequences.

For example, in an arrears-type system, why and how often do customers go into arrears, and what kind of customers have done so in the past? Understanding why customers have fallen into arrears enables the organisation to make decisions based on data, not opinion or assumption, about where to act. For example, the underlying cause may often lie elsewhere in the system – for example, problems with statements or direct debits. In that case the obvious point of intervention would seem to be pro-active work to reduce the number of customers falling into arrears, and requiring expensive chasing, in the first place. Data over time will show the consequences of trying different prevention methods.

Ending the numbers game

Acting this way challenges the organisation to use its ingenuity to interpret and act on actual data, rather than spending its time developing elaborate assumptions that risk clouding rather than clarifying opportunities for improving performance. The predictable result is learning where and how to improve performance systematically and sustainably.

So ask yourself, how much of your organisation is spending its time playing numbers games that hide real performance, rather than helping you to learn?

An inside job

Posted on by

Keith Bennett

Good things come in threes….

It looked like the perfect job.

It had everything I was looking for:

1. A bank that wanted to be a systems thinking organisation, using the Vanguard Method

2. An opportunity to use my knowledge and experience to help to improve service, reduce costs, increase capacity and work towards achieving the corporate goal

3. An excellent package: competitive salary, award-winning pension scheme, share scheme, generous holiday allowance…

I had been a Vanguard consultant for five years, working with leaders and the front line as an ‘external’ consultant, helping my clients to ‘see’ from the customer’s point of view and to understand the ‘what and why’ of service delivery. While every job was different, for me there were two common themes: first, the enthusiasm and passion for change generated by teams using the Vanguard Method, and even more the excitement when they witnessed the results; and second, my heavy-heartedness at leaving in the knowledge that I wouldn’t be there to see them develop and to witness their continued drive towards ‘perfect’. If I took up an internal permanent role, I reasoned, I could experience similar enthusiasm at the successes, at the same time as helping with the challenges that the organisation would normally face in my ‘external’ absence.

I got the job. I was to be an internal consultant, helping leaders, managers and frontline staff to understand their current performance and redesign their systems to achieve their purpose and do what mattered to customers – the consequences of which would be better service, lower costs, greater capacity and improved morale.

I couldn’t wait to get started.

On hearing my news a good friend and colleague at Vanguard offered me some words of wisdom: Remember, he said, if you’re an internal consultant you’ll have all the knowledge required to help the bank study and redesign its services – but you won’t have the full authority to make it happen, and that can be, well,…challenging. I thought I understood what that meant.

Three days in

For the first three days I was immersed in the bank’s values induction programme. I had played the induction games, did the encounter group stuff, fell backwards into a colleague’s arms, participated in the cathartic ‘drama’ which had been designed to demonstrate how we’d all learnt what the values meant and so on. This was all, of course, in the full knowledge that learning to live the values wouldn’t make a blind bit of difference to the customer’s service experience. But I had to give the organisational development folks their due – they didn’t know what they didn’t know and had, undoubtedly, designed the induction with the best of intentions. And, after all, the values were completely focused on the customer; the customer was to be at the heart of everything the bank did.

With the induction box firmly ticked, I had an opportunity to meet those that I’d be working for and with.

Three Directors

There were three key directors. I met with Directors 1 and 2 soon after starting. They had apparently worked with the Vanguard Method before and had ‘hands-on’ experience in previous roles. They were looking forward to working with my colleagues and me. Based on their approach and enthusiasm so was I. They both talked eloquently of the corporate goal – to be a systems thinking bank – and how this bank was going to be different. A bank that would have the customer at the heart of everything we did, that had clarity of purpose from the customer’s point of view, that had measures that would show how well we achieved purpose and did what mattered to customers, and managers who spent time in the work.
And you’ll be helping the teams to study their work and dropping in regularly to understand what they are learning and to assist with some of the analysis; and helping to remove obstacles to the redesigns; and helping to make the redesigns sustainable? I asked. Absolutely, they said. Fantastic.

Director 3 was harder to pin down. Two scheduled meetings were cancelled at the last minute. OK, these things happen. Finally a third meeting was arranged. He didn’t show. When we did eventually meet it was by chance on a train journey to another of the bank’s sites. We were both speaking at a welcome event for new starts. He was to talk about leadership, I was to talk about working on the work. Our messages could not have been more different. He talked about targets and working on the people, I talked about demand and measures that related to purpose and what mattered to customers. It was the first red flag.

I’d long known the absolute necessity of having an ‘engaged’ leader to head a successful intervention. Like all Vanguard people I knew that commitment is fine, but if leaders don’t spend time in the work they just won’t get it. When leaders don’t get it they see our work as a project, something that they can delegate to an ‘improvement team’, something they’ll get reports for, and updates on, at meetings…

I mentioned my observations about Director 3 to my own manager. She assured me that Directors 1 and 2 ‘got it’, having had previous experience of the work. Director 3 might take a bit longer.

But soon more red flags started appearing…

The bank was in the throes of migrating customer and service data from an all old IT platform to an all new one. But the new IT platform had a very traditional design. Hang on, I thought; surely we were going to be a different bank, not one that did a lift-and-shift IT system design? That’s what Directors 1 and 2 had told me – and part of Director 2’s remit was IT. Traditional IT designs get traditional results, not different ones.

Under the plan, each of the bank’s services would in turn migrate from the old platform to the new. The first would be Savings, which is where my work would start – helping an internal consultant colleague and team to study the new business Savings ‘system’ before the IT migration took place. We were to do ‘check’.

The three-legged stool

Vanguard people know that getting knowledge about the what and why of current performance requires what is referred to as a ‘three-legged stool’ – a leader, a manager, and a team of frontline staff – to study their system. Everyone needs to arrive at the same learning place at the same time. Without any one of these three legs the stool will fall over and the work likewise.

We had agreed a team design: it would consist of a manager and a group of frontline staff, and the leader would be the ‘Head of Service’. The directors agreed that they would brief the Head of Service on her role in participating in and supporting the team.

The Head of Service was one of those people that cuts a swathe through an open-plan office, gesticulating wildly as they go, leaving a trail of fluttering papers in their wake. She was too busy to talk when we first met, but suggested I organise a ‘catch up’ for later. That ‘catch up’ took some time…

The check team started its work. There was just one problem – the Head of Service never turned up. The team was not surprised – the members had already worked ‘for her’ before I joined. Still, the data was compelling and the team were lapping it up. As with all check teams they had learned that not all demand represented ‘value’ – in fact, in Savings they discovered that in telephony every other call was failure demand, that is, the knock-on demand created by a failure to do something or do something right for the customer the first time round.

Learning a method to study the system had invigorated the team, as it always does. Members said they couldn’t believe how broken the system was and, more importantly, how easy most of it would be to redesign. I had to keep reminding them: we’re just here to learn, to get knowledge, before we even start to think about redesign.

But their enthusiasm never faltered. One team member commented that this was amazing stuff – this bank was going to be different to everywhere else that he’d worked! Even in the study phase, they could see instantly that by making a simple change to a document they could ‘turn off’ a significant number of calls. That’s what the Head of Service needed to experience too, at first hand, by listening to calls.

Despite repeated requests, however, the answer was always the same: ‘Sorry, I’ve just been too busy. I’ll try to pop in next week’.

Directors 1 and 2 agreed to have a word and get the Head of Service ‘in the room’ with the team. They also undertook to see the team and understand more about what they were doing themselves – as had been promised many weeks ago.

It didn’t happen. The directors did have a word, but the Head of Service didn’t turn up, and nor did they.

They had all been too busy. Another red flag.

I was starting to become concerned. I wasn’t seeing what needed to happen. There wasn’t a lot of commitment, never mind understanding. Had I made a mistake? One night I wrote down the pros and cons of staying with the bank. I focused on the pros: I really should hang in there, it was still early days. In the months to come I referred to the list so often that I had to laminate it to stop it wearing away.

It became a habit: every night I’d do a quick review of my ‘Why I need to stay at the bank’ list in an attempt to persuade myself not to walk away. I mentioned my laminate habit in a ‘What have I done? I think I’ve made a mistake’ call to another friend and former Vanguard colleague. He laughed… a lot.

I made a last-ditch attempt to get the Head of Service to experience just some of what the team was learning. I explained that if she hadn’t ‘seen’ it for herself the team’s subsequent work of redesign wouldn’t make sense. She would simply end up rationalizing, justifying and defending her position.

Saturday mornings were good, she said – so we chose one on which to spend time together listening to calls from savings customers. The lines opened at 8.00am. I arrived at 7.45am, coffee in hand. But 8.00am came and went, as did 8.15am and 8.30am. She didn’t show. I asked a couple of managers when they thought she might be in – they told me I’d be lucky, they’d never seen her on a Saturday…
Why was it so important that she listened to live calls? What did I want her to hear?

Well, I wanted her to experience first hand the large number of unnecessary calls that customers were having to get something done that should have been done before: failure demand. Of course we could have listened to recorded calls together – but I already knew from the team’s work that the failure demands were predictable, and I wanted her to hear them live. This would have been a start, making her curious, leading her to spend time and discuss with the team, getting her to understand that the issue was the system, not the people, and that the real culprit was the management thinking that had created the system.

But it didn’t happen.

And there was no sign of the directors either.

Three little words can make a massive improvement

When customers deposited money in their new savings account they were informed that a Certificate of Deposit would be issued by return. But, predictably, customers would call a week or two weeks later to ask where the certificate was. Now you might think they were right to feel that was quite a long time – but that wasn’t the real reason we got the demand.

If and when customers got through the security questions and actually spoke to an agent (many didn’t), the conversation would go like this:

Customer: Hello, I’m just wondering when I’ll be getting my Certificate of Deposit?
Agent: Certainly, I can help you with that. When did you make the deposit?
Customer: On 1 August
Agent: OK. Yes, I can see it was sent to you on 3 August.
Customer: I have a letter dated 3 August but I haven’t received a certificate…
Agent: Isn’t there a print-out with the letter?
Customer: Yes, so there is.
Agent: That’s your Certificate of Deposit.
Customer: Oh. I was expecting a certificate – that’s what my welcome pack said and it’s what I was told on the phone when I opened the account.
Agent: No, the print-out is your certificate. Now, is there anything else I can help you with?

You get the picture. Adding the words ‘Certificate of Deposit’ to a print-out would eliminate at a stroke tens of thousands of calls that were a waste of everyone’s time and effort. That would free up capacity to deal with the calls that we did want. You know, the calls that sounded like: I want to open an account, I want to make a deposit, I want to withdraw funds and so on. That’s right, the ones that we really were here to deal with.

Easy. A no-brainer.

Well, not quite.

Monday morning arrived. No apology from the Head of Service – but she did say she would be interested to see my report on my findings from Saturday. I politely explained that a report wouldn’t help her get it – on which she walked away.

And that was that. As I knew she would, when the Head of Service, having spent no time studying the work from the customer’s point of view, heard what the team had learned studying the system she rationalized away the findings. And when it came to the simple step of turning off the highest frequency failure demand by using a principle of ‘sending customers documents that they can understand’, she told the team it couldn’t make the change ‘because there’s a freeze on all IT changes’.

The addition of three words – Certificate, of, Deposit – would cost too much money.

The bank’s new IT platform had been developed by a third party which had control of all changes. Because of the contractual set-up any change to an existing document would attract a charge.
So who put the freeze on IT changes?

The directors. They had implemented a total stop because the budget had been exceeded.
But how much was this perceived saving actually costing us in unnecessary calls serviced, capacity uselessly consumed and value calls going unanswered? The perceived saving was costing money.

I spent more depressing evenings staring at my laminated card. As part of the feedback to the directors on what the team had learned, we listened to recorded calls. The directors nodded their heads and winced in all the right places. Afterwards they said that while they understood the team’s excitement about what it had found and wanted to fix, they had to temper the enthusiasm – they had undoubtedly done a great piece of work, but these things would take time to fix.

One team member asked about labelling the print-out ‘Certificate of Deposit’. The directors reiterated that IT changes were frozen – the document would not be changed.

The disappointment was palpable. The team was told that its high-level redesign would be given ‘due consideration’. One member asked me ‘Why have we done all this work? I thought it was to make changes, improve our service, give us better work to do? Why won’t they do it? Why can’t they see how stupid they’re being?’ Another team member said, ‘I wish I’d never ‘seen’ at all, I’d rather still be in the dark and not know how easy this can all be’.

I watched the team members go back to their work. In the days that followed, they admitted they were starting to think the bank was no different to any other – and their leaders and managers were just like all the others they had worked for.

My heart sank. I consulted my laminated ‘Reasons why I should stay at the bank’ – and tried again not to give up.

Then it happened. The final red flag.

It wasn’t so much that the first migration of customer data fell over, dramatically – it was the response to the crisis from the directors. It transpired that the ‘robust pre-migration testing’ had involved no more than 100 accounts. No, really, 100 accounts. The bank’s telephony system was haemorrhaging with failure demand: I can’t access my account, why has no one phoned me back? Waiting times went skyward. The crisis lasted weeks. I had heard many, many distressing calls.

The directors’ solution was to bring in additional resource in the form of non-banking personnel. What mattered in their view was just answering the phones, not providing the expertise required to meet the demand at the point of transaction. The net result was tantamount to: ‘Hello, how can I not help you?’

The non-banking personnel were trained in the basics – they were taught to offer platitudes such as:

● Yes I’m really sorry to hear that
● I understand how you feel
● We have a lot of customers experiencing difficulties right now.
And finally an in-built handoff:
● I’m really sorry (again), but all I can do is pass a message on to my colleagues to phone you back.

Needless to say the handoff resulted in more work, an even larger backlog – and because it took so long for colleagues with expertise to get back to the customer, another round of failure demand in the form of: why has no one phoned me back?

As the crisis broke I sat down with Director 2. I had an outline plan that would help stem the flow of calls. It involved analysing the type and frequency of calls, understanding the knowledge required to deal with the failure at the point of transaction and then rapidly equipping colleagues with the skills to deal with it, meanwhile establishing the root cause and how to fix it.

After listening briefly, the ‘committed’ director told me that ‘what I had to understand was that in times of crisis, systems thinking and all that stuff is out the window – we just need to satisfy the regulator that we are answering calls, end of’.

That evening my laminate went in the bin. A ‘competitive package’ was no longer enough to keep me at keep me at a bank that was otherwise just like all the rest. I left and was fortunate enough to be able to return to Vanguard.

What would have kept me at the bank?

If I’d worked for leaders – directors who spent time in the work, understanding what prevents perfect and working tirelessly with their management and frontline teams to remove the obstacles that prevent delivery of real value to customers

If that had been in place, everything else would have followed – I and my colleagues could have helped leaders, managers and frontline staff to improve service, reduce costs, and create capacity, thus achieving my purpose – what I had been hired to do.

Three main learning points

What did I learn from the experience? Probably nothing completely new – but it did confirm that the principles for a successful intervention remain the same, whether the change agent is internal or external.

1. Just because an organisation says it will be different doesn’t mean that it will be. ‘Commitment’ by leaders is not enough – it must lead to action and action must lead to learning and understanding. Only then can decisions then be based on knowledge

2. If leaders won’t spend time truly understanding the links between their thinking about the design and management of work and performance – then don’t start work with a team. Once people have learned to see, they can’t unsee. There is nothing worse than helping frontline staff to ‘get’ what’s wrong and why and then have leaders not change the system because they don’t understand that it is their own thinking about the design and management of work that is the invisible barrier to change

3. Never take a leader’s understanding for granted – only believe it when you see it.
And maybe just one more…. a laminated list of ‘reasons to stay in your job’ really is a strong signal that something is seriously wrong.

The purpose conundrum

Posted on by

Toby Rubbra, Vanguard Consulting

Toby RubraLocation: UKcontact Toby

For leaders in service organisations struggling with poor Net Promoter Scores (NPS), multiplying complaints, mounting regulatory pressures and disruptive incomers threatening their market share, ‘becoming more customer-focused’ seems like the obvious remedy. To this end, their usual first step is to appoint managers with customer-facing roles and large budgets to drive what they might call ‘client-centricity’.

Yet as if the challenges of meeting their own function’s arbitrary budgetary objectives and targets weren’t enough, the new structure now confronts them with the need for yet more internal meetings to implement and monitor customer initiatives at the behest of the fresh-minted customer directors.
But hang on a minute. In the rush to implement solutions, no one seems to be asking why the organisation became un-customer-focused in the first place. Nor are they questioning whether building what is in effect a new function or sub-function, complete with budgets, strategies and projects, will solve the underlying problem.

The challenge of change

Herein lies the first challenge. If the organisation sees itself as basically successful – in the same position as, and no better and no worse than competitors – there is no compelling case for fundamental change. The leaders’ organisational worldview – basically that articulated 250 years ago by Adam Smith, based on division of labour and functionalisation to increase productivity, with attendant management “norms” of standardisation, specialisation, inspection and extrinsic motivation – remains intact. Part of this functionalised worldview is that operations and customer service are separate, so that there is one director for ops and another for customers. In this perspective customer service is a bolt-on to existing operations which assumes that problems such as poor NPS and rising complaints can be fixed by bringing more resources into play – someone taking responsibility for the customer, managers getting ‘back to the floor’, training the front line or doing stricter inspection.

Actually, the problem goes much deeper than that, to the very heart of management thinking. In today’s functionalised organisations, managers can’t see that the sub-optimisation of service that shows up in complaints and weak customer loyalty is inherent in the way the work is designed, and the way the work is designed reflects assumptions about purpose – what the organisation is there to do.

A question of worldview

Basically, organisations become un-customer-focused because they are torn between two different purposes – serving the customer and serving the shareholders. The problem with trying to serve two different purposes at the same time is that each has its own distinct worldview and its own set of action strategies for management. The balanced scorecard that often sits precariously in the middle between the two only compounds the difficulty by insisting that both are equally important. Why would one treat two differing compasses with equal priority in trying to reach to the same destination?

The prevalent worldview among managers today is that the purpose of the organisation – what it is there to do – is to make money for shareholders. Hence their primary purpose (compass) becomes to ‘deliver profits through increasing revenue and reducing costs’. With the latter hard-wired into personal objectives, promotion and personal wealth it is unsurprising that management ingenuity is focused on sales incentives and the rigorous control of operational costs, rather than on satisfying customers and their needs. Yet the relationship between the customer and the solution is naturally and crucially intimate. Focusing on managing the budget and meeting internal targets has the opposite effect to the one intended, causing existing customers to leave for other organisations that look after them better, and dissuading new customers from replacing them. Perversely, it drives organisations to become un-customer-focused.

Becoming really customer-focused

To create a customer-focused organisation – and to prevent it becoming un-customer-focused – it is necessary to abandon this worldview and replace it with different one.

In the alternative worldview, there is a systemic relationship between customers, the core work and the purpose of the system. There is no split between them. When the purpose is to deliver what matters to customers rather than what matters to shareholders, the organisation drives by a different compass. It focuses on delivering these outcomes and doing so by only doing the value work necessary to deliver what matters. In this way we ensure that our customers get what they want when they want it and, if we are ruthless about just doing the value work, costs fall as waste and failure are driven from the system. As customers talk well of us, more arrive. As a consequence of focusing on the customer, the brand, market share and profitability all improve.

Becoming customer-focused, then, isn’t a matter of adding a few customer-related initiatives to what is already being done. That is just an attempt to paper over the fatal flaw at the organisation’s heart – the confusion over purpose, over ends and means. To become more customer-focused, leaders have to change the worldview that, although not explicitly articulated, is implicit in the measures being used and currently governs how the system is configured and performs for the customer. The only way to change a worldview is the acquisition of knowledge. To acquire knowledge, leaders have first to be curious enough to ask why their organisation was not customer-focused in the first place.

toby@vanguardconsult.co.uk

This article appears in Edition One of The Vanguard Periodical: The Vanguard Method in Financial Services. Ask for your FREE hard copy or PDF.

An exploration into the failure of Lean

Posted on by

Are you curious about Lean’s failure to have an impact on the bottom line?

John Seddon and Brendan O’Donovan (Vanguard’s Head of Research) have written a new paper: An exploration into the failure of Lean.

It is available free of charge.  Leave us your email below to download the paper.

The purpose of the paper is to show that the ‘Lean’ movement is based on a flawed interpretation of innovations that originally occurred at the Japanese automotive manufacturer Toyota in the 1950s.

Seddon and O’Donovan argue that the codification of Toyota’s innovations ran counter to the instructions of the original architect of the Toyota Production System, Taiichi Ohno. As a result, modern leaders, spending millions on Lean programmes, are discovering that the results don’t fall through to the bottom line. Seddon and O’Donovan also illustrate what could and should have been done – and still can be done – to emulate Taiichi Ohno’s innovation in service organisations today.

Would you like to receive occasional emails from Vanguard about other reports and events you might be interested in?(required)