Define the Goals, Otherwise Anxiety Builds
Here is a blog post written by an IT project manager, Gary Rosenfeld, who is in a workplace that is starting to implement Lean. Or, at least they are starting to implement some Lean tools. I’m not sure if this can be held up as a “how to” example.
People were told, on Friday, that they were starting with Lean on Monday. “Just in time” notification, but not in a good way. On a positive side, there was some Lean overview training done for the staff, 1.5 hours.
Now I realize the “gemba” might be different in an IT office — I guess the place where the value adding work is done is in programmer’s cubicles, right? Well, this organization started with a bunch of closed door 1×1 meetings. As Gary pointed out:
“… the purpose of the meetings was not well defined and that closed-door meetings in our office often cause some anxiety.”
Post continues after ad...
That’s understandable, the anxiety. Wouldn’t talking in teams allow for more brainstorming and building upon each other’s ideas?
If the purpose was unclear, I wonder if the goals for Lean were also unclear? What were the goals, and how was this articulated to the IT team? Was the goal improved efficiency? Would people then be afraid of layoffs? Was the goal faster development time? Would people then be afraid of having to work longer hours or to work longer?
This seems like a classic tools-driven approach — let’s go implement Lean tools — but for what purpose?
I hope I’m not being too cynical about their attempts. We’ll continue to follow their progress and I hope they find success with their Lean efforts, without too much employee anxiety along the way. Even though this is a Lean IT implementation, don’t these sound like familiar issues for any Lean engineering or Lean office effort?