As change practitioners we often feel that we create the success behind the scene.  We design great change experiences, and if all goes well, then people won’t notice it.  By this, I mean that if the impacted person has a smooth experience, and that there are no negative incidents or frustrations, then he/she won’t notice the change curve that had just occurred.  I often hear this ‘gutfeel’ from change practitioners.  However, there is more to this.

Designing and executing good change experiences is not just about how skillful the practitioner is.  It is about understanding the system.  Let’s explore this further.

An effective change approach is about assessing what the change needs to be and diagnosing key components of the overall system required to transition impacted stakeholders from current to future.  What are these?

For example, you are implementing a new system and you are hearing that the last system implementation did not go smoothly.  You conduct a series of interviews with key stakeholders to understand what happened.  What you found that was there was insufficient drivership from leaders.  There were adequate communication and training as a part of the rollout.  However, the change was not sufficiently reinforced by middle managers and therefore after the first 2 months where there was good traction, things slowly faded away.  Users started to not use the new system.

In your analysis of the overall system, elements included:

• The extent of commitment and visible reinforcement from various leaders
• The understanding of the why and how this was communicated
• How effective learning interventions were
• Effectiveness of launch visibility on the behaviours of impacted stakeholders
• Influence of manager/leader levels on the behaviours of impacted stakeholders

Learning from the previous system implementation project, you then conducted stakeholder readiness assessments to understand where they are at.  You then utilise what you have learned to tweak your initial change approach to address key levers in the system to ensure the project is successful and avoid previous mishaps.

What you are doing is problem-solving and preventing failures by looking at the whole system.  You’ve broken down the system into its elements and assessed how critical these were in contributing to the success of the overall project. 

You are what author Dan Heath calls the ‘Invisible Hero’ in his book ‘Upstream’.  You’ve saved the day by ensuring the right elements were considered in the change approach and ensured a successful outcome.  Most would not see the work you have put in and there is usually no direct attribution that you lead to the successful outcome.  You’re not a visible hero.  In fact, the Project Manager was probably the one credited with being a hero.

In Dan’s book some of the key concepts of how one can become an invisible hero by problem solving before the problem happens include:

• Focus on changing the overall system, versus just one problem
• Identify what has become normal and zoom in on this as a problem
• Systems can be complicated, and therefore when you tweak elements of the system expect the unexpected
• Design ongoing feedback to ensure ultimate success
• Detect problems before they arise by addressing any early warning signs
• Use key points of leverage to exert the greatest impact

By focusing on the overall system the change practitioner can start to become less reactive and more proactive.  A reactive situation is one where you are constantly fighting fires, dealing with issues raised by stakeholders, and delays in implementation timelines.  A proactive situation is one where you’ve incorporate key risks and challenges and addressed these early on prior to issues happening.  You’ve anticipated stakeholder concerns, potential embedment issues, lack of sponsorship, and ineffective reinforcement of stakeholder behaviours.  This is what Dan Heath means by ‘upstream’, that you deal with problems before they occur.

Looking at the system across the portfolio

Let’s take this one step further.  Organisations are all implementing multiple initiatives.  Stakeholders are not rats in the lab that only face one singular project.  At any one time, they are usually facing multiple changes.  Some large and some small.  To truly look at the whole system we need to consider the system from the impacted person’s perspective.

Some examples of this includes:

• Key targeted behaviours driven across multiple projects
• Overall change capacity impacted by operational factors such as customer work volumes, seasonal work changes, and of course any Covid implications
• The sizes of impacts of various projects, and the priority placed on each of them
• The nature of impacts on different stakeholder groups and how impacts on one stakeholder group could, in turn, result in an impact on another group
• Which stakeholders are most impacted by changes and what additional tactics are required to support them through the multiple changes
• The content of training and communication collateral across different initiatives and whether there is synergy, duplication, or clash
• The change maturity of the impacted groups and to what extent they need additional readiness support for the project you are rolling out

At The Change Compass we focus on providing data visualisation to show elements of the system, whether it’s the relative change capacity of stakeholder groups, to what extent change saturation is exceeded, identifying key behaviour changes targeted across initiatives, identifying hotspots for potential synergy across initiatives, or assess which initiatives are at most at risk due to level of impact versus stakeholder readiness levels.

Are you ready to be an invisible hero?  To what extent are you already incorporating systems analysis and planning as a part of your change approach and implementation? With the right data, stakeholder feedback, and focus, examining the whole system does not need to be complicated, cumbersome or time-consuming.  In the post-Covid agile world where things are constantly in flux, examining the system is even more critical.  This is the ultimate test of the change practitioner in being the architect and tinker.