I have spent a good portion of my professional career working in weakly matrixed organizations tasked with delivering projects. If you have ever worked in that context you know that leadership means having all the responsibility and none of the authority. Creating a high-functioning team focused on delivering a single, integrated, and impactful project that addresses the needs of various stakeholders is challenging and requires consensus, or at least a super-majoritarian, view of the project design from the various team members.
You know that projects are going sideways when a team has retreated into their functional silos and the project is essentially a set of mini projects each only loosely related to the next and that prioritizes to the requirements of the various functional groups (technical disciplines) over integration. These teams will be in conflict over resources, vision, and ultimately management attention (the bad kind of attention). Ultimately this reflects a lack of common vision around the problem, the solution strategy, and how the various technical disciplines integrate to create value.
Systems Thinking
Systems Thinking provides a set of tools that can help teams develop a common vision which is a critical component of high functioning teams. At its core, Systems Thinking serves as a useful approach for codifying a team’s story: what is the problem that they are trying to solve, who are the beneficiaries and how will each benefit, what is the intervention, and how will the interventions lead to the results.
As such Systems Thinking can play a critical role in early stages of team and project development. Notably the approach can be used to embrace the storming phase when team members are putting forth their domain specific problem understanding and solution sets and then integrating those during the norming phase.
Here are three of the characteristics of systems thinking that I have found most helpful in project development:
- Causal Loop Diagrams
Causal Loop Diagrams (CLD) are useful tools for diagraming mental models and ultimately telling the project story. They have two components: nodes and links. Nodes are things that an analyst can observe, and links are relationships between nodes. Following a high-level statement of the problem by a sponsor (client), a project team will have to identify the root causes and then the specific interventions. Domain experts often come with specific approaches to problems; and experts from different domains often have dramatically different diagnosis and solutions to problems. Two broad strategies can be used to co-creation of causal loop diagrams and to additional capture expert implicit knowledge: top-down or bottom-up methodologies.
A top-down methodology is based on understanding and applying problem archetypes. For example: certain types of problems are classically common pool resource problems, others have characteristics of limits to growth, yet others success-to-the-successful archetypes. A bottom-up approach is based on identifying key perspectives on a problem. For example – one can identify the problem as seen by a farmer, a municipality, a regulator, and so on. This can help identify useful metrics for success or stressors, as perceived by each stakeholder, that would need to change to measure impact.
Take the example of a resource which is being exploited beyond its sustainable limit. A regulator attempts to control the amount of resource being extracted (policing) and some exploiters will be tempted to over consume beyond their permitted limits (the illicit act). A top-down approach might hypothesize that this is a variant of the Lotka-Volterra predator-prey model. One might then look for evidence that validates (or contradicts!) the model framework assumption. A bottom-up approach might begin with an observation that growth in illicit resource use is influenced by the scale of illicit use but is constrained by the amount of the enforcement effort. The amount of policing is related to on-going investments and the scale of illicit use but that the effectiveness of those efforts is reduced by time absent reinvestment.
- Mixed Data Types
One of the features that I most like about systems approaches is the ability to mix quantitative and qualitative models. Some data are clearly quantitative, even if uncertain: the incidence of illicit use. Other data are much more likely to be qualitative – what is the quality and effectiveness of policing. This is especially beneficial when working in cross disciplinary teams whose traditions may lean more towards quantitative or qualitative methods.
A project manager’s goal is to manage the scope such that the team is focusing on the smallest number of items most likely to have the desired impact. In this way, helping a team move from a collection of symptoms to assessing the understanding emergent properties from the CLD that drive the observations that are stressing the problem stakeholders helps focus attention. Still the question is to understand the relative impacts of various possible interventions – if not the project is at risk of a shotgun approach.
- Feedback Loops
As project managers, and especially engineers, we are trained to decompose problems into smaller tractable problems and go about addressing each one on its own. Risky! One of the challenges that project leads face is ensuring that the solution works and is not a fix-that-fails. A critical element of avoiding fixes that fail is understanding that a complex system has properties that are not self-evident by analyzing the individual elements.
One of the hallmarks of systems approaches is the existence of feedback loops and lags between action and reaction that amply or dampen the impact of interventions. These systems are non-linear! As a consequence, the system may itself have emergent properties that bear on the how projects should be conceived and implemented. These emergent properties are sometimes characterized into archetypes – or story tropes.
Consider the emergent property of the regulator-exploiter model above – it has a clearly observable cyclical relationship between policing and illicit use. As the extent of illicit use expands, policing efforts also expand albeit with a lag. Eventually, illicit use declines even as policing efforts continue to increase. Then the reverse to close the loop.
If a client is complaining that illicit use is a problem, it probably suggests that policing levels are low and that illicit activity is on the increase. What is the solution? Is it more funds for police? Social Behavior Change efforts to discourage new illicit users? Perhaps improved technology to increase detection rates? Where do you as a regulator invest your limited resources to maximize your impact?
In another post I hope to examine the pitfalls of traditional log frame approaches and how Systems approaches hold the promise of deeper understanding and ultimately transformational change.
Some lessons learned
The first thing to note, is that not every problem requires a systems approach. If your problem is a wicked problem – one in which data is poor, there are large number of stakeholders, the costs and benefits of action or inaction are inequitably distributed, and there are linkages to other problems – then you likely have a problem that might benefit from a systems mindset. In my professional universe of economic and infrastructure development – many problems are wicked.
A systems approach is labor intensive and often requires behavior change within the team and by management. If you go forward, make sure that you have – not acquiescence – but active buy in. In practice, everyone on the team has something to contribute at every stage – from actively contributing to the causal loop diagrams to asking for domain experts to explain issues in lay terms.
Remember the goal of these tools is to ensure that the team, the whole team, has a common mental model – the story – that is used to frame their contributions to the team effort. These stories can help the team focus in on those elements most critical to success – which may be defined differently by different stakeholders. Finally, they help teams focus on the big picture and macro level system behaviors and ensure that the detail work is truly aimed at changing the system – transformational change – rather than incremental changes which may in the end be ephemeral.