Cynefin (cu-NE-vin) is a Welsh word that translates literally to English as haunt or habitat but actually means much more than either of those simple English words. The Cynefin Framework was created by Dave Snowden of Cognitive Edge as a tool to help decision making in complex social environments.
One of Snowden’s reasons for choosing this unusual name for his framework was simply that: “A name which requires a story to explain its meaning avoids confusion or association with existing concepts.”
The framework starts with three types of system: ordered, complex and chaotic. Ordered is divided into two areas called simple and complicated giving four in total. The point of the framework is to help you understand which of the four domains you are dealing with. Hence there is a fifth domain called ‘disorder’ which simply represents the fact that you don’t know which of the other four applies to your situation.
The Cynefin framework has relevance to projects, programmes and portfolios because the P3M approach has to be tailored to the context of the work. Factors such as complexity and uncertainty need to be understood before deciding whether to manage the work as a project or programme, or perhaps deciding whether iterative approaches (such as Agile) are relevant or not.
Click on any of the five labels to jump to the corresponding description.
This is the starting point where you don’t know which of the four domains is relevant. The following four descriptions should be studied to help position the work you are about to undertake. This helps, for example, with the requirement in the identification process of the Praxis process model to decide whether to manage the work as a project or a programme.
Care should be taken because people tend to assess the situation according to their preferred way of working.
In the simple domain there are cause and effect relationships that are predictable and repeatable. They are self-evident to any reasonable person. In the P3M environment it is reasonable to assume that ‘any reasonable person’ represents someone with a technical understanding of what the work involves.
For example, in a construction environment a simple project may involve building a house, especially if the project team have built many such houses before. There will be differences each time they build a house but the cause and effect relationships are well understood. Similarly, in an IT environment, a new web site may follow a tried and trusted format with well-established templates but different content each time.
In this domain the approach is to sense-categorise-respond, i.e. work out what the differences are for this project, categorise them and respond to those differences. Snowden maintains that this is the only domain where the concept of ‘best practice’ is relevant.
People who spend a lot of time in this domain will probably see any project failure as a ‘failure of process’.
In the complicated domain the cause and effect relationships still exist but they are not self-evident and require expertise to analyse them. An example may be building a bridge. While the team may have built many bridges before, every span across a river or road; the traffic it needs to carry and the weather or geological conditions it must survive are different. Specialist structural engineers will analyse the specific context and prepare designs.
The approach here is to sense-analyse-respond and the management of the project would be regarded as ‘good practice’ rather than ‘best practice’.
People who spend a lot of time in this domain will probably see any project failure as being caused by there being insufficient information on which to base the analysis.
Work in this domain has causes and effects that are unpredictable and only obvious in hindsight. Business change programmes would fit into this category as do many IT projects/programmes. This is largely because there are multiple stakeholder relationships with opinions and requirements that emerge with time.
The approach here is to probe-sense-respond, i.e. you will need to experiment and test in order to understand the detailed scope of the work.
The P3M community typically responds to this domain with iterative development and closely integrated multi-disciplinary teams. ‘Concurrent Engineering’ and ‘Agile’ being two examples. The greater the complexity, the more agility is required by the management team to respond to the results of probing and experimentation.
Snowden states that in chaotic systems no cause and effect relationships can be determined. This seems a little extreme as even chaotic systems such as the weather can be predicted to some extent, although it takes considerable data gathering and enormous computing power to forecast for just a couple of days – so perhaps to all intents and purposes in the P3M environment the statement is true.
The chaotic domain should only be deliberately entered for reasons of innovation and clearly this will require a considerable risk appetite. Chaotic projects would only be knowingly conceived if there was a great deal to gain, by perhaps being first to market in a new fast changing area, or as a response to a crisis such as a nuclear reactor melt down.
The approach here would be to act-sense-respond.
There is another way that a project could become chaotic. The boundaries between the domains can generally be transited, for example with work being moved from complicated to simple or from complicated to complex, once analysis has been performed.
But one boundary is different. The one between simple and chaotic is often represented as a cliff. If the diagnosis at the disorder stage is wrong and work is deemed to be simple when it is not, or the work becomes more complicated and the management team don’t respond, then the project could enter the ‘complacent zone’. The governance of the project turns out to be totally inadequate and it slips off the cliff into chaos.