Where does Change Management fit in the Operating Model?
Working with organisations that 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) funded by and reporting to specific projects as required. My short answer – “none of the above”.
If the Change Management specialist 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 that it was difficult to add value as 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 a project 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 Change Management being downstream towards the end of a project to simply action pre-defined ‘communications and training’ tasks.
Both operating models suffer from the impacts of traditional project and program management approaches (command and control, top-down, management heavy). They 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. There is a stronger focus on product management over project management.
Product Management and Change Management are strongly aligned. Change Management is about listening to your people and stakeholders, the users and consumers of your product. Change Management can be that link between just creating the product and achieving the product goal. Don’t just assume the consumers of your product will ‘just get it’.
“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.”
Embed your Change Management capability within your team:
- To get the people ready for the product, and
- To get the product ready for the people.
Undertaking Change Management in an agile way ensures your product is valued by those who consume it. A Change Management lens within the agile team will ensure that someone has their eye on Organisational Change Management concerns, and overcomes the traditional habit of assuming we know all upfront. It will keep the customer’s journey front of mind. Having Change Management as part of cross-functional agile teams helps build the organisation’s capability to truly add value to the organisation.
Ensure Change Management in your Product Backlog
Change Management models talk about building change teams, building leadership coalitions, and change champions as special one-off events or activities, Agile frameworks embed these change leaders into the everyday. All the activities for Change 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, others such as ADKAR focus 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 experience as a Change Manager, people do not necessarily follow the linear progression of change models, the smallest trigger may make a persons view of value change dramatically. Not only does your product management need to be able to pivot and adapt rapidly to changes in stakeholder needs in response to marketplace conditions, but product management also 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 the 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 afterthought or purely a downstream activity. It’s not a supporting service, it belongs in your agile teams. Bring it forward, bring it into the teams. Where possible embed Change Management capability within the team and help them build cross-functional Change Management skillsets within and across teams working at scale. Many Change Management practices complement the intent of agile practices so look at ways to implement the agile Change Management framework and Change Management principles into your agile approach.