Editor's Note: This is the first in a two-part package exploring the growth of Lean IT and its relationship to BPM. Here, consultant and author Steve Bell describes the principles and practices of Lean IT. In Part II, he discusses how Lean IT enables and supports continuous process improvement and offers advice on getting started with the methodology. Bonus: See the end of Part II a list of Lean resources, including all those mentioned in this package.
Lean has revolutionized manufacturing and quality improvement since the 1980s, with a laser-like focus on getting things done "faster, cheaper and better." Now it's IT's turn to join in the revolution. In this Q&A, Steve Bell explains the principles and practices behind Lean IT. Bell is co-founder of the Lean IT consulting firm Steady Improvement and author or co-author of two leading books on Lean IT.
JM: What are the roots of Lean thinking? Where did it first take hold?
SB: The popular origins of Lean are attributed to post-World War II Japan and the quality movement. Most frequently noted are W. Edwards Deming and Toyota, but many other individuals and companies have been involved. Womack, Jones and Roos coined the term "Lean" in their MIT study of Toyota, publishing "The Machine That Changed the World," followed by the classic "Lean Thinking." Taiichi Ohno of Toyota [who, with consultant Shigeo Shingo, guided the early development of the famous Toyota Production System] attributed much of his initial thinking to Henry Ford.
JM: Why haven't IT departments been part of the Lean revolution until now?
SB: Actually, they have been for some time, though not on the holistic scale that is needed for a complete transformation. Agile software development practices have been around for at least 20 years, and they are based on the principles and tools of Lean production. The IT Infrastructure Library [(ITIL)] also has elements of Lean, specifically Deming's "plan-do-check-act" problem-solving cycle, embedded within the problem, change management and continuous service improvement processes.
However, IT organizations typically have a "methodology" mentality, where an end state--for example, an Agile, ITIL or [Enterprise Resource Planning (ERP)] best-practice framework--is "implemented" as a project.
Lean is actually a process of experimentation, rapid iterative cycles of learning and testing, where the next step, the next future state, is a hypothesis waiting to be tested before it is adopted. This is significantly different from implementation, where you select a "known" target state and budget time and resources to achieve it. Many traditional IT budgeting and governance processes resist this incremental, experimental approach – it feels risky and uncertain. But the reason so many projects disappoint is that it is impossible to truly know what the final end state will be.