- Start every limit at 1. Add tokens 1 at a time until one person is always busy, then apply Theory of Constraints.
- Start every limit at an arbitrarily large value, like 10. Subtract tokens 1 at a time until flow is observed. Then start looking for a way to remove 1 more.
- Create a Value Stream Map and measure the time-on-task distribution of each activity. Use Little’s Law to calculate the corresponding queue sizes.
Notice that “match the number of people currently available” is not one of the ways. You’re trying to discover how many people you need not how many you have.
ObiJohn | 05-May-09 at 7:09 pm | Permalink
Okay, I’ll bite… if the goal is to ensure maximum flow, then why not start with a WIP limit of one per every resource available at a process step/activity, and then adjust the limits based upon constraints as per ToC? Isn’t this a faster way to find the bottleneck and use it to pace the workflow?
Corey Ladas | 06-May-09 at 6:55 pm | Permalink
Sure, you could do that. It’s more or less equivalent to starting everything at a high number. It might also be easiest to convince people to do (confirmation bias: see, my role is important) and hardest to convince them to accept the result (what do you mean my role is superfluous? you must be wrong.). The arbitrary high number neutralizes the perception of vested interest. Negative selection is more painful than positive selection–loss aversion is human nature.