2.2 VUCA and the Cynefin Framework

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.

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:

1. 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.
2. 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.
3. 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.