In Theory of Constraints we follow a process to improve. First we decide "what to change". To do this, of course, we need to agree on the problem(s). Once we have consensus on the problem we then work on the solution or "what to change to". And after that, we decide "how to cause the change".
It all sounds very straight forward and logical and it is. This process does work, but at times it can prove to be challenging -- especially when we don’t take enough time to agree on the problem. So Brad and I are especially vigilant about that. Because there is really no point to moving into discussing the possible solutions unless and until we have agreement on the problem. Every time we’ve pushed ahead too fast we always have to go back and get agreement on the problem.
This is particularly true when we are talking about problems that the Theory of Constraints (TOC) logistical solutions will solve. So Brad coined the expression “we are going to go slow so that we can go fast”. That approach has helped us to get better, faster results with clients. Then we teach our clients to do this each time a challenge, problem, or opportunity presents itself. And, with a little coaching and guidance, they also get very good at this.
Then we move to agreeing on "what to change to". Now, you would think this should be pretty straightforward once we’ve agreed on the problem, but we have found it’s not that easy. Why?
- There can be multiple solutions that would work or we think there are multiple solutions that could work.
- People are only comfortable with solutions which they are familiar with and have intuition around.
- We don’t know what we don’t know.
- The Theory of Constraints solutions are often counterintuitive, the opposite of what most people do now, and most people have no familiarity or intuition around them.
So you can see, if the solution is to implement our Velocity Scheduling System for scheduling job shops (
based on Goldratt’s Theory of Constraints and Simplified Drum Buffer Rope) we may get some push back (aka You want me to do WHAT?) even AFTER we have successfully agreed on the problem.
That is the highest compliment someone can pay and we have clearly agreed on the problem. Then those same companies argue and resist every step of the way during implementation. This was super frustrating until we learned how to get them to agree on "what to change to".
So how do we get the key people in a highly custom job shop to do the totally counter intuitive steps of the Velocity Scheduling System? Well, instead of pushing the steps of a system they don’t understand, don’t agree with, and have no intuition around - we build on a previous success.
... next week I'll take you through how we do that.
What's your experience with getting buy in? Please tell me in the comments of this post.
No comments:
Post a Comment