Cynefin - 0Introduction

Despite our best endeavors in codifying many aspects of project management, a lot of what we do in project management is still ‘situational’ and ‘variable’. That is, in project management we need to react to various situations and these situations are a result of any number of variables, the impact of which cannot be fully predictable, understood or comprehended in advance (and occasionally not even while or after they occur).

In this post I want to elaborate on the applicability of a common framework that project managers can use in order to map various situations in their project landscapes. The framework I would use for this discussion is called Cynefin (pronounced cenevin).

Discussion

Cynefin, the details of which will be elaborated on below, provides a conceptual framework for making sense of the different landscapes faced within and by projects. In ‘faced within and by projects’ I mean to say that this framework can be used by the project manager to understand the various landscapes faced by the project (for example the stakeholders’ landscape, vs the development team landscape – and don’t worry if you can’t understand it now, all will be clear by the time you complete reading this post) or the landscape of the entire project, compared with other projects (for example, a web development project vs an R&D project).

The Cynefin framework recognizes that the situations and challenges we face can belong to one of four domains:

The ‘Simple’ (‘known’) domain

The ‘Simple’ domain is characterized by the following attributes:

  • There are known Cause and Effect relationships and these relationships are repeatable, perceivable, predictable and can be determined in advance
  • Challenges can be addressed using Best Practice approaches
  • Activities can be usually codified and documented into Standard Operating Procedures and Work Instructions
  • Best suited for Command and Control style of management

In the context of project management, projects that operate in this space would be ones where the domain of execution is known, regular, predictable and with very low risk. For example, a software house specializing in the delivery of basic small business web-sites, where these web-sites are subject to a regular delivery routine and are subject to similar terms and conditions.

The way to deal with ‘simple’ problems (i.e. the way to make decisions) is by applying the sequence of sense-categorize-respond. That is, you start by assessing (or analyzing) the facts of the situation, followed by categorizing them (i.e. determining what best practice is relevant to deal with the situation) and then implement and execute this practice.

The ‘Complicated’ (‘knowable’) domain

The ‘Complicated’ (‘knowable’) domain is characterized by the following attributes:

  • The links between Cause and Effect are less apparent and not self-evident; but are able to be uncovered
  • No clear ‘Best Practices’ but there are known ‘Good Practices’

In the context of project management, projects that operate in this space would be ones where the domain of execution can be determined by utilizing existing expertise and the project’s risk can be assessed and managed. Less than trivial software development projects (i.e. projects where the level of uncertainty is not insurmountable) would fall into this space.

The way to make decisions in the ‘complicated’ domain is by applying the sequence of sense-analyse-respond. That is, you determine what possible practices would be appropriate for dealing with the situation and then, having selected one (based, perhaps, on the availability of experts in that particular domain) you then implement and execute this practice.

The ‘Complex’ (‘Unknowable’) domain

The ‘Complex’ (‘unknowable’) domain is characterized by the following attributes:

  • The links between Cause and Effect are only clear in retrospect
  • No obvious ‘best practices’ or even ‘good practices’ but a possible practice can emerge as a result of controlled experimentation where quick learning can be achieved.

In the context of project management, projects that operate in this space would be ones with high level of uncertainty but where low-cost-of-failure experiments can be used to narrow down the uncertainty and suggest an acceptable path forward. The type of projects that fall into this space will be innovation or R&D projects.

The way to make decisions in the ‘complex’ domain is by applying the sequence of probe-sense-respond. That is, you start by probing (i.e. trialing out various options using experimentation), then identifying the methods that succeeded and can be used as future patterns of operations for the future.

The ‘Chaotic’ (‘Unknowable’) domain

The ‘Chaotic’ (‘unknowable’) domain is characterized by the following attributes:

  • The are no Cause and Effect relationships
  • No point in looking for the right answers (as no right answer exists)

In the context of project management, project that operate in this space would be ones with high levels of uncertainty through and through. This could include projects with lack of agreement on the project’s scope, business value, mode of execution in a technologically shifting environment.

The way to make decisions in the ‘chaotic’ domain is by applying the sequence of act-sense-respond. The first thing that needs to be done is to take some action (which may or may not work) in an attempt to stabilize the environment and reduce the chaotic nature of the project. One example for a possible action would be to simply stop the project but other options are certainly possible.

Some final notes

There is much more to the Cynefin framework than described above and you are encouraged to explore it further here.

Determining your position in the project’s organizational landscape is important not only because it can prompt you to take the appropriate corrective-actions but also because it could prevent you from applying the wrong solutions.

In the context of recent #NoEstimates discussions it seems to me that the application (or rather the suitability) of the #NoEstmates argument is really only applicable to the ‘Unknowable’ domains. There is no valid reason to suggest that within the ‘Known’ and ‘Knowable’ domains estimates could not be provided (as a matter of fact in the ‘Simple’ domain and with some expert advice in the ‘Complicated’ domain).

Think about it!

Print Friendly

6 Comments

  1. Projects that operate in the presence of chaotic – unknowable – domains will fail. The very definition of a project is we have some notion of what done looks like in units of measure meaningful to the decision makers.

    If there is this chaotic – unknowable – domain, the work should not be called a project. It might be somethings else. Diplomacy, politics, or something similar. There were Unknown Unknowns are actually very rare. They may not be “knowable.” That’s different. You need to protect against those with fault tolerance or robustness.

    But I’d like to hear about a “project” that was undertaken where the future was “unknowable” and the project proceeded to conclusion with success.

    Reply

    • Glen, the ‘unknowable’ ‘area’ within the framework stretches across both the Complex and Chaotic domains. Chaotic projects do not start off as chaotic (as your correctly point out) but are a result of a drift from being Simple, Complicated or Complex into a situation of Chaotic as a result of changes to the project’s environment. I don’t thin it is difficult to identify examples of projects that would fall into that domain.

      Now, I could be wrong, but wouldn’t R&D projects fall into the ‘unknowable’ domain (as defined by the framework) where a fair amount of up front exploration needs to be taken before a clear path forward is identified?

      Reply

  2. One caution that I have is that work – project or otherwise – usually doesn’t fit neatly within one of the four domains. There are aspects of any situation that may be chaotic, complex, complicated or even simple.

    Further to the initial comment on this post, while many efforts may be unknowable (complex or chaotic), Snowden suggests that we need to perform probes or experiments in complex situations. These probes can (and should) be managed like projects. Think of it as carving off a chunk of complexity to make it manageable.

    Having led work that is complex in nature, I’ve done this very thing many times – run a small project designed to create a change, manage it well, monitor it closely and if it works, amp it up. If it doesn’t work, figure out why and change it or end it.

    This is also true in chaotic situations. For example, recovering from a disaster includes work that is simple (put out the fire), complicated (rebuild), and complex (address building codes to improve fire resistance).

    Cynefin is a sense-making framework, not a categorization framework – which is really important to keep in mind as you confront problems and design approaches to managing them.

    Reply

    • Hi Angie, thanks for your great comment.

      Just to explain my position on this matter. I am aware of the fact that my short post does not do full justice to the Cynefin framework and just uses some literary freedom in simplifying some of its more esoteric aspects. I’ve done this deliberately as otherwise I would have had to elaborate much more than I was intending to. As far as the point about sense-making vs. categorization, I’ve actually allowed myself to take my position based on Snowden’s own observations (see in http://cognitive-edge.com/blog/entry/3453/part-five-origins-of-cynefin) where he makes the following observation:

      “The Cynefin framework is frequently (and legitimately) used as a categorisation model around the four domains of simple, complicated, complex and chaotic. Working at this level it allows people to understand the difference between the four domains, the decision models associated with them and the necessarily limits of best practice. Shawn Callaghan of Anecdote produced a four minute explanation of Cynefin considered as a categorisation model which gives a good basic introduction and has proved popular. For a lot of users that level of use is more than good enough to produce results. Adding in disorder and the catastrophic boundary adds meaning when a more sophisticated approach is needed but it’s not always necessary.”

      I love your example re recovering from a disaster as it beautifully illustrates the point you bring up regarding the process of recovering from a chaotic situation while ‘falling’ into different domains.

      Thanks again for your contribution.

      Cheers, Shim.

      Reply

  3. Great to see the application of the Cynefin framework getting attention here. Having an engineering degree myself I definitely have a soft spot for technical professionals with PM a specialization.

    I’ve been working with the Cynefin framework for more than 8 years and am one of the instructors at Cognitive Edge that teach our Cynefin and Sense-making course often with Dave Snowden the principal author of the framework.

    A few comments:

    - don’t forget the 5th domain of Disorder. This is the domain of not knowing which of the other four domains your situation or particular project aspect is in. It’s also the domain that lead to inaction. I.e. no agreement on a course of action as the disagreements between forms of action continue

    - the point on situations having aspects spanning multiple domains is very true. I sometimes use the layering metaphor to explain this in training. The other point to remember, which is sometimes overlooked, is dynamics. Considerable value comes from the framework is in understanding dynamics. Its often about how do we shift this situation to the complex domain or shift it back to the complicated domain. If you think about technology commercialization you can see the dynamic between exploration and exploitation which is the dynamic between Complex and Complicated.

    - the point saying that the framework is primarily a sense-making framework is very true. However keep in mind that you can create models with organizational or project specific data that can be used for categorization. Just be aware of the need for periodic calibration. When we create organizational or department models you often see patterns reflecting a specific culture and a “way of doing things”. This awareness in and of itself is often very valuable in effecting change that lead to performance improvements.

    So situational awareness, monitoring, dynamics, and action are central to the application of the Cynefin framework. We cover much of this in depth in our modular Cynefin and Sense-making training program with the Cynefin framework in particular covered in depth in the session offered in the 2nd day of the full program. If anyone is interested in our modular Cynefin training program they can find a full listing here.

    Reply

    • Hi Michael, thanks for thoughtful comment.

      I’ve addressed the point re categorization in an earlier reply to Angie and add that I accept and understand this distinction.

      I made a conscious decision not to include the 5th domain of Disorder as I thought that project managers will have a problem with Chaos, let alone complete lack of orientation. Having read your comment I would probably need to consider this position and introduce it in a future post as I can see the applicability of it to project life (in the context of inaction and disagreement). Mind you, I have some conceptual difficulty distinguishing between Chaotic and Disorder situations which might explain my reluctance to address them individually.

      Thanks again, Shim.

      Reply

  4. Pingback: New PM Articles for the Week of March 3 – 9 | The Practicing IT Project ManagerThe Practicing IT Project Manager

  5. Pingback: Cynefin Related #NoEstimates Thoughts | quantmleap

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

%d bloggers like this: