Ashton Fourie
Very often businesses incur the cost of elevating a constraint, when they could have, for a much lower cost simply exploited the constraint better.
The five focusing steps
In constraint management there are five focusing steps:
1. Identify the constraint
2. Exploit the constraint
3. Subordinate everything to the decisions made in the previous step
4. Elevate the constraint (if it is still the constraint, otherwise go back to step 1)
5. Once the constraint has been elevated to the point where it is no longer the constraint, go back to step 1.
The intuitive response to finding a constraint in a business is step 4.
For example if you are short on programmers, it would seem that the thing to do is to hire more programmers. This is both difficult (because good programmers are scarce) and expensive (although not as expensive as most programmers wish for it to be).
Don’t spend money before you know what you are wasting
An alternative approach is to take a little bit of time first defining very clearly what is considered productive work for your programmers. Anything that can be done by anyone with less skills would not be something that is considered being productive, for your programmers.
Once you’ve defined this clearly, spend some time analyzing what your programmers are currently spending their time on. There is a good chance that, if you have not done this before, or have not done this recently, you will find that quite a lot of time is spent by your programmers doing non-programmer stuff like admin, attending hour long meetings of which a ten minute summary would have sufficed for the information they needed. Chances are they are doing admin work that an assistant could do, but your budget does not allow programmers to have admin assistants. (This is despite the fact that your programmers are generating throughput, and by not giving them an assistant you are going to end up hiring a much more expensive programmer because you are short on programming capacity)
Chances are the waste is also frustrating and annoying
You will probably also find that many of these activities are not enjoyable to your programmers, and that they would prefer not doing these, but feel obliged to do these.
Such an analysis might take a bit of time of someone who knows how to do this, but the outcome could be a few decisions such as changing the way meeting output reaches programmers and maybe appointing an assistant or two (at a much lower cost than appointing more programmers).
The programmer is just an example, but it’s very typical of what happens with our technical resources. Whether you are engineering, consulting, programming, teaching, welding, or designing toilet seats – don’t start elevating your constraint before you are sure that you are using it as effectively as possible.
Can you think of a place in your business where this applies? And what do you think you should do about it?
Please leave your responses in the comments.
To your success
Ashton