In this episode, we revisit Theory of Constraints, an approach to improving organizational performance by accelerating delivery. Author Clarke Ching shares his FOCCCUS Formula to address the system’s bottleneck. Show Notes

In every process or value delivery system, there’s one constraint (bottleneck) that limits the flow of value of the entire system. If you want to deliver faster, you must identify and address the bottleneck. To improve the flow of value, we can apply the Theory of Constraints, a process improvement methodology that focuses on addressing the bottleneck.

Eli Goldratt’s famous book, The Goal, introduced readers to the Theory of Constraints and how to apply Goldratt’s Five Focusing Steps to address your constraint. However, many people are unaware of or confused by the Five Focusing Steps.

In you’re confused about how to address the bottleneck in your process, you can use Clarke Ching’s FOCCCUS Formula instead. FOCCCUS is an acronym that stands for the steps you can take to address the constraint and improve the system.

FOCCCUS

The first step in the FOCCCUS Formula is “F” for find the bottleneck. You can’t improve the bottleneck if you don’t know where it is. To find the bottleneck, look for work piling up of long queues in front of a step in the process. Work typically builds up in front of the constraint.

Once you find the bottleneck, the next step is “O” for optimize. You want to optimize the bottleneck so that it can get work done faster. You can do this by making sure the work that goes to the bottleneck resource is ready (has everything they need) and the bottleneck is focused only on value added work.

After you optimize, the next step is collaborate. Collaboration helps the bottleneck deliver faster because non-bottleneck resources may be able to off-load work that the bottleneck is doing.

In addition to collaboration, you can apply the second “C”, which is coordinate. This step involves finding ways to coordinate activities of both bottleneck and non-bottleneck resources to optimize delivery. This can include rearranging process steps or changing the timing of certain pieces of work to smooth the flow.

The third “C” in the FOCCCUS Formula is curate. When you curate, you decide what to put in a limited amount of space. Essentially, you prioritize work to maximize the value that can be delivered.

The “U” in the FOCCCUS Formula stands for upgrade. This can mean buying faster equipment, holding training to improve skills associated with the constrained task, or hiring more people. Upgrading can be expensive and you should only upgrade after completing the other steps.

The final step is “S”, which stands for start again. The FOCCCUS Formula is a continuous process. After you complete each step, you should validate that the bottleneck hasn’t moved. If it has, continuing to the next step with the same bottleneck won’t improve the flow of value through the system.

Check each time to ensure that you know where the bottleneck is and start with the simplest, cheapest intervention.

Listen to the full episode to understand how to use the FOCCCUS Formula to improve your process and accelerate value delivery.

Clarke Ching

Clarke has been powered by the Theory of Constraints for over 20 years and Agile since 2003. He wrote Rolling Rocks Downhill (the Agile business novel that never mentions Agile) and The Bottleneck Rules (which was featured in The Guardian newspaper, and was briefly the #2 best-selling leadership book on Amazon.com, just behind Steven Covey).

Latest Episodes

• MBA228: Software Development PearlsKarl Wiegers shares his lessons on requirements, project management, design, quality and more. Karl’s advice can make you significantly better at what you do. Show Notes Karl Wiegers started programming in 1970 and has collected 60 lessons he has learned in several areas of software development including requirements, design, project management, culture, teamwork, quality, and [...]
• MBA227: The Minimum Viable BusinessIan Reynolds discusses how to discover the right solutions for your customers and then deliver them quickly.
• MBALC: Elon Musk’s 5-Step Design ProcessIn this lightning cast, we explore the 5-step design process Elon Musk uses for SpaceX to i...

Karl Wiegers shares his lessons on requirements, project management, design, quality and more. Karl’s advice can make you significantly better at what you do.

Show Notes

Karl Wiegers started programming in 1970 and has collected 60 lessons he has learned in several areas of software development including requirements, design, project management, culture, teamwork, quality, and process improvement. Each of these lessons bring insights that can help you to and your organization to become significantly better at creating high quality, valuable solutions to your customers.

The Need to Iterate

Almost everything we do takes more than a single shot and design is a good example. The first lesson in the design category of Karl’s book is “design demands iteration”. There’s always more than one design solution for a software problem and seldom a single best solution.

The first design approach you come up with is unlikely to be the best option. A good rule of thumb is that you’re not done with design until you’ve created at least three designs, discard them, and take the best ideas from those three and build something better.

The same holds true for requirements. It will take a few iterations to get it right. These are cyclical things that you have to plan in your project management approach. You’re going to have to build in some reviews, get some feedback, prototype, and do some modeling to make sure we’re on the right track.

Icebergs are always larger than they first appear; that means that there’s going to be growth in the project. There’s going to be new information and new ideas that come along. You have to build in that growth and include contingency buffers into your plans. The bigger the project, the more unknowns and ambiguity and the more likely it is to change.

Understanding Stakeholders and Customers

Usage-centric development (as opposed to user-centric) is more likely to satisfy customer needs than product or feature-centered development. We shouldn’t care about features as much as you care about knowing what people need to do with the product. That’s the difference between the usage-centric approach and the product-centric approach.

That begins by understanding your stakeholders. Stakeholders are individuals, groups, or even systems who can shape or influence the direction of a project or who are affected by the project. To be successful, you need to identify your various user classes and identify who’s going to be the literal voice of the customer. Keep in mind that the customer isn’t always right, but they always have a point. Many times, the customer may ask for a solution, which may or may not be the right thing. To provide valuable solutions, we need to understand the underlying problem. If the solution they propose is the answer, what is the question?

Listen to the full episode for more lessons and advice on stakeholders, quality, applying what you’ve learned, and more.

Links Mentioned in this Episode

• Karl’s Personal Website – KarlWiegers.com
• ProcessImpact.com – Karl’s business and book information
• Information on Karl’s book, Software Development Pearls

Karl Wiegers

Karl Wiegers is an independent consultant, author, speaker, and thought leader in the project community. His books on software requirements are considered required reading for Business Analysts and Project Managers. As a consultant and trainer, Karl has worked with more than 100 companies and government organizations of all types, helping them improve the effectiveness and efficiency of their software development activities.

Thank you for listening to the program

To get more valuable content to enhance your skills and advance your career, you can subscribe on iTunes.

Also, reviews on iTunes are highly appreciated! I read each review and it helps keep me motivated to continue to bring you valuable content each week.

Popular Episodes