We hope you have found this book useful, despite its faults, and maybe even enjoyed bits of it! Ultimately, this is how we feel about systems mapping. We know that all models, and thus system maps, are not perfect; indeed, we should expect them to be wrong in some sense—they are simplifications of reality, with many judgements and assumptions used to cut the corners that create the simplification. They will have faults. We should not penalise systems mapping on this point. Rather, where we must be strict is in ensuring that system maps are useful. Either the process, the outputs, or both, of systems mapping must be useful for us and/or our stakeholders. It is this that you must keep forefront in your mind when designing and implementing systems mapping processes, and we hope this book will help you to do this.

Now indulge us in reflecting on what we have learnt by writing this book and some of our final few morsels of (subjective) advice.

What Have We Learnt Writing This Book?

We have both learnt a huge amount preparing and writing this book; from one another, from our reading, and from interviews with experts on individual methods. Systems mapping, and its related methods, concepts, and schools of thought, is a messy space. There are multitudes of definitions and overlapping ideas, subtle differences in approach, and sweeping assumptions. We had underestimated this before; we did not know the waters were shark-infested! This makes it an exciting space to work in, with many different fields and approaches within touching distance, but also a difficult one to navigate. This can be frustrating and off-putting, but the quality, usefulness, and fun of using many of the methods here keeps pulling us back. We truly believe all the methods in this book are valuable in many circumstances, and are, on the whole, under-used in research and practice. We feel better placed to navigate this space having written this book, we hope you do too having read it.

Our Final Take-Home Messages

We have tried our best to be practical in how we have presented the methods in this book, but it is probably worthwhile rehearsing a few final takeaway messages we encourage you to carry into your own work:

  • See system maps as living documents: always try to build in a legacy for your work by having a plan for how your map can be maintained, updated, and re-used in the future. This need not be a fancy web-interface presenting your map but more often can be the capacity and skills you help create in a stakeholder team to continue the work themselves.

  • Be clear about whether you want value from the process, outputs, or both, of a mapping process: value can come from the process of building a map (i.e. the discussions generated through building it, and the knowledge and mutual understanding this creates), from the analysis and use of the outputs of a process (i.e. the map itself, the narratives, insights, and knowledge it generates), or from both. You need to be clear on where you hope to get most value from systems mapping and manage expectations of stakeholders. We find we often expect much more value in process than the stakeholders we work with, who are often surprised just how much they gain from this. The opportunity to reflect and generate understanding with others is surprisingly powerful. Often more so than delivering ‘answers’.

  • Climb the ladder of using methods: imagine a short and stubby ladder with three steps, let us call this the ‘ladder of using methods’. If you embark on climbing this ladder, first, you learn a method, and then want to apply it to everything and anything. You have your hammer, and now everything looks like a nail. On the second step, you become more aware of some similar methods to ‘yours’, perhaps ones you even used to see as competition, but now are more sanguine and maybe even know broadly when they should be used instead of ‘your’ method. On the third step, you have mastered some more methods, and now you can apply these too, but more importantly, you now understand the detail and nuance of how each method operates and so can make informed decisions, with stakeholders, about what to use and when. We highly recommend you try to climb this ladder!

  • Decide whether you want to prioritise participation or conceptual rigour: in an ideal world we could do deeply participatory work which also produced models which were completely conceptually and scientifically sound. In practice, this is rarely possible. Stakeholders will want things included which a neutral ‘expert’ wouldn’t, and they will often lead you off on tangents. This impedes your ability to make the model design decisions needed to make a model conceptually and scientifically sound from a traditional modelling perspective. We need to acknowledge, accept, and plan for this, and again make sure our stakeholders understand this too.

  • Advocate for participatory steering of complex adaptive systems: the philosophy that underpins much of our interest in systems mapping is that we need ways of knowing and acting in the world, that are deeply participatory, holistic, and systemic in their scope, and humble in their attitude. We must accept that we cannot force or control the complex adaptive systems we live in and make up, but we can work with them to steer and nurture the change we want. We hope using systems mapping allows you to adopt this underlying worldview in your work.

Final Thoughts

Thank you for reading this book, and good luck with your systems mapping endeavours. We are always keen to hear about others’ adventures, so do please get in touch!