We have reached the final part of our blog series on identifying countermeasures. If you haven’t read the previous three blogs, you can find them at the following links:
- Part 1: How to Identify Countermeasures: Defining Countermeasures and How They Work
- Part 2: How to Identify Countermeasures: Key Operational Change and Supporting Tools
- Part 3: How to Identify Countermeasures: The Third Component – Person in Charge
In this concluding blog, I will share the last two important points to keep in mind when identifying countermeasures for your process improvement initiative.
👉The incremental nature of identifying countermeasures
When we identify countermeasures, we do not know that they will work. We do not know if they are the right answer. We do not know the whole story yet. Each of these stages is an incremental step. As we get a clearer picture of the problem, we get an idea of the countermeasure, and then we develop it. We then prove that it does or does not work. Even after that, we go live and sustain the process. That is when we get to see it in action.
Like software development, you can plan all day long, but you aren’t sure how effective it is until you see a product being used by users in a working environment. Sometimes you just don’t get it right.
It is important to note that as we identify countermeasures, there is a level of guesswork involved.
We are making very strong estimates and guesses as to what these key operational changes should be. It is through the next step, which is the development of countermeasures, which I will share in another blog, that we prove ourselves.
We are still being incremental. You might have 10 problems and many countermeasures to solve them. In the development process, you might realize that some of the countermeasures do not work or that you have indirectly solved another issue with your countermeasure. This means that you do not need to come up with another answer. It is okay if things do not go as planned.
👉The ratio between problems and countermeasures
When we have a problem, it is rare that only one countermeasure is needed. Typically, we see that a problem needs two to three key operational changes. Ten prioritized problems do not perfectly equate to 10 countermeasures.
Problems are not equal to countermeasures. They are not one-to-one. Problems are very dynamic and need multiple things to address the root cause and solve the problem as a whole.
This is where the scope of go-lives can truly become transformative and powerful. When you have 10 problems that you are solving but are actually implementing 30 or more countermeasures, it is quite impressive what a team can do when they really understand the problem they are solving and completely attack it.
Rather than being vague, ambiguous, or trying to solve everything, we get super specific with the problems through the PDCA process. And when we get to this stage of identifying countermeasures, they are incredibly robust countermeasures.
Divide and Conquer
Once you have named all your countermeasures, it is time to divide and conquer. There is no swinging from this point. There are no additional documents and no more work to be done. From this point on, you are going to create and develop those countermeasures. And that will be our topic in another blog series, so stay tuned.
In your service,
Hilary Corna
