I’ve used a framework (5Cs) that I’ve come up with to solve some complex problems – both in professional life and personal life… I’ve solved and am in the process of resolution for a few of them using this concept. Although you could live without complex issues, at one level these are exciting and keep life interesting.
When I had first inherently started using the model of 5Cs approach to a solve a problem, I did not have a knowledge on Cynefin framework. However, understanding the Cynefin framework, gave me further clarity as to when to use the 5Cs method and when to use other methods like reductionism etc.
My first approach to a problem is to step back and think and place it in the Cynefin Framework. Although I had inherently used the 5Cs framework, the knowledge of this tool has given me more clarity. Cynefin framework essentially divides the problems into 4 quadrants – Simple, complicated, complex and chaotic – essentially a problem can be based on how much line of sight you can draw between cause and effect. The further the cause and effect are, the problem tends to be in complex or chaotic domain. Cynefin framework also talks about complicated problem could be solved by reductionism, where as different approaches are required for problems in the complex quadrant.
Looking at complex problems, where we cannot clearly draw a connection between cause and effect, I use the 5C framework mentally to discover, construct and craft solutions.
The first C is Compartmentalize the problem. A complex problem could have lot of extraneous information, corner cases that can appear central to the problem thus only serving to introduce a high noise ratio. Hence, it is key for us to compartmentalize the problem into several cores (fewer the better) and excluding those noises. This is not linear reductionism approach – the problem itself not broken down, where the sum of the parts is equal to the whole; the cores have similar complexity to that of whole, but perhaps at a lower scale. The core at the center has higher clarity and at the edges it could be blurry. Imagine core to be something similar to fractal - a piece of similar shape although a bit smaller in scale.
Once the problem is compartmentalized into multiple cores, the next C is to Constrain the core. Name those variables that have an impact to this specific core; including dependencies amongst these variables. Analyze in-depth to out the variables; but use the 80-20 rule to name the variables that only has bigger impact on the result; for now ignore the weaker influencers. There would be variables that play across the cores; have cognition of that fact, but for now keep them in the back-burner; you will bring them to the fore-front later on.
The third C is the Contain. The fact that it is a complex problem implies that there will be dependencies across the cores. But it is also important to use the same approach and contain the problem within the core. Minimize the interfaces across the core; eliminate dependencies across the cores as much as possible and as much as a solution allows for the specific core. As we are looking to contain the core and ignore few of the variables, it is possible that the solution that we would have come up with would be incomplete to a certain extent. Let us live with it for now.
Now the core is small enough for it to be solved, although the complexity of the core (much like fractal doesn't lose its shape) is not diminished – the scale could be lower. This is where we use whatever standard methodology for any solution - analytics, empirical, statistical etc. By resolving multiple cores, we perhaps have reached much more clarity on a larger part of the problem that we started with. There would still be areas of holes – that’s where the next C comes in.
Once the cores are resolved, we are going to have few loose threads, the ones we left in the backburner – some part of solution that seems not in place or fitting in right since it has the dependency on another core or an adjacent one. Now its time to Connect; and introduce the variables (from the back-burner) and across the cores – this is where one looks as each core as a puzzle piece and then start fitting the edges together. Now is the time to connect them – its like building a complex Lego pieces with dovetail joints… We now work on the connections to make the cores cohesive enough with each other – start introducing the variables that now run across the cores – go back tune the cores to manage the impact of the new variables. Re-work the core; as we do that, typically I found the blurry edges are places where I needed to work on; the center of the core remains untouched in most cases. In exceptions, it would take a couple of iterations.
Once you have the connections done, we now Complete the solution. The Complete phase is also the phase, I use, what I call, the “Bounce-High and Bounce-Low” method. We have to keep moving between big picture and details – bounce-high for a big picture view to see if the resolution of cores put together does solve the problem and bounce-low to see if the connectors are indeed fitting well enough to make the solution right. This is key, since the solution could be neither solved at a big picture level nor at details level – its like keep a 10 ft x 10 ft puzzle pieces… One cannot solve a large puzzle piece by either staying at 1000 feet level; nor can one put together the puzzle pieces, by just look connector end of the pieces.
The Final “C” – the sixth C – is the Context. But that is an assumption that I have all the time – it is a necessary condition for a problem resolution (so, it should really be the zero’th C). The context in which the problem exists needs to be understood. Without that understanding, my belief is that the people do not acquire the resiliency required to live in the same space in which the complex problem exists. Building that context is very important and essential – it also gives us the ability to look at things in the shades of grey and not just black and white.