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).
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!