13.2 Step 1: Categorising Impacts and Identifying Impact Areas

Sub-step 1.1: Categorising change impacts

CM3 identifies three categories of impact:

Intended change

The vision of the new world, the removal of barriers to get there, and the disruption to productivity while absorbing the change. This should include consideration of areas out of scope or not impacted by the change.

Two things are worth noticing. First, disruption to productivity while absorbing the change is classified as intended — it is an expected, planned consequence, not an accident. This is the learning dip, and treating it as intended means it should be budgeted for rather than reported as a problem.

Second, the instruction to consider areas out of scope or not impacted. Recording explicitly what does not change serves two purposes: it prevents scope drift, and it directly supports Bridges' endings guidance about letting people know what will not change.

Unintended or unplanned change

System outages, process workarounds and misdiagnosed behavioural responses are examples of these.

This is systems thinking made operational. Unintended change is a formal category because it is expected to occur, not because it is a failure. "Misdiagnosed behavioural responses" is an interesting inclusion: it covers the situation where the change team reads a behaviour incorrectly — treating an ability gap as resistance, for example — and the resulting mismatched intervention becomes an impact in its own right.

Change management activities

The involvement of subject matter experts, time spent in scheduled training or in coaching change networks will impact business as usual.

This category is routinely omitted from impact assessments and it should not be. Change management work consumes the same finite operational capacity the change is trying to protect. Every hour an SME spends advising the change team is an hour not spent on their job; every training day is a day of reduced output; every change agent working alongside their day job is carrying two roles.

Counting this honestly changes plans. A change that looks affordable when only the intended impacts are counted may not be once the change activity's own footprint on business as usual is added — which is precisely the kind of finding that belongs in a severity assessment.

Sub-step 1.2: Identifying impact areas with McKinsey 7-S

CM3 uses the McKinsey 7-S model to identify which areas of the organisation are impacted:

Watch the definitions

Two pairs cause confusion.

Systems here means daily activities and procedures that individuals engage in to get the job done — working practices and procedures, not IT platforms. A statement like "there are defined working practices and procedures in place" describes Systems in this model. This is a different sense from Carolyn Taylor's systems, which are the management mechanisms that control, plan, measure and reward.

Staff and Skills are closely related and easy to blur. Staff is about the employees and their general capabilities — who is there, in what numbers, with what roles. Skills is about the abilities and capabilities those employees hold. A change that requires more people is a Staff impact; a change that requires different expertise from the same people is a Skills impact.

Why 7-S is used here

Using 7-S as an impact checklist forces assessment beyond the obvious. A team assessing a new system will identify Systems and Skills impacts without prompting. They will less often notice that the change alters Structure because approval routes shift, or Style because the new process assumes delegated decision-making that the current leadership style does not support, or Shared values because it changes what the organisation implicitly says it prioritises.

Working through all seven deliberately is a cheap way to surface impacts that would otherwise emerge mid-delivery as surprises.

Working the categories in practice

The three categories are most useful applied as three separate passes over the change, because each surfaces different material.

Pass one — intended. Walk the future-state process end to end and record what is deliberately different: tasks that disappear, tasks that appear, decisions that move, handovers that change. Record explicitly what stays the same, since that is both scope control and a message people need.

Pass two — unintended. Ask what else touches the parts you just changed. Which downstream team receives the output? What currently absorbs exceptions? What informal arrangement depends on the step being removed? This is systems thinking applied deliberately, and it is the pass most often skipped because it has no obvious boundary.

Pass three — change activity. Cost the change work itself against operational capacity: SME hours, training days, change agent time, engagement sessions. Convert it to the units the business recognises — days out of the rota, shifts uncovered — rather than leaving it as an activity list.

Running the passes separately matters because a single combined workshop reliably produces a long list of intended impacts and almost nothing from the other two categories.