Fair enough. It is the same question I have.

In this post I will outline my idea for a technique that combines the notion of a project as human system working towards a desired goal (see: Second Turn: Structure For Resilience) and systems thinking, a technique that can be used to find patterns and the real cause-effect-chains in projects. I would really appreciate your additions and comments to this concept.

Adaptive Capacity

A project is a human system working towards a desired goal. A project is running within an environment that is changing continuously.The project needs ways to deal with these changes and still keep performing its function, that is, reaching the desired goal. The project needs a capacity to adapt.

Self Organization

An important concept that allows for adaptive capacity is “self organization”. In contrast to a traditional central plan-and-control organization this would allow for individuals to act fast upon changes in the environment, it would allocate the proper resources to a problem more efficiently. There is no central bottleneck for information which consumes time. There is no central point of decision that has only a fraction of the collective mental capacity.

Self-organization in project teams only works when everybody uses the same rules of engagement, when everybody has the same sense of how things are done within the team (culture).

Continuous Transparent Feedback

A system always communicates with its environment and based upon the feedback it gets from it, alters its behavior. If a group of animals will drink water from a well and one of the groups dies because of it, they entire group may search for a different well. If a company introduces a new product, and sees its stock plummeting because of it, it might change its strategy. It is therefor essential that the organization members get continuous feedback on their own performance and the environment. This is where the use of analytics, metrics and in-your-face information visualization comes in.

Creating A Shared Systems View

At the start of your project organize a workshop with your team and key stakeholders. You will create a shared systems view of the project. The benefits of doing this are

• this will synchronize an important part of the “how we do things” rule set.
• you will discuss and define the metrics that will be used as a feedback mechanism to the team to self-organize.
• you will create insights in a complex situation by using the collective knowledge of your team.
• you create the foundation for fast and speedy discussions when the project is actually running into problems.

The process contains five steps:

1. Go through the flow of the process

The first step is to discuss the flow of the process, the project steps (Prince2, Scrum, XP or your own process). Don’t copy the outline of your handbook, make it dynamic using a whiteboard.

The goal is to create a common understanding of the process. Use an informal notation that uses words and arrows pointing from one word to another.

Look at these examples for suggestions.

2. Define metric variables

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”. When analyzing or discussing your project, you have to look at a certain variable (like budget overrun, defect rate) over time, and then investigate the trend.

First you have to decide on your variables. You can start anywhere.

Just pick the issue that is bothering you the most, or variables that have the highest priority.

Remember, you are going to look for patterns over time. E.g. Programmer productivity is dropping.

For projects you can use for example:

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

3. Discuss how variables influence each other

All these variables can rise or fall over a period of time. Discuss how a variable evolved over time and what the current status is. Always use words that indicate movement: goes down, goes up, increases, rises, falls, improves …

Then comes the next step: connecting variables. 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.

(This technique is described in detail in The Fifth Discipline Fieldbook.)

4. Put delays in to the systems view

In this step you explicitly focus on 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.

5. Summarize

In the final step of the workshop you will create an integrated map of the process steps, the variables, causes and effects and delays. This will be the reference/starting point when future problems in the project are discussed. Every future discussion will cause an update in the systems view.

I would really appreciate your additions and comments to this concept.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Shared Systems View: Bootstrapping Adaptive Capacity In Your Project is a post from: Project Shrink.

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

I started this topic to be able to analyze problematic situations in projects. You will need to try this technique a few times before you really get the hang of it.

To be a good project manager you have to “see” potential problems. Literature provides us with large lists of potential problems in projects. You could look at all those lists to see if your problem is on it somewhere. But wouldn’t it be great to be able to look at problems in your project on a more fundamental level? That would be the best thing that can happen to you, and the techniques discussed in this series, will help you just with that!

Start running small workshops where you discuss the variables you chose (like budget overrun, number of bugs).

• If this variable is going up or down with ever increased speed you have to look for a reinforcing loop;
• If the variable is moving towards a threshold, and either stays on this threshold or starts oscillating around it, you have a balancing loop;
• When a problem symptom alternately improves (the variable goes down) and deteriorates (problem goes up worse than before) you might have a “Fixes That Backfire” on your hands;
• There is growth (sometimes explosive) leveling off or failing into decline, you might start looking for “Limits To Growth”.

Getting familiar with the archetypes helps you looking for the right loops and links.

And there is an additional bonus: when discussing and talking about the problems in this way, the solutions just “pop up” as you are addressing the fundamental causes.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Systems View – Final Analysis is a post from: Project Shrink.

Archetypes can be considered as stereotypes of problematic situations. When analyzing a situation they are the standard patterns you look for.

In this post I will describe two archetypes:

• Limits To Growth
• Tragedy Of The Commons

Image by laurenatclemson.

Limits To Growth

In this case two processes are intervening with each other: a process that indicates growth, and a process that puts limits to this growth (with a delay). If you think about project management a classical sample of this type is the addition of members to a team to increase the total productivity of this team.

Example

To increase productivity of a team new fresh employees are added to the team. However, people need time to learn the ropes within the teams working environment, and with extra members to total communication overhead increases.

Within small teams this may not have a large impact on the productivity of the individual team members, but as more and more new members are put to a team, the productivity gain will drop. It will probably plateau at a given moment, or, when teams are getting too large, too much new members are added simultaneously, etc. it may even drop.

If you have a variable that is increasing and all of a sudden you hit a plateau or it even collapses, you might look for a “Limits To Growth” situation.

Tragedy Of The Commons

The Fifth Discipline archetypes I discussed until know can be considered as relatively simple. Just a view loops that are interacting. Reality will be more complex where multiple archetypes are interacting with each other. The next archetype is such a situation: Tragedy of The Commons.

With Tragedy of The Commons you have multiple Limits To Growth that are interacting with each other. To be more precise, they are interacting on the same limiting process or constraint. The symptoms are identical to a single Limits To Growth, but with increased speed, and not transparent.

Example

Consider the situation where you have two projects (A and B) that are both in testing phase. The growing process is finding new bugs by the test team. The overall performance per project is the number of bugs at a given moment. This will not be increasing forever as the bugfix team will resolve the bugs with some delay. However, the speed of fixing is limited by the capacity of the team.

Normally the capacity is calculated for such situations. But what happens: project A sees that by giving bugs a high priority, the time they get their fix speeds up. Project B concludes the same thing, and does this also. And although the capacity is calculated to handle two projects (but only when using the “real” priorities of bugs) the overall performance drops like a fly.

Next time:

Final analysis.

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

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Limits To Growth And Tragedy Of The Commons – Archetypes Part 2 is a post from: Project Shrink.

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

Archetypes can be considered as stereotypes of problematic situations. When analyzing a situation they are the standard patterns you look for.

In this post I will describe two archetypes:

• Shifting The Burden
• Fixes That Backfire

Image by Terry Wha.

Shifting The Burden

With Shifting The Burden a problem is only superficially fixed and not at its root. A problem occurs and a corrective measure is put into place. However, this is a symptomatic solution that doesn’t tackle the fundamental problem. The fundamental solution takes time; there is a delay before its effects will be visible.

Because of the delay the fundamental solution is harder to find, or more costly to implement. But as the symptomatic solution has only side effects (negative) on the fundamental problem, the situation will not be solved, and will even deteriorate.

(note: the hourglass in the diagrams indicate a delay)

Example

Two information systems have an interface running from system A to system B. Short after going live many data records are marked as error on the receiving end at system B.

At first this does the trick, however after doing this for a while the backlog of wrong records is large; one cannot keep up with fixing the data records. Because of the large amount errors are cascading, making the situation worse and worse.

Fixes That Backfire

Within this system you have two loops that interfere with each other: there is a problematic situation that is solved by a short term (quick) solution. However this loop has unintended consequences that only make the situation worse. The quick fix that bites you in the back.

The sneaky part here is that there is a delay in the backfire: you will only see the unintended consequences after a while.

Example

Suppose you have a software system under development. The quality is not good enough and it is not addressing the right business issues. You assume that this is caused by the lack of quality that your user
group brings into the project: they have a hard time formulating the requirements, they have no experience in testing, and seem to resist change in general.

They will not help you out with the important info, and will not accept the system as something they really want to adopt. Which in the end lowers the quality of the system and ruins your chances of reaching the business goals set for the new system.

Next time:

Two other archetypes: Limits To Growth and Tragedy Of The Commons.

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

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Shifting The Burden And Fixes That Backfire – Archetypes Part 1 is a post from: Project Shrink.

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

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Systems Thinking: Looking For Causal Loops is a post from: Project Shrink.

“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

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Systems Thinking: A Technique To Find Project Problems is a post from: Project Shrink.

This article takes a brief look at each of the disciplines espoused by Senge, which, according to him, are the hallmarks of a “learning” organization:

• Personal Mastery
• Mental Models
• Systems Thinking
• Shared vision, and
• Team learning.

In the backdrop of software projects, systems thinking, personal mastery and mental models work on the level of the individual, while the concept of shared vision and team learning have more to do with team dynamics. This is applicable for the project manager / leader as well as the team member. Every discipline will have relevant links to articles on Project Shrink, so you can plan ideas for improvement.

Personal Mastery

Photography by Mind meal.

“Personal Mastery” is another name given to the state of Self-Knowledge. Project Managers should have a great sense of why they are doing what they are doing. Are you performing a technique because you are supposed to do as a professional, or because you really think personally that the technique will be beneficial to the project? Another part of Personal Mastery can be found in clearly knowing your own desires and goals, your strengths and limitations.

Mental Models

Photography by Tom@HK.

“Turning the mirror inwards” is how Peter Senge describes mental models. He has taken as basis for his postulates, the research work done by Dr. Chris Argyris in the field of mental modeling. Dr Argyris, in his path breaking studies, made the contention that people who manage projects swing between two mental models – one that they adopt as their favorite, and the other that they eventually slip into, in actual practice.

Traditionally favorite mental models bestride extremes of the spectrum – with a plan-and-plan-to-minutest-detail project management approach balancing a plan-minimally-and-manage-as-you-go approach. Senge’s mental model recognizes the “inherent” chaos in managing software projects upfront. Though the initial set of conditions that a project takes off from may be as orderly as possible, Senge suggests that we

• Understand and value “leaps of abstractions” – that is, the tendency to generalize specific issues;
• Recognize the subtext beneath our words that go into the project plan – that is, understand and appreciate that your perception of the other party is saying may be different from what actually got said;
• Strive to achieve a deft balance between the skill of inquiry and advocacy – this is done through actively listening to the other party, and, at the same time, articulating one’s own thought processes and encouraging others to fill in any gaps that they see
  in them;
• Keep in focus the ambivalence in our own favorite theories and the ones that we actually end up practicing.

Mental models provide us with lenses to view the world. If we look through a depressing lens, we see depressing things and behave accordingly. By using different mental models, or mindsets, we can understand other people better, by adopting assumptions of the other person.

Systems Thinking

Photography by Eirikref.

Systems thinking, as a discipline, requires a shift of mind:

• From focusing on cause-effect chains, to focusing on interrelationships between the components; and
• From looking at snapshots and arriving at conclusions, to looking at processes of change, and then form conclusions.

The key factor that matters in Systems Thinking, is that not only is the whole greater than the sum of its parts, but also it is different from the parts themselves. Systems thinking helps us with making sense of the complexity around us. To find some answers in search for causes of project problems. You need some clues to introduce the proper intervention.

Shared Vision

Photography by Lovelypetal.

Shared Vision is a group effort, as opposed to the earlier three disciplines that we have discussed so far. This discipline requires the project team to ask the Five Whys
about the project in order to be clear about the underlying tenets of the work in hand. This also helps in establishing the boundaries of the project and to articulate metrics against which success of the project shall be measured. The end result of this exercise shall be an “Initial Vision” state that the team shall have reached.

This vision is then “sold” to all the stakeholders, through status meetings, emails, etc. Perhaps an exclusive Web site that details the project in full, and is packed with all the relevant information – which all the stakeholders have access to – would help too. The idea here is to transform the “initial” vision to a “shared” vision, where everybody is aware of how the project has to perform and go.

Team Learning

Photography by Veni Markovski.

Like the Shared Vision, Team Learning is a group-centric discipline in Senge’s scheme of things. Team Learning has its roots in fostering creativity amongst the team members through three dimensions:

• Thinking insightful on issues that are inherently complex;
• Taking innovative and coordinated action on specific tasks; and
• Creating a network that encourages other teams to participate and take action as well.

By picking members for a software project that have the right mix of skills and mindset – whose Personal Mastery is such that there is no possibility of working at cross-purposes – and putting them through the process of Systems Thinking and Mental Modeling, one gets to the stage where a cohesive team has been built. A Shared Vision follows. When all the team members are on the same wavelength so far as the software project goes, contributing their ideas on a particular problem in a group becomes easy. Ideas start building seamlessly upon one another, and the entire team learns through this process.

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Fifth Discipline: What To Do When All Your Projects Are Failing is a post from: Project Shrink.

Project life can be quite frustrating when one day after another turns out not how you planned it. The software should be ready when you said it would. It has to. Otherwise you have people waiting, customers complaining and bosses getting annoyed. It is your reputation and ultimately your job on the line. If you just plan harder, more detailed, than the plan must be correct. Right? Of course not. I know, it is becoming some kind of mantra for me, but, yes, it is a shocker for a lot of people, you can’t force reality in sticking to your plan. Forget it. It is not going to happen. Ever. Because it seems to be a habit hard to break, a state of mind hard to get rid of, it is worth spending a little closer look into this matter. Why can’t we predict project future?

Fifth Discipline

The answer starts with something called “The Fifth Discipline”. It sounds like some cult, some hush-hush society that guards a life-changing secret: the 5th Discipline. Although it was life changing for me, it is nothing like that. It is the title of a book by Peter Senge he wrote in the early 1990s [1]. He put forth the idea of “five disciplines” that have to be considered in improving business and organizations (Personal Mastery, Mental Models, Systems Thinking, Shared vision, and Team learning). Every discipline has its own merits, but for the topic at hand we will focus on one: systems thinking. For Senge 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. To give you an idea, consider the following example: A car repair shop has not much to do. So if a client comes with his car, he can be helped 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 to long, clients go away. Having fewer clients, again, the speed of service is up again.

In this short example, our main problem with reality becomes clear. It is called “dynamic complexity”. In our normal line of thinking, we think about an event A that happens, and that causes something else, say B. The occurrence of B might trigger some event C. A nice linear cause-and-effect chain. With dynamic complexity this is exactly what is not taking place: cause and effect are not close in space and time, and therefor, very difficult to see for us.

Another example: to increase productivity of a team, new fresh employees are added to the team. However, people need time to learn the ropes within the teams working environment, and with extra members to total communication overhead increases. Within small teams this may not have a large impact on the productivity of the individual team members, but as more and more new members are put to a team, the productivity gain will drop. It will probably plateau at a given moment, or, when teams are getting to large, too much new members are added simultaneously, etc. it may even drop.

Systems Theory

When you talk about it, it feels quite natural. It has a proper “yeah-this-is-how-it-works” touch to it. But mind you, it is quite a mental stretch for most of us. Between the great World Wars of the 20th century scientist Ludwig von Bertalanffy came up with a new way to look at things in physics, biology, economy, psychology, sociology and all other sciences; he formulated the General Systems Theory. In essence this view on the world consists of recognizing that independent elements make up something larger, something bigger, a unified whole. Although the elements are independent, they are influencing each other, the have a certain relation, they are related. This “whole” with its underlying elements is called “a system”.

Although the previous paragraph may throw your mind in a back flip, the concept of systems is quite an intuitive and natural thing; an organization consists of employees all working and communicating together, they make up the elements for the “whole” which in this case is the organization. Flows of air, the movements of water, the impact of sunshine are all the underlying elements that make up our weather system. Every individual buy or sell transaction make up our economy. You see, nothing to be scared here.

At a first glance this systems world view seems like an empty shell. You might wonder what it brings us? How can this help you and me? The answer is nicely formulated again by Senge [1]

“Business and other human endeavors are also systems. They, too, are bound by invisible fabrics of interrelated actions, which often take years to fully play out their effects on each other. Since we are part of that lacework ourselves, it’s doubly hard to see the whole pattern of change. Instead, we tend to focus on snapshots of isolated parts of the system, and wonder why our deepest problems never seem to get solved. Systems thinking is a conceptual framework (..) to make full patterns clearer and to help us see how to change them effectively.”

Another neat thing about systems is that across the whole spectrum of sciences, systems pop up that look the same or have similar behavior then systems in a different discipline. This allows is to beg-steal-and-borrow theories and models from different areas. Our toolbox to look at our own systems of interest has widely broadened.

Cybernetics

Closely related to the notion of systems is the concept of cybernetics, first formulated by the mathematician Wiener. This concept describes how a system communicates with its environment and based upon the feedback it gets from it, alters its behavior. If a group of animals will drink water from a well and one of the groups dies because of it, they entire group may search for a different well. If a company introduces a new product, and sees its stock plummeting because of it, it might change its strategy. The feedback mechanism comes in all sorts and shapes; they are the focus of cybernetics. The additional value this brings should be obvious; a system always lives within a context (a project within a larger organization for example) and this idea of communication/feedback provides us with an angle on how to look at this phenomena.

And new angles are precisely what we need to counter our idea of reality-following-the-plan. It is all a matter of changing our mindset. Doug DeCarlo almost dedicated half of his book Extreme Project Management [2] to convince us of this fact. In his opinion traditional managers hold a Newtonian view of the world, in the sense that events are linear, cause-and-effect can be nicely summed up in beautiful laws. In today’s world of dynamic complexity that model of the universe in your mind is not going to cut it for you: what you need is a quantum mindset. Exactly the kind of world view I am talking about!

If you are convinced that you cannot predict the future, your control loop becomes completely different. Traditional the thermostat model is used: reality is measured and compared against the plan. If reality is different than the plan, all effort is put into creating such a process that reality is in line with the plan again. If salespeople are not meeting their targets, they don’t get the bonus. This kind of carrot-stick management creates all kinds of unwanted behavior. Like people that are reporting what they are supposed the report to confirm the plan, regardless the actual real situation. Everything to avoid the stick.

When you have a quantum mindset, you know that reality cannot be planned. The thermostat model is therefore a ridiculous way of managing. More natural is the adoption of the scientific model: your forecast of the future is your expectation. If your forecasts are not in line with reality, your assumptions on which you based your expectations on, are not correct. You need to alter your mental model and try to come up with better forecasts.

[1] Senge, Peter, 5th Discipline
[2] DeCarlo, Doug, Extreme Project Management

Bas de Baar helps people find ways to enjoy the diversity of human interaction in their organizations so that they can get out of their own way and achieve their goals. - Reality Refuses To Follow Your Plan is a post from: Project Shrink.