68804943 lean-it-enabling-and-sustaining-your-lean-transformation

Praise for Lean IT
“A great read on how to apply Lean principles to IT. These tools really work to improve IT’s performance and credibility.”
— Niel Nickolaisen, CIO Headwaters, Inc.; co-author of Stand
Back and Deliver: Accelerating Business Agility
“A groundbreaking synthesis, examining IT operations, project management, software development, and governance through a Lean lens. Taut, subtly reasoned, and laced with the kind of
brilliant insights that only come from practicing masters. Required reading for IT executives, architects, and project managers.”
— Charles Betz, author of Architecture and Patterns for IT Service Management,
Resource Planning, and Governance, and practicing Fortune 20 enterprise architect
“A superb primer for anyone interested in learning about Lean. Their work will help business leaders understand the arcane machinations of IT while giving IT professionals a common language to
talk to the business.”
David Almond, Administrator, Office of Transformation for the Department
of Administrative Services; former CIO, Oregon Department of Revenue
“Do most IT organizations waste effort? They do. Can this book transform your thinking and
jumpstart your efforts to eliminate waste and optimize the business value of IT? You bet!”
Kurt Milne, Executive Director, IT Process Institute
“Finally! A practical Lean transformation blueprint that includes information systems and the IT
organization, while addressing the essential element of human engagement across the enterprise.
You can easily digest their lessons and learn how to adapt and apply to your specific organization.
This is the key to business alignment the IT industry has been searching for.”
Andrew Rome, Talent & Organizational Performance executive
of an 80,000-person global IT Management firm
“A deft application of Lean concepts and techniques to a central challenge we all face: how to
increase effectiveness of investments in IT people and systems and the value they bring to enterprise
processes. Current and aspiring business and IT leaders and managers at all levels of the organization will benefit from their in-depth knowledge and broad perspective.”
John Pierce, Vice President, Information Systems, Tripwire, Inc.
“Lean IT is an idea whose time has come, especially now that applications like electronic medical
records may soon revolutionize health care. Bell and Orzen blend creativity and practicality as they
show how to improve both information quality and ease—all the while acknowledging that more is
not always better.”
Naida Grunden, Author, The Pittsburgh Way to Efficient Healthcare:
Improving Patient Care Using Toyota Based Methods
“This book is long overdue. The IT world needs tools and concepts to be structured in their language
and approach so they can join the productivity push that manufacturing has already experienced. “
Bill Baker, co-author, Winning the Knowledge Transfer Race

“This book is a must read for not only IT professionals, but business executives as it aligns information and information systems throughout the enterprise and supply chain, which improves organizational performance and agility.”
Beth Cudney, Ph.D., Missouri University of Science and Technology;
author of Using Hoshin Kanri to Improve the Value Stream
“This work integrates the Lean work over the past century and brings it to focus on the IT organization to eradicate the very drivers of IT wastes, replacing them with a value driven approach based
on Lean principles. This comprehensive book should be required reading for all levels in the IT
organization.”
Mark Swets and Tim Schipper, Lean Coaches, Steelcase;
co-authors of Innovative Lean Development
“From software development to help desk management, business leaders, IT professionals, and
improvement teams finally have clear and concise answers to the question, ‘Yes, but, how does Lean
apply to IT?’ Supported by compelling case studies, this outstanding book goes far beyond theory.
Karen Martin, co-author of The Kaizen Event Planner: Achieving Rapid
Improvement in Office, Service, and Technical Environments
“Lean IT takes the game to a new level, particularly in the field of Lean Healthcare, where effective
information systems are vital. I suppose I will have to buy multiple copies of this book -- So many
IT managers in need of Lean education; so little time.”
Tom Jackson, author of Hoshin Kanri for the Lean Enterprise: Developing Competitive
Capabilities and Managing Profit, winner of the 2007 Shingo Research Prize
“Read it! Learn it! Do it! These pages are meant to be dog-eared, high-lighted, and coffee-stained.
Within these pages are the keys to unlocking the value of information and information systems.”
Dennis E. Wells, Lean Evangelist, Oregon Department of Human Services
“The authors clearly articulate and demystify the overwhelming challenge of enabling IT processes
and organizations to embrace rapid change demanded by Lean transformation. Lean IT represents
an important body of work Lean practitioners desperately need to break through the plateau of
unending point improvements into sustainable system wide improvements impacting the bottom
line.”
Rajesh Solanki, Corporate Director for Continuous
Improvement, RTI International Metals, Inc
“Nearly every week, IT leaders ask me to help clarify their roles in their organizations’ process
improvement efforts. This book not only answers how and why, it also gives great examples showing
that it can be done in your organization too!”
Steve Hoeft, Lean Six Sigma Director, Altarum Institute; Lead Instructor,
Univ. of Michigan Lean Manufacturing, Lean Product Design and Lean
Healthcare Certification courses; and author of Stories From My Sensei.
“The gap from the implementation of Lean in production processes to office practices now has a
bridge! Orzen and Bell are visionary showing the value of a fully integrated lean enterprise.”
Elizabeth M. King, Executive Director Organizational Effectiveness, ESCO
Corporation; Association for Manufacturing Excellence, Director

Lean IT
Enabling and Sustaining
Your Lean Transformation

Steven C. Bell • Michael A. Orzen

Productivity Press
Taylor & Francis Group
270 Madison Avenue
New York, NY 10016
© 2011 by Steven C. Bell and Michael A. Orzen
Productivity Press is an imprint of Taylor & Francis Group, an Informa business
No claim to original U.S. Government works
Printed in the United States of America on acid-free paper
10 9 8 7 6 5 4 3 2 1
International Standard Book Number-13: 978-1-4398-1757-5 (Ebook-PDF)
This book contains information obtained from authentic and highly regarded sources. Reasonable efforts
have been made to publish reliable data and information, but the author and publisher cannot assume
responsibility for the validity of all materials or the consequences of their use. The authors and publishers
have attempted to trace the copyright holders of all material reproduced in this publication and apologize
to copyright holders if permission to publish in this form has not been obtained. If any copyright material
has not been acknowledged please write and let us know so we may rectify in any future reprint.
Except as permitted under U.S. Copyright Law, no part of this book may be reprinted, reproduced, transmitted, or utilized in any form by any electronic, mechanical, or other means, now known or hereafter
invented, including photocopying, microfilming, and recording, or in any information storage or retrieval
system, without written permission from the publishers.
For permission to photocopy or use material electronically from this work, please access www.copyright.
com (http://www.copyright.com/) or contact the Copyright Clearance Center, Inc. (CCC), 222 Rosewood
Drive, Danvers, MA 01923, 978-750-8400. CCC is a not-for-profit organization that provides licenses and
registration for a variety of users. For organizations that have been granted a photocopy license by the
CCC, a separate system of payment has been arranged.
Trademark Notice: Product or corporate names may be trademarks or registered trademarks, and are
used only for identification and explanation without intent to infringe.
Visit the Taylor & Francis Web site at
http://www.taylorandfrancis.com
and the Productivity Press Web site at
http://www.productivitypress.com

This book is dedicated to Morton and Rickie Orzen, and Bob and Betty Bell,
our incredible parents who molded us with their unconditional love.
We also dedicate the concepts and practices within this book to the countless dedicated community volunteers, and aid workers with nonprofit and
nongovernmental organizations around the world. We believe that Lean IT
not only offers benefits to the industrialized countries, but to the billions of
individuals in this world living at the bottom of the pyramid, who must do
more with much less. We hope that Lean IT can help these compassionate
individuals to harness the power and breadth of low-cost information technologies to raise the standard and quality of living for all.

Introduction
Foundation:
What Is Lean IT and Why Is It Important?
1. Why Does Lean IT Matter?
2. Foundations of Lean
3. The Lean IT and
Business Partnership
Integration: Aligning
Lean IT and the Business

Performance: IT
Operational Excellence

4. Lean IT and Business
Process Improvement

7. Lean IT Operations:
ITIL and Cloud Computing

5. Lean IT Lessons Learned
from Lean Manufacturing:
Flow and Pull

8. Lean Software
Development

6. Lean Management
Systems

9. Applying Lean to
Project Management

Leadership Roadmap
10. Leading the Lean IT Transformation
11. A Lean IT Roadmap
Lean IT Case Studies
Barry-Wehmiller, Con-way, Group Health,
Ingersoll Rand, Steelcase, Toyota, Virginia Mason Hospital

Contents
Acknowledgments................................................................................. xv
Introduction.........................................................................................xvii

Section I Foundation
What Is Lean IT and Why Is it Important?
Chapter 1 Why Does Lean IT Matter?................................................ 3
The Business View........................................................................3
The IT View...................................................................................5
What Causes IT and Business Misalignment?.........................6
How Lean IT Encourages Alignment and Creates Value.......8
Moving Forward.........................................................................10
Endnotes......................................................................................11
Chapter 2 Foundations of Lean......................................................... 13
A Brief History of Continuous Improvement........................13
The Age of Scientific Management: 1890–1940.................13
The Age of Engagement: 1940–1995...................................14
The Age of Integration: 1996–Present................................15
Lean Principles...........................................................................16
Constancy of Purpose...........................................................17
Respect for People..................................................................21
Continuous Improvement and the Pursuit of
Perfection................................................................................22
Proactive Behavior.................................................................24
Voice of the Customer...........................................................26
Quality at the Source.............................................................27
Systems Thinking..................................................................27
Flow, Pull, and Just in Time.................................................29
Culture................................................................................... 30
The Central Concepts of Value and Waste.............................33
vii

viii • Contents
Value Stream..........................................................................33
Value........................................................................................33
Value-Added Work: VA, NVA, and NNVA................. 34
The Three Ms......................................................................... 34
Unevenness: Mura........................................................... 34
Overburden: Muri........................................................... 34
.
Waste: Muda......................................................................35
The Power of the Three Ms..............................................36
Lean Tools Overview.................................................................36
A3 Thinking, the Scientific Method, and PDCA..............36
Value Stream Mapping.........................................................37
Kaizen.................................................................................... 40
.
System and Process Kaizen............................................ 40
Kaizen Events, Projects and Daily Improvement.........41
Kaikaku.................................................................................. 42
Standardized Work.............................................................. 42
.
5S and the Visual Workplace.............................................. 43
Let’s Get Started!....................................................................... 43
Endnotes..................................................................................... 44
Chapter 3 The Lean IT and Business Partnership........................... 45
Why Hasn’t IT Been a Focus of Lean?.................................... 46
What Is IT’s Burning Platform for Transformation?........... 48
Lean versus Traditional IT: A Natural Tension?...............49
Legacy Systems.......................................................................50
What about Process Maturity Models?..............................51
What Is Information Waste?.....................................................52
Excess Information Inventory Waste.................................53
.
Information Overprocessing Waste................................... 54
Poor Data Quality Waste......................................................55
Learning to See Information Waste.........................................55
Health Care Information Quality........................................... 56
Lean and Green IT.....................................................................61
The Tools of Lean IT..................................................................63
How Do We Do Lean IT?..........................................................65
Endnotes..................................................................................... 66

Contents • ix

Section II Integration
Aligning Lean IT and the Business
Chapter 4 Lean IT and Business Process Improvement.................. 69
Chapter Objectives.....................................................................69
The Coordinating Function of Information, IT, and
the Lean Office............................................................................70
The Intangible Nature of Information Value and Waste......74
IT Brings Systems Perspective to Business Process
Improvement..........................................................................75
Enterprise Software Applications and the Ghosts of
Projects Past...........................................................................77
The Efficiency–Flexibility Trade-Off: Agility....................79
Process versus Practice........................................................ 80
What Processes and Practices Are “Best”?.............................82
Benchmarking: No Need to Reinvent the Wheel..................83
Using Measurement Effectively................................................85
Compliance: A Special Form of Measurement..................87
Business Process Management (BPM)................................... 88
Prioritizing Process Improvement with Strategy................. 90
Supporting Processes........................................................... 90
Innovating Processes............................................................92
.
The IT Organization’s Contribution........................................93
Endnotes......................................................................................95
Chapter 5 Lean IT Lessons Learned from Lean
Manufacturing: Flow and Pull......................................... 97
Chapter Objectives.....................................................................97
Push versus Pull: What Went Wrong with MRP?.............. 100
Flow, Balance, and Agility......................................................102
.
Kanban Is an Information System for Pull............................104
Creating a Level Schedule.......................................................107
IT Demand Management: The Foundation for Flow..........109
Only Three Choices When Demand Exceeds Capacity.111
The IT Demand Management Cycle.................................112
Demand Planning...........................................................112

x • Contents
Flow Simplifies Demand Planning...............................114
Capacity Planning..........................................................115
.
Balancing.........................................................................116
Executive Review............................................................117
Lean IT Lessons Learned from the Shop Floor....................118
Endnotes....................................................................................119
Chapter 6 Lean Management Systems............................................ 121
Communication...................................................................... 123
.
Knowledge Management and Collaboration...................... 124
.
Knowledge Management....................................................125
Collaborative Workspaces..................................................127
The Evolution of a Lean Intranet Site................................... 128
IT Service Desk (Help Desk)..............................................129
Education and Training......................................................130
Performance Measurement.....................................................131
Lean Business Intelligence.................................................133
Rapid Acquisition and Integration...................................135
.
Strategy Deployment...............................................................136
.
The Role of Information Systems in Strategy
Deployment..........................................................................139
Measuring Value: Lean Accounting......................................140
Focus on Creating Value, Not Cost Reduction....................143
The Importance of the Lean Management System..............144
Endnotes....................................................................................145

Section III Performance
IT Operational Excellence
Chapter 7 Lean IT Operations: ITIL and Cloud Computing........ 149
Quality Is Free..........................................................................150
.
Functional Silo or Value-Adding Service Center?...............152
ITIL: A Lean Approach to IT Services Management..........156
ITIL Is a Set of Integrated Processes.................................157
How ITIL Emphasizes Quality at the Source.......................159

Contents • xi
How ITIL Supports Lean IT..............................................160
.
A3 Problem Solving........................................................160
Voice of the Customer....................................................160
Lean Thinking Applied to Security and License
Management...................................................................161
Quality at the Source......................................................162
Standard Work................................................................162
Measurement...................................................................163
Lean IT in the Cloud................................................................164
Lean Tips for Successful IT Services Adoption...................165
.
Endnotes....................................................................................168
Chapter 8 Lean Software Development. ......................................... 169
.
The Challenges of Traditional Software Development.......171
.
Lean Software Development Basics.......................................174
Lean Software Development Life Cycle.................................177
Organization and Approach..............................................177
Requirements Definition....................................................178
Demand Management........................................................181
Execution and Test Iterations............................................183
Customer Service and Support..........................................186
Measurements......................................................................187
Implementation and Integration Lessons Learned.............189
Endnotes....................................................................................191
Chapter 9 Applying Lean to Project Management..................... 193
The Value of Effective Project Management.........................193
The Project Management Body of Knowledge................197
Portfolio Management........................................................197
Program Management........................................................198
The Project Management Office...................................198
Is Lean a Program?...................................................................199
Project Management.......................................................... 200
The Disconnect between Strategy and Execution:
The Role of the PMO................................................................201

xii • Contents
Improving Project Management Results with Lean
Thinking.............................................................................. 203
Lean Project Management..................................................... 206
The Triple Constraints Model........................................... 206
Applying Lean Thinking to Project Management......... 207
A3 Thinking................................................................... 208
Value Stream Mapping...................................................212
Plan-Do-Check-Act, DMAIC, and Project
Management.........................................................................213
Initiate..............................................................................213
Plan...................................................................................215
The Five Whys...........................................................................217
The Fishbone Diagram............................................................217
Execute.............................................................................219
Monitor and Control..................................................... 220
Close.................................................................................221
Lean Project Management Enables the Lean Enterprise... 222
Endnotes................................................................................... 223

Section IV Leadership Roadmap
Chapter 10 Leading the Lean IT Transformation....................... 227
How to Launch a Lean Enterprise Transformation........... 227
.
Strategic Intent......................................................................... 229
Leadership Is a State of Mind.................................................232
The Importance of Effective Management Systems........... 234
Strategy Deployment...........................................................235
Demand Management....................................................... 236
Business Process Management..........................................237
Project, Program, and Portfolio Management............... 238
Governance......................................................................... 238
.
The Three Levels of a Lean Management System............... 240
Integrating Lean IT................................................................. 244
Endnotes................................................................................... 248

Contents • xiii
Chapter 11 A Lean IT Roadmap.................................................... 249
People Lead Lean IT Change................................................. 249
How to Start the Lean IT Transformation............................252
Lean IT Transformation Roadmap........................................253
Strategy..................................................................................... 254
Establish Leadership Vision and Consensus.................. 254
Articulate Strategic Intent and Drivers........................... 256
Planning.................................................................................... 256
Define and Communicate the Transformation Plan..... 256
IT’s Stop-Doing List.................................................................257
Build a Lean Leadership Team......................................... 258
Create a Basic Toolkit..........................................................259
Assess Key Enterprise Value Streams...............................259
Execution.................................................................................. 260
Launch Pilot Kaizen Projects............................................ 260
Invest in Enterprise-Wide Infrastructure....................... 260
Measure Results and Assess Understanding and
Buy-In................................................................................... 260
Who Goes First?.......................................................................261
Consolidate Gains and Build Momentum...................... 262
Setting the Pace for Change . ................................................ 264
Endnotes................................................................................... 266

Section V Lean IT Case Studies
Case Studies......................................................................................... 269
Barry-Wehmiller: Lean and ERP Work Together............... 269
Con-way: Document Management Virtual 5S.....................271
Con-way: Focused Value Streams..........................................274
Group Health: Lean Software Development Aligns
with the Business Strategy......................................................279
Ingersoll Rand Security Technologies: Lean Six Sigma
Improves Order Quality......................................................... 284
Steelcase: Product Data Management Lean
Transformation........................................................................ 288
Toyota Australia: How IT Helped Implement
Breakthrough Strategy Management....................................291

xiv • Contents
Virginia Mason Medical Center: Laboratory Order
Process and System Improvement.........................................301
Appendix A: A Brief History of Continuous Improvement............. 307
Appendix B: How Lean and Six Sigma Work Together.................... 313
Focus..........................................................................................315
Roles...........................................................................................315
Project Size and Duration.......................................................316
Project Selection.......................................................................316
Complementary Coexistence..................................................317
Appendix C: Information Wastes....................................................... 319
Appendix D: IT Service Desk A3 Example........................................ 329
Index..................................................................................................... 333
About the Authors............................................................................... 349

Acknowledgments
This book was born from our realization of the pressing need to effectively apply Lean thinking to information and information systems. We
are grateful to the many people who provoked, challenged, and elevated
our understanding of this fascinating and diverse subject. This book is
a collection of experiences, lessons learned, and insights from the many
people we have had the privilege of working with over the past 20 years.
Throughout this book, our friend, client, and colleague, Richard Carroll,
has provided thoughtful feedback and, at times, very challenging reviews.
His professional experience and insights inspired us to stress the practical
application of many of the central themes in this book.
Our appreciation also goes to those individuals and organizations who
supported us along the way. These include Jim Womack, Helen Zak, and
Mark Graban at the Lean Enterprise Institute; Jake Raymer and Bob
Miller at The Shingo Prize for Operational Excellence; and Dan Miklovic
at Gartner.
Special thanks for the contribution and support we received from Scott
Alldridge, Dave Almond, Scott Ambler, Valerie Arraj, Bill Baker, Jackie
Barretta, John Bernard, Charlie Betz, John Bicheno, Aaron Brown, Stevie
Campion, Steve Castellanos, Tim Costello, Phil Coy, Beth Cudney, Toni
Doolen, Susan Duke, Troy DuMoulin, Ron Durham, Martin Erb, Dennis
Feagin, Russell Field, Gwendolyn Galsworth, Manoj Garg, Naida Grunden,
Lance Harris, Darren Hogg, Steve Hoeft, Nathan Holt, John Houlihan, Paul
Imai, Ed Israel, Tom Jackson, Gene Kim, Elizabeth King, Susan Kirchoff,
Dr. David Labby, Rick Lemieux, David Mann, Karen Martin, Brian Maskell,
Kurt Milne, Niel Nickolaisen, Debbie Nightingale, Tom Perry, John Pierce,
Travis Pierce, Tom and Mary Poppendieck, Carol Powers, John Price, Jack
ReVelle, Patrick Roach, Andrew Rome, Terry Ross, Brandon Ruggles, Joe
Rutz, James Scott, James Serazio, Praveen Sharabu, Bill Siemering, Rajesh
Solanki, Damon Stoddard, Pete Stofle, Tom Vest, Mike Wegener, Brian
Wellinghoff, Dennis Wells, Brett Wills, Dave Wilson, Stephen Wilson,
and Colleen Young. We’d also like to thank Aurelia Navarro and Caralee
Anley-Casares for their outstanding editing and coaching skills.
xv

xvi • Acknowledgments
We are deeply in debt to those individuals and organizations who
invested the time and patience to write, in their own words, actual case
studies that illustrate real-world examples of the power of Lean IT.
These include Brian Wellinghoff, Barry-Wehmiller; Richard Carroll and
Aaron Brown, Con-way; Mike Manis and Bill Siemering, Group Health;
Rajesh Solanki, Bill Kemerer, and Brent White, Ingersoll Rand Security
Technologies; Mark Swets and Tim Schipper, Steelcase; John Houlihan
and James Scott, Toyota Australia; Lee Darrow, John Eusek, and David
Krause, Virginia Mason Medical Center.
And to the hundreds, or perhaps thousands, of individuals not listed
here, with whom we have interacted over the past years during consulting,
teaching, workshops, conferences, and research, we are grateful. Together
we are forging ahead in a collaborative journey of discovery, learning, and
knowledge sharing, as we collectively develop this new body of knowledge
around Lean IT.
Finally, our heartfelt appreciation and admiration go to our wives, Karen
and Lynda, who endured the many challenges that often accompany projects such as this. Your tireless faith, support, patience, understanding,
acceptance, and love have helped us to become the people we are today.

Introduction
Today’s IT organization faces a clear imperative: reduce costs while improving service levels. At the same time, it must assume an active leadership
role to drive change—continuous improvement, innovation, and agility—
throughout the enterprise, enabling efficient yet flexible business processes
that create value and establish preference in the eyes of each customer.
How can these potentially competing objectives be satisfied with limited
resources? For the answer, we turn to the lessons learned from Lean, which
emerged in manufacturing during the 1950s and has since been embraced
across every industry. It is now the time for IT to adopt Lean thinking as
well.
This is the first definitive and comprehensive text on the Lean IT body of
knowledge, demonstrating how the various aspects of Lean can be applied
to the continuous improvement of information and information systems
in order to enable and sustain the Lean enterprise. Written by Lean IT
pioneers Steve Bell and Mike Orzen, this book distills over 40 years of
experience in applying Lean principles, systems, and tools to information
technology across many industries.
This book was written to help you—whether you are a business executive, manager, IT professional, or member of an improvement team—to
proactively improve, integrate, align, and synchronize information and
information systems to enable breakthrough performance and agility.

What Is Lean IT?
Is business process improvement part of Lean IT? What about best practices and benchmarking? Is agile software development a Lean IT practice?
What about IT operational excellence and the ITIL service management
framework? How about performance management dashboards and scorecards? Is applying Lean techniques to project management considered a
Lean IT practice? And is cloud computing relevant in a Lean IT world?
xvii

xviii • Introduction
The answer to all these questions is yes. But Lean IT is much more than
just a set of tools and practices; it is a deep behavioral and cultural transformation that encourages everyone in the organization to think differently about the role of quality information in the creation and delivery
of value to the customer. Lean IT enables the IT organization to reach
beyond alignment toward fundamental integration, cultivating an inseparable, collaborative partnership with the business.
Whether you are new to Lean, or a seasoned veteran, in this book you
will find new insights into the power of Lean and the critical impact of an
integrated IT function. In this book, Bell and Orzen explore all aspects of
Lean IT within two primary dimensions:
1. Outward-facing Lean IT: Engaging information, information systems, and the IT organization in partnership with the business to
continuously improve and innovate business processes and management systems
2. Inward-facing Lean IT: Helping the IT organization achieve operational excellence, applying the principles and tools of continuous
improvement to IT operations, services, software development, and
projects
These two dimensions are not separate but complementary, two sides of
the same coin. They serve the ultimate objective of Lean transformation:
creating value for the enterprise and its customers.
We begin in Part 1 by exploring the foundations of Lean, and how they
apply to information, information systems, and the IT organization. Part
2 then explores the various outward-facing aspects of Lean IT applied to
business process improvement, supported by an effective Lean management system that links strategy with daily work. Part 3 explores inwardfacing issues: how Lean IT improves the performance of IT operations
and services, software development, and project management, while considering the implications of a shift toward cloud computing. Part 4 brings
it all together, with a comprehensive perspective on Lean management
and governance, offering a Lean IT roadmap to help readers on their own
transformation journey.
The book concludes with case studies from several Lean leaders: BarryWehmiller, Con-way, Group Health, Ingersoll Rand, Steelcase, Toyota,
and Virginia Mason Medical Center. Each offers, in their own words, a

Introduction • xix
practical example of how Lean IT can enable and sustain the Lean enterprise transformation.
An ancient proverb says that the best time to plant a tree is 20 years ago.
The next best time is right now. So let’s get started.

Section I

Foundation
What Is Lean IT and
Why Is it Important?

1
Why Does Lean IT Matter?

Quality information and effective information systems are vital to the success
of the modern enterprise. But the magnitude of IT spending on ill-conceived
or poorly implemented IT projects is staggering. And the dire consequences
of unstable and inflexible systems, failed projects, and chronic misalignment
of IT activities with business strategy are unacceptable—and unsustainable.
The portion of the global economy spent on IT is substantial. For example, banking and finance enterprises in 2008 spent an average of 6.9 percent of their revenue on IT; this figure is a staggering 4.7 percent in health
care.1 If you begin with a conservative assumption that just 20 percent of
these investments do not add significant value to the customer, the numbers add up quickly. And beyond the direct waste of IT dollars spent that
don’t return expected benefits, even more staggering are the consequences
of poor-quality information and ineffective information systems on the
productivity and general health of each organization, and by extension to
the global economy as a whole.
Much is at stake here—clearly IT and the business must significantly
improve the way they work together toward shared outcomes if they’re
going to produce ongoing order-of-magnitude improvement. Aligning IT
with the business has become an all-too-familiar slogan. But what does
alignment really mean? And what are the consequences when alignment is
lacking? Let’s hear from both sides.

The Business View
Business responds to change every day. Customers increasingly want more
choice, speed, and quality, all at a lower total cost, while competitors wage a
3

4 • Lean IT: Enabling and Sustaining Your Lean Transformation
perpetual battle to steal market share. In order to succeed in such a dynamic
and demanding world, business processes and supporting information
systems must be both stable and responsive to change, always focused on
delivering value to the customer. Unfortunately they often fall short.
Business perceptions of IT and the IT organization often include the
following concerns:
• Complexity: Information systems are often difficult to use, costly,
and resistant to change.
• Speed: The IT organization is often perceived as slow moving and late
in responding to high-priority requests.
• Misdirection: The IT organization is focused on technical issues
rather than on solving business problems.
• Foreign language: IT speaks a language that business people don’t understand, and IT often doesn’t understand the language of the business.
• Information overload: IT generates an overabundance of information; many workers suffer from data, e-mail and document waste,
losing countless productive hours each week.
• Project failure: IT projects are sometimes costly, time-consuming,
late, and disruptive, while failing to deliver expected benefits.
• Fragmentation: There are often many disparate, disconnected systems involved in each business process.
• Poor data quality: Data and information are often inaccurate, unreliable, inconsistent, untimely, or, in the worst cases,
counterproductive.
• Inadequate decision support: Users are often frustrated by having too
much data but not enough useful information, at the right time and
in the right format, to support informed decisions.
• Systems anarchy: Many users attempt to control their own information
with workarounds, spreadsheets, and homegrown systems, further
contributing to data fragmentation, redundancy, and poor quality.
• Cost focus: IT is often perceived as a back office cost center, not an
enabler of value creation or a catalyst for innovation.
• Unclear return on investment (ROI): The business is often unable to
measure the ROI of information systems investments, and evaluate
the quality and effectiveness of IT performance. This uncertainty
leads to a vague understanding of IT’s true value to the business,
which in turn leads to uninformed investment decisions.

Why Does Lean IT Matter? • 5

The IT View
Now let’s consider the other perspective: the IT organization is often
overloaded, and reactive crisis management behavior is all too common.
Constant change, shifting priorities, new releases and upgrades, and the
need to balance existing and emerging technologies, all contribute to an
untenable mixture of complexity and volatility. There is usually more
work than IT could ever complete; some companies report three to fiveyear backlogs. And through it all, IT is tasked with keeping information
systems, and the business, up and running at all times, while rigorously
controlling costs. This often creates the atmosphere of a no-win scenario
within IT.
Common IT concerns and challenges include:
• Endless “firefighting”: The amount of unplanned work often exceeds
planned work, which is unsatisfying, exhausting, and ultimately
not sustainable.
• Unclear system requirements: End users can’t always articulate what
they want and often ask for more than they need.
• Conflicting priorities: Business stakeholders are often unable to agree
on priorities, so IT is caught in the middle with unclear goals, budgets, and timelines, having no choice but to pragmatically make
important priority decisions based on incomplete information.
• Lack of engagement: IT is often brought into projects after important
strategic and tactical business decisions have already been made.
• Resource thrashing: Due to unpredictable demand, magnified by
unclear and shifting priorities, IT staff are frequently switched
between projects, causing changeover costs, lost productivity, quality problems, frustration, and fatigue.
• Excessive automation: Rather than eliminating or at least simplifying wasteful processes, they are often automated, creating additional
layers of system complexity and increasing total cost of ownership.
• Poor data quality: This creates additional errors, rework, and
other downstream consequences, and is often caused by lack of
end user training and documentation, and inadequate process
design and controls.

• Scheduling of shared resources and services: A constant challenge,
since specialized resources (human and other assets) are often
shared among multiple projects and operations, each with competing priorities, causing bottlenecks and scheduling delays.
• Regulatory requirements: These can add layers of non-value-adding
activity. The business often focuses on after-the-fact reporting and
control measures, rather than creating high-quality, consistent, and
naturally compliant processes to begin with.
• Outsourcing: The business may believe that outsourcing administrative processes and IT services will reduce costs. However, decision
makers may not fully understand the distinction between commodity processes and those that offer competitive differentiation and
strategic advantage, nor realize that outsourcing may have unintended consequences by restricting agility.
• Budget constraints: There is a natural tendency to focus on IT cost
cutting, rather than waste reduction—emphasizing value creation,
innovation, and enterprise performance improvement.

What Causes IT and Business Misalignment?
The business and IT organization each have a long list of concerns and
challenges—pain they feel every day. While Lean thinking stresses that
every problem is an opportunity for improvement, business and IT stakeholders often have difficulty finding common ground, or even speaking
a common language. As a result, over the years we have observed that IT
organizations are often not aligned or synchronized with the business in
supporting the continuous improvement of business processes. In fact, IT
organizations can become isolated from the business operations they support, losing trust and respect.
Furthermore, because of the complex, volatile, and often risky information systems environment, traditional IT change management moves at a
slow pace. System changes are deployed in carefully planned test-and-release
cycles in an effort to prevent unplanned downtime and business disruption.
This cautious approach to change inhibits business agility, and hinders the
rapid, iterative, and continuous improvement of business processes.

What is at the heart of this disconnect between IT and the business? In
our experience, the lack of integration and synchronization between the
business and IT is caused by unnecessary complexity.
The world is becoming increasingly complex, and large enterprises
have been drawn into ever more intricate circumstances. Global supply
chains, the Internet, intense competition, business combinations, regulation, and security have led to increased necessary complexity. Small
and medium-sized businesses are not immune to this trend, as they
are often drawn into these same global business networks. Their business processes are often no less complicated than those of their larger
counterparts, yet they often lack the IT sophistication and budgets to
address them.
Beyond the challenge of necessary complexity, there is an enormous
amount of unnecessary complexity—self-inflicted pain—arising from the
inappropriate design of business processes and supporting information systems. Lean practitioners call this the waste of overprocessing: excessive work
where cost and complexity exceed the benefits. The human mind has a natural tendency to make things more complicated than they need to be. While
business processes and supporting information systems are naturally complex to some degree, if stakeholders do not deliberately and continuously
simplify and improve them, they naturally degenerate over time, becoming
more and more complex, costly to maintain, and difficult to use.
Overdesign is often the result of a predisposition toward technology and
automation, rather than exercising the discipline to first simplify and standardize underlying business processes. This tendency becomes magnified
when system designers are eager to deploy the latest technology, or enthusiastically develop elaborate solutions to potentially simple problems. The
problem is further aggravated when unnecessarily complex information
systems are applied to unnecessarily complex business processes; a compounding effect of waste (muda squared)* results. In this perfect storm, the
unnecessary complexity of processes and their non-value-adding automation feed on each other—fueling a self-perpetuating cycle that can only be
broken when business process owners and members of the IT organization work together as partners to simplify and improve processes before
applying technology interventions.
* Muda is a common Lean term, the Japanese word for waste, and represents any non-value-adding
activity or obstruction to the smooth flow of work processes.

Seasoned Lean practitioners know, often through firsthand experience,
that many transformation efforts fail to sustain themselves over time,
as organizations gradually fall back on old habits and familiar mediocrity. For a variety of reasons, the IT organization is often not proactively
included in the Lean transformation process. Due to the interdependent
nature of process improvement and IT change management, and because
the execution of business processes frequently relies on technology, the
lack of IT involvement in Lean initiatives is a common contributing factor
for the deterioration of many otherwise sustainable improvements. Put
another way, how could an enterprise successfully transform itself without
addressing the role of quality information systems, and the active participation of the IT organization?
For this reason, we believe the next evolutionary step for many organizations, and the next frontier of Lean across all industries, is the advancement of Lean IT practices to enable and sustain enterprise transformation.

How Lean IT Encourages Alignment
and Creates Value
A Lean enterprise should empower teams to simplify, then when appropriate, automate routine tasks. Process improvement frees up capacity,
providing individuals with more time and better information to exercise
problem solving, creativity, and innovation in situations that are not routine. Early in the transformation effort, teams are often exhilarated when
they realize they can streamline or even eliminate a frustrating process—
one that has always been justified by saying, “That’s just the way we’ve
always done it.”
Once improvement efforts gain momentum and the low-hanging fruit
has been harvested, business and IT stakeholders work together to address
the tougher issues that align strategy with daily activity throughout the
organization. This naturally encourages the development of enterprise
alignment in three dimensions:
1. Vertically aligning strategy up and down the hierarchal organization—from the boardroom through each geographic region, division,
location, and department so everyone understands how their daily

activities support the shared mission, strategy, goals, and objectives
of the organization.
2. Horizontally aligning stakeholders across every functional silo, process, and project—emphasizing the flow of value to the customer,
rather than suboptimization of the individual process steps within
traditional department or workgroup boundaries.
3. Vertically and horizontally aligning information systems—both
manual and computerized—ensuring that IT enables the organization’s strategy and adds value to business processes, projects, and
management systems. Synchronized vertical and horizontal alignment is the balance point for IT-enabled process improvement.
While opportunities for alignment may arise spontaneously during
kaizen (continuous improvement) activities, orchestrating and sustaining
alignment require a disciplined and systemic approach—a Lean management system, a topic we will describe and explore throughout this book.
According to Womack and Jones in their classic Lean Thinking, “Our
advice, based on years of experience, is that every organization should
carefully team a system builder with each of its revolutionary change
agents in order to sustain results.”2
More important than process improvement tools, lasting transformation requires effective management systems that prioritize work and align
daily activities with those goals and objectives that are most important
to the organization. In Lean, the focus of management is to create stable
processes and standardized work which consistently deliver value to the
customer. For a Lean management system framework to be effective, it
must be simple to understand and execute, providing guidance while not
getting in the way. It cannot be too controlling or rigid; otherwise, it will
suppress creativity and learning, hindering improvement and innovation.
And finally, an effective Lean management system must be supported by
quality information.
Lean IT and sustainable Lean enterprise transformation are the result of
collaborative problem solving guided by strategic intent. How is this lofty
aspiration achieved? Let’s start with a working definition of Lean IT that
we will build upon throughout this book:
Lean IT engages people, using a framework of Lean principles, systems,
and tools, to integrate, align, and synchronize the IT organization with the

business to provide quality information and effective information systems,
enabling and sustaining the continuous improvement and innovation of
processes. Lean IT has two aspects: outward facing, supporting the continuous improvement of business processes, and inward-facing, improving
the performance of IT processes and services.

Moving Forward
For many years, Gartner (a global IT research firm) has been asking chief
information officers (CIOs) to identify their top priorities. As you can
see in Figure 1.1, businesses want IT to drive growth and value through
alignment. But now, in the increasingly fast-paced and competitive global
economy, organizations are turning to the IT organization as partners in
change leadership.
Information, information systems, and the IT organization are tightly
interwoven within the fabric of virtually every business process of the
modern organization. IT does matter in the never-ending, always changing race for competitive advantage.
This is especially true as many IT infrastructure and commodity services shift to a scalable, low-cost, cloud-computing model. In this approach
to information systems delivery, with utility-based infrastructure and service-based applications, the business will begin paying for functional utility rather than infrastructure. This will shift a significant portion of annual
IT funding from the capital budget to variable expenditures, potentially
making each investment decision more aligned with the business process
it serves. Along with this shift, the business will expect change capability
Top 3 CIO Priorities
Delivering projects that enable business growth
Linking business and IT strategies and plans
Leading enterprise change initiatives
Reducing the cost of IT
Building business skills in the IT organization

Figure 1.1

Strategic priorities from the Gartner CIO Survey.3

2006
1
2

2009
3
1
2

3

2012
1
2
3

to be more rapid, less disruptive, and at a lower cost. The IT organization must therefore cultivate a clear focus on business process leadership,
maintaining the appropriate balance between efficiency and flexibility …
also known as agility.
Sustainable information systems improvement and innovation cannot be achieved with a focus on technology alone. The Lean IT journey
depends on continuously improving people, process, and technology, in that
order. Eiji Toyoda, who retired as chairman of Toyota in 1994, sponsored
Toyota’s legendary Lean transformation beginning in the 1950s. He succinctly explained the relationship of people, process, and technology in
the Lean journey:
Society has reached the point where one can push a button and be immediately deluged with technical and managerial information. This is all very
convenient, of course, but if one is not careful there is a danger of losing
the ability to think. We must remember that in the end it is the individual
human being who must solve the problems.4*

Endnotes

1 Gartner, “IT Spending and Staffing Report,” November 2009, www.gartner.com/it/
products/ consulting/itkmd/2008/index.jsp.
2. James P. Womack and Daniel T. Jones, Lean thinking, 2nd ed. (New York: Simon &
Schuster, 2003), 314.
3. Gartner, Meeting the Challenge: the 2009 CIO Agenda, (Stamford, CT: Gartner,
2009).
4. Eiji Toyoda, Creativity, challenge and courage (Tokyo: Toyota Motor Corporation,
1983); quoted in Jeffrey K. Liker, The Toyota way (New York: McGraw-Hill, 2004),
159.

* Note to the reader: The introduction of Lean is chiefly attributed to the Toyota Production System,
which emerged in post World War II Japan—for a more comprehensive timeline of continuous
improvement evolution see Chapter 2. At the time of this publication, Toyota is under intense
public scrutiny for quality and safety concerns. In late 2009, just as this issue found its way into
the public spotlight, the new President, Akio Toyoda, admitted that Toyota had lost their way in
the late 1990s. Their focus on quality and customer satisfaction gave way to ambition for growth,
global market share and profitability. Throughout this book we focus on Lean principles, systems,
and tools that helped Toyota through their 50-year ascendancy in the global auto market. These
same principles and tools have helped many companies in other industries as well. It is clear that
even the venerable Toyota cannot violate their own principles without consequences.

2
Foundations of Lean

Chapter Objectives
To create a shared foundation for our discussion of Lean IT, in this chapter
we will:
• Review a brief history of business process improvement, culminating in Lean.
• Establish the foundational principles of a lasting transformation of
culture and performance.
• Explore the concepts of value and waste in relation to Lean problemsolving tools, concepts, and terminology.

A Brief History of Continuous Improvement
Since its beginnings at the turn of the twentieth century, business process improvement has focused on solving problems to improve efficiency, productivity, and quality. We view the evolution of process
improvement as occurring in three distinct stages: scientific management, engagement, and integration.
The Age of Scientific Management: 1890–1940
Beginning in the late 1800s, business pioneers Frederick Taylor, Frank and
Lillian Gilbreth, Henry Ford, and others ushered in an era of efficiency and
13

productivity by introducing standardized manufacturing methods, simplified work, and division of labor. Beginning in 1918, Walter Shewhart pioneered the use of statistical control to improve quality. During this era,
emphasis on output drove significant gains in productivity—for instance,
Taylor at Midvale Steel Company (1878–1890) achieved gains greater than
300 percent—but also left workers uninspired with tedious, repetitive tasks.
During these early process improvement efforts, workers were considered to be property and treated as such. Command and control was the
established management system, in which workers were seen as interchangeable resources, hired for their hands, not their minds. Those in
management positions solved problems and were paid to think, while
workers were expected to follow orders and meet output quotas.
The Age of Engagement: 1940–1995
World War II necessitated a massive shift in industrial productivity that
could not be achieved using the existing system of management or the
prevailing methods of process improvement. The U.S. Department of
War introduced an innovative program, Training within Industry (TWI),
which promoted worker participation, productivity-driven problem
solving, supervisor training, work process documentation, and ongoing
improvement programs that accelerated output and enhanced quality.
During this period, the ideas of W. Edwards Deming, Joseph Juran, and
Armand Feigenbaum broke new ground introducing respect for workers, quality at the source, employee development, team problem solving, and listening to customers to define value. The Quality Movement,
as it became known, shifted the primary focus of process improvement
from productive efficiency to delivering value to the customer. After the
war, Taiichi Ohno and Shigeo Shingo at Toyota, and others in Japan,
embraced the ideas of quality and continuous improvement and developed the Toyota Production System—laying the groundwork for modern-day Lean.
The 1980s were a time of competing methodologies as organizations
experimented with various methods of continuous improvement. Six
Sigma was introduced during this time and quickly became the poster
child of process improvement, with successes at Motorola, Allied Signal,
GE, and many other companies. Six Sigma applied statistical rigor to
improvement processes and emphasized the quantification of results in

Foundations of Lean • 15
terms of dollar savings. With the publication of The Goal by Eli Goldratt in
1992,1 the Theory of Constraints also became popular, demonstrating that
bottlenecks could be exploited to pace production, focus improvement
efforts, and significantly boost throughput. Then in 1990, The Machine
That Changed the World was published by Womack, Jones, and Roos at
MIT.2 This book examined the Toyota Production System and introduced
the term Lean. (For a detailed discussion of how Six Sigma and Lean can
effectively work together, see Appendix B.)
Reengineering the Corporation,3 published in 1993, popularized business process reengineering (BPR) emphasizing process improvement and
encouraging companies to abandon outdated systems, methods, and processes that no longer serve their purpose. While this was well intentioned,
instead of engaging workers, it often was misunderstood and misapplied
to justify downsizing. While the Age of Engagement experimented with
the central idea of engaging people to drive continuous improvement, we
still have a long way to go to achieve Deming’s vision as too many companies still do not engage the hearts and minds of their people.
Note to the reader: For the remainder of this book, unless otherwise
stated, we will use the term continuous improvement to embody all
improvement disciplines, including Lean, Total Quality Management, Six
Sigma, the Theory of Constraints, and the Toyota Production System.
The Age of Integration: 1996–Present
By the mid-1990s, companies around the globe were beginning to apply
Lean, Six Sigma, and other improvement methods beyond the factory
floor to office and administration, supply chain, accounting, and software
development. Nonmanufacturing industries quickly discovered that Lean
manufacturing techniques could produce significant results. Trading
partners were enlisted to develop integrated processes throughout the
supply chain. Advances in computing functionality, speed, and cost
further supported the integration of business systems and communications. In 1996, Lean Thinking4 was published, emphasizing integration of
improvement across value streams, unleashing the current age of integration of improvement methods across all functions of the business, and in
all industries, including health care, insurance, banking, and nonprofits.
For an in-depth discussion of the history of continuous improvement, see
Appendix A. For a timeline of continuous improvement, see Figure 2.1.


Taylor, Gilbreth
Scientific Management

Shewhart at
Bell Labs
Statistical
Analysis/
Process
Control

Feigenbaum publishes
“Quality Control Principles”
Shingo Prize
Total
created
Deming
Quality
Visits Japan
Management
Juran
Visits Japan

1900
Henry Ford
Conveyor Line/
Process Flow

Taiichi Ohno - Birth of
Toyota Production System
Theory of Constraints

Age of Scientific Management

“Reengineering the
Corporation” published
“Lean Thinking”
published

2000

1950
Training
Within Industry

“The Machine That
Changed the World”
published

Age of Engagement

Lean Six Sigma

Six Sigma
Motorola, Allied Signal, GE
Lean Office, Supply Chain,
Health Care, Service
Industries and beyond

Age of Integration

Figure 2.1

Timeline of continuous improvement.

Lean Principles
Many companies and individuals implementing Lean make the mistake
of becoming preoccupied with specific tools. When properly applied,
tools are performance enablers, but it is the principles embedded within
the culture of an organization that compel long-term behavioral change.
Without a clear grasp of Lean principles, focus on Lean tools is like sailing a ship without a rudder. Companies that fail to anchor their continuous improvement efforts with principles rather than tools may experience
short-term localized results, but will not achieve the broad acceptance
needed for sustained improvement. The Shingo Prize for Operational
Excellence* emphasizes this primacy of principles over tools:
As organizations begin a Lean transformation, it is usually at the Tools
& Techniques level in specific areas of the organization. Ideally, the Lean
journey then proceeds to the Systems level, creating a more integrated
and sustained improvement model. Eventually all employees throughout
all business processes develop a deeper understanding of principles (the
* In 1988, the Shingo Prize for Operational Excellence was established to acknowledge Shigeo
Shingo’s contribution to continuous improvement, promote awareness of Lean concepts, and recognize companies that achieve world-class status in Lean manufacturing and business processes.
The philosophy of the Shingo Prize is that world-class performance for quality, cost, and delivery
can be achieved through consistent application of Lean principles and tools in all business processes. See www.shingoprize.org.

‘know why’), empowering the organization to develop and deploy specific
methodologies and practices unique to the organization.5

Principles are timeless, whereas tools evolve as needs change.
Organizations which emphasize principles over tools significantly increase
the likelihood of a successful transformation. By contrast, organizations
that fall in love with certain tools (e.g., 5S and value stream mapping)
may fail to establish the principles that form the bedrock of sustainable
Lean performance. Eventually, the initial enthusiasm for Lean subsides,
improvements become more challenging as the remaining problems get
tougher, and there is nothing to fall back on to sustain long-term change.
In Principle-Centered Leadership, Dr. Stephen Covey stresses the need
for organizations to embrace core principles which serve as a compass,
providing constancy of purpose and alignment of organizational goals
and actions. According to Covey, the most successful companies establish objective, steadfast principles which reflect timeless values that guide
behavior and foster a unique culture.6 When principles are borrowed from
another company, they are easily discarded as soon as they become inconvenient to live up to. Companies should develop their own principles based
on shared values and beliefs, and nurture them as consistent attitudes
and behaviors. The following ideas are a compilation of central tenets we
have seen successfully applied in support of lasting Lean transformations.
Our discussion of Lean principles begins at the base of the pyramid (see
Figure 2.2), laying a solid foundation. Experience has shown three elements that support a strong social structure for a Lean enterprise.
Constancy of Purpose
• Theme: Leadership provides the direction and clarity we need to focus
on the things that matter most—what Deming called “Constancy of
Purpose,” maintaining clarity on important long-term objectives.
This is the cornerstone in the principles pyramid because it provides
the persistent direction needed to influence behavior. When daily
behaviors change, culture also changes.*
* See Out of the crisis by W. Edwards Deming.


Q

T

I

L

A

U

Y
Culture

Flow/Pull/JIT
Quality at
the Source

Voice of
the Customer

Behavior
Foundation

O

E

Perspective

A
L

Capstone
Flow

M

C
O
S
T

R

T
I
M
E

Systems
Thinking

Proactive Behavior
Constancy
of Purpose

Respect
for People

Pursuit
of Perfection

Figure 2.2

Lean Enterprise Principles Pyramid.

• The issue: In many organizations, there is a lack of clarity concerning what matters most. We like to ask various people at our client
sites, “What are the goals of the company, and how do they influence your daily work?” We typically receive a variety of answers.
Two important issues often become apparent: (1) there is a wide
range of understanding of company goals, and (2) goals are at best
indirectly aligned with the concerns and actions of individuals and
workgroups. This manifests as a lack of coordination within departments and between various functional areas, accompanied by counterproductive or conflicting performance measures and incentives.
Activity is often mistaken for productivity and is not necessarily
effective in supporting the organization’s strategy or adding customer value.
• How does the principle address this challenge? Constancy of purpose
focuses thinking and behavior, aligning effort and getting everyone
rowing in the same direction. Effective leaders lead by example, a

responsibility that cannot be delegated. Management should adopt a
visible and active role in supporting change. As people are encouraged to challenge the way we do things around here and begin to
perceive difficulties as opportunities for improvement, collaborative problem solving, and ownership of process quality starts to take
root.
At this critical time, the way management reacts to setbacks
either reinforces proactive behavior or discourages it. Effective leaders embrace an essential truth: poor processes—not people—are the
cause of most problems. For most of his career, Deming put forth the
85/15 rule, suggesting that 85 percent of problems were inherent to
process design and not controlled by the people doing the work. He
later revised the estimate to 96 percent.
A clear understanding that Lean is about fixing processes, not people, creates the tone for fact-based improvement. In this atmosphere,
people move out of their comfort zones, and actively seek out problems
as opportunities to make things better. Every successful Lean transformation we have witnessed has been led by a champion who provided the focus, enthusiasm, and drive that inspired others to move
beyond business as usual. This role can be filled by an executive sponsor, a program manager, or any person in your organization who possesses credibility and respect. Early successes inspire others to become
involved and build momentum. Gandhi said it best: “Be the change
you wish to see.”
To be effective, leadership should be balanced with employee-driven
participation. In a process known as strategy deployment,* leaders establish objectives (top-down) and employees determine how to best accomplish and measure them (bottom-up).
Some organizations often manage in a hierarchal, top-down manner
with management at the top of the pyramid, issuing commands downward. Lean inverts this pyramid, as shown in Figure 2.3. At the very top
are customers and business partners, since they define value and create
demand pull signals that trigger work to be performed. Next are the workers, who most frequently interact with those customers, vendors, and
* Strategy deployment (also known as policy deployment, hoshin kanri, and hoshin planning) is a
management system to align daily work with strategy. See Chapter 6.

CUSTOMERS, SUPPLIERS, AND TRADING PARTNERS

Associates
Team Leads & Supervisors
Managers

Strategic
Direction

Improvement
Ideas

Senior
Leadership

Figure 2.3

Lean Enterprise Inverted Managerial Pyramid.

trading partners and are, thus, in the best position to directly identify
those actions that add the most value.
Management’s role is to translate and communicate purpose, strategy,
and goals throughout the organization to teams and workers. Prioritization
of improvements and consensus is achieved through a back-and-forth dialogue between management and employees that aligns strategy and action
at each level, reconciling action plans with available resource capacity.
Rather than being told what to do, the people closest to the customer and
the work develop and implement ideas for improvement based on a clear
understanding of how their actions support company objectives.
Summary: Executive leadership’s responsibility is to define strategic goals and create a constancy of purpose. Management’s role
is to eliminate barriers to success, stabilize processes, and support employees to develop problem-solving skills, so they can take
ownership of their work and assume responsibility for continuous
improvement. When considering potential areas of improvement,
the alternatives are almost endless, so an important enabler of effective leadership is a formal decision-making framework. This establishes clear priorities and ensures consistent choices are made when
selecting improvement projects. Alignment and prioritization are
consistent themes throughout this book, and we’ll revisit constancy
of purpose in Chapter 10.

Respect for People
• Theme: The second foundation principle is respect for people. All
individuals possess a unique collection of experience and insight,
and can make a distinctive contribution when they participate in
process improvement. Cross-functional problem solving can only
occur when respect for people is consistently applied throughout
all levels of the organization. Respect drives employee development,
encourages participation, and improves supplier, customer, and
community relations.
• The issue: When people sense that their input is disregarded or
not respected, they tend to withdraw their support, concern, and
active participation. Even worse, they may become cynical or
even confrontational from having been left out of the dialogue.
If leaders don’t engage the people doing the work with genuine
respect, change for the better has little chance of succeeding. This
is because those who have the knowledge and ability to create lasting improvement have no stake in the final outcome. Worse yet,
organizations lose the creativity and innovative potential each
person offers.
• How does the principle address this challenge? Respect for people
unlocks personal excellence and creative potential. In a collaborative learning environment, people know their ideas are valued and
appreciated. Those individuals actually doing the work see potential
improvement opportunities at a deeper level than anyone else in the
organization. They hold the insight, understanding, and passion to
add value and drive daily improvement. In some workers, these skills
are dormant from lack of use.
Good leaders tap into this inexhaustible resource by mentoring,
coaching, and collaborating with their associates, seeking their opinions and respecting differing points of view. Lean transformation
requires the input, support, and active participation of everyone in the
organization. Lean organizations cultivate collaborative problem solving where people become scientific thinkers, learning from successes
as well as failing forward from mistakes and setbacks. Questioning the
way we’ve always done it is not only accepted, but also respected and
positively acknowledged.

Humility is a very effective catalyst for a culture of continuous improvement, embodied in the Japanese term hansei, meaning mindfulness and
self-reflection. Everyone in the organization must feel safe about sharing
ideas and taking experimental risks, confident of not being ridiculed.
Experimental risk is feeling comfortable enough to try new ways of doing
things—approaching them as a means to validate new ideas, understanding, and predictions. Experiments never fail because they provide new
evidence, clues to be used to develop further improvements! When we
come to accept that every process can be improved, and that everyone
brings a unique set of life experiences and perceptions to the table, people
begin to appreciate that a good idea can come from anyone and that ideas
have no rank.
Summary: Respect for people taps into an unlimited reserve of creativity by treating every individual with consideration and regard. Give
your people a good reputation to live up to.
Continuous Improvement and the Pursuit of Perfection
• Theme: The final building block in our foundation is the continuous
pursuit of perfection. Today’s solutions, while they may be adequate,
are at best temporary. Change is relentless, and new ideas are needed
whenever current standard work no longer produces acceptable
results. In a Lean culture, workers embrace change as inescapable
(and even desirable), proactively meeting challenges. Every individual should see his or her job as having two inseparable components:
daily work and daily improvement.
Changing social norms and daily behavior involves shifting the tone
of the workplace from reactive firefighting (a deeply ingrained reflex
often based on emotion) to proactive problem solving (methodical
rational behavior).
• The issue: We are all creatures of habit and naturally territorial.
Most people like change, but they don’t like being changed. Effective
change is usually disruptive and uncomfortable. Left to our own
human nature, we fall into patterns of thinking and behavior that
actually avoid change and stifle creativity and innovation. When

Lean is perceived as a program or project (with a beginning and an
end point), people may assume it is just another management flavor of the month that will blow over. They may then decide the best
course of action is to keep your head down and ride low in the middle
of the pack until the storm passes. Without active engagement and
constant reinforcement, we naturally fall back on old habits of thinking and behavior.
• How does the principle address this challenge? When we collectively
recognize that if we are not improving we are falling behind, our
understanding of daily work undergoes a radical shift. This realization breathes fresh ideas and energy into the organization, inspiring us to continually reinvent ourselves. With a constant focus on
improvement, we avoid falling into patterns of stagnation in our
daily behavior.
In The Fifth Discipline,7 Peter Senge uses the term learning organization
to describe an environment where people continually develop their abilities
to understand complexity and improve shared understanding. Setbacks
and failures are treated as opportunities to reflect and learn. Perhaps
most importantly, learning organizations encourage systems thinking—
the ability to comprehend and focus on the whole while understanding
the interrelationship of the parts. Each individual must begin identifying
with the organization’s overall purpose and mission as well as individual
department, workgroup, project, and process-level goals. The pursuit of
perfection requires companies to become learning organizations where a
trial-and-discovery method of process improvement is embraced without
fear of reprimand or ridicule.
The pursuit of perfection is often misunderstood—it’s an aspiration, but
one that is never achieved. Voltaire said, “The perfect is the enemy of the
good.” With Lean, whether in the factory, the office, or the IT organization, we should avoid over-automating or striving for the hyper-efficiency
of a “perfect solution”—these ultimately create waste and rigidity, and
resist further cycles of improvement.
Summary: The endless quest for excellence stimulates everyone in the
organization to make things better. People no longer see a difference
between performing the work they do, improving the work they do,
and improving themselves.

Proactive Behavior
Behavior
Foundation

Proactive Behavior
Constancy
of Purpose

Respect
for People

Pursuit
of Perfection

• Theme: Building on our foundation, proactive behavior means taking the initiative, assuming personal responsibility for the quality of
our work and work environment. Being proactive means seizing the
opportunity to make a difference every day.
• The issue: Why do the vast majority of companies fail to achieve a
sustaining Lean transformation? Perhaps one reason is that many
people in the business world tend to be seasoned firefighters but
poor police officers. Stereotypically, firefighters react to problems*
by rushing into burning buildings and attacking everything that
may be an issue (flames and smoke). They live on adrenaline during periods of intense focus until the crisis passes, and accept (even
sometime enjoy) emergencies as part of normal operations. Police
officers, by contrast, are methodical proactive problem solvers who
walk the beat investigating the current situation to determine root
causes of problems. Their focus is long term, systematic, preventative, and disciplined. They ask lots of questions and shoot only when
necessary.
• How does the principle address this challenge? In The 7 Habits of
Highly Effective People, Dr. Stephen Covey introduces a model called
the Time Management Matrix, dividing work into four quadrants
based on importance and urgency. He points out that the highest
value-added work lies in the Important but Not Urgent quadrant,
where proactive planning, prevention, preparation, learning, and
development occur. Unplanned work focuses on issues that are
either Important and Urgent (reactive firefighting) or Not Important
and Urgent (deceptive activities that seem important due to their
urgency). In either case, they steal time and resources that should be
used to proactively address Important but Not Urgent work.
* Our hats go off to real firefighters, some of the bravest and most proactive thinkers we know. In
this example, we are talking about the common label of firefighting as a behavior.

Urgent
Reactive
Important

Not Urgent
Proactive

Fire Fighting
Crisis Management
Interruptions
Rework

Lean Thinking
Alignment
Prioritization
Planning, Prevention,
and Preparation
Measurement

Deceptive
Not
Important

Misaligned Objectives
Misunderstood Tasks
Unproductive Meetings
Excessive Email
Interruptions

Non-Value
Added
Work

Figure 2.4

Lean perspective of the importance paradigm.

Established culture often reinforces reactive firefighting at the cost of disciplined problem solving. Because firefighting is highly rewarded, some
firefighters become very good arsonists. This unconscious behavior creates a never-ending cycle of interruptions and interventions which introduce more instability. Cultural DNA8 strongly influences organizations
to revert to reactive behavior when problems arrive and the pressure is
on. Ironically, reactive behavior usually introduces waste and creates more
problems than it solves—actually preventing sustained progress.
As shown in Figure 2.4, Lean shifts the emphasis away from unplanned
work to proactive continuous improvement. This approach is effective
because it feeds itself: as more time is invested in process improvement
efforts, less unplanned incidents occur, which frees additional time to
work on more proactive improvements.
Summary: Deming described quality as “pride of workmanship.”
Proactive behavior requires both personal and team pride combined
with discipline. We then take responsibility for solving problems and
strive for quality at the source.

The next level in our pyramid addresses awareness, with three essential
perspectives embraced by the Lean enterprise: voice of the customer, quality at the source, and systems thinking.
Voice of the Customer
Perspective

Quality at
the Source

Voice of
the Customer

Systems
Thinking

Proactive Behavior
Constancy
of Purpose

Respect
for People

Pursuit
of Perfection

• Theme: Lean thinkers always ask, “What does the customer value,
want, and need?” By understanding how customers and information
system users define value, they position themselves to begin with the
end in mind.
• The issue: It is imperative that organizations develop a clear understanding of what customers care about most. Often they assume they
know what customers desire, and as a result deliver products and
services that fail to address real customer needs.
• How does the principle address this challenge? Most processes have
both internal customers who receive work output and external
customers (trading partners and end users) who receive products,
services, and information. To clearly understand the voice of the
customer, you must engage with your customers, whoever they are.
Use customer segmentation, interviews, focus groups, surveys, sales
and service data analysis, and point-of-use observation to develop
critical-to-quality requirements. Then return regularly to the customer to ensure improvements and innovations deliver what the
customer values most.
Summary: Consistently listening to the voice of the customer ensures
you are focusing on the right issues and making improvements that
will be valued by your current and future customers. Understanding
customer needs and desires more clearly than your competition will

enable you to be more responsive and agile, creating competitive
advantage and market leadership.
Quality at the Source
• Theme: Quality at the source means doing it right the first time,
every time: imperfect work is not sent to the next operation or to the
customer.
• The issue: The we’ll fix it later approach is accepted in many organizations due to time pressure, inadequate training, and a lack of
understanding of the entire process. The best time to solve a problem is at the time it occurs because evidence is fresh, workers are
engaged, and it prevents the release of additional defects until the
root cause of the problem is corrected. The focus of daily work should
be producing quality at the source. Solely focusing on quickly working through the backlog results in the same problems reemerging
time and time again. Time-consuming corrections, clarifications,
and completions become necessary when quality is poor, creating
interruptions and delays which increase costs and aggravation.
• How does the principle address this challenge? In a Lean environment, there is an obligation to stop and fix problems, and a shared
commitment to avoid passing known defects downstream toward
the customer. By applying standardized work, training, and error
proofing, every effort is made to ensure the problem or defect is prevented the next time. People assume responsibility for the quality of
the work they pass on, regardless of where the problem originated.
This fundamental change in attitude reduces waste and frustration.
More importantly, problems become the evidence used to detect root
causes and prevent their recurrence.
Summary: When quality at the source takes hold, more time is available to do the work customers are paying for, which in turn improves
productivity, cost, quality, and morale.
Systems Thinking
• Theme: The third element of awareness is systems thinking—the
ability to view the interconnected processes that make up the entire

value stream while being aware of the cause-and-effect interdependencies that either add value or create waste. A value stream is comprised of all processes, tasks, and activities used to bring a product
or service from concept to customer, and includes all information,
work, and material flows.
• The issue: To avoid solutions that create localized optimization
and silo behavior, Lean thinking requires an awareness of the
simultaneously integrated and interdependent nature of all business functions and underlying information flows. This is not the
way our minds and our organizations naturally work; we tend to
focus on specific pieces of a puzzle rather than the entire picture.
Inappropriate measures and incentives often reinforce this narrow
focus.
• How does the principle address this challenge? When problem solving is founded on a clear understanding of the overall value stream
and the customers it serves, companies avoid the common error of
making local improvements which often transfer inefficiencies and
waste from one area to another. Cross-functional teams provide the
breadth of understanding required for systems thinking, spanning
the value stream by connecting the expertise and understanding of
each team member.
The holistic perspective needed here may be unfamiliar to many professionals because they have spent their careers honing skills in a specialized area (e.g., engineering, IT, finance, and human resources). A systems
mind-set stimulates the creative potential of employees by broadening
their horizons and challenging the breadth of their perception. To make
improvements that impact external customers, a value stream must be
viewed as a system. Value stream mapping and systems thinking are
complementary, helping people to view business processes in a new context: flow.
Summary: Systems thinking enables us to see the whole, creating a
smooth flow of value to the customer.

Flow, Pull, and Just in Time
Flow

Flow/Pull/JIT
Quality at
the Source

Voice of
the Customer

Systems
Thinking

Proactive Behavior
Constancy
of Purpose

Respect
for People

Pursuit
of Perfection

• Theme: The next level of the pyramid focuses on flow—the uninterrupted progression of materials, services, and information. As
Jeffrey Liker emphasizes in The Toyota Way, “Flow where you can,
pull where you must.”9 Allow work to flow whenever you can; when
flow is interrupted, use pull signals to initiate work.
• The issue: Poor flow of work manifests as interruptions, delays, rework,
and cost. Deficient information flow causes even more irregular flow
of materials, work in process, and finished work inventory where it
is common to have too much (overstock) or too little (shortage). In
an office environment, inventory is usually composed of paper and
electronic documents, including e-mail. Work in process is all work
started but not finished plus work queued up for the next process.
As a general rule, the more work in process there is, the less work is
able to flow, and the more slowly work is completed. Work in process
inventory causes congestion, confusion, and delays; hides problems;
must be managed and tracked; often becomes obsolete; and is often
reworked or discarded. This in turn creates further interruptions,
delays, rework, and cost.
• How does the principle address the issue? Flow is achieved through
eliminating delays and interruptions throughout the entire value
stream. Value stream mapping is an effective tool for identifying,
quantifying, and eliminating waste. The smooth flow of information produces the transparency and visibility needed to coordinate
efficient flow of work. When information is used to level demand,

balance capacity, and improve quality, flow is improved and value is
delivered to the customer sooner.
When there are no interruptions in a series of tasks, work flows smoothly.
Typically, work will flow until it encounters a barrier that prevents it from
continuing (e.g., physical or electronic transportation to another location).
When work cannot be designed to flow, it needs to be connected to the
next series of tasks that do flow using a pull mechanism.
Pull removes the opportunity for overproduction* and supports flow by
regulating work activity. In a pull system, all work is performed just-intime triggered by a customer demand signal (kanban). The sequence of the
pull signals establishes clear priorities, the receiver of the signal is directly
accountable, and the signal itself provides visibility.
As overproduction decreases, work-in-process inventory decreases and
flow is improved; work stoppages and delays happen less frequently, further reducing work in process, response time, and backlogs.
Summary: As flow improves, information and work product are received
earlier by both internal and external customers. Flow releases pentup, committed time and resources, effectively increasing an organization’s capacity to respond to change with limited disruptions. This
translates to better quality, response time, customer service, inventory turns, and ultimately cash flow.
Culture
• Theme: The capstone on our principles pyramid is culture, which
represents an organization’s shared beliefs and values, manifested as
attitude and behavior. Culture is an outcome of behavioral change.
(See Figure 2.5) A Lean culture of continuous improvement creates a shared capability which enables people to proactively seek out
and solve problems, resulting in superior performance, competitive
advantage, and bottom-line financial results.
• The challenge: Sustained Lean transformation is only possible when culture evolves to reinforce new behaviors. The vast majority of companies
* Overproduction was considered the most harmful form of waste by Taiichi Ohno because it generates other additional forms of waste (inventory, transportation, etc.).


Q
U
T

I

R

L

A

O
L

Y

E

Capstone

M

C
O
S
T

A

T
I
M
E

Culture
Flow/Pull/JIT

Quality at
the Source
Voice of
the Customer

Systems
Thinking

Proactive Behavior
Constancy
of Purpose

Respect
for People

Pursuit
of Perfection

Cornerstone

Figure 2.5

Lean Enterprise Principles Pyramid.

that have embarked on a journey of continuous improvement (Lean,
Six Sigma, or another discipline) have not realized long-term breakthrough results—having failed to transform their daily behavior and
culture. The hearts and minds of their people are not engaged nor
committed.
• How does the principle address the issue? We are often asked, “How
do we create a Lean culture?” Our belief is that a Lean culture is
developed over time by changing the way people perceive their roles
and perform their daily work. In Who Says Elephants Can’t Dance?
Lou Gerstner, former CEO of IBM, emphasizes the importance of
culture:
I came to see, in my time at IBM, that culture isn’t just one aspect of the
game—it is the game. In the end, an organization is nothing more than the
collective capacity of its people to create value.10


Embedding Principles
into Culture
Structuring Tools into a
Systems Context

Creating Point Solutions
Figure 2.6

Stages of Lean transformation.

The evolution of a Lean culture often begins with the adoption of continuous improvement tools, followed by the formation of behavior-driven
systems, guided by shared values and principles. Tools provide structure
and capability, systems* develop common practices and procedures, and
principles provide a foundation which reinforces cultural standards and
daily behaviors. (See Figure 2.6.)11
It’s one thing to create a mission statement and clever slogans articulating strategic objectives of the organization, and an entirely different
thing to have a deeply shared vision and constancy of purpose by all
employees. Shared beliefs are reflected in self-created social systems
that become the way we get things done around here. As organizations
evolve, certain behaviors become the norm and are reinforced by daily
actions.
When it is customary for people to take personal responsibility for the
quality of their work, actively solve problems in a collaborative spirit,
and give their very best, the energy and excitement of the workplace are
palpable. The satisfaction of being part of an effective team accomplishing clear objectives is contagious. When actions are aligned with the
principles we’ve discussed, they reinforce the strategic direction of the
* Systems, in this context, are collections of tools and procedures which form a standard way of
doing things. Examples of Lean systems include kaizen process, A3 thinking, standard work, 5S,
level loading, measurement, the visual workplace, and strategy deployment.

organization while creating a constancy of purpose in support of unrelenting improvement.
Summary: Aristotle said over 2,000 years ago, “We are what we repeatedly do. Excellence, then, is not an act, but a habit.” Shared values
and principles will serve as a compass throughout your Lean journey. Develop a solid foundation of main beliefs that inspire respect,
proactive behavior, innovation, and constant learning, and you will
be well on your way toward sustainable operational excellence.

The Central Concepts of Value and Waste
The principal focus of Lean is problem solving for the primary purpose of
delivering value to the customer, achieved by the systematic elimination of
waste throughout the value stream. While many people we meet feel they
understand these concepts, often we discover their grasp of these terms
varies greatly. Let’s begin by defining value stream, value, and waste.
Value Stream
A value stream is composed of all the life cycle processes required to bring
services, products, and information from concept to customer. This includes
all current activities, whether or not they create value, carried out for internal
and external customers. Value stream improvement requires a cross-functional perspective, drawing individuals, workgroups, and departments away
from local optimization and silo thinking. Systems thinking enables people to
see the whole process and understand value from the customer’s perspective.
Value
Value is what the customer wants and is willing to pay for. Intuitively, we
all know some activities add value for the customer while others do not.
Surprisingly, value stream mapping analysis reveals that, for most value
streams, processes add value only 5 percent of the time it takes to deliver
the product, service, or information to the customer. To put it another
way, no value is created at least 95 percent of the time!

Value-Added Work: VA, NVA, and NNVA

All components of work can be characterized as value-added (VA),
non-value-added (NVA), or necessary but non-value-added (NNVA)
work. The assessment process of whether an activity is adding value is
straightforward but not always easy to answer: if they knew about it,
would customers be willing to pay for it? Alternatively, would the customer judge the product or service as less valuable if the task was not
performed?
NNVA work includes tasks the customer may not choose to pay for but
the company is legally or ethically compelled to do (e.g., filing tax returns,
Sarbanes-Oxley Act [SOX] compliance, supporting the local community,
and other acts of corporate social responsibility).
The Three Ms
Wasteful practices can be divided into three categories known as the three
Ms: mura, muri, and muda. The differences and similarities among these
terms lead to a deeper understanding of the impact of wasteful practices
and the need for their methodical elimination.
Unevenness: Mura

Unevenness and variation (mura in Japanese) represent inconsistency in
the flow of work, caused by changes in volume (uneven demand), mix
(variation), and quality. Customers desire variety and flexibility, but these
should be achieved while avoiding unnecessary complexity and chaotic
behavior. It is the responsibility of management to minimize the impact of
variation by encouraging standardized product and process design, leveling demand, and introducing flow, pull, and just-in-time production control and delivery systems.
Overburden: Muri

Overburden (muri in Japanese) represents placing unrealistic workloads on people and equipment, which leads to stress, mistakes, rework,
and poor morale. It is the job of management to remove overburden by

making use of work design,* training, standardized work, and demand
management† to support a smooth flow of products, services, and
information.
Waste: Muda

Waste (muda in Japanese) is any NVA work (defined earlier). In the
mid-1950s, Taiichi Ohno introduced the concept of systematic elimination of waste at Toyota. This evolved into the Toyota Production
System’s seven wastes found in production (see also Chapter 3 and
Appendix C):
1. Overproduction: producing more or sooner than is needed by the
customer (this contributes to the other wastes)
2. Inventory: having more than the minimum levels of raw materials,
work in process, and finished goods required to support flow and
pull (excess inventory disguises other wastes)
3. Waiting: stopping or slowing down for work to arrive
4. Transportation: movement of work product, information, and
materials
5. Overprocessing: excessive or unnecessary work
6. Motion: unnecessary physical movement
7. Correction: reworking defects and mistakes, inspection, and scrap
Often an eighth major waste is included in the list: unused human creativity and potential. Recently many Lean practitioners have also begun
to add environmental waste to the list. Every type of waste mentioned is
found in all business environments, not exclusively manufacturing.
By learning to see those activities that consume time, materials, and
effort while failing to add value, individuals and teams identify and remove
muda from the value stream. While simple in theory, it requires practice
to develop beginner’s mind—the ability to look at a familiar process as if
for the first time and really see what is happening.
* Work design centers on creating work procedures and environments that support efficient execution of tasks and smooth throughput of work by focusing on the difficulty of tasks, job stress, and
employee satisfaction.
† Demand management is the practice of matching available capacity to a prioritized backlog of
work to support an even flow of attainable work. See Chapter 5.

The Power of the Three Ms

The three Ms bring a comprehensive perspective to waste reduction and
reinforce a cycle of continuous improvement.
Managers are responsible for addressing the systemic conditions of mura
and muri. Variability (mura) reduction is achieved through selecting markets, product design, and pricing, which supports level demand. Overburden
(muri) reduction focuses on designing processes for workflow and consistent quality, standard work, cross-training, and balancing resources to create stable capacity conditions that support the smooth flow of information
and work. When management reduces the systemic wastes of variability
and overburden, levels demand, and frees capacity, workers then have the
time, energy, and focus to continuously improve their activities to eliminate
waste (muda), while simultaneously engaging in their daily work.

Lean Tools Overview
Lean offers a wide variety of problem-solving tools which provide structure
and consistency to identify and quantify NVA tasks, analyze problems,
discover root causes, develop countermeasures, implement improvements,
and measure results. In this section, we provide a brief description of the
most commonly used Lean tools.*
A tool is anything that enables us to accomplish a task more easily and
effectively. We discovered long ago that, if you start out with just a handful
of tools and then hone your process improvement skills, you will be in a
much better position to learn and apply additional tools as you need them.
A3 Thinking, the Scientific Method, and PDCA
At the heart of Lean is the A3, a single piece of paper used to summarize the
definition, scope, discovery process, findings, proposed countermeasures,
* For an in-depth discussion of Lean tools, see Pascal Dennis, Lean production simplified (New
York: Productivity Press, 2007); John Bicheno and Matthias Holweg, The Lean toolbox, 4th rev. ed.
(Johannesburg, South Africa: Picsie Books, 2008); and Chet Marchwinski and John Shook, Lean
lexicon (Cambridge, MA: Lean Enterprise Institute, 2008). For an in-depth review of Six Sigma
tools, see Thomas Pyzdek and Paul Keller, The Six Sigma handbook, 3rd ed. (New York: McGrawHill, 2009).

and results of a problem-solving exercise. A3 is an international paper size
approximately 11 × 17 inches (297 × 420 millimeters), suggesting that a
person or team be able to communicate the essential elements of a problem-solving effort summarized on a single sheet of paper.
An A3 can also be employed as a proposal or status report. But the A3
is much more than a form; A3 thinking is a mental framework used to
reinforce the scientific method of solving problems: Plan-Do-Check-Act
(PDCA*). The scientific method is a structured approach to problem solving
which includes observation, development of a tentative description of cause
and effect (hypothesis), prediction, testing, and evaluation. More often
than not, attempts at problem solving lack structure and method. People
naturally jump to solutions, focusing on symptoms instead of root causes,
and failing to fully understand, let alone solve, the problem at hand.
Benefits from applying A3 thinking include fact-based decision making,
consensus building, clearly documented assumptions, defined targets,
faster results, and follow-up to ensure that improvements are sustained.†
Although there are many different formats for an A3, the specific form
design is not important—but the disciplined A3 thinking process is. For
an example of an A3, see Appendix D.
Value Stream Mapping
Many people have experience with process mapping (as shown in
Figure 2.7), which provides a detailed view of the tasks and decisions contained in a specific process. While process mapping is very effective at
providing a detailed step-by-step view of a specific procedure, it does not
attempt to capture information about flow, elapsed time, cost, or quality
at the value stream level.
Value stream mapping visually depicts the flow of information, materials, and work across functional silos with an emphasis on quantifying
wastes, including time and quality. As shown in Figure 2.8, however, a
value stream map can also illustrate a lower level of detail. Typically, the
focus is at a more macro level than process mapping and does not include
individual tasks and decisions.
* In healthcare this is commonly known as PDSA, Plan-Do-Study-Act.
† For an in-depth example of A3 thinking and PDCA, see John Shook, Managing to learn
(Cambridge, MA: Lean Enterprise Institute, 2008).

Process map example.

Figure 2.7

Service Desk Receives
Request

Start

Service Desk
Initial Routing Process

Covered in
Service
Catalog?
No

Yes
Yes

Acceptance

Create Ticket

Covered
Service?

Delivery

Close Request

End

Forward to Review
Board Queue

Close Request

No

Inform Requestor

Log Service/Close
Ticket

Inform Requestor/
Schedule Work


Days

99.7

57.76

Quality

%

%

18.96 Days

NVA

Lead Time

Hrs

1.40

Cycle Time

Value stream map example.

Figure 2.8

1

Summary Data

Production
Lead Time

%

IN

3

Mins

Quality

80

%

Production 45 Mins
Lead Time

Cycle Time

%

Days

Mins

Review Tags
for Category
and Pricing

100

Quality

95

Quality

Send Tags
to Admin.

5

10

1

Cycle Time

Production
Lead Time

5

Days

Cycle Time 60 Mins

Pick up and
Driver Makes
Receiving Tag

Production
Lead Time

Receiving Crew
Grades Drums and
Completes Tag

Excel

Share
Point

1

Mins

100

One Tag per
Customer

%

2

Mins

100

1

Mins

%

Quality

100

%

Production 2.5 Days
Lead Time

Cycle Time

File Tag

Quality

Production 20 Mins
Lead Time

Cycle Time

Conﬁrm in System

Quality

Production
Lead Time 10 Mins

Cycle Time

Scheduled by
Dispatch
Scheduling Program

SAP

2

Mins

100

%

1

Mins

100

%

1

Mins

Quality

100

%

Production 50 Mins
Lead Time

Cycle Time

Tag and Invoice
to Customer

Quality

Production 20 Mins
Lead Time

Cycle Time

Update Inventory
Batch Size 5

Quality

Production 120 Mins
Lead Time

Cycle Time

Print Out P/U
Request
(local)
1

Mins

100

1

Mins

100

%

Quality

Production
Lead Time

Cycle Time

100

4

2

%

Hrs

Mins

Sort by Location

Quality

Production 15 Mins
Lead Time

Cycle Time

%

POST

IN

11

FAX

Quality

Production
Lead Time

Cycle Time

%

Mins

Mins

100

4

1

%

Days

Mins

4

Mins

Quality

95

%

Production 120 Mins
Lead Time

Cycle Time

Process and Invoice

Quality

Production
Lead Time

Cycle Time

Mail to Corporate
via Cleveland

80

3

3

CSC Receives
Order

E-MAIL

Interoﬃce 3 X week
File a Copy

Quality

Production 60 Mins
Lead Time

Cycle Time

CSC Enters
Information
into SAP

Receiving Information
Current State

POST

10x Day

Customer


Beyond the physical map itself, the activity of value stream mapping helps
to bring a multidisciplinary team together to see the whole process from a
work and information flow perspective. When a cross-functional team is
assembled (ideally including a representative from IT) to map a process,
a picture of the current state emerges through rounds of discussion and
discovery. Once the team agrees that the current-state value stream map
accurately depicts the situation, they are in a position to make data-supported predictions on which improvements will yield the greatest results.
Developing a current-state value stream map brings a shared understanding
and consensus to the cross-functional team, representing stakeholders—
including in-house resources, internal and external customers, vendors,
and suppliers—from various parts of the organization that may seldom
otherwise interact. As the team reaches agreement on the current state of
the process and the waste it contains, they create a baseline for developing
a future blueprint of the improved value stream, in order to highlight gaps
between the current and target future state, prioritize activities, and establish metrics.* Maintaining an updated current and future-state value stream
map keeps the team focused, enabling targeted continuous improvement
that delivers meaningful and quantifiable results.
Kaizen
Kaizen† (Japanese for continuous improvement) is a systematic improvement methodology that is central to Lean. Kaizen involves many small
incremental improvements and provides structure to process improvement.
System and Process Kaizen

There are two kinds of kaizen: system (also called flow) and process
(Figure 2.9). System kaizen attempts to improve the overall value stream
by enhancing material and information flow, and is the focus of management. Process kaizen, performed by teams and individuals, concentrates on reducing waste in specific focus areas within the value stream.
Improvement in one type of kaizen positively impacts the other.
* See Beau Keyte and Drew Locher, The complete Lean enterprise: Value stream mapping for administrative and office processes (New York: Productivity Press, 2004); and Mike Rother and John
Shook, Learning to see (Cambridge, MA: Lean Enterprise Institute, 1999).
† See Masaaki Imai, Kaizen: The key to Japan’s competitive success (New York: McGraw-Hill, 1986).


Senior
Mgmt
Mid
Mgmt

System Kaizen (value stream improvement)
• Improve Work & Info ﬂow
• Eliminate overburden
• Eliminate variation

Process Kaizen
(elimination of waste)
• People
• Process

Team
Members
Top down

Process Focus

Daily
Kaizen

Bottom up

Figure 2.9

Kaizen types

Kaizen Events, Projects and Daily Improvement

The duration of kaizen activity ranges from a few minutes to several
months. The degree of rigor and formality varies with the nature of the
undertaking. Kaizen events are focused short-term improvement efforts
that usually involve a cross-functional team and last from three to five
days. Although the Kaizen event lasts just a few days, preparation can take
place over several months prior to the activity.
Some Lean efforts require more time to plan and execute; these kaizen
projects last from several weeks to up to three months. To maintain focus
and deliver improvements as quickly as possible, we recommend that no
kaizen activity last longer than 90 days. If the scope is larger than that,
decompose the project into smaller phases (see Lean Project Management
in Chapter 9).
For Lean to become a part of daily culture, every individual should be
inspired to drive improvement on a daily basis. Daily kaizen (a form of
process kaizen also known as a kaizen blitz) is spontaneous improvement performed as a need is identified. For example, when a problem is
encountered, an individual or small group stops working to identify the
problem, analyze it, develop potential countermeasures, select the most
promising solution, make the improvement, and assess the impact. In a
Lean enterprise, the highest proportion of problem solving occurs at the
daily kaizen level.

Kaikaku
Organizations also take on strategic breakthrough initiatives. Kaikaku,
typically initiated by senior leadership, is system kaizen focused on
achieving radical improvement, as contrasted with kaizen which is gradual and continuous. Kaikaku is strategically focused and represents a leap
forward, not incremental change. Wisdom and experience suggest an
organization should undertake only a few kaikaku projects at one time.
Standardized Work
Standardized work defines and documents the most effective method
to accomplish a task. There are usually a variety of ways to perform the
same work, depending on who is doing it. Variation in work practices creates variation in time, quality, and cost. First a team establishes a current
standard to which they all agree to adhere. As work improvements are
developed, tested, approved, and implemented (PDCA), they become the
newest version of standardized work.* As variation and waste are reduced,
process quality and stability are enhanced, and cost reduction is often a
natural by-product.
Rather than being dictated by management, standard work is established and owned by the people performing the work, converting tribal
knowledge known only by a few to a documented method consistently
performed by all. Shared understanding of how work is done also supports rapid learning, skills transfer, cross-training, and load balancing.
Standard work also applies to managers, supervisors, and team
leaders. Using a Lean management system, leaders combine standard
work, visual controls, gemba walks, daily accountability, and discipline to support their people and generate measurable results. Gemba
is Japanese for “real or actual place” and highlights the need to leave
the comfort of your office or cubicle and go where the internal or external customer is using the product or service to witness what is really
occurring and verify your understanding. There is no substitute for
personal observation.
For some people, the word standard implies rigidity and inflexibility—
barriers to innovation. But in fact, the process stability created by standard
* For a comprehensive study, see David Mann, Creating a Lean culture: Tools to sustain Lean conversions (New York: Productivity Press, 2005).

work encourages innovation. Why? It is virtually impossible to improve
a process that is unstable or not consistently performed. As work procedures are standardized, employees experience stable work processes upon
which they can build.
5S and the Visual Workplace
5S is a workplace organization method. Roughly translated to English
from Japanese, 5S stands for “Sort, Set in Order, Shine, Standardize, and
Sustain.”* 5S provides a systematic approach for cleaning up, organizing,
and maintaining an orderly workplace. Disorganized work environments
encourage wasteful business practices and hide underlying problems.
They also create mental clutter and chaos. Companies often begin their
Lean journey with 5S, not only to establish a foundation of order, but also
to raise awareness of business processes, sources of waste, and opportunities for improvement (see the Con-way Virtual 5S case study).
5S also lays the groundwork for the visual workplace,† eliminating visual
and mental noise—creating an environment where the status of work is
so self-apparent that emerging problems call attention to themselves. By
actively displaying the information that needs to be shared, the visual
workplace provides people with the information they need to know without having to ask for it. A great deal of time is wasted on interruptions to
answer questions such as “What is the status of …?” Most status inquiries
are no longer necessary in a visual workplace, since the answers to such
queries are constantly displayed, updated, and accessible to all.

Let’s Get Started!
We have established our foundation, discussing the central principles and
tools of Lean. In the next chapter, we build on these ideas by describing Lean
IT and its importance in creating and sustaining a Lean transformation.
* See Thomas Fabrizio and Don Tapping, 5S for the office (New York: Productivity Press, 2006).
† See Gwendolyn Galsworth, Visual workplace, visual thinking (Portland, OR: Visual-Lean
Enterprise Press, 2005); and Hiroyuki Hirano, 5 Pillars of the Visual Workplace (New York:
Productivity Press, 1995).


Endnotes

1. Eliyahu Goldratt, The Goal, (Great Barrington: North River Press, 1984).
2. James P. Womack, Daniel T. Jones, and Daniel Roos, The machine that changed the
world (New York: HarperCollins, 1990).
3. Michael Hammer and James Champy, Reengineering the corporation (New York:
HarperCollins, 2003).
4. James P. Womack and Daniel T. Jones, Lean thinking (New York: Free Press, 1996),
16–26.
5. The Shingo Prize for Operational Excellence: Model-application guidelines, 3rd ed.
(Logan: Utah State University, Jon M. Huntsman School of Business), 3.
6. Stephen Covey, Principle-centered leadership (New York: Simon & Schuster, 1992).
7. Peter Senge, The fifth discipline, rev. ed. (New York: Random House, 2006).
8. Steven Spear and H. Kent Bowen, Decoding the DNA of the Toyota Production System
(Boston: Harvard Business Press, 2007).
9. Jeffrey K. Liker, The Toyota way (New York: McGraw-Hill, 2004), 108.
10. Lou V. Gerstner, Who says elephants can’t dance? (New York: HarperBusiness, 2002),
182.
11. Diagram supplied by The Shingo Prize for Operational Excellence (Logan: Utah State
University, Jon M. Huntsman School of Business, 2009).

3
The Lean IT and Business Partnership

Chapter Objectives
Having established the fundamentals of Lean, we turn our focus to information and information systems as an often untapped source of value. We will:
•
•
•
•

Explore why IT has traditionally been overlooked in Lean initiatives.
Search for IT’s “burning platform” for change.
Consider information wastes and their consequences.
Explore how Lean tools apply to information and information systems.

The most important, and indeed the truly unique contribution of management in the 20th century was the fifty-fold increase in the productivity of
the manual worker in manufacturing. The most important contribution
management needs to make in the 21st century is similarly to increase the
productivity of knowledge work and knowledge workers.
—Peter Drucker

We can all agree that quality information is an essential business asset that
guides behavior and supports good decisions.
Every business process relies on quality information and effective information systems, whether manual or electronic, as the flow of information supports the flow of work and the creation of value. And most organizations in
this modern age have no choice but to rely heavily on electronic information
systems due to the volume, complexity, or global reach of their activities.
45

Many IT organizations have gone beyond traditional business process
improvement, investing in self-service applications, enabling their customers to help themselves, and improving speed, quality, and customer
satisfaction, all while reducing operating costs.
And beyond the improvement of processes, some organizations are learning to differentiate themselves through innovative information value incorporated within, or delivered through, their products and services. For example:
• In 2008, 70 percent of BMW’s production was made to customer
order, and each one of those customers was invited to watch their
car’s assembly on the factory floor through an interactive website,
creating an exciting customer experience even before they climbed
into the driver’s seat.
• GE Healthcare provides abundant information on their advanced
medical products (MRI, radiography, molecular imaging, etc.) helping health care providers use these sophisticated devices more effectively to improve the health and quality of life for their patients.
• Years ago Amazon.com redefined the role of a bookseller, and now they
(along with Barnes & Noble, Apple, Microsoft, and many others) hope
their electronic books and tablet PCs will redefine the traditional book.
• Many providers now offer outsourced information-oriented services,
from accounting to medical chart review and IT services, around
the globe.
The possibilities seem endless, with new innovations appearing daily.
Skillful and innovative application of information and information systems can add value—speed, quality, cost, differentiation, customer intimacy, and more—to the enterprise and its customers.

Why Hasn’t IT Been a Focus of Lean?
Despite its clear importance, however, IT* has received little attention from the Lean community. In our opinion, the IT organizations’
* The term “IT” is used broadly throughout this book, but it can mean many things: information,
information systems, the IT organization, the tangible, intangible and intellectual assets, policies
and procedures related to information and information systems management

The Lean IT and Business Partnership • 47
historical disengagement from Lean efforts is one of the root causes
behind the failure of many enterprises to achieve a sustainable Lean
transformation.
In fact, IT associates often have a better understanding of the company’s
processes and current limitations than the users, because it’s their job to
grapple with the intricacies of maintaining and supporting the underlying systems. But their ability to improve the system may be constrained by
countless factors.
While preparing for a Lean IT workshop for a large global enterprise, we
were presented with a list of questions the participants asked us to address,
asking “How can IT …
• Work in partnership with the business on improving process and
system effectiveness?
• Drive faster and more dramatic improvement and innovation for
the business?
• Improve its ability to deliver projects on time, within budget, with
desired results?
• Place creativity before capital, process improvement before system investment?
• Help simplify IT operations and improve time, quality, and cost of
our services to the business?
• Become more engaged to seek out and solve root causes of problems?
• Achieve greater employee engagement and satisfaction through
Lean thinking?”

This list, their voice of the customer, was on their collective minds that
week, and nicely frames the essential value proposition we will explore
throughout this book. Clearly, if Lean IT can address these issues, it will
be a tremendous catalyst for positive change, overcoming inertia and
resistance that has prevented many organizations from advancing further
in their journey of continuous improvement.
But as we all know, such breakthrough change is often disruptive,
threatening, and uncomfortable. Most individuals and organizations need
a compelling reason to change, a burning platform from which they have
no choice but to jump.


What Is IT’s Burning Platform
for Transformation?
We once heard that managing an IT organization is like juggling alligators
and chain saws—this may not be far from the truth. Business requirements are constantly changing. End users are often unable to articulate
exactly what they need, yet they often seem insistent about what they don’t
want … once they see it.
Software, hardware, and Internet technologies are constantly changing,
becoming more complex, and the interdependencies among multiple systems make the change, upgrade, or replacement of any single component a
risky proposition. The cost of complexity is not linear but exponential, and
it eventually comes to dominate all other costs in most software systems.1
Combine this complexity and volatility with resource and capacity management challenges, conflicting priorities, and frequent interruptions, and IT
leadership has more than a few alligators and chainsaws to contend with.
The number of distinct business software applications used in a midsized company can easily measure more than 100, and in a large global
enterprise, thousands of applications may be in play, causing tremendous integration and software life cycle management challenges.
Changes to this loosely woven fabric of software and data are especially risky and potentially disruptive to the business when they impact
enterprise-wide, mission-critical systems like enterprise resource planning (ERP), supply chain management (SCM), or customer relationship management (CRM).
The Standish Group has been conducting surveys on IT projects since
1994. Their annual CHAOS Report reveals that roughly 20 percent of
IT projects fail,* 50 percent of projects are challenged, and only 30 percent succeed. Over the years, the survey results have improved slightly
(Figure 3.1), which is somewhat encouraging. Nevertheless, if any other
department within an organization consistently produced similar results,
the managers would be updating their résumés.
* The Standish Group defines success as on time, on budget, and meeting the specifications. There is
some debate whether these are useful and measurable guidelines—for example, a cancelled project
may be an indication of good governance rather than faulty project management, and a successful
project may not add value if the specifications don’t properly address customer requirements or
business problems at the root cause.

100%

Succeeded

90%
80%
70%
60%
50%

Failed

40%
30%

Challenged

20%
10%
0%
1994

1996

1998

2000

2002

2004

Figure 3.1

Standish Group CHAOS 20-Year Trend.2

But IT is not like other departments; managing this degree of complexity, volatility, and risk requires a balance of professionalism, technical know-how, artful prioritization, and a little magic. And through it
all the business must keep running, so the IT staff is charged with maintaining order, stability, and performance, while steadfastly preventing
unplanned downtime.
Lean versus Traditional IT: A Natural Tension?
Perhaps there is a conflict arising from the very nature of traditional IT
and Lean practices, as suggested by the table in Figure 3.2.
As you can see from this comparison, traditional IT organizational
practices typically move slowly and carefully to avoid instability and business disruption, while Lean encourages every individual to notice and fix
problems by making small improvements each and every day. This difference creates a tension that permeates the daily activities and interactions among business and IT associates. We are not suggesting these are
irreconcilable differences leading to constant conflict and confrontation,
though that seems to happen within some organizations. We are simply
calling attention to natural tendencies that, left unaddressed, may create
friction, causing the IT organization to disengage or even resist the ongoing improvement of business processes.


Change Management
Organization
Measures

Knowledge Management
Education
Definition of Success

Lean
Organic, incremental, and
continuous
Cross-functional teams
Top-down and bottom-up
performance measures
linking improvement
initiatives to strategic goals
Generalization
Process focus
Speed and Agility

Traditional IT
Engineered and planned
large events
Central command and
control
Cost containment and
uptime

Specialization
Task focus
Stability

Figure 3.2

Contrasting attributes of Lean IT and traditional IT.3

Legacy Systems
A common example of ineffective IT and business coordination is the
existence of a significant legacy information system—homegrown or
extensively modified software that remains in place long past its useful life
cycle. A legacy system may persist for a number of reasons, among them:
unique or unusual business processes are dependent upon it, it may rely
on obsolete or obscure technology, those who designed and built it have
long since left the company, and the system has been patched repeatedly
but the changes are poorly documented. As a result, most IT associates are
reluctant to tinker with a legacy system unless it’s absolutely necessary.
Legacy systems are like organizational scar tissue—they form around
injuries in the business processes, building layer upon layer of hardened
procedures, and limiting flexibility of the process while causing pain.
And each time business requirements change, a new layer of reactive
changes and patches are added. Over the years the legacy system becomes
increasingly fragile, the user workarounds more contrived, and the business processes more ineffective and resistant to change. This degenerative process causes the accumulation of technical debt, a liability that
extracts daily payments in the form of waste and inefficiency, until the
debt is liquidated.
For example, one client was replacing a 20-year-old legacy system that
had been extensively customized to fit their unique requirements, like
a well-fitting but worn-out old glove. Over the years the 100-year-old

company had devised elaborate pricing agreements with many customers.
Some of these agreements predated the legacy system and were very difficult for both the company and its customers to administer.
There is no doubt that renegotiating these pricing agreements would
have been difficult. On the other hand, the impending system replacement provided a golden opportunity to revisit the customer relationships, and re-assess their value proposition, standardizing delivery
services and pricing structures. Instead, the executives decided to transfer the existing agreements to their new ERP system. This created millions of distinct pricing records in the database. The added complexity
caused countless errors and exceptions, while requiring two full-time
employees to maintain the system and chase the problems. No value
was added here.
Removing layers of systemic scar tissue can be uncomfortable, requiring
discipline and effort, so it is often neglected. As a result, entangled systems,
inflexible users, and overly complex designs can smother an improvement
effort. In such cases, members of the IT organization may feel like they
are the scapegoat for deeply rooted problems within the overall enterprise
that are beyond their control.
What about Process Maturity Models?
IT professionals are naturally process-oriented, structured thinkers. So
it’s no surprise that over the years they have participated in the development of an alphabet soup of process maturity models to guide the evolution
of the process-oriented enterprise. Popular models include CMM, ISO,
ITIL, and SCOR.*
However popular these models may be, often they are not effectively
implemented or sustained. For example, over the past two decades or more,
ISO 9000 resulted in many compliance-driven implementations that didn’t
improve the fundamental behavior or performance of the organization.†
* Acronym alert! CMM: Capability Maturity Model; ISO 9000, 14000, 22000, 27000 and others: International Standards Organization standards for quality management systems; ITIL:
Information Technology Infrastructure Library; and SCOR: Supply Chain Operations Reference
Model.
† The same can be said for many other compliance-driven improvements across many industries,
including the Sarbanes-Oxley Act for publicly traded companies, The Joint Commission (JCAHO)
for health care, the U.S. Food and Drug Administration (FDA) Good Manufacturing Practices,
and so on.

These process models provide general frameworks for industry best
practices (or at least acceptable practices), describing the target state of key
processes. In other words, these process models usually describe the what
but not the how. This approach is typically a top-down process, where leadership selects a model, an implementation methodology, and perhaps an
outside consulting firm to drive the implementation.
This authoritative approach can be rapid but may result in superficial
adoption of new practices, while lacking employee buy-in and the subtle nuances that accommodate the company’s culture. This in turn may
lead to resistance, and the inability to sustain the improvements without
constant management oversight and arm twisting. Under these circumstances, compliance often appears, and only temporarily, soon before the
auditors are scheduled to arrive
By contrast, consider a bottom-up approach, where cross-functional teams
identify and solve problems and improve processes as a natural evolution. Each incremental step is defined according to the teams’ perspectives
and priorities. While this results in individuals and teams driving process
improvement and innovation through hands-on problem solving, it may also
create a slow and somewhat random approach to achieving strategic goals of
the enterprise.
The ideal approach to using a process model may be found as a hybrid
of top-down and bottom-up. Teams apply A3 thinking, solving problems
according to the specific circumstances and culture of the organization,
while the general future-state direction is guided by strategic input from
leadership, supported (in some situations) by a mature process model or
framework, such as ITIL (see Chapter 7). In this way, the organization
leverages industry practices to envision and target a desired future state.
In doing so, the organization can adopt best practices for supporting processes (see Chapter 4), focusing its creative energy on innovative practices
that will provide distinction and competitive advantage.

What Is Information Waste?
Data is of course important, but I put greater emphasis on facts.
—Taiichi Ohno, Toyota

The many benefits of electronic information systems are often offset by
the waste they generate. Too many times we have witnessed Lean teams
attempt to improve a process, but the moment they return to their keyboards, they’re forced to act out the same old familiar and wasteful practices in their daily work. Information waste produces many harmful
consequences, including lost productivity, costly delays and errors, and
unnecessary complexity. Often manifesting as confusion and frustration,
information waste is felt by everyone who interacts with the organization.
Excess Information Inventory Waste
In an office or manufacturing context, excess inventory is a highly visible
symptom, a beacon to illuminate the search for root causes of wasteful
activity. From a Lean IT perspective, what is excess information inventory? It is too much virtual stuff … in your inbox, your local hard drive,
shared drives, intranet sites, and data warehouses. Excess information
inventory is work backlog waiting to be done, unnecessary e-mails in
your inbox, unused features in software applications, local spreadsheets
impeding the flow of work as a process skips across departmental boundaries, and so on. Excess information inventory causes congestion, delays,
inefficiency, errors, and rework. Everyone in the enterprise struggles
against info-glut.
Most people naturally hoard inventory; it’s a primal instinct that goes
back to our hunting-and-gathering days. Having too much stuff buffers
you from variability, since you always have enough even when your supply runs out for a while. For this reason, excess information inventory is
important to seek out because it indicates that the process itself, the flow of
work that the information supports, is unreliable. More information (e.g.,
additional data, better software, and more automation) alone is unlikely
to fix the problem.
Just like excess physical inventory is stored in warehouses, excess data
and documents are stored in data warehouses and repositories throughout
the organization. The effort required to capture, store, search, and manage these data just in case they might be needed is wasteful, even if storage space is abundant and inexpensive. This waste is compounded by data
fragmentation, version control challenges, excessive security controls, and
other flow inhibitors caused by excess information inventory.

Information Overprocessing Waste
Another form of information waste is overprocessing, of doing more work
than necessary. A common form of overprocessing is the overdesign of a
software application, creating unnecessary navigation, keystrokes, and
other forms of complexity. Less than half of software features are typically
used, but once implemented, they must all be maintained and supported.
This non-value-added effort creates a burden for users and IT staff alike.
Unnecessary transactions are another common form of information
overprocessing, including unnecessary approval steps, and excessive data
capture to feed calculations and reports that don’t support efficient workflow or effective decision making.
Multitasking is a pandemic form of overprocessing waste in the business
world. At one time we all considered multitasking a virtue to be cultivated,
but now we realize that constant interruptions and task switching are unproductive. In the Harvard Business Review article “Manage Your Energy, Not
Your Time,” Tony Schwartz and Catherine McCarthy suggest that,
Distractions are costly: a temporary shift in attention from one task to
another—stopping to answer an e-mail or take a phone call, for instance—
increases the amount of time necessary to finish the primary task by as
much as 25 percent, a phenomenon known as “switching time.” It’s far
more efficient to fully focus for 90 to 120 minutes, take a true break, and
then fully focus on the next activity.4

Most people require about 15 minutes to productively resume a challenging task when they are interrupted even by something as innocuous
as an e-mail alert, scientists at Microsoft Research and the University of
Illinois found in a 2007 study.5 While 15 minutes may not seem like much
time, if interruptions occur several times a day, this can add up to serious
performance degradation … or worse.
Interruptions seem to be a fact of life, but they are costly in terms of
time, concentration, and quality. Awareness of this fact can, over time,
lead to changing work patterns and communication practices, and setting
aside uninterrupted time and space to tackle difficult tasks. In our experience, especially in the office environment, many interruptions are for
simple status inquiries such as “Where is this?” “When will that be done?”
and “What do you need from me now?” The effective use of simple visuals to communicate status and priority of work can significantly reduce

interruptions, improving the quality and efficiency of work while creating
a more enjoyable workplace.
Poor Data Quality Waste
Yet another type of information waste is poor data quality. Often a sleeping giant within the databases and spreadsheets spanning the enterprise,
poor data quality is both a cause and a consequence of poor process design
and operational execution.
The Lean principle of quality at the source means that data quality is
everyone’s responsibility. Ideally, data should be captured once at the
source, with the appropriate time and effort invested in getting them
right the first time. Ultimately, the process owners (not the IT organization) should take responsibility for data quality, establishing standard
work and error-proofing methods, accompanied by supportive measurements. High-volume transactional processes with data quality problems
are often well suited for the rigorous analytical techniques emphasized
by Six Sigma (see the Ingersoll Rand Case Study).
As you can see from this brief exploration, there are many forms of
information waste—see Figure 3.3, and for a more comprehensive listing
see Appendix C. More importantly, once individuals and teams begin to
understand the many forms that information waste can take, how do they
methodically identify, quantify, prioritize, and eliminate it?

Learning to See Information Waste
To learn to see waste you must first understand clearly the degree to which
a process creates value from the customer’s perspective. Any Lean journey
must begin with this simple question: “What does the customer define as
value?” So from the IT organization’s perspective, who is the customer?
In our experience, kaizen teams are often surprised at how many customers they have and how little they understand what each really values. Every step of every process has at least one customer—the recipient
of the work flow, the next downstream step. In most business processes,
activities are primarily performed by internal resources, serving downstream internal customers. This is the case with internal functions such


Health Care Information Quality
Perhaps no industry suffers greater information fragmentation than
health care. One registered nurse described 33 separate forms she
completed by hand each time she admitted a patient into home
care services. Each form contained overlapping information such
as patient name, address, medical condition, and so on. Not only
does this waste scarce nursing time (an hour to complete the forms
while visiting the patient in the home), but also consider the implications of 33 distinct information systems that interface with this
single process of admitting a new patient. And the chances are high
that at least some data will be captured incorrectly into at least one
of these systems, causing not only redundancy but also incorrect and
conflicting information. This not only causes many forms of downstream waste, but also in some cases may endanger the health of the
patient.
The solution to such fragmentation? Electronic Medical Records
(EMR) may help, but they’re not enough—and if improperly implemented experience and research* have shown they may even make
matters worse. From a clinical perspective, integrated medical teams
are learning to facilitate shared assessment findings, resulting in
improved overall care for the patient and family. From a process
perspective, interdisciplinary systems thinking, enabled by A3 problem solving and value stream mapping, have become popular within
health care organizations in both business and clinical settings.
Cross-functional teams of physicians, nurses, administrators, and
other stakeholders come together to identify and solve problems,
with a focus on value to the customer: time, cost, patient health and
safety. Over time, as processes are simplified, redundant applications can also be simplified, normalized, integrated … and eventually eliminated.
* Electronic Medical Records, Nurse Staffing, and Nurse-Sensitive Patient Outcomes:
Evidence from California Hospitals, 1998–2007, Michael F. Furukawa, T. S. Raghu, and
Benjamin B. M. Shao, Health Research and Educational Trust.

Moving materials from one location Physical or virtual transportation of Handoff of information across organito another
documents
zation boundaries and multiple systems,
security barriers to information flow

Doing more work than the customer Producing reports that nobody reads, Redundant data, unnecessary transacwants (e.g., unnecessary product overuse of the email “reply all” button, tions, unused reports, software features
features)
expediting
that users don’t need

Bending, lifting, twisting, walking, Walking, copying, filing, searching for Searching for information, reentering
packing/unpacking, searching for materials and information
data, excessive keystrokes, frequently
stuff
shifting priorities

Defects that require correction or Work passed on that is incomplete, Incorrect, untimely, and confusing
cause scrap
incorrect, or requires clarification
information that causes bad decisions

Transportation

Over processing

Motion

Defects

Comparing waste in manufacturing, office, and IT.

Figure 3.3

Waiting for materials from the Waiting for unnecessary signature or System downtime, unnecessary workupstream workcenter
approval or monthly closing processes, flow steps
time wasted in unproductive meetings

Delays

IT

Producing more or sooner than the Producing documents before they are Excessive email, reports, system alerts,
customer needs
needed, doing a large batch of paper- etc., that are not read or acted upon
work that the downstream worker can’t
handle all at once

Office

Overproduction

Manufacturing

Excess raw material, work in pro- Work accumulating in physical and Excessive information causing searchcess, and finished goods
virtual inboxes, excess physical files
ing and version control problems, excessive backlog and work in progress

Inventory

Waste


Value Stream: Sales to Cash
Who is the
Internal or
Customer?
External?
Finance
Internal
department

How well do we
understand them?
High

Product
development
team

Internal

Low

Top ten
customers by
sales $

External

Medium

What information do they
value?
Accurate data, available to
support timely financial
close
Not sure, something to do
with accurate sales history;
action item: schedule
department stakeholder
interviews
Accurate invoicing, prompt
response to questions, what
else would differentiate us?
Action item: interview sales
and marketing, consider
focus group

Figure 3.4

Simple voice-of-customer exercise.

as Human Resources, the IT Service Desk (help desk), or the employee
cafeteria, processes that rarely touch the ultimate end customer of the
business.
External processes, such as the customer order processing–to–billing cycle, involve external customers when they request a quote or
submit an order, and again when they receive an invoice as the final
process output. But most of the work in between is still performed by
internal resources serving their internal customers. Any of these steps
that do not add value to the external customer (and are not mandatory for compliance) should be targeted for elimination, rather than
improvement.
Since the focus of Lean is adding value to the customer (internal and
external), improvement activity should include a voice-of-customer (VOC)
exercise focusing the team on who the customers are and what they value.
Figure 3.4 shows a simple VOC brainstorming exercise format focusing on
information value.
Once a team understands what the customer values, it has a basis for
assessing the severity of the waste it discovers, evaluating its impact
on the value stream, and prioritizing its elimination. To eliminate a
particular wasteful activity, the team then determines the underlying

causes, conditions, assumptions, and habitual behaviors that perpetuate it. Lean offers many tools and techniques to get to the root cause—
brainstorming, cause-and-effect diagrams and the perennial favorite:
the five whys—where after someone suggests the cause of a problem,
keep asking, “Why?” This persistent inquiry usually leads to some interesting places, as you probe for underlying causes to explain why things
really happen the way they do. This technique is explored in Chapter 9.
During a kaizen event aimed at identifying and aligning IT value
streams,* Con-way Enterprise Services developed the cause and effect
(fishbone) diagram shown in Figure 3.5. While this diagram illustrates
the underlying complexity of information waste, this is just the beginning—for each contributing factor identified on this diagram, another
“Why?” awaits.
Value stream mapping is an essential tool for identifying and measuring
the impact of information waste on process outcomes. According to Mike
Rother and John Shook, who introduced value stream mapping, “Material
and information flow are two sides of the same coin. You must map both
of them.”6
In a value stream map, work and supporting information flows are
illustrated and quantified, so sources of waste may be prioritized and
targeted for elimination based on their impact to overall process performance. Quantification of the impact of waste (time, quality, and
cost) in the current-state map, compared to the intended outcome in the
future-state map, provides measurement-based justification for change
and investment proposals.
It is not uncommon, particularly in an office environment, for there to be
more information boxes than process boxes on a value stream map (shown
in Figure 3.6). Information proliferation and fragmentation (disintegration) across the enterprise are common causes of waste, and inhibitors to
workflow. With spreadsheets on every desktop and data repositories in
every department, fractured and incorrect data slip between the cracks
as the process is handed off from one siloed workgroup to the next. Data
fragmentation and process misalignment lead to overprocessing, delays,
process rigidity, errors, rework, worker frustration, and ultimately customer dissatisfaction.
* See the Con-way Focused Value Streams case study.

One client’s view: Cause-and-effect diagram of information waste.7

Figure 3.5

Tools easy to use & ubiquitous

Emergence of cloud computing
and Software As A Service

End User Tools are
More Proliﬁc

Business users often distrust IT dept

Info Technology Deployed
in Functional Silos

IT charge-backs drive silo behaviors

Lack of a process orientation
within a company

Improvements funded departmentally
and not by value stream

Lack of business governance & controls

Disruptive technologies

Accelerated technology
upgrade or introduction
cycles

IT budget cuts, IT seen as
cost not enabler

Information explosion

Lack of business
governance & controls

Demand Exceeds Supply
for IT Groups

Less IT resources to manage
more technology & complexity

Increasing Complexity of
Information Systems

More layers of technology
used in business, each
requires funding,
planning & management


Conﬂicting priorities let legacy systems live

Ubiquity/accessibility of end-user tools

Poor data quality in other systems/sources

Legacy systems not being replaced

Accelerated business/change cycles


Proliferation of
IT Systems

Waste Surrounding
Information &
Related Technologies



Email

Spreadsheet on
Shared Drive

Approve PurchOrd
Finance Mgr

Approve
PurchOrd into
ERP

Enter PurchOrd
into ERP

Process Time = 10 m
Lead Time = 1 d

ERP System

IN

Quality = 95%

Process Time = 10 m
Lead Time = 4 h
Quality = 90%

IN

Process Time = 5 m
Lead Time = 1 d
Quality = 90%

Figure 3.6

Information and process boxes in a value stream map.

Lean and Green IT
In this age of global environmental consequences, it’s important to emphasize the role that the IT organization can play in reducing environmental
waste. Lean IT and Green IT are certainly complementary; in fact, many
environmental benefits are realized simply as by-products of ongoing Lean
IT improvement efforts.
When concentrating on green improvements, the issue that most
IT associates consider first is the environmental waste caused by IT
operations:

1. Data center energy efficiency *
2. End user computing energy efficiency
3. Toner and paper consumption
4. Ethical handling of electronic waste†

Additional environmental waste reduction opportunities can often be
found in business operations improvement, which can be enabled or
enhanced by use of technology. In fact, the U.S. Environmental Protection
Agency (www.epa.gov/lean/toolkit) promotes kaizen activity and value
* EPA reports data centers consumed 1.5 percent of total US energy consumption in 2006, this
demand is expected to grow by 12 percent each year.
† This list was provided by the Nike, Inc. IT sustainability team.

stream mapping to focus attention and action on energy and environmental impact.
Significant environmental improvements are often achieved by evaluating the overall flow of materials and transportation from source to customer. For example, United Parcel Service’s (UPS) investment in package
flow software improved the performance of their fleet of 95,000 trucks
(including the amount of time they spend idling in left-hand-turn lanes),
and UPS reported an annual reduction of 28.5 million miles from their
delivery routes, saving 3 million gallons of gas and reducing CO2 emissions by 31,000 metric tons.8
Then there is the ability of information systems to provide feedback
on the effectiveness of environmental sustainability initiatives throughout the enterprise. This includes not only reporting on direct environmental improvement initiatives, but also accumulating data from
process improvements where environmental benefits are a by-product;*
this requires a reporting system that can reach into a variety of internal and external data sources (such as internal ERP systems, external
supply chain systems, and regulatory agency websites), sifting through
large volumes of data, and building aggregated views and reports of
cost reductions and environmental outcomes that are used as feedback
to guide ongoing activities.†
Such a reporting system would offer the additional benefit of automating much of the data collection and reporting overhead that will likely
be required by various regulatory agencies for cap-and-trade and other
environmental programs. And the existence of such a reporting system,
to measure and provide direct feedback on a company’s carbon footprint
and other environmental consequences, would add value to support the
company’s fact-based decision making on environmental issues (see Green
Intentions by Brett Wills).9
Lean IT is in a strong position to support green initiatives as companies
extend their focus to the triple bottom line: people, planet, and profits.
* One client, during a kaizen to improve a customer billing and collection process, discovered
they could avoid printing and archiving billing documents. This eliminated the printing of
over 100,000 pages per year, plus the storage space (plus the electricity for heating and lighting)
required to archive these documents for several years.
† We expect this opportunity will create a growing market for software developers; two early market
pioneers in integrated sustainability dashboards are Microsoft (www.microsoft.com/dynamics/
environment.mspx) and Future State Solutions (www.futurestatesolutions.com/sustainability.
aspx). See also www.iisd.org/cgsdi/dashboard.asp.

While not a central theme of this book, we encourage the reader to explore
all potential direct and indirect benefits to the environment that may
result from Lean waste reduction, both within IT operations and through
technology-enabled business process improvement.

The Tools of Lean IT
In Chapter 2, we explored the basic tools of Lean; now we’ll revisit several
of these tools, highlighting their relevance to Lean IT. We will continue to
explore these tools in various IT contexts throughout this book:
• A3 thinking: While IT professionals are natural system thinkers and
problem solvers, they are usually under intense time and budget pressure. As a result, they often jump to quick workaround solutions that
do not address root causes, creating a technical debt: a continuing
liability of inefficiency and frustration. Lean offers tools that help IT
and businesspeople slow down and take the time to assess a situation
properly. In the realm of Six Sigma, problem solving often includes
rigorous collection and analysis of data.
• Go look, go see (genchi genbutsu, go to gemba): People should make
decisions by fact, not by feeling, so every team must go to gemba
(where the work is performed) to see the situation for themselves.
Gemba can be a physical place, or a virtual space such as a business
intelligence system that represents the inputs and outputs of a transactional process. Ultimately, though, gemba means the people and the
place where the work is done, not the data that represent this work.
• Teamwork: In order to align business and IT activities and investments, they must work together as partners—solving problems and
simplifying processes first, then carefully applying information systems as appropriate (people, process, and technology—in that order).
• Value stream mapping: As we explored earlier in this chapter, value
stream mapping can help to identify and quantify information waste
within every value stream and supporting process.
• Standardized work: Work standards are developed, documented,
and continuously improved by the team members, providing input
for software requirements, documentation, training, testing, and


•

•
•

•

•

•

support. Knowledge management tools serve to standardize, disseminate, and manage standard work instructions across the enterprise.
The work of the IT organization itself should also be standardized to
encourage quality and consistency, avoiding pockets of specialized
knowledge that create a dependency on specific individuals.
Measurement: The keys to a sustainable Lean transformation are
standardized work, accompanied by good measures that provide
feedback to ensure the continuing effectiveness of currently defined
processes, and to identify new opportunities for improvement.
Reporting and analyses are derived from data generated by the organization’s manual and electronic information systems, so IT associates are often called on to assist with the design of measurement
systems.
Workplace organization (5S): Sort, Straighten, Shine, Standardize,
and Sustain your IT assets: storage, hardware, software, licenses,
workspaces, processes, data, knowledge, and intellectual property.
Visual workplace: Make IT process and project flow and status visible to everyone, calling attention to impending problems and avoiding status inquiry interruptions. Visual process measures and alerts
are often automated, providing proactive notification of exceptions
to identify problems and initiate immediate corrective and preventative action.
Cellular organization: People and equipment supporting all or part
of a process are co-located (either physically or virtually using online
tools) to encourage smooth workflow, collaborative problem solving,
knowledge sharing, and continuous improvement.
Demand management: IT organizations commonly have backlogs that are years long, and are often lacking clear prioritization
or decision-making processes. Chaotic demand (mura)—variation
from sudden spikes, frequent interruptions, and priority changes—
contributes to overburden (mura), which leads to wasteful activity
(muda). By working with the business to manage priorities and create level demand, matching it to available capacity to create a steady
pace of work (flow), an IT organization can become more responsive,
giving customers exactly what they want, when they want it.
Strategy deployment (also known as hoshin kanri): Articulate strategy and align daily work through all levels and dimensions of the
organization, ensuring that process improvement and supporting

information systems deliver meaningful and measurable results.
Skillful application of information systems can aid in the deployment of an effective strategy deployment system (see the Toyota electronic hoshin kanri case study).

How Do We Do Lean IT?
Lean IT enables a manageable, synchronized pace for business process change
throughout the organization, focused on delivering value to the customer.
Lean IT is accomplished through people, process, and technology—in
that order. People (working in cross-functional teams) identify the problems and their root causes, which are often found in the process itself and
not the technology. When the process is improved (and often simplified),
the people may find that the supporting systems can also be streamlined
or removed altogether. And when system changes are required to support the process improvement, the future state of the process (defined by
the team) helps to articulate system requirements, while the team guides
their design, selection, development, implementation, maintenance, and
support.
Lean IT thus encourages team-driven, iterative, small, and rapid changes
to business processes and the supporting information systems. IT and
business associates work together, orchestrating change and rigorously
applying A3 thinking to every situation.
Throughout the rest of this book, we will systematically explore the many
aspects of Lean IT. We will focus inward, exploring how Lean techniques
can help improve IT operational excellence. And we will focus outward,
exploring how the IT organization can integrate, align, and synchronize
with the business, supporting (and playing a leadership role in) process
improvement and innovation. Then in the final chapters we will bring it
all together, providing leadership guidance and a Lean IT transformation
roadmap, showing the way to a sustainable enterprise transformation.


Endnotes

1. Mary Poppendieck and Tom Poppendieck, Implementing Lean software development:
From concept to cash (Reading, MA:, Addison-Wesley, 2007), 69.
2. Deborah Hartman, “Interview: Jim Johnson of the Standish Group,” InfoQueue,
August 25, 2006, www.infoq.com.
3. Steve Bell, Lean enterprise systems: Using IT for continuous improvement (Hoboken,
NJ: John Wiley, 2006).
4. Tony Schwartz and Catherine McCarthy, “Managing yourself: Manage your energy,
not your time,” Harvard Business Review, October 2007, 68.
5. Holly Bailey, Daniel Stone, and Jeneen Interlandi, “Will the Blackberry sink the presidency?” Time, February 16, 2009, 37–38.
6. Mike Rother and John Shook, Learning to see (Cambridge, MA: Lean Enterprise
Institute, 2003), 5.
7. Richard Carroll, interview, July 1, 2009.
8. Joel Lovell, “Left-hand-turn elimination,” New York Times, December 9, 2007, www.
nytimes.com/2007/12/09/magazine/09left-handturn.html?ref=magazine.
9. Brett Wills, Green intentions: Creating a green value stream to compete and win (Boca
Raton, FL: CRC Press, 2009).

Section II

Integration
Aligning Lean IT
and the Business

4
Lean IT and Business
Process Improvement

Chapter Objectives
In this chapter we discover how an expanded role for an IT organization
that embraces Lean can support and promote business process improvement. We will:
• Establish IT’s role as a catalyst of business process improvement,
leading the way in bridging functional silos.
• Consider the unintended complexities created by the reengineering
trend of the 1990s.
• Explore the convergence of strategic alignment, information systems, Lean thinking, and the lessons learned from enterprise-wide
system implementations.
• Examine how a Lean IT organization can deliver agility, best practices, and effective measurements throughout an organization.
• Consider the role of strategy in clarifying priorities, aligning effort,
and driving innovation.
The command–and-control organization that first emerged in the 1870s
might be compared to an organism held together by its shell. The corporation that is now emerging is being designed around a skeleton: information,
both the corporation’s new integrating system and its articulation.1
—Peter Drucker

69

The power of Lean IT includes knowing when not to use technology,
because the vast majority of problems are caused by faulty processes,
not people or technology. Unfortunately, organizations often lead with
a technology solution prior to improving processes, all but guaranteeing
the installation of new technology on bad processes. Michael Hammer, 2
a pioneer of business process reengineering, called this “paving cow
paths.” People should initially focus on root causes, creatively improving processes before considering investments in information systems.
Because existing technology can entrench bad practices, it may even be
appropriate to remove rather than add technology as a first step. Applying
creativity before capital eradicates the habitual crutch of rushing to buy
or build big bang solutions, encouraging ingenuity and resourcefulness
from within. If the team eventually discovers that a major investment in
technology is needed, a sound business case can be made based on their
assessment, lessening internal resistance to change.
At Toyota, the introduction of new technology is considered only after
processes have been fine-tuned by cross-functional teams. Technology
interventions are evaluated on their ability to support work processes
while not distracting attention from value-added activities. In The Toyota
Way, Jeffrey Liker explains the value of a team-based approach:
Once Toyota has thoroughly gone through this process, it will quickly implement the new technology. Because of this painstaking process, Toyota will
typically implement the new technology smoothly without the employee
resistance and process disruption that other companies often experience.3

People, process, and technology—in that order. Although managers
and stakeholders are not always comfortable with the patience and discipline required, applying the tools and principles of Lean IT mitigates the
risks and challenges of enterprise systems. When cross-functional teams
(including IT participants) define system requirements, they share ownership and the resulting systems are more likely to succeed.

The Coordinating Function of
Information, IT, and the Lean Office
Most organizations struggle to coordinate behavior throughout the enterprise. In the past, management directed workers, assigned specific tasks,

Lean IT and Business Process Improvement • 71
controlled activities, and checked results. As workers have become more
knowledgeable and organizations more complex, this approach has failed
to consistently deliver productive outcomes.
Today, many companies employ a blend of top-down management and
bottom-up participation to engage the workforce and address the intricacies and rapid pace of change in modern business. All organizations are
composed of core functional areas (usually structured as departments)
that work with one another to deliver a service or product to their customers. Organizational effectiveness, which often varies dramatically from
one company to the next, is determined by the degree of coordination and
alignment of its parts—the greater the coordination and alignment, the
greater the likelihood that targeted results will be achieved and sustained.
The Shingo Prize for Operational Excellence endorses a transformational
model that characterizes the enterprise as five business systems. Customer
relations, product and service development, operations, and supply all
directly create value for the customer. These four functional areas execute
business processes and provide supporting infrastructure which create
the organization’s value streams. These functional segments comprise the
components of a value stream but often function in silos. Management,
the fifth business system, though not directly creating value to the external customer, orchestrates the activities of the other four groups.
From a Lean IT perspective, we view information and information systems as encompassing this network, because information integrates and
enables all value streams and supporting processes. Figure 4.1 shows
information and information systems as a framework, a collection of
shared and integrating services bringing together the parts to make a
whole. Information systems play a critical role enabling the coordination
of activities throughout the enterprise, synergistically providing the means
by which information and knowledge are collected, processed, stored,
secured, analyzed, accessed, and shared. The IT organization serves as a
catalyst for change, an agent that enables, accelerates, and facilitates communication and coordination. Note that we describe IT as an enabler,
one that enables another to achieve a specific end. It is a misperception
to think IT “owns” information, when in fact business owners themselves
are responsible for data quality, and for determining what information is
needed to run the business.
Beyond these five basic functional groups, the typical enterprise is composed of many more dimensions: business units, divisions, regions, shared


Management

Customer
Relations

Supply

Product &
Service
Development

Operations

Information &
Information
Systems
Figure 4.1

Information’s essential supporting role in value streams.

services, as well as ad hoc teams formed for projects and improvement
initiatives. Figure 4.2 illustrates this more complex set of interrelationships supporting enterprise value streams. The degree to which functions
and shared services are synchronized directly impacts the performance of
the value streams. Management and associates, equipped with actionable
information, coordinate functions to create value which flows to the customer. Lean IT, the discipline of Lean applied to information, information
systems, and the IT organization, enables organizational performance by
improving information quality, flow, and accessibility.
Figure 4.2 can be used to illustrate the basic function of any organization, in any industry: finance, health care, hospitality, and so on. In
manufacturing supply chain organizations, information supports the flow
of work—usually in the form of physical materials. But for many service
organizations (e.g., insurance and banking) as well as some office functions within manufacturing supply chain organizations, information

Strategic
Planning

Enterprise value streams.

Figure 4.2

S
U
P
P
L
I
E
R
S

Product and
Service
Design and
Development
Sales and
Order Capture

Procure and
Build/ Service
Delivery

Shared Services: IT, Finance, HR, Legal, Compliance, Centers of Excellence

Dimensions: Geographies, Divisions, Departments, Projects, Teams

Enterprise Value Streams and Supporting Processes

Systems/
Program/
Product Mgmt
Service and
Support

P
U
L
L

C
U
S
T
O
M
E
R
S


is the work product. In any case, because information enables behavior,
there is direct bottom-line impact from improvements made to information systems when these changes reinforce appropriate behaviors.

The Intangible Nature of
Information Value and Waste
In today’s economy, profitability and market share are driven in large
part by intangible (often intellectual) assets: information. As Baruch Lev
explains in Intangibles: Management, Measurement, and Reporting,
Corporate success today is not based any more on production facilities,
financial capital and ownership, but on invisible and untouchable values—
intangible assets—such as relationships with business partners, brands,
ideas, business processes, corporate culture, know-how and innovation
force.4

The intangible nature of information presents unique challenges for
Lean, particularly in the office. Information waste is less apparent than production waste, where errors manifest as increased inventory, wrong parts
made, increased scrap, and other physical problems. In an office, information mistakes are often invisible even as they create the hidden costs of
corrections and rework. Waste is often disguised as useful, normal work.
When communication (electronic, written, or verbal) is not clear, complete, and correct (the three Cs), work and the supporting information
must flow backward to its source for clarifications, completions, and corrections. Correcting information mistakes steals precious time, robbing
attention from the work at hand and disrupting flow. In many organizations, however, people have become so accustomed to correcting mistakes
that they no longer question them or seek their root cause—plodding
through their days in quiet frustration. There is a painful truth to the old
adage, “We never have time to do it right the first time, but we always make
the time to fix the problem later.” However, the downstream consequences
of a single information defect can proliferate widely throughout the enterprise and its information systems, and often cannot entirely be identified
and corrected.

When kaizen teams perform value stream mapping, they often discover
that over 95 percent of the time, no value is added to products and services
as they move through the value stream. Information waste* is frequently
discovered to be a major cause. While some complexity is inherent to the
nature of business processes, much complexity is unnecessary and selfimposed. We believe much of the unnecessary complexity is an outcome of
the reengineering trend of the 1990s. While significant productivity gains
were achieved during this period, the relentless pursuit of hyper-efficiency
and automation in some cases introduced overdesign and over-processing.
Aggressively pursuing automation limited flexibility and ability to change.
Over time, new products, services, and their supporting systems generated a seemingly endless collection of intricately interwoven processes and
software, resulting in layers of non-value-adding activity. The psychological inertia that was created remains very strong and resistant to change.
For example, during a kaizen project to improve information flow, one
client discovered that its billing department used a seven-part invoice
which required an elaborate physical filing system. The team asked when
the invoicing system was implemented and why. They were surprised to
learn that the elaborate paper-shuffling system had been in use for 15
years to fulfill a NASA (National Aeronautics and Space Administration)
record-keeping requirement, but that NASA had not placed an order in 10
years. As this story illustrates, wasteful processes are often indistinguishable after becoming entrenched as tribal knowledge: the unexamined way
things have always been done around here.
IT Brings Systems Perspective to Business Process Improvement
Responsibility for coordinating process improvement efforts lies with process owners: those individuals accountable for process outcomes. Ideally,
process owners have the authority and ability to make necessary changes.
However, they aren’t always authorized to oversee improvements at a process level because traditional silo organization structures often fail to support matrix management, that is, management that creates a horizontal
flow of authority by drawing people from different functional disciplines
to support department-spanning processes without removing them from
their respective positions.5
* Various forms of information waste are discussed in Chapter 3 and Appendix C.

Local optimization of departmental goals rarely, if ever, lead to systemic
value stream improvements that impact end customers. For example,
reducing the error rate in an insurance claim intake process seems to be a
worthy goal, at least to those in the claims department. However, if downstream processes (damage estimates, appraisals, settlements, etc.) are not
taken into account, the impact of improving the intake process alone may
not be realized by the customer in terms of time, quality, or cost.
Although people understand that process improvements should span
functional boundaries, most organizations naturally operate in functional
silos focusing on localized objectives. Measurements are the primary reason for this shortsightedness, since they create incentives that influence
localized perspective and behavior. “Look at my numbers. My area is OK,
so it must be you!” is an indication that silo thinking is alive and well.
When measures center on departmental financial performance, efficiency,
and cost control, people shift their focus away from what counts most to
the customer: performance of the entire value stream. To sustain Lean
improvement, existing measures and incentives must be revisited with a
systems thinking perspective and a focus on customer value.
To make matters worse, process owners may not have the experience
or point of view to see information waste and assess information flows.
IT professionals, equipped with the principles and tools of Lean IT, bring
a systems perspective to problem solving, and an understanding of the
underlying information system functions and interrelationships that
are hidden from most users. IT associates can thus contribute to process
improvement by providing a systems perspective on business problems,
and participating in seemingly nontechnical improvement activities,
while informing the team of technical considerations.
A clear understanding of roles is necessary for overall value stream
improvement. By working in cross-functional teams and creating value
stream maps which reveal the entire process, all participants learn to see
how their individual functions support (or hinder) the flow of value to the
customer. The IT organization, as a shared service playing a supporting
role, sits outside the functional silos, possessing a bird’s-eye perspective
that enables it to see information flow from end to end. IT staff are therefore in a unique position to understand the interdependencies, complexities, redundancies, and inefficiencies of information flow and information
systems—understanding the weaknesses of the current state is the first
step to improving a process.

Enterprise Software Applications and
the Ghosts of Projects Past
Given the volume and intricacy of transactions in a typical office environment (consider procurement, accounting, and customer service), electronic information systems have been developed to address the effective
management of information throughout the enterprise. Common enterprise systems include enterprise resource planning (ERP), customer relationship management (CRM), and product lifecycle management (PLM).
Many industries have their own specialized core information systems,
such as healthcare information systems (HCIS), banking and insurance
transactional systems, hospitality reservation systems, and airline ticketing and scheduling systems. When successfully implemented, such largescale, integrated, enterprise-wide systems enable continuous improvement
by automating and error-proofing routine tasks, centralizing data, and
supporting the smooth and uninterrupted flow of information and work
across all dimensions of the enterprise. Such applications are the operating
system of the organization.
However, the benefits of enterprise-wide systems come at a price. Such
massive software applications are inherently complex, expensive, risky,
and resistant to change. When poorly implemented, organizations experience a frustrating drain of energy and focus from wrestling with the
system and expending precious creativity on workarounds. In fact, studies
show* that the majority of large-scale software implementations fall short
of delivering anticipated benefits and return on investment (ROI). This
happens for many reasons: lack of leadership involvement, misalignment
of objectives, poorly designed processes, resistance to change, extensive
customization, and poor project management, just to name a few. One
organization invested over $50M in a global ERP system only to discover
after going live that process improvement efforts had become significantly
more difficult due to the inflexibility of the new system. In fact, staff had
to be hired to support additional data entry requirements!
When witnessing the aftermath of ERP and other enterprise-wide
implementations, we often discover an underlying assumption that the
new system would deliver best practices and effectively address broken or
missing processes. Some mistakenly expect these applications to be a silver
* See the CHAOS report, Figure 3.1

bullet that will remedy years of undocumented processes, workarounds,
and fragmented information systems. As a result, they lead with a technology solution before defining and improving core processes—a recipe for
disaster. Ironically, during implementation many companies can’t resist
the temptation to customize the new enterprise system to mimic old procedures, repeating the old bad practices.
So what is the correct approach? Our first experience with the convergence of strategic alignment, information systems, and Lean thinking
came nearly 15 years ago, with our involvement in ERP selection and
implementation projects, reaching a crescendo during the Year 2000
(Y2K)* market frenzy. Popular software selection methodologies led many
companies to pursue ERP software suppliers with excessively detailed
“request for proposal” documents followed by exhaustive demonstrations
which often explored every system capability, regardless of their relevance.
The most qualified vendors and consultants were already quite busy, and
this wasteful approach would often just scare them away.
Without a solid grasp of specifically targeted outcomes, or a clear understanding of the strategic intent of the new system, selection teams were
susceptible to choosing the most persuasive sales presentation, rather than
the best match to their requirements. The resulting systems were often
unnecessarily complex, highly customized, and eerily similar to the legacy
systems they had just replaced. This was because selection teams rarely left
their comfort zones, and so their selection requirements were incremental enhancements, based on mental models of their current system. As a
result, many of these very expensive, large-scale systems failed to deliver
breakthrough improvements; these organizations settled for new systems
that were only slightly better than those they replaced. Unfortunately,
these new systems often cemented current business processes into place
for many years to follow.
Early in our practice we engaged cross-functional teams in improvement of key enterprise processes, emphasizing a critical differentiators
approach, helping the company to identify a handful of key issues (strategic drivers) that would successfully guide the selection among dozens
of ERP candidates. Not only did this streamline the selection process,
making it less time-consuming and costly, but it also helped the team
* The Year 2000 (Y2K) market frenzy occurred when many organizations hastily replaced deeply
entrenched legacy systems prior to January 1, 2000, for fear these systems would fail.

focus on the critical drivers for success, what the system would do differently to actually improve the performance of the company in ways
that really mattered. Strategic objectives, when understood by the team,
naturally began to blend with enterprise software selection and implementation practices.
The Efficiency–Flexibility Trade-Off: Agility
The necessity to operate efficiently is a given, but it’s also important to be
responsive and adaptive as customer needs change and new opportunities emerge. Organizations should strive for agility: an appropriate balance between efficiency and flexibility. Efficiency means performing work
well without wasted effort (using fewer resources), while flexibility entails
responding to change quickly with limited disruption. This relationship is
illustrated in Figure 4.3.
At one end of the continuum is efficiency, where Lean focuses on waste
reduction, visual management, standard work, and ongoing process
improvement. At the other end of the continuum is flexibility, where Lean
applies the voice of the customer, demand management, just-in-time, level
scheduling, small lot sizes, mixed model production, cross-training, and
other techniques to create flow (see Chapter 5). Efficiency minimizes costs,
while flexibility creates value by maximizing responsiveness; agility is the
Agility
Eﬃciency

Stable Processes
Standard Procedures
Predictable Outcomes
Minimal Disruption
Rigidity

Figure 4.3

Agility: Balancing efficiency and flexibility.

Flexibility

Fluid Processes
Responsive Procedures
Less Predictable Outcomes
Frequent Changes
Adaptability

balance point between these two capabilities. In Business Agility, Michael
Hugo explains,
Efficiency provides us with basic products and services at the lowest price.
Responsiveness wraps those products and services in a blanket of valueadded services that customize them to our particular needs, and in doing
so, makes them more valuable to each of us.6

IT professionals, as well as all process owners and knowledge workers,
should be aware of this trade-off between cost and value when improving
processes, in order to sustain the appropriate balance. Another useful way
of looking at the efficiency–flexibility continuum is through the distinction between process and practice.
Process versus Practice
At its core, Lean IT supports process improvement by providing the right
information, at the right time, in the right format, to the right audience.
The usefulness of information is determined by the nature of work being
performed. In this regard, it’s helpful to differentiate work as either process or practice to better understand what type of information is needed.
Throughout this book, we use the term process to describe a series of
actions or operations supported by structured information. Processes are
activities that are generally repetitive, well-defined, routine, controllable,
and standardized. In contrast, practices are nonroutine, highly variable,
loosely defined, and require a degree of judgment and experience to carry
out.
To illustrate the distinction, consider a visit to your doctor. The nurse
visits you first and performs standard, routine procedures (takes your
blood pressure, temperature, etc.)—this is process work. When the doctor arrives, she reviews your chart and asks how you are feeling. Then she
proceeds to examine, diagnose, and prescribe based on your symptoms
and medical history, supported by her experience and professional judgment—this is practice work. Society tends to describe professions (such as
legal, accounting, and medical) that depend on a great deal of education,
judgment, and unstructured information processing as practices.
The difference between process and practice influences how improvements should be approached and what type of information best supports

the work. In Product Lifecycle Management, Michael Grieves explains the
important difference, as well as a common pitfall that leads to hyper-efficiency at the expense of flexibility:
The information requirements are different for practices than those of processes. With processes, the focus is on the movement from state to state
as quickly as possible. With practices, the focus is on collecting data and
information at each state in order to build a pool of information to improve
the recognition of patterns in the future. However, when processes and
practices are both part of a task or procedure that is being automated, the
information goals of the practice often get minor attention.7

The better defined a process is, the more efficiently it can be executed. Process standardization creates efficiencies, and information
systems should be designed to reinforce explicitly defined procedures.
Efficient processes are fortified when information systems automate
routine tasks, such as mistake-proofing data entry, and providing feedback for ongoing improvement. Applying the 80/20 rule, simplifying
and automating the 20 percent of core processes that account for 80
percent of the volume and burden can make a significant and immediate impact on efficiency, freeing up human capacity for practices that
require experience and judgment
On the other hand, information used in practice work is typically
unstructured, difficult to define, and often experiential. When improving practices, the focus is on supporting a learning organization through
an accessible collection of knowledge of past experiences to enable situation-specific decision making. To support practice work, knowledge management systems should be designed to manage both unstructured data
(searchable content, documents, and images) and structured data (information in transactional databases, drilldown reports, trend analyses, etc.).
They may also provide access to collaborative social networks, forums,
blogs, wikis, and other sources of free-form knowledge sharing.
Over time, some of the elements of practice work may be simplified and
standardized into processes, effectively creating more efficiency without
sacrificing agility. Successful organizations attempt to achieve an optimal
balance between process and practice which has been described as mass
customization: the ability to produce products and services with the flexibility to meet a wide range of customer needs while maintaining mass

production efficiency (discussed in Chapter 5). With a clear understanding of the differences between process and practice, IT associates (working with the business) are better able to provide appropriate information,
contributing to the evolution of business processes and practices.

What Processes and Practices Are “Best”?
Individuals and organizations need clear targets to focus improvement
efforts, assess progress, and motivate change. The term best practice is
often used to describe what companies are seeking from process improvement and information systems. But what are best practices, and how are
they applied to effectively guide ongoing improvement? In Winning the
Knowledge Transfer Race, Michael English and William Baker define
a best practice as one that “fully satisfies customers, produces superior
results in one operation, performs as reliably as any alternative, and can
be adopted elsewhere.”8
A common misperception is that best practices create competitive
advantage. In fact, best practices create parity among organizations as
they conform to the same standards. Competitive advantage comes from
differentiating your organization through continuous learning, improvement, and innovation.
The majority of knowledge is stored typically inside the minds of workers and not explicitly documented, causing everyone to perform the same
work differently. Inconsistent behavior, by definition, cannot be consistently improved, since there is no established stable baseline from which
to start. When process and practice knowledge belongs only to certain
people, outcomes remain inconsistent, and knowledge is lost when they
leave. But once tribal knowledge becomes stabilized, standardized, documented, and shared with others, processes can be continuously improved
and meaningfully measured. As organizations purposely identify core
processes, assess their effectiveness, and document procedures, they make
knowledge management a natural part of work. As best practices are
documented, they secure the value of the organization’s intangible, intellectual assets. These are process assets that consistently add value to the
customer and create a foundation for continuous improvement and inno-


Continuously
Improving
Quantitatively
Managed
Standardized
Loosely Deﬁned
Unpredictable

Process is optimized on an ongoing
basis as part of a formalized system of
process improvement

Process is managed according to metrics
developed as part of the standard work

Process is explicit and documented
Standard work
Consistent outcomes

Some degree of control
Implicit knowledge
Loosely consistent outcomes

Poorly controlled
Tacit knowledge
Inconsistent outputs

Figure 4.4

The Capability Maturity Model.

vation, providing distinction, competitive differentiation, and advantage
to the organization.
The Capability Maturity Model (CMM),9,* shown in Figure 4.4, helps
an organization assess how well processes are defined and systematically improved. The model provides a framework for assessing process
capability, progressing from unpredictable process outcomes to stable,
continuously improving processes.

Benchmarking: No Need to Reinvent the Wheel
Learning organizations are constantly searching for ways to do things
better (continuous improvement) and to do better things (innovation).
Rather than reinventing the wheel, they often look internally as well
as externally for best practices they can readily apply. Benchmarking
identifies and evaluates best practices within the organization as well
* Originally developed in the field of software development and introduced in 1989 by Watts
Humphrey in Managing the software process, the Capability Maturity Model can be applied to
assess the quality and impact of business processes in any discipline or industry.

as across other organizations and industries to assess performance and
set improvement targets and long-range goals. As companies embark
on an ongoing search for better ways of doing work, they develop innovative future-state possibilities and targets. The basic steps of benchmarking include:
1. Understand your current processes in terms of effectiveness (measures and current levels of performance) and maturity (use value
stream mapping to identify waste and determine where to focus
improvement efforts).
2. Set your focus by determining what business process you are
investigating.
3. Identify what organizations and industries have similar processes
and are potential leaders.
4. Research and contact leading companies to identify best practices
and performance metrics (through the American Productivity and
Quality Center [APQC], the Global Benchmarking Council, trade
journals, conferences, and so on).
5. Collaborate with these organizations to share best practice information. (This works best when companies agree to exchange information beneficial to all parties within a benchmarking group.)
6. Identify gaps and opportunities for improvement, feed these ideas as
suggestions and potential countermeasures into the kaizen process.
7. Implement improved business practices with realistic metrics, goals,
and targets applying PDCA.
Internal benchmarking involves assessing operations from within the
organization (e.g., business units in different countries or other divisions).
These groups are often more accessible and willing to share proprietary
information. And if practices are adopted across the same organization,
there may be less resistance to change. However, the best innovations
often come from exploring the best practices of seemingly unrelated
industries; organizations can use benchmarking to break out of their
industry paradigms to discover breakthrough ideas. For example, an
airline might benchmark a leading hotel chain to discover best practices
regarding check-in and baggage-handling procedures. A hospital could
investigate a leading restaurant franchise to gain knowledge of order-processing best practices. And a surgical team could observe a NASCAR pit

crew to gather best-practice ideas relating to speed, accuracy, safety, and
economy of motion. External benchmarking can help a team break away
from existing assumptions and thought patterns to discover entirely new
ways of approaching work.

Using Measurement Effectively
Tracking actual performance against planned targets, workers preemptively respond to potential problems by applying management by fact—
basing priorities and future improvement initiatives on quantifiable,
objective outcomes. Although we all know measurements are important,
organizations often struggle to find good measurements that influence
desired behavior. Michael Hammer described seven common, deadly
sins10 of performance measures (paraphrased below):

1. Measuring only what you are good at
2. Measuring departmental process, not the entire process
3. Measuring corporate goals, not customer satisfaction
4. Not investing adequate effort to determine what should be measured
5. Measuring only small pieces of the process
6. Not considering the impact of measurements on behavior
7. Not taking measurements seriously

We’ve all heard the saying, “Show me how you’ll measure me and I’ll
tell you how I’ll perform.” Effective measurements focus people’s attention on the right things. Sustained improvement requires appropriate
performance measures, monitoring, and management. Without appropriate measures and the actionable information they provide, it’s just a matter of time before behaviors revert to the old ways of getting work done.
Measures guard against backsliding by focusing improvement efforts as
well as daily activities, emphasizing targeted results.
Often measures are taken, posted, and filed, but not utilized to drive
behavior. Effective organizations use constant goal setting supported by a
continuous measurement feedback loop to reinforce daily behavior which
drives positive change. If measurements do not enable people to move the

dial, they become a burden and detract from value-added work, and are
ultimately rejected.
Measures play an essential role in the Plan-Do-Check-Act cycle, providing the check with which teams act and adjust based on process results.
When used properly, they serve as an early warning system, notifying the
right people when course corrections and adjustments are required before
serious problems occur, often triggering the next cycle of improvement
activity.
Measurements also validate whether process improvements have generated expected results. Because of their influence on daily behavior, we suggest using 30-, 60-, and 90-day post-kaizen reviews to make certain that
process improvements have delivered as expected, and to prevent backsliding to old patterns of behavior.
Organizations often focus on results measures to assess performance
and guide decision making. These are often strategic and track end-of-pipe
outcomes such as revenue and customer satisfaction. While important,
results measurements provide lagging indicators of performance, offering
little predictive value. Exclusively using results measures is like driving
forward while only looking through the rearview mirror. Process measures are leading indicators which focus on tactical activities that directly
or indirectly influence results measures. Figure 4.5 shows some examples
of process and results measures.
Teams should develop an appropriate balance between process and
results measures for each value stream. They should also give attention to
Process Measures

Results Measures

Wait Time and Transaction Accuracy

Banking Experience

On-Time Delivery

Customer Satisfaction

First Pass Quality

Warranty Claims

Cycle Time (Check in and Treatment)

Patient Experience

Accurate and Speedy Check Out

Retail Experience

Figure 4.5

Process versus results measures.

what is measured. Many companies focus predominantly on revenue and
operating expenses. While these are important, revenue and expenses are
indirectly controlled by other factors. The balanced scorecard framework*
emphasizes a healthy balance of internal and external perspectives, applying financial and operational performance, customer satisfaction, and
employee development and innovation measures.
The IT organization plays a key role, helping the rest of the organization to access data, summarize information, and present measurements,
providing clear feedback to the individuals and teams responsible for
performing and improving business processes. IT associates provide the
enabling tools and access to data sources, working with the organization’s
knowledge workers so they can develop meaningful measurements and
analytics (see Chapter 6).
Compliance: A Special Form of Measurement
The burden of complying with regulations can be overwhelming, especially in heavily regulated industries such as banking, health care, insurance, and transportation. In many organizations, compliance represents
necessary but non-value-added activity that consumes massive amounts
of resources and mindshare. In their attempt to quickly conform to
regulatory requirements, companies often build a maze of stand-alone
“end-of-pipe” solutions, each with a unique results focus exclusive to a
functional silo of the business.
While these point solutions monitor certain activities and compliance
data, they seldom address root causes of compliance problems, and thus
do not enable continuous improvement. Compliance of this sort delivers
marginal and temporary value at best, while adding layers of complexity and non-value-added work; this reduces agility, making the processes
more resistant to improvement.
Dr. W. Edwards Deming, perhaps the most influential quality pioneer
of our time, used to say that “you can’t inspect quality into a process,”
knowing that quality must instead be built into a process. In the same way,
you can’t inspect sustainable compliance into a process; you must stabilize
and improve processes so that compliance is a natural outcome. The tools
and principles of Lean enable organizations to take control of business
* See Robert Kaplan and David Norton, The balanced scorecard: Translating strategy into action.

processes, adopt best practices, and develop process maturity, ensuring
compliance with standard work and regulatory requirements.
Lean provides a framework for managing change and controlling
operations—foundations of compliance. The financial officer of one
client, a global, publicly traded company, referred to Lean as “the Holy
Grail of Sarbanes-Oxley.” In his opinion, every hour and every dollar
spent chasing compliance should be refocused on improving processes.

Business Process Management (BPM)
As process improvement expands throughout the enterprise, an organization may reach a point where the scale and complexity of business
processes and improvement activities require a formal business process
management approach. Without a structured approach and supporting
tools, the difficulty and overhead of managing the intricate interdependencies of enterprise value stream and information system improvements
can be daunting. This is particularly true in larger organizations with
multisite and multi-division operations.
A holistic enterprise process viewpoint is not easily achieved, due to
the multidimensional nature of enterprise value streams and supporting processes, shared services, projects, resources, and stakeholders.
However, if an organization is unable to identify its value streams, its
supporting processes, and their interrelationships, it will be unable to
make valid fact-based prioritization decisions on process improvements
and IT investments.
Business process management is as much a philosophy of how to manage process improvement as it is a collection of technology-based tools.
Nevertheless, as a Lean transformation matures beyond the early, lowhanging-fruit improvements, such a framework is often necessary to guide
improvement efforts and align enterprise priorities.
Though an organization may not need an elaborate BPM software
system, it will need a good infrastructure approach, with a sound
schema to identify and categorize processes, manage ownership and
team composition, track improvement activities and results, and control changes to process maps, documentation, and other artifacts. A
disciplined approach is also helpful to organize metrics, dashboards,

and scorecards into a coherent enterprise-wide measurement system.
Such process management and measurement information systems are
often internally developed, and adapt over time to meet the evolving
needs of management and the Lean Center of Excellence. Larger organizations will need a database to manage the many value streams and
supporting processes, and their information system interdependencies,
since tracking on a spreadsheet can be labor intensive and error-prone.
There are several categories of tools and systems that can help an organization manage its process information:
• Value stream and process mapping software– such as Visio and eVSM
• Process management repositories and systems
• Workflow technologies with rules engines—available as stand-alone
applications and built into many ERP systems
• Process simulation tools—available as stand-alone applications and
integrated with BPM systems
• BPM systems—integrated systems supporting mapping, data
repositories, workflow, simulation tools, and interfaces to ERP
applications
While we mention these applications to shed some light on how organizations may automate the complexity of process management, it’s important to note that an organization should be careful not to invest heavily
in technology and automation at first, but rather focus on the social and
management systems issues. Hammer suggests:
The critical elements in success with process are executive leadership, creativity to come up with new ideas, the management of change, and the
management of complex implementation. None of these have much to do
with software tools. Yes, BPM software can help … but it’s not the difference between success and failure.11

Whatever systems an organization employs to manage its business
process infrastructure, it should stress simplicity, transparency, and
manageability.


Prioritizing Process Improvement with Strategy
Consistent and continuous focus on strategic drivers and critical differentiators helps the business develop a clear understanding of how each
process adds value, so trade-off and investment decisions (including but
not limited to IT investments) will optimize strategic outcomes.
One way to achieve this clarity is to separate processes into two categories: supporting and innovating.
Supporting Processes
Supporting processes are those that are necessary for the business to operate, but do not create differentiation in the eyes of the customer. These
include many repetitive or transactional accounting and administrative
activities, as well as many inwardly facing IT operations.
Efficiency should be the primary goal for supporting processes; thus,
they should be rigorously stabilized, simplified, standardized, automated—
and ideally eliminated whenever possible. We are often astonished at how
Lean companies think outside the box, eliminating many long-standing
supporting functions that are so common they are assumed to be necessary. For example, we have seen cases where procurement and payment
processes were eliminated, applying just-in-time and kanban approaches,
so that receiving a shipment instantly triggers release of supplier payment.
No invoice is ever printed, mailed, received, handled, matched, entered, or
archived by the accounts payable department, eliminating countless transactions, errors, paper, time, and other wastes traditionally associated with
the process.
Year-on-year reduction of supporting process operating costs, without sacrificing service levels, often requires investment in automation.
This in turn can necessitate a move toward flexible service-oriented
architectures and low-cost utility cloud computing (whether internally
or externally hosted) and the potential for selective outsourcing. But
here we strongly caution not to simplify, automate, or outsource supporting processes when they can be eliminated altogether. Nor should
companies create overly complex, hyper-efficient, automated processes
which result in near-term cost savings at the expense of long-term
agility.

An example of significant reduction in supporting process costs can be
found with Bechtel, one of the world’s largest engineering firms. Bechtel
made dramatic improvements through data center consolidation, server
virtualization, and private (internally hosted) cloud computing. In 2005,
more than 2,000 IT employees staffed approximately 20 datacenters, where
server utilization averaged between 2 and 3 percent. In 2009, a department
of 1,100 employees operates just three datacenters, where server utilization
averages 60–70 percent.12
While projects like this can yield significant positive results for the
enterprise, if not managed properly they can also spread fear throughout
the IT organization. Even the perception of potential layoffs will throw
a wet blanket on a Lean effort; few will enthusiastically support process
improvement if they fear losing their job as a result. Herein lies a fundamental distinction between a focus on cost-cutting and an emphasis on
adding value through waste elimination, which naturally results in cost
reduction over time. A focus on cost reduction through rapid headcount
reduction is like losing weight by giving blood—while it works quickly,
it isn’t very healthy. The key to Lean success in a cost-cutting world is to
understand waste reduction as an opportunity to free up human capacity
and capability for value-added work.
While waste elimination naturally reduces many costs in the short term,
it also adds long-term value by unleashing potential for growth and innovation. Most companies do not have a shortage of good people with good
ideas; these people are just buried under a mountain of wasteful activity
disguised as daily work. Every time we free up people’s time, emancipating
them from unnecessary and often frustrating work, we enable them to apply
their experience and creativity to perform new value-adding activities: these
include improving, innovating, and spending quality time with the customer (see the Virginia Mason Medical Center case study). Underutilized
human potential is the gold mine hidden within every company.
Successfully retraining and reassigning IT associates quickly, so they
can become productive in a new function or area of the company, is accelerated by the tools and methods of Lean transformation. Once an individual develops proficiency with A3 thinking and problem solving, for
example, he or she can quickly get to the heart of any process and confidently start contributing to its improvement.
As IT infrastructure and applications continue their inevitable migration toward a low-cost cloud computing model, the emphasis of the IT

organization must quickly shift toward process leadership and innovation,
concentrating on the strategic drivers within each value stream. And it is
this freed-up human capacity and potential that will fuel the transition.
Innovating Processes
Innovating processes reinvent the business and establish differentiation in the
eyes of the customer. Innovating processes may include the development of
new products, services, markets, and partnerships; information systems often
play a direct and vital role. For example, e-commerce and social-networking
applications deliver self-service value (choice, convenience, speed, knowledge,
community, etc.) directly into the hands of the customer.
Over their life cycle, innovations often evolve into standard products,
services, and processes—and, at some point, their ability to create competitive advantage diminishes. According to Gary Hamel and C.K. Prahalad,
in their Harvard Business Review article “Strategic Intent,” the essence of
strategy lies in creating tomorrow’s competitive advantages faster than
competitors mimic the ones you possess today.13 In Nike’s case, for example, in the highly competitive athletic garment industry, some product life
cycles are less than 90 days. In general, the toughest competitors often
discontinue a product family before its life cycle goes into decline, causing
their competitors to forever chase their next product release. Innovation
can never rest.
As organizations learn to distinguish critical differentiators in their
processes, they can invest their IT dollars more effectively. For example, many manufacturing companies are focusing their investments
on operating technologies within core value streams, such as product
life cycle management (PLM) and manufacturing process management
(MPM), directly enhancing their ability to design, produce, and deliver
their products and services.14 This is accompanied by a corresponding de-emphasis on necessary but non-value-adding (NNVA) business
processes and supporting IT assets, such as many of the supporting
processes performed by back-office ERP systems. Other industries
are following suit, directing less attention on NNVA and emphasizing direct, end-customer-facing operating processes (e.g., bank loan
approvals, insurance claim processing, and medical laboratory order
scheduling). In fact, in many information-intensive industries, such as
banking, insurance, and often health care, the operating information

system is the production process, and information is the work product
delivered to the customer.
This trend illustrates how IT innovation and differentiation are driven
by awareness of customer value. If the IT organization is going to play an
even greater role in the improvement and automation of mission-critical,
customer-facing operational processes, then IT–business–customer collaboration is essential.
Innovating processes are often practices, different from standardized,
repeatable processes as we discussed earlier in this chapter, requiring
more human interaction, experience, insight, and judgment, supported by
accessible structured and unstructured information. Innovating processes
break new ground and often require multidisciplinary cooperation both
within and across traditional boundaries of the enterprise. A new idea can
come from anyone, anywhere, anytime. Thus innovating processes benefit
from innovative information systems* which facilitate open communication and knowledge sharing, enabling continuous and rapid learning.
Let’s be clear—information and information systems do not drive innovation; they support and enable it. There is only one thing that ultimately
drives value through innovation: the voice of the customer. So we must
learn to listen carefully, engaging all our senses, which can be extended
and amplified through our digital nervous system.
IT process leaders and business process owners must together understand the distinction between supporting and innovating processes,
illustrated in Figure 4.6. With this understanding, accompanied by a constancy of purpose, IT leadership can guide the enterprise toward efficient
supporting processes, while simultaneously enabling innovating processes
to create new, differentiating, revenue-generating value for the customer.

The IT Organization’s Contribution
Throughout this book we explore the goal of alignment between IT and
the core business in which IT and the business start thinking and acting as
one, with a common purpose: to support the strategy of the organization.
* Some examples include collaboration tools, project management, product lifecycle management,
business intelligence, market research and analytics, online surveys, social networking, design,
modeling, and visualization tools.


Innovating Processes
Drive Competitive Diﬀerentiation

Achieve through partnering
to protect internal resources
and mindshare

Focus on innovation and
continuous learning to drive
growth, new markets,
competitive disruption and
advantage

Supporting Processes
Maintain Competitive Parity

Eliminate where possible,
otherwise simplify,
standardize, automate, and
potentially outsource

Low

Focus on continuous
improvement to drive
operational excellence and
cost reduction

Mission
Critical

High

Figure 4.6

Innovating and supporting processes.15

But alignment is an ambiguous word and doesn’t convey the full picture.
IT and the business must work side by side as partners: learning, prioritizing, planning, executing, and measuring the results of process improvement and innovation initiatives. For such a tightly woven relationship we
prefer the term integration. But no matter what you choose to call it, how
you go about achieving it is the real challenge.
Quality information and effective information systems connect, support, and enable process improvement throughout the enterprise. Because
information is the essential lifeblood that coordinates the flow of work
and creation of value to the customer, the contribution of the IT organization is pivotal to the ultimate success of the organization and its value
streams. In the end, organizational effectiveness is about each individual
doing the small things well—seamlessly blending daily work and ongoing
improvement.

In a Lean enterprise, cross-functional teams work in partnership with
IT practitioners to improve business processes. In doing so, the IT organization becomes a partner and enabler of process improvement, shifting
a large part of its focus from supporting activities to innovative solutions
development in collaboration with the business.

Endnotes

1. Peter Drucker, The essential Drucker (New York: HarperCollins, 2001), 111.
2. Michael Hammer is best known as the coauthor of Reengineering the corporation,
which launched the era of business process reengineering; see Michael Hammer and
James Champy, Reengineering the corporation (New York: HarperCollins, 2003).
3. Jeffrey K. Liker, The Toyota way (New York: McGraw-Hill, 2004), 160.
4. Baruch Lev, Intangibles: Management, measurement, and reporting (Washington, DC:
Brookings Institution Press, 2001), The book of the month: “Intangibles: Management,
Measurement, and Reporting” by Baruch Lev, http://www.juergendaum.com/
news/10_30_2001.htm.
5. See Jay Galbraith, Designing matrix organizations that actually work (San Francisco:
Jossey-Bass, 2008).
6. Michael Hugo, Business Agility (Hoboken, NJ: Wiley, 2009), 4.
7. Michael Grieves, Product lifecycle management (New York: McGraw-Hill, 2006),
148.
8. Michael English and William Baker, Winning the knowledge transfer race (New York:
McGraw-Hill, 2006), 39.
9. Watts Humphrey, Managing the software process (Reading, MA: Addison-Wesley,
1989).
10 Michael Hammer, The 7 deadly sins of performance measurement (and how to avoid
them) (Boston: MIT Sloan Management Review, Spring 2007), 19.
11. John McCormick, CIO, as chief process officer, interview with Michael Hammer, Oct.
3, 2007. www.cioinsight.com
12. Mark Everett Hall, “Private clouds gaining traction among IT shops,” InfoWorld,
October 27, 2009 www.infoworld.com/print/97560.
13. Gary Hamel and C. K. Prahalad, “Strategic intent,” Harvard Business Review, May–
June 1989, 63–76.
14. Dan Miklovic, Predicts 2010: Global economic stress changes markets for manufacturing solutions, December 7 (Stamford, CT: Gartner, 2009).
15. Pollyanna Pixton, Niel Nickolaisen, Todd Little, and Kent McDonald, Stand back and
deliver: Accelerating business agility (Reading, MA: Wesley Professional. 2009), 15.

5
Lean IT Lessons Learned from Lean
Manufacturing: Flow and Pull

Chapter Objectives
Looking back on the last five decades of Lean’s evolution, we find many
important lessons learned that have a direct applicability to Lean IT, whatever the industry. We will:
• Examine flow, pull, and visual signals and contrast their simplicity
and clarity with the complexity of material requirements planning
(MRP), a popular manufacturing push-scheduling technique.
• Explore kanban, heijunka, and mixed model production and understand their impact on stability, efficiency, and flexibility (agility).
• Propose a step-by-step process for creating an effective IT demand
management decision-making process.
Simplicity is the ultimate sophistication.
—Leonardo da Vinci

Factories are complex and chaotic places where events rarely go as planned.
When not approached with caution, software intervention can amplify the
existing complexity and chaos. Lean manufacturing practitioners have
learned to simplify their production processes, aligning, balancing, and
reallocating resources so work will flow along value streams, orchestrating
97

activity through pull signals and visual cues. Work is pulled by customer
orders rather than pushed by a forecast-driven schedule. At the start of the
transformation process, Lean practitioners focus on customer value and
the value stream. Lean practitioners eliminate as waste the obsolete, the
unnecessarily complex, and the ineffective, including counterproductive
information systems. Technology is not reintroduced until the underlying
processes have been simplified and stabilized.*
Since Toyota’s production, product development, and management
systems laid the foundation for Lean practice, it seems natural to ask
about their approach to IT to inform our own efforts. There is a commonly held misconception that Toyota is reluctant to use information
technology. Toyota is in fact a significant IT investor and innovator;
however, they do not lead with technology solutions. They first focus
on business solutions, with emphasis on stabilizing and improving
processes through relentless problem solving, supported by appropriate data. Electronic information systems are then carefully deployed to
automate standard work, reduce the potential for errors, and support
effective measurement.
Looking beyond Toyota to other large, global, manufacturing and supply
chain enterprises, Nike’s growth could not have occurred without extensive reliance on pioneering information technologies; their IT organization includes nearly 1,500 staff in 60 countries. Over the last decade, Nike
has made significant investments in a sophisticated technology infrastructure for product development and supply chain management (not without
some expensive learning experiences along the way),1 which enables them
to continuously innovate while improving operating efficiency.
Now that the essential technology framework is in place, Nike has
turned its focus toward business process improvement as a driving force
in IT strategy. In fact, the chief information officer (CIO) of Nike reports
to the chief operating officer, ensuring an operational focus throughout
all IT initiatives. As an indication of transformation in their culture, the
globally renowned “Just Do It” company has rebranded their IT department as Lean Business Solutions (NikeLBS).
According to Lean Enterprise Director Steve Castellanos, “At Nike, we
turned our Lean focus toward the enterprise some years ago and as we did
* For more on Lean IT in a manufacturing environment, see Lean enterprise systems, using IT for
continuous improvement, Chapters 4 and 5, by Steve Bell

Lean IT Lessons Learned from Lean Manufacturing: Flow and Pull • 99
it became evident that our information technology delivery model was out
of sync with the business processes that they were designed to support. This
realization was the driver behind the organizational changes that brought the
former IT and Process Excellence organizations together into what we now
call Lean Business Solutions. With this structure our intent is to position LBS
against enterprise-wide opportunities in an aligned and synchronized way.”2
Another global supply chain organization, Tesco, has been on their Lean
journey for over a decade, with a particular emphasis on essential information systems. The fourth-largest global retailer drives growth through
innovation with small, local stores selling fresh and innovative products.
By simplifying and standardizing their business processes and information systems, Tesco is able to open new stores quickly, while adapting to
local market conditions and consumer preferences.
Tesco’s supply chain systems operate by Lean replenishment rules that
issue pull signals directly to suppliers on a daily basis. Unlike traditional
retail models, this system does not rely solely on forecasts of consumer
purchases. Daily consumption and replenishment signals help reduce
inventory, handling, shrinkage, and stockouts, helping Tesco to ensure
variety and freshness, while quickly spotting new trends and emerging
problems. It’s interesting to note that Taiichi Ohno’s early inspiration for
just-in-time inventory replenishment came on a visit to the United States,
where he observed refrigerated products being replenished from behind as
they were pulled off the shelves of supermarket coolers. So, in Tesco’s case,
Lean has come full circle.
But even with Tesco’s strategic focus on market growth and advanced
supply chain technology, it’s clear that it has internalized the primary
focus of Lean: customer value. According to Mike Yorweth, Tesco’s group
technology and architecture director, “We’re such a big business and it’s …
complex. So you’ve got to make everything as simple as you possibly can,
and standardizing makes things simple for people. If their jobs are easier
to do, it means they can focus on customers. Ultimately that’s what we’re
here for.”3
Toyota, Nike, Tesco, and countless other innovative manufacturing and
supply chain organizations around the world have successfully leveraged
IT capabilities with their Lean practices in a variety of ways. But it’s not
just about big companies; the efficiency and lower costs of Lean operations
and information systems create opportunities for small, agile companies
to compete with larger ones.


Push versus Pull: What Went Wrong with MRP?
One of the key IT lessons learned from decades of Lean manufacturing is
to keep processes and supporting information systems simple. Nowhere is
this more evident than in the history of material requirements planning
(MRP), a method used to calculate what needs to be purchased and built
based on routings, bills of materials, inventory levels, and other planning
information.
In the 1960s computers started tackling many of the most complex challenges that business had to offer, including material planning and control.
After all, if we could put a man into space, why couldn’t we control what
happens on a factory floor? Operations managers adopted a mechanistic
view, creating the discipline of MRP. George Plossl, one of the founding
fathers of MRP, describes these times as full of hope and promise, as well
as unrealistic expectations:
Operations researchers were intrigued by the problem of determining
“optimum” work sequence in complex manufacturing environments. MRP
program designers, obsessed with the potential power of computers and
software, attempted to build into MRP capabilities to cope with every eventuality in manufacturing, and to include every known technique, however
little use these would be.4

In simple terms, MRP combines customer orders and forecasted customer
demand for each finished goods item, then explodes it into time-phased
component-level requirements to guide purchasing and production decisions. MRP calculations determine what needs to be manufactured at each
workcenter and when, creating a never-ending stream of production schedules and dispatch lists—detailed marching orders for the shop floor. This
is push scheduling, where every factory operation is planned in advance—
much like a football coach calling all the plays before the game begins.
The problem is that the plan is never exactly right. First of all, it’s mostly
based on a forecast, and forecasts are just sophisticated guesses. Plus,
conditions on the factory floor are always changing—machines break
down without notice, sudden rush orders delay others, defects unexpectedly consume scarce materials, and so on. Although powerful computers
and MRP software are able to rapidly recalculate each time something
changes, frequent changes cause the schedule to become jittery or nervous.

Constant interruptions and shifting priorities, when communicated to
the shop floor, cause workers to spend more time and energy chasing the
schedule and performing costly machine changeovers (often making them
jittery and nervous, too). So planners attempt to compensate by buffering
with excess inventory, stocking more than is necessary in order to ride out
variability while making fewer changes to the production schedule.
But as companies offer more options to their customers, as supply chains
become more complex and geographically extended, and as customers
continue demanding shorter lead times, the amount of excess inventory
needed to buffer increasing uncertainty inevitably reaches a tipping point.
Taiichi Ohno of Toyota identified excess inventory, and the overproduction (non-just-in-time) that created it, to be the primary causes of waste.
Furthermore, excess inventory hides other forms of waste, hindering their
identification and elimination.
Even the most powerful computers and sophisticated software can’t
solve this fundamental problem: the more we strive to control complexity
through forecasting and push scheduling, the more the laws of uncertainty
and chaos push back. So to many Lean manufacturing practitioners, MRP
is perceived as the enemy of simplicity, agility, and flow.
But there are situations where MRP and other sophisticated planning
and scheduling software tools are useful in Lean manufacturing and supply
chain operations, as long as they are applied judiciously, with awareness of
their limitations. The enemy is not the technology, but our assumption that
we can somehow control complexity by throwing more complexity at it.
What is the key limiting factor in this scenario? Time! The further into
the future an organization forecasts, the more uncertainty it must anticipate and buffer against, buying and building more inventory ahead of
time. And when customer preferences suddenly change, or the economy
takes a turn, the organization is burdened with this excess inventory. The
solution is to shorten the planning horizon, to the point where production is driven not by a forecast but by actual customer orders. The more
production is driven by customer pull signals, the less waste is created
throughout the supply chain.
Just-in-time production is simple to describe, but difficult to achieve. Just
as products, services, and processes differ from one company to another,
so do their planning and scheduling requirements. By understanding
these differences, Lean practitioners in any industry, and IT organizations
in particular, can understand how to apply Lean flow techniques.


Flow, Balance, and Agility
In 1979, two Harvard Business School professors described a pair of
continua: a product life cycle based on maturation from individual-unit
customization to standardization, and a process life cycle describing the
various methods of production.5 Combining these two continua results
in a diagonal (Figure 5.1) which describes the progression of manufacturing types: engineer to order, make to order, assemble to order, and make to
stock—commonly known by the acronyms ETO, MTO, ATO, and MTS.
At the ETO end of the continuum are unique products, individually designed and custom-made to exact customer specifications. On
the other end of the continuum, MTS, highly standardized products
are mass-produced in large quantities to forecast, and are stocked in a
distribution channel for the customer to buy off the shelf. ETO emphasizes flexibility, while MTS emphasizes speed and cost. At this point
the reader may recall the efficiency–flexibility continuum explored in
Chapter 4 (see Figure 4.3).
Custom
Products

O
ET

Individual
Product
Creation

Mass Customization
The “Sweet Spot” of Agility

O
AT

Process

TO
M
TS
M

Continuous
Flow

Mass
Production
Unique
Products

Figure 5.1

The product–process diagonal.

Product

Standard
Products

Over the years, manufacturers have developed a variety of tactics to
provide customers with flexible, configurable products built upon standard, modular options that can be delivered quickly to customers’ specific
requirements. This approach, called mass customization, is covered by the
central region of the diagonal. While some speed and flexibility are sacrificed, and marginal cost is added, the result is agility: the ability to quickly
respond to changing market conditions and customer demand, based on a
standard set of configurable products and processes, with minimal inventory in the pipeline.
The full expression of this approach is called mixed model production,
where each unit flowing on a production line may carry different specifications. At an automobile manufacturer, for example, a red sedan with
leather interior may be followed immediately by a blue passenger van with
cloth interior, flowing down the same line at a steady pace. The right mix
of materials is ready at the point of use, replenished by kanban (discussed
shortly), and production activities are supported by visual communications. At any moment a worker discovering a defect may stop the line to
quickly identify and correct its cause (quality at the source), improving
process stability and product quality along every step of the process.
Many Lean manufacturers are moving toward this sweet spot of mass
customization where an agile enterprise can respond to varying customer
requirements with short lead time and relatively low cost. With a little
creativity, Lean practitioners in nonmanufacturing applications (including IT) find they can apply the diagonal sweet-spot metaphor to their
own products and services, since it represents an agile balance of efficiency and flexibility.
Let’s try it now. Think of an office process in your company (e.g., processing a medical laboratory order, handling an insurance claim, or making
a hotel reservation) where most of the time everything is normal and the
process flows smoothly. But every now and then, a variable is introduced
that slows the process down. Suddenly the associate doesn’t know exactly
what to do and has to stop what he or she is doing to search for materials or
information. Flow is suddenly interrupted—not just for this one transaction, but also for all work queued up behind it.
While it is certainly not easy to make a process flow, there are several
basic issues to consider. First, think about how you would identify all the
common variations (options, configurations) in the product or service that
the customer would value. How might you standardize and categorize them

so anticipated variation is handled smoothly? What sort of materials, information, training, and support should be provided so associates can handle
these variations without interrupting flow? How would the physical and virtual workspace be organized to require minimal movement, transportation,
and delay, while creating a visual line of sight across the entire process?
There are many benefits to flow, among them:
• Work flows smoothly, without interruption, congestion, or bottlenecks, enabling just-in-time response to customer requests.
• The pace of activity is based on demand signals, so no excess inventory is created, and no excess work is performed.
• Associates are able to spot and solve problems quickly, improving
quality and process performance.
• Production time is stable, so customer service–level agreements
(time and quality) can be consistently promised and met.
And, most importantly for the topic of Lean IT, flow simplifies the
information requirements of a process. Since the pace of work is stable,
sophisticated scheduling and control software is often not necessary.
And because process problems quickly call attention to themselves, they
are self-regulating, so invasive monitoring, data capture, and analyses
also become unnecessary. That is not to say that it is not important to
identify key metrics or key performance indicators (KPIs). And there is
still value in collecting and analyzing some data, seeking to understand
process variation and its relative impact on flow, in order to support
continuous improvement.

Kanban Is an Information System for Pull
Kanban is a signaling device that pulls the flow of work through a process
at a manageable pace. Kanban has several purposes:
1. Triggers work only when ordered by the customer: When a kanban
signal is received by a work center, it causes work to begin. Working
only to demand signals (just-in-time) directs resource allocation and
prevents overproduction and excess inventory.

2. Indicates the specific work to be done: Kanban signals contain a
description of the work to be done next, which clarifies the sequence
of work priorities for supervisors and associates.
3. Controls the amount of work in process: By regulating the quantity of
kanbans within a process, inventory is limited.
4. Buffers interruptions: By keeping a small, carefully calculated buffer
of safety stock between operational steps (also called a supermarket),
the downstream operation is not starved by a temporary interruption from an upstream operation.
5. Orchestrates the pace of work: Since each operation is only working
according to pull signals, the work flows at a natural cadence. A sudden interruption is easily spotted, and workers quickly converge and
troubleshoot the problem in order to restart the process flow.
While kanban is simple to describe, the variations are limited only by
the creativity of the team designing the system. In a manufacturing setting we have seen kanbans implemented using cards, bins, pallets, colored
golf balls, flashing lights, and other clever devices.
It’s important to keep kanbans physical and visual whenever possible, but
sometimes electronic kanban communications are appropriate. Electronic
kanban signals include on-demand printed kanban cards with bar coding, overhead or kiosk electronic displays at each work center, roaming
wireless devices, e-mail messages, and other computerized methods. The
rapid communication of supplier replenishment over long distances can
significantly reduce supply chain inventories and delays. Electronic data
interchange (EDI) messages (demand signals) are often sent to suppliers
(external vendors, as well as internal suppliers within an extended enterprise) to trigger replenishment, reducing labor costs, while preventing
delays and data entry errors. Rather than an MRP system sending periodic release messages on a push-scheduled basis, however, electronic kanban pull signals should be triggered in real time by workflow events.
Electronic supplier kanban can be surprisingly simple. Years before webcams became popular and inexpensive, Boeing deployed a clever supplier
replenishment visual kanban system. First, they organized the raw material storage location, using shelving and tape. It was very easy to view this
area and quickly determine when replenishment was needed. After establishing min/max levels with their supplier, Boeing trained a web camera
on this space. Boeing provided the supplier with a secure link so it could

remotely observe inventory levels several times each day. The supplier was
authorized to initiate the replenishment order as needed.
Though kanban was first developed in a manufacturing setting, it
translates easily into the office environment. Imagine an office setting
where each step of a process is performed in someone’s cubicle. Outside
each cubicle hangs a rack, and each slot on the rack can accept a limited number of folders containing work (loan applications, lab orders,
patient charts, insurance claims for review, etc.). Each slot represents a
standard unit of work, pacing production flow while limiting the buildup
of excess work-in-process inventory. Each participant in the process now
has line of sight to the entire process and visual signals to indicate how
well the process is flowing. An empty slot sends signals upstream to produce more work. And if there are too many, or too few, empty slots at a
particular position, it visibly signals that somewhere a flow interruption
has occurred —a silent call for assistance. This arrangement is illustrated
in Figure 5.2.
We have witnessed kanban effectively drive out waste in virtually every
industry, and it can apply to any form of work, material, or information flow. For example, Naida Grunden, author of The Pittsburgh Way to
Efficient Healthcare,6 describes the use of kanban in the pathology lab of
a Pittsburgh-area hospital, where color-coded cards hanging on key rings
signal for a replenishment order. When an item is low, anyone can take a

Standard
Kanban is
5 Work Units

Empty Slot Signals
Step 1 for Next
Transaction

Pull

Step 1
Input
Figure 5.2

Office kanban.

Three Empty
Slots Signals Possible
Upstream Flow Interruption,
Worker Visits Step 2
to Oﬀer Assistance

Pull

Step 2
Processing

Pull

Step 3
Processing

Step 4
Output

laminated card and hang it on a plastic hook on the bulletin board right
next to the phone, where the order entry person will see it. Once this system was implemented, staff labor dedicated to order placement plummeted
from eight hours per week to 10 minutes per day. Inventory was reduced
by about half, stockouts all but ceased, and the investment in an expensive
new information system was avoided.
Just like a factory, when an office value stream extends across a distance
(such as several buildings in a campus setting, or around the globe), there
is limited physical visibility to kanban status without electronic communications. Thus electronic workflow and backlog/inbox management rules
may be designed to follow simple kanban logic, with automated escalation
alerts calling attention to exception and error conditions.

Creating a Level Schedule
Once a process is made to flow, it’s important not to overload it. While kanbans regulate the internal load balancing of a process, a scheduling mechanism is still needed to prevent too much work from accumulating at the front,
and to regulate a steady release sequence of work. An excessive or improperly
sequenced backlog causes an unreliable schedule, which leads to frequent
expediting and rule breaking, ultimately causing flow to fail—chaos.
Heijunka (Japanese for level scheduling), working with kanban, establishes a simple-to-understand visual schedule that releases work at a
steady cadence, while responding quickly to change. Kanban signals can
be physical cards in a physical heijunka box or electronic signals on an
electronic heijunka box.
Figure 5.3 continues our office kanban example, showing the function
of a level schedule. In this example, the pace is established at five work
units every two hours. When people submit new work (demand), they can
look at the daily backlog and instantly determine how loaded the process
is, and when they should expect their work to be completed. This visibility
prevents countless interruptions for schedule status information, which
would otherwise interrupt flow and hinder productivity.
If the new work has a higher priority than what is already in the queue
(a high-priority customer request), with proper authority (preestablished
decision rules are important here) the work unit can be moved nearer to

Office heijunka box.

Figure 5.3

Level schedule
board visually
displays load,
production
schedule, and
expected delivery
time

Pace is ﬁve work
units every two
hours

Demand

3–5 pm

1–3 pm

10–12 am

8–10 am

Pull

Step 2
Processing

Takt Time (Pace) Calculation:
120 minutes / 5 units = 24 min. per unit

Step 1
Input

Pull

Pull

Step 3
Processing

Pull

Step 4
Processing


the front of the queue. The remaining work shifts to a later slot, but since
this work has not yet been released, its reprioritization does not disrupt
the flow of work already in process. Once work is released it flows quickly
(just-in-time) to completion and on to the customer, so expediting is
unnecessary.
With a little creativity, level scheduling and kanban methods can be
applied to any product or service process in any industry. In Chapter 8, we
explore how these methods have been applied to Lean software development (also known as agile).
By simplifying process, product, and service design, and through the
creative use of kanban and level-scheduling methods, the informationprocessing requirements of many processes can be simplified. This stabilizes the environment, helping to maintain service-level agreements with
customers, while avoiding the investment and complication of sophisticated software and the cost and chaos it often creates.

IT Demand Management: The
Foundation for Flow
Plans are useless, but planning is indispensible.
—General Dwight D. Eisenhower

No matter how well a process flows, it is essential to manage the demand
feeding it, creating a prioritized queue of work that is clearly aligned with
customer demand and business objectives. Otherwise, it is possible that all
you have accomplished (with pull and a level schedule) is to cause nonprioritized (and potentially non-value-adding) work to flow more efficiently
to your customers. More likely, however, introducing non-value-added
work into the backlog will result in sudden interruptions and unplanned
changes once the customer sees the results.
IT demand management is essential to ensure the right work is introduced to development and then production at the right time. From the IT
perspective many organizations live with a crushing backlog, often two
years or greater in length. When a backlog grows this large, it becomes
virtually impossible to effectively manage. As business decision makers

lose visibility to the workload, they are unable to make informed trade-off
decisions regarding the best use of already constrained resources.
Also, when a clear decision-making process does not exist or is ineffective, customers tend to treat every new task as a rush job, so priorities
are ephemeral, shifting by the moment. This leads to frequent juggling
and thrashing of IT projects, and interrupting and task-switching of wellintended IT staff, causing widespread inefficiency, poor quality, frustration, and decreased morale.
When people become overloaded, they tend to shift into a reactive, firefighting mode: attacking symptoms and providing quick fixes rather than
identifying root causes and implementing lasting solutions. This behavior
only digs the IT organization into deeper turmoil, since every impulsive
response adds to the growing technical debt of patches, workarounds, and
legacy systems that must some day come due.
From the business perspective, IT is often branded as unreliable—
consuming endless streams of capital, while delivering projects that are
chronically late and over budget, and that ultimately underdeliver.* In
their struggle to establish priorities, many organizations devolve into a
pattern of battlefield decision making, a process depending less on facts
and business priorities and more on assumptions, influence, and persuasion. This in turn creates unhealthy zero-sum gaming behavior among
managers and business units competing for limited IT resources. Often
prioritization is unduly influenced by the requestor’s rank or favors owed,
rather than logical coordination of strategically aligned activities.
As such undisciplined behaviors become the norm, the IT organization
is relegated to the role of order takers—a drive-through IT services window (although the typical fast-food drive-through yields higher customer
satisfaction scores). In the end, the IT organization just does what they’re
told, and the business forgoes the process perspective, insight, and leadership that IT professionals have to offer.
In other cases, when priorities aren’t clear, or are even contradictory,
IT is forced by looming deadlines to make important prioritization and
trade-off decisions by default, without clear business guidelines, and
everyone suffers the consequences.
* In this section we focus on the demand management. Later in this book we’ll explore related
issues, including requirements definition, project portfolio management, strategic alignment, and
governance. In Part 4, we’ll bring all these pieces together into a holistic approach for a Lean management system.

The result of this dysfunctional behavior is the haphazard alignment of
IT activities with business goals, and the squandering of IT resources and
investments. This all but guarantees dissatisfied customers, in both IT and
business, who see the chaos and learn to game the system to get what they
think they require, and hope the situation will somehow remedy itself. This
often leads customers to ask for more than they need, sooner than they
need it, in an attempt to compensate for unreliable and inconsistent delivery performance. Backlog sandbagging creates even more overload and lost
accountability, making matters even worse—and the cycle begins anew.
Such haggling and arm-twisting cause demoralization and loss of trust
within the ranks of IT and across the organization, reminiscent of the
old adage to just keep whipping the horse harder to make him run faster.
Ultimately the best people leave for greener pastures (or, worse, for medical reasons), perpetuating chronic IT underperformance.
Perhaps we’ve exaggerated a bit, painting an overly grim picture? But
then again, perhaps we haven’t. According to the CIO Magazine article “A
New Model for IT Demand Management,”
Demand management is clearly the missing link in most IT departments.
Far from being the rational and structured process we would like it to be,
[IT] demand management is usually a nebulous combination of decibel
management [whoever yells the loudest gets the attention] and organizational politics, significantly amplified in international organizations when
country politics and cultural differences are thrown into the mix.7

While some IT organizations have developed good demand management
practices, in our experience they are the exception, not the rule.
Only Three Choices When Demand Exceeds Capacity
Quite simply, the business faces three choices when its demand for IT services exceeds its capacity to deliver them:
1. Do nothing: The most common practice, no intentional action to
address the situation, is a de facto choice to live with the frustration and ineffectiveness, which continues to worsen over time. The
result is that projects are often prioritized by management edict or

IT default: while this may be expedient, ultimately command-andcontrol prioritization of IT activities does not yield optimal results.
2. Add capacity: This is costly, and not a viable long-term solution, often
creating a deepening cycle of waste and confusion that temporarily
masks the real problem.
3. Manage demand and balance capacity with a disciplined decisionmaking process: Clearly this is the only viable choice if an organization hopes to achieve IT operational excellence.
Most IT planning efforts focus on the supply side, emphasizing project
management, scheduling, problem escalation, and equipment and human
resources management. But without a deliberate focus on the demand
side (balancing prioritized demand with capacity), IT risks doing many
things efficiently, but not necessarily those things which deliver value to
the customer. IT proactively positions itself to take responsibility for a
backlog greater than its capacity, including projects that may not be strategically aligned.
The IT Demand Management Cycle
Senior managers are responsible for establishing management systems
that balance macro-level demand and supply, reducing systemic variability (muri)* and overburden (mura). In the world of manufacturing, a
methodology called Sales and Operations Planning (S&OP)† has evolved
to address this requirement in production operations. A similar approach
can be used to balance IT demand with available capacity. Illustrated in
Figure 5.4, demand management is a periodic, closed-loop feedback system that over time learns, adjusts, and becomes self-regulating.
Demand Planning

Using the traditional S&OP monthly cycle as a foundation, we will walk
through a suggested IT demand management process. We recommend
starting with a regular monthly cycle, standardizing and synchronizing
the pace of organizational decision making.
* Muri and mura are described in Chapter 2.
† See Sales & operations planning, The how to handbook, by Tom Wallace.

Push

Demand management feedback loop.

Figure 5.4

Matching prioritized
demand with available
capacity

1. Demand planning
2. Capacity planning
3. Balancing
4. Executive Review

Demand Management
Cycle
Pull

Delivery commitments based on
available capacity ﬂow in small
increments to the customer

IT Value Stream

IT Value Stream

IT Value Stream

IT Value Stream

Work Request Acknowledgement

Clear priorities aligned
with business objectives

Operations
Projects
Kaizen Participation

IT Backlog

Work Requests

Pull
Customers


During the first week of the month, the demand planning team gathers updated information on new demand, as well as changes to existing
demand: backlog and work in process, including newly discovered inprocess demand (e.g., scope additions, new challenges encountered, and
unplanned work). New demand includes new projects and services, and
changes to existing service-level agreements. It also includes unplanned
ongoing operational commitments for new systems (maintenance, support, upgrades, etc.) that were not accounted for in the original implementation project budgets—an unfortunate but common occurrence.
Unexpected changes to existing demand are investigated to spot trends
and emerging problems, identifying root causes of those problems, which
are used to improve the accuracy of the ongoing estimating and planning
process (PDCA).
Unlike supply chain organizations that have abundant transactional data
(customer orders, sales history, seasonality, and other trends) to support
their demand planning, IT relies largely on anticipated demand requested
by the business.* These requests are often informal and unstructured, and
thus unreliable. Demand planning is a collaborative process where service provider value stream and process owners meet with the internal and
external customer stakeholders that identify and prioritize demand for IT
activities. During this time, the business case is developed, demand identified, and the demand-planning process continuously improved.
Flow Simplifies Demand Planning

Lean flow naturally simplifies demand planning. When delivery cycles
become faster (approaching just-in-time), the planning horizon becomes
shorter. At a certain point, operations are based on what the customer
needs (pull signals) rather than what we (and they) think they might need
sometime in the future. This in turn extends an invitation for frequent
communication with the customer.
This interaction also creates an opportunity to modify the customers’ “buying habits” to create a more level, stable demand. For example, customers of Lean manufacturers are often motivated to submit
* With larger organizations, and those with complex demand and capacity scenarios, process and
software tools beyond spreadsheets (such as Project Portfolio Management software) may be necessary to facilitate the demand management process. However, this section will focus on the process, not the tools.

more frequent orders for smaller quantities, creating a level pace of
demand to the supplier, while reducing supply chain inventory. The
same approach applies to IT demand planning, whether in the iterative, synchronized steps of a software development project, or the
rapid execution of small, operational steps. When customers develop
confidence that they can request something important and receive it
soon afterward, they begin requesting changes in smaller increments
over a shorter time horizon, which makes their requirements more
precise. This creates a smooth flow of smaller work requests, which
can be managed by a level schedule.
Capacity Planning

During the second week of the month, IT department and project managers, and IT value stream owners, review the various IT project and value
stream loads to determine available capacity. When determining available
resource capacity, the question often arises about how to plan for ordinary
time commitments such as meetings, e-mail management, breaks, and
ongoing kaizen participation. The simplest approach is to allocate a percentage of total work time for such activities. Critical capacity constraints
should also be clearly identified and addressed.*
The distinction between value streams and IT projects is important:
1. Value streams are relatively permanent groups of resources, often
physically or virtually co-located, that perform similar ongoing
activities. For example, a value stream may support the processes
of a particular line of business, a domain of IT operations such as
security or communications, a specific software application, or
an enterprise application integration infrastructure. With dedicated value stream resources, the scheduling challenges of shared
resources are avoided. Teams are cross-trained and internally load
balance, enabling a stable pace of workflow. While the assignment of
resources to individual value streams usually results in an incremental increase in total enterprise resources, long ago Lean manufacturers discovered that this trade-off was worthwhile, since flow reduced
total operating costs, improved stability, quality, and productivity;
* See the Theory of Constraints.

and enabled agility. Since value streams are designed for flow, the
determination of capacity is relatively simple: the capacity of a value
stream is the processes’ maximum rate of flow, and (like demand)
can be measured in estimated hours, work units, or points (for discussion of points, see Chapter 8).*
2. IT projects are teams temporarily assembled for a specific event or
deliverable. Multiple simultaneous projects may share resources,
causing contention and scheduling challenges among them; shared
resources are a primary cause of flow interruption. The demand and
capacity balancing of IT projects can be chaotic, because of their
temporary nature, frequent scope changes, and resource sharing.
Capacity is calculated as the number of available work hours by skill
set, and tracking availability is challenging because scarce resources
often move unpredictably among multiple projects.
Balancing

During the third week of the month, all stakeholders representing IT
demand and capacity gather in a series of collaborative sessions to clarify
priorities, manage constraints, and identify trade-offs.
Because of the challenges of shared resources, large groups of IT project stakeholders must meet together, because changes in one project often
cause a ripple effect of compromises and trade-offs in others. This assumes
visibility across all projects—a key element of portfolio management (see
Chapter 9). On the other hand, the demand and capacity balancing sessions for dedicated IT value streams are more focused, and usually simpler
and faster. In fact, IT value stream teams often adopt daily standup meetings to maintain stable flow conditions, so current demand and capacity
are always known and more visible.
During balancing sessions, priorities are established, and the backlog
is updated. Note that there is a subtle but important difference between
prioritization and sequencing. Prioritization indicates the urgency of
the deliverable needed by the requestor. Sequencing of individual tasks
or elements is usually a production consideration, where a lower priority task might be completed first, because there is a dependency from a
* For an example of IT value stream organization, see the Con-way case study; and for an example
of IT demand and capacity planning, see the Group Health case study.

higher priority element. Demand management is concerned primarily
with prioritization of loading the backlog. Furthermore, backlogs must
be kept to a reasonable duration. Many organizations impose a finite
length, such as six months or one year. Requests that do not make the
backlog should not be kept on an informal back burner list to be slipped
into the backlog by sleight of hand. Resubmitted requests should pass
the same rigorous qualification process as new requests.
Summary materials are then prepared for the executive review session.
The strategic and financial impact of each issue is considered at this time.
When decisions requiring management authorization are needed (such as
significant investment for new resources, new equipment, or a new partner
relationship), alternative scenarios and recommendations are prepared for
the executive session. If consensus on a particular trade-off decision cannot be reached, then justifications and supporting information should be
prepared to inform an executive decision.
Executive Review

This brief (target two-hour) meeting should occur late in the third week
of each month, allowing the organization time to prepare for the following month’s activity. The meeting agenda should be standardized, concise,
and tightly facilitated. The root cause of any significant deviation from
the meeting agenda (often due to lack of preparation, unclear recommendations, or excessive detail) should be investigated and prevented from
recurring in future cycles (this is PDCA applied to effective meetings).
The executive review is much more than just a rubber-stamp session; it
may be the only time when non-IT executives get to look deep inside the
engine room to understand IT concerns and their impact on the enterprise. This monthly session aligns tactical operational IT activities with
strategic objectives. Information should be presented at a high level, but
assumptions and recommendations must be clearly documented, and
stakeholders should be prepared to instantly drill down to the underlying
details when requested. Meeting notes should be recorded, capturing firm
decisions and open issues (parking lot) to be investigated.
The monthly demand management cycle is a good example of a management system (explored in the next chapter), where management is accountable for standard, repeatable performance, creating an environment of
stability throughout the enterprise. In the dynamic world of IT demand

and capacity, fluid balance is maintained and communicated, continuously adjusting to new facts and circumstances.
As manufacturers learned years ago, once the monthly planning cycle
is functioning smoothly, the organization will evolve the discipline and
preparedness to call an ad hoc planning session if a serious situation suddenly arises. And because the demand management process is being rigorously practiced and continuously improved with each passing month, the
required effort decreases while the quality of the information improves,
supporting informed decision making and reinforcing the alignment and
agility of IT performance.

Lean IT Lessons Learned from the Shop Floor
Many simple but profound lessons have been learned from Lean manufacturing and applied effectively to other industries. The same guiding principles, tools, and systems have also proven effective to the IT organization.
Perhaps the highest accomplishment in Lean is to achieve value stream
flow. So here are our simple (but not necessarily easy) guidelines for creating Lean IT flow:
• Position and evolve each value stream toward your competitive sweet
spot; maintain a fluid balance between flexibility and efficiency in
every process and practice. Stay light on your feet; keep your focus
moving in the direction of competitive advantage as the market and
your competitors evolve.
• Strive for simplicity and stability in every process before investing in
electronic information systems: apply people, process, and technology—in that order.
• Listen to your customers often, and proactively manage demand to
support just-in-time operations
• Flow every process where you can. Keep a simple line of sight (physical or virtual) along the entire length of every value stream and
supporting process, so they become self-regulating, leveraging the
creativity and problem-solving capability of every participant.


Endnotes

1. Christopher Koch, “Nike rebounds: How (and why) Nike recovered from its supply
chain disaster,” CIO Magazine, June 2004, www.cio.com/article/32334/.
2. Steven Castellanos, interview, February 14, 2010.
3. Jennifer Zaino, “The Tesco directive: Standardize and innovate: Smart IT decisions
help the retail giant’s operations run Lean,” SmartEnterprise 3, no. 2 (2009): www.
smartenterprisemag.com/showArticle.jhtml?articleID=217701399.
4. George Plossl, Orlicky’s material requirements planning, 2nd ed. (New York: McGrawHill, 1995), 7.
5. Robert H. Hayes and Steven C. Wheelwright, “Link manufacturing process and product lifecycles,” Harvard Business Review (January–February 1979): 133–140.
6. Naida Grunden, The Pittsburgh way to efficient healthcare (New York: Productivity
Press, 2008).
7. Michael Gentle, “A new model for IT demand management,” CIO Magazine, October
9, 2007, www.cio.com.au/article/196728/.

6
Lean Management Systems

Chapter Objectives
In this chapter we will explore the following elements of a Lean management system that are typically supported by IT shared services and discuss
how a Lean IT approach can make them more effective:
•
•
•
•
•

Communication
Knowledge management and collaboration
Performance measurement and business intelligence
Strategy deployment
Lean accounting

So much of what we call management consists of making it difficult for
people to work.
—Peter Drucker

Most Lean transformation efforts are unable to sustain themselves
over time as organizations lose momentum and regress to familiar,
wasteful behaviors. This failure is often attributed to abstract notions
such as “lack of leadership support” or the “inability to create a Lean
culture.” While these explanations may sound plausible, what exactly do
they mean, and more importantly, how can we avoid falling into these
common traps?
121

While localized, short-term gains are often achieved with the initial,
enthusiastic application of Lean tools, lasting change requires the transformation of collective behavior—which happens neither quickly nor by
accident. This points to the need for effective and deliberate management
systems to spread, guide, and sustain change throughout all levels of the
organization—aligning daily work with strategy.
In Creating a Lean Culture, organizational psychologist David
Mann suggests that as an organization changes the way work is done,
it must also fundamentally change the way it manages that work. He
describes the behaviors necessary to create an effective Lean management system:1
• Leader standard work: Explicit, interlocking managerial tasks ensure
continual focus on the process, as well as the outcomes
• Visual controls: The performance of processes is visually apparent at
all times, immediately calling attention to abnormalities
• Daily accountability: Brief, structured meetings focus on performance, with follow-ups to close gaps between actual results and
expected performance
• Discipline: Consistent behavior reinforces good work habits and process stability, establishing a culture of quality and accountability
The success of a Lean management system relies on collaboration and
the smooth flow of quality information. The ideal information system is a
manual one, where the information is experiential: visible, accurate, and
meaningful—clearly tied to immediate actions and consequences. In such
an environment, participants intuitively understand the situation and are
able to solve their own problems.
But in most modern organizations, value streams cross many boundaries—departments, workgroups, project teams, functional silos, buildings, time zones, and countries. The span of managerial responsibility
is also great, so face-to-face interaction and hands-on information are
usually not sufficient for an enterprise-wide Lean management system.
Microsoft’s Bill Gates chose the phrase digital nervous system to describe
the role of a distributed business information system. Similar to the function of a biological nervous system, a digital nervous system provides a
constant flow of feedback essential to the organization’s survival:

Lean Management Systems • 123
You always are alert to the most important things, and you block out the
information that’s not important. And companies really need to have that
same kind of thing: the information that’s valuable getting to the people
who need to know about it.2

Clearly, a well-designed framework of shared information system services is necessary to enable an effective Lean management system. It is difficult to imagine getting a day’s work done without e-mail, shared drives,
collaborative workspaces, and reporting and analysis tools. But each of
these alluring “productivity-enhancing” tools can also potentially distract
our focus, causing us to mistake activity for productivity.

Communication
Few will argue that e-mail and meetings are out of control in many
organizations. Office workers often report a large part of each day is spent
wading through e-mail or trapped in ineffective meetings, diverted from
their value-adding work.
When does e-mail add value? The answer to this question in part depends
on the nature of the work each individual performs. The further people are
removed from the hands-on operational activity of the business, the less
structured work and communications they perform. So we should expect
a larger part of managers’ and executives’ daily activity to include communications by e-mail, phone, and meetings.
Furthermore, organizations on the Lean journey usually experience more
cross-functional interaction as they practice systems thinking, breaking
down organizational silos and concentrating on value streams. This naturally causes additional email traffic and increased meeting frequency.
While such less-structured communications are important, excessive
or inappropriate e-mail traffic, endless conference calls, and back-to-back
meetings leaving no time for reflection or follow-up can cause significant
waste. These wastes include waiting (high-value-added work is delayed
because the person is distracted by low-value activities), unused human
potential (frequent e-mail and instant messaging interruptions sap creativity and energy), and overprocessing (reading the same e-mail thread
multiple times before acting on the situation, or attending redundant,
unproductive meetings).

Worse yet, when individuals become habituated to these distractions
and interruptions, they may lose a sense of cadence and flow with their
standard work. They may also fail to recognize subtle process exceptions
and problems, missing valuable opportunities for process improvement.
So e-mail, instant messaging, social networking, and other forms of
unstructured communications should be scrutinized with the same criteria of waste, value, and standardization as any other business activity.
Much has been written about how to conduct effective meetings, yet
poorly run meetings remain a chronic time-waster in many organizations.
When standard work is effectively practiced, and meetings are properly
facilitated, group interactions become more purposeful and structured;
many unnecessary meetings are eliminated, while those that remain
become more productive. Particularly effective are standup meetings,
where a team gathers (physically or virtually) around visual status boards
for a brief daily meeting or to focus on a sudden problem.
Concerned with reducing the time, cost, and environmental impact of
unnecessary travel, many organizations are investing in remote-meeting
capabilities. At the same time, organizations must also learn how to manage these meetings properly. How many of us have mentally checked out,
distracted by e-mail or other interruptions, during a poorly facilitated or
uninteresting electronic meeting or webcast? Remote meetings require
discipline and engaged participation, supported by standard work or else
they too can become monumental time wasters.

Knowledge Management and Collaboration
In a learning organization, the whole of knowledge gained through dialogue and problem solving is greater than the sum of the contributions
from individual team members. Learning is therefore both a technical and
a social process. In The Fifth Discipline, Peter Senge describes knowledge
as a natural result of human interactions:
Knowledge is social. Collaboration is the flip side of knowledge management. So, to manage knowledge you need to address collaboration and
tools that help people collaborate.3

Knowledge management and collaboration systems offer many opportunities for individuals and teams to virtually gather and share knowledge across an enterprise and beyond. But their flexibility also threatens to
spread information chaos and waste. Unless an organization deliberately
establishes a discipline of workplace organization and standard work, electronic document waste can threaten the value and security of an organization’s intellectual assets.
A great deal of structured information exists in databases, used by applications to automate business processes; however, this represents only a small
fraction of the overall knowledge of the organization. A much greater
amount is stored as unstructured repositories of documents (spreadsheets,
text, diagrams, photos, videos, etc.) scattered throughout an organization’s hard drives. But the majority of knowledge (80 percent, according to
a 2002 study)* is stored deep inside people’s heads.
Baby boomers will soon retire, threatening to take much of their knowledge with them. This knowledge (undocumented procedures and insights)
must be captured and standardized, or else the intellectual capital and
competitive advantage of many organizations will be at risk. This loss of
knowledge is especially serious when the work involves more practice than
process (see Chapter 4).
Harnessing collective knowledge is an extension of the empowerment
that personal computers first brought to knowledge workers, and there
is a historical parallel here worth considering. In the late 1980s, personal
computers became increasingly powerful and software more capable—
perhaps some readers remember the impact of Lotus 1-2-3, WordPerfect,
and Novell networks? During the 1990s departmental networks and client/server systems proliferated, displacing (and often duplicating) the
functions of centralized mainframe and minicomputer systems. This
unplanned and ungoverned information expansion and accessibility created endless challenges for IT managers.
In much the same way, abundant departmental shared drives, web-based
repositories, and social networking systems are a double-edged sword.
* This study was prepared by the Giga Information Group, which was later acquired by Forrester
Research.

On the one hand, they enable individuals and teams to take ownership
of information, gathering and sharing knowledge quickly and easily. But
on the other hand, they often violate standards for security, data quality,
version control, change management, and compliance. To IT managers
who experienced the dawning of the personal computer age, this tension
between flexibility and control may seem familiar.
In the years since the study illustrated in Figure 6.1, many organizations
have implemented document and content management systems, attempting to store and access shared information quickly and securely. Yet these
efforts are not always successful, often because of the lack of standard
work and discipline; many document repositories have become sophisticated junk drawers . . . with unlimited capacity.
Experts estimated that in 2008 an additional 487 exabytes of data were
created in the “digital universe”—an exabyte is a million billion megabytes.
They also predict that, with the growing popularity of various forms of
digital content, in 2012 five times as much digital information will be created.4 The content management challenge has suddenly become much
more complex. With the rapid evolution of social networking capabilities—blogs, wikis, online videos, and whatever is coming next—more of
what was once inside our heads is quickly becoming universally accessible
information. We see IT organizations investing heavily in these areas—
but their resources are often exhausted simply by chasing these rapidly
evolving technologies, rather than proactively managing them.
Knowledge in
People’s Heads

80%

Unstructured
Data

Structured
Data

16%

4%

80% of the IT budget is usually invested here
Figure 6.1

Composition of organizational knowledge.

On the one hand, organizations should leverage the creative power that
these new technologies offer. But on the other hand, security, risk, and
other basic governance concerns must be addressed. There is no simple
answer to this challenge, but Lean offers an approach to restore order from
the mounting chaos.
In our experience, the 5S method of workplace organization can be
effectively applied to knowledge management. Given time, coaching, and
specific guidelines (policies that must be adhered to), teams will develop
creative approaches to managing knowledge—and then they will make
them stick, because they own the solution. Most importantly, by focusing
on the fourth and fifth S, standardize and sustain, teams themselves (not
just by management edict but also through peer pressure, motivated by a
sincere desire to improve) will enforce standard work to ensure everyone
follows the mutually agreed upon rules.* And the teams will innovate and
adapt to the continuously changing technology landscape.
Collaborative Workspaces
Collaborative workspaces offer a group of virtually co-located individuals the ability to share knowledge and maintain visual awareness of
project status. Like the traditional project “war room” (also known in
Lean as the obeya room, see Chapter 9), a virtual collaborative workspace helps distributed teams work in unison, tightly coupling learning
with action.
Simple implementations of collaborative workspaces provide capabilities such as document management, communications, reports, task lists,
and portals linking to external sites and content. Sophisticated implementations may include group calendars and scheduling, project and
resource management, automated status alerts, dashboards, and scorecards. When the team includes members outside the organization, special consideration should be given to security and intellectual property
protection.
We often see a special form of collaborative workspace dedicated
to Lean transformation. Lean is truly a team sport, and at the core of
the team are the internal facilitators who support the Lean Center of
Excellence (CoE)—those employees who coach and facilitate kaizen
* For more on 5S, see Chapter 2, and also the Con-way Virtual 5S case study.


The Evolution of a Lean Intranet Site
One client describes their journey:
“Lean learning is a lifetime journey, and nearly everyone takes a
unique path, making for a rich web of knowledge exchange, materials and information. Our organization employees over 30,000 people
in over 30 countries, including 400 lean coaches who actively facilitate the transformation. Because of our global size and reach, we recognized the need early on to create a commonly shared intranet site
to eliminate waste from the learning and knowledge management
process.
“Our first release was based on a simple intranet site targeting support just for our lean ‘pioneers’, the early adopters who were experimenting and learning at a fast pace. Our transformation was moving
so quickly that six months later we began the development of the
next generation, a more complete site targeting a broader audience.
The front page promotes the lean program with examples of kaizen
activity and the benefits realized, while the rest of the site provides an
events calendar, kaizen report-out summaries, and a document repository for sharing best practices.
“We are now planning the third generation site, a portal design that
will allow us to incorporate higher levels of engagement, knowledge
sharing and connectivity through social networking tools, blogging,
and video streaming. Of course, the more features we implement the
more improvements we discover are needed to support our customers.
“We began measuring site performance with a target around number of visitors each week. We are currently reaching an average of
nearly 700 visitors per week, with 70 new visitors a week on average.
On weeks when we run lean promotions we approach 1,500 visitors
per week and we have an end of year target of 2,000. This measure
has helped us to drive focus into our improvement efforts, identifying
problems quickly to better understand what works and what does not.
We are now exploring a metric connected to purpose, proficiency and
how people use the site to create value for the company.
“So far we’ve seen many benefits from this site, as our lean program has expanded worldwide:


• Our measures indicate a growing number of people in all areas
looking for ways to engage and learn.
• Best practices are being shared across our businesses and
regions at a faster pace.
• Learning materials are centralized and standardized, enabling
our knowledge base to grow quickly and efficiently.
• Everyone shares their accomplishments, spreading knowledge
and enthusiasm, creating a sense of pride and ownership.
• Shared learning is helping to redefine our cultural DNA: who
we are as an organization and how we work.”
activity throughout the organization. In our experience, the most effective facilitators come from the trenches, since they have a deep understanding of the organization and its customers, business processes,
problems, and culture.
Developing a CoE and a team of internal facilitators requires a significant investment in training, coaching, and experiential learning over time.
What better opportunity could there be to create an online community
for sharing knowledge? In fact, many organizations invest in a collaborative site for this purpose, with information, contact lists, schedules, lessons
learned, training, articles, links, online videos, book reviews, templates,
and more.
IT Service Desk (Help Desk)
Service desk is an often underappreciated job, the Rodney Dangerfield
of the IT world—they don’t get much respect. However, an effective IT
customer service function* can provide a leading indicator of emerging trouble throughout the company—the canary in the IT coal mine.
In fact, the service desk can become a fertile source of improvement
ideas. With effective teamwork and mentoring, the service desk can
also be an effective onramp for new IT employees, where they can
learn the inner workings of the organization, and its people, teams,
and processes.
* See Chapter 7 for more on IT service desk operations, ITIL, and continuous improvement, and
Appendix D for an example of an A3 for improving service desk performance.

The service desk is a knowledge hub—continuously processing new
technical information from vendors as products are released and updated,
disseminating information to help individuals troubleshoot (and hopefully prevent) problems, while gathering new information during each
call. Effective management of a support knowledge base, and the ability
to provide self-service access to this knowledge, can improve service desk
performance and end user satisfaction.
In one service desk 5S kaizen event we facilitated, over 30 percent of
the documents in the support knowledge base were found to be obsolete,
and many more lacked standard search keywords. In some cases, because
documents were hard to find, duplicate documents had been created, often
with conflicting information. Since knowledge wasn’t shared evenly, pockets of specialized resources evolved, leading to silos of technical support
and dependencies on particular individuals.
As a result of the kaizen, within just a few weeks the number of documents in the knowledge base was reduced by 20 percent. Standard work
ensured that documents were properly stored, easily located, and regularly updated. During this short time, successful search results increased
by nearly 50 percent, dramatically improving first-call problem resolution. Mentoring and cross-training were also instituted, helping to spread
knowledge and avoid overspecialization. Best of all, the improvements to
the existing processes and system proved that a new and expensive service
desk application was not needed.
Education and Training
eLearning utilizes the rich capabilities of the Internet to provide a standardized education and training experience to a large number of individuals.
eLearning can be as simple as individual online sessions delivered on demand,
or as sophisticated as live facilitated online classes, with links to research and
reading material, collaborative exercises, and interactive discussion forums.
eLearning can also provide online testing and assessment, with the ability to
track individual learning activity and performance—identifying individual
strengths to be leveraged and weaknesses to be addressed.
Digital video cameras now appear regularly during gemba walks and
kaizen report outs, recording events to be used for educational purposes.
The ease and low cost of publishing online video provides a new vehicle to record and share standard work instructions, simply by asking an

experienced worker to demonstrate and describe a procedure. In this way,
short, interactive, task-specific training sessions are available to individuals online when performing a task that requires demonstration.
In general, eLearning can significantly reduce travel and other training
costs, while capturing and sharing a significant amount of useful information that can be reused and easily updated when necessary. However, we have
also seen many online learning sessions where attendees become distracted by
e-mail and other interruptions, so discipline and standard work are important.
Even though content can be delivered electronically, there is often still value in
bringing people together in a physical classroom setting for hands-on training
and exercises. Interaction and shared storytelling can make the learning far
more experiential and relevant, while developing a sense of teamwork.

Performance Measurement
A sound performance measurement strategy is a critical foundation for successful and sustaining continuous improvement. Standardized work creates
a stable process baseline for improvement, then measurements provide constant feedback on how well those standards are performing, helping teams
determine where best to focus the next round of improvement activity.
A well-designed measurement system is also essential for an effective
Lean management system. According to David Mann, “Unlike managing
in a results-focused system, process focus implies frequent measurement
against expected intermediate outcomes. As necessary, interventions can
be started before the end results are affected.”5
In order to respond quickly when corrective intervention is needed, feedback should be immediate and visual. Consider the difference between
push and pull performance measurement. Push performance measurement
involves periodic reports that may identify problems some time after they have
occurred. Pull is immediate, event-driven, exception-based feedback, allowing individuals to focus their attention on the problem at hand.* The faster
* One example is the automated publish-subscribe method of asynchronous messaging, which prevents broadcasting unwanted information. Users subscribe to a particular topic, and the system
publishes information on that specific subject whenever an important event occurs, in various
formats such as e-mail alerts and exception reports. This is pull, where the user asks the information system to “send me what I need to know the moment it happens.”

an abnormality is detected, the sooner preventative action can be taken—or,
if damage has already occurred, it can be quickly contained and mitigated.
And the sooner a team investigates after a problem occurs, the better their
chances of detecting the root cause and so preventing its recurrence.
According to Steven Spear in Chasing the Rabbit, organizations learn
to solve problems and build knowledge by signaling, swarming, solving,
and sharing what they have learned. First, a problem should signal for
attention, then teams quickly swarm and solve it, sharing what they have
learned with others. According to Spear,
Swarming a problem is not only beneficial in terms of what is prevented—
an infectious spread of the problem’s impact. It is beneficial in terms of
what is allowed—the gathering of essential, contextual information that
would otherwise be lost to fading memory and changing circumstances.
High velocity organizations insist that the “scientific method” be used in
a disciplined fashion. High velocity organizations multiply the power of
their new knowledge by making it available, not only to those who discovered it, but also throughout the organization.6

There are many ways to share information in an organization, and they do
not necessarily require technology. For example, in a well-designed work environment, problems should call attention to themselves visually. According
to Gwendolyn Galsworth, author of Visual Workplace, Visual Thinking,7 the
walls, floors, fixtures, and other physical surroundings in an office or factory
are often underutilized—“mute.” But they offer great potential to enable flow
and pull, preventing errors, while visually signaling for assistance when an
exception, error, or defect occurs.* Process line of sight allows all participants
to immediately sense (see, hear, or feel) an interruption of flow.
When processes are transactional, spread over long distances and
time frames, and events are electronic, computers can sift through large
volumes of data, looking for abnormalities or trends indicating a potential arising abnormality. This can be achieved with common business
intelligence tools such as database alerts and after-the-fact exception
reporting, and through more sophisticated techniques such as realtime performance monitoring, data mining, and predictive analytics.
* Exceptions are process abnormalities that do not necessarily cause errors but their root cause
should be investigated for their impact on standard work; errors are mistakes that do not necessarily cause defects; and defects are flaws in the work product that must be corrected before they are
passed downstream to the customer.

In this way, computers can generate highly effective, proactive leading
indicators of emerging issues, signaling workers and managers where
attention is needed so they can swarm the problem for preventative and
corrective action. This creates a virtual line of sight, where participants
have constant visibility to the entire process. For measurements to add
value they must lead to effective action: teams must understand what
they’re measuring, how they’re measuring it, and how frequently, how
status will be communicated (visual is preferred), and how they will
respond to deviations.
Lean Business Intelligence
The IT world offers many sophisticated and fascinating business intelligence tools: dashboards, scorecards,* statistical analyses, data mining,
predictive analytics, visualization, and more. And enterprise databases are
overflowing with potentially useful information. From a Lean perspective,
a simple business intelligence approach used effectively is far better than a
sophisticated tool used improperly.
For example, accuracy and timeliness are more important than precision. In fact, data can be extremely precise (e.g., to six decimal places),
supported by sophisticated analyses and visuals. Yet it can be inaccurate, untimely, and irrelevant, giving a false sense of significance to the
viewer.
In Performance Dashboards: Measuring, Monitoring and Managing Your
Business,9 Wayne Eckerson describes three levels of performance measurement dashboards (shown in Figure 6.2) that work together to support
a healthy environment for continuous improvement.
Operational dashboards: Monitor operational activity, often in real
time. This is virtual gemba, providing process line of sight.†
* Dashboards and scorecards are both visual measurement and feedback systems. The two terms
are often used interchangeably, although dashboards provide immediate performance feedback in
near real time, whereas scorecards display trends and progress toward goals over time. Dashboard
and scorecard views can be mixed in the same user interface, further blurring their distinction.
† It’s important to remember that virtual gemba should ultimately lead to actual gemba, since no
software can replace human interaction. For example, we recently heard a doctor say, “I hope
somebody does a study of the quality of interaction when electronic medical records are introduced. The nurses and doctors tend to have more eye contact and interaction with the computer
screen than with the patient.”


Purpose
Users
Scope
Information
Updates
Emphasis

Operational
Monitor operations
Supervisors,
specialists
Operational
Detailed
Intra-day
Monitoring

Tactical
Measure progress
Managers, analysts
Departmental
Detailed/summary
Daily/weekly
Analysis

Strategic
Execute strategy
Executives, managers,
staff
Enterprise
Detailed/summary
Monthly/quarterly
Management

Figure 6.2

Three levels of performance dashboards and scorecards.8*
* In this table, tactical scope indicates a departmental focus. From a lean perspective, this should be
expanded to include a cross-functional value stream and supporting process perspective.

Automated alerts notify individuals to conditions that may indicate an emerging problem or condition requiring immediate
attention. Operational dashboards often use visual displays (dials,
thermometers, flashing lights, etc.) to display status, and are
typically in plain view using electronic signboards, kiosks, wireless devices, and even electronic andons (e.g., lights or sounds)
to attract attention. High-level indicators are often able to drill
down, displaying additional detailed data as needed to assist in
problem solving.
Tactical dashboards and scorecards: Provide managerial views of operational processes, projects, and kaizen activity. They typically identify
exceptions and provide analysis capabilities—both simple self-service analytics, as well as sophisticated tools for specialized analyses
(e.g., forecasting, modeling, and predictive statistics). For example,
overall equipment effectiveness (OEE) measures are a good application for tactical dashboards, since they summarize volumes of operational data helpful for total productive maintenance (TPM) activities.*
Visual project and process status indicators can significantly reduce
interruptions by supervisors and managers. And, as many managers
are always on the move, these systems are often capable of sending
alerts and visuals to smartphones and other handheld devices.
* OEE is a set of metrics used to measure availability, performance, and quality of a tool or process;
TPM is a preventative maintenance program where the operator or team is responsible to monitor
and care for their equipment.

Strategic scorecards: Provide consolidated views of underlying measures
to track progress against strategic objectives, and key performance
indicators (KPIs) to monitor important enterprise-level processes.
Executive scorecards often employ balanced scorecard and strategy
deployment methodologies (more on Strategy Deployment later in
this chapter).
The three integrated levels of performance measurement (operational,
tactical, and strategic) create a tiered, interlocking structure necessary
for linkage and alignment of a Lean management system. A well-crafted
performance measurement system provides custom alerts and self-service
access, so an executive, manager, supervisor, or associate can monitor
areas of interest and drilldown to more detail as needed. But these sophisticated systems should not replace going to gemba—where the work is performed, managing by walking around—“go look, go see, ask why.”
IT organizational involvement in deploying a performance measurement system becomes especially important in multisite situations, and
particularly when each site uses different operational information systems.
In such a case, IT participants must be intimately involved in understanding the processes and data structures of each site and the systems they use,
so a centralized, integrated, coherent set of consolidated information can
be presented.
Companies that invest in sophisticated business intelligence (BI) systems at first often deploy more metrics than necessary, over time reducing
the number until they arrive at a limited set of KPIs that can be used to
effectively guide decisions and identify exceptions. This excess is wasteful and distracting, and can limit the acceptance and eventual utility of
the BI system investment. Organizations beginning the journey to integrated business intelligence should move slowly and carefully, identifying information requirements as they go and designing new reports based
on their immediate usefulness for process monitoring and improvement,
rather than on a desire to utilize the tools in order to justify the technology
investment.
Rapid Acquisition and Integration
Our discussion on performance management naturally leads to the brief
mention of a related topic, the merging of several companies into a single

Lean enterprise. Naturally, the acquiring and acquired companies seek
to quickly and efficiently assimilate and share their collective knowledge
and best practices. Ideally, when this synthesis is achieved, the value of the
combined entity is greater than its individual parts while the individual
distinction and competitive advantage of each entity are preserved.
The lessons of Lean are useful here. Standardized work may be applied
to the technical integration process itself, with templates, checklists, and
the use of data integration and business intelligence tools that can unite
diverse enterprise software systems into consolidated financial and operational views. Standardized work may also be applied to the normalization of business processes, management systems, and information systems
(processes, data structures, reporting and analysis, and knowledge management) across consolidated entities.
A good example of this approach is Danaher Corporation, whose legendary success with rapid acquisition and integration is in part due to
a disciplined focus on IT standardized work. Using business intelligence
and data integration tools, and providing templates, checklists, and a predefined framework for rollup and reporting of operational and financial
data with their global enterprise resource planning (ERP) system, within
30 days of a new acquisition Danaher often achieves a consolidated view
of customers, operations, and financials. Their standard approach also
encourages the rapid assimilation of the Danaher Business System best
practices within the acquired company, while allowing a degree of continued local autonomy.
It has been said that the greatest synergy of a business combination is
either realized or lost within the first six months. If this is so, then a rapid
and standardized (Lean) approach to IT and business process integration
drives significant value and competitive advantage for the entire enterprise.

Strategy Deployment
A Lean enterprise continuously strives to align itself, engaging in systems
thinking, reaching beyond localized improvements to achieve a holistic
and sustaining transformation. Peter Senge stresses that “empowering the
individual when there is a relatively low level of alignment worsens the
chaos and makes managing the team even more difficult.”10 Once aligned,

the energy of chaos is converted into synergy, and the organization is able
to direct its activities toward shared goals.
There are two dimensions of alignment: vertical and horizontal.
Vertical alignment: Ensures all stakeholders from the board room to
operations, through the layers of management interaction, goal setting, and review, can trace their activities and objectives back to the
strategic goals of the company.
Horizontal alignment: Ensures that cross-functional stakeholders of
each value stream, supporting process, project, and kaizen, share
common objectives, making appropriate prioritization and resource
allocation decisions that add value to the customer.
In a Lean enterprise, alignment is shaped and guided through the practice of strategy deployment (also known as hoshin kanri). Strategy deployment emerged in Japan in the 1950s and has continued evolving to this day.
In Value Stream Management: Strategy and Excellence in the Supply Chain,
coauthor Dan Jones (who also coauthored The Machine That Changed
the World and Lean Thinking)11 and other researchers at Cardiff’s Lean
Enterprise Research Centre identified strategy deployment as the first of
four pillars behind high-performance supply chain organizations. The second pillar, the formalization of cross-functional management, is the organizational structure through which strategy deployment is executed.
Strategy deployment is often overlooked as organizations plan their Lean
transformation. This is in part, explain Jones et al., because “of all the Japanese
management techniques, the [strategy] deployment system is the most
‘invisible’ within the factory and less easy to distinguish or emulate than those
‘visible’ elements of the Japanese production systems such as kanban.”12
Those techniques that are easier to identify and emulate are usually
tactical, not strategic, in nature. Strategy deployment begins with a set
of specific objectives to support the strategic direction of the organization. Strategy deployment drives kaikaku, or breakthrough improvement
(described in Chapter 2), throughout the enterprise and guides the many
incremental kaizen priority decisions made each day.
An iterative communications process known as catchball (Figure 6.3)
cascades through successive levels of the organization, guiding improvement efforts and resource assignments to achieve vertically and horizontally aligned targets which support the overall strategic objectives. These

Plan

Act

Do
Ca
tch

Check

ba

Plan
ll

Act

Do

Strategic
Long term strategy
Midterm strategy
Kaikaku (breakthrough
improvement)
Annual hoshin plan

Check
Tactical

Value streams
Divisions
Business units
Departments

Ca
tch

ba

P

ll

A

D
C

Operational
Supporting processes
Projects
Kaizen (continuous
improvement)

Figure 6.3

The strategy deployment management system.

catchball discussions center on the A3, which helps focus thinking and
clarify communications.
Regular meetings at each level establish a steady cadence of interaction
and feedback, essential to leader standard work and daily accountability.
Teams then assess cause-and-effect relationships and develop appropriate
countermeasures and action plans to achieve established targets. In addition to the regular pace of standard meetings, ad hoc dialogue occurs spontaneously whenever a problem is identified that requires managerial input.
At the operational level of the strategy deployment hierarchy, a team or
individual is able to clearly relate how their actions and initiatives support
the strategic goals of the organization. Strategy deployment thus provides
an internal governance mechanism, guiding priorities so resources are consistently targeted across every level and dimension of the organization.
Strategy deployment decentralizes decision making, shifting problem
solving from traditional functional heads to teams that are closer to the

work and to the customer. Strategy deployment in particular, and a Lean
management system in general, empowers all departments, teams, and
individuals to make fact-based decisions in support of strategic goals, and
to understand their purpose and contribution to overall success.
By now, you may have noticed the similarity between the levels of the
strategy deployment management system and the levels of performance
measurement scorecards and dashboards: operational, tactical, and strategic. To be effective, each level of strategy deployment management must
be supported by effective measurement. The strategy deployment management system and the tiered performance measurement system should
evolve in parallel so they are intuitive and mutually reinforcing.
The Role of Information Systems in Strategy Deployment
Strategy deployment relies on a set of cascading A3 documents, along
with supporting documents (text, photos, and other artifacts) data, and
measurements. In time, computer assistance (while carefully avoiding
unnecessary complexity or overautomation) may be necessary to provide
a strategy deployment infrastructure. Specific reasons for this investment
may include:
• Geography: If the planning process spans large distances, a webbased system can facilitate access.
• Change control: The system can prevent changes to targets, history,
baselines, and other control data while recording changes made to
dynamic information over time.
• Security: Sensitive information can be controlled.
• Data types: Electronic A3 documents are often implemented with
spreadsheet-style user interfaces, providing the user with familiar
functions, including text, tables, calculations, and graphics.
• Standardization: User-friendly templates and instructional tools
facilitate iterative and cascading communications, data-gathering,
problem-solving, reporting, and decision-making processes.
• Scalability: Organizations often begin with spreadsheet-enabled
A3s in a document repository offering version control and security, moving to website and database-enabled applications later as
the sophistication and scale of the strategy deployment process
evolve.

We are not suggesting that a strategy deployment system must be
deployed using sophisticated software. In fact, strategy deployment should
first be implemented manually, in a pilot mode, to ensure the process and
framework suit the requirements and culture of the organization.
However, the potential benefits of technology should not be overlooked,
as an organization strives to establish the foundation of a Lean management system that will help to align and sustain enterprise-wide continuous improvement. To that end, we direct you to the Toyota case study later
in this book, where you will learn why this Lean pioneer chose to automate
their hoshin kanri management system, the lessons they learned along the
way, and the benefits they have realized.

Measuring Value: Lean Accounting
It was not enough to chase out the cost accountants from the plants. The
problem was to chase cost accounting from my people’s minds.
—Taiichi Ohno

Now that we’ve explored the role that information, information systems,
and the IT organization play in a Lean management system, we conclude
this chapter with a brief exploration of why financial decisions are often
misinformed—and what we can do to change this.
To frame this discussion, let’s briefly explore an important, yet often
misunderstood, discipline: Lean accounting.* Why is this subject so
important? If you’ve eliminated waste, reduced inventory, cut cycle times,
and increased throughput by applying Lean, but have not changed your
accounting views or thought processes, you may be running your business
with potentially misleading information and burdening operations with
wasteful data collection.
Standard cost thinking does not compel Lean behavior; Lean accounting reflects operational and cash flow reality. If the fundamentals of Lean
accounting are not clearly understood, the CEO, CFO, and shareholders
can quickly kill a Lean transformation, just as it is beginning to take hold.
* Our focus here is on accounting for Lean results, not applying Lean techniques to improve the
efficiency of accounting operations (accounting for Lean, not Lean for accounting).

In a manufacturing environment this is because Lean accounting causes a
sudden shift of previously absorbed overhead expenses (contained within
inventory stockpiles) from the balance sheet to the income statement.
Similarly, using standard cost-accounting assumptions in an IT environment, decision makers can also make misinformed decisions on many important issues, including IT investments and the provisioning of IT services. This
is because traditional indirect cost allocation and chargeback practices often
obscure the true cost, value, and capacity of IT shared services.
Standard cost-accounting practices are not only misleading but potentially counterproductive. According to Brian Maskell and Bruce Baggaley,
authors of Practical Lean Accounting:
Traditional accounting, control and measurement systems … motivate
people to use non-Lean procedures. Traditional systems are wasteful.
Standard costs can harm Lean companies because they are based on premises grounded in mass production methods. The methods are complex and
confusing to generate, they provide a misleading understanding of cost,
and they lead to wrong management decisions on important issues, such as
make/buy, profitability of sales orders, rationalization of products or customers, and so forth.13

Traditional standard cost accounting captures many transactions in
order to allocate costs to specific products and services—these unnecessary transactions themselves are information waste (Figure 6.4).
Furthermore, the allocation of indirect costs distorts financial information. In Real Numbers, authors Cunningham, Fiume, and Adams explain
the fallacy of traditional cost accounting: “Many companies have armies
of cost accountants poring over variance reports after month end, trying to determine their reason for variances. The problem is … it is virtually impossible to trace an unfavorable variance to its root cause. The role
of cost control in a Lean environment is to reduce cost by eliminating
waste.”14
Many individuals, teams, and departments invest their valuable time
and energy chasing abstract concepts such as labor efficiency, cost allocations, and variances, distracting attention from the focus of Lean:
proactive waste reduction and value creation. Carefully monitoring and
regularly measuring activities (inputs and their direct outcomes) helps
everyone do things a little better each day.


Focus

Lean
Value stream performance
against strategic objectives

Costing

“Real numbers” — direct costs
summarized by value streams

Profit drivers

Profit comes from optimizing
flow and value to the
customer, excess capacity
provides flexibility
Unnecessary transactions are
wasteful

Transactions

Control

Processes are simple and visual
so they are self-regulating

Performance
reporting

Box score: single page value
stream summary showing
relevant cash-basis financial
and operational metrics,
capacity utilization, and
non-value activity to aid
decision-making

Traditional
Organizational performance,
department reports to compare
budget to actual
Allocated indirect costs, standard
costs that absorb overhead,
variance analyses attempt to drive
corrective action and process
change
Profit comes from full utilization of
resources, excess capacity is bad

Detailed transactions are often
captured simply to drive cost
allocations
External financial, operational, and
audit controls are essential for
governance
Commonly financially oriented,
based on cost accounting
assumptions; these are difficult for
non-accountants to understand,
and of limited use in daily
problem solving and prevention

Figure 6.4

Comparing Lean and traditional accounting.

At the heart of Lean accounting is value stream costing, where there is
no allocation of overhead (indirect costs) to activities. Shared costs (such
as indirect labor, rent, utilities, and IT shared services) are treated as direct
costs of multiple value streams only when they can be easily identified and
tracked (e.g., the direct, variable costs of an application used only for certain
product or service lines). This results in simple financial information that
can be clearly understood to support sound business decisions consistent
with Lean.
Lean accounting reinforces a culture of accountability, emphasizing the
overall performance of the value stream and not the optimization of any
particular asset or activity within it. Simple measures and reports provide
information that is easy to understand, relevant, and actionable, helping

individuals and teams at every level of the organization to make sound
daily decisions that drive Lean results.

Focus on Creating Value, Not Cost Reduction
Not everything that counts can be counted, and not everything that can be
counted counts.
—Albert Einstein

Controlling cost has always been high on the CIO’s agenda, but after the
high-tech bubble burst in 2001, the resulting crisis of confidence in IT
caused many organizations to begin holding IT accountable to more rigorous cost-cutting measures. To many chief financial officers, running a
“Lean” IT budget implies weight loss—reducing costs and resources as a
primary objective.
Lean practitioners clearly understand that a primary focus on cost
reduction, rather than value creation, is hazardous. Leading with a cost
focus can cause an organization to continue doing the wrong things more
efficiently. Worse yet, across-the-board mandated cuts may inflict irreparable injury to the long-term performance and health of the organization,
losing valuable knowledge.
Shigeo Shingo said, “The four goals of improvement must be to make
things easier, better, faster, and cheaper.”15 Note the sequence of this list;
Lean focuses on adding value and eliminating waste through simplification, quality improvement, and lead time reduction; cost reduction is
a natural outcome. According to Gartner, “One of the biggest mistakes
companies make with Lean is focusing too heavily on driving cost out
of the business. If you approach Lean with that attitude, you’re bound to
fail. Building a huge data center may give you great economies of scale, for
example, but it may also reduce agility and flexibility.”16
Nevertheless, there is often a relentless emphasis on IT cost reduction,
especially during economic downturns. While many organizations (and
their shareholders) focus primarily on financial measures, this can lead
to short-term thinking at the expense of long-term value. For example,
when an employee wastes 10 hours each week performing non-value-

added work, and this activity is suddenly eliminated, that employee can
then focus his or her skill, experience, and creativity on adding value elsewhere. But since this does not lead to a reduction in salary expense, or
any direct impact to the financial statements, this improvement often goes
unrecognized, or is characterized as a soft savings. The same argument
can be made for a kaizen that reduces floor space or the need for existing
equipment, creating the potential that these assets can be redeployed to
add more value elsewhere.
Few people will argue that these improvements don’t create value, but
when it comes to prioritizing improvements, there is nevertheless a strong
bias toward hard cost reduction—those improvements that go right to the
bottom line. This creates a predisposition toward short-term improvements
that have quantifiable cost reduction or avoidance, but many strategically
significant improvements are long term and not easily measured (consider
improvements to flow, quality, and customer satisfaction). To mitigate this
bias, organizations may use hard- and soft-value categories when assessing
the impact of kaizen activities, so whether or not there is a direct financial
impact, they are acknowledging overall value contributed.
To ensure sound decisions are made for the health of the overall enterprise, IT professionals must help the business clearly discern and measure
the true value of each IT service, and its contribution to customer value.

The Importance of the Lean Management System
In the end, a successful Lean transformation requires the aligned, cooperative behavior of executives, management, and individuals. This is enabled
by strategy deployment, and supported by communications, knowledge
management, collaboration, and performance measurement systems
that focus on value creation. Good decisions and effective, aligned action
require simple, understandable, and actionable information.
A Lean management system communicates quality information
throughout the organization, accompanied by the steady cadence of leader
standard work. By decentralizing problem solving and decision making,
and encouraging everyone to take responsibility for Lean performance, an
organization cultivates a sustaining Lean culture.


Endnotes

1. David Mann, Creating a Lean culture: Tools to sustain Lean conversions (New York:
Productivity Press, 2005), vi.
2. Bill Gates, keynote speech, Microsoft’s Second Annual CEO Summit, 1998.
3. Peter Senge, The fifth discipline, rev. ed. (New York: Doubleday, 2006), 270.
4 As the Economy Contracts, the Digital Universe Expands, EMC White Paper, May
2009.
5. David Mann, Creating a Lean culture: Tools to sustain Lean conversions (New York:
Productivity Press, 2005), 11.
6. Steven J. Spear, Chasing the rabbit (New York: McGraw-Hill, 2009), 24–25.
7. Gwendolyn Galsworth, Visual workplace, visual thinking (Portland, OR: Visual-Lean
Enterprise Press, 2005).
8. Eckerson, Performance dashboards, 18.
9. Wayne Eckerson, Performance dashboards: Measuring, monitoring and managing
your business (New York: John Wiley, 2006).
10. Senge, The fifth discipline, 218.
11. Peter Hines, Daniel Jones, Richard Lamming, Paul Cousins, and Nick Rich, Value
stream management: Strategy and excellence in the supply chain (Upper Saddle River,
NJ: Financial Times Prentice Hall, 2000); James P. Womack, Daniel T. Jones, and
Daniel Roos, The machine that changed the world (New York: HarperCollins, 1990);
and James P. Womack and Daniel T. Jones, Lean thinking (New York: Free Press,
1996), 16–26.
12. Hines et al., Value stream management, 116.
13. Brian Maskell and Bruce Baggaley, Practical Lean accounting (New York: Productivity
Press, 2004), 2.
14. Jean E. Cunningham, Orest Fiume, and Emily Adams. Real numbers: Management
accounting in a Lean organization. (Durham, NC: Managing Times Press, 2003), 92.
15. Alan Robinson, Modern approaches to manufacturing improvement: The Shingo system (New York: Productivity Press, 1990), 97.
16. Leon Erlanger, “Smart enterprise insights: Going Lean,” www.smartenterprisemag.
com/showArticle.jhtml?articleID=217701405&pgno=3.

Section III

Performance
IT Operational Excellence

7
Lean IT Operations: ITIL
and Cloud Computing

Chapter Objectives
This chapter provides an introduction to Lean concepts applied to IT
operations, and the delivery of IT services to your organization and customers. We will:
• Discuss how Lean IT creates a foundation for sustained IT operational excellence.
• Explore how the Information Technology Infrastructure Library
(ITIL), a best practices framework for IT service management, complements Lean IT.
• Speculate on the future of cloud computing and its implications for
the IT organization, from a Lean IT perspective.
The IT organization is like a black box to many business executives and
managers. Computers are everywhere, and our employees and customers depend on them virtually every minute of the day. When IT services
are functioning properly, IT operations are transparent—we don’t notice
them. However, there is often an underlying fear of the unknown, of catastrophic failure, so organizations invest large sums of money and effort
in business continuity plans and disaster recovery preparedness—though
often not effectively addressing the root causes of potential failure.
149

More insidious, what we often don’t realize or measure is the impact
of countless small failures on every desktop each day. Temperamental
computers and software steal incalculable hours each week from otherwise productive employees. An incomprehensible error message suddenly
appears on a screen, a printer stops working, a software application hangs
up, a document is lost … calls to the help desk eventually fix the immediate
problem, but only after delays and frustration. So we continue on with our
day, holding our collective breaths until the next time.
At best, minor interruptions sap the vitality of the organization. At worst,
chronic instability may cause anxiety, workarounds, and underutilized IT
investments. We once overheard a CEO refer to his IT organization as “a
necessary evil.” Another CEO lamented that his company was “held hostage” by intractable information systems. In fact, many executives harbor
a deep concern about the dependability of their essential systems, feeling
powerless to take effective action. Meanwhile, in many IT organizations,
technical specialists dash about maintaining order and stability, keepers
of secret knowledge and skills that are hard to understand, and even more
difficult to standardize, measure, and manage.

Quality Is Free
Chronic information system instability, when it exists, is unacceptable.
And often, even when systems are stable, there is the perception of
instability and excessive cost, born from lack of comfort and understanding about how the IT operations function. In any case, IT operational excellence, and confidence in their performance, is necessary if
we are to trust information and information systems to support our
businesses.
In 1979 Philip Crosby published Quality Is Free, arguing that every dollar invested in quality is returned in profitability.1 Although Crosby was
addressing manufacturing at the time, the very same methods may be used
to ensure quality, consistency, reliability, and peace of mind when delivering IT services. After all, IT operations are a business, and they should be
run and measured like one. In the opening paragraph of Measuring ITIL,
author Randy Steinberg poses a challenge:

Lean IT Operations: ITIL and Cloud Computing • 151
Much has been written lately about how IT needs to be “run like a business.” A stronger statement is that IT needs to “act like a business.” While
technology is certainly important, IT needs to inject much better business
management practices by operating services instead of technology silos,
measuring the quality and effectiveness of those services and taking timely
actions to make sure those services are delivered in line with business
needs.2

For most organizations, the cost of basic IT operations represents the
majority of the total IT budget—just to keep the lights on, the servers
running, and the applications working. In 2009 PricewaterhouseCoopers
reported that “operational expense is typically more than 80 percent of
the IT budget. And everyone has a story about IT not fulfilling requests
quickly enough. Business agility is definitely constrained by a lack of IT
agility.”3
Clearly, IT operations and the delivery of shared services represent a significant investment for the business, one that in many companies often fails
to deliver expected results. To ensure value, the business drivers behind IT
costs should be clearly understood by business and IT stakeholders, supporting well-informed decisions on IT investment priorities. And once
these investments are made, the IT organization must deliver services that
balance complexity and manageability, so the business stakeholders can use
systems properly and with confidence. At the same time, IT must deliver
these services while adapting to constantly emerging and maturing technologies. Furthermore, this technological complexity and flux are expected
to be hidden from the end users, who simply want the services to meet their
current needs, while anticipating future growth and innovation.
To achieve these lofty objectives, the IT organization must manage itself
in a way that reduces uncertainty and variability, providing uninterrupted
quality services to its customers. At the same time, they must maintain an
inward focus on morale and on attracting, retaining, and cultivating the
best talent. After all, notwithstanding the sophisticated technology, IT is
essentially an intellectual capital endeavor.
At the bottom line, the business wants to see year-on-year cost reductions and improvement of IT service effectiveness, achieved in a manner
that supports continuous improvement of business processes, and in a way
that encourages innovation and positively differentiates the business from
its competition. Is all that too much to ask?


Functional Silo or ValueAdding Service Center?
Traditional IT organizations structure themselves around technical
domains and skill sets. This approach aims to reduce cost through economies of scale, where specialized resources are concentrated, and the
cost of centralized systems and services are shared across many customers. According to the assumptions of mass production, which have been
ingrained since childhood, this approach is commonly accepted as efficient and cost-effective.
Lean manufacturing pioneers discovered that the functional grouping
of machines causes many challenges as intersecting value streams compete for shared resources and specific skills, resulting in large or rapidly
shifting backlogs, excessive work in process inventory, unclear and shifting priorities, frequent interruptions, quality problems, cost overruns, and
delays.
In the case of IT operations, the overspecialization and concentration of
shared resources can cause:
• Flow interruptions as distinct subgroups focus on internal schedule
optimization and resource utilization, causing uneven batch-andqueue workflow.
• Risk of excessive dependence on overburdened individuals with special skills, who have neither the time nor the motivation to share
their knowledge with others.
• Communication breakdowns as essential information is not shared
across value streams.
• Tendency for specialists to overemphasize technical issues rather than
business processes, leading to unnecessarily complex and wasteful
solutions that are often resistant to change.
And finally, a functional organization presents a disjointed view of
IT services to the customer, particularly when a service is interrupted
and multiple groups have to be contacted separately. This is where the
finger-pointing cycle often begins: each group troubleshoots separately,
focusing on its own localized issues rather than the overall problem from
the customer’s perspective. Not only can this situation be frustrating, but

also this fractured approach obscures the true cost and perceived value
of the services. As a result, the IT organization is often shrouded in an
aura of unpredictability and mistrust, creating a perception of an out-ofcontrol cost center rather than a value-adding service center.
Some IT leaders have therefore begun organizing their resources around
a portfolio of the services required by their customers. These services are
often grouped in categories, such as:
Application services:
• Application Delivery
• Communication and Collaboration (E-mail, Voice, Video, etc.)
• Document and Image Management
• Service Desk (help desk)/Application Support
Component technology services:
• Application and Data Hosting
• Network and Telecommunications
• End User Devices (Desktops, Laptops, Handhelds, etc.)
Professional services:
• Business Technology Strategy Consulting
• Application Selection and Implementation
• Application Development
• System and Application Integration
• Portfolio/Program/Project Management
• Training
Each category usually includes several distinct services and service-level
agreements (SLAs) with a fabric of underlying processes to deliver them.
Furthermore, each underlying process may support multiple service categories (such as application hosting processes which also impact systems
integration services) creating a cross-functional, process-oriented web of
interdependency, responsibility, and accountability.*
* More specifically, within a formal IT Service Management Framework, Service Level Agreements
(SLA) are generally established with business customers who use the IT services (primarily software application services) to support business processes; these are outward facing agreements.
Operational Level Agreements (OLA) are inward facing agreements established among the various technical and professional services (hosting, storage, security, telecom, consulting, etc.) to
enable and support the outward facing services. This web of interdependent service elements
(OLAs and SLAs) are published in the service catalog, which documents combinations of service
elements as predefined service offerings based on predictive customer demand patterns. From a
Lean IT perspective this represents a comprehensive framework of IT service value streams for
designing, delivering, measuring, and continuously improving IT Services

Rather than emphasizing specialized skills development, resource
utilization, and task efficiency, the collective focus of process-oriented
teams shifts from economies of scale to economies of flow. This perspective unites business and IT stakeholders toward increasing the value of
IT services, emphasizing their contribution to the organization’s goals,
rather than exclusively reducing the cost of delivery. For example, crossfunctional teams will be more inclined to eliminate non-value-adding
IT activities altogether, rather than simply make them more efficient.
This emphasis on value over cost is underscored in the Shingo Prize for
Operational Excellence guidelines:
A process focus naturally leads to flow thinking. Flow—producing one item
or performing one service component a step at a time and in a series of continuous steps flowing toward the customer (rather than batching products
or service steps)—is the best driver to make processes easier, better, faster,
and cheaper. A cost focus is particularly dangerous, when it creates perverse
incentives and budget manipulations incidental to actual improvement.4

Gartner describes the same phenomenon from an IT perspective in Six
Steps to Process-Based IT Organizational Design:
Traditional IT service delivery and organization models achieved efficiency at the expense of effectiveness. When resources are orchestrated
in silos, many such silos become involved in delivering an IT service.
None, however, possesses the insight, visibility or accountability for
anything other than its own small part of a delivery chain. To the extent
that business operations are dependent on repeatable, reliable IT service delivery, a process organization and culture are required. Although
technical skills will always be required, the optimized process-based
organization is horizontally focused on outcomes, not vertically oriented around skills. 5

Many natural impediments resist this process-based reorientation, and
perhaps none is greater than basic human nature. Humans are territorial creatures, especially when they have cultivated specialized skills that
become part of their personal identity and sense of pride. If we are going
to ask our IT associates to share their skills with others, to focus their
attention on specific services (rather than the constant adrenaline rush of
smoke jumping from one crisis to the next), and to even move their desks

(gasp!) to a cellular organization more conducive to service-based collaboration and flow, we’d better have a compelling reason.
That reason is found in the hazards of shared resources—people or
equipment with unique capabilities that are spread across multiple value
streams. Shared resources are difficult to schedule and are subjected to
frequent interruptions, creating a migratory bottleneck that can suddenly
disrupt the flow of any process.
Lean offers many approaches to mitigate a shared resource.* First of all, a
constrained resource (bottleneck) should avoid doing work that an unconstrained resource can perform instead. Second, the organization should
reduce its dependency by encouraging knowledge capture and cross-training. Ultimately the IT organization should focus on simplifying processes,
tools, and components, reducing the need for specialized resources. For
many years software designers have emphasized standardization, reusability, and component-based, service-oriented architectures—these same
principles should be extended to the design of IT services themselves, and
to the organization of resources which support them.
Cellular organization is a useful Lean method, where the people and
equipment supporting all or part of a value stream are grouped together to
encourage workflow. Multiskilled workers can move about to lend a hand
where and when it’s needed. Constant daily interaction, coaching, crosstraining, visual measurements, and knowledge sharing within the cell
build capability and flexibility, while encouraging standardization and
small improvements every day. IT workcells may be physically or virtually
co-located, so demand, status of workflow, and issues requiring attention
are quickly and visually communicated among team members. For more
on how remotely co-located teams can be supported by Lean approaches
and virtual collaboration tools, see also Chapter 6.
Fundamentally, once resources are aligned so that value streams can
flow, it is far simpler to balance demand and capacity for each IT service
(see Chapter 5 on IT demand management). Service-oriented teams are
also intuitively better able to see and reduce waste across the entire value
stream (systems thinking), delivering more value to the customer. Cost
reduction is a natural by-product of this reorientation.
* For more on mitigating bottlenecks, see the Theory of Constraints; while it may not be practical for
an IT organization to eliminate all technical specialization, and the one-off systems and technologies that give rise to them, identifying and mitigating these constraints is an important first step.


ITIL: A Lean Approach to IT Services Management
The Information Technology Infrastructure Library (ITIL) is a widely
used IT service management framework that is consistent with many Lean
IT principles and tools. The creation of ITIL is commonly attributed to the
United Kingdom Office of Government and Commerce in the mid-1980s
(which has trademarked the name), and it has since been adopted in many
businesses and governments worldwide.
The fundamental value proposition of ITIL is simple yet profound: without
effective change management, the break-fix response to IT problems is random, time consuming, and costly. Over 80 percent of system downtime is selfinflicted, caused by people and process failures rather than technology failure.
Furthermore, over 80 percent of the time and effort required to restore service
is spent tracking down the changes that were made and determining how they
caused the system failure so effective corrective action can be taken.6 From a
Lean perspective, such reactive, unplanned activity is waste.
At the core of ITIL is continuous improvement, using the scientific
method (PDCA) for identifying, correcting, and preventing problems. By
establishing standardized work methods that regulate system changes,
capture and correct failures when they occur, and rapidly diagnose their
root causes to prevent future failures, performance can be clearly measured and the system reliability improved. As a result, the percentage of
unplanned work (firefighting and reactive workarounds) performed by the
IT staff is significantly reduced, and replaced with planned work which
adds value to the business. Time, quality, and cost of IT operations measurably improve; systems stabilize; and morale improves. Everyone wins.
Auditors are also pleased with ITIL since quality is built into each process, resulting in documented procedures and a more stable environment
with less business risk. This quality at the source approach reduces the cost
of compliance, an important consideration with the increasing burdens of
the Sarbanes-Oxley Act and other governance and regulatory compliance
obligations.
One of the most significant long-term benefits of ITIL is the creation of
a common language for IT services. This enables the business and IT communities to agree upon services provided by the IT organization, setting

clear expectations for their performance and establishing meaningful measurements against those expectations. One of the essential components of
this common language is a service catalog, describing the value-added services the IT organization provides to its customers. A service catalog should
describe standard service offerings and how they are ordered, delivered, and
charged for, with explicitly measurable service-level agreements that define
performance and customer satisfaction—the voice of the customer.
An effective communication, measurement, and feedback framework
encourages adaptation and innovation, where customers can describe,
in meaningful terms, new services they desire and are willing to pay for.
This framework should also allow for the request of nonstandard services as required, such as research and development activities. Service
catalog offerings form the basis for IT resource planning, staffing, skills
development, and management, aligning service capacity with customer
demand.
The ITIL framework is also useful in collaboration with suppliers and
external customers, describing and defining service catalog offerings to
provide dependable supply chain infrastructure and integration services,
while creating a baseline for evaluating future supply chain technology
investments.
Over time, as IT and the business learn the common language and
deploy a standard framework of IT services, chronic system instability
disappears, replaced with teamwork, dependability, and trust.
ITIL Is a Set of Integrated Processes
Over the past two decades, ITIL has evolved to support greater business
alignment—the ITIL Version 3 library (introduced in 2007) has a greater
emphasis on service delivery, service life cycle management, and continuous improvement. According to Manoj Garg of Virtual Information
Executives, the evolution of ITIL demonstrates the transition from a technical focus toward the continuous improvement of processes:
ITIL version one was focused on managing systems and technical silos.
Version two added a process dimension, but it did not offer guidelines for
how to implement those processes. Version three not only helps the IT


3
Service
Transition

2
Service
Design
1
Service
Strategy

Plan
Act

Do

4
Service
Operation

Check

5 Continuous
Service Improvement
Figure 7.1

ITIL Integrated Service Lifecycle Model

organization and the customer work together to define a meaningful bundle of services and performance measures, but also uses PDCA to monitor and continuously improve the fit and quality of those services. This
approach is especially important because the customer understands and
defines the services they are agreeing to purchase, and is actively involved
in their definition, delivery and measurement.7

The ITIL Version 3 service life cycle model consists of five stages, shown
in Figure 7.1:
1. Service strategy: Developing a clear vision and plan for service portfolio design, demand management, and IT financial management
2. Service design: Developing appropriate and innovative IT services,
including their architecture, processes, policy, and documents with
the goal of satisfying current and future business requirements
3. Service transition: Deploying new services, managing service
changes, and the knowledge related to those services
4. Service operation: Delivering services to clients at the agreed level of
service, while managing the applications and underlying technology
to support their delivery
5. Continuous service improvement: Sustaining and improving value
to the customer, collaborating on design improvements and service
modifications


How ITIL Emphasizes Quality at the Source
The diagram below depicts the ITIL Service Support and Service
Delivery functions (version 2) and is useful to illustrate the interrelationships of several key functions:
• The customer has a problem and seeks assistance through
access to a self-service knowledge base or by logging the issue
with Incident Management (e.g., service desk or help desk)
• Service Level Management tracks service desk performance
against customer expectations as established in Service Level
Agreements (SLAs)
• Incident Management coordinates with Problem Management
to establish if the issue is a known problem, and with Knowledge
Management to determine if there is a known resolution
• Problem Management interacts with Change Management and
Release Management, since most problems are typically caused
by past changes and releases, and future changes are planned as
releases to address known problems
• Configuration management tracks the current known state of
all systems (configuration, software, settings, etc)

Customers

Self Service

Incident
Management

Service Desk
(help desk)

Problem
Management

Change
Management

Knowledge
Management

Release
Management
Conﬁguration
Management

Service Support

Service Level
Management

Availability
Management
Capacity
Financial
Continuity

Service Delivery


Since roughly 80% of problems are typically caused by changes,
proactive Change Management (interacting with Release and
Configuration Management) is the key to improving quality and
stability. By understanding the root cause and effect interrelationships among configurations, changes, and releases, new incidents
are quickly addressed, and underlying problems can ideally be
prevented—this is the Lean principle of Quality at the Source in
action.

All ITIL functions and processes across the five life cycle stages are
interdependent; thus, feedback from one stage drives improvement in
another (see sidebar). This is system kaizen, where improvements in one
area of a process are felt throughout the entire value stream, creating
value for the customer.
How ITIL Supports Lean IT
Though ITIL appears to have evolved independently from Lean practice,
by understanding the similarities ITIL can be integrated with the enterprise-wide Lean IT transformation.
A3 Problem Solving

Problem solving is at the heart of ITIL. Beyond the philosophy of scientific problem solving and Plan-Do-Check-Act (PDCA), ITIL teams find
A3 problem solving can provide an essential step-by-step guide to help
them focus on solving a problem without wasted time or effort.

Voice-of-customer (VOC) techniques help determine what the customer
needs, and what elements of the service catalog are required to satisfy
those needs, guiding the development of SLAs to define how they are
delivered, measured, and valued. VOC is the why, service catalog is the


Lean Thinking Applied to Security
and License Management
Two areas where Lean thinking has proven effective are software
license management and security management. These two domains
share common characteristics: they are complex, are constantly
changing, expose the enterprise to great cost and risk, and touch virtually every desktop in the organization.
License management: Organizations usually pay too much, or not
enough (often at the same time for various license agreements), in
part because they have difficulty identifying currently installed and/
or used software applications. Not only does this complicate IT operations, since there is no reliable record of installed configurations,
but it also exposes the organization to potentially significant legal
liability. Tracking licenses has become more difficult in recent years,
due to the variety of platforms supported (servers, laptops, hosting, software as a service, etc.) and the variety and endless details of
licensing agreements offered by vendors. In our experience, the only
way to get a handle on this growing challenge is through a crossfunctional effort involving IT operations, service desk (end user support), finance (asset tracking and compliance), and legal (contract
negotiation and review), as well as representatives of all stakeholders
that use software within the organization. This is fundamentally a
workplace organization challenge, so the 5S methodology is useful—
sorting, organizing, and validating assets in place, then establishing
standards to sustain recordkeeping. Sustaining measures ensure that
assets are properly licensed and configuration changes are tracked in
a timely manner, reducing audit costs and eliminating unnecessary
license fees and compliance risks.
Security management: Many service desks report their largest call
volume is the response to lost password and reset requests. Security
threats are tenacious and widespread, affecting virtually every aspect
of IT and business operations, causing tremendous waste, disruption,
cost, and risk. And the more critical a business process is, the more
extensive the gauntlet of security defenses usually surrounding it;
thus, the most critical processes often suffer the most security waste.
(For an interesting perspective, see Security Kaizen.)8 Because of its


pervasive nature, specific kaizen activities should focus on security
issues across organizational boundaries, processes, and applications.
And all IT-related kaizen activities should deliberately consider the
security implications of every change, clearly identifying when security measures add value, and when they do not. Rigorous A3 thinking thus provides an effective foundation to address the constantly
changing landscape of security risk and waste.
what, and SLA is the how. Conversations with customers should focus on
the what—too often businesspeople want to define the how, and it can
either be contentious or lead IT efforts down the wrong path. The Lean IT
organization should encourage regular engagement and feedback with all
customers to define and improve services and service-level agreements.

ITIL problem management establishes a discipline of root cause analysis followed by corrective and preventative action. ITIL change management prevents abnormal conditions from occurring. Lean tools that may
assist include error proofing of processes and user interfaces, and visual
measurement of process performance with leading indicators of defects
or problems, all aimed toward helping to design quality into IT services.
Standard Work

IT associates are often rugged individualists, very smart people who like
to do things their own way—and that is often the fastest and newest way.
IT professionals and business end users alike are often guilty of wanting the latest software and equipment—but this causes an endless churn
of new systems and configurations that must be supported, resulting in
unnecessary variability (muri), leading to pockets of technical specialization and chronic instability.
Many of the greatest challenges of IT operations are caused by lack of
standardized work, particularly the lack of standard hardware, peripherals, software, and system configurations. When standard hardware
models and configurations are encouraged throughout the enterprise,
this not only reduces purchase and support costs but also reduces spare

parts inventory and service response time, improving the stability of
the environment.
Resistance from IT staff is common; the thrill and adrenaline rush of
crisis response are self-perpetuating and strangely rewarding to many. So
while IT staff may initially view the emphasis on standard procedures as
mundane and unsatisfying, in the long run a more stable environment
supports true innovation and value creation. Culture changes only when
basic behaviors change; this is a team effort, and everyone must learn to
play well together.
Measurement

ITIL measurements have been well defined in recent years, with each measure focused on producing actionable results,* providing feedback to drive
continuous improvement:
• Ratio of planned to unplanned IT work: Provides a good general measure of the stability of the environment. Although this
requires an investment to track unplanned work time, the data
are then useful as inputs for problem categorization and root
cause analysis.
• Mean time between failure (MTBF): The average time between service interruptions. This is commonly used to measure hardware failure, but it can be equally effective with service failure.
• Mean time to repair (MTTR): The average time to restore service
after an interruption.
• Availability: The availability of a resource, which includes planned
and unplanned downtime.
• Percentage of successful changes: This refers to changes that do not
result in downtime or unplanned work, requiring the correlation of
incident report data and change management data.
• Server to system administrator ratio: Measures staffing levels required
to manage systems, indicating the degree of standard work, availability, and manageability of systems.
* Many of these measures are familiar to practitioners of Total Quality Management (TQM), Total
Preventative Maintenance (TPM), and Overall Equipment Effectiveness (OEE).

• Percentage of effort deployed early in the change–release cycle: A good
leading indicator that the scientific method is being followed: more
Plan means less Do-Check-Act.

Lean IT in the Cloud
Cloud computing is suddenly threatening to disrupt many traditional IT
organizations and practices. Let’s explore, from a Lean IT perspective,
what this relatively new practice could mean for the future of the IT organization and its value proposition for the business.
Many companies, including Google, Microsoft, and Amazon, are investing in enormous global data centers to provide Infrastructure as a Service
(IaaS), moving many functions of IT operations into a utility model. These
are true computing factories, providing IT services at massive economies of
scale: low cost (an order of magnitude lower than most companies can provide for themselves), with virtualization, engineered redundancy and fault
tolerance, and automation for high availability and hands-off management.
Going further, many companies (Google, Microsoft, Amazon, Salesforce,
SAP, Oracle, and many others) are providing software as a service (SaaS)
business application components and platforms using a service-oriented
architecture (SOA) to provide standardized and interchangeable parts
needed to assemble (and reassemble as needed) enterprise-class applications over the Internet with lower change and management costs. This shift
resembles the gradual transition of manufacturing from custom engineering to mass customization (see the diagonal shift explored in Figure 5.1).
It may take years for most companies to significantly transition their
applications strategy in this direction. And cloud computing won’t be
appropriate for every situation; indeed, it could make some issues, such as
security and compliance, more challenging than ever. Nevertheless, cost
will inevitably drive many IT services into a utility model, whether internally or externally sourced. The coming of the cloud will not eliminate the
IT organization, but we expect that it will dramatically change its role and
approach toward value delivery to the business.
In the short term, we expect that IT organizations will invest in the standardization and continuous improvement of infrastructure and related services, improving stability and reducing operation cost; this is where ITIL

can play an important role. Over time, as some organizations move significant elements of their infrastructure and application ecosystem to the
cloud, this transition will create competitive pressures for other organizations to move into the cloud as well.
The adoption of cloud computing will undoubtedly cause a shift in
IT operations staffing, but it clearly won’t eliminate the need for highly
skilled internal resources—although many services will be provided from
the outside, the relationships and interfaces to the business must still be
skillfully managed. But we expect there will be an even more significant
and positive shift in emphasis toward business process improvement for
the IT organization. According to the CIO Magazine article “The Tech
Jobs That the Cloud Will Eliminate,” there will be “[a] gradual movement
of the IT profession away from the nuts and bolts of technology toward
the business end of the organization. The cloud is accelerating that movement of technology into the business with business-process-level expertise
becoming more important than ever.”9
In his provocative book Does IT Matter? Information Technology and the
Corrosion of Competitive Advantage, Nicholas Carr argues that with increasing standardization and commoditization of computing resources, like the
shift from localized to centralized electricity generation in the late 1800s,
computing will no longer be a source of competitive advantage since it is
available to everyone at a low cost. While Carr makes many good and subtle
arguments, we disagree with the fundamental assertion for a simple reason:
the low cost and accessibility of a resource do not ensure that everyone will
utilize it equally well. In fact, it may be that with the lower cost of IT services,
more companies will be at risk of making unwise decisions leading to poorer
use of IT capabilities, creating more unnecessary complexity than ever before.
While the cloud may change the cost structure of IT services, competitive
advantage will still go to those who are able to use IT effectively to support
the business. And the key to this? IT process leadership, supporting the continuous improvement and innovation of business processes—Lean IT.

Lean Tips for Successful IT Services Adoption
Now that we have explored ITIL within the context of Lean IT, we must
remember that while a singular focus on tools may yield significant short-

term benefits in isolated areas, sustained enterprise-wide behavioral and
cultural transformation will only occur when actively supported by management and founded upon deeply held principles. Perhaps the greatest
cultural challenge with ITIL and Lean IT, and with developing an IT
service management mind-set in general, is leaving behind what might
be called a cowboy or hero culture, transitioning to an environment that
encourages cross-functional teamwork, disciplined problem solving, management by fact, and responsible change management. Some individuals
may feel that change management implies non-value-added bureaucracy,
and often this occurs temporarily as the IT organization overcompensates
to stabilize an out-of-control environment. But over time the processes,
and the stakeholders responsible for those processes, should become selfregulating. As Stephen Katz, former chief information security officer of
Citibank, once said, “Controls don’t slow the business down. Like brakes
on a car, controls actually allow you to go faster.”10
From a senior leadership perspective, the service orientation and common
language of ITIL provide an opportunity for developing clear and measurable goals for the IT organization. This is useful in aligning IT service activities to the business operations and strategy, and for establishing effective IT
operating and governance policies and procedures. Executives and business
managers must be involved in charting the course, establishing clear process
ownership, service-level expectations, and accountability for each IT service.
As we mentioned in Chapter 3, ITIL is a framework upon which to build
your own best practices. While ITIL offers a set of useful characteristics
or attributes, it is not a prescription, checklist, or methodology for implementation. The ITIL volumes describe a comprehensive but generic future
state which must be adapted to the idiosyncrasies and culture of a particular IT organization and the business that it serves. ITIL is not a project or
implementation; like Lean IT, it is an ongoing journey of discovery and
experimentation. Like any Lean initiative, IT leadership must ensure that
all stakeholders understand and buy in to the discipline and long-term
commitment that are required. Successful IT service management transformation is thus more social and cultural than it is technical, and should
develop from within rather than be imposed from the top-down or the
outside-in.
As you have learned in this chapter, ITIL naturally encourages reorganization away from a functional, silo-based structure, to one aligned according to IT service-based processes that support the customer—from the

Lean perspective, this is value stream orientation. This suggests a change
in roles and responsibilities; each process should have an owner who is
responsible for its performance, directed by service-level agreements
established with the customers.
A service management framework thus naturally aligns core processes
with the needs of the customer, rather than traditional inward-facing performance measures. At every step of the transition, it is therefore important to establish understanding and consensus among team members and
customers, supported by a transparent decision-making process coupled
with effective feedback mechanisms. Respect for every individual’s concerns and ideas is essential—their hearts, and not just their minds, are
needed for a lasting transformation.
Then there is the issue of operations outsourcing; selection of a partner
should consider their willingness and ability to genuinely participate in
continuous improvement activities. This begs the question of how they are
compensated—on the basis of activity or value delivered? For example, an
outsourced call center paid on the number of calls is not incented to address
the root causes that drive higher call volume, thus creating a disincentive
for continuous improvement. Consider operating-level agreements that
recognize the value of effective problem solving and continuous improvement, which requires an explicit commitment of the partner’s time and
resources.
This consensus and transparency must also extend to customers, since
they should understand the relationship between what they request and
how much it costs. Cost chargebacks act as pricing signals to the business, naturally driving behaviors—whether effective or ineffective. The
common language of ITIL, with clearly defined service-level agreements
and IT resources aligned by service rather than function, makes it much
easier to develop direct and clearly understood costing methods that drive
desired behavior and IT investments (see the Lean accounting discussion
in Chapter 6).
All stakeholders involved in the request and delivery of IT services
should come together to define value and determine how it is created.
We recently asked ITIL authority Steve Bittinger, Gartner’s director for
government research, “Does a team-based, continuous improvement
approach to problem-solving accelerate and sustain the adoption of ITIL,
when compared to a top-down, command and control ITIL effort driven
by management and external consultants?”

His response is good advice to any IT organization attempting, whether
through specific ITIL best practices or general Lean techniques, to improve
IT operations performance:
Failure to take a continuous improvement approach is one of the core
problems that many organizations experience during an ITIL implementation. The challenge is to identify a series of improvements that are practical
(feasible/achievable), will create tangible benefits, that matter to the business, and can be done in a relatively short time. ITIL implementation then
becomes a series of these improvement projects, each paying its own way
through the benefits delivered, and collectively contributing to fleshing out
the over-arching ITIL process architecture. It is a very dynamic process
that requires thinking strategically, and acting tactically.11

Though the terminology and best practices framework of ITIL are specific to the IT operations domain, it should be clear to the reader that the
fundamental principles of ITIL and Lean share many of the same themes:
alignment of value-added services based on customer-defined value, standardized work, PDCA problem solving, and continuous improvement
that, over time, creates sustainable business results.

Endnotes

1. Philip Crosby, Quality Is Free (New York: McGraw-Hill, 1979).
2. Randy A. Steinberg, Measuring ITIL (Bloomington, IN: Trafford, 2006), 1.
3. PricewaterhouseCoopers, The real promise of cloud computing, PricewaterhouseCoopers Technology Forecast, Summer (London: PricewaterhouseCoopers,
2009), 8.
4. Shingo Prize for Operational Excellence, Model and application guidelines, 3rd ed.
(Logan: Utah State University, Jon M. Huntsman School of Business, 2009), 5, www.
shingoprize.org.
5. Colleen M. Young, Six steps to process-based IT organizational design, October 18
(Stamford, CT: Gartner, 2006).
6. Kevin Behr, Gene Kim, and George Spafford, The visible ops handbook, rev. ed.
(Eugene, OR: IT Process Institute, 2004–2005), 17, 21.
7. Manoj Garg, interview, August 22, 2009, www.viellc.com.
8. Security Kaizen, www.css-security.com/downloads/papers/security_kaizen_intro_1a.
pdf.
9. Leon Erlanger, “The tech jobs that the cloud will eliminate,” CIO Magazine, July 22,
2009.
10. Behr et al., The visible ops handbook, 18.
11. Steve Bittinger, research director, Gartner government research director, interview,
August 12, 2009.

8
Lean Software Development

Chapter Objectives
In this chapter we will explore Lean software development, also known as
Agile. We will:
• Continue our examination of waste versus value, this time specifically in terms of software development.
• Explore the importance of rigorous voice-of-customer techniques
when defining software requirements.
• Demonstrate how many of the standard principles and tools of Lean
can trim waste and build flexibility into the software development
life cycle.
• Examine how Lean manufacturing approaches such as kanban and heijunka (level) scheduling, along with demand management and a focus
on problem solving, revolutionize software development practices.
In 2001 a group of 17 visionaries signed the Agile Manifesto, establishing a simple set of principles:
We are uncovering better ways of developing software by doing it and helping others to do it. Through this work we have come to value:
• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan1

169

Over the past two decades Lean software development has gone by many
names, most commonly agile (an umbrella term often used to describe
the collection of techniques), scrum, and extreme programming. Behind
these names are many Lean tools and methods that have been adapted to
software development, revolutionizing practices in the software industry.
It is difficult to determine which Lean software development tools and
systems were developed independently and which were derived from both
the Lean manufacturing and Lean product development disciplines.* In
any case, the lessons learned from Lean are useful to guide the continuing
evolution of Lean software development.
The adoption of the term Lean software development is more than a
name change. While agile is a set of development and life cycle management tools and methods focused on the just-in-time development of
quality software, Lean software development addresses a larger context:
the environment within which the software operates, the value streams
of the enterprise. For example, in a business application, properly functioning software is viewed as a supporting element of the business process.
In an embedded software application (such as the operating system of a
smartphone or the control systems of a jet aircraft), the software is part
of the overall product design and value proposition to the customer.
Lean emphasizes seeing the whole through the eyes of the customer, not
its component parts through the eyes of the designer or developer. “Lean
software development views all Agile methods as valid, proven applications of Lean thinking to software,” says Jeff Sutherland, a signer of the
Agile Manifesto. “It goes beyond Agile, providing a broader perspective
that enables Agile methods to thrive.”2 In the words of Mary and Tom
Poppendieck, “A Lean organization optimizes the whole value stream,
from the time it receives an order to address a customer need until software is deployed and the need is addressed. If an organization focuses on
optimizing something less than the entire value stream, we can just about
guarantee that the overall value stream will suffer.”3
We have witnessed many skilled agile practitioners fall into the common
Lean trap: focusing on tools and techniques rather than solving problems
and eliminating waste. Lean software development expands agile’s focus
from optimizing the software development process toward improving
* See The Toyota Product Development System: Integrating People, Process And Technology by
Jeffrey Liker and James Morgan.

Lean Software Development • 171
entire value streams. Thus, Lean software development must integrate and
synchronize with all business processes, management systems, and kaizen*
activity, supporting the Lean transformation of the overall enterprise.

The Challenges of Traditional
Software Development
In the early 1980s, the U.S. government (the world’s largest software customer) conducted a study to improve software quality, resulting in the
Capability Maturity Model (CMM), which became a requirement for
government contractors. CMM defines requirements for software development and creates a framework for process improvement, ensuring a
degree of standardization and measurability, and thus it has been widely
adopted. Despite CMM’s benefits (it imposed a degree of standardization
on a characteristically haphazard industry), it further entrenched a mass
production mentality, introducing significant administrative overhead,
while in many cases making it difficult for organizations to adopt innovative methodologies such as agile.
In 1999, the President’s Information Technology Advisory Committee
reported that the unreliable and costly nature of software development, combined with the government’s enormous reliance on software for defense and
administration, had become so severe that it was potentially harmful to the
United States’ national interests. The committee recommended additional
funding for research programs in software development methodology.
Waste abounds in software design—only about 20 percent of the features
and functions in typical custom software are used regularly and around
two-thirds are rarely used.4 In our experience, IT professionals generally
agree that at least 50 percent of software capabilities in general, whether
or not they are used, are not adding value to the business process they
support; this unnecessary complexity hinders the usefulness of the applications, and requires additional training and support. Furthermore, these
excess features must be designed, built, and maintained, wasting development team effort which could otherwise be directed toward value-adding
activity. In Lean terms, this is the waste of overprocessing— doing more
than the customer values— shortly, we’ll discuss why this occurs.
* Kaizen is the continuous improvement of business processes described in Chapter 2.

Then there’s the concern over software quality, the waste of errors and
the defects they cause. On average, professional developers make 100 to
150 errors in every 1,000 lines of code they write, according to a multiyear
study of 13,000 programs by Carnegie Mellon. As a result, software projects
often devote 80 percent of their budgets to repairing flaws they themselves
produced.5 In addition to this astonishing level of rework are the time, frustration, and disruption inflicted upon the business and its customers, and
the effort required to provide support while problems are corrected.
The Cost of Change Curve (Figure 8.1) illustrates the impact of this
dilemma. Originating with the Total Quality Management movement, the
cost of change shows that the cost of fixing errors increases exponentially
the later they are detected in the development life cycle. This suggests that
not only must we detect and eliminate errors as early as possible, but also,
more importantly, we must prevent errors and unnecessary features from
being introduced into the life cycle in the first place. This is the quality at
the source Lean principle applied to the software development life cycle.*

Lean Defect
Prevention

Defects
(design ﬂaws)
Prevented
with
Rigorous
Voice of
Customer

Defects
Prevented
with Rapid
Collaborative
Integration
Prototyping
and Testing

Traditional Detection
and Rework

Defects
Discovered
During
Traditional
Coding and
Integration

Defects Discovered
During Traditional
Testing
Defects
Discovered
During
Traditional
Acceptance
Testing

Cost and
Business
Disruption
Caused by
Defects
Discovered
After
Release to
Production

Cost
Requirements

Analysis &
Design

Development

Testing

Release to
Production

Figure 8.1

Cost of Change Curve compares Lean and traditional outcomes.
* Design for Six Sigma (DFSS) deserves mention here, a discipline that has evolved through the
application of Six Sigma techniques to the development of new products and processes. DFSS
practitioners describe the cost of change as a lever—the earlier in the life cycle that potential errors
and defects are prevented, the greater the cost/benefit impact on the end result, and thus more
leverage.

Why do these extraordinary wastes of unnecessary complexity, errors,
delays, and cost overruns consistently result from traditional software development? Waste is often embedded in a mass production mentality, shown
in Figure 8.2 as the waterfall approach6,* where the time between initial
customer request and delivery of the software is so great (months or even
years) because large batches of changes are grouped into carefully planned
and controlled releases. This is analogous to the wasteful batch and queue
approach to mass production that is addressed by Lean manufacturing.
As large amounts of incomplete and untested code accumulate (workin-process inventory), undetected errors proliferate throughout the system. Since the project duration is so long, developers (especially those with
scarce skills in great demand) may be shared across several projects and
production support incidents, causing frequent interruptions, switching
costs, bottlenecks, and more errors. On top of it all, this approach involves
significant project management overhead: detailed project schedules,
Requirements
Analysis
Design
Code
Test
Deploy

Several Months Duration
TWO 8.2
Figure TABS

The traditional waterfall approach.
* See the original 1970 IEEE paper by Dr. Winston W. Royce, Managing the Development of Large
Software Systems, calling attention to the risks of the waterfall, suggesting an iterative approach.
It is important to note that the diagram shown here is an extreme oversimplification; in Royce’s
visionary paper he called for a sophisticated iterative approach that was a forerunner to agile
thinking. However, many software development organizations have designed their life cycle processes according to an overly simplified approach represented by this diagram, with the undesirable outcomes we describe in this section.

status reports, and resource management challenges are discussed at
endless meetings by teams attempting to manage complexity, competing
priorities, and scarce resources while trying to keep multiple projects on
track. These are similar to the challenges that drove the transformation
from push to pull in Lean manufacturing over 50 years ago.
Testing is the final step prior to release, where customers finally get to see
what they asked for. Commonly, though, what customers initially asked for
may not be what they really needed. And because of the long delay, their
requirements are likely to have changed (requirements churn) causing significant rework, additional cost, delays, and customer dissatisfaction.
This unreliability of customer requirements is due, in part, to customers
protecting themselves from long development lead times. When a development request is submitted, customers may include everything they can
think of in the requirements list, since they’re afraid their next opportunity won’t come around for months or years—if ever. Then, since the scope
is so large, there is a tendency for planners to buffer the estimate for uncertainties. As the gamesmanship and sandbagging pass through several levels of estimating and planning, customer requirements are distorted and
the cost and time proposed become far greater than necessary.7,*
These extended project life cycles sacrifice agility: the ability to respond
quickly to changing circumstances and requirements. Because software
is developed in such a linear and monolithic fashion, it becomes overly
complex and inflexible, increasingly resistant to change. In Lean software
development terms, such a system has accumulated technical debt, a liability of complexity and obsolescence that must be repaid at a later time.
In the broader context of Lean enterprise transformation, dysfunctional
software development practices inhibit business process improvement
efforts that often depend on those small, frequent software changes.

Lean Software Development Basics
Lean software development begins with a simple premise: identify the
20 percent of the code that provides 80 percent of the value, and deliver
* This is similar to what is known by Lean manufacturing and supply chain planners as demand
amplification, where estimated demand becomes distorted as it passes through multiple layers of
a supply chain; see the infamous MIT Sloan School of Management, “Beer Game,” http://web.mit.
edu/jsterman/www/SDG/beergame.htm.

it just-in-time. Lean software development emphasizes pull rather than
push scheduling, engaging the customer with requirements definition
and testing at every iteration. This approach is reinforced by the popular phrases “Write less code” and “Test early, learn rapidly, and fail
fast.”
According to Tom Poppendieck,
[T]he real problem with the cost of change curve [Figure 8.1] is that it fails
to separate workflow (the sequence of activities) from scheduling (what do
we do when). The curve is fairly flat when we do one feature at a time, it gets
exponential when we do all of one activity before beginning the next. The
underlying mental model behind these mistakes is thinking of software
development as a kind of production (input-process-output) rather than as
a problem-solving/learning activity.8

An effective software development methodology must therefore nurture
an environment where discoveries and ideas unfold quickly and naturally, deferring design commitment to the last practical moment. Lean
software development does not follow a rigid prescriptive model (a checklist-driven, command-and-control push schedule) but an iterative and
adaptive approach where team members quickly learn and solve problems.
Consistent with the Agile Manifesto, collaboration, experimentation, and
feedback are more important than designing the right solution* the first
time.
Paradoxically, adopting a strict zero-defects mentality too early in the
life cycle discourages creativity, continuous learning, and experimentation. According to Dr. Christoph Steindl of IBM Global Services, “[W]hen
a (traditional) organization has software development challenges, there
is a tendency to impose a more disciplined process on the organization, with more rigorous sequential processing; this generally makes a
bad situation worse.”9 So rather than a lengthy waterfall with rigorous
project management, Lean software development relies on rapid iterations (sprints) where each cycle is an opportunity for the team (including
the customer) to make new decisions based upon the results from the
* With set based development, teams may simultaneously develop several approaches to the same
problem and cherry-pick the best elements from each prototype. While this might appear to be a
waste of resources, it can be a very effective way to quickly deliver high-quality, innovative products that customers want.

Requirements
Analysis
Design
Code
Test
Deploy
Release
PDCA
Iteration 1
1–4 Weeks
for Each Cycle

PDCA
Iteration 2

PDCA
Iteration 3

PDCA
Iteration 4

Release

PDCA
Iteration 5

PDCA
Iteration 6

Release

Figure 8.3

The rapid iteration approach.

previous cycle. Each iteration* is a complete Plan-Do-Check-Act (PDCA)
cycle of problem solving.† The transformation of the traditional waterfall
to iterative development is illustrated in Figure 8.3.
Fine tuning the development process to support just-in-time releases usually drives improvements (speed, quality, cost, and flexibility) throughout
the value stream; this is analogous to the transformation which naturally
results over time as a manufacturer shifts from large to small batch sizes,
moving toward one-piece flow. For example, delays and changeover costs
from one iteration to the next can be dramatically reduced. Techniques
such as setup time reduction‡ and continuous integration§ can fundamen-

* Each iteration tests a small set of features in an offline system, which are integrated into periodic
releases and deployed to the customer.
† For more on PDCA, A3 thinking, and the scientific method, see Chapter 2.
‡ Introduced by Shigeo Shingo at Toyota, this technique seeks to reduce the setup time of each
batch, making it more economical to produce smaller batches.
§ Continuous integration is a rapid PDCA cycle where each member of the development team integrates his or her code frequently, leading to multiple integrations each day. This approach detects
problems early, reducing rework, delivery time, cost, and risk.

tally change the installation and upgrade process, making it possible to
rapidly apply small changes efficiently and with no business disruption.
Perhaps the most widely experienced example of one-piece flow in Lean
software development is demonstrated by Google, whose customers around
the world have learned to appreciate (dare we say expect?) frequent, smooth,
and surprising innovations, often released on a daily basis. Google associates are encouraged to invest up to 20 percent of their time pursuing new
ideas and product inventions, similar to engineers in the highly innovative
manufacturing company 3M. This investment of time has proven to be a
strategic driver of rapid product innovation and market share growth.
Google designers observe daily usage behavior, guiding future development
based on evidence of popular features and functions (voice of the customer).
These small, customer-driven innovations are often released in a matter of
days or weeks with little fanfare, and with few service interruptions.

Lean Software Development Life Cycle
Organization and Approach
The role of product manager * is responsible for the overall vision, design,
delivery, return on investment (ROI), and strategic alignment of the software that is being developed. This individual rarely has direct authority
over the entire team, in this matrix management role. The product manager guides the life cycle, owns the backlog, and balances customer requirements and production capabilities, often managing several teams—each
developing individual software components toward a consolidated product. He or she participates in daily standup team meetings and weekly
synchronization meetings across multiple teams.
Collectively, product managers are the primary linkage with the enterprise, synchronizing the pace of software development with changing
business requirements and continuous improvement activities. Each
product manager (and their delegates) should participate in enterprisewide kaizen efforts, coordinating IT involvement for his or her particular
software product with each business process owner.
* Other titles include product owner, on-site customer, and active stakeholder.

Each development team should be assisted by a facilitator* skilled in Lean
software development techniques, and with an objective perspective of the
project. Teams should be kept as small as possible,10,† while representing a
balanced voice of all customers and stakeholders. These multidisciplinary
teams should be composed of individuals with complementary skills,
where every person on the team has something to share and something to
learn from the others.
In the spirit of concurrent development, the entire team (representing all
stakeholders, including the customer) should operate in close proximity,‡
in a space designed to encourage team collaboration and workflow. This
is the application of Lean work cell design, where teams are aligned with
value streams and supported by pull signals and visual indicators. The
organization should avoid shared resources across teams whenever practical, for reasons we explored in Chapter 5. In the case of distributed teams
where physical co-location is not practical, virtual collaborative workspaces
may be used, but occasional face-to-face meetings are helpful to maintain
cohesion and overcome communication blocks. In all cases, team members should make regular trips to where the customer work is performed
(gemba) to reinforce their understanding of customer requirements.
Communications and measurements should be kept as immediate and
visual as possible.§ Visual displays of demand, customer stories, schedules,
project status, priorities, issues, and problems limit interruptions, keeping
the team focused on the essentials with minimal communications overhead. Electronic dashboards may be necessary with distributed teams, but
in our experience nothing beats the energy of a standup meeting in front of
a wall filled with storyboards, butcher paper, and overflowing with colorful
sticky notes, index cards, and discount pizza coupons.
Requirements Definition
The voice of the customer is an essential element in Lean software development, as the customers’ definition of value guides all activity. In this
* Other titles include scrum master, coach, and project manager.
† For an insightful look at optimum team size, and why adding more people does not necessarily
add value or reduce time and cost, see The Mythical Man-Month, 2nd ed., by Fred Brooks.
‡ The venue for co-location is known by many names: project room, war room, bullpen, and Obeya
room.
§ This approach is also known as the visual workplace, big visible charts, informative workspace,
and information radiators.

case, customer requirements guide the actions of the software development
team. The term customer requirements might be interpreted to suggest
that the customer controls software design decisions, and that there is a
separation between the problem, the design of the software, and its implementation. Consider instead the term design choices, which suggests that
the customer and software designers collaborate to understand the problem and develop countermeasures, which may or may not involve software
changes—this is problem solving versus solutions thinking.
First of all, who is the customer? This may be an internal customer,
someone within the enterprise who is processing transactions as part of
an internal workflow. In other cases, the application is used by external
customers, either to support their business relationship with the enterprise
(e.g., order processing or status inquiry) or as a commercially licensed
software product. In all cases the software development organization must
partner with internal customers, and/or representatives of external customers, ensuring all requirements are clearly understood and collaboratively addressed.
The old adage “The customer is always right” doesn’t necessarily apply
to Lean software development, at least not early in the life cycle. This is the
essential reason for the discipline of A3 thinking, since the immediately
apparent “solution” often addresses symptoms, but not the root causes.
The team should therefore respectfully assume that customers may not
initially know what they need, for several reasons:
• Customers may have strong opinions based on an incomplete understanding of the situation. They often don’t see or understand the
entire process, which includes the complexity hidden behind the user
interface and buried deep in the database, and the interdependencies
with other processes and systems. Comprehensive requirements are
thus uncovered by cross-functional teams using tools such as value
stream mapping, where the process is understood by everyone. Start
by asking not what the customer wants, but what the problem to be
solved is; this is A3 thinking.
• Despite their dislike for the old system that is being replaced, the
customers’ mental model of how the job is done, and how the overall
business process works, is based on their familiarity with the current
design. To many business users, the system is the process, and they
may have a difficult time separating the two in their minds. They may

also have a comfort level with the old system, however distasteful and
dysfunctional it may be, and the fear of change may subconsciously
distort how they visualize and articulate a new approach. The team
must help customers transcend their current mental model; otherwise,
the new application may end up behaving much like the old one.
• Different customers think differently; for example, a manager and
an operator may request something entirely different from the same
application. Similarly, expert users may require different capabilities
from mainstream and novice users; it is often the expert users and
managers who are the most outspoken about the system requirements, and mainstream users are left to struggle with unnecessary
complexity in their daily work. The team facilitator should ensure
balanced input while gathering requirements.
• The most important knowledge is often tacit: customers don’t realize
what they know. The team must go to gemba, carefully detecting the
customers’ intent and needs, but not necessarily their initial words.
It is often only through conversation, observation, and experimentation that customers realize what problems must be solved; this is
how breakthrough improvement and innovation often emerge.
The team may use a variety of information-gathering techniques to
discover the voice of the customer, in both qualitative and quantitative
terms. These techniques range from simple brainstorming sessions and
interviews to questionnaires, focus groups, and elaborate studies such as
the Kano method and quality function deployment (QFD).11,* Value stream
maps and other outputs from kaizen activity also provide essential guidance to software development requirements and priorities.
In order to translate customer requirements into software specifications,
the team gathers customer-generated use cases, stories, and scenarios,†
which describe desired user behavior rather than technical requirements.
In fact, the test case design process often helps customers clearly understand what they really need, helping them to visualize the new application
in the context of their daily work rather than theory. Thorough testing is
also essential to mistake proofing, since it challenges the customer to ask,
* For an in-depth look at these VOC tools and techniques, see Lean Software Strategies by Middleton
and Sutton, part 2.
† For more on customer scenario modeling, see www.agilemodeling.com.

“What can go wrong here?” Test scenarios are also important artifacts
that support documentation, training, and the iterative improvement of
the code long after initial release.
Demand Management
The product manager is responsible for managing the backlog, which is
a catalog of stories that identify discrete components queued for development, and the amount of time and effort they are expected to require.
Early in the process, T-shirt size rough estimates are often used (S, M,
L, and XL) to indicate the relative work content of each story. To balance customer demand with development capacity, each component
is assigned a capacity requirement estimate through a standardized
points system. Each point roughly indicates a standard unit of development duration.
There are many unknowns and variables to consider when estimating
points: degree of difficulty and complexity, interdependencies, skills of the
team members, and so on. At first, the product manager and the team may
struggle with estimating points, but after several cycles of feedback and
problem solving, their accuracy usually improves.
Each iteration period has a limit to the number of capacity points it may
be assigned, according to the team cadence (other names include velocity,
pace, and drumbeat). These are similar to a concept in Lean manufacturing known as takt time, where the pace of production varies according
to the rate of demand. However, with software development there is usually more backlog than capacity. So instead of speeding up and slowing
down according to a changing rate of demand, the team should develop
a cadence that is comfortable and sustainable over time. This results in a
level pace and a stable allocation of capacity points for each period.
When determining cadence, the team should agree upon available work
time, deducting downtime for regular meetings, training, preventative
maintenance, vacations, and other planned activities. Unplanned activities should not be factored into available work time; each interruption
should be investigated to identify the root cause to prevent reoccurrence.
A slack factor should also be deducted from available work time; this factor
should be in the range of 15–20 percent of available work time.12 Sustained
resource utilization above 80 percent is harmful to agility and productivity in general. Queuing theory and Lean manufacturing practice have

proven that there must be slack or else thrashing and quality problems
inevitably result.13 The slack factor is not excess capacity or wasted time—it
is intentionally unallocated time, a reserve to be used wisely, giving busy
teams and individuals a little breathing room to do the right things, and
do them right the first time.
The number of points that may be achieved for each sprint cycle is determined by the team based on this demonstrated cadence, not assigned
by managers. This is pull based on capacity, not push based on demand,
enabling the team to naturally maintain a level schedule where the workload is stable without disruptive peaks and valleys (mura)* over time.
With a level schedule, the team develops a steady work rhythm, avoiding
periods of overload (muri) that cause poor quality, low morale, burnout,
and turnover.
To maintain level demand, the development team and the customer
work together to prioritize the components to be included in the next
iteration. Negotiation is often necessary, and the product manager
should facilitate trade-off decisions among competing priorities, also
balancing technical considerations with customer requirements (see
also Chapter 5 on demand management). The team must also decide
how much time to allocate for defect correction—bug fixes and rework
looping. The severity of the issue and the service-level agreement status
should be considered when prioritizing corrections. During the backlog negotiation process, unnecessary features are also culled out; otherwise, they may remain on the backlog for endless cycles yet never
make it to production. The customer must decide when stories should
be removed from the backlog, but the product manager should encourage discipline—features left in the queue that will never get built are
waste.†
A requirement may be identified and prioritized, but there may be a low
degree of certainty in its work content, or how many capacity points it will
consume. Work should not be released to production until the significant
unknowns are clarified; otherwise, they will likely cause errors and delays,
which are catastrophic to just-in-time performance. According to Jeff
Sutherland, “[T]here are only two stable states: ready and done. The team
* Mura and muri are described in Chapter 2.
† The product manager may keep a backburner list of potential changes that are reviewed periodically, but should strive to keep the active backlog uncluttered, representing a limited number of
iterations.

shouldn’t let anything that’s not ready into the flow, and let nothing escape
that’s not done.”14 Additional analysis should be performed prior to inclusion in the backlog if points cannot be reasonably estimated. Fortunately,
if a component is deferred for more analysis, it doesn’t have to wait long
for the next iteration to come around. This is a key benefit of just-in-time:
the production cycles are very short, so work is inserted as needed into
the next iteration. If at the last minute work is resequenced, the cadence of
production is not affected, which explains how high-quality software may
be created with astonishing speed, and according to a customer’s immediate and changing requirements, while causing no disruption to the smooth
pace of development.
The disciplined ongoing process of planning, prioritizing, and sequencing the backlog is essential to maintaining a level schedule. The team,
facilitated by the product manager, should dedicate a significant amount
of effort to making sure the right decisions are made; backlog grooming
and subsequent sprint planning may require as much as 10–15 percent
of the total available work time for the product manager and some team
members. Placing the emphasis on more P (Plan) at the front end of each
cycle ensures less DCA (Do, Check, Act) is needed later—less development
time spent chasing half-baked solutions.*
Execution and Test Iterations
Once work is pulled into production (development and testing), it should
flow swiftly to completion without delays, interruptions, or defects. Lean
manufacturing practitioners have evolved flow into a fine art, even with
highly complex and variable products and processes—just like software
development. Here we will focus on two specific tools: kanban and heijunka, which we introduced in Chapter 5.
Kanban is a signal causing work to begin or to move to the next step of
production. Kanban pulls workflow by demand, rather than being pushed
by a predetermined schedule. In a factory where work is tangible, kanban
signals are often physical: cards, containers, flashing lights, or other signals. In Lean software development, kanban is usually implemented with a
* For a broader perspective on IT services demand management see Chapter 5; for an example of the
alignment of software releases with company strategy using Strategy Deployment (Hoshin Kanri)
see the Group Health case study.

wall-mounted board and note cards or sticky notes, with each card representing a component or story. A kanban board indicates the demand and
activity on a single team or project, so a development organization usually
has several kanban boards, each located near its team. Daily team standup
meetings center around the team boards (including the kanban and other
visuals), which also serve as a spontaneous gathering spot whenever a
question or issue arises. Daily discipline is required to keep the visuals
current, or else they quickly become useless and even counterproductive.
There are two types of kanban boards most commonly used in Lean
software development (Figure 8.4):
1. Backlog: Visually displays queued work, quantifying their relative
degree of difficulty, effort, and priority. This display provides the
customer, team, stakeholders, and business at large with the ability to
visualize priorities and sequence and understand backlog duration.
2. In process: Visually displays all components in development (build
and test) for the current iteration. While this may appear to be a form
of waterfall, these steps are tightly integrated and flow very quickly,
with the entire cycle typically lasting no more than a few weeks. This
visual display clarifies priorities, and prevents status inquiry interruptions and other unnecessary communications.
Heijunka (meaning level schedule) is a visual-scheduling tool that
enforces a steady sequence of work according to kanban pull signals.
In a factory or office, the heijunka box is a series of sequentially timed
slots, like a set of post office boxes (see example in Chapter 5, Figure 5.3).
Each slot represents a scheduled release, and kanban cards representing
jobs are inserted into the slots. When ready for the next job, the gateway (first) workcenter pulls the next card from the slot. This approach
is helpful when the content of the work being done (whether insurance
claims, lab orders, or software components) changes from one item to
the next, since each kanban card may carry individual specifications and
instructions.
In software development, the heijunka schedule is visualized with the
“In-Process Kanban Board,” shown in Figure 8.4. Stories in the backlog waiting for development may be scheduled and sequenced according to the cadence, thus providing a basis for the team to estimate
when the next story will be released to development. The total work

FLOW

7

Complete

Story #14
Short Description

6

Testing

Story #2
Short Description

4 Points
(green)

3 Points
(green)

3 Points
(green)

Story #22
Short Description

2 Points
(green)

Story #11
Short Description

4 Points
(green)

Story #4
Short Description

4 Points
BUG FIX (red)

8 Points
(green)

5 Points
(green)

Story #27
Short Description

3 Points
(green)

Story #19
Short Description

12

Coding

Story #4
Short Description

11

Ready to Code

Story #12
Short Description

Points:

Backlog and in-process kanban board example.

Pull

Story
5 Points

Story
2 Points

Story
4 Points

Story
2 Points

Story
7 Points

Story
3 Points

Backlog

Figure 8.4

RELEASE SEQUENCE

Requirements and Priorities

Customer


in process is illustrated by the total points on the board, and the flow
of work through the process may be viewed by the points at each stage
in the process—excess accumulation of points at a particular stage in
the process suggests a temporary flow impediment. When work stops
flowing, the heijunka release schedule falls behind, and kanban provides a visual sign of where the bottleneck has occurred. These signals
guide problem-solving efforts to identify and address the cause of disrupted flow: perhaps the scope of work is too large (points/hours underestimated), the balance of load and skills needs adjustment, someone
is interrupted or stalled, or myriad other things that can change or go
awry on a daily basis.
An alternative heijunka technique may be applied to Lean software
development, moving from a time-boxed iteration schedule (controlling
the amount of work released to production in each iteration) toward the
ideal of one-piece flow. With this approach, the team simply pulls the next
kanban card from the backlog as they’re ready for it. This works best for
routine tasks with few interdependencies. By continuously reprioritizing
the backlog as circumstances change (e.g., a critical bug is suddenly discovered), a steady stream of new work may be pulled into production at
any time, triggered by available team capacity. In a factory this evolution
may take years, and in some cases a true one-piece flow is never achieved
(and sometimes is not practical); nevertheless, one-piece flow is a perfection target toward which the Lean software development team may strive.
Customer Service and Support
In our experience, customer service and support is a critical element of the
development life cycle that is sometimes disregarded by both traditional
and agile software development practitioners. Voice-of-customer information is ideally gathered from the field as all customers (not just those represented on the team) use a deployed application. There is perhaps no better
place to gather this vital input than through the service desk (help desk)*,
providing an avenue for customers to identify potential problems, and submit enhancement requests to be considered in the development backlog.
For example, during the Lean enterprise transformation of one client,
we discovered an agile implementation where documentation and service
* For more on incident and problem management, see Chapter 7.

desk activities were still anticipating long, slow change cycles. What should
have been a closed loop was in fact two disconnected loops that were out
of phase: service desk staff were never certain of the current deployed state
of the software, since their documentation and training were often weeks
behind the agile release schedule. And since they had only limited visibility to the backlog, they didn’t know which problems and enhancement
requests had been reviewed by the team, and which had been approved
and placed in the backlog for development. In addition to causing internal
chaos, the customers were frustrated, with their problems unresolved, not
knowing when (or if) they were going to be addressed in the future. This
is a case where agile focused on the software development life cycle, but
disregarded the overall value stream.
Figure 8.5 illustrates a complete closed-loop customer feedback cycle
integrating development, communication and training, support, and ongoing kaizen activity. We know of one large company that requires members
of the development team to stand duty on the service desk whenever new
code is released, so they can hear the voice of the customer firsthand.
Measurements
Traditional software development controls and measures focus on
cost and schedule, reviewed periodically on a very large and complex
scale. Until development is performed on a scale that supports rapid,
iterative changes, both of these measures are virtually guaranteed to be
inaccurate, providing counterproductive guidance during the project.
And the act of performing these measures, using traditional detailed
push-scheduling tools, can be arduous and wasteful, leading to many
long project status meetings, lengthy and complex reports, and heated
arguments over the validity of the information. And since these traditional measures are lagging, not leading, indicators, they are of limited
use—signaling for corrective action to a problem that might have been
avoided in the first place.
Compared to traditional software development project management,
Lean software development measures are simple, visual, and immediate.
Just as in the Lean factory or office, because of small scope and rapid iterations, there should be little overhead spent on monitoring and reporting. Problems should call attention to themselves before they are out of


Backlog

Release Iteration

Document & Communicate

Service Desk

Problems
and
Enhancement
Requests

Voice
of the
Customer

Kaizen Activity

Figure 8.5

Closed-loop voice of the customer.

control and be addressed during the daily standup meetings (see also
Chapter 9 on Lean project management).
Ideally, the team should maintain just a few leading indicators (process
measures) that indicate the functioning state of the process, guiding proactive behavior, for example: backlog status, kanban boards, burndown
charts, and defect trend charts. When a deviation occurs in a leading indicator, the team should apply A3 thinking to solve the problem at the root
cause level.
The burndown chart is a common tool to keep the team on track, showing all tasks underway and their status, points or hours consumed, and
work remaining for each component. Ideally, the remaining points or
hours should represent a realistic estimate for the remaining work to be
done, rather than the initial estimate of total hours less time invested so
far, which may misrepresent the amount of remaining work. Significant
deviations between originally planned and final estimates should trigger
a root cause analysis in order to continuously improve estimate accuracy.
The burndown chart is often shown as two trend lines, one displaying the
planned schedule for the iteration, and the other showing actual progress.
The gap between the two lines is an effective early warning signal during
each day’s standup team meeting, helping the team respond quickly with
corrective and preventative action.


Implementation and Integration
Lessons Learned
We close this chapter with a few general observations about implementing
Lean software development.
There is active debate about the ability of Lean software development to
scale for large or geographically distributed teams, for complex products
requiring extended development timelines, or where multiple systems
must be integrated, especially with products developed by outside parties who are not practicing Lean. However the larger and more complex a
system is, the more capacity for change should be designed into it; otherwise, the cost of change and its negative impact on business agility will be
significant. Each case, of course, is different, with its own challenges to be
addressed. Lean software development is not a one-size-fits-all prescriptive approach, but an iterative cycle of experimentation and learning.
Similar objections have been leveled at Lean manufacturing over the
years, but the principles, though not necessarily specific tools, have prevailed in every type of situation. For example, the application of Lean
tools in a repetitive (high-volume, low-mix) production environment is
quite different from a highly engineered (low-volume, high-mix) factory.
Nevertheless, using A3 thinking, teams problem-solve their way to create
flow, often discovering new applications for existing Lean tools and techniques. Similarly, as Lean software development continues to evolve and
push the envelope of scale and complexity, generations of practitioners will
apply Lean thinking in new ways, sharing their discoveries with others.
This leads to the most important factor in the evolution of Lean software
development, as it supports the continuous improvement of the overall
Lean enterprise. In our experience with common agile practices in the
field, software development teams often do not receive formal problem
solving or Lean training, just an introduction to specific agile development tools and techniques. Nor are they regularly invited into kaizen
activities such as value stream mapping and gemba walks, and thus they
do not see the whole value stream, or the immediate problem to be solved,
from a business context. Software development teams should regularly
engage in business process improvement and problem solving alongside
the business, since most problems are caused by faulty processes, not software. This points to a fundamental shift in the traditional way that the IT

organization interacts with the business, which we explore throughout
this book.
Implementing Lean software development (and Lean IT in general)
comes down to each individual thinking differently about the way he or
she works, and the business context within which he or she adds value.
Leadership should anticipate initial resistance to such fundamental
change in thinking and culture. For example, teams often initially oppose
co-location within a bullpen setting, which is often perceived as a violation of their personal space. And there will always be some who challenge
the Lean approach every step of the way, for a variety of reasons.
In the CIO Magazine article “How to Instill Agile Development Practices
among Your IT Team,” CIO Jackie Barretta of Con-way sums up the spirit
of honesty and respect,
I made a rule that every person had to initially follow the practices precisely. I told them that as they became knowledgeable in the practices
they could tweak them, and when they really understood them they could
decide which ones to adopt. So far most people who have experienced the
practices have decided to adopt them for the long term.15

To effectively implement Lean software development, leadership must
establish conditions in which trust can develop. For so long, software
developers have taken the brunt of many jokes, and they are often the
scapegoats for project failure, complexity, and problems that originate
from faulty requirements and flawed business processes. Not that software development is blameless, of course, but teams must come to the
table with a spirit of openness, solving problems and improving processes while not blaming people. After all, Lean software development
naturally focuses critical attention upon uncomfortable issues within
the business processes that many would rather avoid. Honesty and trust
between the business and the IT organization are essential, or this simply will not work.
While product managers naturally take the lead role working directly
with the business, each member of the software development team should
have an opportunity to participate in kaizen events, going to gemba,
sharpening their Lean skills while developing a better understanding of
how the business works. The IT staffing plan must therefore include time
allocation for participation in ongoing Lean training and kaizen activities.

While this will not be easy, just like maintaining slack in production
capacity, the investment will ultimately pay off in many ways.
When all stakeholders, including IT, actively participate in kaizen activity, quality software releases will naturally align and synchronize with the
continuous improvement of the business processes that need them.

Endnotes

1. “Manifesto for agile software development,” www.Agilemanifesto.org.
2. Jeff Sutherland, “Foreword,” in Mary Poppendieck and Tom Poppendieck,
Implementing Lean software development: From concept to cash (Reading, MA:
Addison-Wesley, 2007), xviii.
3. Poppendieck and Poppendieck, Implementing Lean software development, 39.
4 Poppendieck and Poppendieck, Implementing Lean software development, 24.
5. Charles C. Mann, “Why is software so bad?” Technology Review, July–August 2002,
35–36.
6. Winston W. Royce, Managing the development of large software systems (Piscataway,
NJ: IEEE, 1970).
7. MIT Sloan School of Management, “Beer game,” http://web.mit.edu/jsterman/www/
SDG/beergame.html.
8. Tom Poppendieck, interview, June 29, 2009.
9. Christoph Steindl, “Lean software development,” IBM Global Services, PowerPoint
presentation, 2004, www.agilealliance.org/system/article/file/1422/file.pdf.
10. Frederick Brooks, The mythical man-month, 2nd ed. (Reading, MA: Addison-Wesley,
1995).
11. Peter Middleton and James Sutton, Lean software strategies (New York: Productivity
Press, 2005), Part 2.
12. Tom DeMarco, Slack: Getting past burnout, busywork, and the myth of total efficiency
(New York: Broadway, 2002).
13. Poppendieck and Poppendieck, Implementing Lean software development, Chap. 5.
14. Jeff Sutherland, “Ready: The dynamic model of scrum,” blog, July 4, 2009, http://
jeffsutherland.com/scrum/2009/07/ready-dynamic-model-of-scrum.html.
15. Jackie Barretta, “How to instill agile development practices among your IT team”, CIO
Magazine, January 14, 2009, www.cio.com

9
Applying Lean to Project Management

Chapter Objectives
An organization’s project management capability directly impacts the
pace and success of its Lean transformation. In this chapter we will consider how the principles and tools of Lean can be applied to achieve better
project results while reinforcing Lean thinking throughout the enterprise,
as we explore:
• The framework and benefits of conventional project management,
including portfolio management and the Project Management Office.
• How Lean principles complement the strengths of traditional project management.
• How Lean project management specifically applies to IT projects.
• The importance of Lean project management competence as it applies
to Lean enterprise transformation.

The Value of Effective Project Management
Anyone who has tried to lead a project, particularly an IT project,* knows
they are inherently complex, problematic, and risky. If not skillfully
* For the purpose of this discussion, an IT project is any temporary effort to deliver a technologybased solution (e.g., software development, application implementation, enhancement, or process
improvement).

193

managed, the typical IT project goes on longer than expected, costs more
than budgeted, encounters unexpected setbacks, and fails to satisfy stakeholders’ requirements and expectations. Underperforming projects draw
resources and focus away from daily operations. In most cases, project management is the means by which change is implemented—either
enabling the business or dragging it down.
Effective project management is about successful execution—getting the right work done and delivering value on time and within budget. Effective project management is an essential driver of continuous
improvement, operational excellence, and lasting change. Let’s be clear:
this discussion is not an indictment against professional project management. In most cases, it is not a failing of project management processes,
but the failure to apply project management processes properly, that leads
to failed projects.
Let’s set the stage by describing a hypothetical situation at
GreatServices, Inc. where a cross-functional team has been formed to
reduce IT service request delays. The team includes a sponsor, a project manager, and eight team members representing various functional
groups throughout the company. The project goal seems straightforward: the company’s associates need timely IT support to do their job—
break-fix, technical support, reports, new applications, equipment, and
so on—and current service request practices do not consistently meet
expectations.
The project sponsor requests an initial investigation. Using questionnaires and interviews, the team learns that to submit a request, some
departments rely on e-mail, fax, and phone calls, while others use manual
or electronic forms. After submitting a request, not everyone gets a confirmation that the request has been received. The IT staff explains they
don’t always know when a request has been submitted. As a result, service
requests often get lost and deadlines are missed.
Associates describe the process as “a frustrating waste of time.” Some
say they are occasionally surprised to have their requests met quickly and
can’t explain why the system works well only some of the time. One associate characterized the process as “hit or miss.” It’s clear to the team that
no standard service request process has been established.
On the supply side, IT service providers say they have no visibility of
their overall workload or available capacity and, thus, are unable to provide reliable service delivery dates. One manager exclaimed, “Our hands

Applying Lean to Project Management • 195
are tied!” The level of frustration is so high that some departments have
resorted to contracting expensive outside providers because they have lost
confidence in their in-house resources.
Based on their findings, the team concludes that service delays occur
primarily because the company doesn’t have a standard automated service
request system. Many of the people interviewed suggest that the right software system should provide the structure, functionality, and controls that
are currently lacking. The project manager develops a business justification for the purchase and installation of a software application to process
all IT service requests. The proposal is reviewed and approved by a capital
expenditures committee. Next, the project manager creates a project charter and project plan with a six-month duration.
Upon project approval, the clock starts ticking (it actually started ticking when the business customers initially became frustrated) and work
gets underway. The project manager submits weekly status reports to the
project sponsor that track the budget and task completion, highlighting any setbacks encountered or potential problems detected. A steering team (composed of the project sponsor, several directors, and the
project manager) meets every month to review project status and change
requests.
The project is eventually completed with mixed results, taking four
months longer to complete than anticipated, while exceeding the original budget by almost 50 percent. Although training sessions were held
and an online tutorial is available, users of the system say it’s userunfriendly, overly complex, and packed with features they don’t need.
In the end, many choose not to use the new system, developing workarounds and reverting to old methods. A postmortem is held to discuss
what went well and what didn’t. At the meeting, the CEO declares, “I
see this as a qualified win. It could have been much worse; at least the
system is up and some people are using it!” A final report is completed
and filed away.
Does this sound familiar? It’s a scenario that plays out every day in
countless variations. So what went wrong in this case, and what goes
wrong with projects in general? Simply this: people tend to jump at
solutions, bypassing the rigor of grasping the situation, identifying the
real business problems that need to be addressed, and understanding
root causes. In addition, the unexpected is almost always guaranteed to
take place. From the first thought that a project may be required to the

time the project is completed, myriad events and discoveries occur that
alter the assumptions and circumstances upon which the project charter and plan were created. Unanticipated events occur throughout the
life cycle of all projects: new stakeholders, additional requirements and
expanded scope, delayed decision making, internal politics, constrained
resources, project delays, and changes in funding. These unforeseen
changes, occurring suddenly and with little warning, are a major reason
why projects are often late, are over budget, and produce results that fail
to meet the customers’ changing requirements (see the CHAOS Report
in Figure 3.1).
In our experience, the root cause of project failure is the improper application of project management methods. In addition, many project teams
do not examine the value stream context of the problem or opportunity
being addressed. Thus, they are unable to properly diagnose the current
state and their “solutions” are predestined to fail. The telltale symptoms of
doomed projects include:
•
•
•
•
•
•
•
•
•
•
•
•
•
•

Poor understanding of stakeholder requirements
Right solution to the wrong problem
Wrong solution to the right problem
No strategic alignment
Conflicting priorities
No consideration of risks or formal risk management
Lack of user buy-in, trust, and resistance to change
Deficient user involvement
Inadequate resources and/or funding
Unrealistic timeline
Poor change/transition management and communication
Ineffective control of scope
Weak or missing user testing and acceptance
Insufficient monitoring and upkeep after go-live

For anyone who has been involved in a large-scale IT project, this list is
all too familiar. Before we consider how Lean complements and strengthens effective project management, let’s briefly explore portfolio, program,
and project management.

Portfolio Management

Align

• Strategic Alignment
• Prioritization

Program Management

• Project Management Oﬃce
• Standard Best Practices
• Managing Shared Resources

Plan

Project Management

Execute

r
de
Lea

• Tactical Management
• Escalation

m
Tea

m
ble
Pro

g
lvin
So

n
tio
lita
aci
&F

ard
nd
Sta

ls

kil

S
ean

L

rk
Wo

t
en
ym
plo
De
egy
at
Str

Tactical

Strategic

Figure 9.1

Portfolio, program, and project management.

The Project Management Body of Knowledge
The Project Management Institute (PMI)* has established a foundation of
practice upon which we can apply Lean thinking to augment project management practices. The Project Management Body of Knowledge (PMBOK)†
provides a framework that supports central Lean tenets including alignment, standard work, structured problem solving, and effective teams.
Lean principles and tools apply to all three levels of project management:
portfolio, program, and project, as shown in Figure 9.1. Organizations
require competence across all three levels to effectively align, plan, and
execute projects, allocating limited resources to best achieve strategic
objectives.
Portfolio Management
Beginning in the upper-right-hand corner of Figure 9.1, portfolio management focuses on “ensuring that projects and programs are reviewed to
prioritize resource allocation, and that the management of the portfolio
is consistent with and aligned to organizational strategies.”1 Its focus is
* The Project Management Institute establishes global standards and certifications for portfolio,
program, and project management. See www.pmi.org.
† In 1987, PMI first published A Guide to the Project Management Body of Knowledge (PMBOK), presenting the foundational concepts and standards that are applied to project management worldwide. The most recent fourth edition was published in 2008.

strategic, aligning and coordinating all projects and programs to fulfill
the overarching goals of the organization. In harmony with Lean’s strategy deployment (see Chapter 6), portfolio management takes a holistic
view of the company’s projects and programs (which represent investments in people, time, and money), attempting to balance priorities and
available resources with strategic objectives.
Organizations with ineffective or missing portfolio management capabilities are like an orchestra without a conductor—each section of the
symphony is playing their part but with no coordination, cadence, or
synchronization. The collective impact on the business can be disastrous,
leaving a trail of costly disappointments, conflicting priorities and effort,
overburdened resources, and poor morale.
Program Management
PMI defines a program as “a group of related projects managed in a coordinated way to obtain benefits and control not available from managing
them individually.”2 Program management is both tactical and strategic: tactical in that it focuses on coordinating the interdependencies
and resource requirements of related projects, and strategic in the sense
that it supports and directs associated projects toward shared objectives.
Program management allocates resources based on priorities established
at the portfolio management level. Organizations without effective program management are less equipped to purposefully assign resources to
those projects aligned with organizational objectives.
Unmanaged complexity and risk from project interdependencies increase
the likelihood of program failure. Program management addresses interdependencies between projects while ensuring coordination of resources
aligned with established priorities. Through the Project Management Office,
standards and best practices are established, giving project managers the
tools and support they need to effectively manage programs and projects.
The Project Management Office

The Project Management Office (PMO) acts as a Center of Excellence for
project management expertise and discipline throughout the organization.
A Center of Excellence provides standard practices, tools, templates, training, support, knowledge management, measurements, and infrastructure


Is Lean a Program?
We often encounter organizations that refer to Lean and/or Six
Sigma as a program when describing their efforts to become a learning organization pursuing ongoing improvement. In our experience,
labeling continuous improvement a program is a mistake as it sends
the wrong message to the organization. A program is similar to a
project: it typically has a beginning, a middle, and an end point. But
continuous improvement is a never-ending journey of experimentation and learning. Labeling Lean a program is at best misleading
as some associates may choose to “sit this one out,” anticipating the
changes to be short-lived. We prefer to call them initiatives, efforts,
methods, or ways (as in “the Lean way”).
for a particular domain of knowledge and practice such as Lean or project
management.
Depending on the culture and project management capabilities already in
place, a PMO sometimes works in a consultative role providing project management training, tools, and coaching. Alternatively, PMOs may also actively
coordinate and manage project resources, ensuring project management
standard practices are followed, monitoring project status, and intervening
if a project appears to be heading for trouble. Often PMOs assist senior management with portfolio management and steering team activities as well.
Project managers either are members of the PMO and assigned to functional areas of the business as needed, or they are permanent members of
the business who look to the PMO for standards, support, and additional
resources. Figure 9.2 compares each approach. A pool of project managers reporting to a central PMO strengthens consistency of project management standards and practices. On the other hand, project managers
directly assigned to functional areas develop a deeper level of understanding of business operations and stronger relationships with customers.
Operations which own permanently assigned project managers directly
control assignments and sometimes develop unique project management
tools and methods to meet localized needs—a good thing when these bestpractice innovations are then shared with the rest of the organization.
When project managers are centrally located, there is often a challenge
for the PMO to balance demand and supply of project managers (demand
management), necessitating enterprise-wide trade-offs. Some would argue

Project Managers Assigned
to Central PMO

Project Managers Assigned
to Business Units

Consistency of PM practices

Deeper knowledge of the business

Sharing of enterprise best practices

Sharing of business unit best practices

Access to coaching and support

PM practices customized to that business area

Enterprise Demand Management

Localized Demand Management

Central Control of PM resources

Direct Control of PM resources

Figure 9.2

Central Project Management Office (PMO) versus decentralized project managers.

this is preferable as long as trade-off decisions are aligned with enterprise
objectives, creating a dynamic, collaborative environment where choices
are acknowledged.
When project managers are located in functional areas, department
managers may independently make trade-off decisions when demand
exceeds supply, at times choosing between organizational goals, localized
objectives, or individual compensation objectives. In this case, without
an effective governance mechanism in place, there is a greater likelihood
that localized decisions may not be aligned with organizational priorities.
(We’ll address governance in Chapters 10 and 11).
Applying the principles and tools of Lean, the PMO can standardize
project management best practices across the enterprise, eliminating
wasteful non-value-adding activities while reinforcing the consistent use
of A3 thinking, customer-defined value, value stream awareness, and
Plan-Do-Check-Act (PDCA) problem solving. More on this later.
Project Management
PMI defines a project as “a temporary endeavor undertaken to create a
unique product, service, or result.”3 A project is goal oriented and consists
of a series of interrelated non-routine tasks. When projects are completed,
there is usually a handoff to operations.
Project management is defined as “the application of knowledge, skills,
tools, and techniques to project activities to meet project requirements.”4
PMI’s Project Management Body of Knowledge identifies 42 core project
management processes spread over five distinct phases (process groups)
shown in Figure 9.3.


The Disconnect between Strategy and
Execution: The Role of the PMO
IT organizations face the constant challenge of maintaining existing
information systems while keeping up with evolving customer requirements for information and a changing technology landscape, given
limited resources and unremitting pressure to control costs. But they
often lack a standardized approach for prioritizing projects, ensuring adequate capacity, effectively monitoring project performance,
and making timely corrective actions. These shortcomings are by no
means exclusive to IT and are often present throughout the enterprise.
Why do so many companies struggle with the strategic alignment of
programs and projects, and their successful execution? We often discover a disconnect between portfolio management and project execution, between strategy and tactics, intention and action. One Fortune
100 company formed a global project oversight group using state-ofthe-art portfolio management tools. Senior management was pleased
with their plan for strategic alignment of programs and projects.
However, there were no central oversight measures in place, nor
had standard project management practices been developed. Each
functional area (e.g., operations, IT, and procurement) and each geographic region was left to devise its own project management systems
and practices. Not only was alignment detached from execution, but
also every project was run differently. The company had not defined
standard project management practices, nor created support systems
to reinforce standardized work.
The consequence to the organization was inconsistent project
results, with no clear linkage between the defined strategy and
targeted results. Some projects were thoroughly planned and well
executed, delivering anticipated outcomes. Others applied informal,
improvised approaches rendering isolated successes mixed with
many disappointments and a few colossal failures.
What the company was missing were management systems and
standard processes to provide oversight and ensure that strategic
intent was distilled into aligned, prioritized projects that were consistently executed. Applied properly, effective portfolio, program,
and project management address these issues by providing the
framework and standard tools to proactively plan for and adjust to
competing priorities and relentless change.


Initiate

Plan

Execute

Close

Monitor and
Control
Figure 9.3

The five phases of project management.

The primary focus of project management is tactical—centered on task
execution through attention to scope, quality, schedule, budget, resources,
and risk. Experienced project managers may be familiar with another
popular definition for project management: having the responsibility to
create a miracle but not the authority to do so.
Most projects have some disruptive impact on the organization as they
divert resources and attention away from daily operations. When project
management is ineffective, the extent of the disruption is even greater and
expected benefits are often postponed or abandoned. The longer a project
languishes, the greater the cost in time, resources, and credibility, and the
more difficult it is to control scope, budget, and resources while maintaining focus on delivering customer-defined value.
In the past, project management concentrated most of its effort on
maintaining project schedules and budgets, emphasizing the administrative mechanics of defining tasks, monitoring progress, and reporting
status. In today’s complex and multifaceted IT projects, while traditional
project management skills are absolutely necessary, they are not by themselves sufficient. And, from a Lean perspective, as much as half of project
management tasks add little or no value and can be eliminated. Examples
include detailed status reports, excessive meetings, overly-documented
conversations, unshared analysis, and other information-gathering tasks
that do not improve project performance.
Lean principles and tools position the project manager and team for
success. As organizations seek to become more agile (see Chapter 4) and
find ways to remove time and cost from projects without compromising
on quality results, Lean principles and tools represent essential core capabilities. Project managers must see their role as evolving from an exclusive
focus on efficiency, completing projects on time and within budget, to a

focus on flexibility, quickly delivering incremental value to internal and
external stakeholders.
Beyond tactical project management skills, project managers must
develop proficiency in Lean thinking, facilitation, effective team building,
problem solving, and escalation. Escalation is the ability to sense when
an insurmountable barrier is approaching and to resolve it skillfully by
gaining the appropriate level of authority without alienating any stakeholders. Lean project management, driven by A3 thinking and management by facts, supports the art of escalation while minimizing internal
politics. Lean thinking focuses on problem processes, not problem people,
to address root causes, often removing resistance and strengthening trust.
Critical assessments become constructive when people are no longer targeted as part of the evaluation (i.e., shot for being the messenger).
Improving Project Management Results with Lean Thinking
As we’ve discussed throughout this book, organizational effectiveness is
created and sustained by continuous process improvement. Companies
that perceive problems (and projects) as opportunities to improve underlying processes are able to stay ahead of the competition. Frequently, however, project teams focus exclusively on the deliverables of the project: a
system upgrade, new infrastructure, or other tangible investment. While
these may be valid objectives, when teams fail to see the business process improvement opportunity, they miss the path to superior results. By
implementing a solution before thoroughly understanding problems and
improving underlying processes, they unknowingly increase the risk of
project failure. To avoid this common error, rigorous project management
should be augmented with Lean thinking, a focus on the less tangible
(but equally important) deliverables of process improvement—creativity
before capital.
One pragmatic client of ours, a seasoned project manager, observed, “On
the surface, some projects appear to offer very little process improvement
content; you just need to crank out the work.” In our opinion, all projects
are opportunities to work on process improvement while getting the work
done. Organizations that eliminate the distinction between performing
the work they do and improving how work is done develop the habit and
culture of kaizen. We like the motto: do your work, improve your work,
and improve yourself.

Information system project managers tend to come from technical
backgrounds and are likely to perceive a project as an implementation
(e.g., the delivery of an enhancement or new application), not a process
improvement project (e.g., streamlining the release management process).
Often IT projects are assigned a project manager but not a Lean facilitator, so their focus is primarily on the execution of predefined deliverables. Project management has developed formalized processes to manage
complex issues and avoid common pitfalls. However, some of the methods
used by today’s project managers inadvertently introduce inflexibility.
For example, extensive planning, documentation, and stakeholder
signoffs at the front end of a traditionally managed project can create resistance to change later in the project, suppressing much needed midcourse
corrections. Formal change control may require extensive documentation
and authorization. It’s understandable that project managers push back on
change: it’s additional work to change the plan and obtain another round
of signoffs. However, such resistance to change can inhibit the iterative
PDCA process of Lean and prevent a company from becoming a learning
organization focused on rapid cycles of improvement.
Project teams can become so focused on a fixed end state that they may
not pause to consider the root causes of problems. “That’s out of scope,”
they often counter. Such “get’er done” projects must return later to address
root causes (rework), or, even worse, the organization learns to live with
suboptimal results—both are wasteful outcomes. In fact, by not addressing
root causes, the project may introduce new inefficiencies and additional
layers of wasteful non-value-added work. This is a training and process
problem, not a people problem. Although they should be, not all project
managers are familiar with the principles and tools of Lean.
Looking at it from the other side, continuous improvement projects are
rarely assigned a skilled project manager. Companies often assume that
the individual leading a kaizen event or Six Sigma project possesses sufficient project management skills. Process improvement coaches facilitate
A3 thinking, value stream mapping, and iterative problem solving. Their
primary focus is on discovery and adjusting to new facts. These individuals are experienced in applying Lean principles and tools, but that does
not always translate into good project management skills.
The skills and focus of a seasoned project manager are significantly
different from those of a process improvement facilitator, including formal management of budgets, resources, risk, and issues escalation. Their

primary focus is on control and stability, and their skills are particularly useful when process improvement and IT projects extend beyond
departmental boundaries, require significant investment, utilize shared
resources, and introduce risk to the organization. However, many project management tools and methods are bloated with waste and add little
value. Project managers should learn to utilize Lean principles and tools
to reduce wasteful practices, improving project agility and responsiveness.
Figure 9.4 compares project management and process improvement skills.
So how does an organization provide effective Lean facilitation and
sound project management with limited resources? The PMO and the
Lean Centers of Excellence, through training and coaching, are the ideal
resources to ensure a suitable balance between control and flexibility.
In most cases, given adequate training and guidance, two people are
not necessary to fill the dual roles of project manager and Lean coach.
All the skills listed in Figure 9.4 can and should be developed in project
managers. Large, risky, expensive, cross-functional projects should be
considered for a designated project manager and one or more process
improvement facilitators.
When we review the performance of IT projects and continuous improvement efforts, often the key differentiator between success and failure is the
capability and skill of the facilitator (project manager, sensei, black belt,
coach, etc.). Project management delivers a proven framework for control, while Lean encourages flexibility and iterative team problem solving.
Effective organizations combine these competencies to consistently deliver
superior project results based on the bedrock of continuous improvement.
Project Management Skills

Process Improvement Skills

Control / Stability

Discovery / Flexibility

Project Planning

A3 creation and maintenance with team

Requirements Management


Budget/Risk Management

Root Cause Analysis

Resource/Change Management

Team-based Problem Solving
(PDCA or DMAIC)

Train and reinforce standard project
management methods and templates

Train and reinforce Lean/six sigma
principles and tools

Figure 9.4

Project management and process improvement skills.


Lean Project Management
Lean project management applies the core principles of Lean thinking to
reinforce the effectiveness of project management by emphasizing iterative discovery and problem solving, value delivery, and eliminating wasteful tasks, resulting in improved quality, reduced total elapsed project time,
and reduced project costs. To explore this further, let’s begin by describing
a conventional project management approach and then apply Lean thinking to shift the paradigm.
The Triple Constraints Model
Perhaps the most fundamental concept in project management is the
triple constraints model, which suggests all projects are limited by three
elements: time, cost, and scope. The classic adage here is, “We can complete the project quickly, be within budget, and have the deliverables you
want—pick any two.” Fortunately, the situation is often more malleable
than the cliché. As shown in Figure 9.5, the project management triangle
illustrates the principal of project management trade-offs.
If we change project duration, it is likely that costs will be affected. If
the budget is reduced, we may have to adjust the scope of the project. If we
increase the work content of the project to support an expanded scope, it
is likely to impact both time and cost. No element of the triangle can be
changed without impacting at least one of the other elements.
When managing constraints, the first course of action is to determine
the primary driver of the project and adjust accordingly. The art of project management is to blend these three factors to achieve the most critical needs of the organization. For example, if time is the most important
Time

Cost

Scope

Figure 9.5

The project management triangle, or triple constraints model.

aspect of the project, the budget might be increased to support more
resources and/or scope might be reduced.
Applying Lean Thinking to Project Management
Lean project management focuses on reducing overall elapsed project time
to break through the seemingly inherent tradeoff of time, cost, and scope.
Lean project management applies process improvement to both underlying
business processes and project management methods. As waste is removed,
the impact of the triple constraints is diminished. Projects that focus on
reducing total project time (versus individual task time) yield better quality results, in less time and for less cost, because improved quality translates into less rework.
The triple constraints trade-off remains but grows weaker as organizations adopt small, iterative project cycles to achieve targeted objectives. In
doing so, the organization is choosing what appears to be more time and
more cost, because more effort is invested in planning (P-DCA). In fact,
our experience shows that smaller scoped rapid-cycle projects yield better
results, in less total time and cost. As project work is done in rapid iterative
learning cycles, deliverables generate value at each cycle’s completion rather
than only at the end of the project. In addition, there is less work in process,
allowing simpler coordination of tasks and resources, while improving
agility and flow of the overall project to ensure early realization of value.
From a Lean perspective, the critical element that drives project success lies beyond the triple constraints: effective team engagement in root
cause analysis and iterative problem solving. A project can have sufficient
time, adequate funding, an appropriate scope of work identified, and an
engaged team, but without a team equipped to solve root causes of underlying process problems, the most skilled project management expertise will
not generate sustainable results. Project managers, facilitators, and team
members with the skills to see the whole value stream and grasp delivery
of value to customers and stakeholders have a more insightful context in
which to run the project.
All projects should apply Lean principles to the processes targeted for
improvement in order to identify the most appropriate course of action.
When projects start with a predetermined solution (like our GreatServices,
Inc. story at the beginning of this chapter) without initially examining and
improving underlying processes, the inevitable outcome is more efficient

throughput of broken processes—more unsatisfactory results delivered at
a faster pace! This is particularly true with IT projects.
Lean should also be applied to remove non-value-added work from all
phases of portfolio, program, and project management. We typically find
wasteful practices in many activities throughout the project life cycle,
including project administration, reporting, expediting, and documentation. At the project execution level, by eliminating wasteful project management tasks, more time is available to develop countermeasures, test
results, and put improvement ideas into action. Wasteful project management practices include activities such as lengthy and unproductive project
status meetings, collection of redundant or useless project data, and documents (stakeholder requirements, risk analysis, etc.) that are created but
never referenced during the project.
Two common non-value-added practices are detailed schedule maintenance, which is not used to monitor and make adjustments to the project,
and the preparation of consolidated weekly status reports, which are disregarded by senior management until a major problem has been flagged.
Besides introducing non-value-added work, these periodic “push” reports
create an artificial separation between those controlling project information
and the team members and stakeholders who need access to one another.
In a Lean environment, the project team would rely on an obeya room to
communicate project issues on a real-time basis (obeya is Japanese for big
room). The approach is similar to a project war room used as a central meeting place to co-locate team members for the duration of the project. However,
the focus here is on collaboration and communication. The walls (physical or
virtual) of an obeya room are covered with visual charts and graphs depicting project issues, A3s, and other devices communicating actual progress
versus the plan, burn down status, countermeasures, and other useful information. Rather than standard weekly meetings, members of the cross-functional team meet daily, using standup meetings (huddles) to discuss current
issues and challenges as they arise. The goal of the obeya room is to speed up
the PDCA cycle by making information accessible to all team members, so
the team can detect and solve problems as early as possible.
A3 Thinking

A classic maxim in project management maintains that organizations
that fail to define project goals and objectives unknowingly plan to fail.
Project management often begins with predefined objectives and applies

a standard methodology to implement the solution. Often these projects
focus on symptoms rather than root causes. Before contemplating an IT
project (or any project, for that matter) with a predefined solution, organizations should take a step back and clearly define the problem they are
attempting to solve. A3 thinking is about having the awareness and tenacity to move beyond symptoms to take on root causes.
A3 thinking is the consistent application of PDCA problem solving to
identify the best course of action to address challenges and opportunities.
A3 thinking guides the team’s activities toward a well-defined problem or
opportunity and simultaneously builds flexibility into the project. As new
facts are uncovered, project objectives are modified to meet actual needs
instead of planned needs. Defining measures of project success up front is
critical, so everyone can buy into the expected outcome/benefit. However,
activities and performance targets evolve based on the team’s understanding of how effectively current processes deliver value as defined by the
customer; this is the essence of agility.
Flexibility in developing solutions based on reflective observation is a
central principle of A3 thinking. Consider a project to implement a new
invoice payment system. Applying A3 thinking and PDCA, the team discovers the software application works fine but current procedures include
excessive steps and redundant authorizations, adding delays and errors
to the process. It is essential that the project sponsor supports the team’s
evidence-based decisions as their understanding of the facts changes.
When the team meets with the sponsor and shares its findings (through
an updated A3), it is the role of the sponsor to critically challenge—and, if
convinced, support—the team’s recommended course of action. This may
mean abandoning the initial “solution,” which can create some pushback
from stakeholders in the organization. It is the project sponsor who should
address these issues, allowing the team to remain focused on grasping the
situation, seeing the flow of quality work, developing countermeasures,
and making improvements.
Both conventional and Lean project management focus on doing the
right things (leadership) and doing them right the first time (management).
Traditional project management creates a detailed work breakdown structure early in the project for budget and tracking purposes.* In Lean project
management, work tasks are also assigned, but they are expected to change
* See PMBOK Guide, 4th ed., Section 3.2.

based on discovery, rather than being entirely predefined. Lean provides
the tools to support that flexibility. Applying PDCA creates a mechanism
to do the right things at the right time. Lean project management means
having the appropriate level of structure and control to enable progress
toward measurable targets. Work assignments adjust based on the discovered facts. As teams verify that countermeasures produce desired results,
emphasis shifts from problem solving to solution implementation.
It’s important to note that, unlike a project, continuous improvement
never ends; it simply begins another cycle. The focus of the next cycle is
based on the results of the last cycle. If results are less than desired, another
round of PDCA is started. If the results are satisfactory, sustaining measures are put into place to monitor performance and warn of deviations.
Focus then shifts to another round of improvement effort based on the
organization’s priorities.
In our story at the start of this chapter the predefined objective was to
improve IT service request response time, and the team’s “solution” was
to install a software application. Had the team started with A3 thinking,
seeking to grasp core process problems, they would have discovered that
process changes were necessary prior to evaluating a new technology intervention. Once consensus had been reached on the problem and improvements had been made to the underlying business processes, a clear and
accurate determination of appropriate software (if needed) would have
been possible.
There is tremendous leverage when IT professionals apply A3 thinking skills and engage in the entire PDCA process—rather than just the
D (Do). This shift in focus sounds very simple but is fiendishly difficult to
accomplish.
Often organizations adopt the A3 form but not A3 thinking. The A3
form, an example of which is shown in Figure 9.6, is a valuable tool to
communicate the extent of the teams’ understanding of the situation,
project objectives, timelines, status, and results. A3 formats vary; however, the form should be viewed as a representation of the engagement,
discovery, understanding, and problem-solving process experienced by
the team or individual. When used to communicate project issues, experienced project managers new to the A3 are often surprised by its simplicity
and effectiveness. (See Appendix D for a sample completed A3.)
When project managers augment the strengths of established project
management practices with Lean thinking, project results are realized

One example of an A3 form.

Figure 9.6

Problem Analysis (Root Cause)

Current State

Boundaries
In:
Out:

Theme

A3

1)
2)
3)
4)
5)
6)
7)
8)

Parking Lot

Target Outcome

Value Realized

When

Who

Who

Implementation Plan - What

Testing - What

Countermeasures to Test

Future State and Target Measures

Date:
Sponsor:
Coach:
Team Lead:
Team:

Due Date

Actual Outcome


Conventional Project Management

Lean Project Management

Tactical execution

Strategic alignment /

Task completion

Value creation/Problem solving

Fixed

Evolving

Initial analysis, then reactive

PDCA, proactive

Stability

Agility and repeatability

Focus
Daily Directive
Beneﬁts Deﬁnition
Change / Risk Management
Emphasis

Figure 9.7

Leveraging conventional and Lean project management.

more quickly and are better aligned with customer requirements. While
these principles may not be new to project management, they need to be
reemphasized. As shown in Figure 9.7, Lean enhances project management through its emphasis on alignment, customer-defined value, iterative learning, and agility.

In our GreatServices, Inc. story, a group of people form a team and
quickly reach the conclusion that a new software application is required.
Perhaps the need for a new system was assumed even before they started.
Without a defined approach to analyze the current situation, teams rely
on personal experience, bias, isolated incidents, and anecdotes to develop
an understanding of the problems they are tasked to solve. Team members with strong verbal skills and compelling stories may unduly influence team opinion, inhibiting thorough analysis and discovery. Armed
with the best intentions, it is only human nature to identify the solution as
quickly as possible.
Deming said, “Management of a system requires knowledge of the interrelationships between all the sub-processes within the system and everybody that works in it.”5 Value stream mapping graphically depicts the
interdependencies of processes, providing the insight needed to develop
innovative countermeasures to address root causes of problems. Mapping
the value stream enables the team to identify non-value-added (wasteful)
steps in the process, quality issues, and where work does not flow. Clearly
understanding what current information systems provide in the context

of value creation is priceless. Value stream mapping also enables the team
to identify, and potentially quantify, the value of the project deliverables.
The focus shifts from delivering features to delivering value.
Project teams that use value stream mapping develop a common language to describe the problem, building consensus and team chemistry.
Once the team has a solid grasp of the current state, seeing the whole and
quantifying the problem from an overall systems perspective, they are
in position to develop potential countermeasures and prioritize efforts.
In most cases, project objectives and deliverables should not be finalized
until value stream mapping has been completed.
Plan-Do-Check-Act, DMAIC, and Project Management
The nature of project management is the timely execution of a solution
to address a need, opportunity, or problem. All project management
includes some form of problem solving, usually a great deal, but when
teams encounter problems, responses range from ad hoc, shoot-from-thehip reactions to methodical, structured problem solving.
Project managers should be aware of Lean and Six Sigma tools and
methods. Figure 9.8 shows the five phases of project management matched
with Lean PDCA, Six Sigma DMAIC,* and some of the supporting tools.
The following sections explore this in order of the five phases of project
management.
Initiate

The Initiate phase corresponds to the Plan stage of PDCA and the Define
stage of DMAIC. During the initiation of the project, Lean and Six Sigma
practitioners seek to understand voice of the customer to develop a
thorough understanding of stakeholder requirements—avoiding a common source of project failure.
Project managers have always been aware of the importance of stakeholder requirements—this is not a new idea. The difference with Lean
project management is the emphasis that is placed on identifying and
validating customer requirements throughout the project life cycle.
* We discuss PDCA (Plan-Do-Check-Act) in Chapter 2 and Six Sigma’s corresponding DMAIC
(Define-Measure-Analyze-Improve-Control) in Appendix B.


Lean PDCA

Six Sigma
DMAIC

Initiate

Plan

Define

Plan

Plan

Measure/Analyze

Execute
Monitor and
Control
Close

Do
Check/Act

Improve
Control

Act

Control

Traditional PM

Lean/Six Sigma
Tools
A3 / Voice of the
Customer / Gemba
PDCA / Root Cause
Analysis / VSM
Micro-PDCA
SMART Targets /
Statistical Analysis
Lessons Learned /
Hansei

Figure 9.8

Five phases of project management, Plan-Do-Check-Act (PDCA), and Define-MeasureAnalyze-Improve-Control (DMAIC). VSM is value stream mapping. Lean/Six Sigma
Tools are explored in Appendix B.

Often stakeholder requirements are defined by the project manager or a
small part of the project team. Once gathered, a report is created, filed,
and a checkbox is marked complete. The entire team may not even see
the final report. Employing voice of the customer, Lean involves stakeholders and team members at a more intimate level throughout the project. With each PDCA cycle, customers are reengaged to further define
value, validate understanding, and adjust to changing needs. This can
only be accomplished when teams proactively engage with stakeholders
and customers.
Far too frequently, teams perform their analysis of the current state
without leaving the comfort of the team meeting room to talk with the
people performing the work, those who supply the inputs, and those who
receive their output. Lean stresses going to gemba, where the work is actually performed and value created, to witness firsthand the flow of information and work, to see what’s really happening. Project teams should go
to gemba regularly throughout the project to validate facts and develop
deeper levels of understanding. In IT, this also includes observing users as
they work with applications and walking through processes with associates step by step.
In multisite organizations, frequent visits to gemba may be impractical. The next best alternative is to regularly share the latest A3 and value
stream map with other sites and follow up with conference calls and videos of gemba visits. Use technology to stay close to your stakeholders,

deepen your understanding, and hear the voice of the customer. A webbased obeya room is also effective to communicate issues and project status across multiple locations.
Plan

In some organizations, planning is perceived as delaying real project work
(execution) so we rush through the planning stage in order to get busy.
The problem with this approach is that we end up mistaking activity for
productivity. It’s counterintuitive to many, but to speed up a project and
successfully deliver value, you must first slow down! A common misperception is that the Plan-Do-Check-Act cycle is divided into four equal
quadrants, each taking roughly the same amount of time. The left side of
Figure 9.9 shows this common understanding, although in many organizations, planning doesn’t even receive 25 percent of the total elapsed
project time.
As shown on the right, more time should be invested in planning activities than in the other three steps combined. Projects have a significantly
greater chance of success when teams thoroughly grasp the current state,
go to gemba, understand stakeholder value, gather data, measure activity,
and develop and test multiple countermeasures (all planning activities).
As the duration of a project increases, the chance of project failure also
increases. Companies that apply Lean project management divide projects
into shorter phases (this is also discussed in Chapter 8 as an element of
Lean software development). To reduce risk, we recommend decomposing
larger projects into 90-day stages of limited scope and specific milestones.

ACT/
ADJUST

PLAN

ACT/
ADJ
CHECK
DO

CHECK

DO

Figure 9.9

Plan-Do-Check-Act time allocation.

PLAN

This simple technique maintains team focus on current problems and
deliverables, creating a sense of urgency while reinforcing the need for
effective teamwork.
Shorter projects with a focused scope reinforce iterative learning and
adjustments based on facts. In the Harvard Business Review article “The
Truth about IT Costs,” Susan Cramm explains, “Limiting project scope
makes projects less risky and more likely to succeed. That, in turn,
increases buy-in for subsequent stages.”6 This is not a Lean project management invention, but it is Lean in its approach: rapid iterations support
rapid discovery and superior results.
Organizations need to be aware of cultural implications when adopting shorter, iterative-cycle projects. Many companies are accustomed to
using fixed scopes, budgets, and schedules to hold people accountable for
results. In order to gain buy-in and support, senior management must be
comfortable with an iterative rapid-cycle approach. While accountability
is created with smaller scopes and project phases, some cultures are not
initially comfortable with a more fluid, recursive style. In Lean organizations, as shorter cycle projects become the norm, the PDCA cycle becomes
standard practice.
Both Lean product development and Lean software development utilize rapid project cycles. Each development round represents a complete
PDCA problem-solving cycle. As cycles increase (duration decreases while
speed increases), so do the learning, understanding of root causes, and
value generation. For example, Lean software development (also known as
agile, see Chapter 8) has transformed software development from lengthy,
broad-scope, big-bang projects lasting many months (or years) to nimble,
customer-driven, limited-scope, iterative development efforts lasting
weeks or months.
During the Plan phase, Lean and Six Sigma stress current state measurement and analysis. Root cause analysis directs our focus beyond symptoms to systematically address the origins of problems. This is the heart of
A3 thinking and PDCA, which are reflective in nature; an improvement is
made, and based on results, the next step is determined. Two of the most
effective root cause analysis methods are Five Whys and the Fishbone
Diagram (see sidebar “The Five Whys”).
Value stream mapping plays a central role during the planning phase
as the team grasps the current situation, builds consensus, and begins to
develop potential solutions. During mapping the gathering of baseline


The Five Whys
The Five Whys is the simple method of asking, “Why?” repeatedly until the root cause of a problem is uncovered. Normally the
root cause is reached by the time we ask the fifth why. When the
team believes it has identified a root cause, it works backward using
“Therefore…” to test its logic and ensure it hasn’t missed a step in the
sequence. For example, if the team investigating IT service request
delays would have used the Five Whys, it might have gone as follows:
Service Requests are delayed and cause
disruption to operations. Why? (#1)

Service Requests are delayed and cause
disruption to operations.

Because IT departments are unable to handle service
requests on a timely and accurate basis; their system
of logging, scheduling, performing, and delivering
services is inadequate. Why? (#2)

IT departments are unable to handle service requests
on a timely and accurate basis; their system of logging,
scheduling, performing, and delivering services is
inadequate. Therefore...

Because diﬀerent request formats and delivery systems
are used, this creates confusion, missing information
from requestors, and a lack of visibility for the service
providers. Why? (#3)

Requests diﬀer in terms of format, information and
delivery method, which creates confusion, missing
required information, and a lack of visibility for the
service providers. Therefore...

Because there is no standard procedure for submitting
and processing a request. Why? (#4)

There is no standard procedure for submitting and
processing a request. Therefore...

Because no standard procedure has been created.

No standard procedure has been created. Therefore...

Had the team performed root cause analysis, it may have discovered that there was a need for improving underlying business
processes and developing standard work before considering technology-based solutions (a common theme throughout this book).
The Fishbone Diagram
The fishbone* diagram is an effective tool to identify potential causes
of a problem. In the following diagram, the goal (improve IT service
request response time) is analyzed using categories to identify and
organize inputs and possible causes—in this case, people, process,
technology, and information. Other categories might include measurements, information, policy, equipment, materials, maintenance,
* The fishbone diagram was invented by Kaoru Ishikawa in the 1960s and is also known as
an Ishikawa diagram or cause-and-effect diagram.


suppliers, systems, management, regulation, culture, and environment. Teams begin with a blank diagram showing only the fishbone
skeleton and the problem, event, or goal. The team then applies
brainstorming to fill in the diagram. Brainstorming is a problemsolving approach where a group defines a problem or goal and then
captures as many ideas as possible around the potential cause or
solution. The focus is on collecting ideas with no filtering, criticism,
or evaluation during the brainstorming session. The power of this
cause-and-effect analysis is that it sets the context for improvement,
so technology and automation are not the first reaction.
Process

People
Documentation

Training

Service Request
Process Deﬁnition

Provider
Tasks

Availability
Staﬃng

Skills

User
Tasks

Overload

Functionality
System Response
Time

Service
Request
System

Resource
Assignments
Accuracy

Performance

Server Uptime

Maintenance
Technology

Load vs. Capacity

Alerts

Project Backlog
Report

Lengthy IT
Service
Request
Response
Time Causes
Business
Disruption

Visibility

At-Risk
Requests

Information

Once the team has identified potential causes, and themes begin
to emerge, it begins to envision potential improvements, develop a
future-state value stream map, set targets, prioritize efforts, and take
action.
data helps teams to truly understand how information, work, and materials flow to the customer to deliver value. The current and future state value
stream maps are updated throughout the project as facts are gathered and
comprehension deepens.
Before project execution, the team gathers baseline data for all targets,
providing a fact-based starting point from which to assess project gains

and accurately apply PDCA. Teams often overlook this step in their excitement to begin making improvements. In our experience, discoveries during the collection of baseline data lead to a deeper grasp of the current
situation, a fine-tuning of the measurements to be used, and ultimately the
development of more effective countermeasures.
Lean encourages the use of SMART targets, an acronym which stands
for specific, measurable, actionable, realistic, and time-based. For a measurement to be actionable, the team must have the accountability, responsibility, and authority to make improvements. In the Plan phase, during
the creation of the A3 (or problem statement within a project charter), the
team develops project metrics and works with the project sponsor to reach
agreement on SMART targets.
Many process improvement projects do not require the sophisticated measurements or precise statistical analysis offered by Six Sigma.
However, when projects involve reducing the variation of a process,
especially high-volume and transactional processes, statistical analysis
may be appropriate. For example, returning to our hypothetical project
to improve IT service request response time, statistical analysis could be
used to assess such factors as the day of the week the request is made,
or the type of service requested, to determine how strongly each affects
response time. By ranking the probability * of the correlation between
the cause and effect of different variables, teams use statistical analysis
to isolate root causes and prioritize improvements efforts.
Execute

By the time the team has reached the Execution phase, predictions have been
made, and potential countermeasures have been developed, tested, and prioritized. In addition, baseline data have been gathered and measurements are in
place to objectively assess the impact of the improvements about to be made.
During implementation, project teams are constantly responding to change and
making adjustments. What is often missing is a closed-loop feedback discipline
to assess the impact of actions taken, validate results, and provide the basis for
future actions. During these phases, Lean project management employs rapidcycle micro-PDCA to accelerate problem solving. Ideally, each successive cycle
is faster and more focused than the last. Figure 9.10 illustrates this relationship.
* Six Sigma uses hypothesis testing to determine the probability that the correlation between
dependent and independent variables is due to random chance.

PDCA Level of Effort
ACT

Micro-PDCA

CHECK

(Do / Check
testing cycles)

PLAN

DO

PDCA Level of
Effort
ACT

Plan

CHECK
DO

PLAN
PDCA Level
of Effort

Execute

ACT
CHECK

DO

PLAN

Monitor &
Control
Figure 9.10

PDCA applied at three phases of the project life cycle.

Monitor and Control

During the Monitor and Control phase of a project, measurement of
targets against baseline data collected during project planning provides invaluable feedback with which to make course corrections and
adjustments. Lean and Six Sigma provide a rich set of measurement
techniques ranging from simple observation and checklists to advanced
statistical analyses.*
To effectively monitor and control the impact of unforeseen events and
planned change, PDCA is applied at a micro level,† making a complete
cycle within the project execution phase (see Figure 9.3). Figure 9.11 compares proactive PDCA with the informal reactive system we frequently
encounter.
* See Six Sigma Statistics with Excel and MINITAB, by Issa Bass.
† Macro-PDCA refers to the entire process of solving a problem, from problem definition through
implementation and adjustment. Micro-PDCA loops occur within the testing cycle of each proposed countermeasure—the iterative Do-loops within the macro-PDCA cycle.


Planned
Activities
Plan
Missing Feedback
No Act/Adjust
Step

Plan
Do

Check

Unforeseen
Events,
Change

Act: Gather
Feedback,
Assess
and Adjust

Act

Do
Check

Reaction/
Response
Reactive

Proactive

Figure 9.11

Reactive versus proactive project execution, measurement, and control.

The left side of the illustration depicts the reactive approach to unforeseen events and the impact of unanalyzed change. Without feedback
and intentional evaluation, the energy of the team is spent responding
to unanticipated events. These projects experience a self-inflicted chain
of reactive activity (unplanned work), distracting the team from delivering value, causing delays, and increasing costs. Project management
frequently includes a formal assessment of results, but this is often at the
end of the project. Our experience suggests that the degree to which project teams proactively gather feedback and assess the impact of change
during the project varies greatly. Lean addresses this issue head-on with
micro-PDCA.
On the right side, proactive Lean execution, measurement, and control
are shown. Based on the scientific method, the appropriate next step is
determined by observed feedback. Simply by closing the loop, reflection
and learning take place. Projects that apply this rigor stay focused, making
informed adjustments based on the facts.
Close

The final phase of project management hinges on the acceptance of project deliverables by the system users, process owners, customers, and other
stakeholders. A review meeting usually is held to identify lessons learned—
what went well, what challenges were encountered, and what was learned

along the way. Process documentation is updated, and project records are
completed and archived. Often lessons learned are filed away and never seen
again. Lean uses lessons learned to make adjustments, applying continuous
improvement to project management practices— standardized work. Some
organizations utilize knowledge management systems to share lessons
learned in order to leverage the experience in other projects and situations.
Lean project management goes beyond lessons learned by applying the
concept of hansei—Japanese for mindfulness or critical self-reflection.
From an individual perspective, you could say hansei is personal kaizen.
Hansei cultivates an awareness of your own behavior, reflection on your
mistakes, and mindfulness of your impact on others. Hansei is being
honest with yourself about your own limitations and assuming personal
responsibility to improve. They say there is no kaizen without hansei—you
must identify your weaknesses before improvements can be made.
In Lean project management, hansei is performed by the team at key
milestones throughout the project and should also be done frequently on an
individual basis. In fact, the most effective project managers practice hansei every day, continually learning from both their successes and setbacks.

Lean Project Management Enables
the Lean Enterprise
At its core, the Lean enterprise is a learning organization. Critical selfreflection cultivates learning. Hansei also emphasizes humility; a Lean
enterprise is infused with an organizational humility that moves beyond
defending individual positions and ownership of ideas, serving the greater
goals of the team, the organization, and its customers.
Lean IT and Lean project management reinforce Lean thinking and
behavior through the planning and execution of information systems.
Waste is removed from information flows, supporting efficient value creation and the unconstrained flow of value to the customer.
Lean project management is an essential component of Lean enterprise
transformation. Important not only to large projects, it is a mental discipline necessary for small kaizen events as well. For complex, cross-functional, high-risk projects, sound project management is indispensable, but
it is not enough.

Think of a challenged or failed project you have experienced or are
familiar with. Returning to our list of reasons why projects fail (presented at the beginning of the chapter), ask yourself how many of
these hazards could have been avoided if the focus was placed first on
understanding and solving underlying process problems through the
routine application of A3 thinking, voice of the customer, PDCA, and
value stream mapping integrated with sound portfolio, program, and
project management.
Applying the principles and tools of continuous improvement, Lean
complements the power of conventional project management. Focusing
on strategically aligned tactics and value creation, project managers and
teams leverage Lean thinking to generate superior project results on a
repeatable basis. Lean project management is a capability that should be
encouraged across all levels of the organization.

Endnotes

1. Project Management Institute, A guide to the project management body of knowledge
(PMBOK guide), 4th ed. (Newtown Square, PA: Project Management Institute, 2008), 9.
2. Project Management Institute, A guide, 9.
5. W. Edwards Deming, The new economics for industry, government, education, 2nd ed.
(Cambridge, MA: MIT Press, 2000), 50.
6. Susan Cramm, “The truth about IT costs,” Harvard Business Review, March 2009,
http://hbr.harvardbusiness.org/2009/03/the-truths-about-it-costs/ar/pr.

Section IV

Leadership Roadmap

10
Leading the Lean IT Transformation

Chapter Objectives
In this chapter we will examine the nature of transformational Lean leadership, effective management systems, and the information systems that
support them. We will:
• Examine the importance of clear strategic intent in guiding a Lean
transformation.
• Explore the Lean management state of mind.
• Establish the importance of leader standard work, and the essential
Lean management systems from an IT perspective.
• Learn how to focus Lean IT change efforts on those factors that drive
innovation and competitive advantage.

How to Launch a Lean Enterprise Transformation
So your organization has decided to embark on the Lean journey. Or perhaps someone in your organization has already started. You’ve probably
heard the stories of enthusiastic change efforts that somehow lost momentum, gradually slipping back into old habits. You want to avoid this common fate, doing what it takes to achieve escape velocity, launching yourself
toward a self-sustaining Lean enterprise transformation.
227

So what is it you’re escaping from? Like the relentless pull of gravity, there are many sources of inertia that keep organizations firmly
entrenched in wasteful behaviors: complexity, complacency, commandand-control management, silo thinking, and conflicting measurements
and incentives—backsliding into these old habits is a serious threat to a
Lean transformation.
In our experience, most transformations begin with a focus on Lean
tools, to establish new behaviors and demonstrate quick results. Small
teams are given basic training, then concentrate on pilot projects in
known problem areas. Led by skilled coaches, these energized teams
harvest low-hanging fruit. They rapidly establish initial momentum, promoting early successes to build the widespread awareness and support
necessary to expand the effort enterprise-wide. But following this initial
launch, an organization must follow along with practical, standardized
management systems to sustain progress, and with shared values, principles, and strategic direction to guide continuous, organic, inside-out
improvement efforts.
Consistent with our own experience, the Shingo Prize finds that organizations usually begin a Lean transformation at the tools and techniques
level (the “know how”) in specific areas of the organization. Ideally, the
Lean journey then proceeds to the systems level, creating a more integrated
and sustained improvement model. Eventually all employees develop a
deeper understanding of principles (the “know why”).1 At this point, the
organization is learning to see waste across entire value streams, as they
begin adapting Lean to their own culture.
Experience has taught many Lean practitioners that while tools are relatively straightforward to learn and implement, they alone do not sustain
transformation. While some companies may eagerly claim early victories,
declaring themselves Lean by demonstrating proficiency with tools and
heralding localized successes (islands of Lean in a sea of waste), many
eventually slip back into mediocrity.
Introducing Lean management and information systems requires discipline, time and reflection. Lean principles are even more difficult to
embrace, yet they eventually come to influence behavior throughout the
enterprise. Values and principles must have time to become internalized
within the unique culture of each organization. Nonetheless, it is difficult
to begin with values and principles alone, because they are intangible. In
order to achieve a sufficient escape velocity and trajectory, an organization

Leading the Lean IT Transformation • 229

Lean
Escape
Trajectory

Results

Management
Systems and
Principles
Tools

t
jec
ro tum
tP n
ilo me
P o
M

Time
Figure 10.1

Lean transformation escape trajectory.

should launch with a focus on problem-solving tools, then bounce off the
atmosphere established by successful pilot projects (see Figure 10.1), giving
the organization time, momentum, and confidence to develop sustaining
systems and principles.

Strategic Intent
Research consistently shows that in most companies strategic intent is
not clearly articulated, and this leads to a disconnect between strategic goals and daily activities. The better an organization communicates
strategy in clear, actionable, and measurable terms, the more successfully the Lean transformation can focus on driving change where it matters most.
There are many perspectives and approaches to strategy, but it all comes
down to a few simple questions. How does an organization define and

differentiate itself in such a way that customers prefer it over their competitors? What are the activities the organization must engage in to achieve
this status? And how do they sustain competitive advantage over time, as
their competitors constantly try to capture market share?
More important, in our opinion, than the details of an organization’s
strategy at any point in time is how well everyone in the organization
understands the strategic intent, and how this understanding guides their
daily thoughts, behaviors, and decisions.
Strategy and strategic intent are very different. Strategy is often defined
as a specific plan toward a goal, based on a current-state assessment of
resources and the opportunities to utilize them to greatest advantage. Two
commonly noted weaknesses of the traditional strategic-planning process
are that it generally encourages a top-down perspective, and it is usually
incremental in nature—next year’s strategy is often overly influenced by
this year’s challenges. In addition, excessively regimented strategic-planning and budgeting efforts sometimes stifle the very innovation they hope
to inspire.
On the other hand, strategic intent is about purpose and resourcefulness, based on the collective vision and creative potential of the entire
organization. Strategic intent harnesses the wisdom of the anthill, the
idea that shared goals lead to decentralized coordination within an
organization. Shared goals guide daily decisions, where the entire organization is capable of coherent, systemic activity and self-guided evolution. Strategic intent catalyzes leadership throughout all levels of the
organization by creating a shared purpose, pursuing objectives that are
often below or beyond the horizon of the annual planning and budgeting cycle.
Strategic intent is fundamentally allied with the cornerstone Lean principle described in Chapter 2: constancy of purpose, which often leads toward
challenging, even seemingly unattainable goals while inspiring teamwork,
problem solving, and innovation. For example, constancy of purpose
enabled Toyota, over decades of relentless effort and focus on unbending
principles and values, to systematically overtake the U.S. auto industry. In
1961, President John F. Kennedy established constancy of purpose with a
measurable target: challenge an entire country to land a man on the moon
and return him safely to earth within the decade, saying, “In a very real
sense, it will not be one man going to the moon, it will be an entire nation.
For all of us must work to put him there.”

Neither of these efforts seemed possible when the strategic intent was
communicated, nor was there a detailed plan to get there—that too would
have been impossible and, in fact, would have inhibited the necessary
process of experimentation, discovery, and learning. But these challenges
harnessed and guided enormous, sustained, collective resourcefulness
toward a shared vision, one small experimental step at a time.
In 1989 Gary Hamel and C. K. Prahalad published the classic Harvard
Business Review article “Strategic Intent,” where they declared, “Strategic
intent is like a marathon run in 400-meter sprints, providing consistency
to short-term action, while leaving room for reinterpretation as new opportunities emerge.”2 For a learning organization, strategy is a rapidly moving
target—which is very difficult to compete against. To support this agility,
every activity of the enterprise should be reinforced through continuous,
rapid feedback cycles (PDCA) triggering instant, adaptive responses—the
essence of an enterprise-wide digital nervous system.
Once an organization formulates its purpose, and effectively communicates this as its strategic intent in terms of long- and short-term goals, it
must then establish measures that assess progress against those goals, supported by management systems that quickly signal and address deviations.
While financial measures are important for many reasons, sole reliance
upon them is not only incomplete but also harmful. Our recommendation for a comprehensive measurement approach is based on the Balanced
Scorecard (discussed in Chapter 6) where performance is measured across
four complementary dimensions: financial, operational, customer satisfaction, and employee learning and innovation. For an organization to be
healthy in the long run, these four dimensions must be kept in balance.
If any one dimension is neglected, it leaves a flank exposed for the competition to exploit. Especially important to strategy, and challenging to
measure, are the dimensions of customer satisfaction and employee innovation and learning. These are vital to driving continuous improvement,
since they represent the voices of your customers, and your organization’s
ability to listen and respond to them appropriately.
To the extent that an organization can define its strategic intent and
establish effective measurements, it has the necessary foundation to
standardize strategic execution. Measures become the targets that direct
improvement and innovation. They guide IT prioritization decisions in
particular, and strategy deployment in general, across all dimensions of
the enterprise.


Leadership Is a State of Mind
Effective management systems depend on effective leadership, and constancy of purpose provides the direction which enables everyone to focus
on a shared goal. The essence of Lean leadership is to cultivate and coach
people and teams, while developing management processes and information systems that shift problem solving and decision making deeper into
the organization, into the hands of those on the front lines, and closer to
the customer.
Senior management must initiate the Lean transformation from the topdown, demonstrating a commitment to the long-term challenges that true
and lasting change will pose. But once begun, Lean transformation cannot be effectively controlled from the executive suite, in a top-down fashion. Nor can it be an outside-in process, driven by external consultants.
Authentic transformation must grow from the inside-out, and leadership
should be placed into the hands of everyone in the company.
According to Dr. Stephen Covey, true leadership is not something that automatically happens once a person is given a title. “Leadership is a choice, not a
position,” he counsels. “Leaders who have to borrow their authority from their
title will not be as effective.”3 Everyone can practice individual leadership.
Effective leaders create positive energy. Rather than focusing on “What’s
wrong with where we are?” effective leaders start with “What do we do
well, and what will it take to get where we want to be?” Always beginning with an emphasis on what they do well, a positive-minded solution
orientation develops openness and involvement, and an atmosphere best
suited for generating creative solutions.4 This spirit of hansei—humility,
mindfulness, critical self-reflection, curiosity, and experimentation—
characterizes an authentic Lean enterprise.
In Good to Great, Jim Collins rigorously analyzed the performance of
1,435 companies, searching for empirical evidence of a sustained company transformation that far outperformed the competition over 15 years
or more.* His team discovered many contributing factors to sustained
greatness, but most surprising was the nature of extraordinary executive
* Collins and his research team began with 1,435 companies that had at some point been among the
500 largest, going back to 1965. They then searched for companies that made a shift from good to
great performance—meaning they generated cumulative shareholder returns greater than three
times the market average over 15 years. They found 11 companies that met these criteria.

leadership. This was not the high-profile, often overbearing leadership of
celebrity CEOs; rather, just the opposite—what they described as Level
Five leadership—was found to exist in all 11 Good to Great companies.
Collins and his team describe a Level Five leader as one who “builds
enduring greatness through a paradoxical blend of personal humility and
professional will.” A Level Five leader is characterized as self-reflective,
modest, and humble—yet extremely determined, with a nearly fanatical
will to develop the company and his or her own leadership successors. In
over two-thirds of the not-so-great companies, the chief competitors used
for the comparisons, Collins and his team found the presence of a “gargantuan personal ego that contributed to the demise or continued mediocrity of the company.”5
These fundamental human characteristics of humility and self-reflection must be practiced and nurtured, starting at the very top. Senior management must consistently walk the talk every moment if they are to set an
example that influences organizational culture in the desired direction. As
the coauthor of The Machine That Changed the World (the book that originally popularized the term Lean), James Womack* regularly visits organizations on the Lean journey. What he often finds are the tools of Lean, but
not the authentic leadership practices.
For example, he often witnesses traditional management decision-making behavior from the top-down, going through rituals and applying habitual remedies to unique problems, which are then cut and pasted into A3
documents and strategy deployment scorecards, creating the appearance
of disciplined problem-solving behavior and catchball-driven strategic
alignment. While these deceptions may not be intentional or conscious,
they demonstrate how traditional patterns of behavior can become deeply
rooted in our thoughts and actions.
Womack describes four essential Lean management states of mind that
must be cultivated for an authentic transformation:
1. The Lean manager eagerly embraces the role of problem solver.
2. The Lean manager realizes that no manager at a higher level can or
should solve a problem at a lower level—problems can only be solved
where they live, by those living with them.
* James Womack is founder of the Lean Enterprise Institute (LEI), a nonprofit education, publishing, and research organization dedicated to the promotion of Lean thinking worldwide (see www.
Lean.org).

3. The Lean manager believes that all problem solving is about experimentation by means of Plan-Do-Check-Act.
4. The Lean manager knows that no problem is ever solved forever.
Indeed, the introduction of a promising countermeasure is sure to
create new problems at some other point in the organization. This is
not bad. It is good, provided the critical, probing mind of the Lean
manager keeps on the case in pursuit of perfection.6
The Lean manager bestows both problem-solving and many decisionmaking responsibilities where they belong, closest to the work and the
customer. At its core, Lean leadership and transformation are thus more
of a social than a technical process. But beyond this essential leadership
state of mind, there must be standard work in the form of management
systems that effectively link goal-setting and decision-making processes,
with no wasted time, effort, and resources. And we all know how much
waste plagues the typical management system.

The Importance of Effective
Management Systems
According to Kaplan and Norton, originators of the balanced scorecard, a
management system is defined as “the integrated set of processes and tools
that a company uses to develop its strategy, translate it into operational
actions, and monitor and improve the effectiveness of both.” They suggest that “breakdowns in a company’s management system, not managers’
lack of ability or effort, are what cause a company’s underperformance.”7
In their Harvard Business Review article “Mastering the Management
System,” Kaplan and Norton explore elements of an effective management
system. They explain that successful strategy execution has two basic rules:
understand the management cycle that links strategy and operations, and
know what tools to apply at each stage of the cycle. This points to several
themes familiar to Lean practitioners: cadence, flow, and leader standard
work.
The cadence of a management system facilitates the smooth flow of decision making and should match the pace of change in the organization.

While some industries are naturally faster moving and more dynamic
than others, the pace of change has increased for all; today no organization
is immune to sudden disruption, threats, and opportunities. Thus a Lean
enterprise relies on the management system’s ability to match decisionmaking cadence to the tempo of the market, and of its customers, quickly
responding to unanticipated events—ideally driving change rather than
reacting to it. Short cycles of collaboration, problem solving, and decision
making (PDCA) promote rapid learning and agility.
In our view, there are five essential management systems that guide the
Lean enterprise transformation: strategy deployment, demand management, business process management, and project/program/portfolio management, all coordinated by sound governance practices.* As you might
expect, information, information systems, and the IT organization play a
vital role in their performance.
Strategy Deployment
As we explored in Chapter 6, strategy deployment encourages a holistic
focus across all dimensions of the organization (the Lean principle of systems thinking), acting as a compass to align daily activity with strategy.
Through rapidly iterative goal-setting and review cycles, the catchball
process encourages proactive two-way communication, rapid fact-based
learning, and agility. From an organic perspective, strategy deployment
acts as the organization’s distributed nervous system, continuously scanning the environment for exceptions, problems, threats, and opportunities. (Figure 10.2)
Strategy deployment may first be established enterprise-wide, starting
with an articulation of strategic intent and strategic objectives, communicated throughout the dimensions of the organization as measurable
targets. On the other hand, progressive IT leaders may first introduce
strategy deployment from within the IT organization, encouraging its
integration with other functions of the enterprise over time. In this latter case, senior IT management must make a special effort to determine
the strategic intent and goals of the enterprise, and how the IT organization best serves them—a necessary dialogue in any case.
* There are clearly many more management systems required to run a business, but we are focusing
on those which are central to enabling and sustaining the Lean transformation.

Management Systems
Governance

Strategy
Deployment

S
U
P
P
L
I
E
R
S

Strategic
Planning

Demand
Management

Business Process
Management

Project, Program,
and Portfolio
Management

Systems/
Program/
Product Mgmt

Product and
Service
Design and
Development

Sales and
Order Capture

Procure and
Build/ Service
Delivery

Service and
Support

Enterprise Value Streams and Supporting Processes

P
U
L
L

C
U
S
T
O
M
E
R
S

Dimensions: Geographies, Divisions, Departments, Projects, Teams

Shared Services: IT, Finance, HR, Legal, Compliance, Centers of Excellence

Figure 10.2

Essential management system framework for the Lean transformation.

Demand Management
As we explored in Chapter 5, every value stream should engage stakeholders to continuously level demand and balance capacity. The cadence of this
balancing act should be synchronized with the delivery cycles of the particular industry, but generally the demand management process occurs on
a standard monthly cycle. While demand management originally evolved
in supply chain industries (as sales and operations planning [S&OP]), the
fundamentals are now being successfully applied across many industries.
After all, what organization does not need to balance demand from customers with their capacity to deliver?
When a disciplined demand management collaboration process takes
hold, value stream flow is stabilized (mura reduced) and resource overload is avoided (muri reduced). Under these conditions, departments and
teams experience a reasonable workload, so they can focus on the development of people and on the design of work processes that flow smoothly
without interruption (muda reduced). Once the discipline and cadence
of demand management become routine, organizations can identify and
respond to changes quickly with limited disruption to operations, suppliers, and customers.
As Lean practitioners learned in the manufacturing world decades ago,
just-in-time delivery can only be sustained when demand is reasonably

level, without frequent spikes and unplanned disruptions. For this reason, demand management plays a key role, actively engaging with the customers of the IT organization to identify and prioritize requirements. By
minimizing schedule changes so the rate of demand is level (smooth over
time, matching the capacity and pace of delivery), the backlog is kept at
a manageable size and delivery of IT services and projects can be rapid,
responsive, and continuous.
Business Process Management
As we explored in Chapter 4, business process management (BPM) treats
enterprise processes as vital, intangible corporate assets that embody the
competitive advantage and intellectual property of the enterprise. A clear
and relatively uncomplicated logical model of enterprise processes, interrelationships, ownership, and measurements helps to establish a necessary
foundation for prioritization of improvement opportunities so that enterprise resources may be utilized to their greatest advantage. Put another
way, until an organization can describe its portfolio of business processes,
explain their strengths and weaknesses, and assess their relative impact
on achieving strategic goals, there is little basis for fact-based prioritization regarding their improvement.
In many organizations, simply identifying the portfolio of processes can
be difficult, since so many regular activities consist of undocumented practices, tribal knowledge, and habitual behavior, rather than documented standard work. On top of this, many organizations learn that the most difficult
part of BPM is not identifying their processes, but determining who owns
them and what their targets and relative priorities should be. Applying a formalized BPM approach* (accompanied by value stream mapping, problemsolving tools, and clearly defined process ownership) provides a foundation
that promotes understanding and consensus, leading to sound prioritization and decision making. In fact, we can argue that until the enterprise
process portfolio is defined, the linkages of the strategy deployment process,
where strategic goals are associated with processes and their targets, are not
clearly understood (more on this later in the governance section).
* As we discussed in Chapter 4, in many cases this should not require a significant investment in
sophisticated BPM software; focus first on developing a simple, manageable approach to cataloguing your processes.

The IT organization often plays the natural role of process leaders and
architects, providing oversight and guidance to enterprise-wide business
process management. But business stakeholders must play the role of
process owners, with accountability, responsibility, and authority for the
continuous improvement and innovation of each value stream and supporting process.
Project, Program, and Portfolio Management
As we explored in Chapter 9, sound project, program, and portfolio management discipline and practice are essential throughout the enterprise,
not only to large-scale efforts, but also on the smaller kaizen activities.
Teams should constantly practice A3 thinking in order to understand and
address root causes of problems, rather than jumping to solutions and
focusing on potentially non-value-adding deliverables.
Governance
We are introducing this overarching management system here for the first
time and will do so only briefly. Governance is a troubling word to some,
evoking visions of regulation, bureaucracy, endless delays, and unnecessary complexity. As a result of many recent corporate scandals, though,
corporate behavior is now under close public scrutiny. Beyond its ethical
and regulatory implications, good governance practices are necessary to
ensure that decisions are made in a consistent and high-quality manner.
Governance is “the collective set of procedures, policies, roles and responsibilities, and organizational structures required to support an effective
decision-making process.”8 Every organization practices governance,
whether formally or informally, transparently or mysteriously.
From the perspective of process improvement, good governance supports a process where accurate information about the cost, risk, and benefits of each proposed initiative is made available, so they can be weighed
against the needs of other initiatives and operations competing for the
same limited resources. Effective governance is essential for a Lean enterprise to function, providing transparency so all stakeholders have confidence in the decision-making processes that guide the enterprise. This
does not mean that stakeholders will always agree on every decision, but
if they believe the decisions are approached thoroughly and fairly, with an

opportunity for all parties to express a concern or suggest an alternative,
then the likelihood of consensus and support is far greater. And remember, consensus is not unanimous agreement, but general agreement where
dissenting opinions are respected (the Lean principle of respect for people)
and where all team members agree to support the decision of the group
through each PDCA learning cycle.
Leadership must walk a fine line, establishing sufficient governance to
ensure thorough evaluation of initiatives, but with clear and simple decision-making rules and processes, so when the time comes for a decision
to be made, it is done with clarity and confidence. In The Toyota Way,
Jeffrey Liker describes the effective decision-making discipline of a Lean
enterprise: “Make decisions slowly by consensus, thoroughly considering
all options; implement decisions rapidly.”9
According to Peter Weill and Jeanne Ross in IT Governance, corporate
governance regulates decision-making processes for six interdependent
enterprise assets: human, financial, physical, intellectual property, IT, and
relationships.10 In a symbiotic relationship, IT governance is thus subordinate to corporate governance, yet at the same time IT governance (and the
information and information systems managed by the IT organization)
supports a properly functioning corporate governance process.
When corporate and IT governance are working properly, a framework is created for assigning decision rights, establishing formal responsibility and accountability for determining how scarce IT resources are
allocated to operations, projects, and continuous improvement activities. Governance prevents the IT organization (as well as other functional areas) from independently making and later being held solely
responsible for decisions, while at the same time ensuring that business
stakeholders assume their responsibility to participate in making good
IT decisions. To be effective, the governance process requires prioritized
direction (strategy deployment), defined interdependencies (business
process management), and the management of operational constraints
(demand management) in order to make informed decisions on the allocation of scarce resources.
In addition, governance requires effective project, program, and portfolio management for planning and execution. The Project Management
Office (PMO) is a common element of corporate and IT governance, where
the Project Management Center of Excellence (CoE), the Lean CoE, senior
management, and stakeholders from the business and IT organizations

come together regularly to make such resource allocation decisions, and
in general manage the IT and other enterprise priorities including kaizen*
and project portfolios.
As we explored in Chapter 9, centers of excellence are not part of the
management hierarchy, but are a shared service providing enterprise-wide
competency and support in specialized disciplines. Smaller organizations
may not maintain permanently staffed Center of Excellence support organizations; in this case, the functions of a CoE in various domains (such as
Lean, project management, compliance, and safety) should be provided
through internal subject matter experts, ideally with a formal role and
time allocation. Even the smallest companies will benefit from disciplined
practice and standard work in these important areas of enterprise competency, creating an environment of consistency and stability where continuous improvement and innovation may thrive.
Many large organizations, on the other hand, already have established
CoEs and disciplined governance processes in place. But as we explored in
Chapter 4, the nature of many of these governance processes is compliance
oriented, attempting to inspect quality and compliance into the processes
by monitoring outcomes, thus often contributing more waste than value.
These organizations should apply Lean thinking to support the continuous improvement of their existing governance processes, and the activities
they monitor and control, which leads to greater overall compliance as a
natural outcome. The emphasis shifts from process outcome inspection
and correction to process improvement, adding long-term value.

The Three Levels of a Lean Management System
The management systems just described (as well as others commonly found
within the Lean enterprise) must work together, with information, human
interactions, and decisions flowing at a stable and sustainable cadence. But
considering the many dimensions of the typical enterprise, and the many
interactions and motivations of the stakeholders, the overall management
* The degree to which kaizen activity requires governance relies on its scale (system, process, or
daily—see Chapter 2), scope (the amount of shared resources and cross-functional coordination
required), risk, and resource requirements.

system framework can easily become overly complex and unwieldy, creating waste that hinders the effectiveness of the Lean enterprise we’re trying
to create. For a Lean management system framework to be effective, it
must be simple to understand and execute, providing structure and guidance while not unnecessarily slowing progress. It cannot be too controlling or rigid; otherwise, it will suppress creativity and learning, hindering
continuous improvement and innovation.
Considering the sophisticated and enticing information systems that are
now available to automate the various management systems and processes
of a modern, global enterprise, it’s no wonder that many find themselves
mired in information systems complexity. In our opinion, the quest for a
completely unified and integrated enterprise-wide management information system composed of interlocking scorecards, dashboards, analyses,
and other decision support tools is impractical. Such a 100-percent solution would by definition be too complex, inflexible, unmanageable, and
certainly not Lean. Employees shouldn’t need a Harvard MBA to understand how their management systems work. There is a historical precedent
here: overzealous attempts to improve factory performance with material
requirements planning (MRP), introducing sophisticated push scheduling and process control techniques, gave rise to more waste, confusion,
and resistance to change, not less. Our recommendation is to strive for
simple visual management, supported by an 80-percent software solution
that is solid and adaptable, and let human collaboration, communication,
creativity, and rapid adaptive learning cycles do the rest.
Thus the nature of Lean management systems, and the information and
information systems that support them, must be based on simple rules,
practiced consistently with minimal waste and at a sustainable, rapid,
iterative cadence. In fact, some of the most effective Lean management
systems we’ve seen don’t employ computers at the level of daily work, but
rely on frequent management gemba walks. While at the gemba, maintaining a focus on visual process measures and visiting teams where the
work is done, Lean managers help to identify, solve, and ultimately prevent
problems. Thus proactive process monitoring reduces a dreaded cause of
waste—postmortem meetings where people gather to try and figure out
what went wrong some time ago, and how to repair the damage that has
been done.
Many managers resist the idea of structured leader standard work in
their daily behavior and management systems, believing that it diminishes

their flexibility and authority. But in our experience, once managers truly
assimilate Lean thinking into their daily practice, they realize that leader
standard work creates stability while improving flexibility, quality, and
performance. The effectiveness of leader standard work has been demonstrated in many industries where structure, authority, and agility go hand
in hand, including airlines, law enforcement, and health care.
More than just providing necessary data for these management systems to operate across all enterprise levels and dimensions (particularly
in matrixed organizations), properly designed information systems enable
management system processes to flow smoothly. Like any other process,
teams should value stream map management system processes, identifying
workflow and information waste, and looking for ways to apply simple and
effective manual, visual, verbal, and electronic information systems.
But more important than the supporting information systems, an effective Lean management system requires simple, clear roles and responsibilities across all levels of activity, to avoid unnecessary complexity and to
help the value flow (Figure 10.3):
Executives:
• Set and communicate direction (strategy)
• Guide direction (strategy deployment catchball, system kaizen (kaikaku) to drive breakthrough change)
• Enable value stream flow: reducing unevenness and variation (mura)
and overburden (muri)
• Lead (as if they have no authority) and inspire others to lead with
them
• Go see and ask why
• Actively engage in continuous improvement through the practice
of leader standard work supported by a regular monthly cadence of
PDCA
• Improve the work and improve themselves
Managers:
• Establish basic stability: level demand matched with capacity across
value streams
• Communicate strategic direction, align with daily work and process
improvement (strategy deployment catchball)
• Go see and ask why

Drive Improvement
and Innovation

Experiential Learning and
Sharing

Daily Work: Operations
and Projects

Develop and Coach
People and Teams

Align Targets and
Measure Results

Standard Work

A3 Thinking

Value Stream
Mapping

Leader
Standard Work

A3 Thinking

Value Stream
Mapping

Enterprise Value
Stream Oversight

Demand Management to
Create Flow

Leader
Standard Work

Scan for Strategic
Opportunities and Threats

Business, Lean, and information systems focus.

Figure 10.3

Teams and
Individuals

Managers

Execs

Lean
Focus
Strategy
Deployment
(Hoshin Kanri)

Execute Strategy

Business
Focus

Enterprise-wide Transactional Systems
Standard Work Instructions
Error-prooﬁng
Workﬂow Automation
Operational Dashboards
Exception Alerts
Collaboration Tools
Communications

Dashboards and Drilldowns
Analytics and Visualization
Collaboration Tools
Project Management
Skills Management
Communications and Mobility

Scorecards and Drilldowns
Analytics and Visualization
Sales and Operations Planning
Business Process Management
Project Portfolio Management
Governance Tools

Information
Systems Focus


• Actively engage in continuous improvement through the practice of
leader standard work supported by a regular weekly/daily cadence of
PDCA with their associates
• Make time for workers to regularly practice continuous improvement
• Coach change, improvement, and innovation; support cross-functional process kaizen activity; inspire others to lead with them
• Keep problem-solving at the right level, drive decision-making closer
to the individuals and teams that interact with the customer
Teams and individuals:
• Focus on waste reduction, sustain the gains
• Stop the process when an error appears, identify root cause, take corrective and preventative action (quality at the source)

Integrating Lean IT
It is not enough to just do your best or work hard. You must know what to
work on.
—Dr. W. Edwards Deming

Across many industries, billions of dollars are spent each year on IT investments that do not add value or offer differentiation to the customer. What
actions can IT leadership take to redirect funding and focus from these
routine and wasteful activities toward enabling innovation and competitive advantage?
To address this question, in 2007 the IT Process Institute* conducted a
survey, illustrating the degree of IT strategic integration in quantitative
terms. Their methodology identified three IT archetypes:
• Utility providers: They provide primary shared services and infrastructure to support basic information management applications.
* See www.itpi.org; this research was built upon earlier research conducted by Forrester Research
and McKinsey.

• Process optimizers: In addition to the single emphasis of utility providers, process optimizers also focus on enabling business unit–specific objectives via applications that optimize key business functions
and processes.
• Revenue enablers: In addition to the dual emphasis of process optimizers, revenue enablers also focus on technology to enable unique
products and services that capture greater market share and enter
new markets.
Among its many insightful discoveries, the survey shows (Figure 10.4)
that revenue-enabling IT organizations consistently allocated spending
equally among these three areas of emphasis: utility 34 percent, optimizing 33 percent, and enabling 33 percent. Thus, to effectively operate the
IT organization as a revenue enabler, the focus, and the competencies it
develops, should be balanced across these three dimensions. As the figure suggests, by pursuing operational excellence of utility services (waste
reduction) effort and investment can be redirected to revenue-enabling
activities. According to the survey, “The proven practices for this group
paint a picture that indicates tight integration of IT with the business.”12
The results also indicate that revenue enabler organizations have the highest spending on new projects (43 percent, compared to 33 percent for process optimizers and 27 percent for utility providers). Revenue enablers also
have a strong track record for rejecting bad projects. These two facts taken
New Project Spending Mix
Utility
Provider

51%

70% of IT Budget
under IT Control

Process
Optimizer

47%

66% of IT Budget
under IT Control

Revenue
Enabler

57% of IT Budget
under IT Control

31%

34%

Figure 10.4

ITPI survey results.11

13%

35%

33%

14%

33%

Common
infrastructure,
shared services
Business unit
objectives, process
improvement
New products,
services, markets

together suggest agility, complemented by a clear focus on business priorities, where the IT organization is quick to deploy new projects when the
customer requests them and is also quick to terminate a project if necessary.
The key to such agility (as we explored in Chapter 9) is to keep these projects
small in scope and short in duration, so start-stop decisions can be made
quickly without causing unnecessary cost, risk, or business disruption.
The results also illustrate the differences in strategic focus, governance,
and budgetary control among these three archetypes. IT organizations
that act as revenue enablers have less control over their own spending:*
only 57 percent for revenue enablers, compared with 66 percent for process optimizers and 70 percent for utility providers. This clearly indicates tighter integration and stronger collaboration of revenue enablers,
since the business shares strategic prioritization and investment decisions with IT.
As the IT organization evolves from segregation, through alignment, toward
full integration, the business naturally gains an increasing degree of control
over the IT operational budget. This is because more decisions are made by
business and IT together, toward shared strategic intent and objectives. Beyond
the mechanics of moving more budgetary control from the IT organization to
the process owner, there is a fundamental shift in thinking that must occur.
IT should be responsible for managing its capacity and efficient delivery of
functionality (operational excellence), while business units and process owners should be responsible for the ultimate success of each project—including
IT-based improvements and automation of the business process.
When the business assumes ownership of technology-based business
process improvement outcomes, a collaborative alliance ensues and the
likelihood of project success is significantly increased. IT projects are thus
conceived, approved, and funded based on shared strategic objectives—
ensuring that constancy of purpose is translated into aligned action.
This indicates a tightly coupled relationship where IT plays two roles in
relation to the business: supplier and advisor. On the supply side, demand is
collaboratively managed, budgeted, and prioritized across business units,
processes, and projects; then it is balanced against available capacity to
ensure optimal results for the enterprise as a whole. And as a trusted advisor, IT plays an essential role in business strategic planning and budgeting
* Measured as the percentage of IT budget under the direct control of IT governance versus general
corporate governance.

decisions throughout the organization. In this way, the business can apply
systems thinking to all decisions (supported by A3 thinking, of course)
and take advantage of every opportunity to utilize quality information
and effective information systems to create value and stay ahead of the
competition—or even change the game completely.
Based on the survey results, the authors make several recommendations for IT organizations desiring to achieve this exalted state of strategic
integration and enablement, and these recommendations clearly resonate
with the message of this book:
• Shift the CIO role toward greater participation in setting enterpriseand business unit–level strategy, goals and objectives.
• Train all IT personnel on business objectives, so they develop a visceral understanding of IT’s contribution to competitive positioning
and value delivery.
• Matrix IT resources into business units.
• Involve business stakeholders with IT planning and strategy.
• Integrate the IT budget process with the business unit and enterprise
budget cycle.
• Match the pace of IT and business change; revenue enablers must
shift the IT change paradigm to a velocity-based model.
• Utilize a portfolio management approach to invest in IT initiatives that
balance the spending mix across the three areas of focus: utility and
shared service, process optimization, and new revenue contribution.
• Formalize a process for assessing the changing needs of the business,
and proactively responding to them.
This last recommendation bears close examination, since it suggests a
broad goal that IT organizations have been pursuing, often with disappointing results, for years. This points to the value that Lean IT offers
as an enabler, and often a driver, of customer-value focused continuous
improvement and innovation throughout the enterprise. So, finally, let’s
turn our attention to how we make Lean IT happen.


Endnotes

1. Shingo Prize for Operational Excellence, Model and application guidelines, 3rd ed.
(Logan: Utah State University, Jon M. Huntsman School of Business, 2009), 1, www.
shingoprize.org.
2. Gary Hamel and C. K. Prahalad, “Strategic intent,” Harvard Business Review, May–
June 1989, 63–76.
3. Stephen Covey, “Shingo Prize Award ceremony report,” Huntsman Alumni Magazine,
Fall 2009, 12.
4. Ed Oakley and Doug Krug, Enlightened leadership (New York: Fireside, 1991), 89.
5. Jim Collins, Good to great (New York: HarperCollins, 2001), 13, 29.
6. James Womack, “The mind of the Lean manager,” Lean Enterprise Institute Electronic
Newsletter, July 30, 2009.
7. Robert S. Kaplan and David P. Norton, “Mastering the management system,” Harvard
Business Review, January 2007, 62–77.
8. itSMF USA Advisory Board, “Introduction to IT governance,” Advisory Board Paper,
July 13, v. 1.0.3, 1 (Pasadena, CA: itSMF USA, 2005).
9. Jeffrey K. Liker, The Toyota way, (New York: McGraw-Hill, 2004).
10. Weill and Ross, IT governance, (Harvard Business School Press, 2004). vii.
11. Kurt Milne and Laurie Orlov, Know thy self: Improving an IT organization’s ability to
drive business success (Eugene, OR: IT Process Institute, 2008).
12. Milne and Orlov, Know thy self.

11
A Lean IT Roadmap

Every organization—not just business—needs one core competence:
innovation.
—Peter Drucker

People Lead Lean IT Change
The Lean journey must begin with people. After all, people are far more
creative, adaptable, and agile than computers will ever be. Lean thinking channels individual strength and collective diversity into continuous improvement and innovation through shared values, behaviors, and
management systems—in a word, culture. Organizations that learn how to
harness the creative potential of their employees can transcend from good
to sustained greatness over time.
As Figure 11.1 illustrates, three essential elements—people, process, and
technology—must be kept in balance. While no single element should be
allowed to become dominant or weak, people must lead the way through
the transformation. The bottom line is this: the success of Lean IT, and the
future of a sustainable Lean enterprise, relies upon people, process, and
technology, in that order.
In the landmark 1996 book Leading Change, John Kotter set the tone
for contemporary thinking on organizational change. He stressed that
most corporate change efforts achieve only modest results, while many
fail miserably. Kotter cites the natural human tendency to move too
249

Process and Technology
without People
Alienation and turnover
Under-utilized systems

PROCESS

Alienation

SWEET
SPOT
Frustration
People and Process
without Technology
Frustration and ineﬃciency
High cost of operation

TECHNOLOGY

Automated
Chaos

PEOPLE

People and Technology
without Process
Automated chaos and confusion
Poor customer service

Figure 11.1

Balancing people, process, and technology.1

quickly, impatiently accelerating change in order to achieve rapid results:
“The change process goes through a series of phases that, in total, usually
require a considerable length of time. Skipping steps creates only the illusion of speed and never produces a satisfying result.”2 This is consistent
with the Lean maxim: in order to speed up you must slow down. Kotter
proposes a simple eight-step sequence; Figure 11.2 uses this approach to
suggest steps that leaders should (and should not) take toward a successful
Lean IT transformation.
We have applied the timeless wisdom contained in Kotter’s stages
countless times in our own practice, as have many other Lean leaders
we have met along the way. This approach addresses the subtle forces
of human nature that are critical to lasting change. While this is an
indispensible list, providing general rules for the road, alone it is not
enough. A working roadmap needs more specifics to navigate a successful transformation.

Make the vision too complicated, seemingly impractical, impossible or
unlikely to succeed.

Undercommunicate, practice old habits of top-down management,
communication behavior that sends the wrong message about change.
Allow strong willed managers, organization structures, policies,
incentives, and entrenched habits to undermine change.

Declare victory too soon; the higher you climb, the harder the wind
blows. Just when a transformation seems to be taking hold, the
problems become tougher and entrenched resistance can become
stronger.
Give up or let down your guard. Problems are clever, old habits die
slowly. Lean is not a project, or a program, it’s a new way of thinking
that doesn’t go away.

Get beyond the tactical and emphasize strategic value to the business. Develop a
complete roadmap for the transformation, clearly articulate everyone’s role and
contribution, explain that it will be difficult but attainable. As Dr. Stephen Covey
says, “begin with the end in mind.”

Communicate often and through multiple channels, promote success stories, openly
share lessons learned. Celebrate failures as well as successes to eliminate fear and
encourage PDCA.

Remove barriers, encourage and recognize creativity and innovation, cultivate
holistic value stream thinking over localized measures and incentives.

Start with pilot projects that are important, but not your biggest challenges.

Celebrate and promote initial successes, develop culture, principles, infrastructure,
and management systems that standardize and sustain the transformation.

Apply A3 Thinking and PDCA to daily work and decision-making. Develop future
leaders that think and act Lean. Emphasize business and IT partnership in all
management systems and improvement projects.

3. Create a vision

4. Communicate the vision

5. Empower others to act on the vision

6. Plan for and create short-term wins

7. Consolidate improvements and
produce more change

8. Institutionalize new approaches

Stages of the Lean IT Transformation

Figure 11.2

Stop communicating vigorously as the Lean transformation picks up
momentum, thinking that everyone understands what you’re talking
about and why it’s important.

Educate and communicate with all managers, key stakeholders and subject matter
experts, ensure you have critical mass to succeed, and address all concerns.
Cultivate emerging leaders outside the existing management hierarchy.

2. Form a powerful guiding coalition

Under-invest in the factors that will ensure these initial efforts are
successful: education on principles, training on tools, coaching, teams,
measures.

Underestimate the strength of peoples’ comfort zones, and their fear of
losing control or self-worth. This is especially important with technical
specialists. Kotter notes that over 50% of companies fail on this
essential first step.

IT Leadership Should Not:

Help everyone understand that the Lean Enterprise cannot afford a non-Lean IT
organization, and the key to IT alignment and agility is Lean Thinking

IT Leadership Should:

1. Establish a sense of urgency

Change Stage

A Lean IT Roadmap • 251


How to Start the Lean IT Transformation
Over the past two decades, a variety of models (including ISO, CMM, and
ITIL) have aimed to improve performance of the business and the supporting information and information systems. Some of these efforts have
produced significant, though usually localized, results. In most cases,
however, these well-intentioned efforts, based on best practice models
and methodologies, have not delivered sustained, enterprise-wide impact.
Why not?
Because a lasting transformation isn’t just controlled from the top-down
by following a best practices model or methodology, it must grow from
the inside-out. A Lean enterprise is agile and adaptable; every individual
and team throughout the organization possess situational fluency, quickly
and naturally responding to changing circumstances with effective problem solving and decision making. Every solution, to be effective, must be
unique in the sense that it is experienced, discovered and owned by the
teams, who share their different perspectives on the problem and eventually develop a common understanding and goals.
Harmony cannot be imposed from the outside. In order to overcome the
traditional separation of IT and the business and achieve integration, they
must begin working closely together on critical business processes. This
effort is a two-way street: business must take an active interest in information and information systems, and IT must learn to see information
waste and value, frequently going to gemba—listening to the customer,
and experiencing the business process firsthand. This working partnership is a catalyst for enterprise transformation.
So how does an organization deliberately achieve an inside-out transformation? There are countless books that will describe in detail what a
Lean enterprise should look like: the thinking processes it should embrace,
the tools it should use, and the management style and systems it should
adopt. But despite all these encouraging prescriptions, the transformation process itself is very difficult to carry out, and even more difficult to
sustain. In the end, there is no such thing as a one-size-fits-all prescriptive
approach to Lean transformation; it is a fine balance between social and
technical, between process and practice, and of repeatable behavior, experiential learning, and continuous adaptation and innovation. Every situation is different. The idiosyncrasies of people, organizations, customers,

and circumstances ensure that what worked last time, in the last organization, with the last team, on the last problem, very likely will not work
with the next.
For example, representatives of the aerospace industry were attending a
workshop on supply chain integration, a vital element of success in their
industry. Speaking to the group was Hajime Ohba, general manager of
the Toyota Supplier Support Center. After persistent questioning from
the group, which was searching for a prescriptive set of instructions or a
checklist approach to guide them, Ohba finally stressed, “Lean is a way of
thinking, not a list of things to do.”3 He insisted that first he would have
to go to gemba and meet with each supplier to understand its own processes, strengths, and weaknesses before he could suggest a specific course
of action.
In the end, strict adherence to an overly structured model or implementation approach alone is certainly not sufficient (and is usually counterproductive) to a lasting transformation. This, in our opinion, is why so many
model-based efforts to transform and align IT have been disappointing,
since the change was prescribed from without, rather than evolving from
within. This is why Lean thinking does not impose a prescriptive approach,
but instead offers guidance through structured experiential learning and
shared leadership, founded upon timeless, universal principles.
Nevertheless, those seeking a transformation need a general course to
follow, a roadmap for change charted by those who have gone before, so
they can learn from their successes and, hopefully, avoid repeating common mistakes.

Lean IT Transformation Roadmap
In this final section we outline an approach to help you transform your
organization into a Lean enterprise, enabled by Lean IT. While this roadmap will not tell you every turn to make, it will suggest a general direction
in which to travel and signposts to look for along the way.
So what makes a good roadmap? Foremost, it should provide general
guidelines, while allowing autonomy and flexibility for teams and individuals to adapt to each situation—what Tom Peters and Robert Waterman in
In Search of Excellence describe as loose-tight:

Autonomy is a product of discipline. The discipline (a few shared values) provides the framework. It gives people confidence (to experiment, for instance)
stemming from stable expectations about what really counts. Too much
overbearing discipline of the wrong kind will kill autonomy. The “rules”*
in excellent companies have a positive cast. They deal with quality, service,
innovation, and experimentation. Their focus is on building, expanding, the
opposite of restraining.4

Teams should be able to easily understand the intent of the roadmap,
quickly making adjustments in response to new facts and circumstances.
The roadmap must also adapt to an irregular pace and imbalanced acceptance, since some elements of the organization are usually faster than
others to adopt Lean thinking and change their behavior. The three transformation stages of strategy, planning, and execution are thus not entirely
sequential, but cyclical, continuously feeding back into each other as iterative PDCA loops, signaling slight course corrections with each new experiment and learning cycle.
Finally, a Lean IT transformation roadmap cannot be separated from
the overall Lean enterprise transformation plan that it supports. Business
and IT must take this journey together, and an effective roadmap must
reflect this. Figure 11.3 illustrates our recommended roadmap, based on
over 15 years of applying Lean thinking to information systems and enterprise change management.

Strategy
Establish Leadership Vision and Consensus
This effort is usually driven by an executive champion, who initially
establishes a sense of urgency; often called the burning platform, this is a
compelling argument that the organization cannot afford not to change
in a fundamental way. Consensus is needed on underlying values and
principles that will never change. Build on existing beliefs within the
enterprise when possible—if too many new principles and values are
suddenly introduced, it may cause the existing culture to reject them as
* In this case, the “rules” are Lean management systems supported by leader standard work.


Start here
Establish
Leadership Vision
and Consensus

Execution

Strategy
Articulate Strategic
Intent and Drivers

Planning

Consolidate Gains
& Build Momentum

Deﬁne and
Communicate the
Plan

Measure Results,
Assess Understanding
and Buy-in

Build a Lean
Leadership Team

Invest in Enterprisewide Infrastructure

Create a
Basic Toolkit

Launch Pilot
Kaizen Projects

Assess Key Enterprise
Value Streams

Do, Check, Act

Plan

Figure 11.3

Lean IT implementation roadmap.

contrived or disingenuous, just another flavor of the month. Where possible, seek to establish and constantly reinforce those timeless Lean principles described in Chapter 2. Senior management should form a Lean
transformation steering team representing executive stakeholders from
across the enterprise, including strong IT leadership involvement. We
also advise that IT leadership form their own Lean transformation steering team, to oversee the IT organization’s transformation and ensure its
integration with the overall enterprise transformation effort. This is especially critical if the business has been on the Lean journey for some time,
and IT is just starting.
Develop within the management team a clear understanding of the
importance of a Lean management system, and leader standard work, particularly repeatable behavior, accountability, and cadence. Coach members of the management team, since invariably some will more readily

change their behaviors than others. While some managers may delay as
they assess the Lean approach, others (let’s be honest) may be consciously
or unconsciously resistant to change. One careless senior management
intervention opposing the new direction can seriously damage or even
derail a transformation. This initial groundwork embodies Kotter’s essential first step, creating a sense of urgency, and begins the process for step
2, the formation of a guiding coalition. But the coalition shouldn’t end
with senior management; it must also enlist all managers, subject matter
experts, and thought leaders throughout the organization—more on this
in a later step.
Articulate Strategic Intent and Drivers
Senior management must clearly articulate the strategic intent and drivers
(through strategy deployment), so stakeholders can focus Lean transformation activities on those issues that will most affect outcomes. IT leadership
must actively engage in this process so the enterprise can leverage IT vision
and capabilities to their fullest. A word of caution here: in some cases, management may think they know what activities will drive the intended outcomes, but later discover they are mistaken. Often it’s not until teams start
critically assessing core value streams (using A3 thinking and value stream
mapping) that they will begin to clearly understand and quantify the underlying causal relationships hidden beneath layers of unchallenged assumptions.
Management’s role here is to articulate and constantly reinforce strategic
intent, ensuring that teams understand what they’re trying to accomplish
and why. Management should not define the how—that is the work of the
associates who must inevitably drive and own the transformation.

Planning
Define and Communicate the Transformation Plan
First, a plan must be developed that identifies targets, and the timing and
sequence of activities, while anticipating resource constraints and interdependencies. Although we earlier stressed that an overly prescriptive
or rigid framework is inappropriate, nevertheless a plan is necessary to


IT’s Stop-Doing List
Lean IT transformation takes time, so it’s important to show some
early successes to gain support and gather momentum. It’s also necessary to free up time to accelerate the change, since an enterprise can’t
suspend daily operations just to make time for Lean. We’ve never
encountered a client that had extra time in its schedule, so clearly
something must give way. Here we borrow from Good to Great5 the
simple idea of a stop-doing list, to help you free up wasteful time and
energy to focus on launching your transformation.
Let’s start with an assumption: just suppose that at least 20 percent
of the current IT projects, either underway or planned to start soon,
are wasteful from a Lean perspective. The key is for IT and business
stakeholders to quickly find these and stop doing them right away.
(Of course, if the project is wasteful but necessary to temporarily fix
a broken mission-critical process, then you may have no choice but
to keep doing it for now.) Our advice is to immediately reevaluate
every current project in your portfolio so that purpose and desired
outcomes are clear and measurable, and investment is focused on
projects that drive real value. And with the application of A3 thinking, ensure that each investment is focused on root causes, rather
than mitigating symptoms with quick technology fixes while accumulating a growing burden of technical debt. Set yourself a goal of
eliminating at least 20 percent of these projects, which should free up
enough time, resources, and mindshare to invest in your initial Lean
efforts. This bold step will also send a clear message to all business
stakeholders that sound root cause analysis and justification (A3
thinking) will be required for all new project proposals.
communicate objectives and direct the effort. This plan should be developed under the guidance of the steering team to ensure executive support, developing a visceral realization of the breadth, magnitude, and
duration of the undertaking. There must be buy-in from the top-down,
with clear communication, consistent and supportive action, and focused
measurement.
Sequence is important: senior management, middle management, and
then associates must understand what is about to happen and why. Goals

must be clear so people are motivated by strategic intent and shared purpose rather than just the need to follow management dictates.
Create a high-level visual roadmap showing the steps of the transformation, and how they engage the various parts of the organization over
time. Don’t over-promise and under-deliver; rather, position the plan as
a significant and thoughtful investment based on long-term thinking.
Set expectations that an authentic transformation of behavior and culture takes time, discipline, and persistence. It is especially important that
managers help their employees make an explicit commitment of time to
continuous improvement.
Keep the message simple, visual, and memorable. Reinforce the vision
and the reason for change. People must understand value and waste at a
gut level, if they are to overcome years of organizational inertia and process scar tissue. Answer the questions that are on everyone’s mind: “Why
are we doing this?” “How will things be different?” “What challenges do
we anticipate?” and “What’s in it for me?”
One of the most common failures when leading change is to undercommunicate. Update the plan periodically, regularly sharing progress
through town hall meetings and other company communications. Senior
management needs to take this out on the road and personally deliver
the message to everyone, don’t delegate this essential message across the
layers of middle management. Show everyone where the organization is,
where it’s going, and the role each individual plays, so they can plan for
the effort alongside their regular operating responsibilities. Be creative to
catch people’s attention, and keep their interest and curiosity.
Build a Lean Leadership Team
Identify change agents that will become your first wave of Lean leaders,
the core of your Lean Center of Excellence. Make sure IT associates are
well represented here. Look everywhere, since transformational leaders
are often found outside the formal management hierarchy. Invest in these
people, and develop their coaching skills; they will become your frontline transformation team. You are essentially investing in the catalyst of
enterprise change, those who will guide the re-architecting of your future
state, so choose this team wisely. These individuals will eventually become
your ambassadors, spreading Lean thinking across the entire enterprise,
which means that they will eventually engage in areas outside their current

department. While a manager may be reluctant to lose their “best people”
to this effort, if they have truly stabilized and standardized the processes
within their own area, then they should be able to cross-train and transition another person into their role—first as a temporary backfill then
later as a permanent replacement—which is a good human resource development practice.
Gather this team regularly to share their experiences. Send them to the
occasional conference or education event where they’ll meet and learn
from others who may be further along in the transformation journey.
Senior leaders should assume the role of coaches and mentors to the Lean
leadership team, actively participating, learning together, and helping to
shape the adoption of Lean thinking. The Lean transformation will begin
to take hold when this core group of internal Lean leaders develops a
problem-solving mind-set, accompanied by the ability to tell compelling
stories about the value and necessity of Lean thinking within the context
of your organization.
Create a Basic Toolkit
A few basic tools, well chosen and consistently used, are far better than
many tools that are misunderstood or poorly applied. Start with the basics:
A3 thinking, value stream mapping, 5S, problem solving and decision
making, visual management, standardized work, metrics, and communications, supported by experiential learning. Let the core team select and
learn new and advanced tools as they are needed. When a team member
develops special interest and proficiency in a particular tool, ask him or
her to document and share this knowledge with others.
Assess Key Enterprise Value Streams
Value stream map the current state at a macro level; this mapping must
identify and quantify the flow of work and supporting information of
enterprise-wide core processes. Tie the strengths and weaknesses of these
value streams to strategic goals; this alone is usually an enlightening exercise for cross-functional teams as they learn to see their contribution in
the bigger picture of the enterprise and its customers.
Create a high-level process model to guide business process management (BPM, discussed in Chapter 4) efforts, to be used as the foundation

for communicating and discussing the interrelated nature of all core
processes. But be careful not to go overboard: excessive mapping that
does not drive improvement is wasteful—the objective here is to develop
a reasonably simple, accessible, and coherent model of value streams
and supporting processes that will help prioritize and sequence change
efforts. If one does not already exist, establish an enterprise-wide framework for governance and prioritization. If it does exist, dovetail it into
the new enterprise process model, so there is a clear relationship between
strategic goals and enterprise processes. In any case, start with one or a
few processes (pilots) that everyone knows instinctively are in need of
attention and let BPM and governance evolve over time.

Execution
Launch Pilot Kaizen Projects
Choose meaningful problems whose success is achievable; don’t tackle the
hardest problems first. Focus on those areas of the organization that are
most likely to demonstrate early support for the Lean transformation. Use
initial pilots to standardize communications, training, and the use of basic
tools and measurements. Develop your internal coaching skills, demonstrate early wins, and promote meaningful stories and lessons learned to
spread interest and encourage wider adoption.
Invest in Enterprise-Wide Infrastructure
While initial pilots are underway, continue developing the coaching team,
while extending the infrastructure (tested and evolved during pilots,
guided by the Lean CoE) to support expanding Lean efforts: a website,
virtual and physical libraries, a knowledge base, collaboration and knowledge sharing tools, measurement standards and templates, communication tools, skills tracking, education and training materials, and so on.
Measure Results and Assess Understanding and Buy-In
Measuring and openly communicating observations, trends, and
results send a clear message that the Lean transformation is a strategic


Who Goes First?
We are often asked the question “Where does Lean IT start?” Does
Lean IT begin with the IT organization outwardly participating in
enterprise value streams, improving IT operations only as they are
identified as a hindrance to effective business process performance?
Or does the IT organization focus inwardly first on cleaning up its
own backyard, applying Lean thinking to IT services? Or should the
IT organization do both at the same time, as resources and priorities
allow? We’ve seen each approach work effectively, as long as leadership
is mindful of resource requirements, timelines, and expectations.
A progressive IT organization can indeed initiate its own inwardly
facing Lean transformation, even though the overall enterprise has
not yet made the commitment. In doing so, the IT organization may
realize significant, localized benefits. Examples of this can be found
within organizations that have implemented Lean software development and the Information Technology Infrastructure Library
(ITIL). Although these efforts engage portions of the enterprise (the
direct internal customers of these activities), they usually lack an
overall enterprise value stream focus, and thus return only localized
(though often significant) benefits.
priority. In order to ensure a shared understanding of strategic intent,
investigate teams and departments where measured results are not
conspicuously aligned with strategy. Otherwise hidden legacy practices and attitudes (part of the culture but not the formal management system) may inexplicably hinder the transformation in isolated
but important pockets of the organization (known in Lean circles as
anchor-draggers).
Begin with the managers and supervisors to assess their level of understanding of strategic objectives at each step in the organization hierarchy, and clarify their linkage with localized objectives and daily behavior.
Explain why you are assessing people’s understanding of strategic intent.
Does each manager and supervisor understand and support the need for
consistent reinforcement of specific objectives (constancy of purpose)?
Has capacity been freed up to support the new improvement work that
must be done? Let the managers and supervisors know you’ll be speaking
with their teams during the next gemba walk, and what you’ll be asking.

During gemba walks, use one-on-one conversations with those closest to
the work to assess their level of comprehension. Is there clear understanding of strategic intent and objectives? Does everyone understand how their
daily work adds value and supports strategy? Is there a common focus? Is
there buy-in? If not, why? Adjust communications with the goal of everyone
in the organization understanding what they need to accomplish to support strategic intent and why they must be a part of the transformation.
Consolidate Gains and Build Momentum
Communicate successes, failures, and lessons learned openly to establish trust and build support. Document and disseminate standard work
and measurements.
Launch expanded cycles of improvement—move from the pilot phase to
ongoing and self-sustaining kaizen activity. This often involves identifying those members of the senior management team who are most enthusiastic, using their energy and persuasion (backed by the steering team)
to pull value stream improvements through cross-functional areas that
are slow to adopt. Continuously invest in education and communication,
introducing advanced tools and topics as needed.
Senior management should be especially vigilant at this time; the greatest risk for backsliding arises just when the transformation appears to be
taking off. Accountability should be explicit and strong; integrate Lean
management systems into enterprise management processes, and include
kaizen planning and results measurement with the regular management
review and planning processes. Emphasize strategy deployment and
catchball to align strategy with action.
During this time, accelerate the integration of business and IT participants. Matrix IT associates into the business units they support. Break
down the physical, virtual, and cultural barriers that often surround the
IT organization. IT members should regularly attend kaizen events. In our
experience, when IT associates are not involved, inappropriate technology
solutions are often “tossed over the wall” to IT, that do not account for the
underlying (and often hidden) systemic complexities of the process. This disconnect creates technical debt, which the IT organization must ultimately
be responsible for. But when IT associates engage in a kaizen event from the
beginning, it significantly improves the overall team’s understanding of the
situation, and the effectiveness of the improvements that result.

Similarly, business stakeholders should regularly visit IT team meetings
to better understand how IT thinks and works. This mutual understanding and empathy helps to integrate and synchronize IT–business change
management, planning, budgeting, and performance management
cycles—moving from utility investing toward continuous improvement
and innovation that create real value.
Some areas typically adopt Lean IT more quickly and enthusiastically
than others. Of course, the primary constraint that hinders IT involvement
in kaizen is available time. An investment in Lean IT is an investment in
quality at the source: slowing down to speed up, doing things right the
first time. This illuminates a push versus pull dynamic when spreading
Lean IT initiatives throughout the IT organization and across the enterprise in general. Managers must invest in the future, often making difficult
tradeoff decisions, setting aside erstwhile priorities to make time for Lean
improvements to take root. In our experience, however, if you “push” Lean
onto managers, it becomes just another item on their to-do list, more load
on their backlog, more anxiety. But if you properly convey the spirit of
Lean, that it will ultimately relieve waste and pay back dividends in time,
capacity, and quality results, then managers will (perhaps slowly at first)
accept the up-front investment and create a “pull” toward active engagement in kaizen activity.
At later stages of maturity, as momentum starts building, use strategy
deployment to begin directing kaizen activity toward supporting breakthrough (kaikaku) objectives.
Finally, we are often asked, “How long does a Lean transformation
take?” The obvious answer is that continuous improvement never ends,
and it also depends on your definition of success. But clearly, in order to
embark on such an endeavor, we need to set measurable goals that justify
the initial commitment and effort. Though every transformation is different and ultimately follows its own journey of discovery, we set initial
expectations for “time to results” in the following manner:
• Six months for engaged pilots with kaizen success stories—localized
paybacks and celebrated low hanging fruit achievements—supported
by a preliminary Lean management system framework.
• Up to two years to spread basic kaizen proficiency supported by
a sustaining Lean management system and strategy deployment
framework across an extended organization.

• Three to five years to launch an authentic transformation—not just
changing behavior but influencing the way individuals think about
their work and how they seek out problems as opportunities for
improvement.

Setting the Pace for Change
It is not the strongest of the species that survives, nor the most intelligent
that survives. It is the one that is the most adaptable to change.
—Charles Darwin

We have entered an era of process leadership, where the IT organization has
an opportunity to drive meaningful change throughout the enterprise.
Process leadership is not the same as process ownership; each process
should have an owner with sufficient authority to drive improvement,
someone who is accountable and responsible for outcomes. But process
ownership is not sufficient by itself. Process leadership, the art of conceiving and guiding the overall enterprise toward value optimization, is essential, and it is a natural (though perhaps dormant) competency of the IT
organization; no one else is better suited, and in a better position, to see the
whole enterprise from a systems perspective.
As we illustrated in Chapter 1 (Figure 1.1), chief information officers
(CIOs) now list leading enterprise change initiatives as a key priority for
the future. This is well beyond the familiar focus on revenue growth and
cost reduction, going right to the heart of innovation. The collaboration
among process owners and process leaders naturally helps to integrate and
mobilize business and IT efforts aligned with constancy of purpose.
As we have learned throughout this book, common characteristics of
traditional IT include unnecessary complexity, instability, slow change
cycles, and the impulse to lead with technology “solutions” rather than
addressing business problems at the root. As advances in technology continue to accelerate, if these patterns aren’t changed, they will continue
to cause friction, hindering enterprise-wide continuous improvement
and innovation. At best, this resistance will impede the Lean enterprise

transformation, making it longer, more costly, riskier, and more painful,
while introducing additional layers of unnecessary technical complexity.
At worst, it will cause the transformation effort to falter, backslide, and
eventually fail. In our opinion, the lack of IT engagement is one of the
primary reasons many Lean transformations don’t reach sustainability.
But when IT and the rest of the business become integrated, thinking
Lean and acting in unison, something magical happens: quality information and effective information systems unleash the power of human
potential.
Lean thinking helps everyone in the IT organization demonstrate leadership and develop a laserlike focus—inwardly on personal, as well as
operational excellence, and outwardly to the continuous improvement
of business processes—eliminating waste and delivering value to every
customer.
At the strategic level, Lean IT leadership helps integrate and synchronize
business and IT change, enabling a rapid, iterative cadence of collaborative management systems that set the pace, the drumbeat, of enterprisewide improvement.
And at the tactical level, Lean IT leadership helps to institutionalize the
Lean enterprise transformation through process standardization, error
proofing, measuring, communicating, collaborating, and sharing knowledge—creating the foundation for a continuously learning and innovating organization.
When information systems naturally reflect Lean thinking, there is a
continuous systemic reinforcement of Lean behavior throughout all workflows and information flows. The integration of IT and the business accelerates the organization’s ability to learn, change, improve, innovate, and
grow.
True transformation starts from within, with the business and IT focused
on a shared strategic intent, discovering and solving problems together. The
transformation begins with people, process, and technology—in that order.


Endnotes

1. Steve Bell, Lean enterprise systems: Using IT for continuous improvement (Hoboken,
NJ: Wiley, 2006), 373.
2. John P. Kotter, “Leading change: Why transformation efforts fail,” Harvard Business
Review, March–April 1995, 1–10.
3. Earll Murman, Thomas Allen, and Kirkor Bozdogan, Lean enterprise value: Insights
from MIT’s Lean Aerospace Initiative (New York: Palgrave, 2002), 87.
4. Thomas J. Peters and Robert H. Waterman, Jr., In search of excellence: Lessons from
America’s best-run companies (New York: Warner, 1982), 322.
5. Jim Collins, Good to great (New York: Harper Collins, 2001).

Section V

Lean IT Case Studies

Case Study Topics.

Lean IT Topic
Waste
Kaizen - PDCA / DMAIC - Problem Solving
Cross-functional Teams
Standard Work
Problem Solving/Root Cause Analysis
Measurements
Flow/Pull
Systems Thinking
Strategy Deployment/Hoshin Kanri
Leveling Demand/Heijunka
Visual Controls
5S Workplace Organization

E RP
Barr

y-We
hm

i

ller Lea

n and
way

-L

alth

Mgm
t
way Fo

s Doc
- Virt
ual 5

Con-

cus
ed Va
lue S
tream
s

Con-

Ran

are D
ev
ean S
oftw

Grou
p He

ality
r Qu
ca s
Steel

d-O
rde

Inge
rsoll

Mgm
t
Data

e - Pr
oduc
t

ent
Virgi
n

ia

loym

ta
- Stra
tegy
D ep

Toyo

Lab O
rd

ers

Maso
n-

Case Studies

Barry-Wehmiller: Lean and ERP Work Together
Built on nearly 100 years of quality manufacturing history in Green Bay,
Wisconsin, Paper Converting (PCMC) experienced a decline in growth
and profitability in 2004. This company of approximately 900 associates and US$200 million in sales had seen conventional manufacturing
methods cause a run-up in inventory, placing the financial security of the
company at risk. Management had attempted to streamline processes by
implementing a large and well-known enterprise resource planning (ERP)
system several years before, but overcustomization led to greater complexity and less visibility to daily work.
In 2005 PCMC became part of the Barry-Wehmiller organization.
Founded in 1885, Barry-Wehmiller employs over 5,000 associates worldwide, with over US$1 billion in revenues across four product platforms.
Barry-Wehmiller had recently embarked on its people-centric Lean journey, and with their new vision to be a great American manufacturing
company, leadership at PCMC led a dramatic turnaround in the business,
moving from a large loss to a healthy profit in just one year. This turnaround was the result of many forces, including some restructuring of the
business and a cyclical upswing in the business cycle, but no one force was
greater than the ability of established PCMC associates to grow into new
roles of leadership and communicate a vision of a sustainable future for
the business.
As PCMC set its sights on sustaining the turnaround, its underlying business processes and ERP system would have to be addressed. Shortly after
the acquisition, senior leadership prioritized the transition from their previous ERP system to Barry-Wehmiller’s enterprise-wide standard ERP platform. This conversion was dually motivated by issues with the legacy system
and alignment with the ERP platform throughout the balance of BarryWehmiller. Although leaders from sales, operations, and customer service
269

270 • Case Studies
saw the importance of the project, they could not move beyond perceiving
the project as another software implementation led by the IT organization,
instead of an effort that would fundamentally impact business processes.
After a change in IT leadership and team composition, executive leaders soon realized that they had misjudged the scope; this was a companywide, not an IT-centric, project. Using their existing hoshin kanri strategy
deployment process, the ERP implementation was moved to the number one breakthrough priority at PCMC for six months. Resources were
assigned from every department, and the vice president of operations
became the project champion; in his words, “We had chaos; we had no
well-defined process. But the project allowed us to implement brand-new
standard work, to get consistent performance every single day.”
It was at this turning point that PCMC’s ERP implementation became
a vehicle for transitioning to a Lean way of thinking. Cross-functional
teams began to map the current system, finding waste in virtually every
process. In one example, 10 steps involving five people were required simply for an engineer to create a new part number. These teams found that
nearly every process in the organization relied on the ERP system as a
source of information or as a communication trigger for an activity in
another department. The only way to holistically improve their processes
was to redefine how they used the ERP system.
And that is what they did. Multidisciplinary task forces were created for
each major area of the organization: procurement, manufacturing, engineering, and assembly—breaking down silos for the first time. Each task force utilized Lean tools to get to the root cause of common frustrations, brainstorm
solutions, and create a future state plan. Meanwhile, the teamwork in each
group nurtured empathetic relationships where more people than ever before
within the organization understood the essential functions of all departments.
After ERP go-live in April 2008, the implementation team encountered
several difficulties; the project had not solved every challenge, but Lean
had created the process and team-oriented attitude necessary to address
them. Task forces quickly met and found solutions to lingering issues.
The ERP implementation concluded in August with glowing praise from
corporate operational and IT leaders, who called it “the greatest business
implementation in the history of the company.”
As PCMC continues moving forward, the value of utilizing a Lean
approach to drive the implementation and ongoing ERP change management is more apparent than ever. The entire reporting capabilities of the

Case Studies • 271
ERP system changed, producing a handful of real-time, actionable reports
to replace the reams of ignored reports of the past. The number of process
handoffs and delays has been reduced. Moreover, value stream stakeholders throughout the organization feel that the ERP system works for them,
rather than the other way around. In the end, PCMC accomplished much
more than the successful conversion to a new ERP system; it institutionalized the processes and support structures necessary to transition to a Lean
and sustainable future.
Brian Wellinghoff
Director of the Lean Journey, Barry-Wehmiller

Con-way: Document Management Virtual 5S
Con-way, Inc. is a US$5 billion freight and logistics company delivering less-than-truckload regional delivery, truckload long-haul freight,
and third-party logistics and warehousing services. Although Con-way,
Inc.’s corporate headquarters are based in San Mateo, California, many
of the centralized corporate functions are based at Con-way Enterprise
Services (CES) in Portland, Oregon. This location provides the majority of
the information technology, finance and accounting, and human resource
activities for Con-way, Inc.
The Information Technology division at CES includes departments for
each of the three business units, plus infrastructure, the web team, and
desktop services. Within these departments are dozens of workgroups that
create customer specific applications, maintaining and enhancing existing
systems to keep worldwide freight moving on schedule. Internally, these
departments provide full services to the 25,000 Con-way employees scattered around the globe.
Over time a lack of organized document storage procedures, standardized templates, and standard operating procedures (SOPs) created a host
of problems and waste for the organization. Documents and procedures
were stored in personal hard drives, various SharePoint sites, shared servers, and a variety of other locations. Team members often spent hours
each week searching for documentation. Upon finding documentation

there was no guarantee that it was the current revision, which led to
an investigation process requiring more time and energy. Compounding
the problem was the common practice of using e-mail attachments to
deliver files to coworkers, rather than providing links to specific locations where a master document was located. Several copies of files would
be housed in various locations, none of which had revision control or
a clear owner. In other cases documentation could not be located and
would need to be recreated, adding hours of rework to what should have
been a simple request.
Along with wasted time and frustration came additional business risk
to Con-way and its customers. For example, disaster recovery procedures
were difficult to locate and lacked standard formatting, which could create
delays during a recovery effort. Team members were especially frustrated
with the lack of organization around after-hours start-up procedures.
Frequently the on-call support person would be required to call other team
members throughout the night in order to locate specific documentation
for a system that had gone down. This was exacerbated by the number of
systems that were supported by the organization. Confusion, misdirection, wasted time, and frustration were daily occurrences as teams fought
to locate information that kept Con-way, and the customers they support,
up and running.
During the rollout of Lean office to the organization, one of the initial
efforts was a virtual 5S activity for many of the workgroups. Following
the 5S methodology, the teams made great improvements to the organization, upkeep, and accessibility of information. Here is a brief description
of the standard approach we developed, as we have rolled out this initiative across the entire campus.
Sort: Compounding the storage and retrieval problem was the sheer
volume of files that had been created over time, most of which were
outdated or no longer needed. Groups used file or directory searches
and cataloguing tools to analyze the information and identify
unwanted files. These unwanted files were either deleted or placed in
archives, where they would be purged if not accessed within a given
amount of time.
Set in order: A common location was established for workgroups, typically a SharePoint site or a shared drive accessible by all team members. Using tools such as card sort exercises, folders and structures

were established for the specific needs of each workgroup. The process
involved having team members sort cards labeled with contents or
functions into groups that made the most sense for that workgroup.
Shine: Files were placed in the appropriate location and hierarchy, based
on the structure each group had created. In many cases, several layers of the folder structure were restricted in order to avoid team
members “dumping” files at a top layer.
Standardize: An SOP was created for each storage site indicating file
structures, proper data storage protocols, and ownership for each
workgroup. Work groups also determined standards for document sharing, such as sending links to a master file rather than
sending the file itself. Standard templates and naming conventions were also created so that similar documents had the same
look and feel.
Sustain: In order to maintain the improvements, a number of sustaining measures have been put in place. Several layers of the
folder hierarchy are secured and assigned to an individual with the
responsibility for managing the new storage format and structure.
In addition, the top-level folder contains an SOP document outlining the storage procedures. Teams participate in quarterly reviews
of their storage locations, ensuring that the standard work is being
followed.
Best practices are now shared across the organization, allowing teams to
implement 5S methodology faster and in a standard format. As a result of
these activities, thousands of wasted hours have been avoided, amounting
to over US$200,000 each year in labor costs. In addition, many intangible
benefits have been realized: improved understanding of many common
workflow processes, reduced employee frustration, faster response to critical situations, and less risk to the organization should disaster recovery
ever be necessary.
Con-way Enterprise Services continues to implement the virtual 5S program throughout the organization, reaping the benefits of what was once
considered a manufacturing methodology.
Aaron Brown
Lean Manager, Con-way Enterprise Services


Con-way: Focused Value Streams
The Con-way IT organization supports a global enterprise of nearly 25,000
employees and is composed of application development and maintenance
teams for each major business unit within Con-way, Inc. Freight, Menlo
Logistics, and Truckload IT teams are supported with a shared services
group for enterprise architecture and computing infrastructure. This
case study focuses solely on the IT application development group for the
Menlo Logistics line of business, a third-party logistics service that offers
outsourced supply chain engineering, design, and transportation and
warehouse management services.
Menlo IT is composed of several functional teams that manage clientfacing, specialized, and highly configured software applications (e.g.,
Warehouse Management Systems) and that oversee internal business processes for sales support, customer on-boarding (start-ups), and customer
ongoing operations. This creates a matrix structure with highly skilled
and often specialized individuals assigned to multiple customer projects,
internal projects, and IT support tasks.
Current State
A senior IT executive observed the following challenges within his IT
group through observation and discussion with his subordinates:
• Excessive “thrashing”: People were spread across too many efforts,
experiencing frequent interruptions and task switching that caused
waste, lack of focus, and frustration.
• Customer enhancement projects of less than 400 hours had lead
times from 22 to 34 weeks, considered unacceptable by both internal
and external customers.
• Production support issues frequently drew people away from timecritical start-up projects, negatively impacting customers and the
perceptions of IT.
• New start-ups were often started suddenly with little advance notice,
negatively impacting all other work in the queue.
• Customer work was all consuming, and software development teams
were not able to focus sufficient time on improving their own internal processes.

• There was limited standardized work across software development teams.
• The organization was challenged to establish and meet commitment dates.
• The work environment was stressful due to the factors described above.
• Resource scheduling was overly complex, because employees worked on
multiple projects simultaneously. The dynamic nature of large projects
required frequent changes to work plans and resource assignments.
Proposal to IT Management
The senior IT executive made a proposal to his managers in early 2008, outlining a vision for change based on Lean principles of cost reduction, waste
elimination, standardization, cycle time reduction, and improved quality.
Specifically, the executive wanted to emulate a familiar approach from Lean
manufacturing called the focused factory and isolate the more stable IT
processes (production support and small- to medium-sized enhancements)
from chaotic processes (customer start-ups). He believed the focused factory concept offered a promising alternative and envisioned three value
streams within IT. The objectives of this realignment were to:
• Reduce cycle time for each logical IT delivery (value) stream
• Reduce complexity associated with resource scheduling and demand
management
• Improve visual controls for each value stream
• Level the work within each value stream, even though aggregate
demand was naturally variable
• Reduce waste associated with individuals constantly shifting between
projects and production support. Excess switching was estimated to
add 25 percent effort to tasks, causing unnecessary lead time and
quality problems.
• Reduce waste associated with reprioritization
• Increase focus on production support efforts that would improve
service availability (quality) and reduce defects
• Reduce waste associated with excess overtime due to poor
resource utilization
• Better balance individual workloads
• Address workforce frustration and stress

The IT managers collectively met in a workshop to discuss the vision
and identify key concerns, risks, and alternatives. The managers were
initially supportive but also apprehensive, since their teams were fully
loaded and there was no slack capacity to buffer problems should they
occur during the introduction of this new approach. So considerable time
was invested to clarify the goals and fully vet the issues. The managers
developed issues lists and prioritized them based on severity and impact.
They ultimately agreed to a modified version of the original approach by
starting with two value streams: production support, and projects and
enhancements. It was envisioned that enhancements could be segregated
from start-up projects into a third value stream at a later date. The managers identified subprocesses and specialized resources that were to be
shared across the value streams.
Much consideration was given to several key issues. First, the teams were
concerned about being co-located with others in the same value stream.
It was felt this would be too disruptive and limit the sharing of technical
information. Second, the team recognized the need to ensure technical
continuity across the value streams. Third, the production support value
stream (PSVS) was seen as being of less value; employees expressed concern about being asked to make what was perceived to be a downward
career change. Fourth, the managers were concerned about the volatility of demand in the projects and enhancements value stream (PEVS).
Countermeasures were developed to address each of these concerns.
The management team identified the major activities required to launch
the value stream structure:
• Clearly define the role of value stream owner
• Socialize with employees for feedback using a consultative decisionmaking model
• Inform the infrastructure organization of the changes that were taking place, as they provide the support to the production systems
• Assign employees across the value streams
• Finalize the key success metrics for both value streams
• Build the annual budget according to the value stream model
• Modify the customer work intake processes for each value stream to
make demand more visible
• Enhance the workload demand management process and firm up
the master-scheduling role

• Establish time-tracking conventions
• Ensure no negative impact on production control and change control processes
Owners for each value stream were selected, and roles and responsibilities were established. Since it was agreed to retain the existing functional structure in the beginning, the team also determined the roles and
responsibilities between value stream owners versus functional managers
(matrix model).
A team of individual contributors was formed with representatives from
each functional group. These are the individuals whose jobs would be
changed under the value stream model. These employees reviewed the value
stream concept and were given time to provide feedback to management.
Managers met individually with teams to answer questions and explain the
proposed benefits. Employees provided feedback via the representatives,
and management presented a formal written response to all 200+ employees addressing their concerns. This seemed to satisfy the employees, who
greatly appreciated the participatory model that allowed them to comment
on the proposed change. Management clarified its intent to move forward
with the rollout.
The managers then built their annual budgets, based on the value
stream structure, and determined the size of each team represented in
each value stream.
The value stream owners launched the structure by identifying one
representative from each functional team to be a core team member in
the value stream. This core team worked through success metrics, produced “as-is” and “to-be” value stream maps, identified potential kaizens,
and completed a continuous improvement roadmap. Each functional
team also finalized its employee rotation model. In some cases, the value
stream teams had to complete kaizens to establish standard work processes required for a value stream structure. After 12 months of development, feedback, buy-in, and preparation, all teams were successfully
split along value stream lines with new work intake and coordination
processes in place.
To support these changes, the IT sales and operations planning model
was modified so that only resources in the PEVS were built into the capacity plan. This reduced by one-third the number of resources that required
complex workload scheduling. In addition, time to work on continuous

improvement activities was built into each team’s workload plan, and visual
controls were added to show weeks of backlog and employee utilization.
Under the value stream structure, cross-team representatives identify
high-priority kaizen opportunities and execute them. Their progress is
reviewed with IT management each quarter.
Key benefits seen so far (given the structure has been in place for a
few months):
• The production support value stream has experienced less firefighting and overtime, because staffing is more dedicated and is
sized appropriately.
• There is less “thrashing” caused by people moving between value
streams, but it is not completely eliminated because of specialized technical skills of shared resources who must work across both streams.
• The projects and enhancement value stream teams can focus on
projects without interruptions from production support, and the
production support team members are able to stay more focused on
production incidents, providing faster overall response time. The
teams (and their customers) are already seeing the benefits.
• Team members are able to clearly see the lack of standardization
across their teams and the inefficiencies created.
• Teams are able to successfully identify, plan, and complete value
stream (cross-functional) kaizens with success. The functional structure originally inhibited cross-functional kaizens.
• There is improved cross-team collaboration when an incident spans
multiple teams. Having a production support gatekeeper monitor
e-mails and handle assignment and ownership of production issues
ensures that every reported incident or service request is addressed.
This has reduced effort associated with each team monitoring incoming report incidents.
• Although some teams are still having trouble finding time to work
on root causes to problems in the new production support process,
the teams report that capturing the root cause gives them visibility and focus when categorizing the issues. This will yield many
benefits in the future for Pareto analysis and prioritized kaizen
events.

Menlo IT will continue its Lean journey using the value stream
model. With time, IT expects to achieve all its stated objectives. Key
success factors include the slower pace of implementation, allowing
more time to engage employees in the change process. Assigning a
designated owner for each value stream has provided a point of focus
and accountability that will drive proactive change and continuous
improvement forward.
Richard Carroll
VP Applications, Menlo IT

Group Health: Lean Software Development
Aligns with the Business Strategy
Group Health provides health care and medical insurance coverage to
over 500,000 residents in Washington State and northern Idaho. Nearly
two-thirds of Group Health insurance plan members receive care in
Group Health–operated clinics, benefiting from their investment in electronic medical records and other technology-enabled practice innovations. The synergy and information sharing between health care delivery
and insurance enable Group Health to provide seamless, comprehensive,
and cost-effective service to their members, while helping to identify
many opportunities for patient-focused continuous improvement. Our
collective aspiration is to help define the future of quality and affordable
health care.*
We began our Lean journey in the summer of 2006. The operational area
of the Health Plan was designated as the “model line” to pilot Lean efforts,
and within the Health Plan three value stream segments were selected to
be the first out of the gate, including the Application Management value
stream, which provides software development and maintenance to support
health plan operations. Application Management was chosen as a primary
focus because the smooth flow of information is vital in a health insurance “information factory” and frequent changes to provider agreements
* Kevin Sack, “Health co-op offers model for overhaul,” New York Times, July 7, 2009.

and regulations drive constant change in business rules and systems. Bill
Siemering (IT) and Mike Manis (Business) together led teams in defining
the current and future states, representing the activities of business and IT
throughout the value stream.
The Current State
The current state was a typical scribble of waste and delay, long on managing the backlog and creating detailed requirements documents, but short
on releasing quality software on schedule. Not that work didn’t get done;
it just wasn’t the work on the list. Instead priorities were “red-phoned” in
from a vice president or pushed under the door to a programmer friend.
Customers were unhappy, work was not visible, and there was no discernable prioritization or delivery process.
In the initial phase of the model line deployment, we wanted to accomplish a limited set of objectives:
•
•
•
•

Make the work visible
Control work intake
Create a visible daily work management system
Implement Lean techniques, such as last-minute requirements focusing on value
• Change the culture by tearing down silos and creating cross-functional work cells
To help us quickly close the knowledge gap, we brought in a Lean consulting group and invited a team of developers, architects, and business
analysts for training. We then engaged the team in discussions on the
“what,” “why,” and “how” of our mission. While we knew the “what” in a
broad context (using a Lean/agile approach) and we could articulate the
“why” (we needed to become more efficient in supporting organizational
goals), the “how” we had to develop as a team.
The Future State
The future state was developed using a Rapid Process Improvement
Workshop (RPIW) approach where the teams spent many hours over the
course of five days working together to design the new process and plan

the implementation. Although the work was at times a little contentious,
we emerged with a well-documented plan that was ready to implement. We
began immediately, providing last-minute training to business managers
who had new work to submit into the backlog, using detailed process flows
and targets developed during the RPIW to keep us on track. Everyone who
participated in the RPIW was included in one or more aspects of the new
process and helped guide the remaining participants. We converted existing project manager positions to take the role of scrum masters, identified
product owners, and created three work teams: one for maintenance, one
for smaller enhancements, and one for strategic work. We were not at all
sure that this was the best configuration, but decided that it was as good as
other ideas and we could fine-tune later with PDCA.
As we began the implementation, we established a work intake system
that accepted only the highest prioritized work in the backlog: up to three
sprints, where each sprint represents approximately four weeks’ work. In
other words, our planned backlog is maintained at a stable three months’
work. Identification of potential projects came from business owners who
would describe the high-level business need, the expected return, and any
other significant drivers of the work. Business owners from multiple departments from across the value stream would then prioritize each work item
against all others in the backlog. Work was then completed in rapid sprint
cycles, achieving a just-in-time approach to meeting our customers’ highest priority requirements. Contention in prioritization decisions was minimized through group discussion; if a business owner thought his or her work
should be set at a higher priority, he or she was required to justify the change
at the meeting based on value. If consensus could still not be reached, a vote
would be taken. Occasionally, issues were elevated for resolution.
Our Progress So Far
The cornerstone of our methodology is prominent visual systems in all
work areas containing backlogs, front burners, and burndown charts,
supported by teams dedicated to keeping them up to date. Internally
developed software (mostly Excel based) is used to track all activity, produce reports, and print artifacts on colored cards that are posted on the
visual boards.
Each month we host a day-long work-planning and intake session
where business owners bring new Use Cases: a brief description of the

desired business outcome and expected return. Use Cases are reviewed
and prioritized by the business owners, and then unfolded into “stories,”
or buckets of work necessary to complete the Use Case. Stories are sized
by technical staff with business owners present to provide additional
information as needed. The backlog is updated from the planning and
intake session.
The next step is sprint planning. Available hours of staff capacity are
determined for each sprint. Then, starting with the highest priority, stories
are further unfolded into tasks, and each task is assigned a time estimate to
complete. The sprint is full, and the “front burner” filled when scheduled
tasks fill available hours for the sprint. We plan for slack (nondevelopment
time) by building time standards for scheduled meetings, regular e-mail,
and other necessary activities into our available capacity calculations. No
additional buffer is built into the work plan.
Work is divided among three self-contained work teams, each of
which includes architects, developers, and business analysts. Each team
maintains its own visual display area containing all of the stories for
the sprint and index cards for each task. Developers “pull” work simply by moving the kanban card for the highest priority story into the
in-process section. Unexpected production support requirements can
be pulled into process at any time, without causing disruption to the
schedule. This can happen since there is a dedicated work cell for production and maintenance that has scheduled time for unexpected problems. This flexibility is also supported by a heijunka schedule which
allows us to shuffle the sequence of work in the queue at any time until
it is released to production.
Progress is tracked daily via burndown charts that graphically display
the hours remaining in the sprint against the hours of work left to complete. Teams huddle daily to review burndowns (ensuring progress is on
pace for the sprint cycle) and to evaluate what work was completed yesterday, evaluate what will be worked on today, identify remaining hours to
complete, and discuss any constraints or barriers.
Going Forward
In late 2007, our CEO made the commitment to deploy Lean throughout the entire organization, using hoshin kanri (strategy deployment) as
a standard management system, while leveraging our progress in health

Hoshin Kanri at Group Health
Executive
Leadership Team

Strategic Planning
Catchball

Care Delivery
Health Plan Administration

Division Planning
Catchball

Operations and
Improvements are
driven by Value Stream
Outcomes

Functional Planning

Quarterly
Planning
Cycle
Monthly
Execution
Cycle

Catchball

Business drives
change and
prioritizes eﬀorts
by value, IT
pace regulates
capacity


BACKLOG

Business
Team
Members

IT Software
Development,
Support and
Maintenance

IT Infrastructure and
shared services (ITIL)

Requirements
change:
provider
contracts,
regulations,
etc.
Service Desk
Production
Issues

Figure 12.1

Hoshin Kanri guides software development priorities.

plans as a solid foundation. Over the past 18 months we have constructed
a tiered hoshin kanri plan that encompasses the whole enterprise. We
have just launched a significant business intelligence initiative, designed
to provide quality information to support continuous improvement and
the hoshin kanri planning cycle. (See Figure 12.1)
Strategic priorities cascade through divisions and layers of management, feeding the application management backlog and providing business case justification and prioritization guidance. The backlog is also fed
directly with production problems identified through various sources,
including the IT service desk (where we are currently implementing
ITIL). Our Lean Management System is helping the teams responsible
for Applications Management, as well as other areas of the IT organization, focus on delivering services that are most needed in order to provide the best health care to those who matter most: our members and
patients.

While we have been on this journey just a few short years, we have
already begun to realize significant benefits in many ways as Lean behaviors and culture take hold.
Bill Siemering
Executive Director, Health Plan Information Technology, Group Health
Mike Manis
Director, Health Plan Administration, Group Health

Ingersoll Rand Security Technologies:
Lean Six Sigma Improves Order Quality
Ingersoll Rand (IR) is a US$13 billion global diversified industrial company, driven by employees who are proud to offer products and solutions
people use every day to create a positive impact in their world. Driven by a
100-year-old tradition of technological innovation, we enable companies
and their customers to create progress. Our Security Technologies sector
provides state-of-the-art security solutions for residential and commercial markets.
This case study describes the challenges of entering complex order information into a business system with the goal of achieving 100 percent accuracy. It describes the problem-solving process undertaken, and the tools
utilized to dramatically improve the process for manufacturing industrial
doors and related hardware.
Problem Description
There are an unlimited number of product configurations and order
possibilities that may be required to meet our customers’ needs. The
placement and fulfillment of a customer’s order require the entry of the
customer requirements into the manufacturing and business information system. Critical parameters that must be accurate include size, shape,
material, color, finish, and key locations for locks, closers, and other associated hardware, and a correctly calculated price for the configured item.
Customers often provide product specification information in their own

format, which typically does not match the format of our system, creating the potential for additional errors introduced during data translation
and entry.
Orders are received into the sales support area via fax, e-mail, and
traditional mail. The first step is to understand what the customer is
trying to order. This is not easy, since there are myriad ways to describe
what is actually desired. Order entry associates must also determine if
what the customer orders is truly what is necessary to meet fire, safety,
and weather-related requirements. This requires an understanding of
the customer’s specific application, as well as regulations in locations
worldwide.
Once the order has been clarified and reviewed, next it must be entered
into our information system. A product configurator has been developed
to enable us to meet many of our stock offerings; however, it is virtually impossible to predefine all likely combinations. When a configuration isn’t available, the order entry personnel must then key in the order
manually. This tedious process requires a great deal of product and application knowledge; order entry personnel must understand products and
how they are constructed, specific applications, specific door construction techniques, and specific hardware locations and requirements. This
manual process creates a fairly high risk of error.
There are many consequences from this error-prone process: delays,
errors, and rework. The high occurrence of defects via manual order
entry can cause disruption within the order entry function, in manufacturing, and also with customers. Variation of the ordering process is the
enemy. Understanding what causes the variation and dealing with root
cause issues comprised the focus of this problem-solving effort.
IR took on the task of improving the order entry process, utilizing the
DMAIC approach (below) and Six Sigma tools (see Appendix B for more
on Lean and Six Sigma)
The DMAIC Approach
•
•
•
•
•

Define the issue
Measure and quantify the impact of the issue
Analyze the issue: Determine root cause
Improve the process
Control the process

Define

Deal with quality issues (defects), improving the overall order entry accuracy and a reduction in variation.
Measure and Analyze

With the aid of an outside consultant, the group established a metric
for counting total defects. The process was mapped, and defects were
recorded at key internal process points. Understanding where defects
occurred in the process was vital to solving and addressing the issue.
Key tools utilized were process maps, supplier–input–process–output–
customer analysis (SIPOC), operational definitions, and quantitative
methods. Statistical process control was used to trend errors and highlight special causes of variation. Probability analysis was also applied to
predict total defects by type. Fishbone diagrams were used to analyze
potential defect causes. Data collection showed that one of the key process variables was the influence of operator knowledge and skills. Several
experienced operators had developed a “knack” of entering, checking,
and providing defect-free orders.
Improve

Once this knack was discovered, it was captured, standardized, documented, and spread throughout the department through a mentoring program. Creating standard work enabled the process to initially drop defects
by 50 percent within the first six months of the project. Key tools utilized
were control charts, which were used to identify patterns and trends over
time, and Pareto analysis.
Process specialists were also engaged to determine where additional
information systems improvements could be made. These individuals
made many suggestions on ways to mistake-proof the order entry software.
By engaging the operators in a cross-functional team, specific intelligence
was built into the software, making it easier to enter the order correctly the
first time.
Early involvement by the IT organization, establishing a collaborative relationship between IT and the operators, enabled rapid and simple
enhancements to existing software. Look-up tables and search functions
were added to the system, which helped order entry operators find key

I Chart of Total DPU_4 by Stage
1

0.07

Before

0.06
Individual Value

2
1

A
After

0.05
0.04
0.03
1

0.02
0.01

UCL = 0.03978
X = 0.03332
LCL = 0.02685

0.0062

0.00

D

5-

ec

D

26

ec

n

-Ja

16

b
Fe

6-

eb
-F

27

ar

M

20

Week

r
Ap

10

ay

M

1-

ay

M

22

n n
Ju Ju
5- 19-

Figure 12.2

Order Quality Control Chart

information much easier and faster. IT was also able to add enhancements
to mistake-proof key error sources in the entry process.
As a result of these efforts, defects have been reduced dramatically. The
process itself is approaching a 70-percent reduction in defects, moving
from 0.5 sigma to 3.53 sigma. Customer satisfaction has also improved
tremendously.
Control

A plan was put into place to help sustain the gains. Improvements in quality,
stabilization, and consistency enabled the effective use of traditional Lean
tools for continuous improvement efforts now underway. (See Figure 12.2)
Lessons Learned
Early involvement of IT resources with the inclusion of operators and support personnel in a combined team effort, was instrumental to our overall
success. Understanding the process, involving those who work the process, and seeking outside advice were vital to making the process better.
Having the discipline to adhere to the DMAIC method generated significant gains, delivering value to our customers.

Rajesh Solanki
Director of Lean Six Sigma, Ingersoll Rand Security Technologies
William Kemerer
Lean Six Sigma Manager, Master Black Belt, Ingersoll Rand Security
Technologies
Brent White
Master Black Belt, Ingersoll Rand Security Technologies

Steelcase: Product Data Management
Lean Transformation
Steelcase Inc., headquartered in Grand Rapids, Michigan, leads the world in
office furniture sales and manufacturing with over US$3 billion in annual
revenue. One element of our success is a wide offering of products, options,
and finishes. Supporting this large variety of selections in the company’s
portfolio (estimated at over 22 quadrillion variations) creates many challenges throughout the development cycle. The Product Data Management
(PDM) group is charged with maintaining all of the product information
within SAP and other supporting systems. The challenges became critical
when new development projects were delayed because the data could not
be built fast enough—PDM had become a product development bottleneck.
In 2002, the chief information officer (CIO) appointed a new leadership
team that recognized the potential to apply Lean concepts from manufacturing to solve problems in the PDM office processes. The product data
responsibilities were originally fragmented across several departments
which reported to separate leaders. The departments were merged into
one, but the responsibilities still remained largely within functional silos.
Then, during a Lean workshop in the spring of 2003, steps of the new product development PDM process were posted on a large conference room
wall. The wall, littered with hundreds of supporting documents, showed
the complexity of the current state, evidence of rework estimated at 50
percent, and numerous handoffs resulting in delays while people waited
for information. The “wall of shame,” as it became known, exposed the
problems, but they were not solved until value stream mapping techniques

documented the current state and envisioned a future state. The future
state map spawned multiple kaizens, which provided the initiative for
change. One initial kaizen quickly improved the data building of customer service parts, and another addressed the speed and efficiency of
creating data for a new product that was being designed.
Initial kaizen experiments were designed to avoid batch processing by
creating cross-functional teams, enabling work to flow across functional
boundaries. Using the value stream map, handoffs were analyzed, and
many were eliminated by changing work responsibilities or placing workers in closer proximity. Initial experiments proved successful, revealing
the need to reorganize the entire PDM department. In May 2004, the
PDM group restructured to better support the business, dividing into five
teams to align with the business categories of seating, furniture, work
tools, wood, and small business furniture. These new PDM teams each
supported the entire product development process for their category, and
management accepted new roles in managing across functions instead of
by expertise. Now, individual experts, resident on each team, create marketing data, edit catalogs and specification guides, and build the manufacturing data. The five teams work in close proximity to each other,
reporting to a single director, using a common fileshare and intranet,
and sharing discoveries and improvements with each other. The results
were rapid and dramatic. Just five months later, the teams eliminated
the project backlog. Through ongoing kaizens, the PDM group doubled
their productivity and reduced the lead time from 36 weeks (nearly nine
months) to just four weeks, removing the bottleneck from the new product development process.
Additional kaizens focused on data quality at their source. The teams
created a checklist for data readiness, determining at what point in the
product development life cycle data should be loaded into the system
based on the accuracy of the information provided by the business category. The way that data are delivered to the teams is now standardized with a spreadsheet template, used by all marketing personnel across
the business. By not starting work early, the teams avoid the wastes of
repeated data changes, delays, and false starts. Management validated
that the initial rework estimates of 50 percent were accurate. As a result
of improvements to data quality, rework was reduced to 8 percent,
which significantly contributed to the teams’ increased productivity and
throughput.

A new role, titled the information funnel, now exists on each of the five
category data teams. The individual fulfilling this role works with other
departments in engineering and marketing to complete the data readiness
checklist, also providing valuable project coordination. The information
funnel role, modeled after the zone leader in a Lean manufacturing cell,
facilitates a daily team meeting at a visual control board to track the flow
of data through the process, the production of data in the systems, and any
flow interrupters within the process.
Initially, all product development projects were scheduled in batch
mode, and the recurring three-month deadline created a predictable
and dreaded pinch point. Now the team creates data as soon as they are
ready, and downstream processes, such as catalog creation and planning
symbols (used by architects to place furniture in office layouts), naturally
flow in sequence afterward, leveling the demand and workload. PDM has
reduced their cycle time by 33 percent, delivering updates at a frequency
of two months instead of three.
In 2008, the teams turned their attention to the process of building the
catalog data. The Steelcase product offering is cataloged in over 40 documents—each several hundred pages in length. Imagine a shelf of encyclopedias from A to Z; this resembles the row of catalogs. They exist in both
paper (printed annually) and electronic media (updated bimonthly). The
large quantities of furniture images, product descriptions, and pricing
in these catalogs are updated and manually synchronized with several
other data sources, such as enterprise resource planning (ERP), catalog data, and a catalog-authoring tool (manual integration waste is on
the list for a future kaizen). Because of the complexity and specialization of the work to update the catalogs, an outside vendor traditionally
completed the task. To streamline this process, the teams borrowed the
concept of a visual heijunka schedule from the manufacturing plants,
tracking the progression of work through catalog building and releasing
catalog sections to printing only when they are ready. The heijunka visually shows the status of each catalog moving through the process, signaling the upstream processes when one completes and the next cycle can
begin. With the perfected heijunka board in place, the catalog production process flows more smoothly, speed and efficiency have increased
dramatically, and all of the external work has returned inhouse, bringing savings to the bottom line.

Improvements such as these have generated hard, bottom-line savings
of over US$3 million just within the PDM group since the start of the
initiatives. The removal of the PDM bottleneck eased pressure in the new
product development organization and helped to ensure that products are
released to market on schedule. Besides monetary savings, every other key
performance metric improved and the team became a model of a Lean
transformation within IT and across Steelcase.
Mark Swets and Tim Schipper
Lean Coaches, Steelcase
Co-authors of Innovative Lean Development

Toyota Australia: How IT Helped Implement
Breakthrough Strategy Management
Toyota Motor Corporation Australia (TMCA) is one of Toyota Japan’s
global manufacturing centers with a long-term commitment to the domestic and export markets.
TMCA’s head office function and manufacturing and engineering
activities in Melbourne are complemented by comprehensive sales and
marketing operations based in Sydney. Additionally, TMCA has sales and
distribution branches in all mainland Australian states. TMCA employs
over 4,500 people, and thousands more are employed through its supplier
and retail networks.
As well as its locally built Camry and Aurion, Toyota imports a wide
range of passenger, 4WD, and commercial vehicles including the Kluger,
Yaris, Corolla, Tarago, RAV4, LandCruiser, Prado, HiLux, HiAce, and the
revolutionary hybrid model Prius. TMCA has also been successful in adding to its local manufacturing capability the Hybrid Camry from 2010.
Toyota is Australia’s largest vehicle exporter, and in 2008 exported
101,668 cars to over 20 countries worldwide. This strong export drive contributed over AU$1.9 billion (including parts and accessories) in revenue
for TMCA in 2008. TMCA’s domestic sales in 2008 were 245,000 vehicles
(including the Lexus). In addition, TMCA distributes and sells the luxury
Lexus brand of vehicles.

Strategy Management at Toyota Australia
Strategy management is about setting and prioritizing mid- to longterm management plans and annual targets, while engaging all levels
of the organization to clarify their own measures and targets. Strategy
management at Toyota emphasizes the concept of breakthrough
thinking.
In 2000, TMCA implemented a “whole-of-company” strategy management process to all 700 executive staff. Over a five-year period, the
Corporate Strategy Division worked with Board and C-level executives
and their management teams to create clear corporate goals, long-term
objectives (two-year fixed, and three-year aspirational), supporting key
performance indicators (KPIs), and action plans. TMCA did this by combining the Balanced Scorecard (BSC) method with Toyota’s best-practice
processes for continuous improvement, problem solving, and people development. At the core of this initiative was a sophisticated end-to-end strategy management process, with significant focus on strategy visualization,
communication, and execution.
The key challenge faced by Toyota was how to align senior management to “breakthrough” corporate strategy so that everybody understood
their responsibilities and was personally committed to delivering the plan.
Toyota approached this challenge by implementing a logical and consistent
process for setting targets, managing initiatives, and rewarding for achievements at all levels of the company. This process was “visualized” in a simple
but very effective Online Balanced Scorecard application, which was built
inhouse as an agile collaboration between Corporate Strategy and IT.
Balanced Scorecard History
Through better strategy management, TMCA aims to be an organization
which is capable of sustaining high performance, as well as achieving the
specific results required for TMCA to be what is known in the Toyota
world as a “self-sustaining” affiliate. To this end, TMCA first deployed the
Balanced Scorecard as its strategy management tool in 2000. Since that
time, TMCA’s online strategy management system has:
• Increased visibility of strategy: With an Online BSC system composed
of over 150 integrated scorecards and more than 2,000 targets

• Aligned strategy processes: Using BSC as a “strategy hub” linking
the president’s goals, the long-term business plan, budgets, the
individual performance development process, and the short-term
incentive process
• Improved strategic balance: With more emphasis on the “people”
window
• Introduced president’s strategy reviews: Annual visits to each division
by the president to review BSC performance
• Streamlined strategy management process: With the introduction of a
simple user interface and standard management process, supported
by a central database and standard reporting and analysis tools, the
time invested by each employee in the strategy management process
becomes more focused, leading to improved insights, greater opportunity to take corrective action or develop emergent strategy, and
more time to focus on other activities
Evolution of Hoshin Kanri (Breakthrough Strategy Management)
Toyota has a well-documented history of Lean thinking, continuous
improvement, and people development. As Toyota rapidly expanded in
the 1990s and 2000s, Toyota’s leaders realized that the transformation
from an international company into a truly global company required a
vital reliance on new Toyota employees who had different ways of working
due to their varied experiences and cultures. The days of Toyota being a
“Japanese” company were over.
Increasingly, it was necessary to reinforce and reteach the fundamental
principles that made Toyota such a successful and respected company. To
achieve that goal, the Toyota Institute was formed in 2001. The Toyota
Institute’s purpose is to increase the global understanding and application of the Toyota Way, through the four components of the Toyota
Management System:
• Toyota Way Foundations: Values, beliefs, and principles such as continuous improvement, problem solving, respect, and teamwork
• Toyota Business Practices: Problem-solving thinking, tools, and
techniques
• Hoshin Kanri: Problem solving applied to the achievement of longterm “breakthrough” goals

• On-the-Job Development: Stretching and growing individual and
organizational capability
Once the hoshin kanri thinking, tools, and techniques were documented
and delivered through Toyota Institute training courses (called global content), each affiliate was expected to integrate the practices into its existing
business processes.
In 2007, this prompted TMCA to refine existing processes and tools such
as the president’s goals, the long-term business plan, the Balanced Scorecard,
and the performance and development process to fit with hoshin kanri
language, thinking, and principles—supporting the one Toyota global
standard system for breakthrough strategy and people management.
Importantly, the Balanced Scorecard system used by TMCA was a system in the broader sense of the word—covering people, process, information, and technology—as the enabler. So the transition to hoshin kanri
was essentially tweaking the terminology and templates without needing
to change the underlying philosophies or processes.
So what is hoshin kanri? Hoshin means “direction or needle,” as in a
compass; and kanri means “management.” So hoshin kanri means “direction management,” with a focus on “new” or “breakthrough” objectives.
Hoshin kanri principles are:
•
•
•
•

Mid- to long-term viewpoint: focus on priority goals
Vertical alignment: unity in direction
Horizontal coordination: ownership by all
Human resources development: people growth through on-thejob development
• Process management: sustained results through Plan-Do-Check-Act
(PDCA) and problem solving
Evolution of the IT Solution
It required two full years of business process design, redesign, development, testing, and continuous improvement to create a company-wide
process that was ready to be automated in 2002. The solution was developed internally using existing TMCA IT resources. Balanced Scorecard
software was available off the shelf in 2002, and most of the existing systems we examined focused on turning masses of structured data within

business core systems into precious gems of strategic insight. But missing
was a system that was very simple for people to use, and importantly one
that enabled them to enter their own strategy information—most of which
was unstructured data (commentary) such as results, successes, struggles,
countermeasures, and future activities.
For this reason, TMCA committed to the continuing development of
our own inhouse system, which over time has evolved as a key component
of our internal management systems and communications. TMCA’s goal
was to create a strategy management system that would enable knowledge sharing and collaboration rather than a sterile database of highly
structured data. It had to look and feel “human” or “personalized” to be
accepted and used by front-line employees.
To build a system that was “human,” it was preferable to use a development method that was rapid, flexible, and cost-effective. As the
architect of the Balanced Scorecard management system was willing and able to be highly involved in the development process, and
as there was no precedent for the software design, the development
process followed an agile method. Following many white-boarding
sessions and design discussions with key stakeholders, the initial version of the Online Balanced Scorecard was delivered within 12 weeks.
Importantly, senior management were shown the first release so they
could see the working product as soon as possible, helping to build
understanding and sponsorship for what would become the “corporate” strategy management application.
It is worth noting that while the Online Balanced Scorecard system was
regularly enhanced from 2002 to 2006, the core functionality and look
and feel remained constant for the next five years, demonstrating a key
Toyota principle of get it right the first time.
In 2007 the Online Balanced Scorecard was renamed the Online Hoshin
System, and the terminology was aligned to match the Toyota Institute
training material. For example, business objective descriptions were
restated in the “Why, What, and How” hoshin format to improve the
hoshin cascade process, and the column called “Countermeasures/Future
Activities” was broadened to be “Countermeasures/Future Activities/
Expected Results Next Period” to improve management’s ability to follow up actual versus expected results in the next management meeting
(PDCA).

Strategy Management Processes
The Online Hoshin system has two key views:
• A “scorecard” containing objectives, measures, targets, and performance ratings
• A “planning sheet” for each measure containing the initiatives to
support the measure together with commentary on successes, struggles, countermeasures, etc., and attached supporting data to visualize performance (e.g., graphs, tables, and A3 one-pagers).
The process to build a hoshin scorecard is a combination of Western
strategy thinking and Japanese Hoshin planning—so it is a good example
of East meets West. Put simply, the process has five main steps:
Step 1. Assess current environment and identify key challenges—stakeholders; strengths, weaknesses, opportunities, and threats (SWOT);
corporate priorities; mission; market and environmental changes;
vision; and reflection on the previous year’s performance (PDCA).
Step 2. Express challenges as “concrete” problems to be addressed, with
tangible measures and targets.
Step 3. Identify root causes of these problems and set countermeasures
(by whom and by when) to address root causes.
Step 4. Capture “problem” measures and targets in hoshin plans at the
relevant level.
Step 5. Capture “countermeasure” or initiative measures and targets in
hoshin plans at the relevant level.
Spinning wheels normally indicate a lack of traction, but at Toyota it is the
spinning PDCA wheel that accelerates strategy execution. Throughout all
steps in this process, there is constant “catchball”; regular use of the system encourages and facilitates consensus and understanding, visualization, and problem-solving thinking.
If you take a look at the daily and monthly standard management processes that support strategy execution, you will see some pretty basic practices that you would expect any management team to apply. The difference
with Toyota is that there is a big cycle of PDCA with smaller cycles within
each phase, as shown in Table 12.1.

Table 12.1
Toyota Strategies and Management Processes
Strategy (S)
Management Phase

Supporting Management (M) Processes

S-Plan (Q1)

M-Plan: Align long-term, short-term, and operational
planning processes
M-Do: Create the plan
M-Check: Test understanding and commitment to the
plan through “catchball” (Online Hoshin System)
M-Act: Adjust the plan based on catchball feedback

S-Do (Q1–4)

M-Plan: Create action plans to support higher level
initiatives
M-Do: Manage action plans using project management
and problem solving
M-Check: Visualize status using charts, tables, and A3
one-page reports (Online Hoshin System)
M-Act: Take corrective action to keep activities or tasks
on track

S-Check (Q1–4)

S-Act (Q1–4)

M-Plan: Schedule regular strategy review meetings up to
one year in advance
M-Do: Senior management leads by example to check on
progress (genchi genbutsu)
M-Check: Conduct strategy review meetings—identify
countermeasures (Online Hoshin System)
M-Act: Continuously improve quality of review
meeting (e.g., coaching and mentoring participants)
M-Plan: Set countermeasures (by whom and by when) to
address root causes of performance issues
M-Do: Deliver countermeasures
M-Check: Visualize effectiveness of countermeasures
(Online Hoshin System)
M-Act: Address recurring problems in the next round of
strategy planning

One of the greatest challenges with strategy execution is how to make
the strategy visible, so it can be proactively managed. The Online Hoshin
System is a key driver of business strategy because it makes it easy for
everyone from the front line to the executive board to see what the strategy is and how are we doing. The basic question in the strategy game is

“Are we winning?” Toyota leaders and managers alike are always expected
to know whether or not they are winning—and why.
IT as a Customer of the Hoshin System
With Toyota’s relentless focus on Lean operations, all shared “support”
functions such as IT are required to argue their case at least annually
(and more frequently in the current economic climate) for capital funding, operating funding, and people. Status quo is not the norm—real value
creation is expected.
One of the greatest challenges any IT operation faces is how to demonstrate the value that IT brings to the business. In TMCA, IT needs to be a
true business partner, and one of the simplest but most powerful ways of
doing that is to start the conversation with the business about their business strategy and determine how IT adds value, not just cost.
Understanding the real business priorities builds relationships, trust,
and confidence. Generally speaking, businesspeople can be cagey about
their strategy—especially when the questions are coming from a service
division like IT. So when a business leader is asked, “So—what’s your
strategy?” a likely response is “Why are you asking?” or even “None of
your business” or worse.
With access to each division’s hoshin plans, IT (and other service functions) has the information it needs to explain to the business how IT can
help the business achieve their objectives, without an enormous effort to
extract the key elements of the strategy from the business leaders. One
example of this approach is the Hoshin/IT Solution matrix (Table 12.2).
Another example of this approach is the IT Solution Roadmap
(Table 12.3).
Portfolio Management and Project Prioritization
One way to “balance” the IT portfolio is to allocate the expenditure based
on generic categories such as run, grow, and transform. Another way is to
give priority to projects that deliver tangible benefits to a specific hoshin
strategy. By having a system that “staples” business objectives and KPIs to
corporate, operating arm, and divisional hoshins, greater priority can be
given to projects that directly support group strategy.

Table 12.2
The Hoshin/IT Solution Matrix
IT Solution A

IT Solution B

O
—
—

O
O
Δ

Business Objective or KPI
per Hoshin System
Strategy 1
Strategy 2
Strategy 3

IT Solution C

Δ
—
O

Legend: O = Strong support; ∆ = some support; — possibly no support.

Table 12.3
The IT Solution Roadmap
Year 1
Business Objective / KPI
per Hoshin System
Strategy 1

Year 2

Year 3

Year 4

Year 5

IT Solution A
IT
Solution
B
IT Solution C

Strategy 2

IT
Solution
B

Strategy 3

IT
Solution
B

Legend:

IT Solution C

Strong Support
Some Support

Boards and IT investment committees are normally interested in aggregate value for money for IT investment, so it is easier to report investment
at the rolled-up group hoshin level rather than as a project-by-project fragmented view. Having an IT service management approach to organize how
business objectives combine to support group hoshin enables TMCA’s IT
division to communicate the value-for-money story at the group, operating arm, division, or project level.

IT resource planning, loading, and balancing are also made easier by
aligning and prioritizing the “wish list” projects from the development
pipeline with specific hoshin plans. A greater focus on projects with tangible benefits that are linked to hoshins assists IT to negotiate for the right
level of resourcing with the right skills to deliver value back to the company.
It’s Not All about IT
Toyota relies on talented people and good process—not computers—to
achieve great things. The Online Hoshin System is not a substitute for
analysis, communication, questions, and answers. It never will be, and it
is not meant to be. The Online Hoshin System is a tool to help efficiently
focus the attention of people on what’s important—the strategy, and the
necessary actions to achieve it. If leaders and managers do not care about
strategy or are too busy or distracted from strategy, then the information
technology investment in the planning system will be wasted.
Information technology has a crucial role to play, but it is part of a
broader mix. The Toyota Way focuses on human interactions—face-toface wherever possible. All Toyota people are encouraged to go to the
gemba (physical workplace) and see, touch, and feel for themselves (genchi
genbutsu). The principles of teamwork and collaboration are very strongly
present in the day to day of the Toyota Way.
The TMCA Online Hoshin experience has demonstrated that IT systems can help busy leaders, managers, and workers come together in a
constructive way to solve strategic or important problems that are far
too often hidden by the sheer volume of urgent “daily management”
activities.
John Houlihan
Corporate Manager Business Development, Toyota Australia
James Scott
CIO, Toyota Australia


Virginia Mason Medical Center: Laboratory
Order Process and System Improvement
Background
Virginia Mason is a not-for-profit, integrated health care system with a 336bed hospital and nine locations, including the main campus and regional
centers. More than 450 physicians are on staff, and there are 5,000 employees. Virginia Mason is also a teaching institution with a robust graduate
medical education program and a world-class research center.
The health care industry has a defect rate of 3 percent or more, a rate
unacceptable in any other industry. Defects have a high human cost, and
they also have a huge business cost. For example, a study in 2000 showed
that six types of preventable inpatient complications cost US$9 billion
annually. That’s just the tip of the iceberg.
In 2001, Virginia Mason adopted the Virginia Mason Production
System (VMPS), a management method that seeks to continually improve
how work is done to ensure zero defects in the final product. Using this
method, Virginia Mason (VM) identifies and eliminates waste and inefficiency in the many processes that are part of the health care experience,
making it possible for VM staff to deliver the highest quality and safest
patient care. VMPS is based on the Toyota Production System (TPS).
Improving the Laboratory Order Process
In July 2008, stakeholders from the Laboratory and Information Systems
departments at Virginia Mason met and agreed that improving the process for ordering outpatient laboratory tests was crucial. The number
of Patient Safety Alerts (PSAs) related to orders for tests was climbing.
(PSAs are part of a system at Virginia Mason that empowers all staff
to report situations that do, or might, put a patient at risk of harm.)
Although several creative steps were implemented to mistake-proof the
current ordering process, errors continued to slip through, and the teams
trying to improve this process felt that the continuing errors occurred
due to inherent defects embedded in the design of the system. The longterm solution would be the implementation of a computerized provider
order entry (CPOE) system. That, however, was still some years away

due to capital and resource constraints. In addition, parts of the current
information system in use were scheduled to be phased out. As a result,
it was decided to design and implement an interim test-ordering process
that could minimize ordering errors and at the same time streamline
the current order process. It was understood that this interim process
would not delay in any way the future implementation of CPOE in the
ambulatory setting.
Using VMPS tools, the IT department and the laboratory together
conducted a root cause analysis to document exactly where and why
the current process and system were failing, and to understand what an
ideal interim process (until CPOE was implemented) might look like.
The root cause analysis found a process riddled with defects leading to
the PSAs:
• Lost orders, double orders, defective orders, and illegible orders
• Patients arriving without orders
• Orders that were not executed, making it necessary to call patients
back to the lab
• No coherent, consistent method for performing laboratory order surveillance, or for verifying if and when patients had the tests ordered
by their doctor
• Cumbersome process for identifying expired orders and notifying
provider of expirations
The laboratory test–ordering process consisted of e-mail order forms
delivered via Virginia Mason’s intranet, and paper forms completed by
doctors and carried to the laboratory by the patient. The information on
the paper form was manually entered into the electronic laboratory system
by staff when the patient arrived. Paper forms make errors more likely (due
to being incomplete, incorrect, illegible, etc), and reentering data is time
consuming, causing delays, and is a recipe for mistakes. Orders arriving
via e-mail were usually for tests to be done in the future, typically before
the patient’s next appointment.
While e-mail programs help with the message transport, they are not
designed to enable this sort of workflow process. For example, the weak
search function in the e-mail program, combined with the number of
destination mailboxes, made it difficult to find orders for patients coming in for tests, as well as future orders, duplicate orders, and expired

orders. For every patient who presented for tests, laboratory reception
staff throughout VM’s clinic system had to search through thousands of
orders in every downtown and satellite online order group e-mail box.
This search process was extremely cumbersome, time consuming, and
prone to errors. In addition, a staff member sorted through orders every
day to identify the 100–150 orders that had expired. This required searching through 26 separate folders in a group e-mail box and forwarding the
expired orders to the originating department. Figuring out where to send
the orders often depended on tribal knowledge rather than information
contained within the order documents themselves. Once the provider’s
office received notification of expired orders, the physician determined
if the order should be resubmitted, which required rework on the part of
the physician to notify the patient and resubmit the orders.
During the current state assessment, it also became clear that the
paper-based part of the system was extremely wasteful: 500,000 paper
orders were generated annually. Regulations require that seven years of
paper orders (3.5 million paper records) had to be stored off-site at any
given time. These records needed to be boxed, labeled, moved, arranged,
archived, tracked, occasionally searched and copied, and finally moved
again for disposal—causing tremendous labor and environmental waste.
The reduction and eventual elimination of the paper system also became
an important goal for the team.
These software design and paper flow issues were exacerbated by human
ones: typing errors, accidental deletions, and failure to reschedule tests
when an appointment was changed, demonstrating a lack of standard
work in the overall process. Simple mistakes by staff and patients, as well as
poor process design and software weaknesses, caused delays and rework,
ultimately putting patients at risk.
Solution Called for Collaboration
Following the root cause analysis, definition of requirements, and discussion of the lab’s needs, information systems staff recommended that
the pre-CPOE interim solution should be based on a relational database
structure, so that it could effectively search, sort, manage workflow, prevent common data entry errors, assist with queuing and scheduling, and
securely support this high-volume activity across multiple locations. IT

developed such a database to document, communicate, store, and search
orders. They knew, however, that the database alone was not the solution. IT and the laboratory invited the Kaizen Promotion Office (KPO)
to participate in defining an optimal business process for laboratory
test ordering. (KPO is responsible for guiding work using the Virginia
Mason Production System.)
KPO set up a one-day kaizen event in April 2009 to do this work. The
team included staff from the laboratory, IT, general internal medicine, and
other areas. The task was to define the current process and how the future
state should work, resulting in the ideal system functionality. This voice
of the customer exercise illustrated what patients, providers, support staff,
and the laboratory needed the system to do for them. Developers then created a working prototype of the new system, which the users then tested
against these criteria to be certain it could receive all laboratory orders
submitted online, track when tests were drawn, and alert clinical staff
when surveillance was needed.
After a 90-day IT development cycle with frequent laboratory department input, a one-week Rapid Process Improvement Workshop (RPIW)
was held in July to make refinements and corrections and to plan the rollout of this new ordering system. During the week, the team designed the
actual process that physicians and staff would use to place an ambulatory
order using the new online process. They also addressed the patient flow
from the placement of the order through patient arrival at the laboratory
for their blood draw. Patients now simply report to the laboratory, where
their electronic orders are retrieved by the receptionist, tube labels are
printed, and the patient’s blood is drawn. This new process was implemented less than 90 days later with no significant challenges. Further
IT testing and exploration will track whether the system is working as
designed—a crucial element in all VMPS work (Plan-Do-Check-Act,
PDCA).
A member of the IT team estimated that involvement of KPO and
use of VMPS tools may have saved as much as two months of work
by IT analysts, as the new system was designed, built, and tested in
an iterative fashion with frequent customer input. Two positions in the
laboratory were reassigned to more pressing patient care duties because
the time-consuming and non-value-added online order-tracking and
sorting work no longer was needed. In addition, paper generation
and storage costs were reduced due to the paperless nature of the new

electronic ordering system As a result of this implementation, the laboratory gained much needed efficiency in how orders are processed upon
patient arrival. The two freed full-time employees were redeployed to
much needed phlebotomy duties, which decreased the need to hire
additional staff, thus keeping their operating margin intact. The laboratory is also closely monitoring error rates, using the new system, to
assure that the process changes are successful.
It should be noted that post rollout, the original RPIW team met several times and continued to refine the process, making changes that further improved efficiencies both in the physician’s and medical assistant’s
process and in the laboratory processes. This work continues today.
The work described here is a fairly simple example of the power of the
improvement system pioneered by Toyota and now in use at Virginia
Mason. The team consisted of staff who actually use the laboratory order
system, including doctors, VMPS specialists, IT analysts, and others. This
diversity brought together a wide range of experience and ideas and allowed
the team to gain a thorough understanding of the functions needed and to
test ideas in the real world before deciding on a solution.
Lee Darrow
Administrative Director, Ambulatory Services
Virginia Mason Medical Center
John Eusek
Administrative Director, Kaizen Promotion Office
David Krause
Manager, Information Systems

Appendix A: A Brief History
of Continuous Improvement
The birth of modern-day continuous improvement began at the turn
of the twentieth century during the Industrial Revolution.* An industrial engineer, Frederick Taylor, developed techniques to identify the
variables impacting a specific task, thereby defining the most efficient
way to perform that task. During the same period, Frank and Lillian
Gilbreth introduced time and motion studies, significantly reducing
production time. Then in 1908, Henry Ford incorporated process flow,
interchangeable parts, and standard work to support the first conveyordriven assembly line to produce the Model T.†
This innovative period of scientific management led to significant
gains in productivity by applying standardized methods, simplified
work, and division of labor. However, workers often found the simplified, repetitive work dull and meaningless. The scientific approach was
highly efficient but only engaged people’s hands and not their minds,
causing quality problems, poor morale, absenteeism, and management–
labor conflict.
In the 1920s, Dr. Walter Shewhart of Bell Telephone Laboratories
broke new ground by applying statistical analysis to control process
variation, revealing how deviations in a production process caused
irregularity in product quality—a major paradigm shift at the time it
was introduced.
During World War II, the U.S. Department of War instituted Training
within Industry (TWI) to accelerate war production. (For more information
on TWI, see The TWI Workbook: Essential Skills for Supervisors by Patrick
Graupp and Robert Wrona.1) TWI introduced standardized job instruction,
productivity-driven problem solving, supervisor training, worker safety,
* Lean can be traced even further back in history, to the mid-1500s in Venice, where standard
design, standard production processes, and interchangeable parts were used to flow the production of hundreds of warships (galleys). In 1793, Eli Whitney applied interchangeable parts to his
revolutionary invention, the cotton gin, giving birth to the concept of mass production.
† See Today and Tomorrow by Henry Ford, first published in 1926.

307

308 • Appendix A: A Brief History of Continuous Improvement
and ongoing improvement programs that accelerated output and enhanced
quality. These programs were shared with European and Asian countries to
support the reconstruction effort.
Postwar Japan was in short supply of capital, materials, and labor. To
make matters worse, their products were perceived as cheap, low-quality imitations by consumers throughout the world. In 1950, the Japanese
Union of Scientists and Engineers invited several quality experts from the
United States to visit and share their expertise. Among them was Dr. W.
Edwards Deming, who suggested that Japanese industry could turn around
their quality issues and become competitive in five years. The Japanese
embraced Deming’s ideas of quality and process improvement, helping
them to achieve significant gains in only four years, though competitiveness with the Western industrial nations was still many years away.
Although Deming did not introduce the term Total Quality Management
(TQM)* in his classic book Out of the Crisis,2 many of the fundamental
ideas of TQM are contained within it. The essence of Deming’s work is
contained in 14 principles:
1. Create a constancy of purpose.
2. Adopt the new philosophy (a new way of thinking about running
your business).
3. Cease dependence on mass inspection.
4. End lowest tender contracts (do not award business based on price
alone).
5. Improve every process.
6. Institute training on the job.
7. Institute leadership.
8. Drive out fear.
9. Break down barriers.
10. Eliminate exhortations (slogans).
11. Eliminate arbitrary numerical targets (quotas).
12. Support pride of workmanship.
13. Encourage education.
14. Develop top management commitment and action.
* Total Quality Management (TQM) refers to the quality improvement discipline founded on the
ideas of Deming, Juran, and Feigenbaum, stressing that quality must be actively managed by
focusing on customer needs and engaging all employees.

Appendix A: A Brief History of Continuous Improvement • 309
Deming, with influence from his mentor Shewhart, also promoted the
Plan-Do-Check-Act (PDCA)* cycle of problem solving.
In 1951, Armand Feigenbaum pioneered the concept of Total Quality
Control in Quality Control: Principles, Practice, and Administration.3
Feigenbaum stressed quality as defined by the customer, and as a fundamental management philosophy. He also introduced the idea of cost of
quality,† suggesting that the cost of maintaining high quality is offset by
reducing the costs of poor quality.
Joseph Juran made significant contributions to quality management,
also emphasizing the human element of quality (employee resistance to
change), the need for management training, and the application of quality management to functional areas beyond manufacturing. (See Juran’s
Managerial Breakthrough and Juran on Quality by Design.)4 Juran also
presented to the Japanese Union of Scientists and Engineers in 1954 and
was a major influence on management training in Japan throughout the
1950s and 1960s.
The principles and tools articulated by Deming, Juran, and Feigenbaum,
which later came to be known as Total Quality Management, formed the
foundation of Lean and Six Sigma.
By the mid-1950s, many Japanese companies had embraced the
Quality Movement, none more than Toyota. Kiichiro Toyoda, then
president of Toyota Motor Corporation, had been influenced by Henry
Ford’s writings. 5 He planted the seeds of the Toyota Production System
(TPS) in the 1930s by introducing flow-style production, worker training, and a revised factory layout. His cousin, Eiji Toyoda, toured U.S.
factories in 1951, spending three weeks at Ford Motor Company; Eiji
returned to Japan with a vision. Ford’s plants were models of efficiency;
however, they were only capable of producing one product. Every
Model T was virtually identical. Ford eventually lost market share to
General Motors because of its inability to address both volume and
product variety.

* Plan-Do-Check-Act (PDCA) is a structured approach to problem solving which applies the scientific method: observation, development of a tentative description of cause and effect (hypothesis),
prediction, testing, and evaluation. Also known as Plan-Do-Study-Act (PDSA). For a discussion
of PDCA, see Appendix B.
† Cost of quality includes the costs of prevention, appraisal, and internal and external failure.

Toyoda believed that it was possible to achieve both flow and product
variety without sacrificing time, quality, or cost. At Toyota,* these concepts were first applied in 1951 by Taiichi Ohno, a machine shop manager
who would later become a Toyota executive vice president. Over the next
25 years, Ohno worked with Shigeo Shingo, an industrial engineering
consultant, pioneering approaches for waste elimination, flow, visibility,
structured training, just-in-time production, workplace organization, and
standard work. Shingo is credited with documenting Toyota’s improvement procedures, which later became known as the Toyota Production
System (TPS).
The focus on quality improvement continued in Japan throughout the
1960s and into the 1970s, when the OPEC oil embargo suddenly plunged
the Japanese economy into crisis, sending Western consumers scrambling for fuel-efficient vehicles. Among the major companies in Japan,
Toyota was one of the few to make a profit during this time. Beginning
in the 1970s, companies from all over the world started touring Japanese
plants (particularly Toyota) attempting to discover what they were doing
right.
The term Total Quality Management was first used by the U.S. Navy
in 1984 to describe the Japanese-style management approach to quality improvement. TQM focused on holistic quality themes, including
employee involvement, continuous improvement, a focus on customer
requirements, and quality management within daily work. Many of these
concepts were developed in parallel with the principles and tools Toyota
had developed over the past 30 years.
During this period, another field of process improvement emerged, the
Theory of Constraints (TOC). In 1984 Dr. Eli Goldratt introduced the concept of managing the pace of production and supporting process improvements around constraints (bottlenecks) in his landmark novel, The Goal.6
The premise of TOC is that productivity is improved as a result of identifying and managing bottlenecks as pacemakers to regulate production.
By eliminating constraints, the speed at which information and materials
move is increased, improving quality, cycle time, customer satisfaction,
and cash flow.
* Modern-day Toyota Motor Corporation began in 1933 as a department of Toyoda Automatic
Loom Works focused on the production of engines and then automobiles under the direction of
the founder’s son, Kiichiro Toyoda. Toyota Motor Corporation was established as an independent
company in 1937.

Appendix A: A Brief History of Continuous Improvement • 311
Six Sigma emerged in the 1980s; its well-publicized success at large companies such as Motorola, Allied Signal, and General Electric created broad
interest. Many organizations aspired to increase profits by improving
their quality to a Six-Sigma level (3.4 defects per million), investing heavily in training and creating an internal resource pool of specialized green
and black belts. Six Sigma created a rigorous data-driven methodology to
link improvement activities with bottom-line financial results. (See also
Appendix B on Six Sigma and Lean.)
During the 1980s, Japanese automakers’ quality and market share continued to improve. The Sloan* Foundation funded a five-year, US$2 million study by the Massachusetts Institute of Technology, resulting in the
1990 publication of The Machine That Changed the World by Womack,
Jones, and Roos.7 This landmark book explained the principles behind
the Toyota Production System, and coined the term Lean. Then in 1996,
Womack and Jones published Lean Thinking,8 introducing a five-step process for Lean improvement:
1. Specify value from the perspective of the end customer.
2. Identify all the steps in the value stream, eliminating those activities,
processes, and policies that do not create value.
3. Flow products and service smoothly toward the customer.
4. Let the customer demand pull value from the next upstream
activity.
5. Pursue perfection through continuous improvement.
From a broad perspective, continuous improvement began with a scientific focus on efficiency and then shifted to a humanistic focus on creating quality through respect for people. What Deming, Juran, Feigenbaum,
Ohno, Shingo, and others discovered was that significant lasting improvement is achieved by engaging the hearts and minds of everyone in the
organization. As continuous improvement methodologies evolve, they
adopt new names and tools: Total Quality Management, Toyota Production
System, Lean Manufacturing, Lean Office, Theory of Constraints, Six
Sigma, Lean Six Sigma, and so on. Whatever the label, these disciplines
are all natural advancements of process improvement and quality management principles and tools that have evolved over the past 100 years or
* Alfred P. Sloan was the longtime president and chairman of General Motors.

more. While there are differences among them, the key point is that all
these improvement methods are complementary, comprising a rich collection of ideas to be drawn upon where appropriate.

Endnotes

1. Patrick Graupp and Robert Wrona, The TWI workbook: Essential skills for supervisors
(New York: Productivity Press, 2006).
2. W. Edwards Deming, Out of the crisis (Cambridge: Massachusetts Institute of
Technology, Center for Advanced Engineering Study, 1982).
3. Armand Feigenbaum, Quality control: Principles, practice, and administration (New
York: McGraw-Hill, 1951).
4. Joseph Juran, Managerial breakthrough (New York: McGraw-Hill, 1964); and Joseph
Juran, Juran on quality by design (New York: Free Press, 1992).
5. Henry Ford, Today and tomorrow (Garden City, NY: Doubleday, 1926).
6. Eli Goldratt, The goal (Great Barrington, MA: North River Press, 1984).
7. James P. Womack, Daniel T. Jones, and Daniel Roos, The machine that changed the
world (New York: HarperCollins, 1990).
8. James P. Womack and Daniel T. Jones, Lean thinking (New York: Free Press, 1996),
16–26.

Appendix B: How Lean and
Six Sigma Work Together
Six Sigma is a process improvement methodology emphasizing data
analysis with a primary objective of reducing process variation to improve
quality. The Greek letter sigma (σ) represents variability. The sigma level of
a process indicates the probability of defects; the higher the sigma level, the
more stable and reliable the process and the lower the likelihood of defects.
A process functioning at a Six-Sigma level equates to 3.4 defects per 1 million opportunities, which is equivalent to 99.9997 percent defect-free work.
As sigma levels increase, there is less need for inspection, testing, and
rework, which reduces costs while improving cycle times and customer
satisfaction.* Six Sigma and Lean share many similarities: both seek to
establish ongoing continuous improvement, focus on delivering customerdefined value, and pursue the reduction of non-value-added work. They
also apply a disciplined closed-loop† improvement methodology.
The improvement methodology used in Six Sigma is DMAIC (pronounced dee-may-ik), which stands for define, measure, analyze, improve,
and control.
DMAIC is a structured approach which begins with the define step, which
typically includes a comprehensive project charter.‡ During the measurement stage, current-state processes are identified and investigated, baseline
data are gathered, and process mapping is often performed. Metrics used
to determine the effectiveness of current processes are also developed.
In the analyze stage, the process is examined for sources of variation
and wasteful non-value-added activity in order to identify opportunities
* For a comprehensive review of Six Sigma, see Six Sigma Demystified by Paul Keller. For a brief but
thorough overview, see The Lean Six Sigma Pocket Toolbook by George et al.
† A closed-loop feedback system provides information on the effectiveness of a process by supplying
output information on quality, time, cost, variability, or other criteria. The information is used to
make improvements to the system as conditions change.
‡ The project charter includes a problem statement, project objectives and anticipated results, scope,
stakeholders, sponsor, team members, resource requirements, metrics, and project milestone
dates. Project scope defines the project’s boundaries: what will be addressed and what will be
excluded.

313

314 • Appendix B: How Lean and Six Sigma Work Together
for improvement. During the improvement phase, new processes are
developed, implemented, and tested to ensure they function as planned.
Finally, during the control phase, improved processes are documented
and workers are trained in new standard work practices. Lessons learned
are captured, and controls put into place to monitor changes, creating a
feedback loop for ongoing improvement, verifying results, and tracking
financial returns. At the conclusion of the project, a formal report out is
presented to a steering team or senior management, and results are evaluated against the anticipated outcomes defined in the project charter.
In contrast, Lean applies the Plan-Do-Check-Act (PDCA)* cycle
improvement methodology. During the planning stage, a draft A3†
problem summary is prepared and presented to a steering team or project sponsor for approval. Usually, Lean improvements do not require
a formal project charter beyond an A3. During the development of
the A3, the team asks, “What is happening and what should be happening?” Specific, measurable, actionable, realistic, and time-bound
(SMART) targets are developed to measure baseline performance and
later the impact of process improvements. During the do stage, the
team analyzes the current state (often using value stream mapping)
identifies value-added and non-value-added work, isolates root causes
of problems, gathers baseline data, and develops, prioritizes, and tests
potential countermeasures. The most promising countermeasures are
selected for implementation.
During the check step, results are compared with the SMART targets
to determine the effectiveness of the improvements. Finally, during the
act stage, if the results are acceptable, the improved process and supporting metrics are put into practice and become the new standard work.
Employees are then trained in the new procedures. However, if the results
indicate that the countermeasures are inadequate, an adjustment‡ needs
to be made based on the results and the team enters into another round
of problem solving—the hypothesis has been disproven and the PDCA
cycle begins anew. At the conclusion of each PDCA cycle, a report out is
provided to the steering team or project sponsor.
* A variant of this is Plan-Do-Study-Act (PDSA), also known as the Shewhart cycle, Deming cycle,
or Deming wheel.
† See Chapter 2 for a discussion of the A3 thinking process and Appendix D for a sample A3.
‡ Some Lean practitioners like to say the A in PDCA stands for adjust. This implies a more active
role in assessing results of countermeasures and responding appropriately.

Appendix B: How Lean and Six Sigma Work Together • 315

Focus
DMAIC and PDCA are equally effective process improvement methodologies. While DMAIC offers a more formal project deployment model
applying additional rigor in the define stage, PDCA is a very effective
problem-solving method that can be applied with less formality and overhead. Both have their appropriate place in continuous improvement and
should be chosen according to the scope, cost, complexity, and risk of the
undertaking.
A major difference between Lean and Six Sigma is their principal focus:
Six Sigma emphasizes quality through controlling process variation, while
Lean’s primary focus is flow attained from eliminating non-value-added
activities (waste). In most organizations, the vast majority of improvement
opportunities are found in wasteful business processes. It is not surprising
that many companies discover that focusing on waste (not process variation) is the best place to begin their improvement efforts. Lean quickly
prepares organizations to address obvious low-hanging fruit improvement
opportunities that are relatively easy to achieve and deliver a noticeable
impact. Harvesting these opportunities creates early wins, preparing
employees for more challenging projects.
After non-value-added activities are removed from a process, it is easier
to identify high-value problems deserving rigorous attention.

Roles
In Six Sigma, projects are typically led by certified black belts and staffed
with green belts.* Specialists drive improvement activity and are thoroughly
trained in improvement tools and methods. However, the people closest to the
work may lack a sense of ownership and responsibility to solve problems while
waiting for the Six Sigma experts to arrive (generally speaking, Six Sigma
* Black belt and green belt are Six Sigma designations. Black belts have traditionally completed
advanced training (4–6 months) and successfully completed two large-dollar-value projects. They
provide training and mentoring to green belts and other employees. Black belts work full time on
Six Sigma projects. Green belts have received basic training in Six Sigma (often 5 days) and support
black belts by providing project facilitation and guidance. Certification is offered by a number of
professional organizations, universities, and private companies.

316 • Appendix B: How Lean and Six Sigma Work Together
usually engages about 30–40 percent of the workforce). In Lean, all employees
are trained in basic improvement skills and are expected to take an active role
in daily improvement and problem solving. Because Lean is generally more
intuitive and less quantitative, the tools and methods are often perceived as
common sense and less intimidating to employees. In some organizations,
Lean is perceived as being more accessible, engaging the entire workforce.

Project Size and Duration
Lean improvement activity, called kaizen,* ranges in duration from a
few hours to a few months, while the typical Six Sigma project lasts from
three to nine months. Kaizen events are focused short-term improvement
efforts that typically involve a cross-functional team and several weeks
of preparation followed by a week of PDCA activity. Kaizen also occurs
on an as-needed basis as problems and improvement opportunities are
encountered. These daily kaizen are short, focused improvements lasting just a few minutes or a few hours. Some Lean efforts require more
than a week to execute. These kaizen projects can last from several weeks
to several months. Generally speaking, Six Sigma projects take longer to
complete than Lean projects due to the effort invested in formal project
management (e.g., project charters), data sampling, and analysis. Lean is
about hitting frequent base hits, while Six Sigma strives for home runs.†

Project Selection
Because Six Sigma projects make use of trained black belts (a finite
resource), projects are limited. Six Sigma projects are regulated based
on alignment with organizational goals, risk, and return on investment
(ROI). It is not uncommon for Six Sigma projects to target annualized
* Kaizen is ongoing continuous improvement of a value stream (system kaizen) or a single process
(process kaizen). In general, system kaizen is the primary focus of management, while process
kaizen is the responsibility of associates formed into teams.
† For more information on Kaizen, see Kaizen: The Key to Japan’s Competitive Success by Masaaki
Imai.

Appendix B: How Lean and Six Sigma Work Together • 317
returns of $150,000 or greater. With Lean, the emphasis is on continuous
improvement occurring throughout the organization on an ongoing basis;
focus shifts from a few carefully chosen large projects to an unlimited
cycle of incremental improvement activities. Occasionally, Lean improvements include large-scale projects representing radical, even revolutionary
change—called Kaikaku.*

Complementary Coexistence
Can Lean and Six Sigma coexist in one organization? Absolutely! Many
companies today have a Lean Six Sigma program. In the final analysis,
Six Sigma and Lean complement each other by providing the tools and
methods necessary for sustained improvement throughout the enterprise.
Our experience shows that Lean is often the entry point due to its primary focus on waste, low initial startup costs, company-wide participation, and rapid results. Initial Lean efforts often focus on achieving quick
wins. These early successes foster support and enthusiasm for additional
improvement efforts. Once the initial gains have been realized, companies
recognize the need to address more challenging constraints and process
variation. These complex problems often require disciplined analysis and
formal project management. This is where Six Sigma provides the quantitative tools and thorough deployment methodology needed.
On the other hand, several of our clients began their journey with Six
Sigma, finding the structure, discipline, and focus a good fit with their
established culture. After they successfully created a foundation of continuous improvement with Six Sigma, they expanded the effort to all
associates by introducing Lean to the rest of the company. Lean became
the general approach to improvement, while Six Sigma was applied when
specifically suited to the problem at hand. Whether your organization
embarks on its process improvement journey by employing Lean or Six
Sigma, it is important to understand that both these improvement methodologies are complementary and have their appropriate place.
* Kaikaku is breakthrough and radical improvement (initiated by senior management), as contrasted with kaizen, which is gradual, continuous, and often initiated by the people closest to the
work.

Appendix C:
Information Wastes
Following is a list of information wastes we have compiled during our
own practice, along with input from many IT professionals we have worked
with over the years. We hope this list helps you learn to see waste in your
own work environment—the first step toward eliminating it.
This is by no means a complete list, and we’ll continue to update it on
our website: www.steadyimprovement.com. The list is available for download and free distribution.
If you would like to submit your own examples of information waste,
please send them to info@steadyimprovement.com
Inventory
• Backlog accumulating in electronic and physical inboxes
• Old or obsolete electronic and physical files and messages that should
be stored, disposed, or recycled
• Clutter: physical and virtual disorganization wherever work is done
or knowledge is stored and shared
• Endless spreadsheets and other “productivity enhancing” documents
that encourage local optimization while fragmenting the overall process, increasing the number of delays, handoffs, and errors
• Excess information across local drives, shared drives, SharePoint
sites, data warehouses; duplication of the same data in multiple forms
(e.g., electronic and paper)
• Sending attachments rather than links, which creates multiple
versions of a document (also causing version control and security
problems)
• Work waiting to be reviewed, approved, and forwarded
• Software that’s purchased but never deployed
• Unnecessary, unclear, incorrect, obsolete, or unused documentation
• Projects and programs that are not being considered but are still on
the backlog
319

320 • Appendix C: Information Wastes
• Backlog accumulating in the software development, support, or
enhancement queue
• Partially completed development work—uncoded documentation,
unsynchronized code, untested code, undocumented code, undeployed code
• Multiple software code objects that perform the same function
• Introducing excessive tools, technologies, or methodologies
• Unused/unnecessary software user licenses
• Excessive inventory of ink cartridges and other consumables that
require space and may become damaged or obsolete before they are
needed
• Excessive parts inventory
Overprocessing (doing more work than the customer requires)
• Mandated but unnecessary or overly complex processes and
activities
• Inspection and correction activities required to catch and correct
errors that should be prevented by building quality into the process
• Producing and distributing reports that contain information which
is not used
• Sending people unnecessary messages, such as selecting “reply all”
to an e-mail message, when “reply” (or no response) is sufficient
• Unused functionality designed into software
• Failure to cancel a project when it is determined to be no longer
viable
• “Gold plating” system design and performance striving for perfection rather than practical adequacy
• Excessive or unused reason or categorization codes configured into
the software
• Entering redundant information into the same or multiple systems
• Workflow approval routings that are not necessary
• Unclear lines of decision making responsibility/authority that cause
unnecessary changes, time, cost, errors, and rework once a project is
underway
• Management reporting systems (e.g., hierarchal scorecards and dashboards) that do not align strategy with daily activity, and thus do not
effectively prioritize action, leading to effort that does not contribute
to organization goals (doing the wrong work, but doing it well)

Appendix C: Information Wastes • 321
• Frequent switching between incomplete jobs, also known as multitasking, thrashing, task switching
• Ineffective or repetitive meetings that add little value and don’t
resolve lingering issues
• Inviting people to unnecessary meetings, or meetings where they
don’t need to be involved
• Trying to govern or manage systems or processes that are unreliable,
unstable, undocumented, or too complicated to understand
• Searching for information or materials that are difficult to find
• Excessive automated exception notifications and alerts that cause
distraction, but do not drive effective action or decision making
• Multiple reports containing the same or similar data
• Excessive analysis that does not add value to a decision
• Helpdesk troubleshooting that addresses symptoms but not root
causes
• Non-value-adding control activities solely for compliance purposes
• Cost accounting efforts that track and calculate cost per unit/order/
event rather than the value stream cost
• Unnecessary transactions, capturing more information than is
needed to complete the process or to support decision making (e.g.,
capturing standard cost variances and calculating overhead allocations in order to support a process that flows)
• Gridlocked or unclear matrix management practices
• Unnecessary monthly closing activities
• Lack of system and process integration that causes unnecessary
work
• Budgeting tasks that do not lead to better decision making
• Excessive, unnecessarily invasive, or complex security policies and
procedures
• Printed information where electronic is sufficient, for example, presentation slides and handouts
• Writing something, then entering it into a computer system
• Printing information from one computer system then re-entering it
into another
• Capturing data at various points along a process, rather than capturing at the source
• Information addiction, excessive e-mail, web surfing, social networking, and so on . . .

Overproduction (producing more / sooner than the customer requires)
• Unnecessary or early work performed due to unclear priorities,
interdependencies, or sequence
• Software requirements that are specified long before coding
• Producing and distributing a document days before a meeting, that
is then modified based upon later information and redistributed
• Printing collateral materials that are quickly obsolete
• Making extra copies
• Printing single-sided versus double-sided
• Processing paperwork or information before the downstream operator is ready for it
• Making and locking decisions in too early that commit resources
and limit flexibility
Waiting / Delays
• Searching for information (which often consumes a half hour or
more of every individual’s time each day)
• Delays from excessive review and approval steps
• Delays in receiving, transmitting, and storing information
• Slow application response
• Unnecessary distractions and interruptions
• Unclear lines of decision-making responsibility/authority that cause
delays (e.g., project approval)
• Delays between coding and testing
• Waiting for hard copies that could have been handled electronically
• Metrics that are not real-time, having to wait to take action
• Missing, incomplete, incorrect, obsolete, or unclear information
from upstream processes that require time for clarification and
correction
• Overnight batch processing of data
• Reports that take a long time to run
• Waiting for a specialist who is currently working on another task or
project (shared resource)
• Discussions or decisions that take too much time because a team is not
co-located or does not have the capability for online communication/
collaboration
• Long helpdesk hold and callback times

• Using shared equipment; waiting time for availability, plus time
required to reconfigure/reboot/login
• Delays in determining correct groups or individuals needed for process or problem resolution
• Missing, incorrect, unclear, or obsolete process documentation
which causes delays when a procedural problem or question arises
Motion/Transport/Transfer
• Walking to/from printer, copier, fax machine, filing cabinet, archival
storage
• Poor user interface or process design that causes unnecessary keystrokes, mouse clicks, or navigation steps
• Nonstandard handoff of information from one process step to
another when it requires some form of change or re-interpretation
of the information
• Intercompany handoffs of nonstandard, nonintegrated information
(e.g., supply chain transactions)
• Security barriers to flow of nonsensitive information
• Filing or moving physical documents that could be stored and forwarded or linked electronically
• Providing a spreadsheet or report to more people than actually need
it
• Needing to split email attachments into smaller segments due to file
size limitations
• Toggling between disconnected applications
• E-mails sent/responded to uninvolved people
• Unnecessary movement of electronic information
• Sending attachments rather than links to documents
• Printing information from one computer then re-entering it into
another
• On-site visits to resolve system issues that could be resolved (or prevented) with remote monitoring and correction
• Using multiple emails for dialogue when a conference call or face-toface meeting is more effective
• Manual expediting of documents—walking documents through the
approval process
• Poor ergonomic design of work stations

Errors/Defects/Rework
• Incomplete, incorrect, obsolete, or unclear information from
upstream processes that must be corrected
• Inspection and correction processes
• Poor project execution
• Not understanding customer/user requirements and expectations,
thus delivering ineffective “solutions”
• Unstable software, hardware, communications, devices, etc., that
make it difficult for people to get value-added work done
• Lost information
• Mixed messages from management about the importance of
doing work right the first time, while also doing all daily work “on
schedule”
• Excessive productivity standards, measurements, and incentives
that emphasize volume/speed over quality
• Forming a kaizen team to improve an automated business process
without including a representative from IT, often resulting in incorrect system requirements and change requests
• Application bugs and design flaws
• Unauthorized changes to software and systems
• Inadequately tested changes to software and systems
• Testing introduced too late in the lifecycle of a project
• Software patches applied simply to correct errors introduced by the
previous patches
• Assuming customer needs / requirements instead of getting it directly
from the customer (not asking for information, or asking for the
wrong information)
• Measures that lack valid prescriptive guidance
• Time and effort required to identify and correct bad data as it propagates across multiple data sources
• Entering conflicting information into the same or multiple systems
• Reconciling conflicting sources of data and subsequent disagreements over whose data is right
• Consequences of estimating, pricing, forecasting, or scheduling
errors (to name just a few) based on incomplete, incorrect, irrelevant,
or obsolete data or assumptions

• Helpdesk knowledgebase information that is incorrect, incomplete,
unclear, or obsolete resulting in a failed intervention, potentially
causing additional harm and lost user productivity
• Helpdesk interventions that do not solve the problem due to misunderstanding, unclear communication or problem definition thus
requiring further troubleshooting and correction
• Missing, inaccurate, incomplete, unclear, or obsolete specifications
or process documentation
• Errors resulting from insufficient or improper analysis and
reflection
• Meeting conflicts and subsequent rescheduling caused by misuse of
the scheduling system
• Inability to receive email attachments that exceed file size limits,
causing rework
• E-mail, spam, and the problems that result from excessive filtering
• Free text fields instead of drop-downs, check boxes, etc. that allow
user error and the propagation of bad data throughout downstream
systems
• Requiring workers to memorize or write down data from one source
to be entered into another source
Unnecessary Complexity / Overengineering
• Over design of software applications
• Over automation of processes
• Premature technology intervention to improve a process, before the
process is well understood, simplified, and improved by the people
responsible for it
• Developing complex solutions to simple or nonrecurring problems
• Spreadsheets with unnecessarily complex formulas, macros, and
multiple dimensions that give the appearance of sophistication while
masking potential errors and invalid assumptions
• Overly complex governance, funding, prioritization, and control
processes
• Lack of systems thinking: focus on departmental optimization rather
than overall process performance
• Inappropriate or overly complex IT chargebacks that cause ineffective behavior and misguided IT investment decisions

• Rigid and lengthy system change/upgrade cycles that encourage user
workarounds and offline systems
• Attraction to newest, latest technologies rather than existing systems
that serve their purpose
• Not distinguishing between symptoms and root causes
• Proliferating improvement initiatives that are not strategically
aligned, prioritized, or adequately resourced
Underutilized Human Potential
• Information overload
• Unnecessary process, data, or system complexity
• Dull, repetitive, or mundane activities that could be eliminated or
automated
• Unnecessary or complicated top-down rules and process controls
• Lost, conflicting, or underutilized knowledge that must be rediscovered and relearned once a problem occurs
• Excessive approvals needed or other bureaucracy that discourages
improvement and innovation
• Lack of guidelines or work standards to empower employees
• Too much time spent on daily work, with not enough time allowed
for individuals to improve the work
• Not communicating targeted objectives to all associates involved
in a process
• Excessively detailed standards that do not allow flexibility
• Lack of visuals and measures to indicate where problems need to be
solved
• Not asking for ideas
• Not capturing and sharing ideas
• Not making knowledge easy to locate and apply
• Not investing in education and training
• Not encouraging cross-functional communication and collaboration
Environmental Waste
• Electricity consumed by IT assets
• Paper consumed by unnecessary printing
• Printing single-sided versus double-sided
• Ink, toner cartridges, and other recyclables that are disposed prematurely . . . or not recycled!

• Improper disposal of materials, including hazardous materials found
in many electronics
• Using paper coffee cups instead of ceramic mugs
• Document storage, archive, and disposal waste
• Overnight shipping expenses and carbon footprint that could be
reduced through electronic transport
• Transportation (fuel, carbon, and other costs) that could be reduced
through telecommuting and remote meetings
• Business processes causing environmental waste, that could be
improved with thoughtful application of information and information systems

Appendix D: IT Service
Desk A3 Example

329

330 • Appendix D: IT Service Desk A3 Example

Appendix D: IT Service Desk A3 Example • 331

Index
A
Acceptable practices, 52
Accountability, 122, 219
Accounting, Lean, 140–142, 167, see also
Costs
Acquisition, rapid, 135–136
Actionable information, 72, 219
Activity vs. productivity, 123, 215
Adaptability, roadmap, 264–265
Agile Manifesto, 169–170, 175
Agility
defined, 11, 170
executive review, 118
flow and balance, 103
flow and pull, 102–104
information, 79–80
level scheduling, 109
vs. Lean, software development, 170
Alignment, see also Integration and
alignment
business, 8–10
haphazard, 111
horizontal, 137
misalignment, 6–8
vertical, 137
vs. integration, 94
Analyze (DMAIC), 286, see also DMAIC
approach
Anchor-draggers, 261
Andons, 134
“A New Model for IT Demand
Management,” 111
Anthill, wisdom, 230
Approaches
roadmap, 253–254
software development life cycle,
177–178
Assemble to order (ATO), 102
A3 thinking
form vs. thinking, 210
fundamentals, 36–37, 63
ITIL and cloud computing, 160

process maturity models, 52
project management, 208–212
root cause level, 188
service desk example, 330–331
services management, 160
supporting processes, 91
ATO, see Assemble to order
Authority, see also Decision rights
SMART targets, 219
vs. responsibility, 202
Automation
alignment and value, 8
excessive, IT view, 5
Availability, 163

B
Backlog grooming, 183
Balanced scorecards, see also Scorecards
effective measures, 87
strategic intent, 231
Toyota Australia case study, 292–293
Balancing
IT demand management, 116–117
Barry-Wehmiller case study, 269–271
Batch-and-queue waste, 173
Bechtel, 91
Beginner’s mind, 35
Begin with end in mind, 26
Benchmarking
compliance, 87–88
effective measurement use, 85–88
fundamentals, 83–85
Best practices
enterprise software applications, 77
process models, 52
Boeing, 105
Bottom-up processes, 52
BPR, see Business process reengineering
(BPR)
Brainstorming, 218

333

334 • Index
Break-fix responses, 156
Budget constraints, 6, see also Accounting,
Lean; Costs
Burndown charts, 188, 283
Burning platform, 47, 48–52, 254
Business
alignment, 8–10
IT perceptions/concerns, 3–4
Business Agility, 80
Business intelligence, performance
measurement, 133–135
Business partnership
cause-and-effect diagram, 60
challenges, 48–52
comparisons, 57
data quality, 55
doing Lean IT, 65
environmental waste, 61–63
excess information, 53
health care information quality, 56
information waste, 52–55
Ishikawa diagram, 60
lack of Lean focus, 46–47
Lean vs. traditional IT, 49
legacy systems, 50–51
overprocessing, 54
performing Lean IT, 65
process maturity models, 51–52
recognition of, 55, 58–59
tools of Lean IT, 63–64
Business process improvement, 69–70
Business process improvement (BPM)
agility, 79–80
benchmarking, 83–85
compliance, 87–88
coordinating function, 70–74
effective measurement use, 85–88
efficency-flexibility trade-off, 79–80
enterprise software applications, 77–79
information value and waste,
intangible nature, 74–82
process vs. practice, 80–83
systems perspective, 75–76
Business process management, 237–238
Business process reengineering (BPR), 15
Buy-in assessment, 260–262

C
Capability Maturity Model (CMM), 83,
171, see also Process maturity
models
Capacity planning
demand management, 112
human potential, 91
Capital, creativity before, 70, 203
Case studies
Barry-Wehmiller, 269–271
Con-Way, 271–279
Group Health, 279–284
Ingersoll Rand security technologies,
284–288
Steelcase, 288–291
Toyota Australia, 291–300
Virginia Mason Medical Center,
301–305
Catalog, common language, 157
Catchball, 137
Cause-and-effect diagram
information waste, 60
project management, 216, 217–218
Cellular organization, 64, 155
Center of Excellence (CoE)
collaborative workspaces, 127, 129
infrastructure investment, 260
Project Management Office, 198–199,
205
team building, 258
Challenges
business partnership, 48–52
constancy of purpose, 18–19
culture, 31
flow, pull, and just in time, 29
proactive behavior, 24
pursuit of perfection, 23
quality at the source, 27
respect for people, 21
systems thinking, 28
traditional software development,
171–174
voice of the customer, 26
Changes
adapting to, 264–265
agent for, 71

Index • 335
be what you wish to see, 19
change-release, percentages, 164
control, 139
leadership, 10
percentage of successful, 163
social norms, 22
CHAOS Report, 48
Chasing the Rabbit, 132
CIO Magazine, 111, 165, 190
Clear communication, 74
Closeout phase, 221–222
Cloud computing, 10, see also ITIL and
cloud computing
Collaboration solution, 303–305
Collaborative workspaces, 124–125, 127,
129
Command and control, 14
Communication
breakdown, shared resources, 152
management systems, 123–124
most common failure, 258
organization and approach, 179
roadmap, 256–258
three C’s, 74
Comparisons
A3 form vs. thinking, 210
authority vs. responsibility, 202
IT waste, 57
Lean accounting vs. traditional, 142
Lean vs. traditional IT, 49
manufacturing waste, 57
office waste, 57
program management vs. Lean
initiative, 166, 199
value vs. features, 213
Complementary coexistence, 317
Complete communication, 74
Complexity
business view, 4
information wastes, 325–326
necessary vs. unnecessary, 7
Compliance, benchmarking, 87–88, see
also Regulatory requirements
Consensus, 254–256
Constancy of purpose, 17–20, 230
Continuous improvement, see also Kaizen

engagement, 14–15
historical developments, 13–16,
307–312
integration, 15
scientific management, 13–14
service, 158
timeline, 16
Continuous integration, 176–177
Control, see Monitor and Control phase
Control (DMAIC), 287, see also DMAIC
approach
Con-Way
document management virtual 5S,
271–273
focused value streams, 274–279
kaizen event, 59
Coordinating function, 70–74
Correct communication, 74
Corrections, 35, 86
Cost of change curve, 172, 175
Costs, 4, 151, see also Accounting, Lean;
Budget constraints
Counterproduction
information systems, 98
traditional cost-accounting, 141
Cowboy culture, 166
Creating a Lean Culture, 122
Creativity before capital, 70, 203
Critical differentiators aproach, 78
Critical-to-quality requirements, 26
Culture
cowboy/hero, 166
people leading change, 249
Current state
focused value streams, case study,
274–279
Group Health case study, 279
Customers, see also Voice of the customer
requirements, 179–180
186–187
Cycles, IT demand management, 112–118,
see also Life cycle

336 • Index
D
Daily accountability, 122
Daily kaizen, 41
Danaher Corporation, 136
Dashboards
organization and approach, 179
performance measures, 133–135, 139
Data quality
business view, 4
IT view, 5
Data types, 139
Deceptive activities, 24
Decision rights, 239, see also Authority
Decision support, 4
Defects, 324–325
Define (DMAIC), 287, see also DMAIC
approach
Delays, 322–323
Deliverables, 203
Demand
exceeds capacity, 111–112
planning, 112, 114–115
Demand management
feedback loop, 113
fundamentals, 64
181–183
Dependence, excessive, 152
Design, service, 158
Design choices, 179
Digital nervous system, 122
Discipline, 122
DMAIC approach
case study, 285–287
Document management
obsolete, 130
Does IT Matter? Information Technology
and the Corrosion of Competitive
Advantage, 165
Done state, 182–183
Drivers, 256
Drumbeat, 181

Duration of project, 316

E
Economies of flow, 154
Education, 130–131
Efficency-flexibility trade-off, 79–80
Electronic document waste, 125
Electronic kanban, 105
Electronic Medical Records (EMR), 56
EMR, see Electronic Medical Records
(EMR)
End, beginning at, 26
End-of-pipe outcomes, 86
Engagement
continuous improvement, 14–15
IT view, 5
Engineer to order (ETO), 102
Enterprise software applications, 77–79,
see also Software development
Enterprise value streams, 73
Enterprise-wide infrastructure, 260
Environmental issues
information wastes, 61–63, 326–327
triple bottom line, 62
Errors, 324–325
ETO, see Engineer to order
Events, kaizen
Con-way Enterprise Services, 59
fundamentals, 41
Excellence as habit, 33
Excess information, 53
Execution, 183–184, 186
Execution disconnect, 201
Execution phase
project management, 219
roadmap, 260–264
Executive review, 117–118
Executives, Lean management levels, 242
Experiential information, 122
External benchmarking, 85
External customers, 179
Extreme programming, 170

F
Failures, respect for people, 21–22
Features vs. value, 213

Index • 337
Feedback, 138
Firefighting
IT view, 5
proactive behavior, 24–25
pursuit of perfection, 22–23
Fishbone diagram, see Cause-and-effect
diagram
5S method
document management, case study,
271–273
fundamentals, 43
knowledge management, 127, 130
Five Whys method, 216, 217
Fix-it-later approach
information value and waste, 74
Flavor of the month, 23, 255
Flexibility, see Efficency-flexibility tradeoff
Flow
economies of, 154
interruptions, 152
IT demand management, 115
kaizen, 40
Flow and pull
agility, 102–104
balance, 102–104
balancing, 116–117
capacity planning, 115–116
cycle, 112–118
demand exceeds capacity, 111–112
demand planning, 112, 114–115
executive review, 117–118
flow impact, 115
kanban, 104–107
Lean principles, 29–30
lessons learned, 97–118
level schedule, creating, 107–109
material requirements planning,
100–101
Flowchart, Lean IT, viii
Focus, 315
Focused factory, 275
Focused value streams, case study
current state, 274–275
fundamentals, 274

proposal to management, 276–280
Foreign languages, 4
Forward movement, 10–11
Fragmentation, 4, 56
Free-form knowledge sharing, 81
Functional silo, 152–155
Future state, 280–281
Future steps, 282–284

G
Gains consolidation, 262–264
Gemba
fundamentals, 63
Lean stress, 214
operational dashboards, 133–134
standardized work, 42
Genbutsu, 63
Genchi, 63
Geography, 139
Goals of improvement, 143
Good to Great, 232–233, 257
Google, 177
Governance, 238–240
GreatServices, Inc, 194–195, 207, 212
Green Intentions, 62
Green issues, see Environmental issues
Group Health
current state, 280
future state, 280–281
future steps, 282–284
progress to date, 281–282

H
Hands, hiring for, 14
Hansei, 22, 222, 232
Harvard Business Review, 54, 92, 216, 231,
234
Health care information quality, 56
Heijunka, see Level schedule, creating
Heijunka box, 107–109, 184, 186
Help/service desk, 129–130
Hero culture, 166
Historical developments, 13–15, 307–312
Horizontal alignment, 9, 137

338 • Index
Hoshin system case study, see also
Strategic deployment
hoshin kanri evolution, 293–294
IT as customer, 298
purpose, 300
“How to Instill Agile Development
Practices among Your IT Team:,
190
Human potential, see also People
freeing up capacity, 91
wastes, 123, 326
Humility, 22

I
IBM Global Services, 175
Importance, 18, 144
Important and Urgent, 24
Important but Not Urgent, 24
Improve (DMAIC), 286–287, see also
DMAIC approach
Information
actionable, 72
agility, 79–80
efficency-flexibility trade-off, 79–80
enterprise software applications, 77–79
obsolete, 130
overload, business view, 4
quality, 3, 56
shared, system services, 123
systems perspective, 75–76
value, incorporation, 46
Information boxes, 59, 61
Information systems, 3, 139–140
Information Technology Advisory
Committee, 171
Information wastes
cause-and-effect diagram, 60
comparisons, 57
data quality, 55
defects, 324–325
delays, 322–323
environmental wastes, 326–327
errors, 324–325
excess information, 53
health care information quality, 56

human potential, underutilized, 326
inventory, 319–320
Ishikawa diagram, 60
motion, 323
overengineering, 325–326
overprocessing, 54, 320–321
overproduction, 322
recognition of, 55, 58–59
rework, 324–325
transport/transfer, 323
underutilized human potential, 326
unnecessary complexity, 325–326
waiting, 322–323
website, 319
Infrastructure, enterprise-wide, 260
Ingersoll Rand security technologies, case
study
DMAIC approach, 285–287
fundamentals, 55, 284
problem description, 284–285
Initiate phase, 213–215
In Search of Excellence, 253
Integration
continuous, 176–177
continuous improvement, 15
rapid, performance measurement,
135–136
services management, 157–160
transformation leadership, 244–247
vs. alignment, 94
Integration and alignment
business process improvement, 69–95
flow and pull lessons learned, 97–118
Interaction, 138
Internal benchmarking, 84
Internal customers, 179
Interruptions, 54
Intranet site, 128–129
Inventory
information waste, 319–320
waste, 35, 53
Inward-facing Lean IT, xx
Ishikawa diagram, see Cause-and-effect
diagram
Issue clarity

Index • 339
constancy of purpose, 18
culture, 30–31
IT demand management
cycle, 112–118
demand exceeds capacity, 111–112
demand planning, 112, 114–115
executive review, 117–118
flow impact, 115
ITIL and cloud computing, see also Cloud
computing
A3 problem solving, 160
cloud computing, 164–165
functional silo, 152–155
integrated processes, 157–160
license management, 161–162
quality, 150–151
quality at the source, 159–160, 162
security management, 161–162
services adoption, 165–168
standard work, 162–163
value-adding service center, 152–155
ITIL Version 3 service life cycle model,
158, 160
IT’s contribution, 93–95
IT service desk A3 example, 330–331
IT solution evolution, 294–295
IT waste comparison, 57

J
Just in time, 29–30, 101

K
Kaikaku, 42, 263

Kaizen, see also Continuous improvement
events, 41, 59
planning and measurements, 262–263
projects, roadmap, 260
value, 9
Kanban
execution and test iterations, 183–186
fundamentals, 103
Kano method, 180
Key performance indicators (KPI), 135
Knowledge management, 124–127
KPI, see Key performance indicators

L
Laboratory order process, 301–303
Language, common, 156–157
Languages, foreign, 4
Launching transformation, 227–228
Leadership
change leadership, 10
leading transformation, 227–247
Lean IT roadmap, 249–265
state of mind, 232–234
Leader standard work, 122, 242
Leading Change, 249
Lean enterprise, 222–223
Lean IT
alignment, 8–10
business concerns/perceptions, 3–4
defined, xix–xxi, 9–10
forward movement, 10–11
importance of, 3
lack of focus on, 46–47
misalignment, 6–8
perceptions/concerns, 5–6
performing, 65
tools, 63–64
value creation, 8–10
vs. traditional IT, 49
Lean principles
culture, 30–33
flow, pull, and just in time, 29–30
proactive behavior, 24–26

340 • Index
pyramid, 17, 18, 31
respect for people, 21–22
systems thinking, 27–28
thinking, 253
Lean thinking, 203–205, 207–213
Lean Thinking, 9, 15
Lean tools
A3 form, 36–37
daily kaizen, 41
events, kaizen, 41
5 S method, 43
fundamentals, 36
kaikaku, 42
kaizen, 40–41
Plan-Do-Check-Act, 36–37
process kaizen, 40
projects, kaizen, 41
scientific method, 36–37
standardized work, 42–43
system kaizen, 40
value stream mapping, 37–40
visual workplace, 43
Lean vs. traditional, 142
Learning organization, 23
Legacy systems, 50–51
Lessons learned
project closure, 221–222
software development, 189–191
Level Five leadership, 233
Levels, management systems, 240–244
Level schedule, creating
execution and test iterations, 184, 186
License management, 161–162
Life cycle, see also Cycles, IT demand
management
approach, 177–178
customer service and support, 186–187
demand management, 181–183
execution, 183–184, 186
ITIL Version 3 service, 158, 160
measurements, 187–188
organization, 177–178

test iterations, 183–184, 186

M
Make to order (MTO), 102
Make to stock (MTS), 102
Management by fact, 85
Management systems
accounting, 140–142
acquisition, rapid, 135–136
business intelligence, 133–135
business process management, 237–238
collaborative workspaces, 124–125,
127, 129
command and control, 14
communication, 123–124
education, 130–131
fundamentals, 121–123, 234–235
governance, 238–240
importance of, 144
information systems role, 139–140
integration, rapid, 135–136
Intranet site, 128–129
IT service/help desk, 129–130
knowledge management, 124–127
levels of, 240–244
performance measurement, 131–136
project, program, and portfolio
management, 238
strategy deployment, 235
strategy employment, 136–140
training, 130–131
value, 9
value creation as focus, 143–144
Managers, Lean management levels, 242,
244
“Manage Your Energy, Not Your Time,”
54
Manufacturing waste comparison, 57
Mass customization
flow, balance, and agility, 103
process vs. practice, 81
“Mastering the Management System,” 234
Material requirements planning (MRP),
100–101

Index • 341
Matrix management, 75
Mean time between failure (MTBF), 163
Mean time to repair (MTTR), 163
Measure (DMAIC), 286, see also DMAIC
approach
Measurements
balanced scorecards, 87, 292–293
benchmarking, 85–88
blame and shortsightedness, 76
dashboards, 133–135, 139
deadly sins, 85
fundamentals, 64
ITIL and cloud computing, 163–164
performance, 131–136
results, 86, 260–262
scorecards, 134–135, 139
187–188
Measuring ITIL, 150–151
Micro-PDCA, 219–221, see also Plan-DoCheck-Act (PDCA)
Mindfulness, 22, 222, 232
Misalignment, 6–8
Misdirection, 4
Mixed model production, 103
Momentum, building, 262–264
Monitor and Control phase, 220–221
Motion, 35, 323
MRP, see Material requirements planning
MTBF, see Mean time between failure
MTO, see Make to order
MTS, see Make to stock (MTS)
MTTR, see Mean time to repair (MTTR)
Muda (waste), 34, 35
Mura (uneveness), 34, 112, 236
Muri (overburden), 34, 112, 236

N
Necessary but non-value-added (NNVA)
work
compliance, 87
de-emphasis, 92
fundamentals, 34
Nike, 92, 98–99
NNVA, see Necessary but non-valueadded (NNVA) work

Non-value-added (NVA) work, 34
Not Important and Urgent, 24
NVA, see Non-value-added (NVA) work

O
Obeya room, 127, 208
Office waste comparison, 57
Operating systems, 77, see also Enterprise
software applications
Operation, service, 158
Operational dashboards, 133–134, 139
Organization, 177–178
Outsourcing, 6
Outward-facing Lean IT, xx
Overburden (muri), 34, 112, 237
Overengineering, 325–326
Overprocessing
unnecessary complexity, 7
wastes, 35, 54, 123, 320–321
Overproduction, 35, 322
Overspecialization, 152

P
Pace, 181
Paving cow paths, 70
PDCA, see Plan-Do-Check-Act (PDCA)
People, see also Human potential
accomplishing Lean IT, 65
Lean management levels, 244
overloading, 110
respect for, 21–22, 239
roadmap, 249–250
triple bottom line, 62
Percentages, 163–164
Perfect storm, unnecessary complexity, 7
Performance, IT operational excellence
Performance Dashboards: Measuring,
Monitoring and Managing Your
Business, 133
Performance measurements, see also
Measurements
acquisition, rapid, 135–136

342 • Index
business intelligence, 133–135
integration, rapid, 135–136
Plan-Do-Check-Act (PDCA)
demand planning, 114
feedback cycles, rapid, 231
iterations, 176
IT services management, 156
measures, 86
micro-PDCA, 219–221
obeya room, 208–210
planning emphasis, 183
Project Management Office, 200
short cycles, 231, 235
Planning phase
project management, 215–216, 218–219
roadmap, 256–260
PMBOK, see Project Management Body of
Knowledge (PMBOK)
PMO, see Project Management Office
(PMO)
Portfolio management
management systems, 238
organizing resources around, 153
Toyota Australia case study, 298–300
Postmortem meetings, 195, 241
Practical Lean Accounting, 141
Practice vs. process, 80–83
PricewaterhouseCoopers, 151
Principle-Centered Leadership, 16
Prioritization
conflicting, IT view, 5
contradictory, 110
management-employees dialogue, 20
Proactive behavior, 24–26
Problem description, 284–285
Process assets, 82
Processes
bottom-up approach, 52
improvement, prioritization, 90–93
innovating, 92–93

integrated, services management,
157–160
map, 38
owners and outcomes, 75, 264
supporting, 52, 90–92
top-down approach, 52
vs. practice, 80–83
Process improvement, prioritization,
90–93
fundamentals, 90
innovating processes, 92–93
supporting processes, 90–92
Process kaizen, 40
Process life cycle, 102
Process maturity models, 51–52
Process optimizers, 244
Productivity vs. activity, 123, 215
Product life cycle, 102
Product Lifecycle Management, 81
Profits, 62
Program management
vs. Lean inititative, 199
Programming, extreme, 170
Progress to date, 281–282
Project management
A3 problem solving, 208–212
cause-and-effect diagram, 217–218
Closeout phase, 221–222
DMAIC, 213–222
Execution phase, 219
Five Whys method, 217
fundamentals, 193, 200, 202–203
Initiate phase, 213–215
Lean enterprise, 222–223
Lean thinking, 203–205, 207–213
Monitor and Control phase, 220–221
PDCA, 213–222
Planning phase, 215–216, 218–219
portfolio management, 197–198
program management, 198–200
program vs. Lean, 199
program vs. Lean initiative, 166, 199
Project Management Body of
Knowledge, 197
Project Management Office, 198–200

Index • 343
strategy-execution disconnect, 201
triple constraints model, 206
value, 193–205
value stream mapping, 212–213
Project Management Body of Knowledge
(PMBOK), 197
Project Management Office (PMO),
198–200
Project prioritization, 298–300
Projects
failure, 4
kaizen, 41
Six Sigma, 316
Proposal to management, 275–279
Pursuit of perfection, 22–23
Pyramid, Lean principles, 17, 18

Q
Quality, 150–151, 240
Quality at the source
data quality, 55
Lean principles, 27
services management, 159–160, 162
software development, 172
Quality function deployment, 180
Quality is Free, 150
Quality Movement, 14
Queing theory, 181–182

R
Ratios, 163
Reactive firefighting, see Firefighting
Ready state, 182–183
Real Numbers, 141
Recognition, information waste, 55, 58–59
Reengineering the Corporation, 15
Regulatory requirements, 6, see also
Compliance
Requirements
churn, 174
178–181
Resource thrashing, 5
Respect for people, 21–22, 239
Responsibility, 202, 219

Return on investment (ROI), 4, 177
Revenue enablers, 244
Rework, 35, 324–325
Roadmap
approach, 253–254
buy-in assessment, 260–262
changes and adaptability, 264–265
communication, 256–258
consensus, 254–256
defining the plan, 256–258
drivers, 256
enterprise-wide infrastructure, 260
Execution phase, 260–264
gains consolidation, 262–264
individuals, 249–250
infrastructure, enterprise-wide, 260
kaizen projects, 260
measuring results, 260–262
momentum, building, 262–264
planning phase, 256–260
stages, 251
starting phase, 252–253, 261
stop-doing list, 257
strategic intent articulation, 256
strategy, 254–256
team building, 258–259
toolkit creation, 259
understanding assessment, 260–262
value streams assessment, 259–260
vision, 254–256
ROI, see Return on investment (ROI)
Roles, Six Sigma, 315–316
Root cause focus, 70, 188, 207

S
Sales and Operations Planning (S&OP),
112, 236
Sandbagging, 111, 174
Scalability, 139
Scientific management, 13–14
Scientific method, 36–37
Scorecards, 134–135, 139, see also
Balanced scorecard
Scrum, 170
Security management, 139, 161–162
Seeing the whole, 27, 170
Selection of project, 316–317

344 • Index
Self-reflection, 22, 222, 232
Sequence of work, 107, 116–117
Server to system administrator ratio, 163
Service design, 158
Service desk A3 example, 330–331
Service/help desk, 129–130
Service operation, 158
Service-oriented architecture (SOA), 164
Services adoption, 165–168
Services catalog, 157
Services management
A3 problem solving, 160
integrated processes, 157–160
license management, 161–162
quality at the source, 159–160, 162
security management, 161–162
standard work, 162–163
Service strategy, 158
Service transition, 158
Set in order, 273–274, see also 5 S method
Setup time reduction, 176–177
Shared beliefs, 32
Shared capability, 30
Shared information system services, 123
Shared resources/services scheduling
concentration of, 152
hazards, 155
IT view, 6
Sharing, knowledge behavior, 132
Shine, 274, see also 5 S method
Shingo Prize for Operational Excellence,
16, 71, 228
Signaling, knowledge behavior, 132
Silent assistance calls, see Kanban
Simplification, 8
Six Sigma, see also Continuous
improvement
background, 313–314
complementary coexistence, 317
duration of project, 316
focus, 315
historical developments, 14
roles, 315–316
selection of project, 316–317

size of project, 316
Six Steps to Process-Based IT
Organizational Design, 154
Skipping steps, 250
Slack factor, 182
SMART targets, 219
SOA, see Service-oriented architecture
(SOA)
Soft savings, 143
Software development
agile vs. Lean, 170
approach, 177–178
challenges, tradtional methods,
171–174
customer service and support, 186–187
execution, 183–184, 186
fundamentals, 169–171, 174–177
life cycle, 177–188
measurements, 187–188
organization, 177–178
test iterations, 183–184, 186
Solving, knowledge behavior, 132
S&OP, see Sales and Operations Planning
Sort, 273, see also 5 S method
Speed, 4, 250
Sprint planning, 183
Stages, roadmap, 251
Standard, 42
Standardization, see also 5 S method
fundamentals, 42–43, 63–64, 273
vs. innovating processes, 93
Starting phase, 252–253, 261
Status inquiries, 54
Steelcase case study, 288–291
Stop-doing list, 257
Strategic deployment, see also Hoshin
system case study
fundamentals, 64
leaders/employees participation, 19
strategic intent, 231
Strategic intent, 229–231, 256
“Strategic Intent,” 92, 231

Index • 345
Strategic scorecards, 135, see also
Balanced scorecards
Strategy, roadmap, 254–256
Strategy deployment, 136–140, 235
Strategy-execution disconnect, 201
Strategy management and processes, 292,
296–298
Structured information, 125
Successful changes, percentage, 163
Summary
culture, 33
quality at the source, 24, 27
Supporting processes, 52
Sustain, 274, see also 5 S method
Swarming, knowledge behavior, 132
System kaizen, 40, see also Kaizen
System requirements, 5
Systems anarchy, 4
Systems perspective, 75–76
Systems thinking, 27–28

T
Tactical dashboards and scorecards,
134–135, 139
Takt time, 181
Teams and teamwork
building roadmap, 258–259
capacity planning, 116
fundamentals, 63
Lean management levels, 244
Technical debt, 50, 174
Technical issues, overemphasis, 152
Technology
innovating processes, 92
vs. business solutions, 98
Tesco, 99
Test iterations, 183–184, 186
The Fifth Discipline, 23, 124

The Goal, 15
The 7 Habits of Highly Effective People, 24
The Machine That Changed the World, 15,
233
Theme
constancy of purpose, 17
culture, 30
systems thinking, 27–28
Theory of Constraints, 15, see also
Continuous improvement
The Pittsburgh Way to Efficient Healthcare,
106
“The Tech Jobs That the Cloud Will
Eliminate,” 165
The Toyota Way, 29, 70
“The Truth about IT Costs,” 216
Three C’s, 74
Three M’s, 34–36
Time Management Matrix, 24
Toolkit creation, 259
Tools
Lean IT, 63–64
process information management, 89
Top-down processes, 52
Total Quality Management (TQM),
172, see also Continuous
improvement
Toyota, 98, see also Continuous
improvement
Toyota Australia case study
balanced scorecard history, 292–293
fundamentals, 291
hoshin kanri evolution, 293–294
IT as customer of Hoshin system, 298
IT solution evolution, 294–295
Online Hoshin System, 300
portfolio management, 298–300
project prioritization, 298–300
strategy management and processes,
292, 296–298
Toyota Production System, see

346 • Index
TQM (Total Quality Management), see
Traditional methods
vs. Lean IT, 49
Training, management systems, 130–131
Transfer, 323
Transformation
advancement of Lean IT practices, 8
stages, 32
Transformational Lean leadership
business process management, 237–238
fundamentals, 227
governance, 238–240
integration, 244–247
launching, 227–228
leadership state of mind, 232–234
levels of, 240–244
project, program, and portfolio
management, 238
strategic intent, 229–231
Transition, service, 158
Transportation, 35, 323
Tribal knowledge
best practices, 82
wasteful processes, 75
Triple bottom line, 62–63
Triple constraints model, 206
T-shirt size estimates, 181

U
Understanding assessment, 260–262
Underutilized human potential, 326
Uneveness (mura), 34, 112, 236
United Parcel Service (UPS), 62
Unnecessary complexity, 7, 325–326, see
also Complexity
Unstructured information, 125
Utility providers, 244

V
VA, see Value-added (VA) work

Value
creation, 8–10
creation as focus, 143–144
fundamentals, 33
intangible nature, information, 74–82
vs. features, 213
Value-added (VA) work, 34
Value-adding service center, 152–155
Value Stream Management: Strategy and
Excellence in the Supply Chain,
137
Value streams
assessment roadmap, 259–260
balancing, 116
costing, 141–142
enterprise-wide, 73
fundamentals, 33
Value streams mapping (VSM)
discoveries, 75
fundamentals, 37–40, 63
work and supporting informatin flow,
59, 61
Velocity, 181
Vertical alignment, 8, 9, 137
Virginia Mason Medical Center case
study
background, 91, 301
collaboration solution, 303–305
laboratory order process, 301–303
Virtual information, waste, 53
Virtual Information Executives, 157–158
Virtual line of sight, 133
Vision, roadmap, 254–256
Visual controls, 122, 178
Visual workplace, 43, 64
Visual Workplace, Visual Thinking, 132
Voice of the customer (VOC)
exercise, 58
ITIL and cloud computing, 160
Lean principles, 26
list, 47
services management, 160
VSM, see Value streams mapping (VSM)

Index • 347
W
Waiting, 35, 123, 322–323
War room, see Obeya room
Waste, see also Information wastes
batch-and-queue, 173
Waterfall approach, 173
Websites, 319
What matters most, 18
Whole, seeing the, 27, 170

Who Says Elephants Can’t Dance?, 31
Winning the Knowledge Transfer Race, 82
Wisdom of the anthill, 230
Work in process, 29
Workplace organization, 64, see also 5S
method

Z
Zero-defects mentality, 175

About the Authors
Steve Bell and Mike Orzen are pioneers in Lean IT, with management consulting experience in various industries, including global logistics, medical devices, food and beverage, aerospace, software development, financial
services, health care, and nonprofits.
Through many years of hands-on experience assisting their clients with
large-scale IT projects, the authors realized that effective change had to be
based first on improving underlying business processes before technology could make a positive impact. In the proving ground of IT project
implementation, they discovered how to effectively apply the principles
and tools of Lean and Six Sigma to IT efforts across many industries.
Steve and Mike are cofounders of the management consulting firm
Steady Improvement, Inc. (www.steadyimprovement.com), and are on the
faculty of the Lean Enterprise Institute (www.lean.org).
Steve Bell, CFPIM, brings over 20 years of
experience in information systems, operations, and finance. Steve is the author of
Lean Enterprise Systems: Using IT for
Continuous Improvement, published in
2006 by John R Wiley, which was nominated for the 2007 Shingo Prize Research
Award.

Mike Orzen, CMA, CFPIM, PMP,
delivers a unique blend of IT, operations management, Lean, Six Sigma,
and project management. With a BA
from Stanford in economics and an
MBA from the University of Oregon,
Mike has been consulting, coaching, and teaching for over 20 years.
349

68804943 lean-it-enabling-and-sustaining-your-lean-transformation

More Related Content

Similar to 68804943 lean-it-enabling-and-sustaining-your-lean-transformation (20)

Recently uploaded (20)

68804943 lean-it-enabling-and-sustaining-your-lean-transformation