The purpose of this post is to explain how to model interactions using causal diagrams. Causal diagrams depict non-linear and bi-directional interactions between elements that together create a system.
If you’ll be asked to depict in a diagram a simple flow (from customer requests to finished requests), your model will be more or less like the one below. You’ll have different roles that perform different tasks. Each task is connected with a line to the next task (or to a decision point). The lines indicate a clear cause and impact. The source of the line is the cause and the target task is what impacted. Simple linear relations. To fix a problem in this flow we need to find the task (and the role) that has difficulties and create challenges.
Is this simplified model of reality depicts reality and is it helpful to resolve any problem in an organization? The answer is no for both of them.
Let me introduce you to another model that depicts reality more accurately. In this model, there aren’t any linear lines between elements in a system. If A impact B, B also impact A. We need to find out how. This model gives a more holistic understanding of the system and reveals root-cause for known problems.
Like any other model, this model has roles as well. The model contains Variable (nouns that depict any aggregation in the process), lines that depict causality between two variables, plus (or S) to depict A add to B or they are in the same direction, minus (or O) to depict A removes from B or they are in the opposite direction, and delays in the impact.
We start causal diagrams by creating all the variables. In this case, we have five variables. Requests, requirements, Projects, Tasks, finished requests.
The next step is to define how each variable impacts the other. We can start following the linear flow, but we need to capture also how the impacted impacts the cause. For example, if request impact requirements, we need to define how requirements impact requests. The impact should be defined as decreasing/increasing or in the same direction / opposite direction.
Requests increase the number of Requirements and the fact that Requests turn into Requirements encourage people to generate new Requests. So we have two positive (increasing) lines. We are also coloring the lines (green for an increase, red for decrease )
Those two lines create a loop between Request and Requirements. This loop is a reinforcing loop that will keep amplifying (positively – increase or in some point of time negatively – decrease) requirements and requests.
The causality between Tasks and Projects is different. Project increase tasks, but too many tasks decrease the ability to take new projects. This case will have a positive impact on tasks and tasks are going to harm the number of projects. This creates a balancing loop.
Impacts are not just limited between two variables. Any variable can have impacts on other variables, creating loops within loops. The entire picture of all causality within our domain can be a mixture of balancing and reinforcing loops.
As you can see this model took away roles, but add more visual data on what increase and decrease elements in the domain we are focus on. You can see the problem created by the causality between tasks, finished requests and requests. This a good example of how a problem is generated from the interactions of several roles, and not by one underperform role.
We should augment are view with delays, if they exist, that impacts loops. For example, many tasks need to be finished to create finished requests, therefore there should be a delay between tasks and finished projects. The same applies to the impact of finished projects on tasks. It takes time to collect requirements and set up a project. With other related delays, the new diagram should look like that:
Delays are important since people tend not to connect the cause to the impact as delays become longer. You can see visually the impact of delays on the problematic interactions we saw above.
I hope that you can see the benefit of a non-linear view of causality and how it can help you to see challenges that are invisible with the linear approach. Causal diagrams have archetypes that define known problems and solutions for the known collection of loops. We will discuss them in more detail in our next post.