This chapter introduces Participatory Systems Mapping, a method for building and analysing causal system models in groups, developed by us. The method uses tools from network analysis and focuses on chains of causal connections to develop meaningful and actionable insights with stakeholders. This chapter describes in detail what it is and how to use it, considers what it is good and bad at, as well as describes some of the history of its development. We also point to resources and tips for getting started with the method yourself.
- Participatory Systems Mapping
- Network analysis
This is probably the easiest yet oddest chapter for us to write in this book. Our experiences over the last ten years, as we have developed Participatory Systems Mapping (PSM), are one of the core motivations for this book. We have experienced all sorts of reactions when using PSM, from the positive and enthusiastic, through to negative and harsh criticism. Sometimes people have seemed to think we have invented a whole new way of knowing and seeing systems; others have dismissed us as pedalling little more than repackaged consultancy services. These views are both wrong, but in different ways, yet somehow for the same underlying reasons. Underpinning both good and bad reactions, we believe are fundamental misunderstandings of the aims, methods, and value of systems mapping, and an underappreciation of the variety of ideas and practice. As part of our wider commitment to, and belief in, using systems mapping approaches, we felt it was worthwhile shining more light on these methods. In turn, more selfishly, we hoped this would improve our own knowledge and practice, and help us advocate better for PSM!
PSM has evolved a lot over the last ten years, both in simple terms—what we call it and how we frame it—and in how maps are built and how they are analysed. We have tried to find the spaces between what other methods do well, but also to include the ideas and learning from the many people we have worked with using PSM. We have also tried to stay true to our underlying philosophy of a participatory and humble approach to interacting with and managing complex adaptive systems, and to our core idea for PSM - to turn potentially overwhelming complexity (in systems, and in our models of them), into something more actionable, practical, and usable.
We could write reams and reams about PSM; indeed we have in many different places, but here we will attempt to be disciplined and stick to explaining as simply as we can: what it is and how you can use it, common issues and tricks of the trade, what it is good and bad at, and a brief history of how it has evolved. Finally, we will point to some resources for getting started yourself.
What Is Participatory Systems Mapping?
PSM is the process of building, analysing, and using PSM maps. The maps are causal models of a system, represented by a network of factors and their causal relations. They are almost always annotated and layered with information about the factors and their connections. Technically speaking, they are directed cyclic graphs, that is, the connections between factors have arrows and there can be feedback loops in the network. The maps are built by stakeholders, typically through a series of workshops and meetings, and the participatory nature of their development is paramount. So too is the approach to analysis, which uses information from stakeholders, the principles of network analysis, and looks at the ‘flow’ and chains of causal relationships (which we often refer to as ‘causal flow’) to create submaps focused on exploring specific questions or purposes, again in a highly participatory and iterative manner.
Let’s look at an example to get a feel for the basics of what makes a map. Figure 5.1 shows both a full map, which is too large to read on the printed page, and a zoomed-in subsection, so that we can see the detail. Nodes can be from any relevant domain; they need not be explicitly quantifiable or have data underpinning them, but should be expressed as variables, that is, things in the system that can increase or decrease. The nodes in the map are called ‘factors’, and there are often special types of factors such as outcomes or functions of the system we care about, or interventions we control. In Fig. 5.1, there are intervention-type factors coloured in blue and function-type factors in green.
The connections in the map represent causal relationships. These can either be positive causal connections (i.e. if A increases, or decreases, B changes in the same direction), negative causal connections (i.e. if A increases, or decreases, B changes in the opposite direction), or uncertain or complex connections (i.e. if causal relationships depend on other factors or contexts, or if the relationship is strongly nonlinear).
In PSM maps we are normally aiming to build reasonably large networks with at least 20 nodes, often more like 50 or 100. The number of connections is then usually several times larger, running into several hundred on some occasions. Because the analysis approach is centred on creating submaps, and thus we are not too worried about having large maps, the only hard constraint on the size of PSM map is time. Building large maps may require the process to be designed to have parallel streams creating different maps which are then brought together.
The maps are intended to be ‘owned’ by the stakeholders who create them, rather than researchers. They should capture all the complexity important to stakeholders and should use annotations and labels to represent any different beliefs. The final layout of a map can take many forms; sometimes it can recreate the layout that emerged in a workshop, or be rearranged thematically, or a network visualisation algorithm can be used to highlight patterns in the network structure.
Once a map is built (though they are often never really ‘finished’, we can always add more), we can analyse it. At the core of the approach to the analysis is the idea of creating submaps, that is, subsections of the full map, which we can use to focus in on particular questions or issues. The submaps are intended to allow us to get a handle on the map; they offer us a way in, to what can be an overwhelmingly large diagram. The question now becomes, how do we pick where to extract a submap and what do we include and exclude from it?
The starting point for a submap can be defined either by ‘stakeholder-suggested’ factors, that is, what factor(s) stakeholders have told us are important, that represent their suggested or current interventions, or that they think are vulnerable to change. Or we can start with ‘system-suggested’ factors, factors that different types of network analysis (e.g. centrality measures) tell us might have interesting properties in the network. For example, we might have factor with many connections, or a factor which bridges different parts of the map.
Once we have a starting point, the analysis uses one (or a combination) of the following ‘rules’ to generate a submap: one, two, or three steps ‘upstream’ or ‘downstream’ (i.e. following the arrow directions) of the starting factor; ego networks of the starting factor (i.e. any nodes and edges connected to it and the edges between them); or paths between multiple factors of interest (i.e. following the arrows from one factor to the next until we reach the other factor of interest). Figure 5.2 shows how these are defined visually. These rules for generating submaps can themselves also be combined using unions or intersections (i.e. showing multiple submaps together or showing the nodes and edges that are in multiple submaps). We might do this if we want to look both up and downstream from a node of interest, or if we want to see where the ego networks of different nodes overlap. These various approaches to analysis are summarised in Table 5.1.
As the example above and description of analysis shows, the subjective information we collect on factors (i.e. what is important to stakeholders, what is vulnerable, or controllable) is incorporated into analysis. When combined with network analysis this provides different insights. For example, an influential (high out-degree) factor, which impacts many important functions, is obviously significant. However, if it is vulnerable to change or controlled by an external actor, it may be a vulnerability. Whereas if it is controllable, it may be an opportunity to make change, a so-called system lever. Different types of information can be collected depending on what is relevant to the system and stakeholders. Analysis is also often combined sequentially, with one submap generating questions that lead to the creation of another. In practice, the process of generating submaps is a creative, iterative, and exploratory exercise, ideally done with stakeholders. It can be modified and recombined in numerous ways to address the questions that matter to participants.
There is a reasonable amount of variety in how PSM is used, but this normally stems from the needs and purpose of any given project, rather than different perspectives on how to use the method. Examples of variety include (i) different types of information collected about nodes and edges, such as edge weights, different classes of nodes, or more detail about complex causal relationships; (ii) differences in how a PSM process is designed, with almost infinite options of how to organise sequences of workshops, meetings, and interviews; or (iii) differences in how a full map is connected to other models or forms of knowledge (e.g. using a left-to-right inputs-to-outputs-type layout to make it resemble a Theory of Change map). In terms of terminology, there is not too much variation. PSM maps are not known by another name, but the phrase ‘Participatory Systems Mapping’ is quite generic, so we have seen it used in a more high-level way to refer to different methods such as Causal Loop Diagrams or bespoke system mapping efforts that emphasise participation.
How Do You Do Participatory Systems Mapping?
We have previously written detailed guidance on how to run workshops (see Barbrook-Johnson & Penn, 2021; Penn & Barbrook-Johnson, 2019) and how to design and conduct a whole PSM project (see Penn & Barbrook-Johnson, 2022). Here, we will attempt to outline the entirety of the process, in a succinct form, and suggest you check our fuller writing on these topics for more detail. The exact nature of your process will depend on the purpose of your project, and you should be creative and flexible in designing a process, while always erring on the side of doing more participation, rather than less.
We would expect to see the following basic stages in almost all PSM processes (note, we will assume that all are done with stakeholders right from the start):
Deciding on aim of project: There are multiple purposes which a PSM process could be used for, for example, solving a problem or asking a question about a system; designing new interventions for, or uncovering vulnerabilities in, a system; building engagement and shared understanding and ownership of an issue amongst stakeholders; or allowing marginalised perspectives to be communicated to powerful actors.
System definition/boundary: A system boundary needs to be set to make mapping focussed. The system could be a particular physical system, for example, a water catchment, or a more conceptual one, such as a policy domain. You should decide on the problem area you wish to explore. The system will then be defined by this problem or questions around it, and what impacts on it. This task is often one of the most conceptually difficult and can have a huge impact on the project.
Choosing stakeholders: It is important to bring in stakeholders to cover all key parts of a system. You should consider who affects or is affected by the system; who has on-the-ground knowledge and who has a strategic overview; who is often overlooked; are there provocateurs who could usefully be invited to challenge established narrative? The process can be narrowed by reducing diversity of stakeholders, but with a cost to system representation. A useful strategy for individual sessions is to keep group size small but maintain diversity.
Process design: you should begin mapping in groups to produce at least the first full version of a map. This is to ensure that the benefits of collective model building are achieved. The ideal is that a mixed group with representatives of all stakeholder communities is present for this workshop. When this is not possible, sequential workshops can be run which build on maps step by step. Many of the other steps detailed below can be performed outside workshops if it is helpful.
Choosing focal factor(s): Focal factors are usually outcomes or ‘functions’ of the system and are the first nodes laid down in the construction of the map. Choosing the right focal factor(s) is key. They strongly affect the focus of a systems map. Try to ensure all aspects of a system you are interested in are covered. Think about what is important to who. If some groups are not represented, you should ask participants to consider things cared about by these absent groups.
General factors: once we have focal factors, we ask participants to brainstorm factors which are influenced by or influence them, and then bring these together and consolidate. The key criterion for including factors is that they make a difference to how the system works. It is important that a wide brainstorming happens so that we ensure that all domains of influence are covered.
Building the map: the mapping process essentially consists of drawing causal connections between factors. Starting from the focal factors and then bringing in the general factors. The process is often staged to facilitate better system thinking. For example, in a map containing outcomes, general system factors, and policy interventions, all outcomes and the general factors which impact or are impacted by then are mapped first, with policies only added at the end. This is to prevent using familiar, but perhaps inaccurate, linear models of change.
Factor and connection information: once a map structure is created, it is vital to make sure all the appropriate information on factors and connections has been collected. Some information, such as factor types (e.g. interventions, outcomes, functions), is collected throughout, but a time to gather additional information at the end is useful too. For example, which factors are controllable, by who and to what degree, which are vulnerable to particular changes, and which are ‘owned’ by different stakeholders. You might also ask stakeholders for any other categories they think are relevant. Equally, for connections, we should consider is there any extra information we would like to collect.
Verification and review: we expect to go through several rounds of mapping followed by verification and review. Verification and analysis bring up new aspects of the system and prompt reconsideration of the structure of the map. A stable version of the map should be reached after a few iterations; however, in the longer term, maps should be treated as updatable living documents.
Analysis design: analysis should be considered from the start of the process as the information collected and how maps are built is usually modified to allow the analysis that is most relevant to stakeholders. We can ask a variety of questions with analysis, for example, what are the potential influences on outcomes, are they vulnerable or supported; what are potential unexpected impacts of external change, or of planned interventions; are there co-benefits or negative indirect effects; are there trade-offs between different stakeholders’ interests; are there interactions between different interventions, synergies, or clashes; are there interactions between planned interventions and other potential changes or risks. If mapping is being used to design interventions, we can use the map to consider which points of intervention would have most beneficial impacts and for who and are controllable by those wishing to act. If we want to uncover vulnerabilities, we can consider which factors have the most impact on functions that matter to different groups. When preliminary analysis is done, at every stage, stakeholders should also be asked to reflect on what is surprising or interesting in the map, and what questions to explore in further analysis.
These stages in each project will be different, and we often find we iterate between them rather than following them in a dogged sequential order.
Common Issues and ‘Tricks of the Trade’
We have bumped into many issues. Some of these we have learnt to circumvent purposefully, others we likely do subconsciously. The following issues are ones we have seen most often or felt most acutely. First, the most fundamental and most common confusion people have about the ‘rules of the game’ for building a PSM map is what ‘positive’ and (especially) ‘negative’ connections are. Sometimes people think of connections in a normative way, so a positive connection thus means ‘this factor is good for that factor’, or ‘this factor influences that in a desirable direction’, and conversely, a negative connection comes to mean something like, ‘this factor pushes that factor in the wrong way’. It is important to be aware that this might happen and be alert to how connections are being understood and added, questioning when necessary.
A second issue during the early stages of a workshop can be the feeling that the beginning of the mapping process is slow and can start to feel like it will never be finished. This is totally normal. Early discussions on definitions and purpose, and on consolidating individual brainstorming often take up most time in a first mapping session. Once this is done, a session can rapidly accelerate so that people are building the map at a frantic pace, and the problem can flip; you end up being concerned there is not enough discussion. More generally, a sense of being overwhelmed by a map as its starts to get larger, is normal. We have heard of many people starting to use similar system mapping methods and giving up when they feel the sheer weight of the map, and uncertainty on what to do next, become too problematic. One of the most common complements we get is that we persevered when things looked stuck or too ‘hairball-ish’.
On a more conceptual level, we have found it is often difficult to convince stakeholders and users, of both the value a PSM process could deliver for them, and how the analysis will work. The fact that the direction the analysis will take is not clear at the start compounds this issue. It can be hard to show examples because the analysis is bespoke, and much of its value is in iterating through version of submaps and interpretation, rather than just looking at a final version.
To overcome these, and other issues, we have regularly used the following ‘tricks of the trade’:
Be clear about the ‘rules of the game’ from the start: it is well-worth spending an extra ten minutes at the start of workshop explaining the definitions of nodes and edges clearly, rather than discovering two hours in that people were misusing them.
Always ask people to explain: your most powerful prompt during a workshop is ‘could you explain that a bit more please?’ Do not worry about looking stupid or not knowing the system in question; you are not the expert, the stakeholders are. This will encourage discussion and precision in thought and will surface assumptions and disagreements. It will help you work out when one connection would be better shown with three, or where a connection should be marked as complex.
Encourage people to take control: as a facilitator, it is hard to overcome the feeling that you should be in charge of the process of building a map. Things can start this way, but it is usually possible for participants in a workshop to start to take over both the act of drawing and moving nodes and edges, and to lead the conversation (though, we have found working online this is harder to do). This should be encouraged from early in the process. Your role as facilitator thus becomes to ensure the map is sticking broadly to the rules of PSM and is coherent with any agreed aims or purposes.
Keep the whole in mind whilst working on details: it is important that you keep in mind the whole system map that you are aiming for. You want a map that covers all the major areas in equivalent depth, and where distal connections are made between factors that are far apart. You will need to keep in mind the shape, balance, and connectivity as the map as a whole as well as being alert to what is happening on the microscale of local connections. ‘Zooming in and out’ cognitively, and prompting participants to do the same, particularly when stuck, is an important part of a mapping process.
Do not put pressure on the process to finish soon: this is tricky as it involves both managing the expectations of people involved and avoiding letting yourself feel the need to finish soon. PSM is inherently an iterative process. The map will change and be refined and may never feel finished. You need to make your peace with this fact; if you chase after a false sense of completion, you will likely just feel ever further from it, and become disheartened. If you are patient, allow yourself to stop, work on something else, and return with a fresh mind, you will almost always find productive ways forward.
Introduce analysis early: though the analysis stage does not start until you have a map you do not think is going to change lots anytime soon, it is useful to introduce the idea of analysis early and gather ideas for what could be done. Show people the sorts of analysis that are possible. This allows people involved to have a sense of one of the key ways you will use the map and allows you to tailor the process considering their comments and ideas. The reconfigurable nature of the analysis means that people can often come up with their own ideas once they have grasped the general principles.
What Is Participatory Systems Mapping Good and Bad At?
PSM is likely to work best when we want to use systems mapping in a relatively participatory, inclusive, and flexible manner, but when we also want the structure given by clear definitions of how the model works and how it can be analysed. Importantly, it offers this formalism in contexts where we either don’t have data to set up or validate a model, or where we are not confident we have sufficient understanding to turn a system map into a dynamic simulation. It is also directly aimed at capturing the full complexity of a system, but then finding ways to make this understanding practical and actionable using analysis. It is aimed at finding solutions to the common critique of system maps as ‘horrendograms’ but doing this without compromising on depth. Thus, we see PSM as sitting quite squarely in the middle of the spectrum between flexible and qualitative methods, and more formal quantitative methods.
Where PSM is less useful is when we find ourselves wanting to be at either end of this spectrum. If we want a method that is highly intuitive and allows people to engage on any level they wish, PSM will be inappropriate. Conversely, if we want to quantify our model, or have a dynamic model, PSM won’t be the best bet. Probably its single biggest weakness is its inability to explore dynamics in systems; it is a relatively static method.
A Brief History of Participatory Systems Mapping
Our work with systems mapping really started with Fuzzy Cognitive Mapping (FCM) and the project presented in Penn et al. (2013). We found the overall approach of FCM created a lot of value for stakeholders and opened interesting avenues for research. However, we had concerns about how the analysis in FCM is sensitive to many subtle assumptions. In particular, the functions specified for how a change in one factor affects the next. Being sensitive to assumptions is not in itself a problem, this is true of many modelling approaches, but here, assumptions made by the researcher often had a greater impact on results than stakeholder input. Great care must thus be taken for analysis to produce outputs that were meaningful, and the risk of overinterpreting model artefacts increases. We felt this had the potential to constrain the participatory element of FCM and limit the co-design of the analysis. Thus, we started to explore the question of how we could analyse these types of complex system maps in a way which was less sensitive to assumptions, but which was also more transparent, intuitive, and participatory in nature.
The idea of using network analysis and causal flow emerged (see Penn et al., 2016) and this has been refined and extended through numerous projects since. These projects have tended to be with stakeholders from the public sector, so the approach has naturally pivoted to thinking about interventions and their outcomes, despite our aim of using the method to instil wider systemic thinking. This has become one of the main sites of innovation in map building, finding ways to encourage system-wide thinking and analysis, while keeping time-poor and objective-focused stakeholders interested.
Getting Started with Participatory Systems Mapping Yourself
So far, we have avoided the topic of software to use for PSM, however, picking the right software for you will be key to your success. There is a wide array of options, which fall into three types: general purpose diagramming software; network visualisation and analysis software; and purpose-built software. Table 5.2 outlines some of the pros and cons of each of these and mentions some examples. In practice, you might want to use two or more pieces of software for different purposes; if you do, you should have a plan for how you will export your map from one to the other—you do not really want to have to manually create your map twice.
Here are a few further resources we would recommend:
Detailed workshop guide: Penn and Barbrook-Johnson (2019) outlines a detailed guide to facilitating a workshop, covering all the key stages you may need to include. If you are planning a workshop, we recommend using and adapting it to your needs.
Detailed Process Design Guide: Penn and Barbrook-Johnson (2022) provides in-depth guidance on how to design a full PSM process to best fit with a system and stakeholders’ challenges and blind spots.
Centre for the Evaluation of Complexity Across the Nexus (CECAN) PSM briefing notes: there are three short and accessible write-ups of some of the larger projects we have used PSM in, in briefing notes published by CECAN (see Barbrook-Johnson, 2019, 2020; Barbrook-Johnson et al., 2021). These can be useful to share with prospective participants.
Academic examples: a subset of these is written up in Barbrook-Johnson and Penn (2021) in longer academic journal paper form.
You should now have everything you need to get out and start your own PSM project. We cannot emphasis enough, your priority should be ensuring you have good engagement from a set of stakeholders or a user for the work. It is important to get this lined up before doing much else because the aims and design of the project will depend on them. Beyond that, we would recommend a key first step is finessing your thinking about how a PSM process is going to be of value to them, how it will connect to their existing work, and how you are going to design it to maximise chances of success. Think about these sorts of questions before you think about the methodological details of map construction and analysis, so that the real strength of this method—bespoke map construction and analysis design that provides meaningful and actionable insights—can be fully exploited. Good luck!
Barbrook-Johnson, P. (2019). Negotiating complexity in evaluation planning: A participatory systems map of the energy trilemma. CECAN EPPN No. 12. https://www.cecan.ac.uk/resources
Barbrook-Johnson, P. (2020). Participatory systems mapping in action: Supporting the evaluation of the renewable heat incentive. CECAN EPPN No. 17. https://www.cecan.ac.uk/resources
Barbrook-Johnson, P., & Penn, A. S. (2021). Participatory systems mapping for complex energy policy evaluation. Evaluation, 27(1), 57–79.
Barbrook-Johnson, P., Shaw, B., & Penn, AS. (2021). Mapping complex policy landscapes: The example of ‘Mobility as a Service’. CECAN EPPN No. 18. https://www.cecan.ac.uk/resources
Bromwich, B., Penn, A. S., Barbrook-Johnson, P., & Knightbridge, J. (2020). Systems analysis for water resources: Final report. Defra report. http://randd.defra.gov.uk/ (search for WT1512)
Penn, A. S., & Barbrook-Johnson, P. (2019). Participatory systems mapping: A practical guide. CECAN toolkit. https://www.cecan.ac.uk/resources/toolkits/
Penn, A. S., & Barbrook-Johnson, P. (2022). How to design a Participatory Systems Mapping process. CECAN toolkit. https://www.cecan.ac.uk/resources/toolkits/
Penn, A. S., Knight, C. J. K., Chalkias, G., Velenturf, A. P. M., & Lloyd, D. J. B. (2016). Extending participatory fuzzy cognitive mapping with a control nodes methodology: A case study of the development of a bio-based economy in the Humber region, UK In Including stakeholders in environmental modeling: Considerations, methods and applications, Ed. S Gray, S Gray, R Jordan, M Pallisimio
Penn, A. S., Knight, C. J. K., Lloyd, D. J. B., Avitabile, D., Kok, K., Schiller, F., Woodward, A., Druckman, A., & Basson, L. (2013). Participatory development and analysis of a fuzzy cognitive map of the establishment of a bio-based economy in the humber region. PLoS ONE, 8(11), e78319. https://doi.org/10.1371/journal.pone.0078319
© 2022 The Author(s)
About this chapter
Cite this chapter
Barbrook-Johnson, P., Penn, A.S. (2022). Participatory Systems Mapping. In: Systems Mapping. Palgrave Macmillan, Cham. https://doi.org/10.1007/978-3-031-01919-7_5
Publisher Name: Palgrave Macmillan, Cham
Print ISBN: 978-3-031-01833-6
Online ISBN: 978-3-031-01919-7