Mapping change impact by role

Every significant change, whether a new system, a restructured process or a revised policy, lands differently on different groups. For a finance clerk, a new ERP may change almost every task they do. For a sales director, it may mean a new dashboard and little else. Treating both groups the same wastes effort on one and leaves the other under-prepared.

A change impact map fixes that. It is a simple, structured view of what changes for each role and by how much. It takes days rather than weeks to build, and it becomes the basis for training plans, communication, staffing during go-live and readiness checks. This guide shows how to build one.

Why a role-based view matters

Project teams naturally think in terms of the solution: modules, features, workflows. People affected by the change think in terms of their working day: what will I do differently on Monday morning? A role-based map translates the first view into the second.

It also exposes risks that a solution view hides. A modest change to a single screen may be trivial for most users but critical for a team that uses that screen hundreds of times a day. A new approval step may add seconds for the requester and hours for the approver. These differences only show up when you look role by role.

Step one: define the roles

Start with a list of roles affected by the change. Use roles, not job titles or departments, because the same title can cover very different work and the same work can sit in several departments. A role is a group of people who do broadly the same tasks with the same tools.

• Aim for a manageable number, typically between eight and twenty-five roles for a mid-sized programme.
• Include indirect roles: managers who approve, teams who receive outputs, external partners who send inputs.
• Record approximate headcount and locations for each role; you will need these for planning.
• Name a representative for each role who can help validate the map.

Step two: list what changes

For each role, record which tasks, tools and decisions change. Work from the future process design and the solution scope, and be specific. Uses new system is not useful. Raises purchase requests in the new portal instead of by email, with mandatory cost codes is.

Four dimensions to check

• Tasks: what people do, in what order, how often.
• Tools: systems, screens, forms, devices and reports.
• Decisions: who decides, on what information, with what authority.
• Relationships: who people hand work to, receive work from or report to.

Also record what is removed. People notice losses as keenly as additions: a familiar report that disappears, a manual check that is no longer needed, a contact they used to call. Losses often drive more anxiety than new tasks, and they need to be addressed openly.

Step three: rate the impact

Mark whether each change is small, medium or large. The value of the rating depends on consistency, so agree the criteria before you start rather than relying on judgement case by case.

• Small: a minor adjustment to an existing task. A short briefing or quick guide is enough.
• Medium: a new way of doing a familiar task, or a new task that is simple and infrequent. Needs training and some practice.
• Large: a significant change to core daily work, new skills, a change in decision rights or a change in role. Needs structured training, coaching and time to practise.

Then roll the ratings up to an overall impact per role. A role with one large change and several small ones may be rated high overall, especially if the large change affects their main task. A heat map, with roles down the side and change areas across the top, makes the pattern visible at a glance.

A worked example

Consider a typical distributor moving purchasing, inventory and finance onto a single ERP. Buyers move from email and spreadsheets to system-generated purchase orders with approval limits, which is a large change to their core work. Warehouse operatives gain handheld scanners for receiving and picking: a large change in tools, though the underlying tasks are familiar. Accounts payable clerks lose manual invoice matching, which is now automated, and take on exception handling instead, a medium change with a shift in skills.

Meanwhile, department heads gain a new approval step and a dashboard, a small to medium change, and the sales team sees almost nothing different beyond more accurate stock figures. Without the map, all five groups might have received the same two-day training course. With it, buyers and warehouse staff get hands-on practice and coaching, clerks get focused exception-handling sessions, managers get a short briefing and sales get an email.

Step four: validate with the people affected

A map built only by the project team will miss things. Walk through each role’s entries with its representative and, where possible, a small group from that role. Ask whether the changes are accurate, whether anything is missing and whether the ratings feel right.

These sessions are valuable in their own right. People see that someone has thought about their work specifically, which builds trust. They often raise practical issues, such as peak periods when training would be impossible or a workaround the design has not accounted for, that save problems later.

Step five: plan support to match

With a validated map, plan support role by role. Large impacts need training, coaching and time to practise. Small impacts need a clear message and a quick reference. Matching effort to impact is the main payoff of the exercise.

1. Training: design role-based sessions built around the changes on the map, using real tasks and data.
2. Communication: tailor messages to what changes for each role, rather than one general announcement.
3. Go-live support: place floor-walkers and champions where high-impact roles sit.
4. Readiness: define what each high-impact role must be able to do before go-live, and check it.
5. Capacity: plan backfill or reduced targets for roles that need significant practice time.

The map also helps leaders. A one-page summary showing which roles carry the greatest change gives sponsors a concrete view of where the programme’s people risk lies and where their visible support will matter most.

It is also a useful check on budget. If the map shows that most of the change falls on a few large operational teams, the training and backfill budget should reflect that. Programmes that size their change budget before the impact is understood often find it spread too thinly across everyone, with too little left for the roles that need it most.

Keep the map current

Designs evolve during a programme, and the impact map should evolve with them. Review it at each design milestone and before training materials are finalised. A short change log noting what moved and why keeps the training, communication and support plans aligned with what is actually being delivered.

Start with a simple spreadsheet: roles down the side, changes listed under each, a rating and a note on support. Fill it in with the design team in a couple of workshops, validate it with each role and use it to shape every people-related plan that follows.

Source: Intelliversal analysis.

Frequently asked questions

When should the impact map be built?

As soon as the future process and solution scope are reasonably stable, usually towards the end of design. A first draft can be started earlier from high-level scope and refined as detail emerges.

Who should own the change impact map?

The change lead usually owns it, with input from process owners, solution designers and representatives from each role. It should be a shared reference, not a document held privately by the change team.

Do we need specialist software?

No. A well-structured spreadsheet is enough for most programmes. What matters is consistent ratings, specific descriptions and validation with the people affected.

Explore Change management and implementation training