In Enterprise Architecture we often talk about models, patterns, best practices, technology and the like. Given that EA is fundamentally about change, it’s interesting that change management doesn’t get a lot of coverage in EA circles. In this post I’ll introduce a very simple model of change management that has been around for over 50years.
The term “change management” is a daunting one. Conceptually we know what it is and we know that we need it – but we often don’t know where to start. One of my favourite models of change management was devised by Kurt Lewin. I like it because it is insightful – yet extremely simple. And it shows us exactly where to start.In essence, the model proposes that “change” is a 3 step process:
Step 1: Unfreezing
This step deals with determining what needs to change and why it needs to change. It’s about overcoming organisation inertia, breaking down the status quo and changing mindsets. This step is often characterised by fear, uncertainty and anxiety. People’s doubts and concerns must be understood and managed.
Step 2: Change
Once people understand the need for change, new ideas are developed and introduced (usually through a collaborative and inclusive effort). Once the future state is agreed on, the organisation begins the transition from the old to the new. During the transition people will be out of their comfort zone so to allay their fears you need continually reinforce how the change will benefit THEM (not everyone will fall into line because something is good for the company).
Step 3: Freezing
Once the transition is complete and everyone has found their feet again you need to institutionalise the changes – make them the new status quo. Policies, procedures, reward systems and organisational values are all changed to reflect the new reality. This helps the change ‘sink in’ and provides some closure. Eventually, people’s comfort levels begin to return to previous levels.
This key insight from this model is that the process of “change management” has 3 distinct steps. To maximise chances of success you we need to start at the beginning and work your way through.
You could start at Step 3. You can attempt to freeze change by introducing new policies and procedures and then expect people to follow them. The trouble is – they won’t. At best they will obey the letter of the law but not the spirit and at worst they’ll just ignore everything and keep doing what they’ve always done. Sure, you could spend a lot of time on monitoring and enforcing compliance but this is wasted time, money and effort. If you manage change correctly people will voluntarily move with you – without any oversight or coercion.
Unfortunately you see a lot of enterprise architecture groups starting at Step 3. Endless documents, models, policies and procedures are produced and disseminated throughout the organisation. The architecture group expects people to comply. But they never do. And they never will. It is really easy for various groups to come up with arguments why they are special and why the rules shouldn’t apply to them. Typically, those arguments are hard to refute. Even if the architecture group had ‘friends in high places’ which could mandate compliance, such an adversarial spirit between the central architecture group and other groups is counter productive.
You could start at Step 2. Starting here is an improvement over starting at Step 3 because you’re at least consulting various stakeholders throughout the organisation, rather than just forcing change down their throats. This collaborative and inclusive process means you can come up with a better and more complete vision of the future and it also means that people will be less resistant to change because they’ve had a say in what the change will be. The problem with starting at this step is that ‘less resistance to change’ is not the same as ‘support for change’. And you need the latter.
Again, you see a lot of architecture groups starting at this step. Often you see a new lead architect come in and try and change things to suit their personal preference. Or a new technology comes out and the architecture group incorporates it into their vision. The problem is that various project teams are likely to be cynical of the proposed changes and dismiss them as “change for change sake”. Even if the end state is better than the status quo people won’t change, largely because change is hard work. You need to show people that the difference between the future state and the status quo is big enough to make it worthwhile moving.
But you should be starting at Step 1. By process of elimination we’ve arrived at Step 1. The logical place to start. Obviously, there’s never any guarantees when it comes to something like ‘change management’ but as with everything, if you take the time to think it through, you at least give yourself a fighting chance of success.