Our completed Prefilled Root Cause Analysis Map

In today’s blog post our completed Prefilled Root Cause Analysis Map will be presented. For a complete list of our total organisation definition and our principles, please see this blog post.

And as stated before, the Prefilled Root Cause Analysis Map is prefilled with the most important chains of symptoms for being able to dissolve the symptoms, by solving the corresponding root causes(s), see this series of blog posts that is dissecting Dr. Russell Ackoff’s anti-systemic panaceas. Dissolution of problems makes it extremely powerful since it easily reveals way of working problems within an organisation and also which tools and methods that only are anti-systemic, and therefore no panaceas. But, remember that our map can never be fully completed, since the symptoms of symptoms are endless, and can never be exactly the same in any organisation. The concentration in the map is therefore on the most common organisational symptoms, and the closer we are to the root causes, the more valid they will be for most organisations. But, remember that by simply asking why on our organizational problem, we will soon be connected to the root causes, and they are valid and need to be solved for all organisations. Here is Our Prefilled Root Cause Analysis Map – for organisations 0_99:


Also remember that the root causes are our negated principles that all organisations need to follow, but that we of course can continue to ask why on the root causes above, to get the reason why we cannot implement a fulfillment of the principles. In a silo organisation the normal answer will be KPIs on the silos, head count issues, extensive processification, extreme control required, etc., which of course also need to be solved in order for our principles to be fulfilled.
BUT, only looking at these latter reasons, will never give us our principles. This has been a big problem for decades since the new methods and ways of working promise a mix of solving the symptoms within the organisation or/and these latter reasons, seldom solving any of our principles. And as we already have seen for more than fifty years, the creativity of coming up with a new way of working has so far been massive, and will be endless, if we are not looking at our set of principles instead.
Agile development is a good example of this, where some root causes that the silo organisations have on the people side, now have been solved, but where other principles on the activity side of our set of principles instead have been violated.

And as said before, the Prefilled Root Cause Analysis Map is easy to use, preferrably use the colours green, yellow and red and fill it in to get the temperature of your organisation. Start and map your problems and colour corresponding symptoms. If a symptom is red, the root cause(s) it is derived from will also be red colour, since they are the only once that can solve the symptom. See this blog post for a thorough explanation about why having the Prefilled Root Cause Analysis Map. When we have completed the colouring, it is easy to see what root causes we need to take care of.

Here is Our Prefilled Root Cause Analysis Map – for organisations with silo pain points 0_99, how it will look for a normal silo organisation with waterfall projects, with its pain points marked.


Here we can see in the pain point most to the left, regards the unwillingness or non-understanding of the need to solve the organisational problems. In the middle we have the pain points showing that the interactions are hindered within the organisation, restricting the silo organisation with projects to do waterfall work only, and not what the market requires today. This is the main obstacle for a silo organisation, the bigger the more problematic. The Three pain points to the right have to do with too big work packages and the inability to put people together to work with complexity and speed, which are also big obstacles. All the root causes to the pain points need to be solved in order to survive in today’s market.

And here is a different kind of view, showing the domains in the Cynefin™ Framework[1]. The graph is combining “Interaction Arity” (people that interact part (to the left) in the Prefilled Root Cause Analysis Map) and “Disciplinarity” [2] (activities with interdependencies part (to the right) in the Prefilled Root Cause Analysis Map) which are both needed for problem-solving in the different domains in the Cynefinframework in order to be competitive in today’s market. Here is the graph:


Here below we are adding the pain points for traditional silo organisations in a new graph.


As we can see the pain points are in different domains in the Cynefinframework; the lower left showing the problems with lack of parallel work to achieve speed and flexibility in the ordered domains and the higher right the problems when working with complex problems*.

A traditional silo with projects are stuck with only doing handovers to the silos/sub projects/disciplines (Overlapping Concurrent Disciplines) next in the waterfall, unable to solve any problem fast, flexible and complex. That was working pretty good in the era of Technology Push, when pre-development activities are done continuously and in advance, before added to a project.

Next step is that we let the interactions flow between (mostly) the closest disciplines, then we can be faster and more flexible, due to interdependencies are solved faster.

But, to be able to solve complex problems like future-proof platforms and understand the customer needs in software development, we need not only to have everybody in the same boat, transdisciplinary, the interactions must be able to flow freely within the boat, where everybody give and take and in that way are learning from each other.

For a company to survive in the Consumer Pull era, it needs to be fast, flexible and able to solve complexity, all three are important, as well as any of their combinations, because it depends on the context, as always. And regarding flexibility, we not only talking about flexibility to the market, but also flexibility to change contexts fast within the organisation, when moving from different Cynefin domains when problems are encountered.

Note about variability
There is a big misconception that variability can be blamed for almost anything. We will always have variability; our people are different, mistakes are made, people get sick, there are misunderstanding, machines break down, the planning was not executed as planned, instructions are wrong or not clear enough, etc., which is the normal state. See this blog post that deeply elaborate on the problem with blaming the variability of arrival times to queues, instead of asking why we have the queues.

Instead the biggest problem we have in the organisations of today, is that they are not following our set of principles, which will give symptoms of symptoms that we cannot understand or foresee. But, many times this is unfortunately considered as variability, which sadly leaves the root causes unsolved, and instead leave us in a self-imposed mess.

Remind that the negated aim of the organisation is context independent; “Our organisation is too slow, too expensive, delivers the wrong, costly, low-quality products and makes our people unhealthy”. Since also the principles are context independent, it means that all inummerable possible symptom chains in between, are context independent as well. No organisations will have the same root cause analysis map of their problems, all of them are unique and context independent, but they will for sure have the same root causes.

This was all in today’s blog. C u soon.

Next “chapter” according to the reading proposal tree is the blog post about the wrap-up of the whole System Collaboration Blog Book, but the branch about human science where the series of blog posts about human science is the first, as well as the branch about our set of principles, where the series of blog posts about the history of our organisations is the first, should both have been read first

 

*but it is a big difference between Technology Push and Consumer Pull, which are elaborated on in this blog post.

References:
[1] Snowden, Dave. The Cynefinframework. Link copied 2018-08-23.
https://www.youtube.com/watch?v=N7oz366X0-8

[2] Pellaud, Prof. Francine. Film explaining multi-, inter-, trans-disciplinarity in the view of science. Link copied 2018-12-16.
https://www.youtube.com/watch?v=r5Pd4xXxHz4

Leave a Reply