Finished chapter 4 and spent a fair bit of time thinking about it. (Very thought provoking
Even though I really wanted to read it through the lens of mathematical variability I could not escape the similarities with manufacturing.
At first sight, knowledge-work and manufacturing appear different, however these differences could be resolved if we could uncover and better understand the (hidden) assumptions we use when analysing each domain.
There are some assumptions I had to make when reading chapter 4 that I would like to discuss with you. Please correct them if they are wrong.
There are two in particular:
1. Multitasking: What does it really mean to multitask and what makes it so bad?
The “context switching” cost for humans seems very similar to the cost of “setup” or “changoever” durations in manufacturing when different products need to be processed on the same machine.
We can have multiple demand orders from different customers, which can be broken down into multiple tasks. These tasks will need to be processed on various different machines.
The question is: Is it still multitasking if we process tasks from OrderA and OrderB at the same time (i.e. in the same “batch”), if it does not result in any delays?
This is important because we can potentially group tasks that do not require any setups or changeovers together, in order to achieve an Economic Batch Quantity (EBQ).
If this is the case, there are some interesting similarities that could be draw from Chapter 4 of “What is this thing called Theory of Constraints and how should it be implemented?” concerning EBQs.
It appears that “multitasking” as well as “batching” are words that have multiple meanings depending on the context.
Assumption: There are multiple projects in WIP, all of which have different tasks. Switching between tasks within a project as well as switching tasks between projects will incur a “time cost”.
Manufacturing assumption: A machine is only able to do a particular type of work. It may require some downtime to “set things up” or “clean things down”, but essentially the machine does a similar “type” of work. (With a reasonably well known rate of production).
Knowledge-work assumption: When it comes to humans, things get a lot more blurry. In knowledge-work, assigning work is different. We generally assign work to people that have “about the right” skills. Unlike machines we were not designed and purpose built to only do one type of task. (Having the right skills can be very blurry and is open to interpretation, whereas with machines it is not.)
The problem with knowledge-work, unlike machines, is that we do not have a good grasp of how long a task will take to complete. i.e. we do not have a good grasp of our rate of delivery. Especially if the characteristics of the tasks are wildly different, and require different skills.
Manufacturing is better equipped to assign tasks to the right machines, because there is limited choice, and things are better defined. Whereas, with knowledge-work we have more flexibility to assign tasks to people with different skills. What makes things worse in knowledge-work, is that we may not always be certain of the necessary skills required to complete a task (which can result in lot of lost time and effort), whereas in manufacturing this happens a lot less.
2. Wait time and multitasking time
It appears from the geometric diagrams that the wait time is directly proportional to the WIP that has been removed from the system.
To be clearer, are you assuming the system is simultaneously working on multiple projects at the same time, and that if you stopped working on one project (removed it from the WIP) then the wait time affecting the other project will be reduced by the time it would have taken to complete the removed project on its own?
My confusion comes from the graph on page 76, which seems to refer to the time lost to multitasking (i.e. the black bars) as “setup” or “context switching” time (i.e. no productive work is being done).
Let me try and explain my interpretation of the graph on page 76, to see if I understand it properly.
A project should take 100 units of time (let’s assume minutes) to complete (I know it is in percentages but let’s use real numbers to make this easier), if we were only working on this project.
If we have two projects that took 100 minutes each to complete, we could finish both projects in 220 minutes. (i.e. 20 minutes to context-switch), if we focused on one project at a time.
However, if we chose to multitask, and switched projects every 40 mins, it would take us 280 minutes to finish both projects.
If we have 5 projects that took 100 minutes each to complete, we could finish them all in 580 mins, if we focused on one project at a time.
However if we chose to multitask, and switched projects every 4 mins, it would take us 2,420 mins to complete all 5 projects.
The strategy we use to complete the projects is important.
In one case we can complete 5 projects in 580 mins.
In the other case we complete 5 projects in 2,420 mins.
What I am not entirely sure about is what assumptions concerning strategies are you using on page 80 and how many projects are currently in WIP?
What I find interesting is that the adopted strategy effectively acts as a constraint.
Strategy in manufacturing is hugely important (as demonstrated by ToC), but it seems it could be even more important in knowledge-work, mainly because it is one thing to have variability in product mix, and quite another to have variability in capability mix. It creates infinitely more possibilities and options to get things wrong.