Managing Change

Spec 3.3.6.1 names five factors that determine whether a change programme actually succeeds, and expects you to be able to use all five, not just the two — resistance, leadership — that tend to get the most attention in revision guides. The first is organisational culture: a firm's shared, mostly unwritten expectations about how things are done here. This course's earlier lesson on corporate culture (3.3.4.1) already derives why an established culture is hard to change: each person's own behaviour is a rational response to what everyone else currently does, so a written rule can change overnight in a way the actual pattern of behaviour cannot. Here, the same mechanism resurfaces as a named constraint on change specifically — a strong existing culture doesn't just resist a new mission statement, it resists a new process, a new reporting line, or a new performance target, for exactly the same reason.

The second factor is the size of the organisation. A ten-person start-up and a 40,000-employee multinational can announce an identical change on the same day and still see it land at completely different speeds, for two compounding reasons. First, a mechanical one: the instruction has to travel through more layers of management in the larger firm before it reaches every employee, and each additional layer is a chance for the message to be delayed, softened, reinterpreted, or quietly slow-walked — a message passed through ten hops rarely arrives exactly as it left. Second, a structural one: a large organisation typically has more formalised processes, and more people whose role depends on the process staying as it is, so changing it means renegotiating more of the firm's actual machinery, not just issuing a new instruction. A small, owner-managed firm usually has neither problem — the decision-maker and the person acting on the decision are often the same small group of people, sometimes the same person.

The third factor, time/speed of change, is a genuine trade-off, not a simple 'faster is always better' or 'slower is always better' rule. Moving fast shortens the costly limbo period where the old and new systems overlap, and gets the firm to whatever benefit the change was meant to deliver sooner. But speed also removes the one resource that three of the four resistance-management responses below actually need in order to work: education takes time to deliver properly, participation takes time to consult properly, and negotiation takes time to reach a genuine agreement. Only force doesn't need time — which is exactly why a rushed change programme disproportionately ends up relying on compulsion, and disproportionately generates the resistance that goes with it.

The fourth factor, managing resistance, is the one this lesson builds out in full below, because it's the one the spec names without giving any structure to hang it on. Resistance itself — a slowdown, quiet non-compliance, an outright complaint — is a symptom, and the same symptom can be produced by at least four structurally different causes: losing something familiar and valued (status, routine, relationships); fearing that a specific skill you currently rely on is about to become worthless; genuinely disagreeing, on the evidence, that the change is actually a good idea; or simply preferring the lower effort of staying put, with no deeper objection underneath it at all. Naming which of these four is actually driving a given case of resistance — not just naming that resistance exists — is the whole content of the mechanism and worked example that follow.

A real exam extract puts numbers on exactly the resistance side of this trade-off, even though the question that supplies it isn't itself framed as a 'managing change' question by name. Pearson's October 2025 WBS13 paper set a 12-mark Assess question on Tesla — 'Assess the possible strengths and weaknesses for Tesla of its strategic decision to reduce the size of its workforce' (Q1e) — with real, quantified indicative content on both sides of the trade-off this lesson's size and resistance factors describe in the abstract. On the strength side: 'cutting 14,000 jobs will lower Tesla's operational costs, helping the company save on salaries, benefits and other associated expenses,' and 'streamlining the workforce by eliminating duplicated roles can lead to more focused and efficient operations.' On the weakness side, exactly the resistance consequences named above: 'job cuts can lead to a decline in employee morale and productivity among remaining staff, as they may fear further layoffs or feel less secure in their positions'; 'large-scale job cuts can damage Tesla's reputation as an employer, potentially making it more difficult to attract top talent in the future'; 'the reduction in the workforce could disrupt production processes, particularly if key roles are eliminated or if the remaining employees are overburdened'; and a real, named market reaction — 'the announcement of job cuts has already led to a 3% drop in Tesla's share price, reflecting investor concern about the company's future prospects.' Treat this as real-world texture for the size-of-organisation and resistance factors above, not as an exam-verified 'key factors in change' question in its own right — the question evaluates Tesla's HR decision generically and never invokes education, negotiation, participation or force by name, which is exactly why 3.3.6.1 remains this paper's thinnest-evidenced sub-topic even with this addition; see the trap-taxonomy block and this lesson's closing flag for exactly what that distinction changes.

The fifth factor, transformative leadership, is a leadership approach built around a compelling vision of what the organisation is becoming, connected explicitly to what staff themselves value — aiming to change what people genuinely want, not just what they're paid or instructed to do. It's specifically useful against the first factor on this list: a leader who only manages within the existing reward structure (a transactional approach) can't easily shift the culture that structure was built around, because the rewards themselves are calibrated to the old norms; a transformative leader resets the reference point instead. The theory behind this, and why the spec's own phrase 'transformative' and the academic literature's more common 'transformational' describe the same underlying idea, is developed further in the enrichment section below.

These five describe what makes a change land or stall once it's already underway — but a scenario question just as often turns on naming what actually triggered the change in the first place, and Pearson's own published teaching guidance for this unit sets out the same handful of recurring triggers, each with its own specific issues for managers, distinct from the five factors above. Organisational growth, such as expansion into a new international market, raises issues of communication, performance management, training, motivation, labour costs and impact on culture. Poor business performance — falling sales, lower-than-expected profits, rising costs, slower expansion than planned — raises the need to improve performance and often to revisit objectives and strategy altogether. A change of ownership (a merger, a takeover, converting from a private to a public limited company, or a management buy-out) raises role duplication, culture clash and brand-management issues specifically, not just the generic resistance the culture factor above already covers. And a shift in the market or the wider external environment — a new entrant, a competitor exiting, both linking back to Porter's Five Forces — typically forces a change in corporate objectives, strategy, R&D spending and brand positioning. A strong scenario answer names which of these specific triggers is actually driving the change described in the stimulus, not just which of the five general factors is making that change harder to land.

Spec 3.3.6.2 splits contingency planning into two genuinely separate stages, and treating them as one step is the most common way to under-answer a question on this topic. Risk assessment (3.3.6.2a) is the identification stage: naming which specific threats the business actually faces. The spec names three examples — natural disasters, IT systems failure, and loss of key staff — not as an exhaustive list. Of those three, this course's research pass could directly confirm actual exam questions for two: IT systems failure (British Airways, Oct 2021) and loss of key staff. Loss of key staff is, in fact, the one risk category with confirmed exam evidence for BOTH of 3.3.6.2's stages, from two different companies. Pets at Home's question, below, is squarely a risk-MITIGATION question — succession planning, decided once a departure is already being treated as a given. A separate, more recent question is squarely risk-ASSESSMENT instead: Tesla, Q1(d), Oct 2025, 12-mark Assess — 'Assess the extent to which the use of a risk assessment might have avoided the loss of key staff at Tesla.' The verified mark scheme (WBS13_01_2510_MS) builds its indicative content around three real, named departures — Zhu, who 'managed manufacturing at key facilities'; Otto, who 'was in charge of product launches'; and Baglino, whose exit after 18 years with the company the extract itself calls a 'difficult decision' — and credits a risk-assessment-side mechanism genuinely distinct from anything already in this lesson: a risk assessment 'could have helped Tesla spot problems that might cause key staff to leave... such as job dissatisfaction or burnout' early enough to address them, and could have 'highlighted areas where Tesla needed to improve to retain key staff, such as better work-life balance, competitive compensation or career advancement opportunities' — naming the retention risk before it costs the firm a specific person, not just planning a replacement after the fact. The same mark scheme is just as explicit about this mechanism's real ceiling, and it's a genuinely different limitation from BA's 'plans need to be regularly tested and updated' point above, because this one is about what a risk assessment can discover in the first place, not about maintaining a plan once a risk is identified: 'the electric vehicle industry is rapidly evolving and even the best risk assessments might not have predicted the quick changes or offers from competitors' behind departures like these, and 'individual decisions to leave... are often influenced by personal factors that a risk assessment might not be able to predict or prevent, making some departures inevitable.' No natural-disaster exam question was located in the six series checked, so treat that category as spec-accurate but not exam-verified — see this lesson's closing flag. This unit's scheme of work (a separate Pearson document, listing suggested teaching activities and examples rather than exam content) points teachers toward the standard real-world illustration for this exact category: the March 2011 Tōhoku earthquake and tsunami, which closed Toyota's Japanese plants for close to two months, and — because so many of Toyota's component suppliers were themselves concentrated in the affected region — went on to disrupt Toyota's assembly plants outside Japan too within weeks, well beyond the specific site the disaster struck. Treat this the same way as the rest of this risk category: spec-accurate grounding sourced from the scheme of work, not an exam-verified case. Risk mitigation (3.3.6.2b) is the separate, second stage: having a specific plan in place before the risk materialises, not just having identified that it could. A firm that has written a report naming its flood risk has completed risk assessment; it has not completed contingency planning until it also has a mitigation plan for that specific risk.

Before reaching for a specific tool, it's worth being able to name the general strategic posture a business is actually taking toward a given risk — Pearson's own published teaching guidance for this unit sets out four: risk acceptance, where the cost of mitigating a risk is judged to exceed the cost of the risk itself, which is why very small businesses often simply accept a risk a larger firm would spend money managing; risk avoidance, stopping the risky activity altogether — a multinational withdrawing entirely from a politically unstable market rather than trying to manage the risk of staying; risk limitation, the most commonly used strategy of the four, which reduces a risk's impact without removing its cause, such as keeping data back-ups so a systems failure becomes a short interruption rather than a long outage; and risk transference, paying a third party to carry the risk instead — from outsourcing payroll and customer service to buying insurance, which is exactly the link to the moral-hazard mechanism below. Business continuity and succession planning, covered next, are specific, targeted applications of this framework for the two risk categories spec 3.3.6.2(a) names directly — not the whole of what 'risk mitigation' means.

Within that framework, the spec narrows down to two specifically-named tools for the risk categories it lists — business continuity and succession planning — and, as the mechanism below derives, they're not interchangeable general-purpose 'backup plans': each is built for a different type of risk, and using the wrong one for a given risk is a real, avoidable way to under-answer a scenario question on this content.

But contingency planning is not a costless guarantee, and the paper's own anchor question on this content — 'assess the EXTENT TO WHICH contingency planning might have reduced the risk of an IT systems failure for a business such as BA' — is phrased that way precisely because the honest answer is 'partially, not fully.' Two real limits apply to any contingency plan, not just BA's. First, a plan only stays useful if it's actively maintained: testing and updating it as systems, staff and threats change is a recurring cost in time and resources, not a one-off — a plan written years ago for a since-replaced IT system is close to worthless against next month's failure. Second, and more fundamentally, a plan can only cover the specific failure modes someone thought to plan for; it cannot, by definition, anticipate every way a system might actually fail. BA's own repeated IT failures despite the airline conducting regular risk assessments make this concrete: a firm can be doing genuine, ongoing contingency work and still be hit by a failure its planning didn't specify, which is exactly why 'has a contingency plan' and 'is protected from this risk' are not the same claim. A Level 4 answer to an 'extent to which' question has to weigh this real ceiling against the benefit side above — not to conclude contingency planning is worthless, but to reach a genuinely supported judgement on how much of the risk it actually removes, rather than treating 'yes, it helps' as if that settled the question the command word is actually asking.