Thanks @tendon ,
I read the link and it does answer a few questions and raises some others
I agree we should keep things as simple as possible. What I am thinking about would not be complicated to put in place, and I like the conceptual symmetry it has with a fever chart. (i.e. managing the constraint buffer with a similar chart rather than a hard number.)
This is more an exercise in exploration, and would be unnecessary for small projects or when the constraint is close to the start of the work flow. (i.e. it would probably only make sense for managing a constraint that is required by multiple projects and happens to be located towards the end of the workflow.)
This get’s interesting because if the constraint is required by multiple projects it could be located at different positions with respect to the work flow for each project. (For some projects it may be closer to the start and in others it may be closer to the end.)
Yes, I am assuming several tasks are fully kitted in each project and are ready to enter the work flow at a moments notice. Each task (belonging to different projects) would have an overall portfolio priority assigned to them.
Let’s assume the constraint is currently working on a task, which it will complete in 3 days time. The constraint buffer is empty. The next most important task across the whole portfolio will take 5 days to reach the constraint if it enters the work flow now.
This isn’t good because the constraint will be idle for 2 days if we do that. So we have no other choice than to find the next most important task within the portfolio that can get their faster, hopefully within 3 days.
Now I understand we shouldn’t have an empty constraint buffer in the first place (but will get to that shortly). The next best (hypothetical) choices are listed below:
- Task portfolio priority 5, project A. Time to get to the constraint 3. Process duration 4
- Task portfolio priority 10, project B. Time to get to the constraint 2. Process duration 10
- Task portfolio priority 1, project C. Time to get to the constraint 5. Process duration 2
We are faced with a dilemma.
If we go with choice 1. we must hope Murphy will not strike and that we will get the task to the constraint in time. If it does strike then the constraint will go idle until it arrives.
With choice 2, we have a one day buffer in case Murphy strikes, however the problem is, this task has a really low priority and its process time is very long. So much so, that when the task with priority 1 arrives at the constraint buffer it will have to wait 8 (days) before being processed. (What is best letting the constraint go idle for 2 days and process the high value task quickly, or keep the constraint busy but make the high value task wait for 8 days?)
With choice 3, the constraint will be idle for a minimum of 2 days (all going well).
So what I meant by point 3 in my original post is that the initial priority needs to be adjusted when you take into account the time it takes for the tasks to arrive at the constraint buffer, if the buffer is running low.
How should the priorities be adjusted is the open question. (and is perhaps too academic, but found it interesting nonetheless.)
How did the constraint buffer get empty in the first place?
Let’s assume we have several tasks ranging from 1 to 10 in process duration, with a mean of 2 (I really think median is a more accurate parameter).
The task with a duration of 10 is currently being processed on the constraint, but the average in-state flow time is 2.
The average time for a task to reach the constraint buffer is 6
The constraint buffer has 4 tasks in it, each with a duration of 1. (No other tasks are on their way to the buffer).
When the constraint finishes its current task, it will then process the 4 tasks that are currently in the buffer within 4 days. Even if the signal to replenish the buffer is immediately sent the minute it starts working on the first buffer task, it will be idle for 2 days (at best) before the next task arrives.
Rather than using hard numbers for the constraint buffer we could elegantly deal with such situations with a chart. (but only for multiple project scenarios).