Theory of constraints – or why you may be wasting your time

A few months ago I attended an excellent session at the LAST conference given by a guy called James Ross on Theory of Constraints (the session abstracts here: http://lanyrd.com/2012/last-conf/swycf/).

Theory of Constraints (TOC) was developed by a guy called Eliyahu Goldratt who sets out the idea in a book called the Goal (http://www.amazon.com/The-Goal-Process-Ongoing-Improvement/dp/0884271951/ref=sr_1_1?ie=UTF8&qid=1347002336&sr=8-1&keywords=the+goal).

It’s an unusual book in that the idea is presented by telling the story of a plant manager of a failing manufacturing plant. The main character is given 3 months by his bosses to turn the plant around and the book takes the reader through how he achieves this and the problems he encounters along the way.

The book is well worth a read (if only for its unique fiction style!) but the short version is that a system is limited by its slowest part.

An example – well let’s say we have a very simple system made up of 3 processes (imaginatively called A,B,C) that can each produce an arbitrary number of widgets (shown in brackets next to the process name) in one equally arbitrary time segment. Each process depends on the output of the predecessor:

Process A (5) -> Process -> B (5) -> Process C (2)

What’s the maximum output such a system can have?

Well despite A & B being able to produce 5 widgets the maximum output this system can ever have is 2 as Process C can only ever produce 2 widgets.

This means that if you are putting a lot of effort into improving Process A you are wasting your time as the maximal output will only ever be 2. If we want to improve the output of the system we should concentrate our efforts on Process C.

Of course a real system will also have fluctuations e.g. maybe there is a minor cockup, someone is sick so a more realistic output maybe more like:

Process A (3-5) -> Process -> B (3-5) -> Process C (1-2)

In our example we want to make sure that Process C is running as fast as possible otherwise everything slows down. Thus we might employee additional staff in Process C as a buffer as even if they don’t do anything 50% of the time we don’t want this bit of the system slowing down.

At first this all seems a pretty common sense idea but the outcome of this is that if you are trying to improve something that isn’t a bottleneck in the system any improvements you do get will be very limited (although I guess improvements could have an influence on other areas e.g. people may pick up ideas etc).

Even through the books examples are focussed on manufacturing it’s certainly not just applicable to factory settings. For example the book has an example of kids going on a hike where the unfit tubby kid limits the speed of the others (and im ignoring for now the best way to optimize flow in this scenario).

I believe this example has implications for us as developers and consultants as if we are trying to improve a non-bottleneck part of a system we really aren’t going to make much if any of a difference.

Instead we should be looking at what we can do to alleviate any bottle necks. Maybe this can be done by restructuring the process, hiring more people (even if they end up doing nothing half the time as the bottle neck process is constraining your entire output) or even outsourcing the work.

In software development maybe the bottleneck in your environment is getting requirements, maybe its producing a build, maybe its the testing department.

So in conclusion its important to identify potential bottle necks within your system and focus efforts in these areas.

Advertisements