If you've read our blogs, visited our office, or been to our workshops, chances are you'll see process maps at some point. My colleague Jess wrote a great blog post about it. Process mapping is a tool that has become an integral part of a larger body of work that encompasses about a quarter of most "innovation" projects handed to us -- the problem identification phase.
I glazed over a description of this phase while talking about our broader innovation process in another blog post, but much of my work these days has been entrenched in this phase so it happens to be top of mind -- and worthwhile to talk about in city government. Whether you're a resident, a fellow city innovator, or our colleagues in another city hall office, it's important to know how we develop the recommendations we do about how to fix challenges we're tasked with solving. Much of that foundation comes from the time we invest in this problem identification phase.
It begins when we're approached with a challenge of some kind, usually from a department head or senior stakeholder. Sometimes it's "X process takes too long - can you help us improve it?" Or sometimes it's "Y is an issue in the city. Can you help us figure out how to minimize it?" While it's tempting to jump right in and suggest solutions (even if the solutions may seem obvious), there's a lot of value in digging deeper into the problem.
Firstly, this phase we call “problem identification” refers to the phase of work where we use quantitative and qualitative data to understand and get to the root cause of a problem. We engage in this part of the process for a few reasons:
It helps us avoid jumping to ill-fitting solutions.
Jumping to solutions can be dangerous because it puts us at risk of solving for the wrong problem or for something we think is a problem but really isn’t. A thorough problem identification phase prompts us to dig down to the root cause of a problem and learn about it using qualitative and quantitative data so that we know exactly which problem we’re looking to solve, why the problem is happening, and how big of a problem it is. This foundation gives us more confidence that we’re not solving the symptoms of a problem – we’re solving the root causes of the problem itself.
It helps us establish a baseline.
In the process of learning more about a challenge using qualitative and quantitative data, we are able to establish a baseline that tells us more about the state of the challenge as it exists now, how the challenge existed in the past (if we’re lucky enough to have access to that data!), and gives us the ability to set goals for where we’d like to see the state of the challenge in the future.
It helps us build relationships.
During this phase of work, we’re meeting with stakeholders who have first-hand experience with the challenge we’re looking to solve – and we’re sometimes meeting those people for the very first time. It’s very rare that any human being would be comfortable with another person coming into their workplace and immediately telling them what to change and how to change the way they do their work, so the work we do in this phase not only lets us understand more about the challenge but also about the people who we’re going to be working with for the remainder of the project. Empathy is an understated project management tool, but projects (really any interpersonal interaction, whether problem-solving oriented or not) are often much more successful when we’ve taken the time to get to know people and learn how to work together before getting to the heavier parts of the work.
It helps us get to the root cause of the problem.
In addition to characterizing the problem using data so we can accurately “describe” it, we need to be able to understand why the problem is happening in the first place. This is called the “root cause” of a problem. The closer we can get to identifying the root cause (or root causes) of a problem, the more likely we are to be able to tailor our solutions in a way that helps us eliminate or minimize the cause of the problem altogether, thus resolving the problem and the symptoms of the problem.
Below: The visual of a tree is often used to describe the relationship between symptoms, problems, and root causes. When we’re starting a new project and doing problem identification, we look at all three categories but we work hard to dig to the root cause.
Credit: Operational Excellence Consulting
HOW IT’S DONE:
Just like you would have to dig a bit to get to the underground roots of a tree, we have to dig to get to the root cause of whatever problem we’re looking to solve. We have a few “go-to” tools for doing this:
Quantitative data collection – Using numerical data to understand the “what” and “how much” behind a problem. Quantitative data, while incredibly valuable for helping us initially characterize a problem and measure progress over time, is best paired with some form of qualitative data when trying to get to a root cause understanding of a problem. All of the other methods described below are considered qualitative.
Interviews – 1:1 or group conversations with the “experts” – people involved in the process we want to improve or involved in a function related to the problem we’re looking to solve. During interviews, we look to get the story behind what we might be seeing in quantitative data. We also look to get departments' ideas on how a process or city function would look like in their ideal world. One of our favorite questions to ask is “if you had a magic wand, what would you fix?”
Shadowing – Watching other people do their work so we get a sense of how it’s done and identify things we see that could be improved. Or understand why things are done a certain way.
Process mapping – Writing out each individual step of a process or function, including decision points throughout the process. Visualizing each individual step is a helpful tool for pinpointing areas of a process that might be causing issues.
5-Why’s – An exercise where we begin with asking “why” the problem is happening. We take the answer to that and ask “why” again until we can no longer drill down any deeper. When we can no longer dig deeper into “why” something is happening, we’ve reached the root cause.
Fishbone diagramming – This is another exercise that helps us think about the various contributors to an issue by thinking about and breaking down contributing issues by category: Method, Man, Machine, Mother Nature, Materials, Measurement.
Best practices research – If there is another city that has already looked into the same issue we’re looking to solve, we don’t want to reinvent the wheel. We look to what other cities are doing, and will often have conversations with them to understand more about what they found as root causes of the challenges they have faced.
The following are two examples of projects that are currently in their problem identification phase and the tools we’re using to understand and characterize them better.
Illegal Setouts Project
The problem we were presented: There are too many illegal setouts in the city. Note: Illegal setouts is a term for trash or materials that residents or businesses set out on the curb that is either not allowed to be set out or that is set out at the wrong time. For example – setting your trash out on Wednesday if your scheduled pickup day is Friday.
Tools used:
Quantitative data analysis of illegal setout hotspots in the city.
Interviews with city stakeholders involved in citing and picking up illegal setouts
Best practices research on how other cities use solid waste infrastructure and communications to reduce incidents of illegal setouts
Process mapping of illegal setouts citation and collections processes to identify areas for improvement
What’s next:
Interviews with city residents in illegal setout hotspot areas with the goal of understanding why illegal setouts happen more prevalently in those areas
Developing our problem statement, which is a summary of the problem, how we’re measuring it, and what we believe the contributing issues to be.
Property Seizure Process Improvement Project
The problem we were presented: The process of seizing properties and transferring them to the land bank takes too long and not enough properties are being transferred to the Greater Syracuse Land Bank.
Tools used:
Interviews with city stakeholders involved in the process to gather perspectives on the key challenges slowing the process down and why they were happening. For this project, we conducted multiple rounds of interviews so that we could continue digging deeper into the “why” of the challenges we were hearing about.
Process mapping with stakeholders from multiple city departments in order to create a visual representation of the process, see dependencies between departments and ask departments to physically mark in the process where there are unnecessary steps or bottlenecks.
“5 Why” conversations with city stakeholders to help get to the root cause of challenges that were described to us early in the process and that were also brought up during process mapping.
What’s next:
Discussing our “problem statement” with senior stakeholders in order to prioritize which issues are the most pressing to solve.
These examples showcase a portion of our work that we put quite a bit of effort into – if we get this right, we can move forward confidently knowing that we were thorough in gathering perspectives and incorporating them into our description of the problem’s root cause. After we understand the problem, we start the creative process of finding ways to solve it!