Why change management is about more than stakeholder engagement

Do you confuse change management for stakeholder engagement and communications? If so, you’re not alone, many project managers do.

In this blog, we’ll take a look at the main differences. But before we do, it’s worth clarifying that the focus of change management is to prepare your business for disruption, while stakeholder engagement informs and engages stakeholders about project outputs.

Why are they not the same?

Change management is more complex than the practicalities of project engagement related to your stakeholder's interest. Let's remember that leaders, managers, and supervisors, along with their teams, suppliers and customers, have the power to influence performance if they don’t see the value in what you're doing. But value can only occur when you address more deeply how people will be affected once the change is in place. Once people understand the importance of their contribution to support the change, ‘why’ a change is happening becomes as important as ‘how’ the case for change will work. It's not easy; not everyone will see the positives across diverse groups but coming together and grasping what it truly means is vital for maintaining sustainable operations for your organisation.

Limiting beliefs

Success in change management also takes more effort than stakeholder engagement. It's only part of the process and writing well-scripted communications explaining how great a project is won’t equip your workforce to make a change. Particularly when it’s something they don’t care about. Below are some of the common misconceptions that perpetuate this myth.

Communication is enough to support people, they’ll quickly adapt.
Change management adds delays, it’s time the project schedule doesn’t have.
There’s no need for training, the technology is intuitive.
People issues are not the project's concern, that’s a HR problem.
We don’t need more planning to manage people, the project delivers plenty.
The transformation will get people on board, projects are mandated.
When the handover is complete, the rest works itself out.
Why measure if the project made the right impact, people ‘seem’ OK.
Let's communicate the IT, stakeholders don’t need to understand why or what for.
Struggles ease with time, corporate implications are overstated.

If we flip the idea that we only need to inform our stakeholders of the IT project outputs, then what about the possible aftermath? For example, this could lead to potential problems such as:

Issues hitting your service desk when daily operations become affected by people's lack of ability.
Increased vulnerability around security policies due to low-level competence
Increased regulatory fines when poor workplace adoption triggers data breaches
The inability of the organisation to scale operations due to workforce struggles with new ways of working.

Change to increase quality services with great productivity at a minimal cost is what your sponsors care about, but the adoption rate will always come down to an individual's perception of how different the future looks and the value it holds for them.

You won't have all answers

Buy-in is not without its problems. It takes work to translate the true implications of not changing and what capabilities are required for the future. Even with the best intentions, communications can go wrong so early engagement is needed to prepare the business areas, explaining there will be unknowns before opportunities can be realised.

For instance, if an IT transformation is technically challenged, temporary workarounds will likely inflame your naysayers. They won't tolerate disruptions occurring while the implementation is gaining momentum and won’t understand why it won't be solved with a proper technical fix. Why? Because what they care about is what matters to them at that moment, not your project. So as project professionals, we need to look at all the elements to develop a meaningful approach to managing a business change, including methods and other specialisms like marketing.

I think introducing a change is much the same as launching a product in a new market. Once a good marketer knows what customers need and what problems to solve, they are better placed to develop successful products with higher returns. The same principle applies to targeting our efforts. Once we have a better understanding of stakeholders, we can endeavour to profile groups that can influence our success. This, in turn, can help sway the low-level or high-level interests of the groups. We can also delve deeper into metrics that can quantify trends and bottlenecks.

Lead with empathy

Project managers shouldn’t ignore workforce difficulties or think their issues can be unravelled at the end of the project or in business-as-usual operations. So think about educating relevant groups as a prerequisite to gaining their trust or at the very least, gaining some leniency when you need it. Otherwise, stakeholders who don’t feel your honesty will start to push back. But keep in mind, sometimes the root cause of people's frustration can be reframed as the behavioural change to adapt, not technical problems to solve.

These types of emotional reactions shouldn’t be ignored. They may be out of scope for your technical plan but they should be factored in at the start of a change management strategy so all bases are covered. It’s best to articulate this clearly showing you’re listening with intent and addressing their multiple perspectives, behaviours, and opposition.

Take a look at Prosci’s ADKAR model from my previous blog post to help you navigate people's motivations throughout the project life cycle.

If at this point, you’re starting to think project management leadership needs to be more than design, development and deployment for delivered outputs to stick, then you’re right. Our roles are evolving with the pace of change so we need to get comfortable with empathy and include what stakeholders care about in the delivery process. Otherwise, without joined-up thinking, it's tough to gain ‘the intended value’ that all projects are expected to deliver.