Welcome to this blog post that will dig deep into the world of MECE, which is an acronym for Mutually Exclusive, Collectively Exhaustive. We will go through who is using it, how and under what circumstances it is used, why it is used, what it is in more detail, when it can be used and most important of all, when it cannot be used.
We start with some initial information, important for the later understanding of the blog post. We can divide problems into two categories, built-in and normal problems (MECE ;-), here is a blog post series, which really deep dives into this matter. This is very important since normal problems we can in many cases directly categorise into the three domains of the Cynefin™ Framework by Dave Snowden [1] [2]; Clear, Complicated and Complex. Examples of this is a normal problem to make a software architecture or assemble a car at a manufacturing line, some kind of initiative where we are starting from scratch with our way of working. We also have normal problems depending on mistakes or Murphy’s law, that we need to find the root causes to, before we can understand that the symptoms are built-in or normal. Built-in problems on the other hand are very different, since they are symptoms, originating from not fulfilling the Organizational Principles, which directly induces deficiencies in our way of working. And built-in organizational symptoms can never ever be solved directly. They can only be dissolved [3], as Dr. Russell Ackoff so aptly ascertained already three decades ago.
MECE is commonly used by management consultants, who often use it in a problem-solving process, where MECE is a sine qua non. The problem-solving process many times includes the Minto pyramid principle and the SCQA, Situation – Complication – Question – Answer. As a fundament, there also need to be a framework like the Profitability or the Porter’s 5 force framework depending on the customer problem to solve. This problem-solving process is especially used by the big strategy consultant companies McKinsey, BCG and Bain, and was invented by Barbara Minto in the late 1960s when she was working at McKinsey. The main thinking is that this gives a structured and systematic way, a process for tackling a customer problem and later presenting the information by storytelling, both written and verbal. The goal for the customer presentation is to structure the information in a narrative way, so it becomes more attractive, clear and not least, persuasive.
Without going into too much details on the total problem-solving process mentioned above, some important parts still need to be discussed. The SC part of the SCQA results in the problem definition. The QA part is where the developing of hypotheses are started by asking questions, that follows the chosen framework. The questions are then proved or disproved by answers, resulting from deep research. The pyramid principle is characterized by bottom-up synthesis & sense-making, and a top-down communication. The presentation on the top level is normally according to SCQA. All the levels below the top level, where the problem/issue or the hypotheses that needs to be solved are found, should always be structured according to MECE. Worth to mention is also that there will be several iterations within all the phases of the process, from redefining the problem to restructure the answers and the solutions depending on the chosen framework, before the investigation and presentation are finalized.
Within the MECE method, ME, Mutually Exclusive, is the part where the whole is broken down into distinct subsets, that do not overlap, meaning that the items can only fit into one subset a time. When MECE is used for problem solving it means that the problem, as well as its solution space is divided into smaller and smaller parts. CE, Collectively Exhaustive is the part where any item, out of all items, is fit into one of the subsets, i.e., all the solution space is covered. This means that MECE is a method for separating a whole, or a set of items, into subsets, with no overlaps and no gaps. By doing that, logical, clean buckets of analysis, will be achieved, which is a very important part of the total problem-solving process, since every bucket means a work stream, that can be handed out to one and only one consultant.
MECE is based on reductionistic [4] and atomistic [5] thinking, where the common Divide and Conquer algorithm is an apt example that uses this thinking. Reductionism is a natural scientific approach and is thousands of years old and goes back to at least the earliest forms of atomism [6]. Reductionism refers to any approach to explanation that attempts to reduce complexities of structure (or behaviour) to two or more less complex units, and where the atomism perspective is, from these smaller units, to also want to explain and solve them, to get an aggregate solution to the original problem. Atomism (and reductionism) easily leads to what is called framing, which means that the solution will be in the same frame as the sub-problem itself. Framing is therefore treacherous and can be deeply problematic in especially two cases. Within a complex and complicated context, it means that the solution to the whole, is framed into parts, without any design how the parts will fit and interact together to become a unified and well-functioning whole. That is only to try to optimize dependent parts, which means sub-optimization. Regarding problem-solving, a built-in problem, i.e., a symptom, can never be solved no matter context, which is a fundamental fact. If we try to divide the symptom into parts, will not change that fact, which once again then means sub-optimization. So, in both these cases framing will lead to a sub-optimisation, an attempt to optimize dependent parts one by one. The solution for the whole is therefore antisystemic [2], as Ackoff would have put it, no matter which dimension that is sliced to achieve the frames.
The method for Divide and Conquer algorithms on the other hand, is always mathematically stringent due to that are always solving a non-caused problem, i.e., not a symptom of something else. These algorithms can be seen as having three steps; divide the problem (normally set) into sub-problems (normally subsets) in a number of steps, solve (conquer) the sub-problems and finally combine in some way the solutions to the sub-problems, to determine the solution for the original problem.
All solutions to symptoms (caused problems) are suboptimizing the whole, but some symptoms are incidents, which means that we need to take care of them. For example, when people get burned-out syndromes, we of course need to take care of them, but that will of course not remove the root cause. The same goes for if there is a car accident because of a hole in the road: We need to take care about the incident; injured people, car wreck, clean the road, etc., but it will of course not remove the root cause, i.e., the hole in the road. There is no difference if we look at the symptom, or incident, as the effect of a cause, since the solution of an effect will never remove the cause either.
The systemic solution space can only be considered before the root causes occurred in the past, which means that we need to ask multiple why to get to the root causes. The root causes together with the organizational principles will give us our systemic solution space for our organization. This means that it does not matter if we increase the solution space in the present to cover all the symptoms that the organization suffers from. That symptoms are not possible to solve is two-fold; a solution to a symptom only has a suboptimizing solution space according to above, as well as new instances of the symptoms will come, since the root causes are still not removed. This also includes that all the symptoms’ respective solution does neither aggregate to a systemic solution. At the present time, we can only sense the problems, the unintended consequences, from events occurred in the past, but without the root causes, we can never understand the systemic solution space. By finding the root causes in the past, we also understand the systemic solution space, which we then apply in the current now. This is the only way forward, even if we increase the solution space to be the whole universe, we can never solve symptoms. It is the time aspect that is vital here, because events that has already happened due to a cause (that already has happened too), can never be undone (not the cause either). Instead, we must change the future way of working, by learning from the past mistakes, so (new instances of) our old built-in problems are never generated anymore. Dissolving root causes means that we are having a continuous and systemic learning by making a new systems design of our way of working, where also the line hierarchy and virtual delivery structures are part of the solution.
Since the problem-solving process where MECE is included, de facto is never asking why on the problem proceeded from, it will not bring us back to the root causes of our own organizational problems. And we are really talking about “back to the root causes” as discussed above, since they can have happened as much as years ago in a complex context like product development, where the feedback loops are generally very long. In a clear repetitive context where the complexity is low, like when something is produced, a car or a meal, the feedback loops can be very fast. But, no matter context, there will always be interactions between people as well as the need of planning, which are important ingredients of the way of working for any organisation. So, if we have problems with the economy, one part can be the efficiency of the current way of working, which then will have its root causes, since it happened in the past. Without looking for the root causes, the solution to our problems will be faulty, to say the least, since root causes are fundamental facts that we can lean on.
Without looking for the root causes, we are not learning from problems generated by our own way of working, so they will continue to be there. This means that the solution presented to the customers only regards the present, based on conclusions drawn from data, from assessments, surveys and what other organisations have done. But it does not include anything about the built-in deficiencies in the organisation’s the way of working, which means no actual learning.
As we understand, reductionism and its corollary aggregation, or atomism with its corollary combination, will never work in a complex or complicated context, or never in any context when having built-in problems (symptoms). And as we also understand now, neither will MECE. But this also means that we under the same circumstances, never can take the requirements on the whole and just dish them out into parts, components, buckets, containers, value streams, etc., the name does not really matter. The requirements on the whole cannot just be split into the different parts, as some kind of categorisation. This is because it is not until we integrate the solution to a whole and test it, that we can understand that our hypotheses, the specified requirements on the parts, worked. Just trying to ladle out the requirements of the whole into parts as categories, cannot even be considered half-baked, since the risk-taking is limitless.
So, even if the solution needed, needs to be executed fast, due to for example economic reasons, without the root causes we do not have all the essential information. This means that we will cut the wrong expenses, fire the wrong people, or make a re-organisation we did not even need to do, etc., which can put the organisation in serious troubles for the future. Without the root causes, we simply do not have the fundamental facts that we need, to make the right decisions. And the root causes are very easy and fast to find, and the solution from them, often straightforward, so we cannot have that as an excuse either, for not even looking for them.
Here is a one-pager, a picture where the symptom “too many meetings” is analysed, symptom – too many meetings. In the case to the left by looking at all the symptoms within the organization to get the total problem picture, and to the right by the consultant problem-solving process with the Minto pyramid principles with MECE.
The problem picture analysis to the left is done by using the Systemic Problem Picture Analysis – SPPA method, is authentic, and comes from software product development built on scaled agile, but it is only a small part of the total problem picture for the whole organization. The symptoms as well as the found root causes can be seen in many organizations scaling up agile, especially when developing bigger and new products. As you can see, the right side only tries to reduce the meetings, or the length of the meetings. This is not a bad thing, since no meetings shall be lengthy, and we shall only join the meetings we need to be at, etc. But as we can see, these solutions are not even near to the root causes, since they are only focused on closing the gap, the vision, strategy or goal, of having only the right number of meetings with the right length. This can also be seen as taking care of incidents as described above, especially if our people are working constantly too long days. But, as we can understand regarding the root causes, they must be dissolved, otherwise we will make the wrong product wrong, most probably by more and more unhealthy people, not to mention even more meetings. And important to add is, that it is only when we know the root causes, we can know which of the meetings we can reduce, or not participate at, or shorten, in order to give us more time, never before. This is especially valid for meetings regarding built-in problems, which will disappear over time when we dissolve the root causes, compared to meetings for normal problems that we of course still need to have in order to make our product. See also this blog post for a deep dive into different types of (too many) meetings.
Here is another example with a symptom “the delivery time cannot be met”, still authentic to the left and visionary to the right, symptom – the delivery time cannot be met.
As we can see, the left is the same, there is no difference, the root causes are the same, which is not strange, since the problem picture is the same, it has not changed. But, to the right, we are trying to solve the symptom “we cannot deliver in time”, but still not a root cause in sight, so there is still no valid solution that is not sub-optimising our whole. And there cannot be a root cause in sight either, since why has never been asked. Here we can also take Toyota’s production system, that is a Clear context according to Cynefin™ Framework, as an example. It is rather self-evident, that Toyota when having the symptom “the delivery time cannot be met”, never would even think about trying the right side of the picture.
If we instead take a last example, the symptom at the top, “our organization is not profitable”, that one is according to management consultants, a perfect match for the right side to choose the Profitability framework. Here is the picture over how that will look, symptom – our organization is not profitable.
But, as stated before, without asking why, we can never find the root causes, and therefore we can never dissolve our problems to the left. And too often, the solution to non-profitable organizations is to cut the expenses by outsourcing or by firing people by evenly slicing from all silos, departments, units, etc., in the organization. But no matter if we think that any part is inefficient, ineffective, too expensive, have too bad quality, etc., are just symptoms. These symptoms are originating from the integration of the parts (us) of our organization, when trying to fulfil our purpose with our way of working, which is not fulfilling the Organizational Principles. This means that to just cut the costs on any part of the organization, is only a sub-optimization. The reason is that any non-fulfilment of the Organizational Principles means that our organizational systems design is antisystemic, leading to that we have root causes and symptoms. A systems design that dissolves the root causes and the symptoms, is the only way forward, to have A Walk in the Park. Trying to solve organizational symptoms, is exactly the same as sub-optimization, which means unintended consequences (bad ones) and will only lead to A Walk in the Dark.
We can simply just pick any symptom in the problem picture to the left, and we will get another impossible attempt for symptom solution, another useless sub-optimization, to the right. And apart from that the right side never can remove any root causes, we can also understand how much time that is spent on very wasteful sub-optimization if we are using the right side for problem-solving. And the symptoms will pop up anywhere in the organization, so multiple parts of the organization will work on the same symptom, only a different instance of it; silos, value streams, team of teams, units, sections teams, individuals, functions, etc. We can also understand that the further away from the root causes, the higher up in the hierarchy of the organisation we will come. They will bother about these symptoms, since it is clearly their responsibility. But still, top management has no idea about these root causes that we can see in the pictures, no matter in what organization we find root causes; production, service, product development, or others. This means that without that knowledge they will definitely make the wrong decision, with or without help. This since, the decision to be taken, is not based on any learning from the wrong decisions already taken in the past, which has led us to today’s problematic situation. Now, we can start to sense not only the power of SPPA, but also that it is really simple, straightforward and fast to use as well, when leading us down to the root causes.
The total management consultants’ problem-solving process above where MECE is an important part, is often described as to move from what to do (trying to find the solution directly, which many customers try), to how to do it. During the effort to find the solution to the often ambiguous and complex problem, the what the customer must do, is to be found. As we understand by this time, there is a big problem with this, since the question why is never asked. But, when we have symptoms, we must always start to ask why. Always, since otherwise we are trying to solve symptoms, and that is impossible, and this is even though buckets, handed out to as independent parts to the consultants, looks neat and tidy. But, if we put all these different attempts to try to solve every symptom, and do not forget that every symptom is multiple anywhere in the organisation, we will instead have a mess like this on the right side, symptoms can never be solved. But, still no root causes in sight. And without finding the root causes to our (organizational) built-in problems, a systemic solution is never possible.
The conclusion we can make is that no matter problem-solving process we are using, including MECE or not, we need to start our critical thinking already on the problem-solving process itself, since we always need to look for the root causes from the total of all our built-in problems. We need a problem-solving process that is actually working, like SPPA, and we cannot let a clean structure with no overlaps or gaps pervert our critical thinking regarding the fact that symptoms are impossible to solve. The root causes are therefore vital to find and together with the organizational principles they are fundamental to be able to make a systemic (dis)solution, valid for the whole organisation. We need a systematic approach for a systemic learning, based on theory, if we want our organisation to be efficient, effective and flourishing. Looking for the root causes is therefore always necessary and the most vital part of any problem-solving approach. Yesterday, today and tomorrow.
C u soon again.
References:
[1] Snowden, Dave. Explaining The Cynefin™ Framework in a film. Link copied 2020-04-13.
https://www.youtube.com/watch?v=N7oz366X0-8
[2] Snowden, Dave. Explaining The Cynefin™ Framework in a blog post. Link copied 2020-04-13.
https://cognitive-edge.com/blog/cynefin™-as-of-st-davids-day-2019/
[3] Dr. Ackoff, Russell. A Lifetime of Systems Thinking. Link copied 2021-11-06.
The Systems Thinker – A Lifetime of Systems Thinking – The Systems Thinker
[4] Social Research Glossary. Reductionism. Link copied 2021-11-01.
Social Research Glossary (qualityresearchinternational.com)
[5] Lexico. Atomism. Link copied 2021-11-03.
ATOMISM English Definition and Meaning | Lexico.com
[6] Snowden, Dave. Blog post. Link copied 2021-11-02.
Deal with the system as a whole please – Cognitive Edge (cognitive-edge.com)