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 (now the Cynefin Company) 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 ‘AC’ which simply represents the fact that you don’t know which of the other four applies to your situation. AC stands for ‘aporia/confusion’.
The Cynefin framework has relevance to projects, programmes and portfolios because the project delivery 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 deciding what degree of agility is appropriate.
Confused
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 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.
Clear
In the clear domain there are cause and effect relationships that are predictable and repeatable. They are self-evident to any reasonable person. In the project delivery 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’.
The clear domain aligns with the low end of the continuum of uncertainty. Higher levels of agility are used in the early phases of the life cycle while specifications are being agreed, but the delivery phase will be clear enough to rely on change control approaches.
Complicated
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 or programme 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.
In the complicated domain, it takes longer to establish specifications. But initial uncertainty can be resolved. Once again, the early phases the life cycle will use higher levels of agility to resolve uncertainty but less agility is needed during the delivery phase.
Complex
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 project delivery 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.
In this domain, it isn’t possible to resolve uncertainty in the early phases of the project or programme. Much of the work to resolve uncertainty will shift from the identification and definition phases, to the delivery and development phases. High levels of agility will be used throughout the initiative. This is what is often referred to as an agile project or programme.
Chaotic
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 project delivery 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.
Success will depend upon fully understanding the cost of change and a highly flexible attitude to budgets and timescales.
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 clear or from complicated to complex, once analysis has been performed.
But one boundary is different. The one between clear and chaotic is often represented as a cliff. If the diagnosis at the confused 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 or programme could enter the ‘complacent zone’. The governance of the project turns out to be totally inadequate and it slips off the cliff into chaos.
