This topic fascinates me.

There is a constant need to “superimpose” a customer due date over a workflow environment. That workflow environment could be a factory or a service environment. I mean, what else should you do?


We use the word “due date” without a lot of context. But is it?

-The date the customer wants to use the goods
-The date the customer expects to receive the goods
-Or the date the goods are available to send to the customer.

Most of the time, we assume it is the date the customer expects to receive the goods.

We seem to have a need to decree that “we are late” or “we are on time” or “we are early”. And the due date coupled with the decree cause some undesirable effects.

When we impose a customer due date on a workflow environment, we end up with a negative side effect, when under pressure, “to shove jobs in” to meet dates.


We know from years of seeing this, that very rarely does “shoving it in” work and we get these undesirable effects:

-Rush jobs
-Resetting plans far more often and too often
-Remaking jobs lost, only to find the original job later
-Some jobs done too early and some jobs done too late
-Lots of work in progress
-Way more interference to get jobs activated and completed.
-More late jobs
-More overtime worked.
-Forcing a customer to receive on time deliveries forces someone else to be late!

So, let’s consider “decoupling” the date by which a job is available for a customer from the date the customer expects the job, which is typically the date the customer supplied.

Now we have two systems (internal and external), and they are not superimposed.

So what? Well, now we have a way to control two decoupled systems. Of course the customer date is still important, but we can now “see inside” the two systems and see way more than before.


The magic is we can now have visibility inside these systems:

-An internal system in control and an external system out of control!
-Or an internal system out of control and an external system in control.
-Or both in control
-Or both out of control.


When these systems are “superimposed” all we see is:

-The system is in control
-The system is out of control.

When I first saw the distinction between internal and external, it was a revelation. It was the key that unlocked the door. It was the insight that connected the processing of packets of work with customer due dates.

How so?

Because when they are decoupled you have a much higher chance of increasing the control and increasing the speed. Think of these pairs of behaviours with respect to the internal system.

Behaviours we have now

-Shoving it in, doesn’t make it come out
-Schedule to maximize resource utilisation with respect to due dates
-Release work in batches to maximize up time
-Stay on a job for as long as possible
-If I can’t hear the machines, we are not making money!
-Do chase ups to get work to move

Behaviours we want to move to

-Schedule in, what came out
-Schedule the slowest process, and only that process, with respect to due dates
-Release work to meet customer due dates
-Switch jobs to keep a queue of ready to run work in front of the slowest process
-If I can’t see a queue of work in front of the slowest process AND the slowest process is not running, THEN we are not making money
-The state of the internal system sets priorities

Let’s imagine the Jobs in Process are operating in a time buffer, and let’s say that time buffer is 6 days.

If 85%+ of the jobs are completed before 4 days has passed, we know this is a stable system.

If 15%+ jobs are NOT completed before 4 days has passed, the risk of a date failure increases and now the system is becoming less and less stable. What’s more, the capacity is diverted to increase the chance of success, and now new jobs entering the system are not started. The inevitability is that more and more, the load shifts to days 5/6, and more and more jobs will be late. So, shoving more jobs in with a due date of 7 days or less is never going to work! But that is what we do, a lot.

So, let’s manage the load by getting customer due date expectations out from the jobs in process buffer, and be a little bit clever about what we do, and face up to the inevitabilities that we know about!

The demarcation between Jobs Waiting to be Started and Jobs in Process is a key decision. Don’t abuse it! You are granting permission to start a job, consume raw materials and commit labour and machines.


The decision to release a job from to be started to in process, should be based on:

-The customer due date
-How many jobs were completed since the last release. We release the same number of job equivalents.
-If this decision causes a valid due date to be left behind, DO NOT release it under duress.
-Find a way to go faster with the work already released and when the job completion rate rises, then re-apply rule 2 on the next release.
-Or negotiate with the sales rep/customer to a new due date. [NB: most customer supplied due dates are a wish, mostly no harm will be done if dates are moved. How often do you see “rush” jobs sitting around for days and weeks at a customer site!]

Keeping the 6 day time buffer in control by avoiding “shoving it in” can have massive speed and control advantages.

We know stable systems are the lowest cost systems to run. We get lowest cost by not allowing “overproduction” to occur. We get lowest cost by not chasing jobs about. We get lowest costs by having faster flow.

Coupling a due date to a job is folly. Managing a time buffer to be in control has far greater benefits. But we must accept that from time to time, the time buffer will be in control, and the market (ie customers) may receive goods late. Remember, many times late can be avoided by other strategies. Talk to the customer early enough so both you and him can rejig if necessary.

To join us at our free lunch event and discuss workflow and productivity in your business click here.