Resource guide · Transformation and Risk

Change Management for Regulated Organisations

A practitioner’s guide to the people side of delivery. Stakeholder engagement, communications, training, resistance, and embedding, written for the kind of organisation that has to land change well.

Introduction

Most programmes that fail in financial services do not fail because the technology was wrong. They fail because the people the technology was built for did not adopt it, did not adopt it consistently, or adopted it badly. The systems went live on time. The processes were documented. The training was delivered. And the operating environment that emerged on the other side was not the one the programme was designed to produce.

This is where change management matters most. It is the discipline between technical delivery and operational reality. Done well, it is the difference between a programme that is adopted and one that simply delivers an output. Done badly, or left too late, it is one of the main reasons major investment in regulated organisations produces disappointing results.

This guide is written for people running change in regulated organisations: programme managers, change leads, business heads accountable for areas going through change, senior managers operating under accountability regimes, and consultants or contractors supporting delivery. It assumes practical experience in delivering financial services and focuses on the disciplines that matter most in regulated environments.

Three features of regulated change shape almost everything that follows. The change is often not optional, because it is driven by a regulatory obligation rather than a commercial choice. The people affected are usually experienced professionals with strong operational judgement, not passive recipients. And the accountability around senior managers means poor adoption does not stay at the programme level. It lands on named individuals.

Taken together, those features make this a discipline that has to work hard in practice. Engagement has to be substantive because professionals do not respond well to corporate script. Training has to build documented capability, because the evidence may need to stand up under review. And embedding has to be planned and resourced, because drift often shows up later in assurance work, audit, or supervisory feedback.

The discipline is teachable. It draws on a well-developed body of literature, including the Prosci ADKAR model, Kotter's eight-step framework, and the Bridges transition model. The guide refers to these, where they earn the reference. The body of the guide, though, is about what the principles look like in practice when the organisation is large, regulated, and running multiple programmes simultaneously.

What change management actually is, and what it is not

Change management as a discipline has accumulated a lot of baggage. The phrase has been used to mean everything from organisational restructuring through stakeholder communications to a workstream label inside a programme plan. That ambiguity is a problem because the activities being referred to differ in kind and are managed in different ways.

The working definition this guide uses is narrow and practical. Change management is the discipline of moving an organisation and its people from one operating state to another in a way that produces sustained adoption of the new state. It is not the change itself. It is not the technology. It is not the policy. It is the work of ensuring the people who have to operate in the new state actually do so consistently, with the capability and support they need.

What sits next to it

Three adjacent disciplines need to be named because they are often confused with change management, which leads to poor outcomes.

Project and programme management deals with delivering the change, scope, schedule, dependencies, risk, governance, technical build, testing, and go-live. Change management is not a substitute for project management. It is a parallel discipline that takes the deliverable being built and prepares the receiving environment to operate it well.

Organisational design deals with how the organisation is structured. Roles, reporting lines, team boundaries, and accountabilities. A change programme may produce organisational redesign as one of its outputs, but the design work itself is a different activity, with different skills and a different governance trail.

Culture sits underneath all of it. Culture is the accumulated pattern of how the organisation actually behaves when decisions have to be made. Culture change is not a programme. It is the long-term consequence of consistent leadership behaviour, reinforced by what gets rewarded and what gets tolerated. Change management interacts with culture, but it cannot do the work of culture change inside a programme timeline. That confusion produces a familiar pattern: a culture workstream gets bolted into a programme, ticks every activity box, and changes nothing.

The frameworks worth knowing

Four frameworks turn up repeatedly in change management practice. None of them is a substitute for thinking, and none should be used to organise this guide. But each offers something practical, and a programme manager who understands what each is doing will read change management situations more accurately.

Lewin's three-stage model is the historical foundation: unfreeze, change, refreeze. The current state has to be loosened before change can take hold, and the new state has to be locked in before it becomes durable. The model is simple to the point of being thin, but the underlying insight, that change requires both forward motion and active stabilisation at both ends, runs through everything that came later.

Kotter's eight-step model is the most-cited in the executive and consulting literature. Create urgency, build a guiding coalition, form a vision, communicate the vision, empower action, generate short-term wins, sustain acceleration, institute change. It is well-suited to strategic, leadership-driven transformation. It is less useful in regulated settings, where the urgency is supplied by the regulator and the vision is supplied by the regulation. The first three steps tend to be box-ticked.

The Bridges transition model addresses something the technical frameworks underplay: the psychological dimension. Bridges separates the external change (the new system, the new policy, the new role) from the internal transition (the experience of letting go, of being in the in-between, of starting to inhabit the new): endings, neutral zone, new beginnings. For regulated change, where professionals are being asked to give up established ways of working they may have spent decades refining, the Bridges lens is useful. Resistance is often a sign that someone is still in the ending phase. Treating it as an obstruction misses what is actually happening.

The Prosci ADKAR model is the most operationally useful, particularly in regulated environments. ADKAR identifies five things an individual needs to move successfully through a change: Awareness of why the change is happening, Desire to participate and support it, Knowledge of how to do the new thing, Ability to apply that knowledge in practice, and Reinforcement to make the change stick. The value is not in the acronym. It is in the diagnostic question the model invites: when a change is not landing for someone, which of the five is missing? An awareness gap is solved by communication. A desire gap is solved by addressing the reasons for resistance. A knowledge gap is solved by training. An ability gap is solved by practice and support. A reinforcement gap is solved by sustained leadership attention. Treat all five as the same problem, and you waste effort on the wrong intervention.

What change management is not

Three patterns matter in practice.

Change management is not a communications campaign. Communication is a tool the discipline uses. It is not the discipline itself. A programme that defines change management as a poster, an intranet page, and a town hall has not done change management. It has done internal marketing.

Change management is not a workstream that appears near the end of delivery. Calling it a workstream is often part of the problem. It suggests this is something done alongside the build, rather than built into the design and running of the programme from the start. The way the programme works with the business involves stakeholders in design, times its communications, and builds training, all of which shape whether the organisation adopts the change. If this work starts late, design decisions are already fixed, resistance is already present, and the chance for real engagement is much smaller.

Change management is not an HR exercise. It is not exclusively about the people and culture function, although that function may contribute to it. It is a delivery discipline, owned by the programme, drawing on whichever functions and capabilities are needed to land the change well. Treating it as something HR does to the business produces a programme in which communication, training, and engagement happen in a separate building from delivery, never quite synchronised, often working from different assumptions.

Stakeholder management in regulated organisations

Stakeholder management is one of the most important determinants of programme success, and one of the most consistently under-resourced activities. The people affected by a transformation programme are not simply recipients of change. They are sources of knowledge about how the current state actually works, they are the people whose cooperation is needed to make the new state function, and they are the people who will either support or resist the change in ways that determine whether it lands.

Mapping is the foundation, not the deliverable

Stakeholder mapping at the outset of a programme is a discipline most programmes do at least nominally. The output is usually a chart with names, roles, and colour-coding for influence and interest. Then the chart is uploaded to the programme repository, and nothing further happens to it.

The map is not the point. The point is the work that the map supports: targeted engagement based on a genuine understanding of who is affected, how, with what authority, and with what current disposition. A map that is not updated through delivery and not used to drive engagement decisions is a documentation exercise.

A useful map captures four dimensions for each significant stakeholder or stakeholder group: who they are and what role they play in the change; what the change means for them in practical terms; what authority they have over the programme's success; and what their current disposition is. Disposition is the dimension most consistently glossed over. Supportive, neutral, sceptical, opposed. Programmes that pretend everyone is supportive at the outset find themselves doing damage control by surprise six months in.

The accountability dimension

In regulated organisations, stakeholder maps need to take account of personal accountability. In the UK, the Senior Managers and Certification Regime places clear individual responsibility on senior managers for the areas they oversee. Australia has a comparable accountability regime through the Financial Accountability Regime. New Zealand takes a different approach, using governance, licensing and conduct obligations rather than a direct equivalent of SMCR. This changes the stakeholder dynamic in important ways.

A senior manager whose area is being changed by a programme is not just a stakeholder. They are an accountable individual whose responsibility extends to ensuring the change is implemented properly in their area. They need to understand the change in enough depth to discharge that accountability. They need access to the programme's decision-making, not just its outputs. And they need to be able to escalate concerns through their own accountability route, not just through the programme's governance.

Stakeholder maps that do not identify the accountable senior managers, what they are accountable for, and what they need from the programme to discharge their accountability are missing the dimension that matters most. The work of supporting accountable senior managers is sometimes called sponsor management. The phrase understates what is going on. A senior manager exposed to a duty of responsibility issue because a change programme delivered something they did not fully understand is in a different position than a generic sponsor.

Different stakeholders need different things

One of the most consistent failures in stakeholder management is treating all stakeholders as if they need the same thing from the programme. They do not.

Senior leaders need to understand the strategic rationale and their accountability. Operational managers need to understand the impact on their teams and how they will be supported through the change. Front-line staff need to understand what will change for them in practice and what support is available. Specialist functions, particularly compliance, legal, and risk, need to understand the regulatory implications and the design choices being made. Each group needs different information, at different points in the programme, through different channels.

A communications plan that treats all of these audiences the same, with the same all-staff email and the same intranet page, will fail all of them. Senior leaders find the content too detailed and operational. Front-line staff find the content too strategic and abstract. Specialists find the content insufficient for their assurance role. The programme has communicated extensively, and nobody has what they need.

Engagement is a relationship, not a transmission

There is a meaningful difference between communication and engagement, and it is worth being precise about. Communication delivers information from the programme to the stakeholder. Engagement builds a relationship through which information flows both ways, concerns are surfaced, and the stakeholder is involved in shaping decisions they have a stake in.

Programmes that communicate well but do not engage well usually underperform. The pattern is familiar in delivery. Stakeholders are surprised by decisions that were supposedly announced earlier. Concerns reach the steering committee when they should have been resolved in design. Resistance appears late, hardens quickly, and is harder to address than it would have been if it had surfaced earlier.

Engagement takes time; the programme often does not feel it has. Meeting with operational leads to understand the realities of their current state. Working sessions with the people who actually run the process are being changed. Workshop-based design rather than design-by-document. Each of these is slower at the front end than a communications-only approach. They are dramatically faster overall because they surface the issues that would otherwise turn up in user acceptance testing or, worse, after go-live.

The professionals' problem

Most change management literature is written about generic organisational change, applicable across industries. It tends to assume a stakeholder population that is broadly homogeneous, broadly compliant, and broadly responsive to corporate messaging. Regulated financial services organisations are not that.

The people absorbing the change are usually professionals: traders, MLROs, credit officers, risk managers, compliance specialists, lawyers, and technologists. They have deep operational expertise in their domain, often deeper than anyone on the programme team. They have strong views, sometimes deeply held, about how the work should be done. They have professional pride that engages or disengages in response to quite specific signals. And they are usually too busy to engage with the programme on the programme's terms unless they see why it is worth their time.

This shifts the engagement approach. Generic corporate communications land poorly. Town halls with leadership platitudes land poorly, workshops where the programme tells the experts what is going to happen land worst of all. What works, and what most programmes do not invest enough in, is genuine consultation: structured engagement that recognises the expertise of the people being affected, makes meaningful use of their input in the design, and shows the change of design that resulted from the input. Done well, this turns potential resistors into informed advocates. Done badly, or skipped entirely, it produces a programme that is technically delivered and operationally rejected.

Communications design across the programme lifecycle

Communications across a programme lifecycle is more than a series of messages. It is a designed sequence, segmented by audience, paced against the delivery plan, and continuously adjusted based on what is landing and what is not. Most programmes do this badly, and the reasons are familiar: communications is treated as a content production exercise, the audience is treated as a single block, and the rhythm is set by the programme calendar rather than by what the audience needs at each point.

Segment by audience, sequence by phase

The starting point for communications design is the segmented audience map produced from stakeholder analysis. Each audience needs its own communications plan: what they need to know at each phase of the programme, through which channels, with what frequency, with which leader visibly attached, and with what mechanism for feedback. The plan is not a calendar of events. It is a designed flow that anticipates the questions each audience will be asking at each phase, and provides the answers before the absence of answers becomes the story.

Sequencing matters because the questions change. Early in the programme, the dominant questions are why and what: why is the change happening, what is being changed, who is leading it. Middle of the programme: how and when. How will it work, when will it land, what does it mean for my role. Late in the programme: what do I need to do, where do I get help, what changes on day one. After go-live: how is it going, what is being learnt, what is next.

Communications that stay stuck on the first phase, repeating the strategic rationale long after the audience has moved past it, lose credibility. Communications that skip the early phases and start with implementation detail leave the audience without the context they need to interpret what they are being told. Sequencing failure is one of the most common sources of programme communications fatigue.

The sponsor speaks

Across major change management research, one finding is consistent: active and visible senior sponsorship is a leading predictor of successful adoption. Prosci's benchmarking research has identified it as the top contributor to success across successive studies.

Active visible sponsorship has a specific meaning. It is not a sponsor who signed the business case at the outset and then handed delivery to the programme team. It is a sponsor who shows up. Who speaks to the change personally and credibly. Who attends key milestones. Who is willing to have the difficult conversation with a peer who is resisting. Who is associated, in the eyes of the affected population, with the change itself rather than with the programme that is delivering it.

The communications plan has to make this real. Sponsor visibility is not a side product of the plan. It is one of the inputs the plan is designed around. If the sponsor cannot make time for the role, the programme needs to surface that early, because the consequences of an absentee sponsor are not a communications issue. They are an adoption issue, and they will produce a poor result regardless of how good the communications team is.

Cascade and the middle layer

Communications that go directly from the programme to the entire affected population over the heads of line management produce predictable problems. People hear about the change from a faceless programme rather than from their own manager. The manager is left explaining a change they have not been adequately briefed on. The signal that the change is being driven from outside the line of management becomes part of the story, and not a helpful part.

Effective communications cascade through the management structure. The senior leader speaks to their direct reports. The direct reports speak to their teams. The team leaders speak to the front line. At each level, the communication is adapted to what that audience needs, but the message stays consistent.

This is harder than it sounds, for two reasons. The first is that each layer needs to be briefed, equipped, and supported. A cascade communications plan without proper briefing of the middle layer is a broken phone game. The second is that the middle layer in many organisations is the most under-invested part of the management structure. They are expected to lead the change in their teams without receiving the support, the briefing, or the development that the executive layer above them receives. The programme that recognises this and invests in middle-management enablement consistently produces better adoption than the programme that does not.

Channels match the message

Different messages need different channels. The decision to go live with a new system at a specific date is not an intranet article. It is an email from the sponsor, followed by team-level briefings, followed by training, followed by visible support during the cutover. A complex policy clarification is not a town hall. It is a written explanation, with worked examples, available for reference at the point of decision. An update on programme progress is not a video message. It is a short written report with metrics.

Programmes that default to a single preferred channel, usually because that is what the corporate communications function is set up to deliver, produce communications that are well-produced but poorly suited to the substance being communicated. Channel choice is part of the design, not an afterthought.

Two-way is not a survey

Most communications plans include a section on two-way communications, and most of those sections amount to a quarterly engagement survey. That is not two-way communication. It is feedback collection on a delayed cycle, processed by aggregation, and rarely visible in subsequent programme decisions.

Genuine two-way communication needs mechanisms that operate continuously and produce visible response. Open question and answer sessions where the programme team takes hard questions and answers them on the record. Listening posts in the business, where members of the programme team spend time with affected teams and report back what they have heard. Pulse checks that produce action, not just data. And the most important test: when concerns are raised, do they produce a visible change in what the programme is doing, or do they get absorbed and ignored? The answer to that question, in the eyes of the affected population, determines whether the next round of engagement gets honest answers or polite ones.

Training: building capability, not knowledge

Training is the change management activity most consistently misdesigned in regulated organisations. The most common pattern is content-led design: build training around what the new system does or what the new policy says, deliver it through the channel that fits the project timeline, capture completion records, move on. This produces training that satisfies a compliance requirement and does very little for adoption. The training has happened. The people who received it cannot reliably do their job under the new arrangement. The programme has met its training milestone and missed its training purpose.

Start with the capability, not the content

The right starting point for training design is what people need to be able to do, not what the system does. A trader using a new front-office system needs to be able to enter trades correctly, recognise the conditions in which the system will and will not behave as expected, respond appropriately when a trade does not flow through, and escalate when something looks wrong. An MLRO operating under a new reporting workflow needs to consistently assess internal disclosures, decide whether to prepare external reports, document the decision, and operate within the time pressures the new workflow imposes. A credit officer applying a new lending policy needs to be able to apply it in the cases the policy was clearly designed for, recognise the cases it was not, and escalate the latter to the right authority.

Training design that starts with these capabilities, then works backwards through what someone needs to know to achieve them, then builds the learning experience that gets them there, produces fundamentally different content than training that starts from the policy text or the system manual. A capability-led design is shorter, more practical, more focused on edge cases, and more directly assessable. It produces learners who can do the thing the training was for.

The regulatory weight of training

In regulated organisations, training carries weight that is absent in generic settings. Where the change relates to a regulatory obligation, training records may need to be produced under examination. A supervisor or auditor will not just want to know that training happened. They will want to know who attended, what was covered, whether competence was assessed, what was done about staff who failed the assessment, and how often the training is refreshed. Regulation 24 of the Money Laundering, Terrorist Financing and Transfer of Funds (Information on the Payer) Regulations 2017 requires relevant employees and agents to be made aware of the law, to be trained regularly, and to be recorded in a written training record. Under the Senior Managers and Certification Regime, firms must assess the fitness and propriety of senior managers and certification staff, and certification for certification staff must be renewed at least annually. Firms must also train staff who are in scope of the Conduct Rules so they understand how the rules apply to them.

This changes the training design problem. It is not enough to deliver content; the design has to produce records that demonstrate competence has been achieved. Completion of an online module is recorded. It is not a record of competence. Where the regulation requires competence, the training must include an assessment, and the assessment must be substantive enough to provide evidence the firm can stand behind.

The design implication is that regulated training generally needs three elements: substantive content, structured assessment, and a documented response to failure. The third is often missing. Programmes design good content and good assessment, then have no process for what to do if someone fails. The result is staff operating in a role for which they have not demonstrated competence, yet their record says they have.

Timing

The timing of training is as consequential as the content. Training delivered too early is forgotten before it is needed. Training delivered at go-live, when people are also absorbing the operational pressure of implementation, lands badly. Training delivered after go-live, when staff are already operating the new process imperfectly, creates a hard-to-remediate adoption pattern in which the wrong way of working has become the established way.

The right timing depends on the role, the complexity of the change, and the learning approach. For complex changes affecting front-line staff, a layered approach often works better than a single intervention. Awareness training months before go-live, to build context. Practical training in the weeks before go-live, close enough to be remembered. Floor walking and one-to-one support during the first weeks after go-live to consolidate learning through practice, and refresher training at the first natural pause to address common issues that have emerged.

Most programmes default to whatever timing fits the project timeline. That is the wrong answer. The timing should be designed to meet the audience's needs at each phase. If the project timeline cannot accommodate the right training timing, the project timeline needs to absorb the conflict, not the training plan.

Role-specific design

Generic training that covers everything is one of the most consistently disappointing investments in change management. The cost is high, the content is necessarily watered down to suit the broadest audience, and the relevance to any specific role is low.

Role-specific training takes more design effort. The starting point is segmenting the affected population by what they need to be able to do differently. The output is a set of training products, each tailored to a specific role or role group, drawing on genuinely common content but delivering the role-specific material in role-specific form.

The investment pays off in adoption. A trader trained on what a credit officer needs to know is wasting both their time and the programme's. A trader trained on the front-office workflow, with realistic worked examples and the escalation procedures specific to their book, is in a position to operate the new system from day one. The same applies in compliance, operations, customer service, and any function where the change has different implications for different roles.

Methods that work

The method that works depends on the role, the complexity, and the size of the affected population. In practice, a few methods work consistently in regulated environments.

For knowledge content that needs to reach a large population at relatively low cost, online modules with structured assessment work well. The design discipline matters: short modules, frequent assessment, role-specific content, and clear records. Generic e-learning that runs forty-five minutes and ends with a tick-box quiz is well known to produce poor outcomes.

For complex changes affecting smaller specialist populations, instructor-led training is often appropriate. The design discipline is to use time on activities that benefit from direct interaction: working through edge cases, discussing escalation criteria, and practising decision-making under realistic conditions. Lecturing on content that could have been read is a waste of expensive time.

For operational changes affecting front-line staff, simulation and practice are often more effective than either online or classroom training. A new claims handling system, a new customer onboarding workflow, and a new payments process all benefit from training that puts the trainee in the situation with realistic data and lets them work through it with support. Floor walking and one-to-one support in the first weeks of operation extend this approach into the live environment.

For all of these methods, the assessment is what matters. Training without assessment produces a record of attendance. Training with substantive assessment, including consequences for failure and a remediation route, produces a record of competence. The latter is what the regulatory environment requires.

Resistance and how to read it

Resistance is the subject of change management most consistently mishandled in practice. The default treatment is to view it as an obstruction, something to be overcome, neutralised, or worked around. This framing misses what is actually happening, and misses an important source of intelligence about what the programme is doing wrong.

Most resistance, in well-run programmes in regulated organisations, is not bad faith. It is information. It is a signal that something in the change, or in how the change is being landed, is not working for the people who have to operate in the new state. Treating it as a problem to be managed rather than information to be understood produces a recurring pattern: resistance gets suppressed, the suppression gets called success, and the underlying issue surfaces after go-live as poor adoption.

The legitimate concern

A significant proportion of resistance in regulated change comes from people who know something the programme has missed. The trader who notices that the new workflow does not handle a specific transaction type. The compliance specialist who recognises that the proposed control will not survive supervisory scrutiny. The operations manager knows that the plan's timing assumption is unrealistic given the team's other commitments. The senior manager sees a duty-of-responsibility issue arising in the way the change is being structured.

Each of these is a legitimate concern. None of them is an obstruction. The right response is to take the concern seriously, investigate it, and either incorporate the input or explain clearly why the design will not be changed. Programmes that do this build credibility. Programmes that wave the concern away, or treat the person raising it as a problem, lose credibility in ways that compound over time.

The harder version of this point is that legitimate concerns often arrive in irritated tones from people who feel they should have been consulted earlier, when the programme team is already under pressure. The information value of the concern is the same regardless of the tone. Filtering the substance from the manner is part of the skill of running change in a regulated environment.

The capacity concern

A second large category of resistance comes from teams that genuinely cannot absorb the change at the pace the programme requires. They are running at capacity on existing work. They have other regulatory programmes already in flight. They have customer commitments that cannot be deferred. The programme is asking them to take on a significant new burden without any visible relief from the existing one.

This kind of resistance cannot be solved by communication. It is not solved by training. It is solved by addressing the capacity problem, either by phasing the change to fit available capacity, by providing additional resources to the affected team during implementation, or by deferring other work to make space. None of these is programme-level decisions. They are portfolio-level decisions, and they need to be surfaced at the right governance forum, not pushed back at the resisting team.

Programmes that respond to capacity-based resistance by asking the team to prioritise the change consistently produce a familiar outcome. The team does what it has to do to satisfy the programme, but does it badly. The change goes in. The operating model that emerges on the other side is unstable. The supervisor finds it months later.

The political concern

A smaller but significant category of resistance is political. The change disadvantages a particular business unit, or shifts authority from one function to another, or undermines someone's standing in the organisation. The resistance is expressed in terms of operational concerns, but the actual driver is the political consequence of the change.

Political resistance is harder to address with the standard change management toolkit because the cause is not visible in the words used. It needs to be addressed at the level it is actually operating: a conversation between sponsors, a decision at the executive committee level, a structural choice about authority and accountability. The change management team is rarely well placed to resolve political resistance directly. Their role is to recognise it, surface it to the sponsors who can act on it, and not pretend it is something else.

The fear concern

A final category, and an important one to name explicitly, is fear. Fear of being unable to do the new role. Fear of being made redundant. Fear of losing a hard-won expertise that becomes irrelevant. Fear of having to admit, to oneself or to others, that something that has been done a particular way for years was wrong all along. These are not unprofessional reactions. They are human reactions to changes that affect identity and security.

Fear-based resistance is consistently underestimated. It surfaces in indirect ways: in cynicism, in disengagement, in selective compliance, in a sudden interest in early retirement. It rarely surfaces as a direct statement of fear. The response that works is not to address the cynicism or the disengagement at face value. It is to recognise what is underneath and respond to that: clear communication about what the change does and does not mean for people's roles, visible support through the transition, honesty about what is and is not known, and patience with the time the transition takes for individuals.

Reading resistance well

The single most useful skill in change management, and the one most consistently underdeveloped, is the ability to read resistance accurately. Is this person opposing the change because of a legitimate operational concern, a capacity problem, a political issue, or a fear-based reaction? Is this resistance broad-based, or is one influential individual giving voice to something everyone else feels as well? Is the resistance hardening over time, or is it resolving as engagement progresses?

These questions cannot be answered through a survey. They are answered through the relationships the programme team has built across the affected population, through the conversations they have had, and through the informal feedback they have gathered. This is one of the reasons that change management cannot be delivered remotely or by a function operating at a distance from the business. The intelligence required to read resistance well is gathered through proximity.

The handover to business as usual

The point at which a change moves from programme delivery to business-as-usual operation is one of the most consistently underprepared transitions in financial services. The programme is winding down, the programme team is dispersing, the systems are live, the policies are signed off, and the assumption is that the new state will now operate itself.

It will not. The new state is fragile in the months after go-live. The processes are unfamiliar. The exception cases have not been worked through. The management information is unfamiliar and harder to read than expected. The people who designed the new state are leaving, and the people who have to run it are still learning. This is the period in which most programmes either embed successfully or visibly degrade, and the quality of the handover usually determines the difference.

Named owners, not nominal ones

A handover is only as good as the owners who receive it. Every significant component of the new operating state needs an identified owner within the business with the authority, capacity, and knowledge to manage it through the embedding period. Controls need a control owner. Processes need a process owner. Systems need a system owner in the operating function, not just in technology. Training needs an owner who will refresh and reinforce it.

The common failure mode is the nominal owner. A senior manager who has been assigned ownership of a handover document but was not involved in the build does not have the capacity to engage with the issues that arise and lacks the team to support them. The handover documents say the new state has been transferred. The reality is that nobody is actively managing it. By the time the supervisor or the auditor finds the gap, the trail back to a programme that has long since dispersed is hard to reconstruct.

Named ownership must be agreed before go-live, not announced at handover. The named owners need to have been part of the build. They need the documentation supporting their ownership in a form they can use. They need a clear understanding of what they are responsible for, what authority they have, and where they can get help if something goes wrong. The handover is the formal moment when responsibility transfers, but readiness has to be built over the months leading up to it.

Hypercare and beyond

The period immediately after go-live, often called hypercare, is when most problems surface. The volume of edge cases is higher than predicted by testing. The new management information is unfamiliar. The training has not yet been reinforced by practice. People are slower and less consistent than they will be in a few weeks.

A good hypercare arrangement keeps the programme team or a designated transition team in place for the first weeks after go-live. Issues are triaged, prioritised, and addressed rapidly. Management information is reviewed daily. Senior support is visibly available. The metric is not the number of open tickets. It is how quickly the operating environment is stabilising and how visible the support is to the people running the new state.

Hypercare ends when the new state consistently produces the outcomes the programme was designed to produce, without disproportionate exception handling. That point usually arrives several weeks after go-live, sometimes longer, depending on the complexity. Programmes that declare hypercare complete on an advanced-set date, regardless of the operating environment, leave the receiving organisation to manage stabilisation without the resources the programme was supposed to provide.

Documentation that survives the team

The documentation that gets created during a programme is generally a mix of working documents, decision records, design documents, and operational artefacts. The handover question is which of those documents the receiving organisation needs to run the new state, and whether those documents are in a form the receiving organisation can actually use.

This is often where the gap appears. The working documents are accessible to the programme team, but unfamiliar in structure to the people who now have to consult them. The decision records are scattered across emails and meeting minutes. The design documents are detailed but not connected to the operational situations the new owners will face. The operational artefacts are in place, but the path between them and the design decisions that explain them is not visible.

The discipline that works is to design the documentation set the receiving organisation will need, not just the documentation set the programme produces along the way. Operational process documentation. Control documentation that connects each control to its design and testing. A decision log that captures the significant choices made during the programme and the rationale, so that future amendments can be reasoned about. Training material that can be picked up and used by a new owner without needing to call the original designer. This work usually has to be planned and resourced explicitly because it does not arise as a by-product of delivery.

Embedding and sustaining change

The work of making a change stick continues for months after go-live, often for years. The processes have to become a habit. The exception cases have to be worked through. The management information has to start telling a coherent story rather than a noisy one. The supervisors who run the new process have to learn what good looks like and how to coach their teams. None of this happens automatically.

Reinforcement is active, not passive

The ADKAR model's reinforcement step is the one most programmes do least well. The assumption is that once the change is in place, it will sustain itself. The reality is that without active reinforcement, the new way of working tends to drift back to the old way, particularly under pressure.

Active reinforcement looks like specific things. The visible attention of leadership to whether the new way of working is being followed. Recognition for the people and teams who are operating the new state well. Consequences, including remedial action and where necessary disciplinary action, for the people who are not. Updates to performance management to reflect the new expectations. Updates to incentive structures where they are pulling against the new state. None of these is dramatic. Their power comes from their consistency, over time, in the moments people are watching.

Programmes that hand off to a business that does not consistently reinforce the change tend to drift back to the old state within the first twelve months. The visible symptoms vary. Workarounds are emerging that bypass the new controls. Selective use of the new process for the easy cases and the old process for the hard ones. Management information that is being produced but not acted on. A growing sense, on the floor, that the change was a programme that has now passed, and life can return to what it was. Each of these is a reinforcement gap. They are solved at the level of leadership behaviour, not at the level of communications or training.

Tracking adoption, not completion

Most programmes track delivery metrics: milestones hit, deliverables produced, training completed, systems live. Few programmes track adoption metrics: whether the new way of working is being followed consistently, whether the outcomes the change was designed to produce are being achieved, and whether the control environment is stable.

Adoption metrics are harder to design and harder to maintain than delivery metrics. They require an honest baseline against which to measure improvement. They require regular measurement, often through a combination of management information, sampling, and direct observation. They require someone to own them after the programme has dispersed.

The metrics that matter vary by the change, but a useful general set covers four dimensions. Process adherence: Are people following the new process? Outcome quality: Is the new process producing the intended outcomes? Issue volume: Are the exceptions, errors, and complaints in the new state at an acceptable level? Stakeholder experience: Do the people operating in the new state feel adequately supported? Tracking these four through the first year post go-live, and acting on the trends, is the practical work of embedding.

The role of culture

Embedding is where the relationship between change management and culture becomes visible. A change being implemented into a healthy culture, one where leaders consistently model the new expectations and the organisation responds to feedback, embeds relatively quickly. A change being implemented into an unhealthy culture, where stated expectations and actual behaviour diverge, embeds slowly, if at all.

This is one of the reasons change management cannot deliver culture change within a programme timeline. If the culture is weak, the embedding work will be harder, regardless of how well the programme delivers. The change management team's role is to recognise this, to do what can be done within the programme's scope, and to be honest with sponsors about the cultural conditions that will determine whether the change ultimately sustains. Pretending that good change management alone will overcome an unhealthy culture is one of the more expensive forms of false reassurance in financial services delivery.

The next iteration

Regulation does not stand still, and operating environments evolve. The change the programme has just delivered will itself be amended, refined, or replaced within a few years. The embedding period is the right time to start anticipating this.

This is not a heavy task. It is a discipline of noticing where the change is showing strain, where the operating environment is producing exceptions the design did not anticipate, and where regulatory guidance is evolving in directions the design will need to absorb. The information is captured. It informs the next round of change. The organisation builds, over time, an institutional memory of what it has tried, what worked, what did not, and why. The organisations that do this well make each programme easier than the last. The organisations that do not repeat the same mistakes.

The relationship between change management, project management, and culture

Change management does not operate in isolation. It is one of three related but distinct disciplines that together determine whether a change in a regulated organisation lands well. Each does work that the others cannot do. Each has its own skills, governance, and success criteria. And each is often confused with the others, sometimes deliberately.

Project and programme management

Project and programme management deals with delivering the change. It is concerned with scope, schedule, risk, dependencies, and the technical or operational build. Its measure of success is whether the change has been delivered as designed, on time, within budget, with the documented quality.

Change management deals with whether the receiving organisation can absorb and operate the change. Its measure of success is whether the new state is genuinely adopted, consistently, by the people who have to operate in it.

A programme that delivers without change management produces an artefact. A change management effort without delivery produces an aspiration. The two need to be integrated from day one. Decisions about design, phasing, resourcing, communication, and training are all areas where both disciplines have a stake. Programmes that separate the two, treating change management as a workstream that follows delivery, consistently produce the predictable result: technically delivered, operationally rejected.

Culture

Culture is the accumulated pattern of how the organisation behaves when decisions have to be made. It is not a programme output. It is the long-term consequence of consistent leadership behaviour, reinforced by what gets rewarded and what gets tolerated.

Change management interacts with culture in two ways. The first is that the prevailing culture shapes how change is received. A culture of psychological safety, where concerns can be raised and heard, supports good change management. A culture of fear or cynicism makes good change management harder, regardless of how well the discipline is practised.

The second is that programmes can reinforce or erode the prevailing culture through how they are run. A programme that engages thoughtfully with the people affected, takes their concerns seriously, and produces a visible response, reinforces a culture of engagement. A programme that imposes change on a population that has no say in it, treats resistance as obstruction, and walks away after go-live, reinforces a culture of imposition. Neither is invisible. The way change programmes are run is one of the strongest cultural signals a large organisation produces.

None of this means that a change programme can do the work of culture change. Culture change requires sustained leadership behaviour over years, not a programme over months. But every change programme is either reinforcing or eroding the culture it operates in, regardless of whether it intends to. The programme manager who understands this runs a different kind of programme than one who does not.

Where they connect

In a well-run regulated organisation, the three disciplines are visibly connected. The same governance forum considers delivery, adoption, and the cultural signals the programme is sending. The same senior leader holds accountability for all three. The performance of the programme is judged not just on whether it delivered, but on whether it was absorbed and on what it taught the organisation about its capacity for change.

Most organisations are not yet at that level of integration. The disciplines are managed separately, by different functions, with different governance, often with conflicting incentives. The result is the recurring pattern of well-delivered programmes that fail to produce the operating reality they were designed for. Bridging the gap is one of the highest-leverage things a senior delivery leader in a regulated organisation can work on.

Implementation checklist

The following covers the questions a programme manager, change lead, or senior sponsor should be able to answer at any point in a change programme in a regulated organisation. It is intended as a working reference rather than an exhaustive methodology.

Foundation

• Discipline understood. Is change management understood as a delivery discipline integrated with project management, not a workstream or a communications function?
• Frameworks not slavishly applied. Are the relevant frameworks understood and drawn on selectively where they add value, rather than imposed as a methodology?
• Resourced from day one. Is change management resourced from the start of the programme, with people of appropriate seniority and credibility, not added at week 36?
• Owned by delivery. Is change management owned by the programme, not subcontracted to HR or to a function operating at a distance from the business?

Stakeholder management

• Map produced and used. Has a stakeholder map been produced, kept current through delivery, and used to drive engagement decisions rather than left in the repository?
• Disposition assessed honestly. Does the map capture each stakeholder's current disposition, including those who are sceptical or opposed?
• Accountability mapped. Have the senior managers personally accountable for the affected areas been identified, with a clear understanding of what they need from the programme to discharge their accountability?
• Engagement is two-way. Is the engagement approach producing genuine input that visibly changes programme decisions, rather than one-way communication?
• Professionals respected. Does the engagement approach recognise the expertise of the people being affected, with structured consultation that makes meaningful use of their input?

Communications

• Segmented by audience. Does the communications plan address different audiences with content tailored to them, rather than treating all stakeholders as a single population?
• Sequenced against the phase. Does the sequence of communications match what each audience needs to know at each phase of the programme?
• Sponsor active and visible. Is the senior sponsor visibly and actively associated with the change, not just signed off on the business case?
• Cascade through management. Are communications cascading through the management structure, with the middle layer adequately briefed and equipped to lead in their teams?
• Channels match content. Is the channel matched to the substance of each communication, rather than defaulting to whatever the corporate communications team usually produces?
• Two-way mechanisms are working. Are there continuous two-way mechanisms producing visible responses, rather than periodic surveys that disappear into aggregation?

Training

• Designed for capability. Is training designed around what people need to do, rather than around what the system or policy requires?
• Role-specific. Is training segmented by role and tailored to the specific capabilities each role needs, not delivered as generic content?
• Timed against need. Is the timing of training designed against when learners need to apply it, not against when the project timeline can accommodate it?
• Substantive assessment. Does the training include an assessment substantive enough to produce a record of competence, not just completion?
• Failure pathway defined. Is there a clear process for what happens when someone fails an assessment, with documented remediation?
• Regulatory records. Are training records being captured in a form that will satisfy supervisory examination: who, what, when, with what assessment outcome, with what refresher schedule?

Resistance

• Read as information. Is resistance being treated as information about what the programme is doing wrong, not as an obstruction to be neutralised?
• Categorised correctly. Is each significant area of resistance being categorised accurately: legitimate concern, capacity issue, political dynamic, or fear-based response?
• Addressed at the right level. Is each category being addressed at the level at which it is operating: design change, portfolio prioritisation, sponsor conversation, or supported transition?
• Proximity maintained. Does the programme team have sufficient proximity to the affected population to read resistance accurately, rather than secondhand?

Handover and embedding

• Named owners ready. Does each significant component of the new operating state have a named owner in the business who has been involved in the build and can manage it forward?
• Hypercare planned and resourced. Is there a defined hypercare period after go-live, with the programme team available, daily management information reviews, and senior support visible?
• Documentation usable. Is the documentation set being prepared for the receiving organisation in a form they can actually use, rather than the working documentation the programme produces?
• Reinforcement active. Is there active reinforcement of the new way of working through leadership behaviour, performance management, and, where necessary, disciplinary action?
• Adoption tracked. Are adoption metrics being tracked through the first year post go-live, covering process adherence, outcome quality, issue volume, and stakeholder experience?
• Next iteration anticipated. Is the embedding period being used to capture what is being learned about how the change is operating, to inform the inevitable next iteration?

A final note

Change management in regulated organisations is the discipline that determines whether the substantial investment in delivery actually produces the operating reality the firm needs. It is not a workstream, not a communications campaign, and not a generic management overlay. It is the work of moving an organisation and its people from one operating state to another in a way that produces sustained adoption.

The discipline is teachable and supported by a strong body of literature and practical methods. The judgment is harder. It comes from doing this work inside organisations, working with the people who have to operate the new state, and seeing what holds up in practice. Programmes that take the discipline seriously, resource it from the start, and integrate it with delivery produce better operating outcomes than programmes that treat it as an afterthought. That is well supported by experience and evidence, even if many organisations still under-invest in it.

Senior delivery leaders, programme managers, and change leads who understand this run a different kind of programme. Quieter at the front end. More deliberate in design. Faster to land. Less prone to surprise. More likely to produce the operating environment that was intended. The return comes through stronger supervisory outcomes, lower friction in later change, and better day-to-day operations.

Change is hard. The discipline required to manage it is harder. Both repay the effort.