ITIL® by ITSM Assist Ltd

Complexity Thinking

The Cynefin Framework ("Cynefin" a Welsh word for habitat) was designed to help with decision-making and problem-solving based on principles relating to response and sense-making (complexity-thinking).

ITIL® 4 endorses the Cynefin Framework particularly when addressing complexity in environments that are volatile, uncertain, complex and ambiguous (VUCA).

The Cynefin Framework Explained:

There are five domains which make-up the Cynefin Framework, organised by the relationship between cause and effect as shown below:

1. Clear (obvious)

2. Complicated

3. Complex

4. Chaos

5. Disorder (confused/aporetic)

Referring to the diagram above, the domains on the right-hand side allow cause and effect to be deduced, whereas the domains on the left-hand side of the diagram can only be deduced by hindsight.

This framework can be applied in many situations, in fact I often incorporate this framework within incident management.

Clear (obvious) Domain

This is where we have clear causality, where predetermined best practice should be applied, e.g., based on fixed actions such as following a predefined model. For clarity, a model is defined as “predefined steps” and whilst these steps do not typically include detailed content, albeit these steps may include basic scripts, guidelines, procedures and instructions etc., following each step in the predefined order of the model will normally produce a satisfactory resolution. Simply put, we could translate this as first line support resolution executed by a service centre agent. Or from a manging a project perspective, we could translate this as a typical Waterfall approach.

Given the nature of this domain is we first sense, then categorise, and then respond.

Complicated Domain

This is where we have unclear but knowable causality that can be determined by analysis or expertise (good practice) based on governing constraints. Meaning while there is high probability of the outcome there is more freedom compared with fixed constraints referred to within the Clear Domain however, with less freedom compared with enabling constraints within the Complex Domain. Simply put, we could translate this as escalating to a specialist team, or improving a product, e.g., where all the variables are knowable and such a team know what we need but not sure how to go about it. We normally use the term “good practice” here because whilst we can indeed adopt elements of best practice, this domain may not necessarily follow a predefined model, in other words its best way we know how. From a manging a project perspective, we could translate this as a typical Agile/Scrum approach.

Given the nature of this domain we first sense, then analyse, and then respond.

Complex Domain

This is where we have unclear and unknowable causality requiring fail-to-safe experimentation based on enabling constraints. Meaning we expect to produce a wider range of outcomes and have more freedom compared with enabling constraints highlighted within the Complicated Domain. Simply put, we could translate this where many factors and/or situations intervene therefore, in the context of an incident this would typically trigger a Swarm (where a temporary cross-functional team of experts come together). From a manging a project perspective, we could translate also as potentially pre-Agile/Scrum requiring parallel experimentation due to such ambiguity. This domain could also represent new situations where we are unable to make predictions such as the stock market or controlling an epidemic.

Given the nature of this domain we first probe, then sense, and then respond.

Chaotic 

This is a more extreme form of complexity (e.g., a place of unknown and unknowable) and demands immediate action with a view of taking control and stabilising the situation, where at the very least transitioning the situation to the Complex Domain as quickly as possible.. In the context of an incident this could be translated as a major incident.

Given the nature of this domain we first act, then sense, and then respond.

Disorder (confused/aporetic)

The state of not knowing in which of the other domains you are in. In this domain we are lost with a lack of situational awareness therefore, there may be a bias to assume that the domain corresponds to the context in which we are most experienced based on past behaviours and/or previous decisions. In the context of an incident, if the entire user community are unable to access the network, we find ourselves in a state of confusion however, as part of this confusion are we in denial of a systems attack or is it really a power outage?

In conclusion, there are many benefits gained through adopting the Cynefin Framework, such as:

• Recognising the complexity by whether we are "sensing and categorising", "sensing and analysing", "probing and sensing" or "acting and sensing", or if we are in a state of "disorder and confusion"?
  

• Recognising the proportion of activities which take place in the "Clear Domain" that could be robotised (automated or part automated)? Meaning, recognising where humans are best placed.
  

• Recognising how many situations we are moving from the "Clear Domain" to the "Complicated Domain"? Meaning how much tacit knowledge required in the "Complicated Domain" could be transformed into explicit knowledge and therefore, remain within the "Clear Domain".
  

• Recognising when and where swarming is best placed, and when and where experimenting is needed?

And it goes on...