WIP limits matter

One objective of Lean should be a continuous reduction of inventory levels. But while there seems to be a common understanding about the benefits of low inventory levels in manufacturing, the folks in indirect areas often refuse to embrace the idea of WIP limits. In fact, indirect areas process so much projects, tasks and activities in parallel, that keeping track of the actual backlog gets rather difficult. For that reason I would like to give a brief, illustrative, and quantitative example which should shed some light on the benefits of WIP limits.

Where do high WIP levels come from?

Without loss of generality, let’s consider a software factory which has to deliver three projects: Project A, Project B and Project C. So you might start to work on Project A. But soon encounter some impediments: A product specification is missing, the client is delaying the approval for the next phase, or your supplier is late on the delivery of some critical component. In any of these cases you face two options: Either you wait until the problem is solved and let your team be idle, or you start doing some work for Project B. If you choose the latter, you get on a slippery slope. What happens if you got stuck in Project B as well?  You might start with Project C, just to maintain your team occupied. So, at the end of the day, you run all projects in parallel.

Why is parallelism bad?

Running the projects in parallel might seem a good idea. After all you can keep your team busy even if you face impediments. Less idle time should equal more productivity, right? Wrong, dead wrong! This kind of behaviour creates more overhead and delivers less value. Let me show you why.

In order to quantify the example let’s assume the following characteristics:

• We have 6 team members, each costing U$ 1,000 per week
• Project A requires 3 weeks of work and generates U$ 1,500 per week after deployment
• Project B requires 2 weeks of work and generates U$ 400 per week after deployment
• Project C requires 1 weeks of work and generates U$ 500 per week after deployment
• If you run one project at the time you need 10% more time due to occasional idle times
• Each project in progress requires overhead cost of U$ 150 per week for reporting

Given those numbers the cost for running the projects in parallel is quite straight forward:

Costs Team:	6 weeks x 6 team members x U$ 1,000 = U$ 36,000
Costs Overhead:	6 weeks x 3 projects x U$ 150 = U$ 2,700
Gains with Project A:	0.6 weeks x U$ 1,500 = U$ 900
Gains with Project B:	0.6 weeks x U$ 400 = U$ 240
Gains with Project C:	0.6 weeks x U$ 500 = U$ 300
TOTAL COST	U$ 37,260

The costs for executing the projects in sequence can be calculated in a similar fashion:

Costs Team:	6.6 weeks x 6 team members x U$ 1,000 = U$ 39,600
Costs Overhead:	6 weeks x 1 projects x U$ 150 = U$ 900
Gains with Project A:	3.3 weeks x U$ 1,500 = U$ 4,950
Gains with Project B:	1.1 weeks x U$ 400 = U$ 440
Gains with Project C:	0 weeks x U$ 500 = U$ 0
TOTAL COST	U$ 36,010

So if you compare U$ 37,260 to U$ 36,010, you see that maintaining the WIP Limits gave you a cost saving of 4%.

Conclusion

Of course the numbers in this example are arbitrary and can be tweaked to prove the opposite as well. But disregarding the final result, the example makes the strong case that the Backlog in IT and Service areas must not be disregarded, and therefore advocates in favor of WIP limits.