Today’s blog post will go through the method Systemic Problem Picture Analysis – SPPA. SPPA is a proactive method and is used for problem-solving in human complex adaptive systems (human CASs), where its main focus is on organizations. SPPA is the first part of Dissolve the organizational problems (in human Complex Adaptive Systems (CASs)), which in turn is a part of System Collaboration – “A systematic approach for systemic learning”. System Collaboration is the total approach for a continual systemic learning, with the focus on organizations, even though it is also valid for any human CAS, since the organizational principles are general as well.
Problem-solving in organisations is always urgent, irrespectively if it is an organizational problem or a product problem, where the former always will lead to the latter, and where mistakes in both of them also will lead to problems. This is why organizational problem-solving is so important, due to the organizational problems are directly connected to product and service problems. And to find them as early as possible by being proactive, before they lead to severe consequences, is another strength of SPPA, apart from finding all the root causes. The proactiveness makes it possible to have fast feedback to other teams to become better, and to other initiatives before they even start, by changing the way of working as fast as possible. A Lesson Learned only done at the end of a project is too late and is never looking for the root causes anyway, making the next project or initiative not properly taking of existing problems, since symptoms are impossible to solve. By making frequently retrospectives in agile at scale or not, without looking for the root causes, will not help either. SPPA on the other hand, takes care of both kinds of problems, the ones done by mistake, and the ones due to a malfunctioning way of working. And by doing SPPA with a regular interval, we can also verify that the changes have decreased the number of, and the severity of the problems. This means that we can get rid of numerous measurements, since most of the measurements done in agile development are only measuring on parts of the organization or product, meaning extreme risk for sub-optimization or/and gaming. To get rid of many of the measurements, also means we are minimizing the risks of comparing the teams due to the measurement gives us the possibility. Here are some example of measurements that we not need anymore (and never should have done in the first place 😉 ); how well we adopted to certain pre-set, preferred or suggested solutions in the methods or frameworks, self- assessments (risk for the measurement to become the goal instead of being the means) how our people and leaders behave (only consequences of the way of working), measuring flow efficiency on team, team of teams or higher (follow-up whole initiatives have meaning, comparing teams is always devastating for the “we” feeling in a team of team delivery constellation), throughput, employee engagement, number of deployments, releases, features, user stories (easily gamed by making the work smaller and smaller, on any level; team, team of team, portfolio, etc.), etc. These measurements are all about symptoms or consequences from the way of working. And since we never look for the root causes to any of these symptoms, why should we even measure them at all, since every attempt we will do to try to get better measurements, will clearly be sub-optimizing interventions from shallow analyses.
There are many times the case that the way of working can be made better, when failures occur in the product or service. This is an approach that Toyota follows to 100%, with their Kaizen (continuous improvements) and Jidoka (problem-solving). So, if there is a failure, the people are never to be blamed, the system is wrong or can always become better, even with the slightest update of a process instruction. Here is also the strength with SPPA, since it is very easy and understandable to do, as well as that it is not time-consuming either. This means that we can (and really should) move away from thinking that it maybe is not worth solving, or sometimes, not even look for the root causes*, which often means that the understanding of how to find the root causes, or what a root cause really is, is simply not there. We also need to be vigilant to the promises that big data and the digitalization are proclaiming for us, since we still need to find the root causes and solve them. This is especially valid since the examples made are generally from clear contexts or from isolated parts, which makes them having very low validity for product development (complex context), having much longer feedback loops. We can also add that, without finding the root causes, our changes for trying to get an optimization on the whole, will only result in a sub-optimization, trying to optimize components (parts) of the whole**. Another way to put it is that we cannot measure to get data on the whole, and then optimise the parts, in order to get a better performance (better data) on the whole. And it does not help that we are stating that if the performance (data) is not good, it depended on that we did not optimize the parts good enough. This is very clear from complexity theory, stating that we cannot isolate parts of the whole, and optimize the parts one by one, which means that dividing the organization into product, people and process is wrong per se. Note that sub-optimization is context independent, which means that when not digging down to the root causes also for a clear context like production, we will sub-optimize as well. For a complex context like product development, the resulting sub-optimization is even trickier to realize, due to the long feedback-loops of the wholeness (product and/or way of working). Dividing into parts that together deliver an entangled whole, product/system or way of working, is really a treacherous habit, but more and more common today, so beware out there and use critical thinking before any optimization. This leads us to be vigilant also for the current digitalization that currently is on-going in most organizations, so we do not digitalize a way of working with built-in root causes. Because, even with the newest and most advanced technology and methods for measuring, collecting and analysing data***, we still need to find the built-in root causes in our way of working, since we will not come anywhere with any kind of mitigation of effects. We cannot measure parts in isolation, to be able to improve the whole, since an isolated measurement never will give us any information about finding the root causes. This means that before we start to measure, measure and measure**** and implementing performance management*****, we need to have a well-functioning way of working including our organizational set-up., i.e., a way of working with no built-in root causes. And when we measure, we need to concentrate our measuring on wholes and not parts no matter if it is our product/system or our way of working. If we have problems, we need to go for the root causes, which is why SPPA always will be invaluable, easy and fast to use as it is.
Here is a picture of SSPA in its context of System Collaboration, which this blog book is all about, system collaboration – SPPA.
Let us now start to explain the method of SPPA. First, we collect all individual problems seen in the organisation, where the individual part also can be emailed in advance to reduce the work shop time. The reason for starting the work shop with an individual part is many-fold. We need to collect problems (symptoms and consequences) that each individual perceives under no influence from others, from different positions in the organisation. We also need plenty of problems, enough problems to be able to find all the root causes within the organization, think about the Cobra Effect which could not be understood until the cobra farms (symptom) were found. The found problems are never rewritten by the facilitator or higher managers, they are the reality, the problems seen within the organisation.
The problems can be seen as negative narratives in the organisation, narratives that we want to get rid of, so we truly can increase our systemic learning. The problems the people in our organization see, can also be seen as our qualitative data, our negative narrative. From the problems found, we find the root causes, from which we find the solution that will dissolve our problems. At our next problem picture analysis, we look for the qualitative data again. What problems do we have now, and what improvements can we do to our current solution? Quantitative data we always need to be careful about, since product development has long feedback cycles, i.e., we must trust the need of always follow science, no matter if the science is valid for our organization or our product. So, therefore the number of problems is not actually any good quantitative data, even though a decreasing number of root causes, can be a good indicator that we are on the right track, especially if the root causes are more and more of local character than global.
The role of the facilitator is only to be an administrative help and a catalyst for connecting the problems found and finally finding the root causes, even though the facilitator also should be aware and understand the organizational principles, and that the only root causes that can be found, are non-fulfilled principles. The goal of the work shop is stated above, to find the (normally entangled) problem picture with its connections between the problems found, and down to the organizational root causes, but not the solution to the root causes. By asking “why?” on a problem, we can connect the different problems found, from high-level problems like “we have bad flow in the organisation”, all the way down to the root causes. Since we are not trying to solve the root causes, we are neither going into context, nor the domain of the organisation, since all the problems, root causes (the non-fulfilled organizational principles) and all the problems are universal. This can easily be seen on the problems found as well, since it is not possible to see what organisation the individual problems or the total problem picture originate from, meaning that organisations with the same unsolved root cause, will experience very similar problems. From the root causes found it is therefore also many times easy to see in which context the organisations have its main concerns in the Cynefin™ Framework; the Clear, Complicated or Complex domain.
By doing this kind of analysis, a retrospective assessment on the current way of working to achieve the purpose****** of the organisation, together with the individual part for collecting the different problems seen by the employees and managers, many items from the list to consider can be avoided. In this way we are achieving also the important non-cognitive and non-verbal dimension aspects of the functioning of our human system [1], our organisation.
If we refer to some of the items in the list regarding phenomenology, we will individually experience different problems (for example inattentional blindness). This means that everyone’s perception of the reality of the solutions to the problems within the organisation, will be subjective and therefore problematic. By instead individually gather many different problems for the Big Picture of problems, this subjective phenomenology from each person’s individual perspective, is not an issue since no one’s perspective are suppressed. Gathering many problems are also a necessity, to be able to find the effect-and-cause chains down to the root causes as stated in a former blog post in this series, once again with reference to the Cobra Effect. This means that we need both many problems in order to get quantitative data, but also many different problems seen all over the organization, in order to get qualitative data, where there of course also is of high value if many different persons report the same problem. Both the quantitative and qualitative data make it possible to connect the different problems to each other, since they are effects from an earlier root cause. If we refer to the Cynefin™ Framework (that is an ontological framework [2]), the Confused domain is the place for phenomenology for all kind of problems. This makes sense, since we cannot, as already mentioned, try to ontologically (how things are) map the symptoms or consequences in one of the domains of the Cynefin™ Framework (Clear, Complicated or Complex), due to that they are not solvable from a system (wholeness) perspective. This means also that we should avoid talking about solutions (epistemology) having premature convergence in these cases, since the symptoms and consequences are insolvable, and therefore instead talk about immature convergence, due to the impossibility of trying to solve them directly. This impossibility is what Dr. Russell Ackoff referred to as the need of dissolve a problem, which is the only way of truly acting systemically, by changing the system (or its environment if that is possible) to be able to get rid of the problems within it. These problems can be seen as negative stories as mentioned above, and to get rid of negative stories Snowden states; “One of the best ways of stopping a negative story is to take actions that make the negative story difficult to sustain.” [3]. But we still need to be careful so these actions are on enough depth in the entanglement of our problems, so we with our actions in reality are not only trying to solve symptoms and consequences anyway. Dissolving the organizational problems secures that, since our actions are only operating on the “deepest” level, i.e., dissolving the root causes to the problems (negative stories). This will not only remove the problems, so the way of working is changed, that in turn will generate new interactions, but also remove the negative stories as well, as a positive consequence. Of course, in parallel with dissolving the problems and their root causes, we sometimes need to do something about the current problem in the here and now, which we then can refer to as an incident. Incidents are always reactive and sudden, and can for example be missing I-competence, technology, tools, etc, where the root cause is that the actual planning is not correctly considered in the way of working. In the case that a person is missing I-competence, it is not the person that is wrong, it is just improper, non-existing or non-sufficient planning. Incidents can also be of more severe nature in form of negative consequences, when people are burned-out, being disrespected, etc. Remember that we do not consider incidents that has arose from human mistakes. Human mistakes will always happen, where the solution to the mistake can be a fine tuning of the description of the way of working, in order to avoid the mistake to happen again. Instead, we are focusing on built-in problems, generated from a dysfunctional way of working, which need to be redesigned so we can achieve awesomeness.
That means that we will get into deep trouble, if we accept subjective epistemology from each person’s individual perspective about how to solve these problems, since we can never directly solve symptoms or consequences. And since symptoms or consequences cannot be solved, epistemological pluralism [4] or wisdom of crowds [5] will not help us either, since many views of how to solve the symptoms and consequences in the present, will neither aggregate to solving the root causes that happened in the past. The solution simply cannot be found in the present among all the symptoms and consequences no matter how many we have observed, since the root causes has already happened. The root cause can therefore only be found in the “past” by using deduction and asking why on the symptoms and consequences and at the same time get the problem picture and its connections, making SPPA the epistemology (the method) to always choose first.
When we have found all the root causes, we can dissolve all our problems, by making a new systems design for our new way of working (incl. people structures) with SOSD – Systemic Organizational Systems Design, see this blog post for the theory. The steps for SOSD, will always will ontologically be in the Complicated domain, since we only are reducing transdisciplinary complicatedness. This means that, no matter solution for a new way of working with SOSD, it will be integrative, which means that there is no perfect specification to make first, rather like a prototype in order to achieve the new cohesiveness. Our system will therefore be tremendously much more efficient, effective and flourishing than before since we now are following the science. But still, the first solution from SOSD, most probably will need some small tweaking. If tweaking is necessary, will be fully transparent at the next SPPA, which is preferably done a couple of times per year, or at certain appropriate scheduled occasions. This is not a big effort as described above, since the bigger effort (and still only a few days) can be done with rather few people, and the individual part for different levels in the organisation is very little, a short reflection of the problems seen, that everyone should do continually anyway. This is also how Toyota continually improves their production and product development, by encouraging their people to propose improvements and report problems seen, and where all “proposals”, every one of them, are taken care of.
As we can see, SPPA is not focusing on a single problem (observation, symptom, consequence, negative story, negative narrative, incident) within the organisation. Instead, many problems are gathered from all over the organisation, which means some kind of inductive******* thinking, that is most often missing in the different traditional analysis to find the root cause(s) present today; 5 why, Ichikawa diagrams, etc. By not focusing on a single problem that is an individual mistake, the blame-game about whose fault it was will not occur, since SPPA is done proactively before the incident has happened (and if the incident already happened, the concentration is on making the system better, or to avoid new easy mistakes if that was the case, and not on the people making the mistakes). This fully removes the risk of not digging deep enough for finding the root cause(s). To not focus only on a specific organizational problem, and instead trying to gather “all” problems in an organisation, goes hand in hand with two of Ackoff’s statements “Problems are not disciplinary in nature but are holistic” [8] and “The best thing that can be done to a problem is not to solve it but to dissolve it” [8]; meaning that a problem within an organisation simply cannot be isolated and directly solved, i.e., which goes for all the root causes that are global within the system. When we have the picture of problems, we start asking why, which leads us to a deductive approach, where we are connecting the different problems (symptoms and consequences) and find their root causes. To later find the solution of the root causes is an abductive approach, aiming for dissolving the organizational problems and find a new cohesiveness, as Alicia Juarrero [9] would have stated it (note that we cannot use the abductive approach to the actual problems, since they are only symptoms, which are impossible to solve). Dissolving the organizational problems, with SPPA and SOSD, is therefore a technique that combines all three different types of reasoning; inductive (partly*******), deductive and abductive (but, where the System Collaboration Deductions for product development, fully removes the need of abduction when creating the way of working). We always need to match the inferential strategy to the different problems we encounter, which Dissolving the organizational problems clearly shows, by combining all of the three different reasonings in a systematic approach, on our way to a continual systemic learning.
If we are successful with finding the root causes to all our organizational problems, we can also see that we have avoided all the items in the list we cautiously need to consider when intervening with a live system, that was presented in the introductory blog post in this series. This makes life a lot easier, but most of all, correct.
The next blog post in this series is a deep dive into the method Systemic Organizational Systems Design, how we after finding the root causes with SPPA, can start redesigning our way of working in our organization.
C u soon.
*Why it may be better NOT to address root cause of a problem – Kepner Tregoe (kepner-tregoe.com)
**Achieving business impact with data | McKinsey
***Root-cause problem solving in the Ops 4.0 era | McKinsey & Company
****Advanced analytics: Nine insights from the C-suite | McKinsey
*****Getting visual performance management right (mckinsey.com)
******With organizational purpose means; manufacture a product, service, develop a new product, etc., with a certain price and quality. We are not talking about the nowadays popular Purpose statement, that is only a continuation of the easy-gamed value and mission statements. In this kind of statements, behaviour, properties and core values of our employees are stated, which is more of wishful thinking, since they will only emerge from multiple interactions within the organization. Since the interactions in turn, also emerge from our way of working, one can believe that if the purpose of the organization is not fulfilled, neither will the emergent behaviour and properties of our organization be what one could wish for.
*******Inductive logic means to achieve a general result from noted regularities (specific cases), but do not explain why, and since symptoms and consequences (the regularities) are not possible to solve, we only use the observation part (phenomenology) of induction. This first observation part is also the first part of a situational assessment as well as Double Loop Learning by Chris Argyris [6] and Donald Schön [7].
References:
[1] Snowden, Dave. Blog post. Link copied 2021-07-17.
ligne de fuite: 2 of 3 – Cognitive Edge (cognitive-edge.com)
[2] Snowden, Dave. Blog post. Link copied 2021-08-15.
Cynefin™ & perception – Cognitive Edge (cognitive-edge.com)
“Above all, Cynefin™ is about context, about realising the nature of how things are and working with that.”
[3] Snowden, Dave. Blog post. Link copied 2021-08-03.
The ‘N’ Word – Cognitive Edge (cognitive-edge.com)
[4] Turkle and Papert. Epistemological Pluralism and the Revaluation of the Concrete. Journal of Mathematical Behavior (1992) vol. 11 (1)
[5] Snowden, Dave. Blog post. Link copied 2021-08-18.
Wisdom (?) of Crowds – Cognitive Edge (cognitive-edge.com)
[6] Argyris, Chris. Wikipedia.
Chris Argyris – Wikipedia
[7] Schön, Donald. Wikipedia.
Donald Schön – Wikipedia
[8] Ackoff, Russell Lincoln. Article. Link copied 2018-12-15.
https://thesystemsthinker.com/a-lifetime-of-systems-thinking/
[9] Juarrero, Alicia. Presentation from the Lean WX conference, April 2015.
Constraints that Enable Innovation – Alicia Juarrero on Vimeo