Sunday, March 2, 2014

Organisational change in change resistant organisations

In organisations that are resistant to change, I introduce change incrementally and iteratively. I use a Plan Do Check Act approach to rollout changes step by step. This blog describes that approach and what I think about as I attempt to implement changes. Most of my thinking focuses on the Planning step. That focus comes because the act of planning mitigates impediments, strengthens your plan and builds consensus. All of which is crucial in a change resistant organisation.

If the approach that I describe seems ‘heavy’ to you, that’s because it is. This approach will be overkill in organisations that are ready to embrace change. However for change resistant organisation I have found that this approach allows me to gradually introduce changes that deliver Impact. As those Impacts mount up, people slowly begin to trust more and allow for more impactful changes.  

Summarised change approach

Plan Do Check Act cycle


Plan

  1. Recognise opportunities 
  2. Recognise impediments
  3. Draft an action plan that will create Impact
  4. Learn from stakeholders
  5. Tune your action plan

Do

  1. Try it out, on a small scale.


Check

  1. Observe the results
  2. Discuss the results with your stakeholders. 


Act

  1. Tune your plan for the next attempt. 
  2. Iterate on the Plan, Do, Check, Act cycle. Rolling out the change to more people/teams.



Plan

Planning step from Plan Do Check Act cycle



Recognise opportunities

As a Change Agent I will identify a specific opportunity for change that I think will be beneficial. This kick starts my change approach.

E.g. The Delivery Teams currently do not use Test Driven Development (TDD). I would expect that introducing TDD would increase quality in the short term and that reliability and speed would increase in the long term. Once I have identified this, I need to work how to go about introducing TDD.

An alternative starting point to identifying a specific change; is that you want to improve a general aspect of the organisation. Generally you will want to produce one or more of these Impacts:

  • Improve effectiveness
  • Improve speed
  • Improve quality 
  • Improve innovation
  • Improve morale
  • Improve reliability


Aside: I did not mention ‘improve efficiency’ or ‘reduce cost’, as they came from achieving increased speed, with increased quality and increased reliability. We are better off chasing positive influences, as opposed to reducing negative influences.
If you are interested in generally improving an aspect of the organisation I recommend you read up Selling the Idea of Lean to Management

The rest of this blog will tackle the situation where you have a specific change that you want to put into place. I will go through how I create, tune and deliver a plan of action to introduce that specific change.


Recognise impediments

I find it is important to identify and mitigate the impediments to my plan. Just thinking about what impediments you may face is often enough to come up with simple solutions to mitigating them.

I try to consider as many different sources of impediments as possible, such as:

  • People – they can be allies or impediments.
  • Organisation Structure, Team Structure.
  • Processes – from all levels and all departments.
  • Policies – from all levels and all departments.
  • Tools – entrenched, lacking or poor.
  • Environments – limited, tightly controlled, unreliable.
  • Culture – the way things are done around here, we have always done it this way, etc.
  • Environmental – building, desks, rooms, lighting, etc.



Draft Plan

I draft a rough plan of action to implement the change. I do this considering what Impacts I want to achieve and what Impediments I am facing. It is not a good idea to create a detailed plan, because I expect the plan to change significantly during the next step.

The plan usually consists of some dot points, such as:

  • Which Teams / People should I start this with?
  • Which Teams / People should I avoid?
  • Which Teams / People would be next?
  • How will I convince the initial Teams People of the benefits?
  • Who do I need to gain support from to initiate the change?
  • What Impacts do I expect?
  • How will I measure those Impacts?
  • What costs do I expect during the rollout?
  • What costs do I expect in an ongoing basis?
  • What Impediments do I need to remove?
  • What Impediments can I avoid by going around them?



Learn from Stakeholders

The plan that I draft is just the beginning. Things get serious when I start to talk to stakeholders. Engaging stakeholders serves the dual purpose of learning how I can improve the plan and building consensus for the plan.

Generally I arrange an individual discussion with each stakeholder. Starting with the least influential and working towards the most influential, and finishing with those who I believe are opposed to the plan.

Alternative approach: Sometime it can be incredible useful to discuss the plan with a critic earlier in the process. This will help improve the strength of your plan, and make future discussions easier. This works best when you have built a good relationship with someone who is critical and good at providing constructive feedback.

When meeting with each stakeholder I tend to focus on the opportunities and impediments. I avoid talking about the details of my plan unless they are a detailed focused person. I listen intently for obstacles, support, their values, what is driving their behaviour, alternative ideas and potential variations to my plan. Overall I am trying to bring them onside, and learn from them so that I can strengthen my plan for future discussions.

After each discussion I think of how to improve my plan. i.e. How to strengthen its benefits, ease its introduction costs, better ensure success, reduce obstacles, prepare arguments against potential disagreements, find evidence to support it.  I also consider which variations of the plan instead of the pure original idea will still be successful. I find it really important to be flexible in how we achieve the impacts I am seeking. 

Do

Do step from Plan Do Check Act cycle
Add caption


By now, this should seem like the easy step. I have built support from the change from numerous stakeholders. I have learned how to mitigate any significant impediments. The plan is ready and many people are vaguely aware that some change is coming.

This is where I try it out, hopefully on a small scale. I get the official green light from the key stakeholders. Communication before, during and after change helps significantly. So I make sure the Teams / People know what is coming up. Then get them involved. Importantly I support and observe the whole change as it is implemented. This is not a good time to go on holiday.


Check

Check step from Plan Do Check Act cycle



With the initial change rolled out. I check in with the participating Teams/People. From them I can check what the real Costs, Benefits and Impacts are.

Going back to the stakeholders and discussing the results of the initial change, is a good way to build further support and gain consensus for a wider rollout. Additional it is useful to mitigate any unexpected impediments. 


Act

Act step from Plan Do Check Act cycle


The discussions with stakeholders in the Check step; allows me to tune the plan for the next attempt.

From here it is a matter spreading the change out to more Teams / People with Plan, Do, Check, Act. 

Consider Pivoting: If you significantly toned down your original plan (i.e. Rolling out TDD, changed to rolling out Test First) consider what evidence you have gathered that justifies reverting to your original change idea. Perhaps you can now convince those hesitant stakeholders that your change is really worth the effort. 


Good Luck

Change is hard, especially change that sticks. 
Good luck with your change journey.