How to make a MECE Issue Tree

As part of my reflection of the problem solving framework, I mentioned the need to have a proper issue tree to ensure that the problem solving process is Mutually Exclusive Collectively Exhaustive (MECE). In this write up, I will use the same inventory ledger problem to show in greater detail how to use a MECE issue tree to solve problems given and also how to check your issue tree to make sure that it is up to standard.

 

Why MECE

Before we dive into the details, let us look at why we even need a MECE issue tree in the first place. The main reason for this is because of Vatico’s result-oriented culture where work must be done. 

 

Without MECE, complex problems may become too challenging for everyone to solve and cause us to give up. However, with MECE, we are able to break down complex problems into smaller parts. As such, we will be able to find solutions to each aspect. While it is true that there are solutions we do not adopt due to reasons such as cost, there is still a large difference between knowing and not knowing what the issue is. By knowing the solution, we can evaluate the cost and benefits of the solution and this allows us to prioritise our resources so that if we do have the resources in the future, we can come back to solve it.

 

How to use a MECE Issue Tree to Solve Problems

Now that we know why MECE is used, let us now see how we can apply MECE concepts in an issue tree. This MECE tree should only be done during the problem solving phase after revisiting the problem and objective and gaining knowledge of the underlying issue.

 

The issue tree will always start the main problem we are tackling. We will then begin to divide this main problem into mutually exclusive sub problems that explain why the main problem occurs. This is done by listing out all the possible causes of the problem, then coming with SQL queries to check they are the ones that are causing the current problem. In the event it is another problem that is not previously, feel free to add into the tree. This will continue until solutions are reached. We also need to make sure the solutions are actionable and measurable. (covered in later section)

 

Simple Issue Tree with only 3 layers

 

 

How to decide how many layers there should be

 

Knowledge base

With a large knowledge base, we will have a better understanding of where we could go wrong in the business process, this will thus lead to us having more layers. Conversely, having less knowledge will lead to fewer layers at the start. However, as we investigate the issue, we will gain more insights into the issue and hence it is normal that we will add more layers along the way regardless of our current knowledge base.

 

Objective

Different problems have different objectives which have different levels of details needed, hence they would also need a different number of layers. For projects where the objective is a high level strategy, we would not need to dig as deep to the root cause of the issue. On the other hand, for issues like audit work, we need to be detailed. In such case, we will need to dig deep and really reach the root cause of the issue.

 

How to QC your issue tree to make sure it is up to standard

 

Check 1: Main Problem is correct

The first and most important check is to ensure that your main problem is defined correctly at the start, if this is done wrongly, your whole tree might become irrelevant.

 

Check 2: Mutually Exclusive Sub Problems

There must not be any overlap in the problems mentioned. One example of overlapping problems would be (using the same inventory example) if one of the problems was delta ≥ 0 while the other problem in the same layer was delta ≤ 0. In such a situation, delta = 0 is covered in both problems, thus resulting in problems later on. 

 

It is however ok to ask the same question on different branches in the same level.

Example of what is not considered as overlap

 

 

Check 3: Collectively Exhaustive Solutions

We also need to know when it is ok to stop iterations in finding solutions and when it is not. One clear guideline would be to stop only when we have reached the root cause of the issue. For eg. it would not be sufficient to say the difference is due to missing inbound inventory, as we are still unable why there is missing inbound if we stop here. On the other hand, if we now find out that missing inbound is due to returned items being returned to the nearest warehouse rather than warehouse of origin, we would know the root cause of the issue and hence be able to resolve it.

 

Check 4: Measurable

Problems and solutions must be measurable so that we can evaluate them. An example of a measurable problem would be physical count and inventory ledger as we can tell if they are correct or wrong. On the other hand, if the problems were human error and system error, we would have no way of calculating what they are and thus make them meaningless.

 

Check 5: Actionable

Problems and solutions need to be something that we can control and solve. Examples of non-actionable problems would include bad economic conditions, which we have no control over, making solutions to it unrealistic and meaningless.