Goldratt's Theory of Constraints (Part 2 of 3)

There are three basic principles of Goldratt's Theory of Constraints, and they are treated as axioms, which means that they are supposed to be true, but there is no proof to that end.

• Convergence

This first principle is also referred to as “inherent simplicity.” It states that the more complex a system is to describe, the simpler it is to manage. This works off the idea that the more inter-connected the pieces of a system are, the fewer areas you need to manag to impact the whole system. You can think of this in terms of a chain of dominos. Only one domino need be knocked over to knock down the entire chain. A secondary part of this principle is the assumption that every organization has at least one constraint relative to its process at any given point in time, for if it did not, it would be running at ultimate performance and reach all of its goals. The more complex and interconnected the organization is, then, the lower the number of constraints it will have. This is good news for project managers!

• Consistency

This second principle is also known as “there are no conflicts in nature.” It simply states that if two interpretations of a natural phenomenon are in conflict, then either one or both of them must be wrong. In other words, they cannot both be correct. When an organization has a common goal with two parts of the organization in conflict (or facing a dilemma), the reasoning that led to the conflict must contain at least one flawed assumption. The fun, of course, is determining which is the flawed part and making the necessary changes.

• Respect

This third principle could also be called “people are not stupid.” It simply states that even when people do things that “seem” to be stupid, they have some reason for that behavior. In other words, neither employees or managers in an organization are inherently bad. This principle bridges the gap between process and humanity, which is the place where all successful project managers must function.

The processes used in TOC, also called “thinking processes,” are a set of tools used to help managers walk through the steps in determining where the constraints lie. For project managers, then, these are the steps by which they initiate and implement a project. These steps include asking strategic questions, focusing on which steps to take next, achieving process by-in, and analyzing the effect-cause-effect relationship. The five processes are as follows:

• Gain agreement on the problem
• Gain agreement on the direction for a solution
• Gain agreement that the solution will solve the problem
• Agree to overcome any potential negative ramifications
• Agree to overcome any obstacles to implementation

Project managers sometimes refer to these processes as working through layers of resistance to change. In simple terms, the purpose of the five thinking processes is to help one answer four questions essential to achieving focused improvement:

1. What needs to be changed?
2. What does it need to change to?
3. How can we make this change happen?
4. How can we maintain this change?

As stated before, this process needs to be ongoing. So what does this mean in practical terms? The steps to implementing an effective process of improvement begin with articulating the goal of the organization. This could be something as simple as “make money now and in the future.” Everyone needs to be on the same page at the beginning, though, in order to move to the next step in the process.

Once everyone is united in terms of the goal, the next logical step is to identify exactly what it is that keeps the organization from getting what it wants. In other words, you may ask, “What is it that keeps us from achieving our goal?”

The next step is sometimes called “exploiting the constraint.” This may sound odd, but it really just means getting the most out of the constraint resource. As a group, you need to make sure the constraint always has work to do. In other words, don’t let the constraint fall idle because of a lack of resources. The idea is to make sure there is always enough work, but no more. For example, if developers are the constraint, make sure that they don’t fall idle because the analysts/designers/customers can’t provide them with enough work. The second part of exploiting the constraint is to make sure the constraint is doing only what it is designed to do, and not something that it should not be doing. In other words, cut all unnecessary, non-productive work from the constraint.

Next, you must subordinate all other processes to exploiting the constraint. In other words, align all other processes to achieve the resource of the constraint. This may involve what is called “elevating the constraint.” It is sometimes necessary to permanently increase the capacity of the constraint—“buy more.” This is why you need to have everyone on board at the beginning. For some, this process will not always be painless.

Finally, you need to constantly be re-evaluating. If, as a result of these steps you’ve taken, the constraint has moved, you need to go back to step one. Realizing from the outset that this process is a continual one and will help the group come to terms with the reality of what this means at a later date.