Hi Janelle – wow, thank you for the kind words. I appreciate that.

In Goldratt’s example, he discusses a boy scout troop on a hiking trail. Some of that group wish to go really fast and some moderately fast, and some slow. In his example, the entire troop goes only as fast as the boy scout in the front of the trail. That makes sense. But it can also work the other way around: The entire team can only go as fast as the slowest person on the team. That can also be the constraint.

So, since constraints are a natural phenomenon present in every dynamic system, recognizing what the constraint is in the system and then managing to it is key.

Again, thank so much for your kind words.

I had a question. In your drum-buffer-rope picture, you have a guy in the back that you label as the “constraint”. This really confused me, since I thought the bottleneck (the drummer), would be the constraint?

I know it’s been years since you wrote this article, but would you mind explaining this part?

Also, you say that you made sure that the upstream pick-rate would never be higher than the pack-rate. That is not good. There are times that the upstream pick-rate MUST be higher than the pack-rate. Those times would be that the buffer, for whatever reason, becomes depleted. Otherwise, there is no way that the buffer to the constraint can be replenished without starving throughput at the constraint, and that’s the whole point of the buffer.

The pick-rate should NORMALLY be no higher than the pack-rate for this example–as stated, the constraint acts as a drum to keep the pick-rate at the rate where maximum throughput is sustained. But the pick-rate must have excess capacity that can be called on when needed to replenish the buffer to prevent sacrificing throughput at the buffer, otherwise you would need an infinitely-long buffer to ensure that it never becomes starved.