[In this blog series, Robert Slepin explores one IDN’s objective to drive out waste. The first part focused on establishing goals and building a case for going Lean; this segment will describe the starts and stops his team experienced in launching the initiative.]
When it was time to launch a formal process improvement initiative, systems infrastructure seemed a natural starting point. Computer servers, data storage and network all needed replacement or major upgrades, and had to be migrated to a new data center before kicking off the EMR implementation project, which required a modern infrastructure. The IT systems group consisted of smart, hard-working professionals, but was small in number and informal in its processes. We reasoned that the team’s limited bandwidth could be a rate-limiting factor for delivery of a highly reliable infrastructure on an aggressive schedule. In other words, the team seemed to be a constraint needing management attention.
Following a short introductory training for the entire department on world-class IT performance and an overview of Lean process improvement principles, our consultant began working with a smaller process improvement group within the IT department composed of systems infrastructure personnel. He facilitated an exercise for infrastructure managers and front-line staff to develop a current reality tree, a concept from the Theory of Constraints. In small groups and one-on-one sessions, IT staff detailed their observations of current conditions on yellow sticky notes. The consultant arranged the notes on a wall in the IT conference room, being careful to order them according to apparent cause and effect.
Over the course of a number of discussions, the group refined the information and causal connections until the exercise concluded. In the end, one core problem was at the bottom of the tree with numerous branches shooting upwards. Toward the top were the typical effects of a sub-optimal IT operation — dissatisfied customers and users, stressed employees, project over-runs, unreliable systems and service issues. The underlying core problem, which seemed obvious from the visual analysis, was an implicit mode of IT operations.
In other words, the systems team operated in chaos. Faced with frequent production system defects and outages, reactive fire-fighting was common. Assignments streamed to team members from multiple directions. Electronic service tickets, email requests, new projects, IT leadership directives and drive-by requests — all were sources of tasks. Each staff member decided his own priorities for the day. Picking and choosing tasks was not easy; the loudest cries for help often drew attention before the most critical items. There was way too much work — far more than the staff could handle, and much of it was unplanned, sometimes demanding heroic efforts to accomplish. Management had no single place to see everything on the team’s plate, much less forecast labor resource needs for the weeks or months ahead. Problems often went unnoticed entirely by management or didn’t surface until becoming a major crisis.
Through its analysis of the situation and root causes, the IT process improvement team hypothesized that an effective strategy would be to develop an explicit mode of operations. Consistent with the scientific method, an experiment was needed to test the hypothesis. It was time to commence a series of Plan-Do-Check-Act (PDCA) cycles.
The team established a target future-state condition of “no unplanned work.” To achieve this ambitious goal, the consultant recommended a set of counter-measures. One was implementation of a visual system of work (e.g. Kanban) where all pending, in-progress and finished work orders would be visible to anyone with a need to know. Operating rules were established — such as working on only one or two tasks at a time — to cut down on inefficient task-switching, which impedes employee productivity, increases stress and slows throughput.
When major obstacles were encountered during the day — or whenever a drive-by occurred — staff was asked to immediately notify a supervisor in order to facilitate real-time, at-the-elbow problem-solving. Managers were instructed to see for themselves what was happening with their staff, and not rely on email messages, written reports or second-hand retelling of issues. Fifteen-minute huddles were held first thing each morning to review the previous day’s performance indicators and discuss plans for the current day. Key performance and outcome metrics were posted on the wall to help facilitate agreement regarding actual versus desired performance, and enable rapid recognition of abnormal results requiring management intervention.
The Kanban pilot lasted for several months and yielded mixed results. The exciting news was the pre- and post-experiment data supported the hypothesis: drive-by volume declined, although not surprisingly, zero drive-bys was very difficult to achieve and proved unsustainable. Additionally, critical IT service incidents decreased, productivity increased and for some employees, morale improved.
IT staff reaction to the pilot varied. Some team members became excited at having their eyes opened to a new and possibly better way of doing things. They realized that highly visible, repeatable standard work does not necessarily equate to a loss of creativity, autonomy or fun. Instead, it can be liberating. Defining, measuring, monitoring, stabilizing and constantly improving work processes contributes to consistency and quality results, which makes for a better employee experience and improved customer satisfaction. However, none of the team enjoyed rekeying service management tickets from Magic into the Kanban system, and staff found it difficult to allocate time for improvement work when they were so busy recovering from service outages or redoing defective work. Two staff members resigned as the result of the radically different work environment.
Eventually, the Kanban experiment fizzled. The consultants left and a change in management hampered enthusiasm for continuing. Although we abandoned the pilot program, we did not consider it a failure, but rather, learning. We doubled down, pushing ahead with more Lean training.
This time, nearly everyone in the IT department received more extensive training in process improvement skills. They learned the 5-Whys technique of root cause analysis, value stream mapping and A3 thinking. Led by an IT director responsible for championing Lean, kaizen events involved staff in designing and improving key IT operations processes. We linked business and IT strategy to day-to-day operations with the Daily Management System (DMS), a balanced scorecard on steroids. High-level business goals, IT department goals and team objectives and measures were posted on walls throughout the department. Teams met daily to discuss, in a systematic way, progress toward goals and to problem-solve abnormal conditions standing in the way of success. DMS was highly effective in spreading Lean thinking and engaging stakeholders across the entire IT organization.
In my next post, I will share thoughts on how Lean differs from a conventional approach to leadership and key lessons learned.
Robert Slepin is Director of Electronic Health Records (EHR) at Johns Hopkins Aramco Healthcare (JHAH), the result of a joint venture between Saudi Aramco and Johns Hopkins Medicine. JHAH provides integrated and patient-centered care to Saudi Aramco’s employees and health care beneficiaries. Slepin’s role is to lead the Epic@JHAH program, a transformation initiative to digitize patient data and automate patient-care processes at JHAH’s Dhahran hospital, satellite clinics and remote area clinics across the Kingdom of Saudi Arabia. Previously, he served as CIO at John C. Lincoln Health Network.
Share Your Thoughts
You must be logged in to post a comment.