- Traditional Change Models
- Disparate Change Groups
- Uncontained Change
- No Standard Change Approach
- Tools Focus
- Reliance on Benchmarking
- Changes Are Not Based On Data, Good Data, Or The Right Data
- Changes Made Based On Symptoms, Not Causes
- Systems Versus Processes
- Focus On People, Not On Process
- Lack of Context for Solutions
- Adding Versus Subtracting (Patching)
- Poor Implementation
- No Emphasis On Control
- Management Versus Leadership
- Summary
Lack of Context for Solutions
As described in the previous “Disparate Change Groups” discussion, it is often difficult to get full stakeholder representation of the process together for a project, and hence a more localized approach to change management is undertaken. Also, with little solid data available on which to base decisions and with just simple tools at hand, versus more advanced data-driven change methodology, decisions are often primarily based on gut feel. This is known euphemistically as “basing decisions on experience.” Managers (incidentally who are measured on making change) pull teams together ostensibly to implement a known solution (usually theirs), and any examination of data is done purely to provide grounds to do so. With this localized and biased viewpoint, little is done to gauge the potential impact of the solution, and even less is done to proactively examine beyond this one solution, let alone to examine the broader solution space.
Changes made on conjecture without context of any kind in high-stress environments are likely doomed to failure when glitches inevitably come along—the changes are not based on any form of evidence and thus are prone to a reversal of subjective opinion and support when things don’t go quite as planned. Any initial support quickly wanes, and the focus is on trying to find another solution.
Many symptoms described in this chapter play off each other. For example, as mentioned earlier, benchmarking without context is a common practice. New processes are brought in without an understanding of the old process’s needs or the new one’s capabilities. Similarly, again described earlier, focus tends to be on people and not the process, so any process context is lost when people are the primary focus. The same thing applies to the systems-versus-process discussion. If the focus is on the supporting system and not the process, the context of process understanding is not addressed, and changes are made without the foundation of understanding required.