People in orgs aren't resisting change... they’re just trying to get through their Thursday.
Many change programs start with leaders designing for Work-as-Imagined, the perfect process in the PPT deck and comms sent out.
However employees don't operate in a work as imaged reality, they live in a Work-as-Done one... you know, the messy reality of broken tools, weird handoffs, and no time.
If we keep forcing a Work-as-Imagined process on a Work-as-Done reality, we will keep getting the famous change fatigue and resistance we keep hearing about.
Here is a process you can use to de-risk your change projects.
-PRE-FLIGHT Make sure you are framing your problem in behavioral terms and that you have a clear outcome you want to reach, including the assumptions needed and the ways you will measure success.
-DISCOVERY Map the actors and the interactions, and account for the system Make sure you also account for the context and constraints
-DEFINE Make sure you identify the actors, and the behaviors that are needed to be done, ask: who does what, when, where, with what. Then diagnose what could be blocking or helping to drive those behaviors, if you are not doing a good diagnosis.... you’re designing based on preference.
-DEVELOP Take your diagnosis and turn it into options, so you know what ingredients are needed to match the drivers, and to know where you have leverage. Make sure you have options for both individuals but also for the system.
-DESIGN Prototype the conditions, this can be workflow changes, tooling, norm signals, feedback loops... etc...
-DELIVER Make sure you it's realistic and survivable beyond a pilot... which means you may need to think about how roles, routines and cadence fit in and how the system will influence and either sustain or revert those pilot results back to the way it has always been.
Then... to sustain, you will need to scan, validate → iterate constantly
Where does change break most in your org
Discovery, Define, or Deliver?