Usually they come in with a bang and leave with a whimper. However, they keep popping up because, at our core, we share a fundamental desire to get better. The results may be mixed, but failure to try leaves us bitter and cynical.
When Lean first started gaining popularity in government circles, I thought, "Here we go again." Now, I must admit I'm a big fan of Lean (a.k.a. Lean IT or Lean Government), and I think there's a wealth of good we can accomplish by applying Lean methodology to our operations. In fact, having worked with multiple types of Lean methodology in project teams, I'm more encouraged by it than any other government improvement effort. There certainly is potential.
Lean is the process that elevated Toyota, is embraced by private-sector companies around the globe, and seems to focus on all the right areas. It even sounds healthy. But it also sounds like the flavor of the month and runs the risk of being overemphasized, underutilized and could evolve into another bit of jargon for sales pitches.
Introducing Lean
Here's a quick introduction if you don't know much about Lean. It's about improving the processes we work in. It doesn't focus on those superfluous "efficiency savers" like furloughs, turning off lights in soda machines and canceling all out-of-state travel. Instead, Lean looks at how we do what we do and encourages us to do the most essential things faster, better and more cheaply. It's about teams of employees working to examine issues and provide solutions to customer problems, system issues and budget catastrophes.Lean deals with the 95 percent of waste that William Edwards Deming, who many consider the Lean movement's founder, taught is in every work process. It's about reducing the time spent handing off work between units, eliminating the wasted resources seen in batch work and expanding those bottlenecks that slow processes to a crawl. It involves looking at the fundamental way that work is done by business units and improves how it's done.
Caution: Lean Back
I encourage all CIOs and IT professionals who see Lean coming to run away as fast as they can. When you hear the word Lean, you should shut down, check your BlackBerry for e-mails and do everything possible to indicate that you are distancing yourself from it -- at least for now.My warning stems from the fact that if you engage in Lean now, you'll screw it up. There's no technology solution in Lean, at least not yet. As a guy who loves technology, it's hard to admit when it isn't the answer to efficiency problems. But more often than not, IT professionals aren't providing the solution, and it will be a very rare occasion when we can drive Lean into a business unit with great success.
Allow Lean to take root in the managers who run the day-to-day operations. Give them the space and time they need to look at their processes without putting false hope in new applications. Allow them to dig into the core of what they do without confusing system upgrades with process change. If meaningful transformation is going to happen, it probably isn't going to be the IT component alone that's the catalyst.
Let me back up such blasphemy. In 2001, a large state was trying to reduce the time citizens waited in line for automobile registrations. It had invested heavily in a new system that was going to automate portions of the process and link several databases together, thereby reducing the number of documents and forms citizens needed to provide at the DMV window.
During the two years leading up to the new system and the year and a half implementing it, all ideas to improve the process were met with some variation of the same chorus: "The new application will take care of that." But when it was fully implemented, it had zero impact on the time that citizens waited in line.
Another example was a health organization that went live in 2007 with a new billing system. It was met with a tidal wave of negativity. The new system forced compliance in areas that had been ignored for years and were the constant target of auditors. What the new system didn't do was address why clients were out of compliance in the first place. Therefore, it had to drastically scale back functionality to assure proper payments were being made. In this case, "proper" was defined as the way they were made before the new system.
Both of these projects were relatively strong from a technical standpoint, but the processes they addressed were tied to the premise that just adding automation was the solution. Worse yet is when development of a technical solution is mixed with process improvement. Isn't this why our change management structures are so taxed? Costs go up and time delays occur when business units change or add ideas during application development. We blame scoping, but the problem comes before that. It's at the very start -- when we begin that natural desire to improve. We look to technology to fill that need.
I encourage you to use Lean or any process improvement discipline first, and automation second. Fix the business processes and then automate the portions that need it. Otherwise, we're automating the 95 percent of the stuff that doesn't really need to be done at all.
I jest about distancing yourself. That's counterproductive to being part of government and relegates our role to being a simple computer geek. I think IT has a vital role in these initiatives. After all, there isn't a whole lot going on in government today that doesn't use technology in some way, and often IT can be used to improve service delivery. Our role should be to assure that the process improvement is done before any contract is let, before any code is written and before any budget item goes to committee.
The balance is in the sequence. The "T" comes after the Lean, after the process waste has been eliminated and the core work functions have been re-engineered, after teams have made sure that their work still is meeting customer needs, and after we've done all we can to improve the way work is done.
Lean and other improvement efforts have the potential to make daily operations stronger, and potentially they can include a sizable IT component. But they shouldn't go hand in hand. Good process improvement first, good IT implementation second. There isn't a concrete barrier separating the two, but if the line is too blurred it's more likely both will fail.
