Five impact dimensions: change impact assessment for mid‑market teams

A change impact assessment is a structured exercise that identifies who and what a proposed change will affect, across people, process, technology, data and culture, before that change goes live. Run it early, in the diagnose or planning phase, when scope can still be adjusted. Leave it until go-live and it stops being an assessment and becomes damage control.

TL;DR:

Conducting impact assessments early helps identify scope issues and dependencies that can significantly reduce rework and prevent costly delays.

The five dimensions—people, process, technology, data, and culture—must be evaluated to uncover hidden effects that could impact adoption or cause disruptions.

Regularly updating the assessment during implementation ensures risks are managed as scope, teams, or timelines change, maintaining relevance and accuracy.

Gathering comprehensive evidence from process maps, system inventories, and stakeholder input improves the credibility of impact ratings and mitigation strategies.

Using a live organisational model accelerates assessment speed and accuracy, supporting continuous updates and better decision-making throughout change initiatives.

What is a change impact assessment and what does it cover?
Why run an impact assessment before you commit resources?
When should you run the assessment, and how often should you refresh it?
What inputs do you need, and who should be involved?
The five dimensions of impact: what to check in each one
How do you run the assessment step by step?
Turning findings into mitigation, resourcing and communications
Common mistakes and how to calibrate a reliable assessment
How Oak & Nine applies impact assessment in practice
When does an impact assessment actually change a programme's outcome?
Get impact assessments moving faster with Oak & Nine
Further resources on running a change impact assessment
Sources

What is a change impact assessment and what does it cover?

A change impact assessment is a structured, systematic process used to identify and evaluate the potential consequences of a proposed change across people, process, technology, data and culture. It differs from stakeholder analysis, which maps who has influence or interest in a change. An impact assessment maps what actually shifts under each stakeholder group: which roles get merged, which handoffs break, which system loses a dependency, which report suddenly pulls from a different data source.

This distinction matters more than it sounds. Stakeholder analysis tells you who to talk to. Impact assessment tells you what to tell them.

Concrete effects worth chasing down include reporting lines that quietly change without anyone updating the org chart, workflows that assume a manual step someone forgot still exists, and data ownership that shifts from one team to another without a handover plan. A five dimensional lens, covering people, process, technology, data and culture, catches effects a narrower review would miss entirely, particularly the cultural ones that never show up in a project plan but decide whether people actually use what you built.

Why run an impact assessment before you commit resources?

Conducting a change impact assessment helps reduce resistance, avoid costly delays and improve adoption of change initiatives. That is the headline benefit, but the mechanics behind it matter more for anyone signing off budget.

An assessment done early gives you four things a project plan alone cannot:

Lower rework costs by catching scope problems while changes are still cheap to make
Prioritised mitigation, so effort goes where impact and likelihood are both high, not where the loudest stakeholder shouts
Better resourcing decisions, because training and communications plans get built against real affected numbers, not guesses
Stronger governance conversations, since sponsors can see impact evidence rather than take a project manager's word for it

Skip this step and you tend to find out the hard way, three weeks after go-live, when a team you never consulted discovers their workaround no longer works.

When should you run the assessment, and how often should you refresh it?

Run the first assessment early, in the diagnose or planning phase, while scope is still negotiable. Impact assessments are most effective when conducted early, largely because that timing preserves your ability to adjust course rather than just document the fallout.

A single assessment at kickoff is not enough for anything beyond a trivial change. Build in triggered reviews at three points: design completion, build completion and pre-implementation. Each milestone tends to surface details the original assessment could not have known, a supplier dependency, a data migration wrinkle, a stakeholder group that got added mid-project.

Update the assessment whenever scope, timeline or stakeholder composition shifts materially. Teams that treat the first version as final, rather than as a living document, are usually the ones explaining unplanned disruption to a steering committee after the fact.

What inputs do you need, and who should be involved?

An assessment is only as credible as the evidence behind it. Before scoring anything, assemble the following:

A change summary and scope statement setting out what is changing, what is explicitly out of scope, and by when.
Process maps showing current-state workflows for every process the change touches.
A system inventory, including integrations and data flows, so technical dependencies are visible before someone discovers one the hard way.
Data source documentation and org charts, covering ownership, reporting lines and access.
Stakeholder input from process owners, IT, HR, frontline representatives and, where relevant, suppliers or external partners.

Gathering that evidence rarely comes from a single source. Workshops surface the effects people feel day to day; structured interviews with process owners catch the exceptions nobody writes down; and for technical changes, dependency tracing and system traces reveal transitive impacts that no interview would ever uncover on its own. Skipping frontline representatives is the single most common gap, because the people closest to the work are usually the last people asked.

The five dimensions of impact: what to check in each one

A five-dimension framework, covering people, process, technology, data and culture, keeps an assessment from collapsing into a technology-only or process-only exercise. Each dimension needs its own set of questions.

People. Which roles gain, lose or merge responsibilities? What new skills are required, and by when? Does workload increase for any specific team, and do reporting lines change?

Process. Which process steps disappear, change sequence, or gain a new owner? Where do handoffs between teams change, and what exceptions to the standard flow need a documented fallback? Oakandnine's own people, process and technology framework is a useful lens for tracing these connections rather than assessing each in isolation.

Technology. Which systems are directly modified, and which are indirectly affected through an integration? Who loses or gains access, and what happens to any dependency nobody documented three systems ago?

Data. What needs migrating, what quality issues exist in the source data, and who owns the data after the change? Which reports or dashboards change their underlying source, potentially without anyone noticing until the numbers look wrong?

Culture. Which behaviours does the change ask people to drop, and which does it ask them to adopt? Does decision-making cadence shift, faster approvals, slower sign-off, and do collaboration patterns between teams change as a result?

Culture is the dimension most assessments shortchange, largely because it resists neat documentation. It is also usually the dimension that determines whether adoption actually happens.

The five dimensions of impact: what to check in each one — overview diagram

How do you run the assessment step by step?

A repeatable method beats a clever one. Use this sequence:

Define the change in a single paragraph: what's changing, why, and by what date.
Map the current state for every affected process, system and data flow.
List every affected group, department by department, not project workstream by workstream.
Assess each group against all five dimensions, scoring impact and likelihood separately.
Plot results on a severity grid and prioritise mitigation from there.

For scoring, pick a consistent scale before anyone starts rating anything. Numeric scales enable aggregation across a portfolio of changes, useful if you are running several change initiatives at once and need to compare them on one dashboard. A five-point scale gives more granularity for formal governance reporting; a three-point scale (low, medium, high) moves faster in a workshop setting and is often enough for smaller changes. Whichever you choose, write the criteria down before scoring starts, otherwise every assessor calibrates differently.

Pro Tip: Define what "high impact" actually means in writing, for example "affects more than 50 employees or requires a new skill within four weeks", before anyone opens the scoring sheet. Vague criteria produce inconsistent scores that fall apart the moment two assessors compare notes.

Build an impact-likelihood grid, five columns for likelihood, five rows for severity, and plot each affected group as a dot. Groups landing in the top-right corner get mitigation attention first; groups in the bottom-left get monitored, not ignored, but not resourced heavily either.

A quick worked example: a mid-market manufacturer consolidating two warehouse systems into one might rate its warehouse operations team as high impact, high likelihood (new interface, new daily workflow, immediate), its finance team as medium impact, medium likelihood (a reporting field changes, but only monthly), and its external logistics partners as low impact, low likelihood (no visible change to their interface at all). That single grid tells a steering committee exactly where training budget and communications effort need to go, without a single page of narrative.

Turning findings into mitigation, resourcing and communications

An assessment that stays in a spreadsheet has failed. The executive summary should state, in plain terms, which groups face high impact, what the top three risks are, and what decisions the sponsor needs to make now. Detailed appendices carry the dimension-by-dimension scoring, so technical reviewers can check the working without cluttering the summary.

Every mitigation action needs a named owner and a deadline, not a vague intention logged against "the project team". Link each finding directly to the plans it should shape: high people-impact groups get prioritised training slots; high technology-impact systems get extra testing cycles before cutover; high data-impact areas get a dedicated migration validation step rather than a shared one.

Bring the impact map and heatmap into governance meetings rather than a narrative slide deck. A grid showing exactly where severity and likelihood intersect gives sponsors something to interrogate, and it tends to produce sharper resourcing decisions than a written summary alone. For changes touching core systems, an integration roadmap helps sequence the technical mitigation work against the assessment's technology findings.

Turning findings into mitigation, resourcing and communications — overview diagram

Common mistakes and how to calibrate a reliable assessment

The most frequent error is assessing by project workstream instead of by stakeholder group. A workstream view tells you what the project delivered; a stakeholder view tells you who actually has to change how they work, and those are rarely the same list.

Other recurring problems worth guarding against:

Scoring before defining criteria, which produces inconsistent, incomparable ratings across assessors.
Losing the evidence trail, so nobody can later explain why a group was rated high impact.
Assessing changes in isolation when several concurrent initiatives are hitting the same teams, understating cumulative burden.
Skipping frontline input, which leaves blind spots exactly where disruption tends to land hardest.

Structured templates and clear rating criteria, agreed before scoring starts, fix most of this at the source.

Pro Tip: When two or more changes hit the same team in the same quarter, run a combined assessment rather than two separate ones. Cumulative impact is almost always higher than either change alone would suggest.

How Oak & Nine applies impact assessment in practice

Assembling the inputs, process maps, system inventories, org charts, is usually the slowest part of any assessment. A live organisational model that holds those inputs already connected allows mapping which roles, systems and data sources sit behind a proposed change faster than traditional interview scheduling.

Real-time insights surface dependencies that a static document would miss, a system integration nobody remembered, a process that quietly relies on a report that's about to change. That speed shows up directly in the outputs: impact maps and mitigation trackers generate from the model itself rather than getting rebuilt by hand for every change. Leaders exploring a pilot can review the Change Management Software: A Mid-Market Buyer's Guide for a practical starting point.

When does an impact assessment actually change a programme's outcome?

Most implementation friction I've seen traced back to one thing: the assessment got written once, filed, and never revisited. Early assessment matters, but iteration matters more, because the strongest change functions treat this as a living document, not a milestone deliverable. Assumptions made in week two rarely survive contact with week ten's reality.

If there's one habit worth adopting, it's validating every assumption against frontline data before it hardens into a plan. The groups closest to the work usually spot the gap the org chart never showed you.

— Ronan

Get impact assessments moving faster with Oak & Nine

This platform provides mid-market leaders a live model of the organisation where roles, processes, systems and data are already connected, so the inputs to an impact assessment are ready before the workshop starts, not assembled from scratch during it.

Managing directors, operations leaders and HR teams running frequent organisational change get the most out of this, because every new assessment builds on the last one instead of starting cold. Findings, impact maps and mitigation trackers stay connected to the underlying model, so when scope shifts, the assessment updates with it rather than falling out of date within a fortnight. If you're planning a change that touches multiple teams, explore what the platform offers operations leaders or visit Oak & Nine to request a pilot walkthrough of the model in action.

Further resources on running a change impact assessment

For deeper reading on frameworks and scoring methods, the University of Exeter's change impact framework and The Change Compass practitioner guide cover template design and severity grids in detail. For risk scoring that complements impact ratings, see this risk assessment guide.