Change management has an image problem. Too often it gets reduced to a spreadsheet exercise: list every Jira ticket, map it against user groups, and document the "change impact" - sometimes before a single line of the actual solution has even been built.

That's not what the users of your shiny new system want - or need! Change management is there to support them - not your project stakeholders, CEO or the steering committee - the users.

Real change management starts with a question that a spreadsheet can't answer: how will this actually change the way people work?

The ticket, work item, user story or feature is only a description of something being delivered. The real impact sits with the person who has to use it. What will they need to do differently? What will they need to learn? What behaviours will need to change, and what might they need to stop doing? What does this change mean in the context of the other changes already happening around them?

You can't meaningfully assess the impact on a user group until you understand what the solution actually does and, ideally, have something real to work with. That might be a working feature, a prototype, a demonstration or a new process that people can actually experience. Trying to determine change impact from a ticket title or a high-level requirement is often little more than educated guesswork.

At AppGenie, we treat change management as something that sits alongside delivery, rather than something that happens downstream of it. That means understanding what is changing for people, not simply what is changing in the system, and bringing the human impact into the delivery conversation early enough that it can actually influence the outcome.

It also means thinking about adoption in terms of behaviour rather than communications alone. People may need to learn something new, unlearn something that has become habitual, or change the way they interact with a process they've used for years. They may need training, support, time to adjust, or simply a good explanation of why the change is necessary. And those needs are often very different depending on the people involved.

Most importantly, change rarely happens one ticket at a time. Several changes that look relatively minor when assessed individually can have a significant cumulative impact on the people experiencing them. Understanding that requires looking at the change as people experience it, rather than as it happens to appear in the delivery backlog.

Good change management is often invisible when it is done well. People understand what is changing, why it is changing and what it means for them. They have been involved early enough to influence the outcome, and they have the support they need to move from the current way of working to the new one.

That is fundamentally a human exercise. The paperwork and the impact assessments are useful tools, but they aren't the change management.

So the next time a project asks, "What is the change impact of this ticket?" before the ticket has even been built, it is worth asking a different question:

What is actually going to change for the people affected, and what do they need from us to make that change work?

That's the work that empowers users, raises adoption and makes your new "system" return the ROI that was stated in your business case - that magical unicorn we're all after.