Successfully shepherding change within an organization is often a challenge. Often change management strategies are mainly about how to cope with a toxic culture but exclude the option of fixing the toxic culture. Why not address the root causes instead of trying band-aids?
You can try to push change in an ad hoc basis by adopting some strategies to create a similar feeling about the individual change effort. But that isn’t as effective as establishing them in the culture are. Strategies such as: going the gemba, pdsa, build trust via respect for people…
These tools and concepts build trust within the organization. The do that by showing people are respected and that the change effort isn’t just another in the long line of wasted effort for ineffectual change. The first part can be addressed, normally the second part can’t be addressed effectively. Often that is at the core of the issue with why the change effort isn’t working. It is a bad solutions. It hasn’t been tested on a small scale. It hasn’t been iterated numerous times to take a seed of an idea and grow it into a proven and effective change that will be successful. If it had been, many people would be clamoring for the improvement (not everyone, true, but enough people).
But still you can use strategies to cope with lack of trust in your intentions with the change and lack of trust in the effectiveness and fear of change. Some of those are included in the links below. But mainly my strategy is based on focusing on building the proper culture for long term excellence and the change management strategies are just short term coping mechanisms to help deal with the initial challenges. Using those strategies as a long term solution for dealing with change in a toxic culture isn’t a very sensible way to manage.
If observed performance/behavior in a system is a result of the interactions between components–and variation exists in those components–the best root cause explanation we might hope for is a description of the interactions and variation at a moment in time. How can we make such an explanation useful?
A single root cause is rare. Normally you can look at the question a bit differently see the scope a bit differently and get a different “root cause.” In my opinion “root cause” is more a decision about what is an effective way to improve the system right now rather than finding a scientifically valid “root cause.”
Sometimes it might be obvious combination which is an issue so must be prevented. In such a case I don’t think interaction root cause is hard – just list out the conditions and then design something to prevent that in the future.
Often I think you may find that the results are not very robust and this time we caught the failure because of u = 11, x = 3, y = 4 and z =1. But those knowledge working on the process can tell the results are not reliable unless x = 5 or 6. And if z is under 3 things are likely to go wrong. and if u is above 8 and x is below 5 and y is below 5 things are in trouble…
To me this often amounts to designing systems to be robust and able to perform with the variation that is likely to happen. And for those areas where the system can’t be made robust for some variation then designing things so that variation doesn’t happen to the system (mistake proofing processes, for example).