Continuous improvement (often called continual improvement, more on that later) is commonly misperceived as being a process intended to move the needle in a positive way regarding a system, product or service. The misperception is regarding the need to continuously "IMPROVE" a system. This suggests that an organization could expect to see a solid, and incremental, increase in the satisfaction customers have with a system.
Most of the organizations we've worked with have an overly optimistic perspective of what the implementation of an "improvement" will do to the user experience of a system. Even the best planned optimizations will rarely have a path that looks like this.
Continuous improvement (CI) very rarely looks like this, and if it does, it usually means it's being done wrong. CI is a very specific type of improvement; everything that can be considered an "improvement" shouldn't make it through to implementation if continuous improvement is being managed correctly.
There are a few important aspects of CI I'd like to share:
- Improvements should help people better achieve defined outcomes; improvements that don't do this, should be deprioritized and should only be considered when/if they become relevant to the evolving outcomes the system supports.
- Improvements should provide continuity to the customer experience and not be disruptive. Customers should not have to re-learn how to use the system as the result of an improvement.
- Improvements should be systematic; at Hostile Sheep we prefer to use the Plan-Do-Check-Act (PDCA) method of iterative improvement, where CI activities help us recognize opportunities to improve, then we implement a change using a small-scale experiment, that experiment is analyzed before action is rolled out to the greater system.
- Improvement should focus on three pillars: (1) customer satisfaction, (2) system quality, and (3) operational efficiency.
That said, continuous improvement tends to be a non-linear process.
Even with extensive planning and testing, improvements don't always have the expected impact on complex systems for all users. In fact, we've come to believe that if an improvement provides a linear improvement to a system, it's a table-stakes improvement and didn't really need CI activities to uncover and validate it. This non-linear path to improvement is the most common path that we see when CI is implemented in an effective way.
A more realistic perspective is that the introduction of "improvements" will destabilize the system for some; regardless of how well the update is planned or how well the design adheres to continuity principles. This destabilizing aspect of continuous improvement is unavoidable... and if you are able to completely avoid it, it's likely you're not making large-enough bets. Continuous improvement is largely about improving systems in a safe and low-risk way, however, if you're not seeing fluctuations after implementing improvements you may be filtering out improvements that can have a significantly positive impact on your ICP (ideal customer) experience in exchange for not destabilizing the experience for any customer.
We often remind our customers that we've worked really hard to help them build resilient systems that are capable of self-stabilization. Continuous improvement may put that resiliency to the test, but the continuous improvement process itself supports a resilient system. It's important to remember that CI relies on "always on" activities such as experimentation and feedback loops; thus, any critical instability will self-correct over time.
One final comment I'll make is regarding nomenclature; at Hostile Sheep we prefer to use the term "continuous" when referring to CI instead of the term "continual". In many aspects, they mean the same thing. However, "continual" simply suggests that CI is a never-ending process (which is true), while "continuous" implies that the process is always happening. In the world of digital system design, this is true; CI actually does mean that the process of improving a system is continuously occurring through several CI activities such as experimentation, feedback loops and automation.