Study guide
2.2 VUCA and the Cynefin Framework
APMG Change Management Foundation Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: The v3 Foundation Exam and the Organisational Context
1.1 Exam Structure, the Five Syllabus Areas and the Certification Path 1.2 Scene Setting: External and Internal Factors Shaping Change 1.3 Change Management, Benefits and Dis-benefits
2 Chapter 2: Understanding the Change Context
2.1 Kelman's Three Levels of Adoption 2.2 VUCA and the Cynefin Framework 2.3 Planned Change versus Emergent Change 2.4 Systems Thinking in Change 2.5 Organisational Culture and Its Three Levels
3 Chapter 3: Diagnosing and Structuring the Change Approach
3.1 Lewin's Force Field Analysis 3.2 Co-Design 3.3 The ADKAR Model 3.4 Evolving the n-Step Process and Kotter's Eight Accelerators
4 Chapter 4: Delivery Strategy, Agile Practices and the Change Strategy
4.1 Delivery Strategy: Big Bang, Phased, Voluntary and Iterative 4.2 Agile Practices and Agile Change Practices 4.3 The Continuous Change Management Cycle 4.4 The Change Strategy
5 Chapter 5: People and Change — Individual Difference and Response
5.1 Differences in People and Personality Preferences 5.2 Neuroscience and Change: SCARF, Mindset and Insight 5.3 The Change Curve 5.4 Bridges' Transition Model
6 Chapter 6: Motivation, Resilience and Learning
6.1 Rewards, Punishment and Pink's Three Motivators 6.2 Positive Psychology, Resilience and Appreciative Inquiry 6.3 The Beckhard-Harris Change Formula and Schein's Two Anxieties 6.4 Competence, Learning and the Learning Dip 6.5 Learning Preferences: Kolb, Honey and Mumford
7 Chapter 7: Key Roles in Change Leadership
7.1 Key Roles in the Change Process 7.2 The Role of the Change Sponsor 7.3 The Change Agent's Role and Personal Influence 7.4 The Role of Local Leadership in Change
8 Chapter 8: Psychological Safety, Leadership and Culture
8.1 Psychological Climate and Psychological Safety 8.2 Carolyn Taylor: How Leadership Shapes Culture 8.3 Leadership Styles and Organisational Climate
9 Chapter 9: Teams and Change
9.1 Team Structures and Change Agent Networks 9.2 Tuckman's Stages of Team Development 9.3 Lencioni: Assessing and Growing Team Effectiveness 9.4 Harvesting the Value of Team Diversity
10 Chapter 10: Stakeholder Identification, Analysis and Engagement
10.1 Stakeholder Definition and Identification 10.2 Stakeholder Analysis, Segmentation and Empathy Mapping 10.3 Stakeholder Mapping and Sources of Power 10.4 Barriers to Engagement 10.5 Planning Stakeholder Engagement
11 Chapter 11: Communication Theory, Messaging and Emotional Connection
11.1 Communication Theory and the Communication Process 11.2 Barriers to Communication and Cognitive Biases 11.3 Messaging: Setting Context and the Tell, Sell, Include Approach 11.4 Appealing to Hearts and Minds
12 Chapter 12: Communication Channels and Planning
12.1 Ways of Communicating and VARK Language Style Preferences 12.2 Communication Channels: One-Way, Two-Way, Lean and Rich 12.3 Communications Planning
13 Chapter 13: Assessing Change Impact and Severity
13.1 Change Management as Risk Management and the Two-Step Assessment 13.2 Step 1: Categorising Impacts and Identifying Impact Areas 13.3 Step 1 Continued: Gap Analysis, Impact Profiles and Monitoring 13.4 Step 2: Change Impact Severity
14 Chapter 14: Resistance to Change
14.1 Causes of Resistance and Oreg's Four Neural Factors 14.2 Common Reasons for Resistance and How to Deal With Them 14.3 Building a Strategy to Manage Resistance
15 Chapter 15: Change Analytics and Exam Readiness
15.1 Measurement Types and the Change Delivery Scorecard 15.2 Building a Change Analytics Strategy 15.3 Exam Technique and Final Revision
2.2 VUCA and the Cynefin Framework
Key Takeaways Explain This Topic AI
VUCA stands for volatile, uncertain, complex and ambiguous, describing the conditions many changes operate in
Cynefin, developed by David Snowden, sorts situations into obvious or simple, complicated, complex and chaotic domains
In the obvious domain cause and effect are clear and best practice, rules and processes apply
In the complex domain relationships between elements are unknown and it is often safer to take an experimental, emergent approach
- In the chaotic domain immediate action is needed even though results will be unpredictable
- Last updated: September 2026
Two tools help a change manager describe the kind of situation they are facing before choosing an approach. VUCA names the conditions. Cynefin classifies the problem and prescribes a matching response.
VUCA
VUCA is an acronym describing conditions in which change increasingly takes place:
- Volatile — the situation changes rapidly and unpredictably in scale and speed
- Uncertain — the future is hard to forecast even with good information; precedent is a poor guide
- Complex — many interconnected variables produce effects and impacts that are hard to trace to causes
- Ambiguous — the meaning of what you are seeing is unclear; the same evidence supports several readings
VUCA is descriptive rather than prescriptive: it explains why detailed multi-year change plans built on fixed assumptions so often fail, and it justifies the more adaptive, feedback-driven approaches that CM3 sets out later in the syllabus.
The Cynefin framework
Cynefin, developed by David Snowden , is a sense-making framework. Its central argument is that different kinds of situation require fundamentally different responses, and that applying the wrong kind of response is a common source of failure. Learn the four domains and their characteristic responses precisely — the exam quotes their wording.
Domain Cause and effect Who helps Appropriate response
Obvious (Simple) Clear; the situation is stable and well understood Anyone following the rules Rules, processes, policies and best-practice approaches
Complicated Knowable but requires careful analysis; often many "right" answers Experts are essential Analyse, then work towards a solution or a plan
Complex Relationships between elements are unknown; even the right questions are unknown Experts help but may disagree, and their advice should not be ignored An experimental, emergent approach — cautious, safe-to-fail, with input from all levels
Chaotic Major cause-and-effect relationships are unknown and may change Nobody yet Immediate action; results will be unpredictable but may clarify the situation
Obvious or simple
The situation is stable and well understood, and cause and effect are clear. A change of this type — updating a form, changing a supplier code, implementing a small procedural amendment — is amenable to rules, processes, policies and best practice. Elaborate engagement machinery here is waste.
Complicated
The relationship between cause and effect is knowable but requires careful analysis, and there are often many right answers. This is expert territory: a pension scheme migration, a regulatory implementation, a data-centre move. It is possible, though not easy, to work towards a solution or a plan. Planned change approaches fit well.
Complex
Here relationships between the elements of the situation are unknown, and even the right questions to ask are unknown. Experts can help, and their advice should not be ignored even when their opinions differ, but that advice should be combined with a cautious safe-to-fail experimental approach, with input and discussion from all levels of the organisation recommended.
Culture change, changes to ways of working, and most behaviour-dependent change sit here. This is the domain that punishes over-planning most severely: a detailed 18-month plan in a complex domain is a confident statement about relationships you do not actually understand.
Chaotic
Major cause-and-effect relationships are unknown and may change; the situation and its future are unknown. Immediate action is often needed even though the results will be unpredictable — though those results might help clarify aspects of the situation. A major incident, a sudden regulatory shutdown, a critical system failure. In chaos you act to establish some stability, then reclassify.
Using Cynefin in change decisions
The practical discipline is to classify before you plan, then match:
Classify the change. Which domain does this genuinely sit in? Be honest — organisations habitually classify complex changes as complicated because complicated problems can be planned and reported on comfortably.
Choose a matching delivery approach. Obvious and complicated changes suit planned, structured delivery. Complex changes suit iterative, incremental delivery with feedback loops and a continuous change cycle.
Re-classify as you learn. A change can move domains. A complex change often becomes complicated once you have run enough experiments to understand the relationships.
The most common and most damaging error is treating a complex situation as complicated — commissioning experts to produce a definitive plan for something whose causal relationships nobody actually understands, then defending the plan when reality contradicts it.
Reclassifying as you learn
Cynefin domains are not permanent labels, and one of the framework's practical uses is tracking movement between them.
A change that starts complex — nobody knows how a new collaborative way of working will land — becomes complicated once enough experiments have run to reveal the relationships, at which point planning becomes appropriate and continued experimentation becomes wasteful. A change in the obvious domain can be knocked into chaotic by a system failure at go-live, and the correct response changes immediately from following the process to acting to establish stability.
The discipline is therefore to revisit the classification at intervals and after any significant event, and to say out loud when it changes, because the appropriate governance changes with it. A complex-domain change reporting against a fixed plan is being governed as though it were complicated, and the mismatch produces the familiar pattern of a programme defending a plan against evidence.
The framework also names a fifth state — disorder or confusion — for situations where the domain has not been agreed. That is not a stable place to operate from: in practice, unclassified changes default to being treated as complicated, because that is the domain conventional project governance is built for.