Shared Systems View: Bootstrapping Adaptive Capacity In Your Project

“All this talking about self-organization, complex systems and other fuzzy wuzzy stuff. HOW DO I USE THIS IN A REAL PROJECT?”

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.