When we have a principle necessary for our organisation to flourish, we know that we can negate it to become a definite root cause. To try to go in the other direction is not to recommend, due to the risk that it is not a definite root cause, rather a symptom.
The reason why we sometimes divide the negated principle into several smaller root causes and not one big root cause, may need a further explanation. The reason is that from our problem description “Our product development is too slow, too expensive and delivers the wrong products.”, we will get many symptoms when we ask why we have this problem. The same will happen when we ask why again on the symptoms, and we will get more symptoms. Finally, when we ask why, we will get a root cause to the problem description. From the problem description we will accordingly have many chains of symptoms ending in root causes. We therefore need to be able to distinguish between these chains*, since a company may only have difficulties with one of the chains and its corresponding root cause. Here is a picture how it can look like.
As you can see there is also a black rectangle added at the bottom of our Prefilled Problem Picture Analysis Map for organisations, and that all root causes are connected to, with the text “A non-adaptive system will die”. That is from complexity theory, and points out the necessity of a system being adaptive for its survival. In our case it is our own organisation that need to be adaptive to meet the changing market.
The reason for some principles having parenthesis is that sometimes the text inside the parenthesis actually is a symptom, but just to be clear why we need the principle. In for example the principle: “We need timely integration events (to get just-in-time feedback).”, one answer on why we do not get just-in-time feedback, is the root cause “our integration events are not timely”.
Further on, when we add more principles, we will sometimes only add on information to existing principles, i.e. combining them. And the same goes for the root causes that can get very different text, when two root causes are added to one. And since all the root causes and symptoms gather together to one map, we need to be scarce with the words in the symptoms and root causes, to not run out of space.
And as stated before, the Prefilled Problem Picture Analysis Map is very easy to use. Just print it out in A3 format, gather the team, the team of teams, or a high management team and just let them colour the symptoms and the root causes with; red – we have the symptom or root cause, yellow – we have partly the symptom or root cause, green – we do not have the symptom or root cause at all.
Except from the colouring giving the temperature of your organisation, it is also important to look at the different colouring between the management and the employees. When you find too big difference between the colouring of the management team and the employees’ teams it is also an indication of that something is terribly wrong. Which also means that the problem is difficult to fix, since there is no agreement about that problems even exist.
And of course, a Prefilled Problem Picture Analysis Map can be done for other human Complex Adaptive Systems for example; families, communities, schools, cities, countries. The hardest work (the harder the later in the list) is to find a set of principles, but for sure some of the principles for our organisations will be valid. When we found the set, we negate the principles to root causes, make a problem description like “Nothing works”, and from that ask why multiple times, to get the symptoms, until finally ending up with the root causes. That will give us a map, and then it is up to us to stop trying to solve symptoms, i.e. sub-optimising our system, and instead dissolve the symptoms together with the root causes. This is elaborated on further in this blog post.
Now it is soon time to deepen the understanding of the last part of our start organisation definition, “activities with interdependencies.” and find some more principles, but first we need to elaborate on queues, which is next blog post.
C u then.
Next “chapter” according to the reading proposal tree is the series of blog posts about how to dissolve problems instead of trying to solve them.
*The symptom chains are in fact innumberable, meaning they are not the same between two organisations, but it does not matter, since we will end up in the same root causes.