When I decided to bring this blog back from the dead, one of the thoughts that constantly were in my mind was the question "where to start ?". What is the most logical point to start with ? I decided that a (not so) brief introduction of the knowledge base I would be using in my posts was a good start place. So I did wrote posts about Lean and TPS. Now, having done that, the question visited me again.
Considering that all the tools and techniques discussed in this blog will possibly represent a change, I decided that a good course of action would be to analyze the change itself, it's impacts and how to handle it in a controlled way.
One of the best studies on change I could find was in the work of Ms. Virginia Satir. Ms. Satir was a social worker and a researcher on family therapy. Amongst other works she is responsible for the creation of the Virginia Satir Change Process Model. In this change model, focused on human and family behavior changes, Virginia identified that change had 5 distinct stages:
The first state, or Old Status Quo describes a stable system, where occurrences are predictable, familiar and comfortable. From a organization perspective, the Old Status Quo represents a system stable, where everyone understand their roles and attributions, although not necessarily this is an optimal system. In 1A change gets introduced into the system. According to Ms Satir analysis, the first reaction to change is Resistance. In a organization this could mean that there is slow adherence to the change. Several reasons could be behind a slow compliance to the change, from disagreement to lack of familiarity (it is easier to keep the Old Status Quo). After some time, people will get more used with the idea and attempt to adopt the change. This is where Chaos becomes apparent. The lack of experience with the new scenario will directly impact functionality. While people learn and get familiarized with the new standards, it is normal to expect delays, questions, misunderstandings and errors that will reflect as a drop in overall performance. Given proper time, questions will get answered, people will become familiarized with the new standards, error rates will drop. This period is called by Ms. Satir as Integration. During this period, performance will start to raise again, until stabilizes on a New Status Quo, where people will understand their new roles in the process and new ways of work are bedded down. The New Status Quo can be positive, neutral or negative, depending on the change impact on the organization. A positive change will have a New Status Quo with higher performance than the Old Status Quo. A neutral will practically remain unchanged while a negative will have a worst performance.
The size of a change will impact the size of the curve in a proportional way. A large change tends to generate more Chaos (and more performance drop) than a small change. One big risk when introducing changes in the environment is that your performance drop falls bellow of your minimal acceptable performance. A MAP is a estimated line in your performance level, that represents an impact the business can not live with. In this cases, it is not unusual for the change to get rolled back to the Old Status Quo.
The larger the change, the more risk it carries to hit your MAP. One approach used to avoid this issue is to break the changes into smaller changes, with smaller impacts on performance. This way, it is still possible to perform change keeping the impacts to an acceptable level.
Another great advantage of smaller changes is related with the outcomes. Even if you get a negative change, due to a shorter cycle time of small changes, and the continuous improvement of the process, it is easier to review and start a new change.
Lean uses this concept in the form of kaizen and standardization.
Masaaki Imai in his outstanding book Gemba Kaisen: A Commonsense Low Cost Approach to Management, describes this process in a comprehensive way.
"...SDCA (Standardize-Do-Check-Act) standardizes and stabilizes the current process, while PDCA (Plan-Do-Check-Act) improves them. SDCA refers to maintenance and PDCA refers to improvement" - Gemba Kaisen.
When inserting a change, it comes in the format of a standard (standardize), stabilizing the process. Do refers to implementing the standard. Check refers to determine if the implementation remains on track and has brought the planned improvement. Act refers to performing and adopt the new procedure to prevent recurrence of the original problem or to set the goals for the new improvement in case it does not meet expectancies. Then, as part of continuous improvement, a PDCA cycle is called. P refers to plan the improvement, D refers to implement it, C to evaluate and A to adopt or plan a new cycle.
When applying the cycles to Virginia Satir Change Model, we use SDCA in the first interaction. If the results are below expected, then a PDCA can be used to improve the change process. This step can be repeated until we have a satisfactory result from the change. Later, if the team identify that there is still room for improvement, we repeat every step of the process, starting with a new SDCA and iterate with PDCA until the results match the expectancy.
To illustrate the use of this process, I will give a real example that happened last year in our Porto Alegre office. One of the critical components of our infrastructure are the virtual conference rooms. This is due to the distributed nature of our company and the fact that majority of our clients are located in different countries. The meeting rooms setup that we use for virtual conference have a flat screen TVs, one mac mini, one conference microphone and a Full HD webcam. During the day, different groups and projects share the meeting rooms, and it is not unusual for them to change configurations. Different versions and brands of communication software are used, based on what the client have available. In order to maintain all this updated and functional, we discussed and created a process. In this process we would automate the deploys of images in a daily basis. The images would receive software updates once a month. We implement the process and waited. During the next two weeks, we collected feedback from the users about this new process. Many users were not satisfied because their temporary files and configurations would be erased when the new image was deployed. At this point, we decided that the results were below expected and started a new PDCA cycle to improve the process. After discussion about the problem, we decided to change the deploy time, from daily to monthly. We implemented and once again observed. In the feedback sessions with the users we found that it was better, but still was impacting them. So we started a new cycle. This time we decided to change the deploy from monthly to every 3 months, based on a research of how often companies would release new patches. We also, change the image generation to every 3 months, to eliminate unnecessary work. We applied the changes and observed. From the feedback that we received, the users were, overall, feeling comfortable with the solution. At this time, we decided that we had reached a desired result and documented the process. The process then was distributed to other offices of the region to be deployed. All the changes that we did were small changes, with low risk to the business. When we discussed the issue, we always attempt to unveil the root cause and work directly on it. Also, in the check phases, we gave two weeks for the users to familiarize with the change and only then we actively look for feedback. In this case, it took us 3 cycles to get into a state where the results from the change were satisfactory. It is really difficult to get it right in the first try. Many of the changes that we applied in our offices required at least two cycles to get it right. This is not waste. By ensuring that your change will have satisfactory results you will always be aggregating value and eliminating waste from the system.
Considering that all the tools and techniques discussed in this blog will possibly represent a change, I decided that a good course of action would be to analyze the change itself, it's impacts and how to handle it in a controlled way.
One of the best studies on change I could find was in the work of Ms. Virginia Satir. Ms. Satir was a social worker and a researcher on family therapy. Amongst other works she is responsible for the creation of the Virginia Satir Change Process Model. In this change model, focused on human and family behavior changes, Virginia identified that change had 5 distinct stages:
- Old status quo
- Resistance
- Chaos
- Integration
- New status quo
The first state, or Old Status Quo describes a stable system, where occurrences are predictable, familiar and comfortable. From a organization perspective, the Old Status Quo represents a system stable, where everyone understand their roles and attributions, although not necessarily this is an optimal system. In 1A change gets introduced into the system. According to Ms Satir analysis, the first reaction to change is Resistance. In a organization this could mean that there is slow adherence to the change. Several reasons could be behind a slow compliance to the change, from disagreement to lack of familiarity (it is easier to keep the Old Status Quo). After some time, people will get more used with the idea and attempt to adopt the change. This is where Chaos becomes apparent. The lack of experience with the new scenario will directly impact functionality. While people learn and get familiarized with the new standards, it is normal to expect delays, questions, misunderstandings and errors that will reflect as a drop in overall performance. Given proper time, questions will get answered, people will become familiarized with the new standards, error rates will drop. This period is called by Ms. Satir as Integration. During this period, performance will start to raise again, until stabilizes on a New Status Quo, where people will understand their new roles in the process and new ways of work are bedded down. The New Status Quo can be positive, neutral or negative, depending on the change impact on the organization. A positive change will have a New Status Quo with higher performance than the Old Status Quo. A neutral will practically remain unchanged while a negative will have a worst performance.
The size of a change will impact the size of the curve in a proportional way. A large change tends to generate more Chaos (and more performance drop) than a small change. One big risk when introducing changes in the environment is that your performance drop falls bellow of your minimal acceptable performance. A MAP is a estimated line in your performance level, that represents an impact the business can not live with. In this cases, it is not unusual for the change to get rolled back to the Old Status Quo.
The larger the change, the more risk it carries to hit your MAP. One approach used to avoid this issue is to break the changes into smaller changes, with smaller impacts on performance. This way, it is still possible to perform change keeping the impacts to an acceptable level.
Another great advantage of smaller changes is related with the outcomes. Even if you get a negative change, due to a shorter cycle time of small changes, and the continuous improvement of the process, it is easier to review and start a new change.
Lean uses this concept in the form of kaizen and standardization.
Masaaki Imai in his outstanding book Gemba Kaisen: A Commonsense Low Cost Approach to Management, describes this process in a comprehensive way.
"...SDCA (Standardize-Do-Check-Act) standardizes and stabilizes the current process, while PDCA (Plan-Do-Check-Act) improves them. SDCA refers to maintenance and PDCA refers to improvement" - Gemba Kaisen.
When inserting a change, it comes in the format of a standard (standardize), stabilizing the process. Do refers to implementing the standard. Check refers to determine if the implementation remains on track and has brought the planned improvement. Act refers to performing and adopt the new procedure to prevent recurrence of the original problem or to set the goals for the new improvement in case it does not meet expectancies. Then, as part of continuous improvement, a PDCA cycle is called. P refers to plan the improvement, D refers to implement it, C to evaluate and A to adopt or plan a new cycle.
When applying the cycles to Virginia Satir Change Model, we use SDCA in the first interaction. If the results are below expected, then a PDCA can be used to improve the change process. This step can be repeated until we have a satisfactory result from the change. Later, if the team identify that there is still room for improvement, we repeat every step of the process, starting with a new SDCA and iterate with PDCA until the results match the expectancy.
To illustrate the use of this process, I will give a real example that happened last year in our Porto Alegre office. One of the critical components of our infrastructure are the virtual conference rooms. This is due to the distributed nature of our company and the fact that majority of our clients are located in different countries. The meeting rooms setup that we use for virtual conference have a flat screen TVs, one mac mini, one conference microphone and a Full HD webcam. During the day, different groups and projects share the meeting rooms, and it is not unusual for them to change configurations. Different versions and brands of communication software are used, based on what the client have available. In order to maintain all this updated and functional, we discussed and created a process. In this process we would automate the deploys of images in a daily basis. The images would receive software updates once a month. We implement the process and waited. During the next two weeks, we collected feedback from the users about this new process. Many users were not satisfied because their temporary files and configurations would be erased when the new image was deployed. At this point, we decided that the results were below expected and started a new PDCA cycle to improve the process. After discussion about the problem, we decided to change the deploy time, from daily to monthly. We implemented and once again observed. In the feedback sessions with the users we found that it was better, but still was impacting them. So we started a new cycle. This time we decided to change the deploy from monthly to every 3 months, based on a research of how often companies would release new patches. We also, change the image generation to every 3 months, to eliminate unnecessary work. We applied the changes and observed. From the feedback that we received, the users were, overall, feeling comfortable with the solution. At this time, we decided that we had reached a desired result and documented the process. The process then was distributed to other offices of the region to be deployed. All the changes that we did were small changes, with low risk to the business. When we discussed the issue, we always attempt to unveil the root cause and work directly on it. Also, in the check phases, we gave two weeks for the users to familiarize with the change and only then we actively look for feedback. In this case, it took us 3 cycles to get into a state where the results from the change were satisfactory. It is really difficult to get it right in the first try. Many of the changes that we applied in our offices required at least two cycles to get it right. This is not waste. By ensuring that your change will have satisfactory results you will always be aggregating value and eliminating waste from the system.
The conclusion is that the use of continuous improvement and standardization to control small continuous changes will lead your environment to a positive transformation, without the addition of unnecessary risks.
No comments:
Post a Comment