2. Analysis (those that fall in the Complicated domain)
There are subject matter experts we can name (or at least the groups that they come from). We are able to plan workshops or analysis activities from 2-3 hours or up to 3 days (any longer is likely to not be analysis). At the end of this time, experts will have come up with a good solution that can then be estimated.
3. Can of Worms (those that fall into the Complex domain)
These are items we are not sure about or don’t even know who should be involved with yet. Solution options would be heavily debated if we tried to simply workshop them.
It can be tricky to work out what to do about “Cans of Worms” projects and problems. A topic or activity that should take just one workshop suddenly turns into three or four. And we end up with a lot of assumption-based conversations. The main thing we want to do is turn these conversations into fact-based discussions. The easiest way to do this is to understand one key assumption and go and find out more information about it.
In one of these projects, we had the product manager go and ask some key questions about another project which was further along and had solved the item that we identified as complex to see if it could be re-used. It took a 30 minute
conversation to find out that indeed we could more or less reuse their approach. In this way we avoided derailing other analysis workshops planned for the following week.
Once my team needed to design a solution that we discovered would impact another project no matter how it was designed. People would suggest one thing and immediately the topic would turn to the impact on the other project before we could finish working out a feasible approach to the first one. We went around in circles. In this case we decided to use one session to focus on creating a feasible solution with the attendees from the impacted project (noting the impacts, but not raising them in the session), and another just to discuss the impacts.
That’s when I realized we could use the domains in the Cynefin Framework to identify these
different kinds of conversations much earlier,
which would help us plan our work better. In hindsight, I realized I would have used exploratory conversations or technical “spikes” to check our assumptions first and then run workshops to design the solution with a lot more solid information. So now that’s what I do.
When and How To Use Experts Versus Non-Experts
Back to our ideal world – of course we would like to have "experts" work on all facets of our projects. However, this often causes bottlenecks and delays while we wait for a particular subject matter expert to finish one workshop and become available. And there are times when expertise can actually be a disadvantage. In his book Sources of Power: How People Make Decisions, the decision-making research psychologist Gary Klein tells us:
“Expertise can also get us in trouble. It can lead us to view problems in stereotyped ways. The sense of typicality can be so strong that we miss subtle signs of trouble. Or we may know so much that we can explain away those signs, as in the missed diagnosis in example 16.1. In general, these shortcomings seem a small price to pay; however, there may be times when a fresh set of eyes proves helpful.”
18