Dougal Mather, Vanguard Consulting
‘Hello… hello… anyone…?’ The customer’s voice reverberated into space. Jack Travers sighed. He had done this many times before. For all his skill at navigating the automated system, he found himself thinking ruefully of Indiana Jones trying to gain access to the Temple of Doom.
Travers had no need for more doom in his life. He had plenty already and it was in his kitchen after a pipe had burst five weeks ago. The receiver sputtered to life…’Good morning, Mr Travers, you’re speaking with Sean. How can I help you?’
Odd question. Travers had made it clear the help he needed the first time he’d called to alert his insurer to the flood. It wasn’t that unusual: his kitchen was inundated, and he wanted it back as soon and as tidily as possible.
What he got instead was a crick in the neck from phone marathons and a procession of people traipsing through the front door with measuring tapes, dictaphones, mobile printers and cameras. Lots of work had been done in the shape of notes taken, trips made, reports written, photographs checked and saved, but nothing so far in the way of making good damage or laying tiles. It had taken a week for the drying equipment to be brought in for a start.
In his darker moments, Travers wondered what proportion of insurance premiums go to pay for this kind of busyness. It’s a good question.
What drives this travesty of helpfulness? Not malice or indifference. Most people working at the coalface of insurance claim systems are eager, at least at first, to help callers in need (whether that’s still true after years of fighting the above might be a different matter).
The driver is, in fact, not unique to the insurance sector, but one linked to the fundamental archetype of the system, and a very common one: the ‘complex project environment’.
The importance of archetypes
When thinking about services as systems, it is useful to consider some basic archetypes. Understanding the archetype helps guide towards likely points of leverage for improvement.
Along with complex projects, two other basic archetypes are:
● Transactional systems. For example, making a one-off payment. Here, the most direct route to improvement is bettering one-stop capability.
● Flow-centric systems. For example, the bank bereavement centre described in Will Pyke’s recent post, ‘Casino Banking.’ In flow-centric systems much can be leveraged from studying processes and redesigning to eliminate non-value creating waste.
The complex project environment differs from these simpler systems in a number of ways.
First, projects or cases deliver individual and unique outcomes to the service user. The Travers kitchen is unique in size, shape, damage and materials; a bespoke approach is required for its restoration.
Second, they entail processes that cannot (by traditional means at least) be completed quickly. Satisfying demand is not a matter of a one-stop phone conversation; multiple interactions are the norm and a succession of actions must be put in place, generally involving third parties and subcontractors – in this case Sean and his colleagues, a surveyor, a firm with drying equipment, and later carpenters and other tradespeople to make good the damage. Some form of IT workflow system is generally used to control the work. It hasn’t escaped Travers’ notice (how could it?) that despite copious computerisation every new person he speaks to requires another full briefing on his situation and previous contacts. Who out of this list truly creates value is a worthy question to reflect on.
Neither claims systems, nor even wider financial services, have a monopoly on the attributes above, which in the wild may be met in a wide variety of businesses and services, in both public and private sectors – for example, housing allocations and voids; general and life insurance claims; mortgage fulfilment; legal work; town planning; social work; environmental health systems; installation and repair programmes; pension claims; and IT development.
Why does this matter? Here’s the thing. Disguised within what many people consider to be ‘regular’ operations, complex project environments are rarely recognised as different. And this lack of recognition may go a long way to explaining why conventional performance indicators and improvement schemes fail to yield the hoped-for results or staying power. They are not typical transactional or flow-centric systems, and treating them as if they were will stymie their performance every time.
To understand why, let’s look at the prevailing leadership beliefs within complex project environments and how they create shared norms.
Belief 1: The sooner we start, the sooner we finish
Unpicking this belief is key to unlocking performance in complex project environments. Flooding operatives with new work is the number one driver of ‘bad multi-tasking’ – the continual picking up and putting down of work without completing it.
The consequences are cherry-picking, leading to mushrooming failure demand: In any service where many cases are open and few get completed, people constantly get in touch to check on progress. This kind of communication may consume 80 per cent or more of a system’s contact capacity, turning it into a kind of Petri dish in which ‘work’ breeds.
Belief 2: Showing progress on a variety of tasks is important and worthwhile
It’s a purpose thing. What’s the purpose of the system? To show progress or to get cases closed to the satisfaction of the customer? All too often ends and means are confused. When clarity is wanting, workers sink beneath the waves of bad multi-tasking, little knowing that they are expanding the workload in the process. Far from improving throughput, multitasking slows customer resolution, damages productivity and drives up frontline stress.
Belief 3: Workers need targets to make them effective
Targets take many forms: due dates, SLAs, KPIs, call answer times. Each of these pushes activity towards easy cases to make the numbers, piling fresh cases on the front line.
The core issue lies with what they are conceived to do. The focus is on getting work started, only to neglect closing cases efficiently and happily. No one measures the massive effects of this apparently minor difference in focus in terms of increased failure demand, lost man-hours, executive-level complaints, distress and inconvenience in pay-outs, cost of revisits, let alone the huge cost to morale of keeping people busy but not effective.
Many managers swear that people love targets. The truth is that they crave to know where they stand. When a target is the closest thing to that feedback, people cling to it. It is vitally important to inform both business and employees where they stand by replacing arbitrary performance indicators with measurement that relates to the purpose of the system and what matters to its customers, and is sophisticated enough to take into account the natural variation inherent within it.
Belief 4: Functionalisation equals productivity
Ever since Henry Ford, managers have divided work into segments to facilitate control, quality, ease of training and replacement, to name a few. Anyone having a studied a service as a holistic system knows it is folly.
In complex project environments, functionalisation distorts priority and focus. Operatives become more concerned with “is this my department, or can I pass it on?’ than with “how do I resolve this from the customer’s point of view?” Process has become more important than service user.
As ever, the absence of end-to-end measurement contributes to the dysfunctionality. Splitting measures by function invariably inflates time and cost and in so doing buffers those in the system from the realities of the customer’s actual experience.
Workflow systems linking separated front and back offices compound these difficulties by paradoxically making the work that counts invisible – most commonly by adding cases to queues to make the targets for getting them “on the system”, or by leaving them to languish as open allocated cases that are not being driven forward to completion. Conventional management will have the mechanics in place to sweep up the latter from time to time, scouring reports for “deadwood” or cases about to breach service agreements, but only after the event (and cost).
Making a complex project environment work
So how could you choose to act differently in a complex project environment system? What would need to change in order to benefit performance, cost and morale?
As in any other context, change is dependent on the ability to let go of accepted conventions in the face of counterintuitive truths. Thus, pushing work at the front line doesn’t change the reality that a team can only deal with allow what capacity allows. The purpose of these systems is to close cases efficiently and to the satisfaction of the consumer, not to keep people busy for the sake of it. Targets should be replaced by measures related to purpose. And with due respect to Henry Ford, functionalisation is actually the problem, not the solution.
Some new goals to help break from the damaging norms are shared in the table below:
|Keep everyone busy fire fighting||Focus on unblocking and closing cases|
|Functionalise and split tasks||Develop your resource to a position of case ownership and an end-to-end understanding of the service|
|The sooner they’ll start, the sooner they’ll finish||Experiment with limiting or choking the release of cases to operatives|
|Pick off easy cases first||Develop a clear and enforced policy rule and stick to it|
|Drive work by targets||Switch to a programme of capability measures directly relating to purpose and what matters to customers|
|Attend to cases dictated by workflow||Make visible all open cases and ensure that everyone knows who’s responsible for which. Focus managers on unblocking and problem solving|
|Accept problem cases will take longer||Insist on escalation of blocked cases removing the option of going on to something else without it|
Replacing the misguided management initiatives discussed above can lead to transformational leaps in service, cost and morale.
Making that initial step change, is not, however, the whole extent of the challenge. It has got to last. Better still, keep improving. An enormous part of sustaining this change is keeping resolutely in mind the new operating principles and goals. In addition, though, there are two key areas to sustainability that leaders should pay special attention to.
Making change sustainable
First, stringently measure and re-measure throughput (volume of cases in versus volume of cases out). If public enemy number one is bad multi-tasking caused by employees being flooded with open cases, constant vigilance is needed to ensure that those toxic conditions aren’t being recreated.
If new projects or cases are coming so fast that even slowing their release is incapable of preventing a backlog, consider whether there is a real capacity issue. If there really is more work than can be absorbed, piling it on will not get it finished faster, however unwelcome that may be to those up the line.
Conversely, if raw capacity is not the problem, there is a need to take aggressive action to rid the system of all feasible waste.
Second, repurpose all managers away from the usual functions of allocating, report writing and target maintaining. Send them out into the work with those involved in live cases, learning how to unblock them and stop other cases from becoming blocked in the first place. Managers may initially not thank you for it, but customers will. So will others as durations shorten, satisfaction rises and costs fall, while a bond forms between the front line and managers who get to grips with the barriers preventing them from providing the service they know they should be capable of.
Now, none of these beneficial impacts can be realised unless we recognise that we’re in a complex project environment in the first place. Fall at this first hurdle and the all too likely consequence is the familiar vicious circle of ‘stretching targets’, shorter handle times and when that fails, big-ticket spending on non-value-creating IT that on the contrary worsens service performance.
But what if an insurance company were to take the measure of the archetype and design a claims process that was customer-shaped at its heart, set up with capacity to meet predictable demand and staffed against it?
…Discovering his kitchen disaster, a future Jack Travers gets in touch with his insurer. He is pleased to connect directly with a human being, who seems to understand the urgency of the need to get his kitchen up and running again — he or she also being confident that the more effectively the purpose is met, the lower will be the indemnity spend and operating cost for the company.
First and most importantly, the agent listens, with the sole aim of understanding what Travers is most concerned about and putting together a course of action that meets that need. Of course, in real life things aren’t simple: not every claim is legitimate. But in that case the agent can ‘pull’ the necessary support and expertise to make the decision on the spot, rather than leave it hanging for later.
Once Travers has explained his needs and the initial steps have been determined, it is all about execution: getting the right resource to the right place at the right time for the client, with a single-minded focus on completion. No more photos, recorded interviews, reports or duplicated measurements – only what furthers safety, drying out and making good, all having regard to the daily imperatives of family life.
As the relieved Travers family gets back to normal, the agent at the contact centre who has handled the case end-to-end has only to enquire if the claim could have been handled better and store the lesson for the next time. At the same time, managers studying flow are working to identify further scope for joined-up action that will continue to reduce failure demand. Instead of beating up on subcontractors, they are working with them on issues to reduce end-to-end time and recall rates and improve their ability to arrive with exactly the right materials and tools to perform the job.
A pipe dream? No. Many companies have seen just such results with many services bold enough to seek the benefits of a different approach. But you do have to be able to recognise a complex environment when you see one.