Corporate Services Scrutiny Panel: Lessons in Lean

ciChange

Leading and Supporting Corporate and Individual Change - Thinking | Consultative | Driven

Corporate Services Scrutiny Panel: Lessons in Lean

On Monday, 11th April 2011 the Corporate Services Scrutiny Panel Comprehensive revived a presentation by John Seddon, author of The WHITEHALL Effect. Below are extracts from the meeting which are both interesting and relevant to Lean in Jersey. Notably there are some predictions made in 2011 which will be interesting to test now in 2015. If you’d like a full transcript please contact me.

A USEFUL CASE STUDY

In this extract John Seddon explains how an attempt to standardise and streamline tasks and managing the processes for responding to customer demand actually makes matters worse, driving up costs and delaying delivery of services right-first-time to the customer.

[this example relates to] housing repairs where, when people employ a systems method, typically they now deliver housing repair on the day and at the time the tenant wants it and this is delivered at half the original cost; so the cost of housing repairs has been halved. That is the repair costs, not the total system costs. Let me just describe a conventional housing system. What has happened in the U.K., and particularly in England, is that everybody has had to comply with designs dreamed up in Whitehall. For example, in housing repairs you would see a call centre, because the idea is that if you have a call centre it is easy to access a service. In the call centre their job is to determine which of the Government targets relate to each repair, because there are targets for emergencies, urgent and other and there are categories that relate to each of those 3 or types of repair that relate to those 3 categories. The second task in the call centre is to decide what the repair is and, to that end, they have a book called the Schedule of Rates which was introduced to control costs. In this book is every repair that can go on in a house with associated materials and the standard time. So they do their work and then they pass that docket or whatever to the supervisor to give it to the tradesmen who enter the property and you would think not much could go wrong. Systems methodology requires you to study a system from a different point of view and the first question that you ask is: “What is the purpose of this from a tenant’s point of view?” From a tenant’s point of view, they want their repair done either quickly or when they would like it done. So as part of the studying you have to measure how well we achieve that and that is where managers get their first shock. They find that the true end-to-end time to affect a repair could be months and yet we appear to be meeting all of our targets. This is because one repair from a tenant’s point of view can be a number of repairs in a target-driven system. So if you have a broken window, we achieve our emergency target by turning up and boarding it up but then we might have to do some glazing, some carpentry, some plastering and some painting. These are all separate jobs all on a 28-day target. Now, you also discover when you start studying the system that the call centre is full of what I call failure demand. Failure demand is demand caused by failure to do something or do something right; so these are people ringing up saying: “It is still broken,” or: “He has not arrived,” or: “When is he going to do the next bit?” This takes a lot longer to deal with than the work because you have got to chase around and find out and get back to people. When you get the managers out studying you have to get them out with the tradesmen to find out how often they fix the property when they enter it and, typically, you find in these conventional designs it is less than 40 per cent of the time. Then you start to understand what is going wrong with the design because you have got essentially somebody who does not understand the plumbing talking to somebody in the call centre who does not understand the plumbing who creates a job ticket for somebody who does. This is why you find that most of the time the tradesmen come out of the property saying: “You sent me in to do a 72 in the Schedule of Rates but it was an 83. Therefore, I have got to visit twice. I have got to get other materials and so on.” So now you start to understand how much things are going wrong and how the current measures that you had that told you you were doing quite well are misleading.

There are perhaps some ideas that we should consider in Jersey and our approach to property and facilities management. We should perhaps start as John suggests with looking at the customer need, rather than the existing roles, responsibilities, stock and processes. He makes the point of differentiating between “what we provide” from “what they want”. The challenge is to employ Lean thinking to delivering outputs and outcomes that that the customer values.

I know I am guilty of this, as a project manager I generate much more paperwork in the execution of a project than the sponsor or customer actually “wants”. Frankly most customers and sponsors seldom read all the project paperwork unless something goes wrong. In those circumstances the paperwork is for defensive purposes rather than something that the customer values and is willing to pay for. In simple terms they want a Widget, on-time, on-budget and to-specification and generally aren’t enthusiastic about paying £750/day for lots of paperwork.

ANOTHER CASE STUDY

In this extract John Seddon explains housing allocations in Great Yarmouth. This is topical and useful because it again highlights the difference between “what we provide” and “what the customer needs” and some of the problems trying to fit their requirements into our systems. Seddon argues of course that we should tailor our systems to their requirements.

This is housing allocations and you would assume, would you not, that all of the people on your housing waiting list probably need a house? It is not the case. In Great Yarmouth what happened was that they started studying their work and someone said: “Well, what do we know about the people on the database?” Of course, the answer was: “Well, they filled in a form.” When you look at the form you find on the form they have answered all the questions we were interested in but we really do not know anything about them. So what they did in Great Yarmouth is they have started going out to meet everybody on their database and it was most instructive. What they learned was that there is only 15 per cent of the people on that housing register in need of a house. There were about 35 per cent of the people that they were meeting and also on that database who had a problem, but it was not a problem that required a new house. It was a housing-related problem. It might be something like: “Well, I am a keen gardener. I have got very old. I really cannot look after my garden any more. Maybe I should move to a bungalow.” Whereas the right solution is: “Get someone else to do the garden and stay where you are,” if that makes sense. They were those sorts of problems. There were 50 per cent of the people on the database who would never get a house in a month of Sundays and had no need. I think your question was: “How would you scope?” I would not. What they now do in Great Yarmouth is they house the 15 per cent, they solve the problems for the 35 per cent ... well, they help them solve their problems in the community so they get a sense of taking responsibility for themselves, and they tell the other 50 per cent that there is no point in being on the waiting list as they will never get a house, which is interesting because you find that people are very happy to walk away knowing where they stand rather than walk away having filled in a form and getting a letter every 6 months saying: “Do you want to stay on the database,” which is just an absurd waste of administrative resource.

There are perhaps some ideas that we should consider in Jersey about the way we log, rank, and monitor projects or other task/job allocation systems. This is a concern to me because it suggests that perhaps we abandon formulaic approaches to project and programme management and instead become facilitators for change.

Instead of managing a database (of housing requests, or project requirements) we sit with the customer and explore how we can help them. Meetings with the customer are often in stark contrast with the project meetings that often include all the gurus and none of the customers. Indeed I’ve seen “project status reports” that don’t even mention the customer or sponsor, let alone get shared with them!

HOW SHOULD WE WORK DIFFERENTLY

I *think* we do need to maintain a database (of housing requests, or project requirements) but maybe that’s because I am a programmer and project manager and old habit die hard. However I am willing to concede that we don’t talk to the customer enough. We make lots of technical decisions for and on behalf of the customer, but too often in their absence and with them ignorant of the implications. Maybe a key question to ask, repeatedly, is “Is that what the customer really wants” and the key action is to check!






ciCHANGE FEEDBACK

Please share your thoughts either directly by email or via Social Media
Facebook http://www.facebook.com/ciChange
Twitter @ciChange https://twitter.com/CIChange
Linked-In http://www.linkedin.com/groups/CI-Change-4301853

ciChange is sponsored by Total Solutions Group http://www.tsgi.co

THE AUTHOR

Tim Rogers is an experienced Project and Change Leader. He is founder of www.ciChange.org and curator for www.TEDxStHelier.Com . He is Programme Manager for the commercialization of Jersey Harbours and Jersey Airport, and prevously Operations Change and Sales Support for RBSI/NatWest, and Project Manager for the Incorporation of Jersey Post. He is also Commonwealth Triathlete and World Championships Rower with a passion for teaching and learning and is a Tutor/Mentor on the Chartered Management Institute courses. He is a Chartered Member of the British Computer Society, has an MBA (Management Consultancy) and is both a PRINCE2 and Change Management Practitioner.

Email: TimHJRogers@AdaptConsultingGroup.com
Mob: 07797762051 | Twitter @timhjrogers | Skype timhjrogers