When you’re making a system map in Kumu, it’s important to have skill and familiarity with the tool itself, but it’s equally important to have an understanding of the concepts of systems thinking.
You can learn these concepts and learn Kumu at the same time if you follow the Systems Practice methodology developed by The Omidyar Group. When we’re mapping systems ourselves, teaching systems skills, or simply brushing up on our own skills, this methodology is one of our all-time favorites.
Notably, though, the Systems Practice methodology is time-consuming. The workbook itself is nearly 100 pages long, and it mandates weeks, if not months, of study and stakeholder engagement.
For serious system mapping work, spending this much time studying, thinking about, and mapping your system helps ensure you are addressing root causes rather than instituting quick fixes. In the long term, the time and resources you invest in Systems Practice will pay dividends.
But what if you’re not quite sold on the Systems Practice methodology yet? What if you haven’t encountered systems thinking before and just want to dip your toes in? Or what if you’re an expert or an educator with only a few hours to introduce Systems Practice to a fresh new group of systems thinkers?
At Kumu, we face this problem all the time! Whether we’re doing a product demo, giving one-on-one support to Kumu users, or leading day-long trainings, we rarely have more than a few hours to introduce Systems Practice, introduce Kumu itself, and get as close as possible to the first draft of a system map.
Give those constraints, and after plenty of trial and error, I’ve settled on an abridged version of Systems Practice that fits comfortably into a 2–4 hour session. In this article, I’ll share the main concepts and activities that comprise “Systems Practice, Abridged,” organized into the following sections:
- What is a Systems Practice?
- The power of mapping with Kumu
- Applying systems thinking
- Incorporating others’ perspectives
- Leverage and learning
What is a Systems Practice? (15–30 mins)
Under time pressure, I gravitate toward a short and snappy definition of Systems Practice:
Systems Practice is a methodology for solving complex problems.
This definition is such a barebones collection of words that, at first glance, it hardly seems to do justice to the power and promise of Systems Practice. But, digging deeper, I think it unpacks nicely:
Systems Practice is a methodology…
Systems practice is decidedly not a simple tactic; it’s not something you can accomplish in a day; it’s not a band-aid or a quick fix. It’s a methodology composed from a full suite of techniques for studying and describing complex systems, then identifying appropriate actions to take to ensure that certain system dynamics persist and others fade away.
…for solving…
Systems Practice has a clearly defined outcome: solutions to your problem. Gaining knowledge and insight is a beautiful thing. I have a huge soft spot for research, data collection, experimentation, and analysis, but even I know that knowledge without practical action won’t help us address the major challenges of this century and beyond.
…complex problems.
Systems practice isn’t appropriate for all problems! It’s appropriate for complex problems, which you can identify by looking for the following characteristics:
- Understanding of the problem is low.
- Consensus about what to do in response to the problem is low.
- The problem is not self-contained. It’s intimately connected to a dynamic and changing environment that is outside of your control.
- Your intention is to make long term change rather than achieve short term goals.
The power of mapping with Kumu (30–60 mins)
A system map is one of the main deliverables that Systems Practice produces, and its purpose is not only to help you understand the context and identify potential solutions, but also to document your thoughts and decisions along they way.
Kumu is a tool for creating digital system maps that not only show the intricate structure of systems, but also allow you to create profiles, rich with metadata, for each of the factors, connections, and loops in the system. This approach encourages you to draw conclusions from the overall structure of the system, but still provides a great home for more precise information gathered from people with real-world experience in specific areas of the system.
As you implement a long-term solution, you’ll continually be able to return to the map to remember why a certain process or program was put in place, how small actions relate to the bigger picture, and what assumptions did or did not factor into the original decision-making process. Very important stuff!
That said, you don’t have to be a Kumu expert before you start working through the Systems Practice methodology. If you’ve never used Kumu before, there are only a few basic concepts you need to know that will help you dive in — I like to call this collection of concepts “Kumu 101”:
How do I get started with my first Kumu project?
I recommend working through our First Steps guide, which goes through everything you need to know to hit the ground running.
The First Steps guide will teach you how to pick a template, how to start building your system inside the map, how to design and customize the map, and how to invite other people to help you out.
Where can I go to learn more about Kumu?
To help you learn more about Kumu, we put together some great resources. First and foremost is our documentation website, where you can find guides on everything there is to know about Kumu.
You can also subscribe to this blog, check out the In Too Deep podcast, and follow us on Twitter, Facebook, and Linkedin!
If I get stuck, where can I go for help?
If you get stuck and need advice, feel free to email us at support@kumu.io, or post in our public Slack workspace at chat.kumu.io. And if you have awesome work to share, we’d love to see it in either of those channels!
For more info and inspiration on what I like to cover when introducing Kumu and system mapping, check out our blog post on Kumu 101.
Applying systems thinking (30–45 mins)
If system mapping is the science of Systems Practice, systems thinking is definitely the art. Identifying a system’s factors, relationships, and feedback loops, with all of their categories, subcategories, archetypes, and metadata, is a complex process and will be a unique experience for each individual system you study.
Even so, there are a few tactics you can use to apply systems thinking and extract factors, relationships, and loops more quickly:
Define a guiding star and a near star
Your guiding star (you’ll likely have one) is the answer to the question, “What healthy, future system is your team passionate about working toward?” and your near stars (you’ll likely have more than one) are the answers to these questions:
- What have you learned about how to be effective in your sector? For example, what have you learned about how to counter human trafficking/ slavery?
- What outcomes are most important to your organization? For example, do you have organizational beliefs or values that cause you to prioritize specific populations or parts of the world or communities?
- What sub-sectors or outcomes play to your team and organization’s strengths (e.g., capacities, knowledge, networks)?
- What trends, research/new findings, or bright spots have you seen that point to promising approaches?
Another helpful framing idea: your guiding star is a broad, ambitious goal that will take 7–10 years to achieve, and near start are impactful but narrower goals that take 3–5 years to achieve.
Your guiding star and near star will often become the first factors that you add to your map.
Start with abstract categories, then get more specific
In the System Practice workbook, there’s a great activity that involves identifying “enablers” and “inhibitors” in your system. The workbook gives excellent definitions for these terms, so I’ll quote directly:
An enabler is a significant force in the environment that supports, encourages or increases the health and effectiveness of the system as defined in your guiding star.
An inhibitor is significant force in the environment that undermines or prevents the health and effectiveness of the system as defined in your guiding star.
In my experience, the “enablers vs. inhibitors” categories are superbly useful, but not necessarily because those categories exist in every system. Rather, the simple act of defining any abstract category of factors makes it easier to fill up the map with concrete examples.
Use the enablers/inhibitors dichotomy, or come up with your own categories (e.g. political, economic, social, environmental, and technological), then let those categories guide you toward specific factors that actually exist in your system.
Pro tip: If you’re adding factors to your Kumu map while you brainstorm, take a second or two to open the profile of each factor after you create it and add its category to the “Type” field (just underneath the label). Or, if your factor can fall into more than one category, add all of its categories as Tags:
Write a few paragraphs describing the essential narrative(s) of your system
Tell a few stories about your system, describe both the challenges you perceive and their potential solutions. If you’ve already added some factors to the map, incorporate those factors into your paragraphs.
Once you’ve written your paragraphs, the real work begins: translating your words into cause and effect relationships. There’s a trick to doing this well: the relationships will be hidden in the the verbs you used to describe your system.
Some relationships will be easy to find:
- Factor A increases the likelihood of Factor B
Given that sentence, you can confidently draw a connection from Factor A to Factor B on your map. But in real prose, causal relationships will usually be a little more difficult to find — they’ll be spread across multiple paragraphs, hidden by fancy sentence structures, or split up by interjections and asides. They’re also likely to use more creative words than “increase”, for example, “A is key to B,” or “In order to have Y, we need to have X first.”
If you get stuck on a factor that doesn’t seem to have any connections, just ask yourself:
- What increases/strengthens/leads to/creates this factor?
- What decreases/weakens/detracts from/destroys this factor?
Each new answer you find will be another connection for the map.
Look for loops
Colloquially, you can use the word “loop” to describe any kind of line that curves around in a circle or an oval. When you’re mapping systems in Kumu, you’ll find many groups of connections that meet that definition, but they aren’t necessarily the loops that a Systems Practitioner is looking for.
In a system map, my litmus test for discovering loops is to ask the question, “If I follow the arrows in this group of connections, can I get trapped?” If the answer is yes, I’ve found a loop, if not, the structure is not a loop, but might still be complex enough to deserve some further study.
Here’s an example of a structure that looks like a loop, but is not, because no matter which arrow I follow, I always end up at the same factor, escaping the trap:
On the other hand, if I reverse just one of the arrows in the structure, I inevitably get trapped going around and around in a circle:
This is the kind of loop we’re looking for in Systems Practice. It’s rarely so simple — in many cases, your loops will contain more than three connections, and they likely won’t be laid out in such a nice, circular shape.
But, after you’ve gotten a few practice rounds under your belt, I’m confident that you’ll have no trouble picking out groups of connections that cycle you through the same factors, over and over again, repeating the same dynamics, cycling through the same factors, over and over again, repeating the same…ahem. Moving on!
Incorporating others’ perspectives (45–90 mins)
If you’re going solo on your system map, hats off to you! It takes guts to try and understand a complex system all on your own. We invite you to return to this article anytime you need some extra guidance, or, if you need help, reach out to us in our public Slack workspace at chat.kumu.io.
If you’re working with a team, you can incorporate their perspectives into your Systems Practice with a simple team activity:
- Designate someone to be your Kumu mapmaker. This person should have a solid grasp on the concepts covered in the Kumu 101 section of this article.
- Everyone else can take turns identifying factors, connections, and loops in the map, using the tactics described in the Introduction to Systems Thinking section of this article, while the designated mapmaker adds them into the Kumu map.
I’ve found that it’s fun and helpful to set a limit on how much each person can contribute — for example, set a rule that each person can add 3 items (i.e. factors or connections) to the map, or they can take a stab at identifying and naming one loop. After someone hits their limit, move on to the next person and get a fresh perspective!
Leverage and learning (30–90 mins)
If you work through everything I’ve outlined in this article so far, you’ll have completed only two of the five total sections in the Systems Practice workbook. Clearly, there’s much more work to do!
The final three sections of the workbook teach you how to:
- Identify actions you can take to make change in your system
- Strategically take those actions
- Learn from the results of those actions
- Adapt for the future
This work is very complex and important, and it’s arguably irresponsible to undertake it after only a few hours of systems study. But, in your abridged Systems Practice session, I do think it’s possible to sketch out an action plan, if only to familiarize yourself with the remaining steps of the process.
With that in mind, here are a few practical things you can do with your remaining time:
Identify leverage opportunities
In the context of Systems Practice, a “leverage opportunity” is an action that strikes a balance between feasibility and long-term positive impact in your system.
Explore that thought for a moment: acknowledge that there are many possible action you could take that will affect your system. Some of those actions require very little investment of time, talent, money, technology, or any other resource you have access to, and some require much more than the resources that are available to you. Some of these actions will create huge positive impact, some will create small positive impact, and some may even create negative impact.
More often than not, the actions that create the largest and most positive impact are also the least feasible.
To identify leverage opportunities, start by brainstorming actions you could take, anywhere in the system. Once you have a robust list, evaluate each action, and make explicit predictions about what type, quality, and quantity of resources each action requires, as well as what size of impact each action will make, and what potential ripple effects it might cause.
Narrow your list of actions down to include only the ones that seem to strike a balance between feasibility and impact. Remember that this is a judgement call —your system map and your feasibility & impact predictions can guide you, but at the end of the day, only you can decide which actions are worth pursuing!
Make a measurement and learning plan
You now have some pretty detailed predictions about how your leverage opportunities will affect you and your system, but how will you know if they come true? By measuring the effects!
In any system, the first actions you take are almost always imperfect, and you’ll need to learn from those imperfections, then pivot and adapt. Before taking action, you’ll want to have tools and processes in place to measure the effects, so that the next iteration will be even more successful.
Remember, the basic metrics we’re interested in are:
- What type, quality, and quantity of resources each action requires
- What magnitude of impact (positive or negative) each action will have
- What results will emerge from the ripple effects caused by your actions
You can definitely add to that list as you see fit; every system will have unique measurement needs.
Once you know what metrics you’re interested in, commit to measuring them regularly — keep a journal, make a spreadsheet, talk into a tape recorder, build a robot that follows you around and watches everything you do — whatever it is, just make sure you’re measuring!
Most importantly, make an effort not to take these measurements alone. They are often subjective and tricky to pin down, so be sure to work with a team, interview stakeholders, and in general, involve other people and their perspectives in the measurement process.
Get ready for round 2!
I mentioned that Systems Practice is a methodology for solving complex problems, but you should also know that it’s a cycle.
As you act upon your system, you’ll change it, and those changes can be drastic, extremely subtle, or anything in between. When you observe changes in your system, you should return to your system map and update it to reflect the new real-world dynamics. After you update your map, you’ll of course need to rework your leverage opportunity predictions, and you may need to update your measurement strategy, too.
In short, the Systems Practice methodology requires that you continually revisit its techniques and tactics in order to adapt to your changing world.
That’s the essense of Systems Practice, Abridged! The full Systems Practice workbook is extremely well designed and well written, so we recommend working through it when you have time, but we hope that Systems Practice, Abridged can serve as a comprehensive overview for you or for any soon-to-be systems thinkers you’re teaching.
If you’d like to dig deeper into Systems Practice we encourage you to enroll in the Systems Practice course on +Acumen!
Originally published at Kumu.io
Frontend Developer at Kumu
I’m passionate about software development, data visualization, and applying science and technology in the majority world