The Critical Information behind the Planned-Load

When I developed the concept of the Planned-Load I thought it would be a “nice-to-have” additional feature to my MICSS simulator.  MICSS provided me with the opportunity to check different policies and ideas relevant for managing manufacturing. It took me years to realize how important the planned-load is.

Actually, without the use of the planned-load it is impossible to use Simplified-Drum-Buffer-Rope (S-DBR), which replaced the much more complex DBR. Still, it seems most people in the TOC world, including those who develop TOC software, are not aware of its importance and certainly not its potential value, not yet fully materialized.

The planned-load for a critical resource is the accumulation of the time it would take to complete all the work that is firmly planned. The objective is to help us understand the connection between load, available capacity and response time!

Let’s use the justice system as an example. Imagine a judge examining the work he has to do: sitting in already scheduled trial-sessions for the total of 160 hours.  On top of that he needs to spend 80 hours on reading protocols of previous sessions and writing verdicts.  All in all 240 hours are required for completing the existing known work-load.

Assuming the judge works 40 hours a week then all the trials currently waiting for the judge should theoretically be completed in six weeks. We can expect, with reasonable certainly, that a new trial, requiring about 40 hours net work from the judge, would be finished no later than ten weeks.  I have added three weeks as a buffer against whatever could go wrong, like some of the trials requiring additional sessions or that the judge becomes sick for few days. This buffer is required in order to reasonably predict the completion of a new trial.

However, in reality we could easily find out that the average lead-time of a new trial is fifty (50) weeks – how can that be explained?

When expectations based on the planned-load do not materialize we have to assume one of the following explanations:

  1. The resource we are looking at is a non-constraint and thus has a lot of idle time. In the judge case, the real bottleneck could be the lawyers that ask and get long delays between sessions.
  2. While the resource is a constraint, the management of the resource, specifically the efforts to exploit its capacity, is so bad that substantial capacity is wasted.
  3. The actual demand contains high ratio of urgent cases, not planned a-priori and thus not part of the current planned-load. Those cases frequently appear and delay the regular planned work already registered in the system.

The importance of the planned-load of the “weakest-link” in operations is quick rough estimation of the net queue-time of work-orders and missions.  When the queue time is relatively long the planned load gives an estimation of the actual lead-time provided there is no major waste of capacity.  In other words the planned-load is a measure of the potential responsiveness of the system to new demand.

Have a look at the following picture depicting the planned-load (the red-bar) of six different resources of a manufacturing organization. The numbers, on the right side of the bar denotes hours of work, including average setups.


Assuming every resource works 40 hours a week, we see one resource (PK – the packaging line) that has almost three weeks of net work to do.

The green bars represent the amount of planned-work that is already at the site of the resource. In production lines, but also in environments with missions that require several resources, it could be that a certain work is already firm, but it has not, yet, reached the specific resource.  That work is part of the planned load. It is NOT part of the green-bar.  PK is the last operation and most of the known work-orders for it reside at upstream resources or maybe even not released, yet, to the floor.

The truly critical information is contained in the red-bars – the Planned-Load. To understand the message you need an additional piece of information:  the customer lead-time is between 6-7 weeks.

The above information is enough to safely conclude that the shop floor above is very poorly handled.

The actual lead-time should have been three-weeks on average. So, quoting four weeks delivery time might bring more demand.  Of course, when the demand goes sharply up, then the planned-load should be carefully re-checked to validate that the four-week delivery is safe.

Just to illustrate the power of the planned-load information – here is planned-load of the same organization four months after introducing the required changes in operations:


The customer lead time is now four weeks. The demand went up by 25%, causing work-center MB to become an active capacity constraint. As the simulation is now using the correct TOC principles, most of the WIP is naturally gathered at the constraint.  Non-constraint resources that are downstream of the constraint have very little WIP residing at their site.

The longest planned-load is three weeks (about 120 hours of planned work for MB). The four weeks quotation includes the time-buffer to allow getting over problems in MB itself, and having to go through downstream operations.

This is just the basic understanding of the criticality of the planned load information. Once Dr. Goldratt internalized the hidden value of that information, he based the algorithm for quoting “safe-dates” on the planned-load plus a part of the time-buffer.

A graph of the behavior of the planned-load through time could be revealing. When the graph goes up – it tells you there is more incoming new demand than demand delivered, which means a risk of having an emerging bottleneck.  When the graph goes down it means excess capacity is available allowing faster response.  Both Sales and Production should base their plans accordingly.

Other important distinction is to look for the immediate short-term impact of the planned-load in order to manage overtime to control the reliable delivery. The time horizon is the time-buffer – making sure the capacity is enough to deliver all orders within that horizon. It identifies problems before buffer management warning of “too much red”.  One should always look on BOTH planned-load and buffer management to manage the execution. 

SDBR, and its planned-load part, certainly applies to manufacturing. But, SDBR, including both the planned-load and buffer-management should be used to manage the timely completion of missions in almost all organizations.

There is a tendency in TOC circles to assume that any big enough mission, for whom several resources are required, is a project that should be manage according to CCPM.  While it is possible to do so and get positive results, this is not necessarily the best way, certainly not the simplest way, to manage such missions.

I think we should make the effort and distinguish clearly when SDBR can be effectively used for missions and when CCPM is truly required.   And, by the way, we can all think how the capacity of key resources should be managed in multi-project environments.  Is there a way to use the Planned-Load as a key indicator whether there is enough capacity to prevent too long delays or there is an urgent need to increase capacity?


Published by

Eli Schragenheim

My love for challenges makes my life interesting. I'm concerned when I see organizations ignore uncertainty and I cannot understand people blindly following their leader.

7 thoughts on “The Critical Information behind the Planned-Load”

  1. The Planned-Load also provides the current lead time of the system. As the market is constantly asking for shorter lead times, probably we can stablish a point in the planned load (protective capacity) as an alarm that the tolerable time of the market has been penetrated. When the load in the system continuously penetrate that point is a clear indication that we need to increase capacity.


  2. Gustavo you are absolutely right. The point you talk about has to be determines together with buffer management. When the planned-load penetrates the point we look for, the result is that after some time the number of red-orders, according to buffer management, would go up – warning us that the tolerance of the whole system has been compromised. Urgent efforts, using a lot of overtime could, hopefully, help to re-stabilize the system, but now you know you don’t like to go beyond that point in the planned-load.

    Liked by 1 person

  3. Great post, Eli!

    I’ve been calling what you call “Planned Load”, “Backlog” with a current client. In some respects it’s a constraint buffer, as well – of course – and also (in some service industries) gives one the opportunity to tetris work in more optimally. (I.e. If the backlog shrinks too far, we don’t have enough jobs of the various types to schedule work optimally, so lose time , irretrievably.)

    I’ve taken it slightly further (along the lines you mention, in your comment) in creating a set of management levers (a multi-option intervention framework) against the backlog state and the direction of its movement (Is it growing or shrinking? Is the change temporary (e.g. seasonal or situational) or permanent (e.g. demand growth or compliance related)).

    The next layer that I’ve created is a set of executive levers that provide a multi-option intervention framework for execs, in managing multiple streams in concert (e.g. seconding constraint-resources to where the need is greatest) and supporting the managers in an informed way (i.e. focus and defocus).

    Have you done anything in this respect? It would be interesting to compare notes…

    Thanks again for the post!



    1. The planned-load is expressed by time: say 120 hours, which translate into three weeks of work. If this number approaches the tolerance of the market to your response time – say the market cannot tolerate responding in more than 4 weeks (3 weeks plus some buffer time) then you should consider increasing the capacity to be able to respond much faster.


  4. Hi Eli,

    Why do you think so many people (consultants and clients) understimate and overlook the importance of planned load? We’ve had some cases where against all our efforts and recommendations, companys choose to not implement planned load.

    I think the importance of planned load is to smoothen the load at the CCR (release more or delay the release of WIP) . Otherwise, you are the market’s mercy. Planned load is such an important concept it deserves a couple more posts to include the reservation of capacity for urgent orders or strategic clients and how to do planeed load in hybrid MTO/MTA environments which can be tricky!

    Alejandro Céspedes


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s