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.