Theory of Constraints 108: Identifying the Constraint

In the previous episode, I introduced the Five Focusing Steps, which can be used to improve any system of value creation:

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

But what does it actually look like to go about identifying the constraint in an organization?

In the days of factory manufacturing, it was relatively straightforward: walk the factory floor, and look for where parts are accumulating (a practice Toyota called gemba). This was one of the reasons for putting so much emphasis on reducing work-in-process inventory — with minimal material on the factory floor, a pile of parts waiting for a machine to finish its operations stuck out like a sore thumb.

But how do we identify constraints in knowledge work, which is often so immaterial? This requires a bit more sophistication, but is far from impossible.

First, you have to make work-in-progress visible. Because information work doesn’t usually have a physical manifestation, much of modern productivity starts with making it tangible: kanban boards, gantt charts, burndown charts, to-do lists, calendars, and timesheets create visual displays where workloads and progress can be evaluated more easily.

Second, look for the most scarce resources. At an individual level, look for those tasks on your calendar or to do list that get repeatedly pushed back and rolled over. These tend to be tasks that require certain types of resources — skills, states of mind, tools, blocks of time, or the presence of others — that are in short supply. If your personal constraint is dedicated focus time, for example, then tasks that require such time will accumulate and get delayed, an experience familiar to many.

At the team level, a full column on a kanban board where notecards are slowing down and piling up is a pretty clear indicator that there is a constraint at that step. Team task management software (like Jira) can track the cycle time of each step — the average amount of time tasks spend in that column before moving on. The constraint in the flow of work will be the step with the longest average cycle time.

Third, ask people. Using the visual measures and data collection from the previous two steps as a reference point, simply ask your people: what is the resource you are most often waiting on? (tip: it helps to use the term “most scarce resource” instead of “bottleneck” to avoid bruised feelings)

At what point in the product development pipeline are there most likely to be “quality cycles” — back-and-forths and rework. Often blamed on “uncertainty” or treated as “iterations,” such cycles represent work moving backward through the system, and are a ripe target for standardization and process improvement.

What you are looking for with these questions are the recurring problems that are slowing down or blocking people from moving forward, causing them to start new tasks “in the meantime” and thereby making WIP explode. Common issues include needing information or a decision from another department, reviews or approvals from management, and answers to questions from internal stakeholders.

Fourth, look for constraining policies and rules. It is tempting in the initial surge of constraint-hunting excitement to immediately tackle what looks like the “biggest and scariest” problem. It seems logical that the “squeakiest wheel” that everyone complains about must offer the biggest gains.

But this is usually a mistake. Remember from the previous post that the whole point of focusing on the constraint is not to launch a massive, all-encompassing overhaul project. Instead we want to start with small, local improvements and rely on the feedback loops of the system to magnify our efforts before doubling down.

It’s interesting to note that, even in the days of manufacturing, Goldratt said that the most restrictive and damaging constraint in an organization was almost always a “soft constraint” like a policy or rule, not a hard constraint like a machine or the design of a work area. We saw in episode #105 how an innocuous-seeming policy — to provide time estimates within 48 hours — led to a software engineering team wasting fully 40% of its capacity.

Being immaterial and abstract, policies can spring up in an instant, at the word of a supervisor or the stroke of a pen. They can even arise accidentally, from a misinterpreted word or glance of disapproval. Abstract rules are not subject to physical limits or counter-pressures — a freakishly dysfunctional machine would quickly collapse under the laws of physics, while a freakishly dysfunctional policy might warp the behavior of employees for years before anyone realizes what is happening. It is harder to point out the damaging effects of such policies, because they exist only in the minds of people.

The good news is, their immateriality also means that constraining policies and rules are the easiest things to change, and have the most immediate effects, because they can also disappear in an instant.

Fifth, perform experiments. With the previous steps in place, you’re now ready to perform some experiments. You have in hand a means of measuring changes to throughput (visual work-in-progress and performance data) as well as an initial intuition for where the constraint may lie (through interviews with employees and sensitivity to rules and policies).

The basic one is a concurrency experiment: make a list of all active projects in the company or department, and cross off half of them, strictly prohibiting any work on the inactive projects until further notice.

As WIP drops, the least constrained work centers will start to run out of things to do. This is a pivotal moment — you have to avoid the temptation to either “load them up” with new tasks, or fire them as “excess capacity.”

As unconstrained work centers hold off on starting new projects, they will start sending less work to the constraint, causing throughput to go up. This is the lightbulb moment — when everyone works less, and the company as a result produces more. It is not difficult at this point to convince everyone that their job is to do whatever it takes to maximize the constraint’s productivity, instead of working as many hours as possible.

Case study: see Tony Grout and Chris Matts talk about their application of TOC at large scale at Skype (2,000 developers across 10 locations). They found that identifying the constraint in the organization was the single most important step, because it made the problem visible to everyone.

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.