Cool stuff: Different Work | Your Big Adventure | The Fish Pond
This is the fourth post in my series about using systems thinking for analyzing problems in projects. I recommend you read the previous posts before diving head first into this post.
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.
Now consider the situation where the fix team within a company is shared. So project B will use the same capacity of the fix team. The two processes are interacting on a common resource.
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
The limits to growth section of your articles brings back memories of the Fred Brooks classic software engineering essays entitled the Mythical Man Month. As you remind us those lessons still apply today. I have worked with many development teams who would agree that adding new person to a late project is the last thing you should do if you want to hurry it up. The training and distraction factors for the core team often results in a net delay. However, adding testers works well for QA bottlenecks. Project managers need to be sensitive to the limitations of adding people to certain tasks.
The common resource issue is also one I can relate to. For software projects, one should never underestimate the impact of concurrently sharing a developer across two projects. In systems terms, I would factor in a half day switching delay or latency for every change in context.
Ah yes “Adding resources to a late project will only make it more late” or something! Great reminder.
About switching costs: I think that is why all productivity gurus on the net are telling us multi-tasking is bad