How to Achieve Continuous Improvement
Continuous Improvement is a term that is bandied about by many in IT but as common it is it seems to be just a elusive to actually achieve.
Many times it feels like a sisyphean task but it doesn’t need to be that way
Through the years, I have read many books and articles that suggest they offer the missing piece in the continuous improvement puzzle. There is quite a bit published on the subject, it’s surprising that everyone doesn’t have the concept solidly implemented by now with so many maps to success floating around. The problem is I don’t believe that the people who have written the articles have actually been successful in implementing a continuous improvement system. In my view they are either so focused on a manufacturing environment, or so overly broad as to not be really helpful. They include suggestions like “publish your metrics frequently” and “empower your employees” or “make it a part of everyone’s daily job” and “focus on finding the root cause of a problem.” I even ran into an article debating if the term should be Continual (implying periodic stops to assess & measure) or Continuous (meaning never stopping). None of these suggestions helped me implement a continuous improvement framework, that is until I ran into a very pragmatic 5 step approach and coupled it with two other tools (DFMEA and 4DX) that I was learning at the time.
Five Simple Steps to Achieve Continuous Improvement:
Define the current state or condition: Describe the current situation as thoroughly as you can. This may include system documentation and evidence why it needs to change. Why do we not want to stay in the current situation? What is the impact to the end users of the current situation in tangible, measurable business terms? How do you measure your current state; what metrics can you point to that indicate that change is needed?
Define desired state or condition: Describe the desired situation as thoroughly as you can. This may include system design documentation or other technical or functional documentation. What does “perfect” look like? Eliminating any constraints that may exist, what would it look like if there were infinite resources (money, time, staff etc)? Knowing everything that you know now, what would it look like if it was implemented in a completely greenfield situation and you had a chance to correct all of the annoying defects that you currently live with? What would it look like if there were no considerations other than implementing the best possible solution (eg political or bureaucratic considerations)? How would you know how when it’s achieved; what will the metrics look like once the change has been successfully achieved?
Identify the one thing that can be done to get closer to the desired state: This is the key morsel of wisdom. Often times when thinking in terms of continuous improvement it is very easy to get carried away and think about all the ways that things can be improved and try to implement them all at once. By focusing everyone on achieving just one thing that get us even just a little bit closer to the desired state makes it easier to actually achieve. Identify who is responsible to complete the task, and what support they need to be successful. That support may be resources or the ability to focus (removing other tasks from their plate as spreading them out among the larger team to allow them the space to successfully execute the task).
Identify what is preventing getting to the desired state: What obstacles are there in the way? Why haven’t we already achieved the desired state? What blockers are in the way? These obstacles may be structural in the organization, they may be technical, they may be financial or due to conflicting priorities. An honest assessment of what has previously prevented the team from achieving the desired success is the first portion of this step; however, the second step is brainstorming a plan to mitigate the obstacles and assigning someone to support and monitor the mitigation plan.
When can we follow up? Documenting a deadline when the task will be completed makes the achievement tangible and while this is helpful the more important portion is identifying who is accountable for the completion of the task and identifying milestones. Milestones are a pre-agreed waypoint that the team agrees to regroup, review and refocus on completing the task. At the milestone points, the team will review the status and the 4 other steps above focusing on what additional support is required to ensure success.
Once the task is completed, the team regroups and restarts the five steps. The current state is updated to reflect the improvement that was completed. The desired state is reviewed - is it still the desired state? If so, can we make our definition clearer at this point? If not, what needs to change? Were there unexpected obstacles that made achieving the most recent improvement? If so, how will we manage them if they arise again. What is the one thing that we can do next to get closer to the desired state and when can we follow up? As improvements are achieved, it’s likely that the desired state may evolve and this is okay because in truth, continuous improvement is a philosophy or a lifestyle rather than an event. It repeatedly builds on past success to achieve future improvements and when combined with principles of DFMEA and 4DX becomes something that is able to actually be put into practice.
I want to credit Fred Kaschak, Thomas Longcore, and Lonnie Wilson for mentoring me in applying Continuous Improvement concepts within my sphere of influence, everything I know and all the tools I use can probably be traced back directly to one of these three gentlemen - Thank you for your influence in my development.
Design Failure Mode Effects Analysis (DFMEA)
The Design Failure Mode Effects Analysis (DFMEA) process is a powerful tool in the continuous improvement arsenal. While many people are familiar with the generic FMEA, the DFMEA starts the analysis at the systemic design level. It provides a structured approach to analyze each component within the system, their interactions with other components in the system and how they fail individually and in concert.
The DFMEA process evaluates each failure mode to first identify:
The Probability- the likelihood that this failure mode will occur (on a scale of 1-10 with 10 meaning that it will occur frequently)
The Severity - the impact that this failure mode has when it occurs, is it catastrophic or transparent (on a scale of 1-10 with 10 meaning major customer impacting issues will occur)
The Detectability - the likelihood that when the failure occurs it will be proactively detected (on a scale of 1-10 with 10 meaning that it is not detectable and would rely on end users to identify and notify the appropriate teams of the issue)
the product of these three numbers is called a Risk Priority Number (RPN). While the RPN is not universally comparable, it does allow the team to focus on identifying the biggest potential risks caused by system failures.
The next step in the DFMEA is to evaluate if any changes can be made that would adjust one of the three numbers above. Even small monitoring changes can have a significantly positive impact on the RPN. These mitigating steps are fed as input into the Continuous Improvement cycle and a separate RPN is calculated based on after the improvement is implemented. This information helps prioritize what failure modes should receive improvement efforts or investment.
When applied correctly the DFMEA along with the continuous improvement cycle and 4DX provide major tools to increase stability and reliability of almost any large and complex system.
“-isms”
I was asked in front of an audience to define my leadership style. I wasn’t expecting this question and rapidly reviewed the leadership philosophy books that I had read recently. Although I certainly had a number of very helpful ideas and takeaways from these books, none of them truly resonated enough for me to say it defines my leadership style. As the painful seconds ticked away I stared into a sea of attentive faces in the crowd, suddenly a brief interaction with a member of my team came rushing into my consciousness. He said he always appreciated my “-isms”, that I always was able to come up with little succinct drops of wisdom that always seemed to provide simple guidance on how we should handle the situation. I realized at this point that over the years, I had collected a series of truths that really define my approach to life and to leadership. These were culled from books that I had read and leaders that I admired, and when followed they usually led to success.
The following is a summary of most of these “nate-isms” that give guidance to my leadership philosophy:
Begin with the end in mind - This is the quintessential Franklin Covey quote. However, within it is not only a truth, but it also conveys a large part of my continuous improvement philosophy.
You can’t steer a ship that’s not moving - Making a decision, even if it isn’t the best potential decision, is always better than being suck in decision making mode especially if it leads to gaining more information and facilitates a feedback cycle that leads to course corrections once more information is available.
There HAS to be a better way - Satisfaction with Status Quo is a dangerous place to be, it is critical that leaders are always challenging the current situation and encouraging the team to come up with ideas to improve even making small improvements towards a desired state.
It’s okay to make mistakes as long as they re all new ones - Making mistakes is a critical part of the learning process. When viewed in this manner, especially when one takes the time to pause and reflect to understand the lessons revealed, mistakes are one of the most effective learning tools available. That being said, not taking the time to learn from the mistakes and thus repeating them is inexcusable.
We are the “they” - Often times individuals who are not engaged will make observations about a situation or an organization indicting the “they” who should be responsible for affecting change: “they need to do something about this situation” or “they don’t seem to care.” This language robs the speaker of power and absolves them of responsibility, and if everyone has this attitude nothing will be done. It is important to me that my team is always empowered and responsible to make a change and improve the situation, seeing a problem and being able to do something about it helps everyone involved.
What is right is more important than WHO is right - John Kenneth Galbraith once said “Faced with the choice between changing one’s mind and proving that there is no need to do so, almost everyone gets busy on the proof.” When engaged in conflict, both sides get entrenched in their positions convincing themselves and anyone else that will listen that they are right. The ability to rise above the conflict, keeping an open mind and the ability to change it are key to ensure that right thing is done to the benefit of the entire organization.
Simpler solutions are more successful - Often complex solutions are attractive based on the sheer breadth and the ways they solve every outlying scenario within its rubric. However, taken as a whole if a simpler solution meets the need, even if it doesn’t solve every potential edge case, then it will be more likely to succeed.
To a hammer the world is a nail - Abilities and past success often creates blinders that limit the options that we consider when facing a new challenge. A hammer has experienced success installing nails, but when faced with a screw treating it like a nail is not likely to lead to success. Being open minded and embracing diversity of experience and abilities is the best way to avoid this problem.
Start with “yes”, follow with “and” - When faced with a new request from a customer, it is easier to focus on all the reasons why what their asking is not feasible and easier to tell them “no”, however, starting with a “yes” and then taking the time to give them context for what would be required to be successful will be more likely to lead to a positive outcome and a better customer experience.
Perception is more important than reality - Absolute truth and reality definitely exist and are important to understand. However, one’s perception of the truth of a situation often creates limitations and barriers that don’t actually exist; however, unless that perception is challenged the two are a distinction without a real difference. If perception limits one’s experience of reality, one’s perception is more influential on one’s experience than the actual reality.
Don’t make good the enemy of perfect - Frequently when trying to develop a solution, teams will reject a good solution in the pursuit of perfection. It is frequently better to put in a good solution, gather feedback and input to drive an iterative improvement, cycling through this process towards an end state. This will not only get closer to perfection than if one attempted to get there in one step but it will provide the stake holders the benefit of an improved solution much earlier in the process.
Innovation is important but execution is required - Innovation is a key component of improvement, however, execution is critical. Without execution to implement the innovations, they are just ideas without much value.
A man with two watches never knows what time it really is - Developing two systems or processes to answer a similar question creates the potential for uncertainty to exist if the two systems contain different results. It is better to work to figure out how to simplify the systems and processes to ensure that they meet the needs of all those who utilize the information.
Don’t boil the ocean - When faced with having to make large scale changes, especially within an organization, trying to do too much at once will not only lead to resistance but it will burn out all those involved. To be successful, it is critical to break the changes into manageable components, to demonstrate success with a number of quick-wins, and to gain support for larger more impactful changes.
Never dig a well when you’re thirsty - The need to change is frequently not realized until the situation demands it, trying to start the process to affect change when the need is pressing is a very difficult task. It is much better to anticipate the change and work to put the solution in place before it’s needed.
The best time to plant a tree is 20 years ago, the next best time is today - Frequently teams will complain about choices or decisions that were made in the past, facing challenges today they have a clear view of what the right choice would have been in the past. The past cannot be changed, but this clarity can be applied as an actionable task today. Instead of wasting time lamenting the past, use that energy to change today and you’ll be on a better path.
You often cannot change your situation, but you can change your reaction to it - Often times situations occur that are beyond our ability to control. Mistakes are made because people are human, hardware fails for random reason, problems happen due to not fault of your own; when this happens it is tempting to act with strong negative emotions… usually focusing on who is to blame. However, at the very least these situations provide learning opportunities. Understanding this and intentionally looking for the opportunities it represents will truly help find the benefit in any situation.