When Continuous Improvements Fail

Photo by ThunderChild tm

Here’s the theory:

  • Big improvements require big risks. Small changes require small risk.
  • Conversely, If you only take small risks, you can only expect small improvements.
  • As an aside: People always look for “deals” (where a small risk gives you a big improvement), but like the rest of the world, real deals are far and few between.

Now in terms of continuous improvements, small risks with small improvements are ok as you only need to show improvement – any improvement. Small changes are sort of the point of CI. But in terms of long term sustainability, small changes only work so long. This is best illustrated by an analogy:

You own a pay phone, and you want to continuously improve it. So you replace the buttons and you polish the black handset till it shines. Maybe you even outfit it with a credit card reader. You have continuously built a better pay phone.

But what was missed in the exercise is that there are 3 billion cell phones on the planet. How do you continuously improve a pay phone into a cell phone? You can’t! At least not with small incremental improvements. At some point, the pay phone has to go wireless. This is a huge change. It affects everything in the pay phone world: sales, support, infrastructure, equipment design, etc.

So to add to the theory:

  • Small improvements, if they are not occasionally broken up by big improvements, can become equivalent to no improvement at all.
  • In terms of risk: If you never take big risks, you may find your continuous improvements hit a wall  and cease to deliver competitive advantage.

By “big risk”, I am not specifying an exact size. Only that it is large enough to move from a pay phone to a cell phone in your own industry or environment.

And I am not saying that you can’t make significant improvements incrementally – you can and companies do every day. But you should step through it carefully – you don’t want to discover cell phones have taken over the world, and you’re still shinning up your very pretty pay phone.

The solution to this problem is to not use Continuous Improvements exclusively, or with too narrow of a focus. You could also succeed by running parallel process to investigate/prototype/etc a cell phone while continuing to incrementally improve the pay phone. At a later date you then have the ability to sustain your business by choosing to discontinue one in favor of the other. There is a fine line here because simply trying something different could be constituted as a big risk in your environment. Neverless, it is about perspective – and here you would not continuously improve your pay phone, but you would continuously improve your business.

Tags:

Comments are closed.