Linda LaGanga, who works in a community mental health service in Denver, has written a useful summary of her service’s experience of applying Lean.
Their use of Lean is shaped by the economic context of US health care, but there are several useful lessons in their work. The Mental Health service’s interest in Lean began, as is often the case, by serendipity. The service had a problem – low attendance at out-patient clinics – and a manager attended a Rapid Process Improvement event in another service, and saw a set of techniques which offered a solution.
This initial problem is a classic Lean opportunity: it involves patient flow, numerous administrative processes and, in most services, considerable unproductive effort, related to systems that may not quite gel. In this case, the efforts of the people who worked in the service led to a 27% increase in completed appointments in the following year – a significant achievement, and one which resulted in the decision to use Lean techniques again.
The Denver report includes a fascinating summary of the time it took to implement changes from each subsequent project:
Project One (the out-patient project) – One month
Project Two (on initial appointments) – Three months
Project Three (recruitment processes) – Six months
Project Four (management of grant income) – Twelve months
Project Five (training of new staff) – Twenty-four months
The pattern here is obvious. Lean is supposed to help produce rapid change, but in the experience of this service, change became more and more difficult to implement with each successive project, and took longer each time.
Part of the reason seems to have been decisions on methods of improvement. In the third project on recruitment processes, the first with a significant delay, the solutions adopted were changes to an electronic information system. According to the report on the Denver service,
‘Implementing the solution required extensive systems analysis and programming from scarce analytical staff and took six months to complete because of the bottleneck caused by the growing work queue of such staff.’
The outcome of the project was, according to the service’s account, a three day reduction in the length of time to hire new staff. At face value, this seems a relatively modest trade off for the work involved.
Their fourth project was intended to improve reporting on spending. Quite rightly, the project team wanted to avoid multiple stand alone spreadsheets, with potential for error and confusion, so designed a new electronic system to gather the required data. The development of the system took a year, because of issues over sequencing of other work, the time required for system development, and a lack of clarity over which staff were accountable for implementation.
In the last example, training of new staff, the project team concluded that tasks such as teaching people to access their e-mail could be done more efficiently by developing new on-line modules.
These are all worthy projects, and it is easy to see why an organisation would want to work on these problems. The bigger question may be whether these were Lean projects at all.
Most people agree that Lean is intended to focus on value, and to decrease non-value added activity by decreasing various kinds of waste. There is an interesting discussion of the challenge of defining added value in office processes here.
To me, most of the projects described by the Denver service sound like Business Process Reengineering. There is a great discussion of the differences between Lean and Process Reengineering in this Forum discussion. One of the posts, by Bill Roper, seems particularly relevant.
‘Lean focuses on making things better rather than making things perfect and accepts that multiple rounds or improvement will be necessary, and are in fact desirable, to help move the change process along.’
The Denver work, after the first couple of examples, seems to have focused on producing a perfect process. This is an unarguably admirable aim, but in these cases producing the perfect may have been at the expense of the ‘good enough’. Once the IT solutions were delivered, it’s still necessary to then make them work in practice. I’ve written previously about Virginia Mason’s ‘Pursuit of the Perfect Patient Experience’ – but perhaps the key word is pursuit – it depends on continuous quality improvement and a willingness to go on changing over time.
In these projects, would it have been better to have engaged staff in rapid, small cycle change, or to aim for the perfect solution? What do you think?
Photo by email@example.com