If you’ve been watching my blog, or heard me speak about The Phoenix Project, you may have some familiarity with something that I refer to all the time which is the Theory of Constraints and Technical Debt. This post is a quick primer on the Theory of Constraints, and I’ll dive into Technical Debt in the next post to bring it all together.
The Goal
By The Goal, I really mean “The Goal” which is a phenomenal book by Eli Goldratt. This book is regarded as the standard for efficiency creation in process management. While its roots come from manufacturing, the principals were found to be applicable to virtually every industry and every process. In fact, Gene Kim, George Spafford, and Kevin Behr who authored The Phoenix Project have all referred to Goldratt’s principles as the root of The Phoenix Project and the DevOps movement that they have been contributing to for years.
In a nutshell, these are fundamentals of the Theory of Constraints, or TOC:
- Identify the constraint(s)
- Exploit the constraint(s)
- Subordinate everything else to the above decision(s)
- Elevate the constraint(s)
- Go back to step 1
It’s really that simple. Another great thing that the TOC highlights is that everything has simplicity at its roots, because a complex system is actually comprised of a number of other simpler systems.
What is a constraint? It could be anything that limits a system from reaching its result. If manufacturing it could be something around speed or quality. In fact, most of the time we find that one becomes a side effect of the other. By increasing speed, we could risk quality. That is why we have to evaluate the constraint to ensure that we have solved it in the best way.
By eliminating constraints, we also have the potential to move the constraint elsewhere causing a downstream effect. This is like having a system of dams in a river, and as you release each one it will cause the water to be held back at the following dam. That’s ok though, because there is a reason that we have a 5 step list above with the 5th step being to return to step 1. There are always going to be constraints of some type, it is just a matter of how much impact they have on the overall system.
As each constraint is dealt with and elevated, we re-assess where the next constraint is. It may actually still be on the one we have just elevated. It just means that there is another constraint within that can be removed.
That is what I call the lather, rinse, repeat cycle.
How Do We Identify the Constraint?
Another key feature of the TOC is what is called TOC thinking. This is a process where all foot stakeholders on the system have to work through these 5 steps:
- Gain agreement on the problem
- Gain agreement on the direction for a solution
- Gain agreement that the solution solves the problem
- Agree to overcome any potential negative ramifications
- Agree to overcome any obstacles to implementation
If you want the TL;DR of that: get buy-in from all involved.
You can see how each of these steps is particularly important, and it is absolutely important that the entire 5 points have been achieved or else there is a risk that the constraint will not be removed.
There is a reason why my tagline is People, Process, Technology. It’s exactly what is needed to make a system work. Without the work of the people to agree on the challenges on the processes, the technology won’t do much good. Remember, technology is an enabler for business processes. In a way, technology is just a way to lift a constraint by putting in an electronic system to augment an existing process.
If anyone who is involved in the process does not play along, then you’ll quickly find that the process flow will not improve. We hear about the ever famous Luddites (http://en.wikipedia.org/wiki/Luddite) which illustrates the exact issue around process improvement challenges. By having someone involved who is sabotaging the removal of a constraint, whether intentional or not, it will delay or cause failure to the improvement. It can be unintentional in cases where someone builds a process to improve something but doesn’t fully understand the real requirements. In those cases, the supposed improvement was actually not removing a constraint at all, and may actually create one instead.
I could go on for hours about this, and it’s because I’ve put these processes in place and found success from it. There is a reason that Goldratt’s methods are referred to by people from all around the world in every sector of business. The TOC has become the basis for other powerful methodologies like Lean, Agile, Six Sigma and many more.
What’s Next to Learn More?
I’ll always have the same response for this when people ask me what they can do to learn: Read The Phoenix Project. If you’re really looking to dive deep, you should take the extra time and read The Goal. As a technologist or a someone in business who works with technology, The Phoenix Project is definitely a win-win to read.
Once you get through that, I’d also recommend Lean Startup by Eric Ries. I make a point to re-read each of these books every 6 months or so to keep the concepts fresh. I’ve gotten great benefit from them, and if you’re ever up to chatting on either of these concepts, I’d love to help if I can!
2 thoughts on “A Quick Primer on the Theory of Constraints”