Five Steps to Get Lean

No, this is not an exercise or fitness blog post. This is about moving your IT department toward Lean. Many healthcare organizations are moving toward implementing Lean principles as a way to improve patient care, improve quality and reduce waste (which may translate into reducing costs).

Many IT departments struggle to implement Lean in the same manner their hospital departments do because the work in IT is quite different. However, though the work is different, it doesn't mean you can't find ways to implement Lean in your department. Yes, it takes time, patience, effort and planning - all things that can be in short supply in any healthcare IT department. So, with that, here are five steps you can use to get Lean going in your department.

1. Engage your team in discussion. What problems are they facing over and over? Regardless of whether you manage an application, infrastructure, operations or project management team, begin the dialog around what problems they keep solving. If no problems surface, something's really wrong because every team I've ever worked with can list these problems almost off the top of their head in less than five minutes. [If no one is speaking up, you may have a culture of fear that prevents them from speaking up - that should be your first priority to fix.]

2. Identify a recurring problem to solve. Are you always getting 'surprise' requests for interfaces? Are you always finding yourself at the tail end of new construction or move planning? Do your PCs keep breaking in the same way? Do your users call in for the same 5 problems every week? Once you've identified recurring problems, select on that you can work on. To start with, you should select on that really engages the team even if it's not the biggest bang for the buck. People starting out in Lean often wonder whether they should pick a small problem for 'practice' or go all in and solve a big, gnarly problem. While it's your call, I would suggest finding a problem the team really wants to solve, regardless of size (though I would avoid really big, knotty problems at first).

3. Determine the right Lean tool for the job. Make sure you select the right tool. One frustration I've heard raised many times is that the process for solving the problem is more onerous than that problem itself. If that arises, it's a clear signal you've selected either the wrong tool for the problem or you might be using the tool incorrectly. A hammer is not a great tool for removing a screw. A drill is not great for applying paint. For example, an IT security team identified a problem with how long it took between identifying unusual PC behavior (possible malware activity) and getting a desktop analyst out to look at it. The security team thought this might be a good problem to start out with in their Lean learning. However, when they started performing a value stream analysis, they got frustrated. Eventually they realized they were spending a lot of time analyzing things that actually didn't impact this problem. Wrong tool. They stepped back and performed a workflow analysis, found that the step that was causing the delay was the dispatching of a desktop analyst. When they examined that, they found that the delay was because the alert was routed in an odd way and was not clear as to the expected action. The team modified the alert routing, modified the wording in the alert and tested it. They monitored the results for 30 days and found that the average response time was reduced by more than 18 hours and was sitting consistently at under 120 minutes.

They improved the process, reduced waste and confusion and improved security. They thought this was good, but they were not satisfied with 120 minutes, so they looked at the process again to see how they might reduce turnaround further. It was then that they realized that they could disconnect the PC from the network by disabling the port to which the PC was connected, thereby buying them time to get out to the device. This also would help reduce the "drop it and run" disruption this current process was causing on the desktop team (which is why it's important to include all impacted parties in the problem solving so you don't just punt the problem to another team).

So, they modified the process again to route an alert to the network-engineer-on-call to disable the port identified and then another automated alert went to the desktop team to go pick up the offending PC. They measured this and found the network engineer was able to disable the port within 15 minutes of the alert. The desktop team then had up to 24 hours to pick up the PC, though they often were able to swap out the PC within about 4 hours.

The net effect of this was the end users were less impacted (PC was available again within 1 day in areas where other PCs were available, 4 hours otherwise) and more satisfied. The information security team was pleased to disable a potentially harmful PC within minutes of identification and the desktop team had a bit more leeway in responding.

4. Determine the best way to measure and manage improvement. In the prior example, the team gathered 3 months' worth of data from their ticketing system to determine the shortest, longest and average time to response for these types of incidents. They looked at those that took longest and shortest to identify the underlying problem(s). After they came up with a theory as to how to improve the response time (hypothesis was that alerts were unclear and causing delays), they measured for a month to see if they were headed in the right direction. If yes, continue. If no, step back and try something else.

5. Document results and set to monitor. Repeat. Once they saw that this process seemed to be working, they documented it in their knowledge base, they set up an automated report (monthly) to review metrics to ensure there were no new problems introduced or no slide back to prior state. Then, they moved on to the next problem they wanted to solve

Here's the key. If you engage your staff in fixing problems that drive them nuts, they'll be highly engaged in the process. That's the best way to introduce Lean tools and management systems (huddles, standard work, leaders standard work, kaizens, plan-do-check-act, etc.) and gain traction.

One of the worst things you can do is drop a pile of Lean tools on their desk (figuratively speaking) and force them to solve problems they don't see as problems. This is not about manipulation by any stretch. This is about facilitating a change in mindset and a use of standardized tools that can assist in solving problems.

In IT, some of the best Lean initiatives involve reducing steps needed (to do any task), streamlining and automating, reducing turn around time on requests, reducing hand-offs across teams, increasing the quality of deliverables to the organization, reducing costs and more fully leveraging existing systems/tools.

In summary, find the right tool for the job and give it a try. Even 'failure' produces excellent feedback and that can be transformed into a better path forward on the next try.