Theory of Constraints 110: Elevating the Constraint

A series of 5-minute posts on applying principles of flow to knowledge work

Previously, I described how to go about subordinating the non-constraints of an organization in order to maximize its throughput. The next step, #4 in the Five Focusing Steps, is to elevate (or relieve) the constraint itself:

1. Identify the constraint
2. Optimize the constraint
3. Subordinate the non-constraints
4. Elevate the constraint
5. Return to step 1

The first thing to notice is that only now, after 9,000 words of commentary, do we arrive at the step many people use to “summarize” the Theory of Constraints: “Oh yeah I know TOC — it’s about focusing on the bottleneck.”

But consider what we miss out on when we go straight to Step #4, ignoring the first 3:

• We haven’t taken the time to properly identify the constraint, by making work-in-progress visible, by talking to the operators closest to the work, by looking for quality cycles and recurring dependencies, or by performing experiments that reveal the bottleneck. We are likely to go after the “squeakiest wheel,” which may be the hardest thing to change, instead of other solutions that may be easier, and more impactful.
• We haven’t bothered to optimize the capacity we already have, which means we aren’t taking advantage of buffers, preventative maintenance, work process simplification, or offloading. We likely aren’t using quality checks strategically, and haven’t ensured the constraint is working as much of the time as possible. We are in danger of spending huge amounts of time and money to add new lanes to the freeway, while a giant sofa blocks the express lane.
• We haven’t subordinated the non-constraints, which is necessary to pave the way for any benefits to be realized: ensuring non-constraints have excess sprint capacity, shining a light on the impact of emergency expediting, and setting a culture of always giving priority to the constraint. Even if your first guess at where the constraint lies happens to be correct, any improvement will likely be blocked as other people continue to optimize their own work, at the expense of whatever change you’re trying to institute.

Relieving the constraint is just one step along the journey, not the whole story.

In an interview in the appendix of The Goal with Dr. Antoine Van Gelder, who manages the hospital at the University of Pretoria in South Africa, we learn about their efforts to increase patient throughput using TOC. They identified their constraint as the supply of doctor’s time to attend to patients, which probably isn’t a surprise. The obvious solution would seem to be to hire more doctors. This is what it looks like to go straight to Step #4.

With a little more thought and observation, they identified a particular workstream that was taking up a large proportion of doctors’ time, and that was also particularly easy to fix: people not showing up to their appointments. In effect, they realized they were using their scarcest resource — doctor time — to perform a low value function: confirming appointment attendance.

With that insight, the solution becomes obvious: they developed a call-in list, which they called the “patient buffer.” Nurses were tasked with calling patients a day or two before their appointment, simply to ask if they planned on showing up. This had the effect of actually reducing the no-show rate, since it served as a reminder, and even if they didn’t attend, there was still plenty of time to find a replacement.

What this story illustrates is that the solution is simple in hindsight. But to maximize the chance that you’ll actually arrive there, it helps to follow the process.

Once we reach Step #4, we have an arsenal of tools to apply to “breaking” the constraint. Some examples:

Tracking performance data

Tracking the performance of the constraint, along multiple dimensions, in much more detail than you’d be able to do for all work centers. Your goal is to identify and then fix the top sources of lost time using cross-functional teams.

Reviews

Inserting special reviews or quality checks just before, during, or after the constraint, trying to isolate the factors leading to lost time or quality defects. Note that you’re able to apply much more rigorous reviews than you’d be able to do normally, or even ones that destroy units of the product, since you are doing so only at the constraint. The Lean technique of Poka-Yoke (definitely the best Japanese Lean term, by the way) advises building defect detection and prevention into the equipment itself. This would be the modern equivalent of advising people to choose stronger passwords right when they’re creating an account.

Setup reduction

Made famous by Toyota (where it’s known as SMED — Single-Minute Exchange of Dies, and Jidoka — partial automation), this applies equally to knowledge work: automating deployment, integration, and testing for software programmers, or using templates or style guides for designers.

Updates/upgrades

Once you know what the constraint is, you can afford to spend quite a bit of time strategizing around its maintenance. This could include proactively scheduling updates and upgrades to avoid unnecessary downtime (known in Lean Production as TPM — Total Productive Maintenance).

Increase capacity

And finally, you can of course always buy more machines or hire more people at the constraint. Note that the economics of doing so are completely different than for the typical hire: it makes sense to hire even extremely expensive or extremely unproductive resources, because every unit of capacity at the constraint is worth the throughput of the whole organization. But because adding any capacity is extremely expensive in terms of time and money, we do it as a last resort, instead of a first resort.

Policy constraints

As I mentioned in TOC107, it is often policies and rules that represent the most limiting constraints. Being immaterial, their impact is pervasive, but difficult to pin down precisely. This is why Step #4 is called “elevating” or “relieving” the constraint, and not “expanding the bottleneck” — if it is a policy or rule you’re fighting, you want less of it, not more!

Paradigm constraints

Of all the principles and techniques the Theory of Constraints addresses, for me the most interesting is paradigm constraints. They are the blindspots and the assumptions, the worldviews and the filters that enable, but also limit, our view of reality.

These paradigms were an important factor even in manufacturing, as decades of experience show that even in factories, people management is paramount.

But in knowledge work, they become all-important. Our challenge is to translate the universal principles of flow to the mysterious inner workings of the mind. To show that exponential improvement in throughput is possible even with virtual, immaterial, networked information, not just raw materials.

As we creep closer to the very center of consciousness, it becomes more and more difficult to tell what is the constraint, and what is the self. It becomes clear that our conception of who we are is itself a constraint, that relieving this ultimate bottleneck requires nothing less than elevating the self.

But we’re not done with TOC yet. There remain two topics that together serve as a bridge from manufacturing to knowledge work: the application of TOC to project work, known as Critical Chain Project Management; and the final application of TOC, to logic itself, known as the Thinking Processes.

Follow us for the latest updates and insights around productivity and Building a Second Brain on Twitter, Facebook, Instagram, LinkedIn, and YouTube. And if you're ready to start building your Second Brain, get the book and learn the proven method to organize your digital life and unlock your creative potential.