A Guide to Implementing the Theory of
How Much Time Is Necessary?
There are some very important issues that revolve around the expectation of the necessary time required to implement an application in Theory of Constraints. Let’s have a look at these;
(1) If you expect an implementation to take a long time and cost a great deal – it will.
(2) If you expect an implementation to take a short time and cost a little – it will.
Your expectations will determine how long it takes to have an effective implementation.
We are conditioned by experience (and maybe management consultants) to expect that our complex problems will require complex and expensive solutions. And besides, if the solution was so simple we would have already implemented it – right?
We naturally expect complex solutions to take a long time (and management consultants to cost a lot of money), in part because we tend to value things on basis of the effort put in rather than the result that is obtained out of the effort. This seems to be part of the reductionist/local optima heritage that we must deal with – “please break down your budget into hours spent on this and hours spend on that.” We should really be asking how quickly – how many weeks – will it take to pay back the investment?
Think for instance of the time required for business process reengineering (BPR) – and did it work? Or the time required for a complete activity based costing analysis (ABC) – it cost an arm and a leg but did profit go up? Or the time required implementing total quality management (TQM) or total productive maintenance (TPM). How about the time required to implement the balanced scorecard (BSC) or one of the ISO business standards such as ISO 1400.
We are not talking about weeks, we are talking about years!
Why is Theory of constraints so rapid while other methods take so long? Well there are two reasons for this. Firstly, Theory of Constraints is rapid because it addresses a dynamic complexity problem. We learn how to isolated the few critical dimensions and address them explicitly – dependency, variation, and the role of the constraint. Thus an apparently complex problem can be resolved with a simple solution. Moreover, the solutions are designed to be transferred, the education is built into the solution, and the organizational knowledge within constraint practitioners ensures that improvements in implementation methodology are quickly disseminated.
The second reason is that the other methodologies mentioned, and including MRPII, all focus on detail complexity. They attempt to address everything, everywhere, all of the time; on the basis that whole of the system is the sum of the parts. If we do this then we miss the true leverage points completely or we minimize our focus on them as we try to balance our focus on all the other “important” things at the same time. Detail complexity methods also require accuracy of data, rather than robustness of data, and so considerable time and effort goes into data collection and reporting.
Robert Newbold (1) has a cloud that expresses the dichotomy between having simple solutions and complex solutions. It looks like this;
That is to say; in order to develop a good solution, the solution must be understood. And in order for the solution to be understood it must be simple. On the other hand in order to develop a good solution, the solution must be acceptable. And in order for the solution to be acceptable it must be complex. Clearly having a complex solution and having a simple solution are direct conflict with one another.
And what is his trim? Let’s have a look.
So, conceptually simple solutions that only address the necessary detail (not every detail) are the requirement for success. Theory of Constraints provides this.
What sort of durations can we expect?
Well, from direct experience, how about increasing output by 25% in 8 weeks in a system that was “capacity constrained,” and further increasing the output to 45% by the 8th month. Imagine what that did to the profitability. Or how about reducing work-in-process by 2/3rds in 12 weeks and stabilising it there? Imagine what that could do inventory costs and lead times. The first example had a staff of 40 people on the floor; the second example had a staff of 400.
The size of the implementation is not important. However, the degree of understanding and alignment is important. Theory of Constraints can be a very rapid.
If you are really between a rock and a hard place and the issue isn’t one of “do we have to do it so quickly” to one of “we have no choice but to do it very quickly,” then we should also look at utilizing Critical Chain.
Critical Chain is a Theory of Constraints logistical solution for project management. Like drum-buffer-rope for manufacturing, critical chain “rolls-up” all the local safety into strategically placed global buffers. The net result is that projects can be completed on-time and in full in about ½ of the normal duration (2, 3). If time is of the essence, what would you do – critical chain or traditional critical path?
Think about this a little more. Projects and manufacturing are really not that different at all. One; manufacturing, deals in multiple units of product per unit of time. The other; project management, deals in multiple units of time per unit of product – the project. In manufacturing we are trying to maximize the number of units and we do that by protecting the constraint, the slowest step. In projects we are trying to minimize the units of time and we do that by protecting the constraint, the longest dependent path in project.
Theory of Constraints implementations are very rapid compared to other approaches for a number of reasons; they address dynamic complexity – the few critical leverage points, they are results or outcome oriented, they are designed from the very beginning to be transferable, they address the alignment issues and have the toolsets to deal with the technical and organizational factors that will occur along the way. And last but not least, its all been done before by many different people in many different places.
(1) Newbold, R. C., (1998) Project management in the fast lane: applying the theory of constraints, pp 233-234.
(2) Goldratt, E. M., (1997) Critical chain. The North River Press, 246 pp.
(3) Newbold, R. C., (1998) Project management in the fast lane: applying the theory of constraints. St. Lucie Press, 284 pp.
This Webpage Copyright © 2003-2009 by Dr K. J. Youngman