Theory of Constraints 107: Identifying the Constraint
A series of 5-minute posts on applying principles of flow to knowledge work
In the previous post, I introduced the Five Focusing Steps, used to improve any system of value creation:
- Identify the constraint
- Optimize the constraint
- Subordinate the non-constraints
- Elevate the constraint
- 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? 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 cross-check, 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 product development are there most likely to be “quality cycles” — back-and-forths, quality checks, or 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 dependencies that are slowing down or blocking people, causing them to start new tasks “in the meantime” and thereby making WIP explode. Common ones include information or decisions from a client, reviews or approvals from management, and answers to questions from internal groups.
Fourth, look for constraining policies and rules. It is tempting in the initial surge of constraint-hunting excitement to 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 improvement project. Instead we want to rely on the dynamic feedback loops of the system to magnify our efforts, not fight against them.
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 post #105 how an innocuous-seeming policy — to provide time estimates within 24 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 an email memo. They can even arise accidentally, from a misinterpreted word or glance of disapproval. Abstract constructs 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 company 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 live 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 resources will start to run out of things to do. This is a pivotal moment — you have to avoid the temptation to either “load up” these resources with new tasks, or fire them as “excess capacity.”
As unconstrained resources 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 nearly 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.