In the previous episode, I described how to go about identifying the constraint in a knowledge work organization. The next step, #2 in the Five Focusing Steps, is to optimize that constraint:
- Identify the constraint
- Optimize the constraint
- Subordinate the non-constraints
- Elevate the constraint
- Return to step 1
Once you understand that every minute lost at the constraint is a minute lost for the entire company, a whole range of investments that may have seemed too time-consuming, expensive, or risky suddenly make sense. In fact, they become your #1 priority.
Here’s a checklist of questions to get you thinking:
Buffers: how can you pre-prepare and pre-package units of work, to make sure the constraint never runs out of work and goes idle?
As we saw in previous posts, this means that the person or team before the constraint must have excess capacity, to be able to build up a buffer (or queue) of work-in-progress. All the upstream departments should spend time carefully packaging their work for easy “consumption” by the constraint.
Quality checks: how can you check the quality of work before it goes through the constraint, to be sure that it doesn’t waste time on tasks that will need to be redone?
One option is using a light-weight prototype to check that the product features really make sense, before spending too much engineering time on them. Or having the editor check the copy before sending it to the web designer, to avoid time-consuming and error-prone HTML edits.
Continuous operation: how can you make sure the constraint is running as much of the available time as possible?
This could mean establishing policies that encourage focused work, as when Uber created a policy that anyone with headphones on was not to be disturbed. It could also take the form of catered lunches, company shuttles, or no-meeting days. Anything that saves the employees’ time potentially increases the number of hours they can contribute to the bottleneck.
Preventative maintenance: what actions could you take in advance to reduce the chance of a breakdown that might interrupt the constraint?
This includes physical maintenance, updating software, checking servers, and having backup power or wifi. But in knowledge work, it also means preventing emotional and health breakdowns — offering benefits and incentives that encourage employees to exercise, eat well, get enough sleep, take care of their health, and even engage in volunteering and other activities that connect them with a higher purpose.
Offloading: which tasks that the constraint is currently performing could be performed by other departments?
It is common to think of the constraint as a person or team, but in reality it is usually a skill or capability. A team of 10 software developers may only have one person who knows a particular coding language, or who understands the overall system architecture. If another developer can also perform this task — even if they do so FAR less efficiently — it is worth offloading that task from the constraint. As long as they are able to take on even 1% of the work of the constraint, that investment begins to pay off at the rate of the whole company’s throughput.
5S: how could the constraint’s work environment be organized to promote efficiency, effectiveness, and order?
Borrowed from Just-In-Time manufacturing, 5S refers to five categories of activities: Sort, Set in Order, Shine, Standardize, and Sustain. For knowledge work, this could include everything from clean, visually pleasing offices with minimal clutter; to equipping employees with late-model computers and user-friendly software; to standardizing how digital files are named, stored, and updated.
Andon: how can we make it easier and faster for constrained resources to surface and solve problems?
Do engineers have to submit tickets to a vast and unresponsive Complaint Management System? Problems and obstacles are inevitable, so might as well get good at fixing them: rapid-response IT teams, dispensing free computer peripherals via vending machines, displaying constraint metrics via real-time dashboards, and rewarding employees for taking the time to report problems. Another technique borrowed from JIT, Andon is really about creating a culture that treats problems as “jewels to be treasured,” not mistakes to be hidden or blamed on someone.
Let’s combine all the above into a tangible example. Assume the constraint in a software development team is a developer with a particular set of skills. How can she be fully optimized?
She can be protected from idleness by always having a pool of development tasks ready to be started (a buffer). She can be protected from interruptions by a company structure that minimizes the lines of communication, and from distractions by a quiet working environment (continuous operation). She can be further optimized by providing her with the best equipment and development tools available (5S and preventative maintenance). She can offload tasks like progress reporting and time-tracking to support staff, or to tools. The team can use mentorship, pair programming, retrospectives, and code reviews to make sure bugs in the code are found and resolved as quickly as possible, or even better, never introduced at all (andon). She can benefit from clearly articulated product requirements, to minimize the time she spends interpreting and clarifying them (quality checks).
Notice that none of the above implementation ideas is new. What the Theory of Constraints adds is a targeting and implementation system: where and how will improvements actually make a difference, and how can they be used together?
For another example, consider this case study of a hospital emergency room in Kentucky that used TOC to fix recurring problems and improve the number of patients it could serve.
The constraint was identified, after two rounds of surveys of the hospital staff, to be the availability of nurses. They had numerous responsibilities: preparing rooms for new patients to be admitted, attending to the front desk, taking dispositions, not to mention actually caring for patients. Because they had so many jobs, the nurses were often not available to discharge patients, who waited around and created backlogs at various points.
The solution they developed was to hire new staff dedicated to a simple, but time-consuming task: making the beds and preparing the rooms. This improved the throughput of the ER by freeing up nurses for more constrained tasks. It improved the nurses’ (and presumably doctors’ and patients’) morale, by allowing them to focus on higher-skill jobs that leveraged their training. Remarkably, this small change (along with a few others, like better standard operating procedures) resolved the majority of staff complaints collected in the survey.
The change doesn’t have to be big, expensive, or dramatic, but it does have to be in the right place. Ask yourself: are your efforts at improvement, whether in work or in life, optimizing your constraint?
If not, why bother?
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.
- POSTED IN: Flow