What is a Constraint? – Part 3 of 11

‘What if there was One Thing responsible for the majority of the bad things in your life and/or business? Would you see it? Would you recognize it even if it did not go boom, or have a flashing red light on top of it?’

I then mentioned that we would attempt to define a Constraint, that One Thing That Can Affect Everything in my next blog post.

Before we can identify our constraint(s), we must first understand what a constraint is, and that there is more than one type of constraint. In Eli Goldratt’s book, Theory of Constraints, he defines a constraint as anything that limits a system from achieving higher performance versus its goal.

I remember my first realization that there was a constraint in my cabinet manufacturing plant, and being excited about the possibilities of elevating or breaking that constraint. Once that constraint had been not only elevated, but broken, as with all constraint breaking processes, something else became the constraint, but this new constraint was very unlike the first constraint. My first Constraint was a physical Constraint, but this second Constraint was not tangible, you could not see it with your eyes, or hold it in your hand.

The first constraint identified in my cabinet manufacturing plant was the finish department, and with just the most rudimentary understanding of Theory of Constraints, that piles of inventory and/or work in process would be in front of the constraint, it was easy, easy, easy to identify. This second constraint, well it proved itself very elusive in the discovery process.

Sometimes we are so immersed in the physical world that we can’t see anything past the physical realities around us (the proverbial not being able to see the forest because of the trees). But there are other things at work other than just physical machines, processes and people. So now that we have defined what a Constraint is, and said that there are two types of Constraints, lets spend some time talking about that second category of constraints.

If there is one absolute certainty in business (if you do very much business at all), it is that you and/or your people will make mistakes. There will be hick-ups, bumps in the road, mistakes a plenty, and those mistakes are almost always costly. With our keen understanding of the costs of mistakes, we attempt to prevent mistakes, and not always after considerable thought and planning, but many times as a knee jerk reaction to the mistake.

The form these corrections typically take is almost always a new and/or improved policy, a policy that is supposed to prevent that mistake from ever happening again. Now don’t get me wrong, not all policies are the result of a mistake, many are simply our attempt to have a standard way of doing things, or an efficient way of doing things, but in any case, we all have policies.

Policies themselves can take several forms. Some policies are written policies or procedures, others are unspoken policies (although you are expected to know they exist). One of the biggest surprises to me when I started digging into Theory of Constraints, was that there was such a thing as a policy constraint. For me, that second constraint that was so elusive was just that, a policy constraint. It was not a policy put in place based on a reaction to some mistake, or a policy that was in place for any particular reason at all, other than my own preconceived ideas based on life experience and advice.

You see, my second constraint was based purely on my decision to never deliver less than the entire house of cabinetry (the classic policy constraint, based on nothing more than a decision). My cabinet manufacturing life experience had told me that you can’t make money making multiple trips to the job-site. As a team, we had worked hard at reducing our batch sizes, we believed that single piece flow was the ultimate manufacturing system, but our beliefs did not translate into actions that aligned with those beliefs as it related to delivery.

I had all the clues that delivery was the constraint (WIP in front of the delivery trailer), but could not see the forest for the trees again. It was not a matter of not enough delivery trailers, we only used ours once a week at the most. When we sat down as a team to analyse the situation, it simply did not add up. The WIP in front of the delivery trailer (the hardware area) said that delivery was the constraint, but that we only used our trailer once, and at most twice a week said differently. How can something that is underutilized be a physical constraint? A great question.

The answer did not come easily, but it did come through a series of meetings to discuss the problem. As with all simple problems, once we got it, we all had a hard time understanding why it took so long to see the forest in spite of the trees. The delivery trailer was not a physical constraint, the delivery process was a policy constraint. Whether the policy was based on batch mentality, or inertia from a time when we did much smaller projects really did not matter, what mattered is we needed to CHANGE THE POLICY.

The beauty of a policy constraint is that it requires absolutely zero resources to elevate and/or break, it simply requires someone to change their mind. In this case, that someone was me. Next time we will look at the implications and the results of me changing my mind, and thus changing the policy that was our constraint. I promise I will get to identifying constraints, but the thought process that is required needs to be fertilized a little with these precursors to identification.

To make sure you won’t miss a crucial part of this discussion, enter your email address in the Subscribe to Blog via Email field on the right, and each time I add to this discussion, you will automatically be notified. Oh, and you won’t hurt my feelings if, depending on where you are seeing this, you Share, Like, Plus or Re-tweet it (there are buttons somewhere on the page to help you with that).

May the Lord bless the work of your hands, heart and mind.