Level up your change management model

Most change practitioners have worked in a model where they are attached to a project, and are responsible for supporting the people impacted by the project. This approach has definitely improved the success rate of major change initiatives over the last decade, but we still have a long way to go. I believe change management is required both earlier and later in the project life cycle than is currently the case – and this article outlines how to dramatically improve business results during implementation for minimal additional cost.

We know that when people understand and can see the benefit of the change personally, they are much more likely to adopt the change. However, with most projects, the change managers don’t have time to fully appreciate the impact on all stakeholder groups and are not able to provide to the level of detailed support that helps individuals be productive in the new system quickly. There is usually too big a jump between a project change manager and an impacted individual.

Therefore, for larger projects, consider a model where a project has a ‘delivering’ change manager as well as ‘receiving’ change managers for each stakeholder group.

I was recently involved in a project that did exactly this, although it was not originally planned this way. The agency was rolling out an EDRMS (electronic document and record management system), and the project’s funding included business analysts and a delivering change manager. The project was run by IT and had limited business sponsorship, as is often the case. The IT project’s responsibility was to roll out the system (including high-level communications and training) but their responsibility did not include ensuring the business knew how to use the tool to their maximum advantage, as is often the case. Resourcing was insufficient for business needs. However, in this particular project, there happened to be a receiving change manager (me, as a divisional change manager) already embedded in a major stakeholder group in the business. Because I – along with the executive team – had prior experience with the implementation of an EDRMS, we knew how fraught and problematic an EDRMS implementation could be and therefore, with only two weeks notice prior to implementation, I quickly established a change management strategy for my stakeholder group.

First, here’s the basic description of the delivering/receiving change management model.

The delivering change manager is principally located within the project and works closely with the project team and the receiving change managers. Their responsibilities are more strategic and corporate focused, and ensure appropriate change activities are planned, scheduled and supported.

The receiving change manager/s are located within the business areas and work closely with the business, as a trusted member of the team. Their responsibilities are more operational and implementation oriented.

The delivering change manager responsibilities are focused on ensuring the change requirements are well reflected in project activities:

  • More strategic focus – ensure the solution addresses business needs, address executive buy-in
  • Begins work on the project in the planning phase
  • Ensure the impacted stakeholder groups needs are reflected in the project’s work and change activities
  • Ensure change activities are either part of project governance or have their own channel of reporting
  • Work with the business sponsor and project manager to deliver project objectives
  • Use corporate communication and executive messaging channels
  • Determine when receiving change managers need to be engaged
  • Work with the receiving change managers to ensure broad change approach is effective, make adjustments if required
  • Role usually ends at delivery cessation of project funding, so if cannot be extended, hand over to receiving change managers.

The receiving change manager responsibilities are focused on adoption of the change at the local level:

  • More operational focus – now the solution is determined, focus on its effective implementation on the ground
  • Begins work on the project once the detail of the solution can be clearly articulated
  • Understand the ‘big picture’ – the context for the change as well as how the business operates day-to-day
  • Develop change strategies to address immediate to medium term adoption
  • Determine and be able to articulate the day-to-day impact on affected staff
  • Determine and liaise with local leaders, both formal and informal
  • Use local formal and informal communication channels
  • Work with the delivering change manager to tailor change approaches, such as altering messaging as required
  • Role ends when adoption has effectively completed, which is perhaps a couple of months after the formal project has ended.

Factors to consider when determining different stakeholder groups:

  • Where the nature of the impact will differ
  • Where the process to adoption will differ
  • Where communication channels differ
  • Size and location of stakeholder groups
  • Note: receiving change managers can be part time, but should be experienced.

For projects with an IT component, I would strongly recommend the same approach with business analysts: delivering and receiving business analysts.

Sometimes, a change champion network is established by a project team to accomplish a similar objective, using existing resources in the impacted stakeholder groups. However, this model often does not succeed as there are so many constraints. Change champions rarely have sufficient time, authority, experience, exposure, maturity or support to do this work. An experienced and credible change manager is required to appropriately support the business.

There are significant benefits as a result of this approach. The voice of the impacted stakeholder groups is amplified, both within the project team and to the executive, and the impact on the stakeholder groups are better understood. There is greater empowerment of the business stakeholder groups at an earlier stage to address implementation issues. Real-time feedback allows for the last weeks of a project to directly address user concerns and prioritise bug fixes appropriately. For a small additional cost, the likely success of the project has now greatly increased. Having someone internal to the business directly supporting the change feels like true support, and much less like something is being ‘done to’ the business.

The benefits of this approach in the EDRMS project I worked on were significant. The additional combination of engaged executives on the business side, a receiving change manager and a receiving business analyst meant the following:

  • business principles were developed
  • an effective and usable filing structure was built
  • good user habits were established early (eg naming and saving documents)
  • an engaged and active user group was established
  • user feedback immediately informed project bug fixes and enhancements before the project disbanded
  • adoption was supported on a local and day-to-day basis.

The bottom line was that the receiving business analyst and the receiving change manager (me) were able to quickly empower business with the knowledge needed to make informed decisions regarding implementation, and were able to provide specific help to the specific needs of the separate teams ensuring good habits were developed early. As the receiving change manager, I also greatly enjoyed the dynamic of discussing (and amending) change approaches with the delivering change manager.

There was a “control group” in the form of another division which relied on the delivery change manager only; there was no receiving change manager. In the first weeks after implementation there was a marked difference in the use of the new EDRMS.

In my division, with a receiving change manager and receiving business analyst, uptake was dramatically better which greatly supports future effective future document management practices. The results speak for themselves:

  • an immediate uptake prior to any compulsion to do so
  • thousands more files and documents created
  • a greater transparency and sharing of information
  • better naming conventions used
  • higher quality metadata used to tag each document
  • even the language used to discuss the system differed between the divisions (largely positive vs largely negative).

This is a more expensive model, but not much more so. The receiving business analyst and receiving change manager were part time, and effectively supported over 100 staff. They overlapped the project by about two months. The additional cost of two part time resources for eight weeks is not expensive, particularly looking at the productivity gains from having a significantly more successful implementation.



2 thoughts on “Level up your change management model

  1. Pingback: Level up your change management model | millionairesoul

  2. I would like to come from a different angle.
    That angle suggests that even if you do all Jude suggests, people are immune to change. Kegan and Lahey tell us that ‘A recent study showed that when doctors tell heart patients they will die if they don’t change their habits, only one in seven will be able to follow through successfully. Desire and motivation aren’t enough: even when it’s literally a matter of life or death, the ability to change remains maddeningly elusive’.

    So if only 1/7 people who are going to die won’t change, why will they change for a piece of software that few people seem to care about?

    Kegan and Lahey say that deep beneath the resistance to change are hard wired beliefs and values.

    Unless leaders attend to these beliefs and values, all change management, whether it be delivering or receiving, are doomed to sum optimal outcomes.

What do you think?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s