The Theory of Constraints offers a simple five step process:
- Identify the constraint
- Prioritise work at the constraint
- Optimise the constraint
- Add capacity to the constraint
- Goto 1
Often the hardest thing to do is step 1, to identify the constraint.
One of the main frustrations for a coach is that they can see the constraint but cannot convince the organisation that they need to address the constraint. This is because the organisation has not reached the state of conscious competence about the constraint. They may see the constraint but they do not value it. Paul Adams talk reveals that famous people make us aware of new things but we only adopt them (value them) if one or more of the four people close to us in that context value it.
This means that often before the organisation will accept the constraint, they must first see the coach as a close trusted advisor. In order to achieve this, the coach must first help the organisation remove the constraints that the organisation think are the most important. Even though the coach might be torn because Theory of Constraints shows that working on anything other than the constraint has no impact, they are actually working on the Zeroth Constraint. The Zeroth constraint is that the organisation do not see the coach as a close trusted advisor.
Coaches who do not address the zeroth constraint may find themselves frustrated or in conflict with the organisation they are coaching. They find themselves in this state because they are acting with integrity, they are trying to focus on the most valuable work for the organisation. However first, they need to align themselves and the organisation in terms of understand the value of fixing the true constraint. To do this, the coach may need to demonstrate that they can fix the constraints that bother the organisation even if they are not true constraints. Demonstrating this ability to address these constraints will give the organisation more confidence that the coach can help them fix constraints they might otherwise prefer not to acknowledge.
If you are coach who is worried about working on improving the system away from the constraint, feel confident that you are acting with integrity because you are working on the zeroth constraint.
This insight came out during a conversation with Tony Grout (of course). I would say it was his idea, he might say it was mine.
The IT Risk Manager 
February 5th, 2017 at 8:50 pm
The Theory of Constraints is slightly wrong. While it’s true that work on anything but the constraint won’t directly improve output, work on other portions of the system will either generate slack or inventory. If you can avoid the inventory, the slack may be useful for maintenance, analysis, swarming, and ultimately help detect and eliminate primary constraints. Slack is valuable, don’t discount it.
Of course, much of this requires that people listen to those doing the work, if that doesn’t happen, then all their insights will be wasted, and, ultimately, little improvement will happen.
February 5th, 2017 at 8:52 pm
Thank you for the clarification. 🙂
February 5th, 2017 at 8:55 pm
In other words, without slack you won’t have queues to identify the constraints. 🙂 Nice.
February 5th, 2017 at 8:58 pm
Without slack, you waste your employees brainpower, as they have no time to think, they can’t see, can’t learn, and can’t help.
February 5th, 2017 at 10:27 pm
Marty, I’m not entirely sure you have processed Goldratt’s intent here. Goldratt doesn’t suggest that there is no work outside of the constraint, he calls for subordinating the other tasks in the system to the constraint – subordination suggests that they ‘first’ serve the constraint (ensure it is fed, and it’s output consumed); beyond that one has to think about the overall system before determining whether resource (capacity) is excess. Where maintenance, analysis, swarming etc generate realised customer value, and are not upstream of a bottleneck (perhaps they bind later in the flow) then the fundamental question is one of return on capital. Where they are contributing inventory to the line (e.g swarming to design something, or analysis of a future requirement) take care to avoid convincing yourself that building inventory (including product backlog) is a good thing. Throughout accounting would caution us to deduct the value of WIP from the output of our system.
February 5th, 2017 at 11:01 pm
Certainly, he argues for subordinating others tasks to the constraint, this translates to: don’t generate inventory. It is a correct sentiment. Everyone knows that excess inventory is waste.
The problem is when there is some easy cheap way to increase the capacity of a non-constrained task that will not generate downstream work. Theory of constraints would imply that the change should not be made. However, making the change will generate more slack, and that slack will eventually improve the system around the bottleneck or avoid other more urgent bottlenecks.
Worse, you are arguing that maintenance generates no customer value. This is clearly false, as, unmaintained machines eventually break, making them unable to serve the constraint. Worse, delayed maintenance costs tend to raise exponentially with the delay, timely maintenance is always cheaper.
The same goes for analysis. If you wish to resolve the constraint, someone must notice some way to either bypass it, or increase its capacity. This is the outcome of analysis, and when you don’t give most employees time for it, then most ideas to fix the constraints won’t be found.
Finally, I don’t think that you understand what swarming is. It’s the kanban principle that when either you input buffers is empty or output buffers are full, you should investigate what is happening in that direction. The result of swarming is that, everyone quickly learns where and what the constraint is. As a result, a large number of people can contribute ideas to resolve it, leading to a quick fix or workaround.
The basic problem with Theory of Constraints is that it is a top down problem solving framework. It depends on the genius of some external optimizer to fix the system. Unfortunately, the genius of a single individual, no matter how great, will usually be outweighed by the ideas generated by a large group near the work. Fundamentally, improvement is a bottom up process, with management’s main role being encouragement, coordination, and getting out of the way.
February 6th, 2017 at 1:06 am
Reinsertsen says that the problem is not the constraint rather things upstream. Managing queues is where the problem lies according to him. Product Development is an intellectual pursuit entailing variability that TOC doesn’t handle that well. I’m not an expert on TOC – however I do note the David Anderson in his first book used TOC but was then advised by Reinsertsen that a Kanban system would be more appropriate for Product Development. That aligns with Marty’s last paragraph as well. Kanban and self organising teams with managing to create flow is preferred according to the doctrine (which seems to work well)
February 6th, 2017 at 6:56 am
Marty,
I appreciate your passion and the force of your argument. I’m not an adherent to any particular school, methodology, process nor thinking model. I do appreciate Chris’ investing time and energy to study and share his learning here. I myself find that being forced to clarify my own thinking helps me understand what I have and have not understood well enough to share.
I felt compelled to reply for a few reasons:
1. The manufacturing language typically associated with TOC (and historically lean) have resulted in a number of misunderstandings and misrepresentations that I felt you were perhaps falling foul of;
2. I worry about the response that “without slack, you waste your employees brainpower, as they have no time to think,”; I don’t think this is a function of TOC, or more specifically the ‘focusing process’; of course it is possible that line management misunderstand the application of a practice to a ‘knowledge work’ system such as software development, but this is a management problem. Similar criticism is levelled against Scrum and several other approaches.
I’ll try not to light the fires, but wanted to respond to a couple of points you have raised in response to my comment (which was, perhaps too abbreviated and throw-away).
You said: “when there is some easy cheap way to increase the capacity of a non-constrained task that will not generate downstream work. Theory of constraints would imply that the change should not be made.”
First, I think TOC thinking would have us focus our effort first on the constraint within the system (I think you make this point yourself in your argument for “swarming” when you say “when either you input buffers is empty or output buffers are full, you should investigate what is happening in that direction”. Once you have determined that there is either nothing to be done, or that the constraint operates such that the element of the system that you represent has ‘excess capacity’, TOC is not prescriptive that such ‘excess’ be eliminated; and in many cases the resource (like a specific machine on a factory floor) cannot be ‘cut in half’ and reduced. In most systems, the resources at each stage are not fungible (or are poorly fungible).
Second, TOC thinking would suggest that you shouldn’t increase (or rather exploit an increase in) the capacity of a non-constrained part of the system (if such increase in capacity has cost) unless such increase added value to the customer. I specifically don’t think there is a concept of downstream-work other than inventory; and certainly the objective is to control (not eliminate) inventory. TOC is explicit that building excess in process inventory (local optimization) is sub optimization of the ‘whole system’, or as lean would label it ‘waste’.
I do worry, however, about an assertion that “However, making the change will generate more slack, and that slack will eventually improve the system around the bottleneck or avoid other more urgent bottlenecks.” Clearly these are potential outcomes, but equally likely are that changes focused on local optima will generate a change in the output/outcome from a process stage/step and impact the system more broadly, or that avoiding other more urgent bottlenecks involves speculation by participants at the relevant ‘node’. Instead, TOC thinking, particularly as espoused in the ‘critical chain’, would suggest that under/unutilized resource should be applied to the overall system, rather than at the node from which it is released. This may be what you are saying, but is an important distinction in my view. I think you may have misinterpreted this in your ‘genius of a single individual’ comment. TOC eschews focus on local optima, that doesn’t prevent a well facilitated system from allowing resources to be contributed to global optimization.
I take exception to the assertion that “Worse, you are arguing that maintenance generates no customer value.” I made no such assertion. First, I think you are conflating the maintenance of the means of production with the maintenance of the product of production ‘unmaintained machines eventually break’. I was specific that where maintenance can deliver value to the customer independent of any current bottleneck then it should be evaluated on a ROIC basis and prioritized as with any activity (this is actually independent of whether such maintenance is ‘product maintenance’ such as in a software development organisation or ‘means of production maintenance’ which might include toolchain, or capital plant in a manufacturing context).
With regards analysis, I don’t recognise the distinction you are making. If analysis is subordinated to the constraint then it is consistent with TOC. In knowledge work, if you don’t give people time for analysis in everything that they do, then you are not maximising the value of their work overall (this in my view is where many software projects that have sought to specify and ‘send to the factory’ whether in-house, onshore or offshore, have failed). My concern is where thinking is shoehorned into downtime generated by failures elsewhere in the system, at which time it typically results in incremental inventory (more work to do later); I’d rather have thinking ‘built in’ and therefore free up resources for the whole system where there is a constraint or interruption to flow, rather than have those same resources build analytical inventory at their local place in the system.
I think we were talking past each other when I referred to swarming. It was not clear from your comment that you were making a Kanban reference; I rather interpreted your comment as referring to any concentration of human effort around a single problem. Using your definition, “when either you input buffers is empty (sic)” then the constraint is upstream from you and so releasing effort in that direction is subordinating resource to the constraint; similarly if “output buffers are full, you should investigate what is happening in that direction” would imply the same. Neither assertion is incompatible with TOC thinking. I would however argue that “As a result, a large number of people can contribute ideas to resolve it, leading to a quick fix or workaround.” is worthy of unpacking; specifically most of us have first-hand experience that suggests that adding more people to a problem area in a system doesn’t necessarily ‘lead to a quick fix or workaround’. It is important that these people offer such assistance as those who own the impacted sub-system want (and so subordinate themselves to the issue/constraint).
All too often there are polarisations across schools of thought that are unhelpful to creating progress overall. I enjoy Chris’ writing as he endeavours to be a student of all that crosses his path, and like him I have found myself to be better for each new approach, method, model or process that I seek to understand. Understanding doesn’t necessarily require application, nor does it demand religious adherence from those who apply it.
Within the scope of each practice, adopting Shu-Ha-Ri can help keep us all sufficiently humble, we learn by doing (without modification); in Ha we might inoculate practices from another model (we have learned before) into that which we are practicing; in Ri we recognize the learning of the deep thinking practitioner and evolve the state of the art (from where often others develop new discrete practices which demand our Shu learning evolve). In each case, we rarely learn without deep understanding and I appreciate your taking the time to clarify your thinking so that I could better understand.
February 6th, 2017 at 2:07 pm
Marty said: “The basic problem with Theory of Constraints is that it is a top down problem solving framework. It depends on the genius of some external optimizer to fix the system. Unfortunately, the genius of a single individual, no matter how great, will usually be outweighed by the ideas generated by a large group near the work.”
This statement is either a misunderstanding or a misrepresentation.
Have you read Goldratt’s novels? i.e. The Goal, It’s Not Luck, Critical Chain, Necessary but not Sufficient? In every one of them improvement solutions is derived by intense team work of people collaborating and elaborating ideas together. There is no place in TOC where the guru, top-down approach is prescribed. To the contrary, the tools offered aim at building a deeper understanding (like Deming’s) of what really is happening in the system; an understanding that is shared by all people involved. This is where TOC has an edge. While TOC might seem like a top-down imposition, it never works without the involvement of all and everybody.
(Besides, that’s why I put the “Unity of Purpose” pattern at center stage of TameFlow.)
March 25th, 2017 at 3:12 am
[…] using the Theory of Constraints to coach an organization, “The Zeroth constraint is that the organisation do not see the coach as a close trusted […]
April 15th, 2017 at 2:29 pm
[…] before anything can start they need to build trust and respect with their fellow executives. Not something that happens over […]