Constraints

Eliyahu Goldratt put together his “Theory of Constraints” and presented its principles in his book The Goal. He explained that systems generally have a single (sometimes more) bottleneck that limits, or constrains, production.

In a more general sense, a constraint is anything that prevents you from accomplishing something that you want to do. Constraints come in a variety of forms. Laws (like speed limits), regulations (like those that OSHA administers), and customer preferences are all constraints.

In most organizations, there are lots of limiting factors. Often, they are not real, but rather perceived or self-fulfilling constraints. See if any of these sound familiar:

• A software package is taboo to talk about in a project. The company spent $3 million implementing it, and its champion wants to make sure it is used.
• The boss does not like (fill in the blank). You can’t use it.
• HR won’t let us try that.
• Our customers won’t go for that.
• The (fill in the blank) is too expensive.
• We are on a capital spending freeze.
• The IT group is swamped—we won’t get any support from them.
• If it doesn’t payback its cost in 3 years, it won’t get approved.

These, and many other constraints, are not real. They are the results of how we have set up our processes, policies, etc. THEY ARE NOT REAL! Very few constraints truly exist. Gravity is a real constraint. A shortage of space is not. You may have trouble fitting things into a facility in the current configuration, or you may not yet own/lease a new building, but it is an artificial constraint. It is established by choices you and your company have made, not by the way the world is. That being said, whether the origin is real or not, you still have to deal with the limitation. Just make sure you recognize that they are not written in stone.

Don’t confuse constraints with boundaries. In some projects, you may choose to only work on the last three stations of an assembly line. This is a frequent means of reducing the scope to a manageable level—not because the rest of the line is off limits.

When someone brings up a constraint, see if you can figure out its heritage. Where did the constraint come from? Who has the authority to change it? Who is affected by it? Understanding your constraints will help you loosen them up when you ask good, logic filled questions. Keep in mind, though, that logic will not always carry the day. Sometimes emotion trumps logic. Keep an eye out for those cases.

When you get bogged down trying to overcome a constraint, it might pay to treat the constraint as real so you can get moving on a project. Don’t do this if it violates a major principle. But if it goes along with the better, not perfect philosophy, you might find that you can more than offset the limitations of the constraint.

This is a workaround, and only recommended if you start feeling like you are spinning your tires. Sometimes, getting momentum, and making some improvement is better than jousting with a constraint that you might not be able to break easily.

Eventually, though, if you erode all of the perceived “supporting evidence” through improvement projects, you can remove a constraint indirectly. As everything around the constraint improves, it becomes more and more obvious that something has to be done about it. The rationale that prevented you from going after it before comes tumbling down.