The change management process is the sequence a change travels from decision to daily habit, and the version that delivers adoption treats that sequence as a loop run on evidence rather than a timeline approved in advance. Most organisations still design the process as a straight line: assess readiness, publish a communication plan, run training, monitor, declare success. That picture is tidy, easy to approve and easy to report against, and it bears little resemblance to what happens when a change meets real people with real workloads.
This guide is for change, HR and transformation leaders who are accountable for adoption, not just for delivery. It argues that the seven steps of the process still matter, but that their order, pace and content should be set by what your people data shows during delivery, not by a plan frozen at kickoff. By the end you will be able to design a process that fits your organisation’s maturity, reads the change from the impacted person’s side, measures continuously, and adjusts between rollout cycles instead of after the post-implementation review.
Why linear processes fail
A linear change management process fails because it treats the organisation as stable, the change as isolated and the plan as an accurate forecast, and none of the three holds in a complex organisation. Traditional models assume that if you follow the steps correctly, transformation will succeed. That assumption misses something fundamental about how organisations behave once a change starts to move.
The environment has also become harder to plan against. A 2026 Harvard Business Review analysis by Gartner HR researchers attributes the growing difficulty of leading through change to four converging factors: changes are stacked on top of one another, they are continuous with no clear start or end date, they are larger and interdependent, and they are increasingly driven by external forces such as technology and geopolitics. A process that assumes one change, one timeline and one team is designing for a world that no longer exists.
The core problems with linear change management approaches
Readiness is not static. An assessment conducted three months before go-live captures a moment in time, not a prediction of future readiness. Organisations that are ready today might not be ready when implementation arrives, especially if other changes have occurred, budget pressures have intensified or key leaders have departed.
Impact is not uniform. The same change affects different parts of the organisation differently. Finance functions often adopt new processes faster than frontline operations. Risk-averse cultures resist more than learning-oriented ones. Users with technical comfort embrace systems more readily than non-technical staff.
Problems emerge during implementation. Linear models assume that discovering problems is the job of the assessment phase. But the most important insights often emerge during implementation, when reality collides with assumptions. When adoption stalls in unexpected places or proceeds faster than projected, that is not a failure of planning. It is valuable data about what actually drives adoption in your specific context.
Multi-change reality is ignored. Traditional change management processes often overlook a critical fact: organisations do not exist in a vacuum. They are managing multiple concurrent changes, each competing for attention, resources and cognitive capacity. A single change initiative that ignores this broader landscape is designing for failure.
The evolution: from rigid steps to an iterative process
An iterative change management process plans, implements, measures, learns and adjusts, then cycles again with what it has learned. Modern change management processes embrace this agile change management approach because complex change reveals itself through delivery, not through analysis beforehand.
The shift is visible in the profession’s own data. Prosci’s latest benchmarking found that fewer than 70% of participants now follow a formal change management methodology, the first time that has been true since 2011, a decline Prosci links to the rise of agile and adaptive approaches. The same study found that practitioners actively managing a portfolio of changes rose from 38% to 43%. Practice is moving from one-off project processes towards continuous, portfolio-level operation. For a deeper look at the research behind this move, see our summary of why iterative, agile change management succeeds where linear approaches fail.
The iterative change cycle
Each pass through the cycle asks the same five questions of a defined cohort, function or geography:
Plan: Set clear goals and success criteria for the next phase. What do we want to achieve? How will we know if it is working? What are we uncertain about?
Design: Develop specific interventions based on current data. How will we communicate? What training will we provide? Which segments need differentiated approaches? What support structures do we need?
Implement: Execute interventions with a specific cohort, function or geography. Gather feedback continuously, not just at the end. Monitor adoption patterns as they emerge, and track both expected and unexpected outcomes.
Measure: Collect data on what is actually happening. Are people adopting, and are they adopting correctly? Where are barriers emerging? Where is adoption stronger than expected? Which change management metrics reveal the true picture?
Learn and adjust: Analyse what the data reveals. Refine the approach for the next iteration based on actual findings, challenge initial assumptions with evidence, and apply lessons to improve subsequent rollout phases.
This iterative cycle is not a sign that the original plan was wrong. It is recognition that complex change reveals itself through iteration. The first iteration builds foundational understanding. Each subsequent iteration deepens insight and refines the change management approach, so the fifth cohort should adopt faster and with fewer barriers than the first.
The organisational context matters
The same change management methodology works differently depending on the organisation it is implemented in, which is why copying another company’s process rarely reproduces its results. Change maturity, leadership capability and culture all change what a good process looks like.
Have muscle memory and infrastructure for iterative change
Build on existing change management best practices
Low maturity organisations:
Need more structured guidance and explicit governance
Require more time between iterations to consolidate learning
Benefit from clearer milestones and checkpoints
Need more deliberate stakeholder engagement
Require foundational change management skills development
The first step of any change management process is an honest assessment of organisational change maturity. Can this organisation move at pace, or does it need a more gradual approach? Does change leadership have experience, or do they need explicit guidance? Is there existing change governance infrastructure, or does it need to be built?
These answers shape the design of your change management process. They determine the pace of implementation, the frequency of iterations, the depth of stakeholder engagement required, the level of central coordination needed, and the support structures and resources you will have to provide.
The impact-centric perspective
An impact-centric process designs around the lived experience of the person who has to change, not around the project’s categories of “users”, “stakeholders” and “early adopters”. Every change affects real people, and the quality of your design depends on how well you understand what the change asks of each of them, given everything else they carry.
This matters more as changes interlock. The Gartner HR researchers writing in Harvard Business Review describe today’s changes as interdependent rather than separate, which means the effect on one person rarely comes from one initiative alone. A practical way to start is a structured change impact assessment that maps what changes for each group, by how much and when.
From the impacted person’s perspective
Change saturation: What else is happening simultaneously? Is this the only change or one of many? If multiple initiatives are converging, are there cumulative impacts on adoption capacity? Can timing be adjusted to reduce simultaneous load? Recognising the need for change capacity assessment prevents the saturation that kills adoption.
Historical context: Has this person experienced successful or unsuccessful change previously? Do they trust that change will actually happen, or are they sceptical based on past experience? Historical success builds confidence; historical failure builds resistance. Understanding this history shapes engagement strategy.
Individual capacity: Do they have the time, emotional energy and cognitive capacity to engage with this change given everything else they are managing? Change practitioners often assume capacity that does not actually exist. Realistic capacity assessment determines what is achievable.
Personal impact: How does this change specifically affect this person’s role, status, daily work and success metrics? Benefits are not universal. For some people, change creates opportunity. For others, it creates threat. Understanding this individual reality shapes what engagement and support each person needs.
Interdependencies: How does this person’s adoption depend on others adopting first? If the finance team needs to be ready before sales can go live, sequencing matters. If adoption in one location enables adoption in another, geography shapes timing.
When you map change from the impacted person’s perspective rather than a project perspective, you design very different interventions. You might stagger rollout to reduce simultaneous load. You might emphasise positive historical examples if trust is low. You might provide dedicated support to individuals carrying a disproportionate change load.
Data-informed design and continuous adjustment
This is where the modern change management process differs most sharply from the traditional one: nothing is assumed, and everything is measured. Implementing change without data is like navigating without instruments. Prosci’s research shows the payoff: among participants who measured compliance and overall performance, 76% met or exceeded project objectives, compared with 24% of those who did not measure.
Before the process begins: baseline data collection
A baseline gives every later iteration something to be compared against. At minimum, capture:
The current state of readiness
Knowledge and capability gaps
Cultural orientation toward this specific change
Locations of excitement versus resistance
Adoption history in this organisation
Change management performance metrics from past initiatives
During implementation: continuous change monitoring
As the process unfolds, data collection continues and tracks the full path from awareness to behaviour:
Awareness tracking: Are people aware of the change?
Understanding measurement: Do they understand why it is needed?
Engagement monitoring: Are they completing training?
Application assessment: Are they applying what they have learned?
Barrier identification: Where are adoption barriers emerging?
Success pattern analysis: What is driving adoption in the places where it is working?
This data then becomes the basis for iteration. If a readiness assessment showed low awareness and commitment did not emerge from initial communication, you are not simply communicating more. You are investigating why the message is not landing, and the reason shapes the solution.
How to measure change management success
Measuring change management success means tracking whether people are using the new way of working, how well, and whether it lasts, then using the answer to change what you do next. A single end-of-project survey cannot do that, and the real value of measurement is diagnostic rather than evaluative.
Consider the common case where adoption is strong in Finance but weak in Operations. You do not just provide more training to Operations. You investigate why Finance is succeeding:
Is it their culture?
Their leadership?
Their process design?
Their support structure?
Understanding the difference helps you replicate success in Operations rather than trying harder with a one-size-fits-all approach.
Effective measurement covers six dimensions throughout the change, and change management success metrics should be defined before implementation begins:
Adoption: who is using the new process or system, and how proficiently.
Readiness indicators: awareness, understanding, commitment and capability levels.
Behaviour change: whether people are actually changing how they work, not just attending training.
Performance impact: operational results against the baseline.
Sentiment and engagement: confidence, trust and satisfaction.
Sustainability: whether adoption persists over time or reverts.
Data-informed change means starting with hypotheses but letting reality determine strategy. It means being willing to abandon approaches that are not working and trying something different. It means recognising that what worked for one change will not necessarily work for the next one, even in the same organisation.
The 7-step change management process
The seven steps are a readiness checklist for an adaptive loop, not a one-way conveyor. Modern change management processes are iterative rather than strictly linear, but they still progress through recognisable phases, and understanding how those phases interact prevents you from getting lost in iteration. Steps 1 to 5 are the cycle every change passes through; Steps 6 and 7 are the organisational conditions that decide whether the cycle can run well.
Step 1: Pre-change planning
Before formal change begins, build foundations:
Assess organisational readiness and change maturity
Map the current change landscape and change saturation levels
Identify governance structures and leadership commitment
Conduct an impact assessment across all affected areas
Understand who is affected and how
Baseline the current state across adoption readiness, capability, culture and sentiment
This step establishes what you are working with and sets the pace and approach for everything that follows.
Step 2: Awareness and readiness building
Help people understand what is changing and why it matters. This is not one communication. It is repeated, multi-channel, multi-format messaging that reaches people where they are, and it should be tested against a readiness assessment so you know whether the message has landed.
Different stakeholders need different messages:
Finance needs to understand financial impact
Operations needs to understand process implications
Frontline staff need to understand how their day-to-day work changes
Leadership needs to understand the strategic rationale
Done well, this step moves people from unawareness to understanding and from indifference to some level of commitment. The ADKAR model’s first two elements, awareness and desire, describe this movement in individual terms, and Prosci’s ADKAR overview is a useful reference for sequencing it.
Step 3: Capability building
Equip people with what they need to succeed:
Formal training programmes
Documentation and job aids
Peer support and buddy systems
Dedicated help desk support
Access to subject matter experts
Practice environments and sandboxes
This step recognises that people need different things: some need formal training, some learn by doing, some need one-on-one coaching. The process design accommodates this variation rather than enforcing uniformity.
Step 4: Implementation
This is where iteration becomes critical:
Launch the change, typically with an initial cohort or geography
Measure what is actually happening through change management tracking
Identify where adoption is strong and where it is struggling
Surface barriers and success drivers
Iterate and refine the approach for the next rollout based on learnings
Repeat with subsequent cohorts or geographies
Each cycle improves adoption rates and reduces barriers based on evidence from previous cycles.
Sustained change requires ongoing reinforcement, continued support and regular adjustment as the organisation learns how to work most effectively with the new system or process.
Step 6: Integration with organisational strategy
The change management process does not exist in isolation from organisational strategy and capability. It is shaped by, and integrated with, several critical factors.
Leadership capability
Do leaders understand change management principles? Can they articulate why change is needed? Will they model new behaviours? Are they present and visible during critical phases? Weak leadership capability requires more structured support, more centralised governance, more explicit role definition for leaders, and coaching and capability building for change leadership.
Operational capacity
Can the organisation actually absorb this change given current workload, staffing and priorities? If not, what needs to give? Pretending capacity exists when it does not is the fastest path to failed adoption. A realistic assessment covers:
Current workload and priorities
Available resources and time
Competing demands
Realistic timeline expectations
If you do not yet have a way to quantify this, start with a change capacity model that compares the load of planned changes against the headroom each group actually has.
Change governance
How are multiple concurrent change initiatives being coordinated? Are they sequenced to reduce simultaneous load? Is someone preventing conflicting changes from landing at the same time? Is there a portfolio view preventing change saturation? Effective enterprise change management requires:
Does the organisation already have change management tools and techniques, governance structures and experienced practitioners? If so, the new process integrates with these. If not, do you have the resources to build this capability as part of this change, or do you need to work within the absence of this infrastructure?
Culture and values
What is the culture willing to embrace? A highly risk-averse culture needs a different change design than a learning-oriented culture. A hierarchical culture responds to authority differently than a collaborative culture. These are not barriers to overcome but realities to work with.
The future: digital and AI-enabled change management
The future of the change management process lies in combining digital platforms with AI to expand scale, precision and speed while keeping human judgement in charge. The evidence so far says the hard part of AI adoption is not the technology. Prosci’s study of 1,107 professionals found that 63% of AI implementation challenges stem from human factors rather than technical limitations, which is precisely the territory a change process exists to manage.
Current state versus future state
Current state:
Practitioners manually collect data through surveys, interviews and focus groups
Manual analysis takes weeks
Pattern identification is limited by human capacity and intuition
Iteration is based on what practitioners notice and stakeholders tell them
Future state:
Digital platforms instrument change, collecting data continuously across hundreds of engagement touchpoints
Adoption behaviours, performance metrics and sentiment indicators are tracked in real time
Machine learning identifies patterns humans might miss
AI surfaces adoption barriers in specific segments before they become critical
Algorithms predict adoption risk by analysing patterns in past changes
AI-powered change management analytics
AI-powered insights can highlight which individuals or segments need support before adoption stalls, identify which change management activities are working and where, recommend where to focus effort for maximum impact, correlate adoption patterns with dozens of organisational variables, predict adoption risk and success likelihood, and generate automated change analysis and recommendations. Our complete guide to AI in change management covers the practical use cases.
But here is the critical point: AI generates recommendations, and humans make decisions. AI can tell you that adoption in Division X is 40% below projection and that users in this division score lower on confidence. It can recommend increasing coaching support. A human change leader, understanding business context, organisational politics and strategic priorities, decides whether to follow that recommendation or adjust it based on factors the algorithm cannot see.
Human expertise plus technology
The future of managing change is not humans replaced by AI. It is humans augmented by AI:
Technology handling data collection and pattern recognition at scale
Humans providing strategic direction and contextual interpretation
AI generating insights while humans make nuanced decisions
Platforms enabling measurement while practitioners apply judgement
This future requires change management processes that build in data infrastructure from the beginning. It requires defining success metrics and change management KPIs upfront, continuous measurement rather than point-in-time assessment, treating change as an operational discipline with data infrastructure, building change management analytics capabilities, and investing in platforms that enable measurement at scale. A change intelligence platform such as Change Compass is built for this: it brings change impacts, capacity and adoption signals into one view, so the loop described in this guide runs on current data rather than on last quarter’s survey.
Designing your change management process
The change management framework that works for your organisation is not generic. It is shaped by organisational maturity, leadership capability, change landscape and strategic priorities. Designing it is a six-part exercise, and each part feeds the next.
Step 1: Assess current state
What is the organisation’s change maturity? What is leadership’s experience with managing change? What governance exists? What is the cultural orientation? What other change initiatives are underway? What is capacity like? What is the historical success rate with change? This assessment shapes everything downstream and determines whether you need a more structured or more adaptive approach.
Step 2: Define success metrics
Before you even start, define what success looks like:
What adoption rate is acceptable?
What performance improvements are required?
What capability needs to be built?
How will you measure change management effectiveness?
What change management success metrics will you track?
Who is affected? In how many different ways? What are their specific needs and barriers? What is their capacity? What other changes are they managing? This impact-centric change assessment shapes:
Sequencing and phasing decisions
Support structures and resource allocation
Communication strategies
Training approaches
Risk mitigation plans
Step 4: Design the iterative approach
Do not assume linear execution. Plan for iterative rollout:
How will you test learning in the first iteration?
How will you apply that learning in subsequent iterations?
What decisions will you make between iterations?
How will the speed of iteration balance with consolidation of learning?
What change monitoring mechanisms will track progress?
Step 5: Build in continuous measurement
From day one, measure what is actually happening:
Adoption patterns and proficiency levels
Adoption barriers and resistance points
Performance impact against baseline
Sentiment evolution throughout phases
Capability building and confidence
Change management performance metrics
Use this data to guide iteration and make evidence-informed decisions about change management success.
Step 6: Integrate with governance
How does this change process integrate with portfolio governance? How is this change initiative sequenced relative to others? How is load being managed? Is there coordination to prevent saturation? Is there an escalation process when adoption barriers emerge? Effective change management requires integration with broader enterprise change management practices, not isolated project-level execution.
Change management best practices for process design
Start with clarity on the fundamentals of change management:
A clear vision and business case
Visible and committed sponsorship
Adequate resources and realistic timelines
Honest assessment of starting conditions
Embrace iteration and learning:
Plan, do, measure, learn and adjust cycles
Willingness to challenge assumptions
Evidence-based decision making
A continuous improvement mindset
Maintain human focus:
Individual impact assessment
Capacity and saturation awareness
Support tailored to needs
Empathy for the lived experience of change
Use data and technology:
Baseline and continuous measurement
Pattern identification and analysis
Predictive insights where possible
Human interpretation of findings
Integrate with organisational reality:
Respect cultural context
Work with leadership capability
Acknowledge capacity constraints
Coordinate with other changes
The process as an adaptive system
The modern change management process is fundamentally different from traditional linear models. It recognises that complex organisational change cannot be managed through predetermined steps, and it requires data-informed iteration, contextual adaptation and continuous learning.
It treats change not as a project to execute but as an adaptive system to manage. It honours organisational reality rather than fighting it. It measures continually and lets data guide direction. It remains iterative throughout, learning and adjusting rather than staying rigidly committed to original plans.
Most importantly, it recognises that change success depends on whether individual people actually change their behaviours, adopt new ways of working and sustain those changes over time. Everything else (process, communication, training, systems) exists to support that human reality. Organisations that embrace this approach do not achieve perfect transformations. They achieve transformation that sticks, that builds organisational capability, and that positions them for the next wave of change.
What to do before your next change goes live
Take the seven steps you already use and make three changes this quarter. Run the first rollout to a single cohort and agree in advance what result from that cohort would make you alter the plan. Put one adoption measure and one capacity measure on the same page, reviewed fortnightly with sponsors. And check the change against everything else landing on the same people before you confirm a date. None of this requires a new methodology or a new team. It requires deciding, before kickoff, that the process will respond to evidence, and then letting it. Do that, and the review that follows the go-live reads as a record of what you learned and adjusted, not an explanation of why adoption fell short.
Frequently asked questions
What is the change management process?
The change management process is the structured approach for moving individuals, teams and organisations from a current state to a desired future state. It typically includes pre-change planning, awareness building, capability development, implementation with reinforcement, and sustainment. Modern versions are iterative rather than linear, using continuous measurement and agile change management principles to adjust to real-time adoption data.
What is the difference between linear and iterative change management processes?
A linear process follows predetermined steps (plan, communicate, train, implement, measure at the end) and assumes that following the methodology correctly guarantees success. An iterative process repeats a plan, implement, measure, learn and adjust cycle with each cohort or phase. Iterative approaches suit complex change because they let evidence inform strategy, so barriers are found early and what works is replicated.
How does organisational change maturity affect process design?
Change maturity determines how fast an organisation can move through iterative cycles and how much structure it needs. High-maturity organisations with experienced leaders and strong governance can move quickly and adjust decisively. Low-maturity organisations need more explicit governance, more support and more time between iterations to consolidate learning. Assess maturity before designing the process, because it sets the pace, structure and governance you need.
How do you measure change management effectiveness throughout implementation?
Track adoption, readiness indicators, behaviour change, performance impact, sentiment and sustainability, and define the success metrics before implementation begins. Continuous measurement shows what is actually driving adoption or resistance in your context, which is almost always different from planning assumptions. It lets you replicate what works, fix what does not and make evidence-informed decisions with each cycle.
How does the process account for multiple concurrent changes?
Effective enterprise change management maps the full change landscape, assesses cumulative impact and saturation, sequences changes to reduce simultaneous load, and builds support for people managing several changes at once. Portfolio-level governance coordinates initiatives, prevents conflicting changes and monitors capacity. Single-change processes that ignore this context tend to fail because they design for capacity that does not exist.
Banks now take more than a year, on average, to fully implement a single regulatory change, and most are running several at once while modernising the technology underneath them (CUBE, Cost of Compliance Report 2025). Change management in financial services is the discipline of delivering transformation, regulatory change and legacy modernisation concurrently, inside a risk and compliance culture, by measuring adoption, operational performance and compliance risk while the change is still rolling out. This article is for transformation, change and operational risk leaders in banking, insurance, superannuation and asset management who are accountable for outcomes that boards and regulators will test. It argues that the sector’s real constraint is not appetite for change but visibility: most institutions cannot see whether a programme is landing until after go-live, when fixing it is slowest and most expensive. By the end you will be able to place your organisation on a three-level change maturity scale, make the case for agile delivery that risk and compliance will sign off, and define the five measures that replace narrative with evidence in a board pack.
Why financial services change is different
Financial services change is different because three loads land on the same people at once: continuous regulatory change, ageing technology, and a cap on how much risk any experiment may carry. Other sectors face one or two of these. Banks, insurers and super funds face all three, and each makes the others harder.
Regulatory change never finishes
Regulation in financial services does not arrive in waves with pauses between them. APRA’s Prudential Standard CPS 230 on operational risk management came into force on 1 July 2025 for authorised deposit-taking institutions, general and life insurers, private health insurers and superannuation trustees, with existing service provider contracts brought into line by the earlier of renewal or 1 July 2026 (APRA). The EU’s Digital Operational Resilience Act began applying on 17 January 2025 across 20 types of financial entity (EIOPA). In the same period CUBE logged 157 new laws and rules on AI in financial services, almost double the previous year, and 60 percent of the 2,000 compliance and risk officers it surveyed expect regulatory change costs to rise again (CUBE).
The practical effect is a permanent queue. A change team finishing one compliance programme usually inherits the next before the first has bedded in.
Legacy technology absorbs the change capacity
The second load is technology. Accenture’s 2026 banking trends report found that about 70 percent of bank IT budgets are consumed by maintenance of technical debt, and that software costs have grown by an average of 8 percent a year since 2017, outpacing revenue growth (Accenture). That leaves a small slice of investment for the modernisation that customers, regulators and shareholders are all asking for.
For change leaders the consequence is less about money than about people. Modernisation programmes often depend on the same product owners, operations teams and subject matter experts who are already carrying regulatory deadlines. Every new programme draws on a shared pool of attention that nobody is measuring.
Concurrent programmes compete for the same frontline
The third load is concurrency. A branch manager, claims assessor or relationship banker may in a single quarter absorb a CPS 230 control uplift, a new lending platform, a policy rewrite and a restructure. Each programme tracks its own readiness. Nobody tracks the total. This is the heart of the saturation problem, covered in more detail in managing change saturation, and the mix of change types behind it is mapped in financial services transformation: eight core types.
Unlike a retailer or a manufacturer, a financial institution cannot treat a failed compliance transformation as a project miss. It carries regulatory penalties, remediation costs, customer trust and sometimes shareholder value, so the standard for evidence is higher.
The regulatory pressure cooker
Regulatory pressure shapes financial services transformation because it consumes most of the change budget and sets the sequencing of everything else. Boston Consulting Group found that banks spend 40 to 60 percent of their change budget on regulatory compliance, and that a significant part of that spend is inefficient because of sequential, waterfall delivery (BCG, When Agile Meets Regulatory Compliance, 2017). The share is the most-quoted quantification of the problem, and the 2025 data suggests the underlying dynamic has not eased.
The tension for transformation leaders
This creates a first tension that every transformation leader in the sector recognises. How do you fund modernisation when the majority of resources go to compliance? How do you hold momentum for a digital programme when a new directive resets priorities every few months? And how do you judge success when the regulatory requirement was met on time but the behaviour change that makes the control real never happened?
CUBE’s survey shows the scale of the execution gap. Fully implementing a regulatory change takes more than a year on average, 21 percent of respondents rate their regulatory change management as somewhat or highly ineffective, and only 16 percent report potential regulatory change directly to their executive team or board (CUBE via Wealth Briefing).
Compliance completion is not compliance behaviour
Institutions at lower maturity often stumble because they lack integrated visibility into how regulatory changes cascade through the transformation portfolio. They can complete a compliance programme on schedule and still have no view of downstream operational impact, adoption or whether the risk was actually remediated. A control that exists on paper but is bypassed by a manual workaround is the usual failure, and it tends to surface in an audit or an incident, not in a project status report.
More mature organisations build change tracking into their compliance processes. They separate two questions: did we deliver the control, and did people change how they work because of it? The second question is the one regulators increasingly ask, and the one the governance model for financial services is designed to answer.
The agility paradox: Risk as guardrail, not gate
Agile change management can work in a regulated bank or insurer when risk and compliance are built into every increment of delivery rather than applied as a final approval gate. The same environment that demands caution also demands speed, because regulation itself has become iterative and complex.
Why sequential projects fail against moving rules
MiFID II began as an 80-page level 1 text and expanded to more than 5,000 pages at implementation level (BCG). Sequential approaches assume the requirement is certain before build starts, and in this sector it rarely is. BCG estimated that properly governed agile delivery could reduce IT spending on compliance projects by 20 to 30 percent while improving on-time delivery.
Many boards remain sceptical, and the scepticism is not irrational. A technology firm can run experiments at speed. A fintech can pivot. A bank cannot without regulatory comfort, compliance sign-off and governance endorsement. Ironically, the rigidity designed to protect stability often produces slower time-to-market, higher cost and strategic misalignment when external conditions shift.
Making agile acceptable to the second line
The way through is to reimagine risk management, not to abandon it. Agile risk management means agile-specific risk assessments and continuous monitoring that embed compliance checks at every step, rather than at the end. In practice that means:
Risk, compliance and the business sit in the same cross-functional team from sprint zero.
Control objectives are written as acceptance criteria for each increment, so evidence is produced as work is done.
Release decisions use agreed risk thresholds rather than a single end-of-project sign-off.
Change impacts on frontline teams are assessed per release, not once at the start. The agile change management in the AI era article covers how to keep this practical.
This turns risk management from a gate into a guardrail.
From second line of defence to design partner
It also requires a cultural shift for risk and compliance functions. They must move from a second-line mindset in which they audit and approve to a design-partner mindset in which they collaborate from day one. Institutions with higher change maturity consistently do this better, because they have embedded risk and compliance perspectives into change governance from the start rather than at the approval stage.
The cultural challenge: Risk-aversion meets innovation
Risk-averse culture is the hidden barrier in financial services transformation because the same instincts that protect customer deposits also make experimentation feel dangerous. Conservative decision-making, extensive approval chains and multiple layers of governance evolved for good reasons. They have also built institutional muscles that resist testing.
Accountability has become personal
That culture is now reinforced by regulation. Australia’s Financial Accountability Regime applies to authorised deposit-taking institutions from 15 March 2024 and to insurers and superannuation trustees from 15 March 2025, and it is designed to improve risk and governance cultures through a strengthened accountability framework for entities and their senior executives (APRA; ASIC). When an executive is personally accountable for a change outcome, appetite for visible experimentation understandably drops.
A technically excellent transformation can stall because the institution’s cultural immune system rejects change it perceives as risky. Conversely, a transformation that wins buy-in by positioning itself as low risk may lack the ambition to change anything.
Risk-aware innovation
Leading institutions create controlled experimentation frameworks, sometimes called risk-aware innovation. The pattern is consistent:
Test in a sandbox or limited cohort with defined exposure.
Set explicit guardrails and monitoring before launch.
Agree in advance what degree of failure is acceptable in pursuit of learning.
State the trade-off openly: a marginal increase in risk here to capture an opportunity there, with the mitigation named.
The transparency matters as much as the sandbox. Regulators and boards are far more comfortable with a measured, documented risk than with an undisclosed one.
Treat resistance as data, not as a communications problem
This is also where maturity differences show most clearly. Lower-maturity organisations treat cultural resistance as an engagement problem to communicate away. Mature organisations read it as a signal of misalignment between stated strategy and actual incentives, governance structures and decision rights. They use change data, such as adoption patterns, sentiment and participation, as diagnostic tools to surface those tensions and address them directly.
Change maturity: The predictor most programmes ignore
Change maturity is a stronger predictor of transformation success in financial services than budget, sponsorship or project management rigour, because it determines whether anyone can see and correct problems while the work is under way. Institutions sit on a spectrum, and the CUBE data shows why tooling alone does not move them along it: 98 percent of respondents have some automation in regulatory change management, yet 21 percent still rate their process as ineffective (CUBE). The distinguishing factor is how change data is used, not whether it exists.
The three levels
Level 1, project-centric. Change is an overlay during a project. A team is assembled, engagement campaigns run, and the team disperses at go-live. Nobody tracks whether changes stick, adoption plateaus or benefits are realised.
Level 2, governance-integrated. Change is part of project governance and practitioners are trained. Measurement is qualitative: surveys for adoption, workshop attendance for engagement, spot checks for compliance. Leaders cannot reliably tell a programme that looks on track from one that is failing without anyone saying so.
Level 3, data-driven operations. Change is a continuous operating discipline. Adoption metrics reflect behaviour, not logins. Operational performance is tracked against baseline, compliance risk is forward-looking, and financial impact is checked against business case assumptions in real time.
What Level 3 looks like in practice
The most mature institutions integrate these streams into one view that supports diagnosis, not just description. If adoption in a division is 65 percent, the question is why: a training gap, a process design flaw, misaligned incentives, cultural resistance or weak leadership communication? Each has a different fix, and a leader armed with diagnostic data can intervene precisely.
They also distinguish the expected J-curve dip, where performance falls before it improves as teams learn new processes, from structural degradation that needs action. Their capability often goes unrecognised externally. Peers see the results and attribute them to better technology or luck, when the cause is a deliberate investment in making change visible. The foundations are laid out in why change maturity matters and how to build it.
A worked example: One control uplift at three levels
Take an illustrative case: a mid-sized insurer uplifting its operational risk controls and service provider management to meet CPS 230. At Level 1, the project team documents the new controls, runs briefings for process owners and closes the programme at the regulatory date. Whether claims or procurement teams actually follow the new steps is discovered at the next internal audit. At Level 2, the team adds a readiness survey and a training completion report, which is better, but both measure intent and attendance, not behaviour.
At Level 3, the insurer tracks the control in use: how many contract renewals went through the new due diligence step, which teams still approve suppliers through the old email route, and how long the new step adds to cycle time. When one division lags, the data shows whether the cause is workload, unclear ownership or a poorly designed form. The programme closes with evidence that the control operates, which is what a supervisor will ask to see.
What boards and regulators need: Evidence, not narrative
Senior leaders and boards in financial services need operational evidence of risk and impact, not change management frameworks or engagement scores. They want to know whether the transformation is on schedule, where adoption is stalling, what the effect on operational performance is, whether compliance is at risk and what return the investment is producing. Only 16 percent of compliance and risk leaders report potential regulatory change directly to their executive team or board (CUBE via Wealth Briefing), which suggests much of this information is not reaching the people who need it.
Five measures that replace narrative
Operational leaders in the sector think in a distinct vocabulary. These are the five measures to put in front of them:
Regulatory risk. Which processes remain misaligned with requirements, what is the remediation timeline, and what is the forward-looking exposure as systems and processes change?
Operational performance. How steep is the J-curve, how long will it last, and which signals mean intervene?
Adoption velocity. Not only whether people use the new system but at what pace and proficiency, which groups lag, and which steps are bypassed with manual workarounds.
Financial impact. Cost savings, revenue from faster time-to-market and reduced rework, tracked in real time against the business case.
Risk incident frequency. Whether the transformation is introducing new operational risk: error rates, compliance incidents, early warnings of instability.
Why the data usually does not exist
Most programmes track adoption at process level but not operational performance at transaction or customer level. They record compliance status historically, not as a forward-looking view. They report milestones, not business impact. Without the data, leaders decide on narrative and intuition, and cannot tell a programme that is tracking well but communicated poorly from one that appears on track while masking emerging operational risk. In financial services, discovering the second case at go-live rather than during implementation is exponentially more costly.
How change management software supports transformation
Change management software supports financial services transformation by turning adoption, readiness, impact and compliance exposure into a continuous, shared data set that leaders can act on before go-live. Rather than relying on periodic surveys, workshops and engagement tracking, platforms instrument the transformation to capture continuous signals. Their relevance has grown as regimes like CPS 230, which requires entities to identify, assess and manage operational risks with effective controls, monitoring and remediation (APRA), expect evidence of oversight rather than assertions of it.
What effective platforms capture
Change management metrics and success measurement. Dashboards that track whether transformations deliver intended outcomes, moving from activity metrics (people trained, workshops held) to outcome metrics tied to adoption velocity and business impact.
Change monitoring and readiness assessment. Continuous readiness for change by department, team and role, so support goes where it is needed before go-live rather than after problems appear.
Change tracking and analysis. Operational, financial and compliance position of each change, integrated with operational data to indicate what is driving adoption patterns and which interventions will work.
Performance metrics and analytics. Correlation of adoption with operational performance, compliance risk and financial outcomes, answering questions such as whether 75 percent adoption in a division is sufficient.
Strategy alignment and initiative orchestration. Connecting individual initiatives to the wider strategy so leaders see how concurrent changes interact, compound or conflict. This matters in a sector juggling dozens of regulatory and technology changes simultaneously.
Assessment and challenge identification. Early surfacing of skills gaps, process misalignments, governance mismatches and resistance, while leaders can still act.
Embedding change data in the operating rhythm
The decisive difference among mature organisations is that they do not treat this as optional project reporting. Change measures feed monthly leadership reviews. Alerts fire when adoption thresholds are breached. Compliance risk is assessed continuously, and financial impact is tracked against projections with course correction when they diverge. IAG’s change governance team describes this kind of data-led approach in a large insurer.
When a regulatory change rolls out, leaders see whether behaviour is really changing or whether people are working around it. When agile teams experiment, leaders see whether the risk envelope is holding. When a cultural programme runs, they track sentiment and behavioural adoption instead of waiting for a survey that arrives months after the decisions were made. The software is valuable not because it is clever but because it makes visible what was previously invisible.
Building credibility with regulators
This data infrastructure has a second function in the sector: it builds credibility with regulators. When a supervisor asks about a major transformation, the question underneath is whether leadership has genuine visibility of operational risk and compliance impact. Real-time transformation metrics show leadership is monitoring and managing the change, not hoping it works. In a regime where accountable executives are named, that evidence matters to the individuals as much as to the institution.
A digital tool for change visibility
For organisations ready to move from project reporting to this kind of operating discipline, purpose-built platforms such as Change Compass provide the integrated view of change impact, load and adoption across a portfolio, so that decisions about sequencing, capacity and intervention rest on evidence. The benchmark for the sector is no longer a well-run project; it is a transformation portfolio managed with the same rigour as financial or operational performance.
Systems thinking: Five data streams in one operating model
The shift from reporting to operating discipline rests on integrating five streams of data rather than collecting them in parallel. Adoption data goes beyond login frequency to whether processes are followed correctly and deliver the intended outcome. Operational data tracks speed, accuracy, error rates and compliance breaches against baseline as the change lands. Risk data gives forward-looking signals about exposure, process gaps and vulnerabilities the transformation itself introduces. Financial data compares actual cost and revenue impact with the business case. Sentiment and engagement data provides early warning of resistance or leadership misalignment.
On their own each stream describes. Together they explain. The organisations that perform best embed this combined view into how decisions get made, in monthly reviews, investment committees and risk forums, instead of keeping it as a parallel reporting activity run by the change team.
Setting the industry standard
Institutions at the top of this maturity range have stopped trying to choose between risk-aversion and innovation. They designed transformation so that risk management, compliance oversight and governance run inside the rhythm of change rather than in sequence after it. They treat controlled experimentation as a core capability, not an exception to risk doctrine, and they regard every transformation as partly a data problem: the work is to understand change in real time, at the granularity and speed senior leaders and supervisors expect.
The practical lesson for any leader in a regulated sector is that maturity is built through systems and decision infrastructure, not through more training sessions or a longer methodology document.
Frequently asked questions
Why is change management harder in financial services than in other industries?
Financial services runs transformation and regulatory change at the same time, inside a risk and compliance culture built for control. A single regulatory change takes more than a year to implement on average, and regimes such as APRA CPS 230, DORA and the Financial Accountability Regime add personal accountability for senior executives. A failed change can mean regulatory penalties and lost customer trust, not only lost money.
How much of a bank’s change budget goes on regulatory compliance?
Boston Consulting Group found that banks spend roughly 40 to 60 percent of their change budget on regulatory compliance. Much of that is inefficient when delivered through sequential, waterfall projects. The same analysis found agile approaches, properly governed, could cut IT spending on compliance projects by 20 to 30 percent while improving on-time delivery.
Can agile work in a regulated bank or insurer?
Yes, if risk and compliance are built into delivery rather than added as a final approval gate. Cross-functional teams that include risk, compliance and the business can release in small increments while controls are tested at every step. This turns risk management from a gate into a guardrail and keeps the audit trail regulators expect.
What should financial services leaders measure to know a transformation is working?
Track outcomes, not activity. The five measures that matter are adoption velocity (correct use of the new process, not logins), forward-looking regulatory risk, operational performance against baseline, financial impact against the business case, and new risk incidents introduced by the change. Linking them in one view lets leaders diagnose why a division is lagging and intervene precisely.
What are the levels of change maturity in financial services?
There are three broad levels. At the project-centric level, change management is an overlay that disbands when the project ends. At the governance-integrated level, change is part of project governance but measured mainly through surveys. At the data-driven level, change is a continuous operating discipline with real-time visibility of adoption, compliance risk, operational performance and financial return.
Building the transformation financial services needs
Delivering on time and on budget is no longer enough in this sector. The programmes that earn their place are the ones that move adoption at pace, hold operational performance through the transition, manage compliance ahead of the deadline, show a return against the business case and leave the organisation better prepared for the next round. That is an operating discipline more than a project skill, and it depends on a view of the whole portfolio, not one programme at a time.
Start with an honest placement on the three maturity levels, then pick the one measure from the five above that your board cannot currently see. Make that visible first, and use it to build the case for the rest. Institutions that do this are better able to hold regulatory deadlines, concurrent modernisation and a cautious culture in the same plan, because they can show where each is landing while there is still time to adjust.
The need for organizations to remain flexible and responsive to market demands has never been more critical, and scaled agile (SAFe) provide the framework to achieve this. Integrating change management work with SAFe is essential for seamless product delivery but yet is not clearly articulated in literature. However, for agile product delivery to be successful, it must be supported by robust change management work steps. Those that not ensures that all stakeholders are aligned and engaged throughout the process and also that the consecutive changes delivered are adopted. Let’s explore how change managers can effectively integrate their approaches with scaled agile methodologies to enhance product delivery.
Understanding the Intersection of Change Management and Agile
Change management and agile methodologies both aim to facilitate successful project outcomes, but they approach this goal from different angles. Change management focuses on the people side of change, ensuring that stakeholders are prepared, equipped, and supported throughout the transition through to benefit realisation. Agile methodologies, on the other hand, emphasize iterative development, continuous feedback, and rapid adaptation to change.
Whilst SAFe acknowledges the importance of managing the people side of change and leading the change, it does not spell out how exactly this work should be integrated with the methodology in a detailed manner. References to change tends to be at a high level and focuses on communication and readiness activities.
What are key call outs of the SAFe methodology:
1) Lean-Agile Principles: SAFe is grounded in Lean-Agile principles such as building incrementally with fast, integrated learning cycles, basing milestones on objective evaluation, and making value flow without interruptions. These principles help ensure continuous improvement and adaptability
2) Organizational Agility: To remain competitive, enterprises must be agile. SAFe enhances organizational agility by fostering Lean-thinking people and Agile teams, promoting strategic agility, and implementing Lean business operations
3) Lean Portfolio Management: Aligns strategy and execution by applying Lean and systems thinking. It includes strategy and investment funding, Agile portfolio operations, and Lean governance to ensure that the portfolio is aligned and funded to meet business goals
4) Continuous Learning Culture: Encourages a set of values and practices that promote ongoing learning and improvement. This culture is crucial for adapting to changes and fostering innovation within the organization
5) Agile Teams: Agile teams in SAFe operate using methods like SAFe Scrum or SAFe Team Kanban. These teams are responsible for understanding customer needs, planning their work, and delivering value continuously through iterative processes
6) Built-in Quality: Emphasizes the importance of quality at all stages of development. Practices include shift-left testing, peer reviews, and automation to ensure high standards and reduce defects early in the process
7) Value Stream Management (VSM): Focuses on optimizing the flow of value across the entire portfolio. VSM helps organizations improve their value delivery processes by managing and monitoring value streams effectively (Scaled Agile Framework).
8) Lean-Agile Leadership: Leaders play a critical role in fostering a Lean-Agile mindset. They must model the values and principles of SAFe, provide guidance, and create an environment that supports Agile teams and continuous improvement
9) Decentralized Decision-Making: Promotes faster value delivery by empowering teams to make decisions locally. This reduces delays, enhances product development flow, and fosters innovation
10) Customer-Centric Approach: Agile teams are encouraged to maintain close collaboration with customers to understand their needs better and ensure that solutions deliver real value. Techniques like direct customer interaction and feedback loops are essential
Below is a diagram from Scaled Agile Frameworks on key elements of a scaled agile product delivery framework.
Agile-Style Deliverable Artefacts
To support agile product delivery, change managers need to create agile-style deliverable artefacts early in the product delivery cycle. These artefacts serve as essential tools for aligning the team, stakeholders, and the overall change initiative with agile principles. They are significantly ‘lighter’ in volume and more succinct in focusing on key analysis points that determine approaches and actions required to plan and implement the change.
Change artefact 1: Change Canvas
An Agile Change Canvas is a strategic tool designed to plan, manage, and communicate change initiatives effectively within an organization. It begins with basic identification details such as the Project Name, Business Owner, and Author. This section ensures clear accountability and ownership from the outset.
The Change Vision & Objectives outlines the overarching project objectives and intended outcomes of the project. This architecture vision acts as a guiding star, ensuring all actions align with the desired future state of the organization. Following this, Core Challenges are identified to highlight potential obstacles that could impede progress. Recognizing these challenges early allows for proactive mitigation strategies.
Stakeholder Impacts analyses how different stakeholders will be affected by the change. This includes assessing both the positive and negative impacts on employees, customers, and shareholders, ensuring that their concerns are addressed and their needs met.
The Key Milestones section, presented in a table format, outlines significant checkpoints in the project timeline, often represented in Gantt charts. Each milestone is associated with a particular function, ensuring that progress is measurable and trackable. Similarly, the Resources section details the necessary financial, human, and technological resources required to implement the change, ensuring that the project scope statement is adequately supported.
Why Change section provides the rationale behind the need for change, which could include market demands, competitive pressures, or internal inefficiencies. This section justifies the project’s existence and urgency. Complementarily, What Will Change (WWC) describes the specific changes to be implemented, including processes, technologies, behaviours, and structures, offering a clear picture of the project’s scope.
Key Metrics are identified to measure the success of the change initiative. These metrics are both quantitative and qualitative, providing a comprehensive view of the project’s impact. Change Interventions listed in a table format, detail specific actions or initiatives designed to facilitate the change, ensuring a structured approach to implementation.
To foster a culture of innovation and adaptation, Change Experiments are proposed. These pilot programs test aspects of the change in a controlled environment before full-scale implementation. Finally, Change Risks identifies potential risks associated with the change and outlines strategies for mitigating these risks, ensuring that the project can navigate potential pitfalls effectively.
By incorporating these elements, the Agile Change Canvas provides a comprehensive framework for managing change initiatives, ensuring that all critical aspects are considered, planned for, and communicated effectively to stakeholders.
Using a Kanban board for change management activities provides a visual and dynamic method for tracking, prioritizing, and managing the flow of work while implementing changes. A Kanban board typically consists of columns that represent different stages of work, such as “To Do,” “In Progress,” and “Done.” For change management, additional columns might include “Proposed Changes,” “Under Review,” “Implementation Planning,” and “Monitoring.”
Whilst most change practitioners are used to kanban boards In working with various change management activities, there is opportunity to use kanban to plan and prioritise a series of agile-style changes and the associated change activities with each change. These ‘change cards’ within the kanban board presents a clear way to visualise a series of changes across the ‘delivery train’ where the project team continuously delivers pieces of change.
Prioritizing Change Management Activities
Visualizing Workflow:
Proposed Changes: This column lists all suggested changes, each represented by a card detailing the change’s purpose, impacted areas, and expected benefits.
Under Review: Changes move here once they are being evaluated for feasibility, risks, and alignment with project goals.
Implementation Planning: Approved changes are further detailed, including resource allocation, timelines, and specific tasks needed for implementation.
In Progress: Changes that are actively being worked on are tracked here, showing current status and any blockers encountered.
Monitoring: Recently implemented changes are monitored to ensure they are delivering the expected outcomes and to identify any issues early.
Done: Fully implemented and stabilized changes are moved here, marking their successful completion.
Setting Priorities:
Value and Impact: In conjunction with the project team prioritize changes based on their potential value and impact. High-value changes that significantly improve project outcomes or stakeholder satisfaction should be addressed first. From a change perspective, the input here is about the readiness of the stakeholder to receive the change, and what timing and work is required to get there.
Urgency and Dependencies: Changes that unblock other work or are time-sensitive should be prioritized. Dependencies between changes must be mapped to ensure logical sequencing. For example, work required to lift capability/leadership or readiness may be critical dependencies, without which the change cannot be delivered successfully.
Feasibility and Risk: Assess the feasibility and risks associated with each change. High-risk assessment of changes might require more careful planning and monitoring but should not necessarily be deprioritized if their impact is critical. The change input here is the people impact for the impacted stakeholders with other changes not just within this project/program, but with the overall portfolio or even outside the portfolio (including business-driven changes).
Proposed Changes: This column lists all suggested changes, each represented by a card detailing the change’s purpose, impacted areas, and expected benefits.
Under Review: Changes move here once they are being evaluated for feasibility, risks, and alignment with project goals.
Implementation Planning: Approved changes are further detailed, including resource allocation, timelines, and specific tasks needed for implementation.
In Progress: Changes that are actively being worked on are tracked here, showing current status and any blockers encountered.
Monitoring: Recently implemented changes are monitored to ensure they are delivering the expected outcomes and to identify any issues early.
Done: Fully implemented and stabilized changes are moved here, marking their successful completion.
Value and Impact: In conjunction with the project team prioritize changes based on their potential value and impact. High-value changes that significantly improve project outcomes or stakeholder satisfaction should be addressed first. From a change perspective, the input here is about the readiness of the stakeholder to receive the change, and what timing and work is required to get there.
Urgency and Dependencies: Changes that unblock other work or are time-sensitive should be prioritized. Dependencies between changes must be mapped to ensure logical sequencing. For example, work required to lift capability/leadership or readiness may be critical dependencies, without which the change cannot be delivered successfully.
Feasibility and Risk: Assess the feasibility and risks associated with each change. High-risk changes might require more careful planning and monitoring but should not necessarily be deprioritized if their impact is critical. The change input here is the people impact for the impacted stakeholders with other changes not just within this project/program, but with the overall portfolio or even outside the portfolio (including business-driven changes).
Ordering Change Planning and Implementation
Collaborative Planning:
Engage stakeholders and team members in planning sessions to discuss and agree on the priority of changes. This collaborative approach ensures that all perspectives are considered and that there is buy-in from those affected by the changes. This includes change champions.
Regular Review and Adaptation:
The Kanban board should be regularly reviewed and updated, within the change team and within the project team. During these reviews, re-prioritize changes based on new information, shifting project needs, and feedback from implemented changes. This iterative approach aligns with Agile principles of flexibility and continuous improvement.
Limit Work in Progress (WIP):
To avoid overloading the change team and ensure focus, limit the number of changes in progress at any given time. This constraint encourages the team to complete current tasks before taking on new ones, promoting a steady and manageable workflow.
Use Metrics and Feedback:
Utilize metrics such as cycle time (how long a change takes to move from start to finish, from awareness to engagement to eventual adoption) and work with the project team on the throughput (how many changes are completed in a specific timeframe) to assess the efficiency of the change management process. For example, based on the size and complexity of each discrete piece of change delivered, how long did this take and what was the deviance from actual time period planned? Feedback from these metrics should inform decisions about prioritization and process adjustments.
Engage stakeholders and team members in planning sessions to discuss and agree on the priority of changes. This collaborative approach ensures that all perspectives are considered and that there is buy-in from those affected by the changes. This includes change champions.
The Kanban board should be regularly reviewed and updated, within the change team and within the project team. During these reviews, re-prioritize changes based on new information, shifting project needs, and feedback from implemented changes. This iterative approach aligns with Agile principles of flexibility and continuous improvement.
To avoid overloading the change team and ensure focus, limit the number of changes in progress at any given time. This constraint encourages the team to complete current tasks before taking on new ones, promoting a steady and manageable workflow.
Utilize metrics such as cycle time (how long a change takes to move from start to finish, from awareness to engagement to eventual adoption) and work with the project team on the throughput (how many changes are completed in a specific timeframe) to assess the efficiency of the change management process. For example, based on the size and complexity of each discrete piece of change delivered, how long did this take and what was the deviance from actual time period planned? Feedback from these metrics should inform decisions about prioritization and process adjustments.
Benefits of Using Kanban for Change Management
Implementing a Kanban board for change management in Agile projects offers several benefits:
Transparency: Everyone involved can see the status of change activities, leading to better communication and coordination.
Flexibility: The board can be easily adjusted to reflect changing priorities and project dynamics.
Focus: Limiting WIP helps the team maintain focus and reduces the risk of burnout and task switching.
Continuous Improvement: Regular reviews and adaptations promote a culture of continuous improvement, ensuring that change management processes evolve and improve over time.
Change artefact example 3: Change Impact Assessment
A Change Impact Assessment (CIA) is an essential component in managing organizational change, particularly in agile projects where the focus is on iterative and incremental improvements. The assessment helps to understand the scope and magnitude of the change, identify affected stakeholders, and plan interventions to manage impacts effectively. An agile-friendly CIA is more summarised, and gets to the heart of what the impact is, who is impacted, how, to what extent, and when.
Below are the core elements of a change impact assessment, with a comparison to traditional methods:
1. Identifying the Impacts
Agile Approach: In scaled agile projects, the impact identification is ongoing and iterative. Each sprint or iteration is reviewed to assess the impacts of delivered changes. This dynamic approach ensures that emerging impacts are quickly recognized and addressed.
Traditional Approach: Impact identification is typically conducted at the beginning of the project, with periodic reviews. This method can be less responsive to new impacts discovered during the project lifecycle.
2. Stakeholder Identification and Analysis
Agile Approach: Continuous stakeholder engagement is crucial. Stakeholders are regularly consulted, and their feedback is integrated into the process. Agile methods ensure that stakeholders’ changing needs and concerns are promptly addressed.
Traditional Approach: Stakeholder analysis is often conducted early in the project, with limited ongoing engagement. This can result in less adaptability to stakeholders’ evolving requirements.
3. Extent and Nature of Impacts
Agile Approach: The extent of impacts is assessed incrementally, considering the cumulative effect of changes over multiple iterations. This allows for a nuanced understanding of how impacts evolve over time.
Traditional Approach: Typically focuses on a comprehensive initial assessment, with less emphasis on the evolution of impacts throughout the project.
4. Timing of Impacts
Agile Approach: Timing is aligned with the iterative delivery schedule. The impacts are mapped to specific iterations or sprints, allowing for precise planning and mitigation.
Traditional Approach: Timing is generally assessed at the project level, which can make it harder to pinpoint when specific impacts will occur during the project lifecycle.
Typical Sections of an Agile Change Impact Assessment
Impact Overview:
Explanation: Summarizes the nature and scope of the change, providing a high-level view of the anticipated impacts.
Agile Twist: Updated regularly with each iteration to reflect new findings and emerging impacts.
Stakeholder Impact Analysis:
Explanation: Identifies who will be affected by the change and how. It details the extent of the impact on different stakeholder groups.
Agile Twist: Involves continuous stakeholder feedback and updates to capture evolving impacts.
Impact Extent and Nature:
Explanation: Describes the extent (e.g., minor, moderate, significant) and nature (e.g., process, technology, cultural) of the impacts.
Agile Twist: Assessed incrementally, considering both immediate and long-term impacts across iterations.
Impact Timing:
Explanation: Specifies when the impacts are expected to occur, mapped to the project timeline.
Agile Twist: Aligned with sprint or iteration schedules, allowing for detailed timing predictions.
Mitigation Strategies:
Explanation: Outlines plans to manage and mitigate identified impacts.
Agile Twist: Adaptive strategies that are refined continuously based on iteration reviews and stakeholder feedback.
Monitoring and Review:
Explanation: Describes how the impacts will be monitored and reviewed throughout the project.
Agile Twist: Continuous monitoring with iteration-end reviews to ensure timely identification and management of impacts.
Explanation: Summarizes the nature and scope of the change, providing a high-level view of the anticipated impacts.
Agile Twist: Updated regularly with each iteration to reflect new findings and emerging impacts.
Explanation: Identifies who will be affected by the change and how. It details the extent of the impact on different stakeholder groups.
Agile Twist: Involves continuous stakeholder feedback and updates to capture evolving impacts.
Explanation: Describes the extent (e.g., minor, moderate, significant) and nature (e.g., process, technology, cultural) of the impacts.
Agile Twist: Assessed incrementally, considering both immediate and long-term impacts across iterations.
Explanation: Specifies when the impacts are expected to occur, mapped to the project timeline.
Agile Twist: Aligned with sprint or iteration schedules, allowing for detailed timing predictions.
Explanation: Outlines plans to manage and mitigate identified impacts.
Agile Twist: Adaptive strategies that are refined continuously based on iteration reviews and stakeholder feedback.
Explanation: Describes how the impacts will be monitored and reviewed throughout the project.
Agile Twist: Continuous monitoring with iteration-end reviews to ensure timely identification and management of impacts.
Stakeholder Engagement in a Scaled Agile Environment
Planning and designing stakeholder engagement activities in a scaled agile environment requires a dynamic, iterative approach that contrasts significantly with traditional, non-agile methods. In SAFe, the focus is on continuous collaboration, transparency, and adaptability, ensuring that stakeholders are actively involved throughout the project lifecycle.
Iterative and Continuous Engagement
Scaled Agile Approach: Stakeholder engagement is an ongoing process. Agile frameworks emphasize regular touchpoints, such as sprint reviews, planning meetings, and daily stand-ups, where stakeholders can provide feedback and stay informed about progress. These frequent interactions ensure that stakeholder input is continuously integrated, enabling swift adjustments and alignment with evolving needs. This iterative approach fosters a collaborative environment where stakeholders feel valued and engaged throughout the project. Engagement rhythms and processes should also be established not just at a project, but program, portfolio and enterprise levels as required.
Non-Agile Approach: Traditional methodologies often involve stakeholder engagement at fixed points in the project timeline, such as during initial requirements gathering, major milestone reviews, and final project delivery. This approach can lead to periods of limited communication and delayed feedback, which may result in misaligned expectations and missed opportunities for timely course corrections.
Flexibility and Adaptation
Scaled Agile Approach: Agile projects embrace change, allowing stakeholder engagement activities to be flexible and adaptive. As project requirements evolve, the engagement strategy can be adjusted to address new priorities or challenges. This flexibility ensures that stakeholder needs are consistently met, and any concerns are promptly addressed. Agile frameworks encourage a culture of openness and continuous improvement, where stakeholder feedback directly influences the direction of the project. Change managers need to ensure that stakeholder understand this fully, and have the skills to work within this context, not just with the project team but in leading their teams through change, when ‘the change’ may be constantly shifting.
Non-Agile Approach: In contrast, traditional approaches tend to follow a rigid engagement plan that is set at the project’s outset. While this provides a clear structure, it can be less responsive to changing stakeholder needs or external conditions. Adjusting the engagement strategy mid-project can be challenging and may require significant effort, leading to delays and potential dissatisfaction among stakeholders.
Collaborative Tools and Techniques
Scaled Agile Approach: Agile environments leverage a variety of collaborative tools and techniques to enhance stakeholder engagement. Digital platforms such as Jira, Confluence, and Miro facilitate real-time collaboration, transparency, and documentation. Agile ceremonies, such as retrospectives and demos, provide structured opportunities for stakeholders to participate and contribute. These tools and techniques help maintain a high level of engagement and ensure that stakeholders have a clear view of project progress and challenges.
Non-Agile Approach: Traditional methods might rely more heavily on formal documentation and periodic reports for stakeholder communication. While these methods ensure thorough documentation, they can sometimes create barriers to real-time collaboration and immediate feedback. Meetings and reviews are often scheduled infrequently, which can lead to less dynamic interaction compared to agile practices.
Planning Stakeholder Engagement Activities
Regular Touchpoints: Schedule frequent meetings and reviews to ensure continuous stakeholder involvement. Examples include sprint reviews, iteration planning meetings, and daily stand-ups. Business-led rhythm that enable the dissemination and engagement of updates to teams is also critical.
Flexible Engagement Plans: Develop engagement strategies that can be easily adapted based on stakeholder feedback and changing project requirements.
Use of Collaborative Tools: Implement digital tools that facilitate real-time collaboration and transparency. Tools like Jira and Confluence can help keep stakeholders informed and involved. Non-digital engagement tools may also be leveraged to fully engage with stakeholders, beyond one-way push communication. Assessment needs to be made of the openness and ability to engage regarding the change through the chosen channels.
Active Feedback Loops: Establish mechanisms for collecting and integrating stakeholder feedback continuously. This can be done through retrospectives, surveys, and informal check-ins.
Clear Communication Channels: Maintain open and clear communication channels to ensure that stakeholders can easily provide input and receive updates on project progress.
As mentioned previously, the change approach, including engagement approaches, need to take into account the broader organisational context of program, portfolio and enterprise levels. This may mean mapping out the various channels and how they can be used for different changes, stakeholders and organisational levels.
Supporting Agile Delivery Cadence
To align change management activities with agile delivery cadence, it’s essential to integrate them into the core agile events, such as PI (Program Increment) planning and demos. Here’s how:
PI Planning
PI planning, or program increment planning, is a critical event in the agile framework, where teams come together in the PI planning process to plan and commit to a set of objectives for the next increment. During PI planning sessions or PI planning events (including team breakouts), ensure that change management considerations are part of the discussion. This involves:
– Including Change Management Objectives within PI objectives and program vision: Ensure that change management objectives and organizational readiness are included in the PI planning agenda as a critical part of project management. This helps align the change activities with the overall delivery goals.
– Identifying Change Risks and Dependencies: Identify any dependencies related to the change initiative that may impact the delivery schedule and the overall agile release train. This ensures that potential risks are addressed early and do not disrupt the delivery process. Common considerations include the various people change impacts across the program and how they intersect or overlap
– Engaging Stakeholders: Involve key stakeholders in the PI planning sessions. This ensures that not just product managers but business stakeholders understand the change objectives and are committed to supporting the change initiative during the implementation process. PI planning is also a great opportunity to assess and see in action the level of engagement, support and potential leadership skills of key stakeholders to reach the common goals and business benefits.
Demos
Demos are an opportunity to showcase the progress of the agile teams and gather feedback from stakeholders as a part of the iteration plans and sprint planning. Use demos to communicate the benefits and progress of change initiatives within the entire agile release train. Engaging stakeholders in these demos can help them see the value and stay committed to the implementation plan. Here’s how:
– Highlighting Change Benefits: During demos, highlight the benefits of the change initiative and how it supports the overall product delivery goals. This helps stakeholders understand the value of the change and its impact on the project.
– Gathering Feedback: Use demos as an opportunity to gather feedback and user stories from stakeholders. This helps identify any concerns or areas for improvement and ensures that the change initiative remains aligned with stakeholder needs.
– Showcasing Progress: Showcase the progress of the change initiative during demos. This provides stakeholders with a clear understanding of how the change is evolving and the positive impact it is having on the project.
By embedding change management activities into these agile ceremonies, change managers can ensure that change initiatives are aligned with the delivery schedule and maintain stakeholder buy-in.
Implementing Change Activities as Small Experiments
One of the key principles of agile is to work in small increments and learn quickly. Change management activities can adopt this approach by implementing small experiments, such as:
Messaging
Test different communication messages to see which resonates best with stakeholders. Gather feedback and refine the messaging based on reactions. This iterative approach ensures that the communication strategy is effective and supports the change initiative. Consider the following:
– A/B Testing: Use A/B testing to evaluate different messages. This involves sending two variations of a message to different stakeholder groups and comparing the responses to determine which one is more effective.
– Feedback Collection: Collect feedback from stakeholders on the messaging. This can be done through surveys, focus groups, or informal conversations.
– Message Refinement: Refine the messaging based on the feedback received. This ensures that the communication remains relevant and impactful.
Stakeholder Involvement
Experiment with various levels of stakeholder involvement to determine the most effective way to engage them. Use these insights to inform future engagement and risk management strategies and your overall implementation strategy. Here’s how:
– Pilot Programs: Implement pilot programs with small groups of stakeholders to test different involvement strategies. This provides valuable insights into what works best and helps refine the engagement approach.
– Engagement Metrics: Track engagement metrics to evaluate the effectiveness of different involvement strategies. This includes participation rates, feedback quality, and overall stakeholder satisfaction.
– Iterative Adjustments: Make iterative adjustments to the involvement strategies based on the insights gained. This ensures that stakeholder engagement remains effective and aligned with the change initiative.
By treating change activities as experiments, change managers can adapt quickly to what works best, ensuring a smoother integration with the agile delivery process.
Best Practices for Integrating Change Management with Agile
Successfully integrating change management with agile methodologies requires a strategic approach. Here are some best practices to consider:
Foster Collaboration
Encourage collaboration between change managers and agile teams, as well as key business stakeholders within the business context. This helps ensure that different disciplines and functions are aligned and working towards the same goals. Consider the following strategies:
– Joint Planning Sessions: Conduct joint planning sessions to align change management activities with agile delivery approaches and schedules. This ensures that both disciplines are working towards the same objectives.
– Regular Communication: Establish regular communication channels between change managers and agile teams. This helps keep everyone informed and ensures that any issues or concerns are addressed promptly. Specifically focus on various agile roles such as UX (user experience), business analysis, testing, and portfolio management. There are key intersections of change work and each of these disciplines, beyond general project planning and coordination.
The below is an example of a portfolio level adoption dashboard from The Change Compass.
Change Data-Driven Insights is absolutely a Must-have for SAFe
In SAFe, change management driven by data insights is critical to ensure that changes are not only effective but also efficient and sustainable. Data-driven change management leverages quantitative and qualitative data to guide decisions, optimize processes, and align strategic goals across the organization. By incorporating metrics and analytics, organizations can gain a comprehensive understanding of the impact and progress of change initiatives, allowing for timely adjustments and informed decision-making.
At the portfolio level within a SAFe setting, data-driven insights are essential for prioritizing initiatives and allocating resources effectively. More than this, change data including stakeholder capability, readiness and impact levels can be critical to determine when releases should happen, the priority of releases, and the sequencing of releases.
Ill-prepared or insufficiently skilled stakeholders may require longer time to adapt to the change. Also, looking beyond the project itself, by understanding the overall change landscape for the impacted stakeholders, change releases may need to be chunked and packaged accordingly to maximise adoption success.
Key attention should also be paid to the impact on business performance of impacted stakeholders, not just from a change volume perspective, but also from a strategy perspective in terms of how best to reduce risk of performance disruptions. Is it through exemplary middle leadership? Or frontline engagement? Or the power of change champions embedded across the business?
At the enterprise level, data-driven change management enables organizations to scale agile practices consistently and coherently across the entire team across multiple portfolios. This involves the use of enterprise-level dashboards and analytics tools that provide a holistic view of the organization’s agile transformation. Key performance indicators (KPIs) such as employee impact data, adoption rates, readiness metrics and productivity metrics help leaders assess the effectiveness of change initiatives and identify areas that require additional support or intervention. For instance, tracking the adoption rate of agile practices across different departments can highlight areas where additional training or coaching is needed to ensure consistent implementation.
Integrating change management with scaled agile methodologies is essential for seamless product delivery in today’s dynamic business environment. By creating agile-style deliverable artefacts early, continuously adapting engagement activities, supporting agile delivery cadence, and implementing change activities as small experiments, measure change progress and outcomes, change managers can effectively support agile product delivery. This integration not only enhances the success of change initiatives but also ensures that product delivery is seamless and aligned with organizational goals and the strategic plan.
By fostering collaboration, embracing agile principles, and using data-driven insights, change managers can create a cohesive strategy that maximizes the benefits of both change management and agile methodologies. This holistic approach ensures that change initiatives are successful, stakeholders are engaged, and product delivery is efficient and effective.
Chat to us to find out more about how to leverage the power of a change measurement platform to sustain your single source of truth to support your scaled agile organisation.
Agile methodology is fast becoming the ‘norm’ when it comes to project methodology. There are strong benefits promised of faster development time, the ability to morph with changing requirements, less time required to implement the solution, and a better ability to meet project objectives through continuous improvement. There aren’t too many organisations that do not use some form of agile project methodology in how they manage initiatives.
What started out as a way of developing software has evolved into the accepted methodology for managing projects. A scan of literature available on the internet shows a significant outline of the various roles, including the product owner and the development team, and their importance to stakeholders, including end users, in the agile project methodology process. Most roles are clearly outlined and accounted for. There are clear roles established for the business owner, the project manager, the scrum master, developers, testing and quality, product manager, architect, human-centred designer, and even IT operations.
However, there is a glaring gap. What about the role of the change manager?
A review of literature available through project management organisations such as APM (Association of Project Management) and PMI (Project Management Institute) showed glaring omission of the role of the change manager or change management practitioners from agile methodology. The same is also true for Scaled Agile Frameworks where there is a brief mention of the importance of change management in the agile approach, but no mention of the role of the change manager/practitioner.
Is it that there are less projects requiring change managers?
The evidence is against this hypothesis. Jobs in change management are plentiful, with data on ‘Indeed’ online employment portals pulling up over 38,000 job postings. On top of this, there is an increasing number of jobs posted. According to the U.S. Bureau of Labor Statistics, “management analytics” which includes change management, is projected to have a 14% growth rate between 2018 and 2028. In Australia, the ‘Seek’ employment platform projected change management job growth to be at 15% growth in the next 5 years.
Is it that agile methodology is more for technical projects and therefore the omission of change managers?
The agile approach and agile manifesto can be used for a range of different projects, but not all projects. There is certainly evidence of agile project methodology used by software developers in a wide range of industries from financial services, government, non-profit, pharmaceuticals, utilities, and retail industries. The agile methodology is commonly cited for being better for projects where the outcome is not clearly known and where the end change has a level of uniqueness. There are times, though, when waterfall methodology is more appropriate, depending on the situation.
However, it is not true that agile methodology is only used for more technical projects. Even for projects where the focus is not on technical development, agile approaches are used widely. Agile changes have been used for re-organisation exercises. Here is an example from the Business Agility Institute. Executive teams also use agile means to manage various strategic initiatives that are not technical. Agile approaches are even applied to managing church initiatives.
What is the likely reason for the clear omission of change management in the agile methodology?
Organisations in charge of documenting agile methodology are mainly focused on project management and software development. If we take the examples of PMI and APMG, both are project management associations, and both are focused on the project management perspectives of agile, particularly in complex environments. The portion on organizational change management is a specialism of project management. It could be that these organisations have not sufficiently developed agile change management methodology to integrate with agile project management.
Organisations in charge of documenting agile methodology are mainly focused on project management and software development, and not include the agile change management process. If we take the examples of PMI and APMG, both are project management associations, and both are focused on the project management perspectives of agile. The portion on organizational change management is a specialism of project management. It could be that these organisations have not sufficiently developed agile change management methodology to integrate with agile project management.
Even at Scaled Agile, which is about applying agile across the organisation, the omission of the role of change managers is still the case. Frameworks from Scaled Agile are quite detailed and rigorous. All aspects of the roles of various organisational members, including scrum teams, are clearly outlined. Even the role of IT departments in DevOps are clearly spelled out to support agile. But not the role of change managers. Again, this could be due to those at Scaled Agile not having a change management background, and therefore not being able to articulate the various role detail.
However, there are some very critical roles that change practitioners play not only at project level, but at program, epic, and organisational levels. Without the right change management support the following are key risks when organisations are working at SaFe (scaled agile) level:
Change sequencing to maximise adoption across the change portfolio
Packaging change to achieve optimal change adoption, e.g. in terms of integrating communications and learning interventions across projects
Establishing business unit based change champions that can support multiple projects and can help piece together different changes for impacted employees
There are some attempts at closing the gap to document agile change management approaches as a part of the change management process. However, most are conceptual, high level, and not sufficiently detailed to provide clear guidance and practical application for the change practitioner. On the other hand, the work of change management in agile projects should not only be clear for the change practitioner but also be clear for the project manager and other project members.
To access practical agile playbooks visit our agile playbook resources.
What’s the problem of omitting the role of change managers from agile methodologies?
1. The role of change management could easily be omitted. Particularly for less experienced project managers who are starting out in agile. The risk could be that change management is omitted from the project altogether since it is not called out as a clear role
2. Change practitioners and agile practitioners are not clear with the roles they play and therefore are not sufficiently involved in driving and supporting the project in the right way. Since there is not a clear set of guidelines and agile principles methodology for change practitioners, it is common to see varying approaches in how change managers support agile projects within the current business environment, with some still using a similar approach as to supporting traditional change management and waterfall projects which may not be appropriate.
3. Agile projects are not successful because change management work is not sufficiently incorporated into agile processes, particularly in the context of digital transformation. With change management roles not spelt out, the project executes the change without critical change management foundations, and therefore, by embracing agile thinking, it is at the risk of not achieving the adoption, adaptation, and benefit realisation targeted.
What should we do about this?
1. Encourage change management associations such as CMI and ACMP to invest in detailing agile change management methodology in a way that sets standards and guidelines for change management skills practitioners to follow.
2. Influence and work with APMG, PMI and Scaled Agile to include explicitly the role of change managers and agile change management methodology.
Change management is emerging to be a strong discipline that executives are starting to recognise as critical to successful change. The role of change practitioners should be stated explicitly and recognised clearly. Change managers should not have to tip-toe in maneuvering their place in supporting agile change projects, nor should they need to convince other project team members of their place throughout various agile routines and methodology phases. It is now time for the change community to drive this and achieve the recognition that it deserves.
Diagnosing change resistance is the practice of working past the most visible symptoms to identify the actual structural, behavioural or environmental cause that is blocking adoption. Surface-level blockers, such as low attendance at training or complaints in town halls, are usually downstream effects of deeper causes: unclear sponsorship, competing operational pressures, undisclosed scepticism about the business case, or a previous change that left scar tissue. A layer-by-layer diagnostic method asks “what is causing this” repeatedly until the answer points to something the change team can actually act on. Without this discipline, change interventions end up addressing symptoms while the root cause continues to derail adoption.
Change management, much like peeling an onion, involves uncovering multiple layers before reaching the core. Each layer peeled back in the journey of planning and implementing change reveals new insights about the organization and the stakeholders impacted by the change. This process is essential to understanding the full scope of the change, adapting strategies accordingly, and ensuring successful implementation. By examining the various facets of an organization, such as leadership capability, operational practices, and cultural traits, we can better navigate the complexities of change management. Let’s explore the analogy of peeling an onion in change management and some practical insights for transforming change outcomes.
What is the peeling the onion protocol and how does it work?
The Peeling the Onion Protocol is a change management strategy that involves gradually uncovering layers of resistance within an organization. By systematically addressing concerns and facilitating open dialogue, this protocol fosters understanding and acceptance of change, ultimately leading to smoother transitions and enhanced collaboration among team members.
Peeling the layers – each layer reveals a different facet of the organisation and how they may or may not be conducive to supporting the change. Here are some ‘layers’ you may want to examine.
Leadership and Managerial Capability in Managing Change
Effective change management begins with strong leadership. Leaders and managers play a crucial role in guiding the organization through the transition. Peeling back this layer reveals whether leaders are equipped with the necessary skills, knowledge, and attitudes to drive change. It also highlights their ability to inspire and mobilize their teams, communicate the vision effectively, and manage resistance. Assessing leadership capability is fundamental, as inadequate leadership can hinder the entire change process.
Operational and Business Practices
The next layer involves examining the organization’s operational and business practices. This includes evaluating current workflows, processes, and systems to identify areas that may need adjustment or improvement. Understanding how daily operations align with the proposed changes helps in anticipating potential disruptions and devising strategies to minimize them. Are existing practices consistent with the end state of the change? Are existing practices consistent? (or NA?) Why or why not? This layer also involves identifying key performance indicators (KPIs) that can measure the success of the change initiatives (https://thechangecompass.com/how-to-manage-a-multitude-of-change-initiatives-including-enterprise-wide/).
Change Governance Practices and Structure
Change governance refers to the frameworks and structures in place to manage and oversee change initiatives. Having the right governance structure ensures that the right oversight and decision making is setup to steer the change to success. Peeling back this layer involves assessing the effectiveness of existing governance mechanisms, such as steering committees, decision-making protocols, and accountability structures. Strong change governance ensures that change initiatives are well-coordinated, resources are allocated appropriately, and progress is monitored consistently. Weak governance, on the other hand, can lead to confusion, misalignment, and failure to achieve desired outcomes.
Key questions to ask here include such as:
Is there sufficient governance bodies in place at different levels of the organisation to support change?
Are there too many governance bodies?
Are decision-making processes clear and effective?
Are the right stakeholders involved in the relevant decision-making areas?
Engagement Channels
Effective engagement is critical in change management. This is more than just communication. This layer focuses on the channels and methods used to engage with stakeholders throughout the change process. Evaluating engagement channels helps in understanding how information is disseminated, feedback is collected, and concerns are addressed. It also highlights the effectiveness of internal communications and the role of external communications in managing stakeholder expectations and perceptions. What channels are most effective for what audience groups? Are there any gaps for engaging with all groups of stakeholders? (beyond just blasting emails or messages).
Change Champion Network
Change champions are resignated individuals within the organization who advocate for and support the change initiatives. Peeling back this layer involves identifying and empowering these champions. It also includes assessing their influence, credibility, and ability to motivate others. A strong network of change champions can facilitate smoother transitions by promoting buy-in, addressing resistance, and reinforcing positive behaviors. With the right nurturing and experience, an organisation-wide changechampion network can act to support a myriad of change initiatives.
System and Process Maturity
The maturity of systems and processes within an organization significantly impacts the success of change initiatives. This layer involves evaluating the current state of technological systems, process automation, and data management practices. Mature systems and processes provide a solid foundation for implementing changes efficiently and effectively. Conversely, immature systems may require significant upgrades or overhauls to support the desired changes.
Change Management Maturity
Change management maturity refers to the organization’s overall capability to manage change. Peeling back this layer involves assessing the maturity of change management practices, methodologies, and tools. Organizations with mature change management capabilities have established frameworks, experienced practitioners, and a culture that embraces change. In contrast, organizations with low maturity may struggle with inconsistencies, resistance, and a lack of structured approaches.
This layer examines the availability of resources and capacity to support change initiatives. It includes assessing the organization’s financial resources, human capital, and physical infrastructure. Adequate resources and capacity are essential for executing change plans, overcoming obstacles, and sustaining momentum. Insufficient resources can lead to delays, reduced quality, and increased stress on employees. This does not just include the resources required within the project itself, it points more to the impacted stakeholders and if they have the resources and capacity required to undergo the change.
Culture and Behavioral Traits
Organizational culture and behavioral traits play a significant role in how change is perceived and adopted. Peeling back this layer involves understanding the underlying values, beliefs, and behaviors that influence how employees respond to change. It also includes identifying cultural strengths that can be leveraged and cultural barriers that need to be addressed. A supportive culture fosters resilience, adaptability, and a positive attitude towards change.
Specifically:
Do existing behaviours and practices support the change end state?
Are there potentially inconsistent behaviours comparing the end state and the current state?
Beyond the specific behaviours required in the change initiative itself, how are these in alignment with broader cultural practices?
Key Takeaways from the Onion Analogy in Change Management
1. Each Layer Needs to Be Peeled Before Another Layer Can Be Peeled
The process of discovering and understanding the complexities of change cannot be rushed. Each layer provides valuable insights and learning opportunities that prepare the organization for the next layer of discovery. Skipping layers or rushing through the process can lead to incomplete assessments, overlooked challenges, and ineffective solutions. Patience and persistence are crucial for a thorough and successful change management journey.
Assessing and understanding each layer can take time. Data, both quantitative and qualitative, may be required to truly understand what each layer means and how it implicates the change.
2. How the Onion Appears May Not Be What It Is at Its Core
Initial perceptions of the organization may not reflect its true state. It takes time and effort to uncover the deeper issues, strengths, and opportunities. This requires a willingness to look beyond surface-level indicators and delve into the core aspects of the organization. Attention to detail and a commitment to uncovering the truth are essential for developing accurate and effective change strategies.
For example:
Are publically communicated and reinforced messages acted on?
Do leaders practice what they preach?
Do stakeholders commit to decisions already made? Or do they ignore it?
Is there clear alignment between different layers of the organisation? How is this done?
3. You May Discover Rotten Parts That Need to Be Replaced
During the process of peeling back layers, you may encounter parts of the organization that are severely inadequate or dysfunctional. These “rotten” parts may need to be replaced or significantly improved before the change can proceed. This could involve overhauling critical capabilities, restructuring teams, or implementing new systems. Recognizing and addressing these issues promptly is essential for ensuring the overall health and success of the organization.
You may find, for example:
Stakeholders that are adamant to block the change for various reasons
Teams that simply do not have the right skills or attitude to transition to the required state
Processes that are simply outdated or convoluted, so much that end state targets cannot be achieved
Systems that are outdated and do not provide the right insights to support the end state
4. Different Types of Onions and Organizations
Just as there are different types of onions, organizations vary in size, complexity, and nature. Assessing the complexity of the change at the outset helps in determining the time, effort, and resources required to peel back the layers. A comprehensive understanding of the organization’s unique characteristics allows for tailored change management strategies that address specific needs and challenges.
Practical Steps for Applying the Onion Analogy in Change Management
Step 1: Initial Assessment and Planning
Begin by conducting a thorough initial assessment of the organization. This involves gathering data, engaging with key stakeholders, and understanding the current state of affairs. Develop a comprehensive change management plan that outlines the objectives, scope, and timelines for each layer of the onion. This plan should also identify key metrics for measuring success and mechanisms for tracking progress.
Step 2: Assess Leadership and Managerial Capability
Evaluate the capability of leaders and managers to drive change. This includes assessing their skills, experience, and attitudes towards change. Provide training and support where needed to enhance their ability to lead effectively. Strong leadership is foundational to the success of any change initiative.
Step 3: Examine Operational and Business Practices
Analyze current workflows, processes, and systems to identify areas that may require adjustment. Engage with employees at all levels to gather insights and understand potential bottlenecks. Develop strategies to streamline operations and ensure alignment with the change objectives.
Step 4: Review Change Governance Practices
Assess the existing governance structures and practices in place to manage change initiatives. Ensure that there are clear decision-making protocols, accountability mechanisms, and regular progress reviews. Strengthen governance frameworks as needed to support effective change management.
Step 5: Evaluate Engagement Channels
Review the channels and methods used to communicate with stakeholders. Ensure that there are effective mechanisms for disseminating information, collecting feedback, and addressing concerns. Enhance engagement strategies to foster transparency, trust, and collaboration.
Step 6: Identify and Empower Change Champions
Identify individuals within the organization who can serve as change champions. Empower them with the necessary tools, resources, and support to advocate for the change initiatives. Leverage their influence and credibility to promote buy-in and address resistance.
Step 7: Assess System and Process Maturity
Evaluate the maturity of technological systems and processes. Identify areas that require upgrades or improvements to support the change. Invest in the necessary infrastructure and tools to ensure seamless implementation.
Step 8: Assess Change Management Maturity
Conduct a maturity assessment of the organization’s change management capabilities. Identify gaps and areas for improvement. Develop and implement strategies to enhance change management practices, methodologies, and tools.
Step 9: Review Resources and Capacity
Evaluate the availability of resources and capacity to support the change initiatives. Ensure that there are adequate financial, human, and physical resources to execute the change plans. Address any resource constraints proactively to prevent delays and disruptions.
Step 10: Understand Culture and Behavioral Traits
Conduct a cultural assessment to understand the underlying values, beliefs, and behaviors that influence how employees respond to change. Identify cultural strengths that can be leveraged and barriers that need to be addressed. Develop strategies to foster a supportive culture that embraces change.
The analogy of peeling an onion provides a powerful framework for understanding and managing change within an organization. Each layer peeled back reveals new insights and learning opportunities that are essential for successful change management. By carefully examining the various facets of the organization, such as leadership capability, operational practices, and cultural traits, organizations can navigate the complexities of change more effectively.
Patience, persistence, and attention to detail are key to uncovering the true state of the organization and developing tailored strategies that address specific needs and challenges. Ultimately, the journey of peeling the onion in change management leads to a deeper understanding, better preparation, and more successful change outcomes.
