“unordered” on the left. Take a look at the image below. It shows three different categories of problems. The categories are based on the Obvious, Complicated, and Complex domains from the Cynefin Framework:
If you have a problem that falls in the Simple or “Obvious” domain, the actions you take can safely be based on best practice because you have a high level of certainty about them – you know what you’re working with.
If your problem falls in the Complicated domain, you should base your actions on expertise and analysis as you still have a high level of certainty and there may be several good solutions available. And lastly,
if your problem falls in the Complex domain, you should base your actions on exploration and experimentation. Then you need to identify your assumptions about what’s going on and use specific techniques to look for stable patterns to help you understand what’s really going on.
What you want to avoid with any project or problem situation is applying thinking and actions you’ve used for simple/obvious problems in the past to complex problems based solely on
your comfort with a previous process or experience. When you do this, you create more problems, waste time, and almost always get undesirable outcomes.
Using Cynefin for Project Management and Better Decision-Making
We run workshops where we pull together diverse subject matter experts from various functions to provide context and do analysis work collaboratively. Our earliest workshops (Idea Collaboration Sessions) are designed to help us learn more about the customer needs we are trying to design for, the groups and systems we think will be impacted by the project, and the overall costs and time-frames associated with the project. We do this so we can make well-informed decisions about which projects to invest in.
We use these workshops to gather the context-relevant information we need to make decisions. They allow us to gain an understanding of the scope of the project and whether it is feasible to deliver it for a desired budget and time-frame.
Once an idea proves feasible, we make a list of high-level functions, features, and capabilities that are required to deliver the project. We make this list by walking through customer experience stories or journeys – the kinds of things you’d recognize from a course on Design Thinking.
As we walk through customer journeys, we note any extra capabilities we think will be required to support that customer experience. The principle we use here is to “go very broad and very shallow on scope.” (We may just get out an excel spreadsheet and make a list of required capabilities in column A, see image below).
Next, we narrow the scope to the set of capabilities that we are certain we need to have ready for day 1 (project launch date). This set we colour green in the template, anything that we debate about color yellow, and anything we are sure can wait until a project phase 2, we color white. For the rest of the project we focus only on green items. This saves us time and money by only doing detailed work on the scope we are certain that we need. As we go, we “argue other scope in” because it is more effective to argue scope in after and only after we know what we really need.
16