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.

Categories

Meta

We do not share personal information with third-parties nor do we store information we collect about your visit to this blog for use other than to analyze content performance through the use of cookies, which you can turn off at any time by modifying your Internet browser's settings. We are not responsible for the republishing of the content found on this blog on other Web sites or media without our permission. This privacy policy is subject to change without notice.Ok