Where does Change Management fit in the Operating Model?
Working with organisations who recognise the value of an organisational change management capability, has given me the experience of some lively leadership debates around where within those organisations, their change management capability should reside. The debate was often polarised between a centralised team of Change Management subject matter experts (maybe reporting to the HR or the Communications department) providing services across the organisation, or individual people (often contract resources) brought on board and funded by and reporting to specific projects as required. My short answer – “none of the above”.
If the change management specialists is sitting in a centralised team on the org chart, they may find themselves working across multiple programs at once. Available time and quality of work is reduced by context switching and being spread too thin. In this model, Change managers often reported finding it difficult to add value and that projects weren’t really interested in ‘managing the change’, but rather ‘ticking the box’ by following a schedule of predefined change activities. Being a step or two removed from the projects means that often change managers are unable to implement feedback mechanisms that could actually impact the direction of the project.
Interestingly, Change Management experts reporting directly to projects expressed similar concerns; difficulties in actually ‘managing the change’ to add value. The causes were different and included the churn of short-lived teams, or funding constraints that resulted in CM being downstream towards the end of a project to simply action pre-defined ‘comms and training’ tasks.
Both operating models suffer from the impacts of traditional project and program management approaches … traditional command and control, top down, ‘management heavy approach’. And are not supported by mechanisms that allow the programs to listen and learn from their stakeholders. Change activities are locked in upfront.
Change Management Capability Embedded within Agile Teams
With the 2020 updates to the scrum guide the goal of the ‘product’ vision comes into greater focus, alongside self-managing teams. A stronger alignment with product management over project management.
Implementing agile is all about culture and change as there is a strong alignment between change management and product management. Agile change management is about listening to your people and stakeholders, the users and consumers of your product. It is about ensuring your product is valued by those who consume it.
Don’t just assume the consumers of your product will ‘just get it’.
So why do you need change management capability embedded within your team?
- To get the people ready for the product, and
- To get the product ready for the people.
Having change management as part of teh corss fucntional agile team helps build the organisation’s change management capability to truly add value to the organisation. “The Scrum Team is responsible for all product-related activities from stakeholder collaboration, verification, maintenance, operation, experimentation, research and development, and anything else that might be required.”
A Change amangement lens within teh agile team will also ensure that someone has their eye on Organisational change management concerns and overcome our habit of assuming we know all and will keep the customers journey front of mind. Change management can be that link between just creating the product and achieving the product goal.
Ensure Change Management in your Product Backlog
Change management models talk about building change teams, building leadership coalitions, change champions as special events or activities, Agile frameworks embed these change leaders into the everyday. All the activities for Cchnage management relating to your product should live in the backlog of your product and help you achieve your product goal. Writing a Change management feature is no different to any other, the same tools used for backlog refinement, writing a feature, splitting a feature and so forth still apply.
The main change models all have their focus. For instance, Kotter’s change models focuses on early leadership action and vision setting, other such as ADKAR focuses on activities to bring the individual on a journey through Awareness, Desire, Knowledge, Action & Reinforcement. Regardless of the Change management model you are inspired by, the Change outcomes required to support your product should be part of your product backlog and tested as Lean CM experiments.
In my expereince as a change manager, people do not necessarily follow the linear progression of change models, the smallest trigger may make a person view of value change dramatically. Not only does your product management need to be able to pivot and adapt rapidly to changes in stakehodler needs in repsonse to marketplace conditions, product management needs to be able to adapt to the emotional and cognitive changes of your customers.
To adapt, you need to be continuously checking in. If you already have an agile framework in place then you are set up to listen and take customer feedback on board. Use your scrum events to stay focussed on value to customer talk to your customers and stakeholders early and often. The Change Management features in your backlog are ever changing, rarely is it do something once and it is done. Adapt and refine your backlog accordingly.
Building an Agile Change Management Capability
To set up your organisation to succeed, Change should not be an after thought or purely a downstream actvity. It’s not a supporting service, it belongs in your agile teams. Bring it forward, bring it into the teams. Where possible enbed change maangement cpability within teh team and help they build corss functional skillsets in change within and across teams working at scale. Many change mangement practices compliment the intent of agile practices so look at ways to implement the agile change management framework and change mangement principles into your agile approach.