Change management is not about persuading people to accept a decision that has already been made. It is about turning an organisational choice into behaviours that are possible, understandable and sustainable.

When a company introduces software, redesigns a process or changes responsibilities, the technical project is only part of the work. The other part concerns the people who must interpret the new setup, learn different actions and understand what will actually change in their day. If this dimension is addressed at the end, with a general announcement and a few hours of training, the result may be a formally delivered solution that is barely used.

Change is not the same as the project

A project has scope, budget and a closing date. Change continues after go-live: it lives in everyday decisions, exceptions, habits and collaboration. Change management is therefore neither an internal campaign nor a separate communication plan. It is the work that connects objectives, processes, skills and adoption.

The distinction resembles the gap between delivering technology and making it work in a real context, explored in Working between technology, communication and people.

Three numbers behind the pressure on organisations

The World Economic Forum's Future of Jobs Report 2025 draws on more than one thousand large employers representing over 14 million workers. It estimates that 39% of workers' existing skills will be transformed or become outdated by 2030. Sixty-three per cent of respondents identify skills gaps as the main barrier to transformation, while 85% expect to prioritise workforce upskilling.

39%

Share of current skills expected to be transformed or outdated by 2030 — WEF, 2025

These figures do not mean that everybody must start again. They do show that technology, organisation and learning cannot be managed as separate worksites. If the process changes faster than skills and responsibilities, adoption slows and informal work returns to fill the gaps.

Start from the work as it really happens

Before designing messages and courses, observe how work is done today. Which steps exist only because somebody knows a shortcut? Where does waiting accumulate? Which information travels outside official systems? Who handles exceptions? The answers reveal the distance between the designed process and the practised one.

Involving people does not mean putting every decision to a vote. It means using their experience to identify dependencies and consequences that a project map may miss. Participation works when its boundaries are clear: what has been decided, what can still be adapted, which criteria guide the choice and when people will receive an answer.

Communication, training and support are different things

Not enough

  • •Announcing change only when the solution is ready
  • •Explaining features and deadlines alone
  • •Concentrating all training before release
  • •Measuring success only through project completion

Also needed

  • •Making the problem behind the change visible
  • •Clarifying responsibilities, impacts and decision criteria
  • •Supporting people through their first real cases
  • •Measuring adoption, quality and obstacles after release

Communication builds understanding; training develops capability; support helps when theory meets a real case. Confusing them means asking a newsletter to solve a process issue, or expecting a course to compensate for an undefined responsibility.

Measure adoption, not agreement

A change can create doubts and still work; it can also receive positive comments and never become part of the job. Useful metrics therefore look at behaviours and outcomes: usage frequency, data quality, lead times, errors, support requests, duplicated activities and the ability to handle exceptions.

Metrics need to be read over time. An early increase in support requests may be normal; the persistence of the same problems suggests that process, interface, skills or responsibilities need revision. Mature change management does not defend the original plan: it uses evidence to correct it.

This approach depends on capabilities that cross roles and disciplines, as discussed in Transferable skills are not vague skills, and on balancing speed with structure, explored in Start-ups and companies: two very different schools.

Shared responsibility must still be explicit

Saying that change concerns everyone must not mean that it belongs to no one. Sponsors, process owners, project managers, communication, training and operational teams have different responsibilities. Naming them reduces ambiguity and makes intervention possible when adoption stalls.

The aim is not to eliminate all resistance. It is to distinguish generic fear from useful signals: an overlooked workload, a conflicting incentive, a function that misses a real case or a decision without an owner. Resistance is sometimes the first qualitative data available about a project.

The same principle is visible in vibe coding: building faster does not remove control, maintenance or responsibility.