Before You Announce the Change, Map Who Has to Work Differently

Before announcing a change, map how the work will differ for each role.

A polished all-staff email is not a change plan.

Before you announce a new system, process or policy, ask a more practical question: who will have to work differently on Monday morning?

A project can be approved, a system can be nearly ready and a training session can be booked, while the people doing the work still do not know what will change for them. The problem is not always that communication arrived too late. Often, the project moved to communication and training before it understood the operational impact.

A simple change-impact map makes that impact visible. It compares today’s way of working with the future way of working for each affected role or group, then connects the difference to a practical support action.

Why this matters

A change can look small in a project plan but feel large to the person doing the work. Replacing a shared mailbox with an online form may sound like a technology change. For a coordinator, it may alter how requests are checked and assigned. For a team leader, it may change approval steps and visibility. For a support desk, it may create new questions and escalation paths.

If those differences are not mapped, teams tend to produce generic communications and one-size-fits-all training. Important groups can be missed, support demand can be underestimated and old workarounds can survive after launch.

Change-management guidance consistently points towards understanding which people are affected, how their roles will change and what support they need. PMI describes impact and readiness assessments as useful ways to build actions for specific recipients, while Microsoft’s implementation guidance recommends using change-impact assessment to shape role-based training. A map is a practical way to bring those ideas into an ordinary project conversation.

For a related workflow perspective, see Before You Automate a Broken Workflow, Map the Work First. For the handover and launch perspective, see Before Go-Live, Prove the Service Is Ready.

What a change-impact map is

A change-impact map is a short working document that compares the current and future work for each role or group affected by a change.

Its job is to answer six questions:

• Who performs or supports the work?
• What do they do today?
• What will they do in the future?
• What specifically changes for them?
• How significant is the impact?
• What communication, training, process update or support will help?

A simple table is enough. Use columns for role, current work, future work, specific impact, impact level, support action, owner and timing. Keep the first version small: no more than five role rows is usually enough to reveal the main risks.

How to build the map

1. Describe the change in plain language

Start with one or two sentences that describe the operational change, not the project slogan. Avoid “implement a modern digital solution”. Say what will actually happen.

For example: “Service requests will move from individual email inboxes to one online form and a shared triage queue. Coordinators will assign requests from the queue, and team leaders will approve exceptions inside the system.”

If the project team cannot describe the change plainly, it is too early to design broad communication or training.

2. Identify roles at the level work happens

List the roles that perform, approve, receive, support or rely on the work. Use business roles rather than broad labels such as “all staff”. A department may contain people who use the same system in very different ways.

Think in terms of tasks. A coordinator who enters information, a manager who approves it and an administrator who maintains the workflow are three different change audiences, even if they have similar system access.

3. Map today and the future

For each role, write a short “today” and “future” description. Focus on observable work:

• tasks performed
• decisions made
• information used or created
• handoffs and approvals
• tools, forms or procedures used
• measures or reports relied on

The contrast between today and the future exposes impacts that a generic stakeholder list will miss.

4. State the impact as a practical difference

Write each impact as a clear shift from X to Y. Examples include:

• from emailing a request to submitting a structured form
• from local prioritisation to a shared triage rule
• from verbal approval to recorded approval
• from a weekly spreadsheet to a live dashboard

Then check whether the change affects skills, workload, decision rights, timing, compliance, data handling or working relationships. This prevents “new system” from becoming the only impact recorded.

5. Rate impact without pretending it is precise

Use low, medium or high. The rating is a conversation aid, not a scientific score.

Low means the role needs awareness but performs almost the same work. Medium means some tasks, tools or handoffs change and guided practice may be needed. High means core responsibilities, decision rights, workload or risk controls change.

Add a short reason beside the rating. “High: daily workflow and exception approval both change” is more useful than a coloured cell with no explanation.

6. Match support to the impact

Now decide what each group needs. Avoid using “send email” as the default action. Support may include a manager briefing, demonstration, practice task, updated procedure, job aid, drop-in session, champion network, revised roster, temporary capacity or a clear escalation path.

Give every action an owner and timing. “Update the procedure” is not a plan. “The process owner updates and approves the procedure before role-based training begins” is.

7. Validate the map with people who do the work

A project team’s first version will contain assumptions. Test it with a small, representative group from the affected roles. Ask:

• What have we misunderstood about today’s work?
• What will be harder, slower or riskier in the future?
• Which exceptions or handoffs have we missed?
• What would help you perform the new process confidently?

Update the map, then use it to shape the communication plan, training plan, operating procedures, support model and launch checklist. Review it again when the solution or process changes.

A realistic example

Imagine a community health-service operations team introducing one online form for non-clinical service requests. Today, requests arrive through several shared and personal inboxes. Coordinators interpret each message, copy details into a spreadsheet and ask a team leader about unusual cases.

The project initially plans one organisation-wide email and a 30-minute system demonstration. The change-impact map shows why that is not enough.

Coordinators face a high impact: intake, data entry, prioritisation and assignment all change. They need scenario-based practice, an updated procedure and extra support during the first week. Team leaders face a medium-to-high impact because exception approval moves into the queue and must be recorded consistently. They need an approval guide and a short dashboard briefing.

Managers have a medium impact because reporting moves from a weekly spreadsheet to a live view. The support desk has a high launch impact because it must recognise workflow issues and know where to escalate them. Occasional requesters have a low impact and mainly need a clear link and guidance on what information to provide.

The map turns “communicate the change” into a set of specific actions for specific people.

Common mistakes to avoid

• Starting with the organisation chart. Reporting lines do not show how work actually flows. Map roles and tasks.
• Treating everyone as a user. People enter, approve, monitor, administer and support work differently.
• Recording only technology changes. Process, workload, decision rights, data and handoffs may matter more.
• Confusing stakeholder interest with operational impact. A senior sponsor may be highly influential but perform little changed work, while a coordinator may face a major daily impact.
• Using the map once. Update it when scope, process design or rollout sequencing changes.
• Skipping validation. A neat project-room table can still be wrong if nobody who performs the work has checked it.

Try This This Week

Choose one upcoming workplace change and book 30 minutes with two or three people who understand the work.

Create a table with eight columns: role, today, future, specific impact, impact level, support action, owner and timing. Complete no more than five role rows.

Circle the row with the highest impact. Ask one representative of that role to review it. Then change one practical item in your plan: the training format, procedure update, support coverage, communication message or rollout timing.

If the exercise produces no change to your plan, challenge the map. It may still be describing the project rather than the work.

Key takeaway

People do not experience “the change” in the same way. They experience changes to tasks, decisions, tools, handoffs and expectations. A one-page change-impact map makes those differences visible early enough to act on them.

Before writing the all-staff email or booking generic training, map who must work differently.

AI disclosure

AI tools assisted with research and drafting. The final article requires human review and approval before publication.

Sources and further reading

• Project Management Institute: Engaging stakeholders for project success
• Microsoft Learn: Create a training plan for implementation projects
• GOV.UK Service Manual: Set up a service team