Yesterday I talked about how systems thinking can be used to find patterns and cause-effect-chains that help you find solutions to problems in projects.

All these patterns, links and loops are fine and dandy, but you are probably wondering right now how this is going to help you running your project?

Check Out This Example Of The Housing Crisis.

Image by I See Modern Britain.

First have a look at this great example about the housing crisis. Twitter user @jeremyx sent it in reply to yesterday’s post. Thanks!

I recommend to go to this example and click on “2. Trace Causal Loops”. It provides a nice, step by step explanation of the elements of the housing crisis …

“Tracing the CLD (causal loop diagram) will give you a high-level understanding of the relationships between the key components of the underlying model – housing supply, housing prices and demand for both housing and mortgages.

Stepping through the feedback loops really helps to explain the situation in very operational terms. And it’s much easier to understand what’s happening when you’re dealing with one loop at a time.”

And… you’re back!

The behavior of a system can be described using variables. A variable is an element of the systems you are looking at that changes over time, like “speed of service”, “number of clients”” or “number of customers that slap you in the face”. Or in the housing example “housing supply” and “housing prices”.

When analyzing your project using systems thinking, you have to look at a certain variable (like budget overrun, defect rate) over time, and then investigate the trend.

You are looking for patterns of behavior over time. As the systems are reocurring loops that effect certain aspects, patterns will emerge when you view them over time.

The pattern that you might discover is a hint to which archetypes one might look into (archetypes are the stereotypes of organizational problems and will be discussed in a later post). They don’t provide the final answer at once, you might try several archetypes before settling on your final verdict.

But first you have to decide on your variables.

You can start anywhere.

Just pick the issue that is bothering you the most, but don’t try to explain it, yet.

Remember, you are just looking for patterns over time. E.g. Programmer productivity is dropping. When you are doing this exercise with other people, it is always nice to use an element of the situation that can relatively be measured neutral.

For projects you can use:

• Schedule slippage
• Budget overrun
• Programmer productivity
• Size of backlog
• Number of change requests
• Number of bugs found
• Number of test cases performed per day

You get the idea.

Telling The Story

All these elements can rise or fall over a period of time. Try to describe how this element evolved over time and how the current status is. Always use words that indicate movement: goes down, goes up, increases, rises, falls, improves …

Then comes the next step: connecting elements. What is the impact of the movement of the first element on the next?

Because productivity is dropping, the risk of schedule slippage increases. You have to try to tell your story using sentences that indicate a causal relationship. “As this happens, then …”, “This in turn causes …”.

Go back and forth for a while. Make the story as detailed as possible. Avoid being judgemental. Only look for cause and effects. After a while, your loops will pop of the whiteboards!

This technique is described in detail in “The Fifth Discipline Fieldbook”.

Next up…

The Archetypes explained.

This a post in my series about using systems thinking for analyzing problems in projects.

1. Systems Thinking: A Technique To Find Project Problems
2. Systems Thinking: Looking For Causal Loops
3. Shifting The Burden And Fixes That Backfire – Archetypes Part 1
4. Limits To Growth And Tragedy Of The Commons – Archetypes Part 2
5. Systems View – Final Analysis

Finding the real cause of a project problem can be a difficult task. You have to look for patterns …

“These patterns are dynamic systems in action, a human system seen over a time period. Patterns are trends over time and involve dependencies with other systems. To spot such trends in projects we use metrics as indicators. If I have the right metrics I can ignore everything around me and focus just on the dashboard.”

Image by Kjai.rm

A technique that can be used to find patterns and the real cause-effect-chains in projects is systems thinking. “Systems Thinking” is one of the 5 disciplines described in the famous book “The Fifth Discipline” by Peter Senge (for an overview view my posting “Fifth Discipline: What To Do When All Your Projects Are Failing“).

This is the first post in a series that will describe this technique and how to use it in your projects.

In The Fifth Discipline an organization is viewed as multiple “systems” (or you may think about processes) that interact with each other. The systems are not viewed as linear, but more as loops that keep on repeating, until some change has been done.

In the Fifth Discipline Fieldbook the image that is presented is that of “loops” and “links”:

“In systems thinking, every picture tells a story. From any element in a situation (or ‘variable’), you can trace arrows (‘links’) that represent influences on another element. These in turn, reveal cycles that repeat themselves, time after time, making situations better or worse.”

Car Repair Shop

To give you an idea, consider the following example:

A car repair shop has not much to do. If a client comes with his car, he can be serviced immediately. After a while worth of mouth about the speed of service, provides this repair shop with an increasing number of clients. As the number of clients grows, the waiting time for service also increases. When the service time takes too long, clients go away. Having fewer clients, again, the speed of service is up again.

After extensive research Peter Senge, author of the book, found patterns that were common among the situations he studied; a couple of loops that occurred in multiple situations: the archetypes.

The archetypes are the stereotypes of organizational problems; the sweet girl, the evil stepmother and the jealous husband from organizational theory if you want.

Basic Structures Underlying The Archetypes

However, underlying the archetypes are three basic structures, the components that make up almost everything, the systems DNA:

1. Reinforcing Feedback Loops
2. Balancing Feedback Loops
3. Delays

Feedback Loops In General

A feedback loop is like a boomerang: you throw it away from you, and after a while, it kicks you back in the head. In the sample of the car repair shop the speed of service creates a chain of event (word of mouth, increase in customers), which after a while influences the speed of service. So with feedback loops there is a cause, and after a chain of effects, the cause itself is influenced again: this is why it’s called a “loop”.

Reinforcing Feedback Loops

This kind of loop generates an ongoing rise of growth or fall (exponential, if you are into that kind of lingo). Sales keep on growing and growing with ever increasing speed. The quality of service is dropping of the scale more and more. With a reinforcing loop a small change feeds itself; it starts slow, but will have a tremendous speed after a while, all by itself. You can actually think about it as a “snowball effect”.

Balancing Feedback Loops

Balancing loops have some kind of limit build in them. When this limit is reached, the plateau, it drops, and having reached some lower limit, it goes up again. It is balancing around a certain point. This type of feedback loops have the appearance of self-regulating.

For an example see the car repair shop earlier in this post.

Delays

Not every effect follows its cause nicely in a timely fashion; it doesn’t have to wait neatly until the cause is completely finished before it will start. You can have time issues. Delays can occur in all kinds of loops. Problematic situations can arise when interacting loops have different kinds of timing. Delays make it difficult to “see” cause and effects, because it is not clear what triggered an event if its root happened already a while ago.

One of the main causes of problems within projects (and companies in general) are two interacting processes where one of them has a large delay; this delay causes problems in the other, much faster process.

Let me give you an example:

A fast paced project runs into time and money problems. New plans are drawn up fast to minimize the impact, but as some more time and budget may be needed, an agreement / decision of some higher level is needed (e.g. a steering committee).

If the project starts adopting the new plan, pending the decision, on the assumption that they will get the ok the situation can occur that when the ok comes, everything is already finished: you can call it “Retrospective Decision Making”.

Next time:

All these patterns, links and loops are fine and dandy, but you are probably wondering right now how this is going to help you running your project?

This a post in my series about using systems thinking for analyzing problems in projects.

1. Systems Thinking: A Technique To Find Project Problems
2. Systems Thinking: Looking For Causal Loops
3. Shifting The Burden And Fixes That Backfire – Archetypes Part 1
4. Limits To Growth And Tragedy Of The Commons – Archetypes Part 2
5. Systems View – Final Analysis