Featured Product
This Week in Quality Digest Live
Quality Insider Features
Shannon Brescher Shea
Ten years and $1 billion to build the NSLS successor
Stephanie McArdle
The agency seeks to balance expedient exemptions against public transparency about medical devices
John Hunter
Why do we have to ‘sell’ quality improvement initiatives?
Venkatesh Shankar
Here’s a look back at how it changed the world
Manfred Kets de Vries
Leaders always need to keep hubris in check

More Features

Quality Insider News
Examine nine ways to help understand context, diffuse politics, heal relationships, and find the right work at the right time
New auditors must pass the exam before auditing for GFSI-recognized certification programs
Provides eight operating modes and five alarms
The profile measurement system has an accuracy of 5 µm and a measuring range of 1 mm to 50 mm diameter
ATOS Triple Scan used to design 12 bronze busts
Kreon breaks new ground with 3D scanner designed mainly for CMM applications
Making lean Six Sigma easier and adaptable to current workplaces
Inkbit is overcoming traditional constraints to 3D printing by giving its machines ‘eyes and brains’
Ideal for measuring large components in precision machining, casting, plastic moldings, electronics, and PCB inspection

More News

Jim Benson

Quality Insider

You Can Better Manage What You Can See

How to visualize knowledge work in process

Published: Monday, January 27, 2014 - 14:05

‘Those people in IT, I don’t know why we have them around.” Richard, a department head for a major healthcare firm, stared at me across the table. “They have projects that are six months late! Projects they told us would take only a few months to do! We’d be better off if we just outsourced the whole department.” He shook his head. “It can’t be fixed. We tried.”

There were more than 200 people in this company’s application development group. You needed a small theater to get them all in the same room. Why couldn’t they seem to complete simple tasks—simple by even their own definition?

Finding the gemba

The first place to visit was the gemba. Go talk to the programmers, see their space, and gain an understanding of what predictable impediments might be slowing them down. When visiting any shop floor, we usually find, first and foremost, physical manifestations of undue constraints or poor management. Unfortunately, software developers are engaged in knowledge work that is invisible. There is no gemba, merely people staring back at you from behind their keyboards.

This was not a 5S issue; keeping things clean and in their proper places was not going to solve anything. This was, however, a straight-up lean problem.

The first task: Create an observable gemba.

Teams of knowledge workers face a major challenge in that it is possible for them to be productive and effective for weeks at a time and have no idea what their co-workers are doing—even if they are working on the same project or even task. The work is simply invisible. Their main tools for production are their brains.

This invisibility of work means that simple acts of collaboration on the shop floor such as, “Help me lift this,” or, “Hey, you’re doing that OK, but here’s how you might improve,” or, “There’s too much inventory here; slow down production so the others can catch up,” become incredibly difficult to carry out.

Simply put, we can better manage what we can see.

These teams had created personal kanban boards that tracked the work of each individual coding team. These were on huge rolling whiteboards that tracked the flow of programming work through a simple, but illuminating, value stream.

The board also limited the work in process for individual contributors, so no one person would be overloaded, and the team as a whole could focus. They had created an observable gemba by building a proxy for work in progress, flow, and bottlenecks.

Visualizing for real

This all appeared to work on the surface, yet on-time performance did not improve. Projects were still mired down, and customers were becoming increasingly angry.

The second task: Be honest about work in process.

Every morning, each team would huddle for five minutes to talk about what work they were going to take on that day. These meetings were effective at getting everyone on the same page for that project. All team members left knowing what was on their plates for that day.

Then they’d work for awhile and then go to another huddle. Then another. Then another.

It turns out that people in the application development group were going to four to six huddles every day and accepting work in every huddle. The average worker was involved in four to six projects simultaneously. This would be comparable to working at Toyota and simultaneously assembling doors for Camrys, engines for Pathfinders, suspensions for Corollas, battery harnesses for Priuses, and dashboards for Tacomas. It would be utter insanity anywhere with visible work, but it’s routinely accepted as status quo for software developers, civil engineers, graphic designers, and accountants.

There was simply too much distraction and too much work in process for anyone to focus effectively and complete.

In order to get the teams on schedule, most of the projects they were on would need to be put on hold. Roughly 80 percent of the active projects would need to wait while the IT group focused solely on the remaining 20 percent.

This was not a popular idea.

When confronted with an 80-percent reduction in active projects, managers became unhinged. “Do you have any idea of the number of people waiting for those projects?” one midlevel manager screamed. The other midlevels nodded. It was simply too politically painful to stop any project.

Developers, presumably the beneficiaries of lower work in process, were likewise upset. “Those projects are important!” they protested. “We need to get them out as soon as possible! We can’t put them on hold!” Even those who were in charge of production didn’t believe anything would be completed on time.

This famous graphic from Gerry Weinberg made everyone nod, but still they were stuck. Political and emotional fear kept them working with so many projects that completion was either greatly delayed or impossible.

There was nothing wrong with Gerry’s graphic, but its inability to get people to act is telling. It was theory. It was possibility. But there was no direct impetus to act. People tend to act when they see something is amiss. The personal kanban boards they were using were showing them neat, orderly projects. Gerry’s graphic was showing them potential, but their own visualization was lying to them.

The teams then took butcher paper and hung it along the bottom of their rolling whiteboards. On that paper the people on the teams put a sticky note for everything they were doing on other projects. This created a view of real work in process for every team. That looked like the image below. At the very bottom, notes were so plentiful, they were stacked on top of each other.

The result was so ugly, so offensive, that no one could stand looking at it. We had succeeded in making the problem explicit.


The explicitness of the problem with the “hula skirt” compelled the group to greatly curtail the number of projects in process. A smaller number of projects allowed a given team to focus on one project at a time and realize the savings pointed out in Weinberg’s chart. Teams went from mostly context switching and politics to actually working.

The newfound focus on completion had immediate payoffs. Releases went from being an average of six months late to happening every week. Defects also fell because the reduction in projects in process directly reduced the delay between coding and testing. This led to shorter feedback cycles and more effective programming.

Relationships with the customers became more collaborative, also due to shorter feedback cycles. Prior to the reduction in work in process, the team would ask a customer a question and then get back to them weeks or months later. Now the turnaround time was days or even hours. Customers felt listened to, and it’s no wonder, now they really were.


The moral of this tale is simple. Most knowledge workers (not just software or IT) suffer under mountains of work in process. This largely happens because knowledge work is invisible. Although no change is easy, immediate improvements to team throughput and effectiveness can be seen by simply visualizing the work and limiting the work in process.

Visualize the work to understand it. Limit the work in process to complete it.


About The Author

Jim Benson’s picture

Jim Benson

A pioneer in applying lean and kanban to knowledge work, and an internationally recognized speaker and writer, Jim Benson is CEO of the collaborative management consultancy Modus Cooperandi. He is a fellow in the Lean Systems Society and recipient of the Brickell Key Award for Excellence in Lean Thinking, 2012. He is the creator of Personal Kanban and co-author of Personal Kanban: Mapping Work | Navigating Life (Modus Cooperandi Press, 2011) winner of the Shingo Research and Publication Award, 2013. His other books include Why Plans Fail (Modus Cooperandi, 2011) and Beyond Agile (Modus Cooperandi Press, 2013).