One of the basics of improving our effectiveness is that we should control the amount of work we have in progress (WIP). Overloading people, teams and programs with more work than they can accomplish is a common problem. It causes multiplexing and frequent context switching. It overloads the people doing the work, reduces focus, reduces productivity and throughput, decreases quality and increases wait times for new functionality.

The problem is particularly an issue for knowledge workers in that most of the time WIP is not visible. Knowledge is hidden. The first step is to make it visible so that you can see it. A kanban board displaying how you work is a natural tool to do this.

Once you have done this you will find that WIP has a number of sources:

• Over-utilization of people. This happen especially when people are focussed on “100% utilization. See What Is Wrong With 100% Utilization Thinking? for more information.
• Over emphasis on starting. This happens when every project manager, for example, insists that their project is seen to be making progress.
• Large batch sizes being handed-off between stages. This happens when there are stage gate approvals.
• Bottlenecks in the process. This happens when people don't understand where the bottlenecks are.
• Interruptions and other unplanned work. Especially when people just say “yes” and take on all such work.
• Inability to make decisions. Which lead to lag / bottlenecks in the process
• Push-based approaches. For example, when the schedule says that “all this must happen now”.
• The “superhero” culture.
• Existing large queues of work (inventory).

You then must take proactive action to reduce your WIP:

• Establish a cadence and synchronize work on that cadence. Done correctly the cadence will naturally mean that you cannot take on too much work (although note that people / teams will still over-commit.)
• As it is visible, set limits on how much WIP you are willing to take on for this stage. Note that setting a WIP to be the “same as the number of people in the team” just hides the problem - you need to set up a lower constraint so that people really start concentrating on flow.
• Aggressively triage the work. See How Do We Deal With Product Backlog Explosion? for ideas on how to apply this thinking to a product backlog, but the reality is that this idea can be applied everywhere.
• Ruthlessly prioritize at all levels. Too much WIP at the program level has a tendency to result in too much WIP at the team level.
• Only commit when it means something. For example, if you are about to start some work, but have a dependency on another who is not able to do their part for a long time, it makes no sense to start your work now.
• Focus your work, working sequentially one item at a time.
• Stop starting and start finishing. This is especially important when you have inherited a huge backlog and people are asking you to take on more. Finish work that you have started before taking on anything new.
• Bring (flow) work to the teams (not people to the work). If you are planning using a traditional “resource / skills matrix” and planning percentages of FTE's to be assigned to projects, you will have a tendency to increase the amount of WIP.

And, again, begin by making WIP visible.