Taking Time To Learn
We have one plant that is a model of lean manufacturing. They are so good at one-piece flow and just-in-time that, from one day to the next, they carry no finished goods inventory. Orders placed today are built and shipped tomorrow. One piece flow allows this plant to have exceptional quality (no errors are ever passed on to the next stage of the process). Because of their manufacturing agility and zero finished goods inventory this plant can introduce new products without any risk of obsolescence. This plant has the highest margins in the division.
About 15 miles away from this plant is its evil twin. Their idea of continuous improvement is to refine the way they over-produce inventory. They have a high scrap rate and keep asking for money to expand their warehouse. When I walk through the warehouse, I see inventory with many years of count tags collecting dust. The plant manager honestly believes they he runs a good operation. I once asked him how he knew this to be true. He answered that he knew because things were better now than under his predecessor. In the same conversation, I asked him if he had ever driven the 15 miles to visit our lean model plant. “No”, he said, “their process is different enough from ours and so I don’t think I can learn anything from them.” Over the past few years, we have pulled work from this plant to shift it to other, more lean operations. Yet the plant manager seems oblivious to this cause / effect relationship.
I am intrigued by the plant manager’s attitude. This plant manager’s domain is shrinking yet he remains unmotivated to drive 15 miles to see what the other plant does to achieve its stellar results. He won’t even consider taking the drive.
What intrigues me about this is wondering in what aspects of my work I am falling into the same attitude. Are there better ways of leading and managing IT projects that I don’t consider? How much better could I be doing if I were willing to drive my metaphorical 15 miles? I don’t want to torture myself with what I don’t know but are there some simple things I can do to stay abreast of best practices?
The approach I have taken is to pick a topic and allocate time and focus to learn enough to know how I can use this information in my work. For example, a couple of year ago I spent time reading about and visiting with practitioners of Agile / Iterative Development. We do very little custom software development but I learned enough in my studies and visits to apply the principles to our implementation projects. We no longer engage in months-long projects. We apply rigorous prioritization not just to our portfolio but also functions and features on specific projects. As another example, someone once mentioned that they had replaced ITIL with MOF (the Microsoft Operations Framework). That was enough to motivate me to investigate the differences and relative strengths and weaknesses. As a result, I too became a user of MOF. I still convene, on a regular basis, CIO’s of public companies to discuss how they have improved their Sarbanes Oxley (SOX) compliance. Even though I think we do SOX really well, I am guessing that others are finding ways to reduce costs and complexity that I should know about.
I have found that unless I pick a topic and focus on it, I will be too distracted to learn enough to apply the principles. Our oblivious plant manager thinks he has applied lean principles to his processes. If he dug deeper and learned more, I hope (for his sake) he would realize that the principles will work for him. Same for me and Agile, MOF, and SOX. I need to learn enough to know what will and will not work.

