Exploring and Understanding Problems

In Chapter 2 you started the discovery process, gathering information and evidence about a problem or opportunity and in Chapter 3 you looked at how to work with the people involved, learning their goals, needs, concerns, and the different ways they see the situation.

However, an information system or product is part of a larger system of organizations, people and technologies, and how well it works depends on how all of those parts work together, so you should look to understand problems, gaps and needs more broadly.

This chapter builds on your earlier discovery work and leverages the information you've gathered so far to help you look more closely at the problem or opportunity, test what you think you know, and develop a clearer understanding of what is happening and why.

How to Explore Problems

Problems, and the opportunities to address them, rarely exist in isolation as organizations, the people they serve, and the external partners and institutions they interact with form complex systems of people, processes, technologies, information, policies, structures, and relationships, which influence each other.

A problem that appears in one place may actually be the result of something happening elsewhere in the system and so exploring the system more broadly helps look beyond the visible symptoms and identify important relationships and dependencies, that you need to consider to address the issue (Meadows, 2008; van der Bijl-Brouwer & Malcolm, 2020; Sevaldson & Jones, 2019).

Following this systemic approach to exploring and understanding these problems includes:

1. Reviewing what you've learned so far, identifying the important problems and gaps, and defining opportunities for improvement.
2. Exploring the broader system, mapping the people, processes, information, technologies, policies, organizations, and external factors involved in the system and how they interact.
3. Investigating what is shaping the situation, analyzing important patterns, dependencies, structures, and possible contributing factors in more detail.
4. Identifying changes that can make a positive impact, or address a need or gap that your new system will support.

Remember, these aren't rigid steps as discovery involves repeatedly broadening and narrowing your focus as you learn more. As you explore the problem, you'll diverge and expand your understanding of stakeholder perspectives, the wider system, and possible contributing factors, then converge as the evidence helps you develop a clearer understanding of the problem or opportunity. You should expect to move back and forth between these activities as new findings raise questions or change what you thought you understood.

Describe the Problem You're Exploring

By this point, you'll already have information from stakeholder interviews, workshops, documents, operational data, observation, previous research, and the existing knowledge of your team. Bringing this information together into a short working description of the problem or opportunity gives you and your stakeholders something concrete to react to and guide further investigation.

Create a Working Problem Statement

A working problem statement helps you summarize what you currently understand about the situation, who it impacts, and why you think it's important to address. It's a useful output from the work you've done so far, and helps get everyone on the same page.

A simple template you can use to describe the problem includes:

• The situation. A brief description of the problem, change, or other situation you're exploring.
• Who is impacted. List the stakeholders, users, customers, teams, or other groups that are involved or affected.
• The impact. Describe the consequences, risks, inefficiencies, or other impacts you're seeing.
• The context. Identify where, when, and under what conditions issues and problems happen.

Keep the statement relatively short, and revise it as new stakeholder input, evidence, and further investigation improve your understanding of the problems and gaps you're exploring.

Exploring the Broader System

System mapping is a set of techniques that helps you visualize the system in which an organization, its stakeholders, and any solution you design needs to work within. The map identifies the elements in a defined boundary (people, organizations, technologies, resources, and policies) and the relationships among them, including flows of information, money, materials, and influence.

Exploring the system more holistically helps identify dependencies, gaps, and leverage points that can be difficult to understand if you only examine each part separately.

These maps should be developed collaboratively with your team and stakeholders, as developing the map together lets people compare their different views of how the system works, challenge assumptions, and develop a shared picture of the situation. It can also reveal stakeholders, systems, relationships, or external factors you may have overlooked and show where a problem appearing in one area may be shaped by something happening elsewhere. These maps also serve in helping you understand both the current state and the future design of the system. That clarity aids in addressing any opportunities for change and improvement you identified.

Common Types of System Maps

• Stakeholder Maps. As mentioned in Chapter 3, stakeholder maps help you visualize the stakeholders within your system. Your stakeholder mapping also forms the basis for value stream and ecosystem mapping.
• Value Network Maps. These build on your stakeholder map, to visualize the flow of value between stakeholders. That might be information, money, products and services, but it can also include less tangible things like trust. You can use this to identify bottlenecks or hidden champions within a network (Stickdorn et al., 2018).
• Ecosystem Maps. An ecosystem map builds on your stakeholder map or value stream map to visualize complex systems that involve various components, such as humans, machines, interfaces, devices, platforms, systems, and so on, as well as their relationships and interdependencies.

Keep in mind that you are still at the exploratory stage and discovery is iterative and so this process will likely uncover more gaps, questions and other areas you need to investigate.

How to Create a System Map

Decide what you are trying to explore, map and set its boundaries, using a stakeholder map if you're trying to develop a view of just your stakeholders, a value network map to show the value exchanged, or an ecosystem map if you want to look at broader interactions between these, the information exchanged, the technology used and other elements within the ecosystem.

After creating an initial stakeholder map I find creating an ecosystem map provides the most benefit as it helps create a rich picture of the system being explored by including the technologies that are part of information systems as well as (digital) product design and development.

Begin with a rough sketch of the key people, roles, teams, systems, organizations, and external parties connected to the problem or opportunity, then add the important relationships and flows between such information, requests, approvals, decisions, resources, feedback, products, services, or data.

As you develop the map:

1. Identify the actors. Capture the key people, roles, teams, systems, organizations, and external parties involved, including those upstream and downstream of the area you are investigating.
2. Map relationships and flows. Draw connections between the parts and use arrows and labels to show what's moving where.
3. Identify issues and gaps. Mark where delays, confusion, duplication of effort, communication breakdowns, or other problems occur.
4. Review the system boundaries. Check whether the map includes enough of the surrounding system, including important factors, stakeholders, technology, systems and other actors.
5. Annotate what you learn. Add important observations, evidence, assumptions, and areas of uncertainty so the map captures both what you know and what still needs investigation.
6. Refine as you learn. Update your map as discovery progresses and new information changes and you learn more.

You can use your ecosystem map as a reference for understanding the broader context of the problem or opportunity and deciding where you need to investigate further. Later, you can use techniques such as journey mapping, workflow or process mapping, or service blueprinting to focus in on a particular experience, process, or part of the system in more detail to help inform your system design.

Causal Loop Diagrams

A causal loop diagram can help you understand the relationships, dependencies, feedback loops, and delays that shape how a system behaves. It can also help you see how changes in one area may affect other parts of the system, explore possible unintended consequences, and provide a visual way to discuss these relationships with stakeholders. A causal loop diagram includes several basic elements:

• Variables representing factors that can increase or decrease.
• Links showing how one variable influences another.
• Signs on the links showing whether the variables move in the same or opposite directions.
• Loops showing chains of influence that feed back into themselves. These are usually identified as either reinforcing or balancing.
• Delays, where appropriate, showing that the effect of a change may not be immediate.

How to Create a Causal Loop Diagram

1. Review your research. Look for factors that appear to influence the problem or situation you are exploring.
2. Identify and create variables. Use short clear nouns and describe it as something that can increase or decrease, such as workload, employee satisfaction, or customer demand.
3. Create links between variables that show their influence on each other.
   1. Use an S when the variables move in the same direction. If one increases, the other increases. If one decreases, the other decreases. For example, if increasing the number of customers increases revenue, the link between customers and revenue would be marked S.
   2. Use an O when the variables move in opposite directions. If one increases, the other decreases. If one decreases, the other increases. If increasing workload reduces employee satisfaction, the link between workload and employee satisfaction would be marked O.
4. Identify the loops. Label each loop as reinforcing (R) or balancing (B). A reinforcing loop amplifies or compounds change, while a balancing loop counteracts change and works to stabilize the system. A quick way for you to determine if a loop is reinforcing or balancing is to count the number of "O" links. An even number of "O" links indicates a reinforcing loop. An odd number indicates a balancing loop. You should always double-check this by walking through the loop to make sure the links are labeled correctly (Lannon, 2016).

Causal loop diagrams can be difficult to interpret if people are unfamiliar with their notation (Jones & Van Ael, 2022), so when using them with stakeholders, add short annotations to help explain important relationships, loops, or insights.

Investigating Contributing Causes to an Issue

Once you have a broader view of the system, you can look more closely at the areas that appear important, uncertain, or poorly understood.

Stakeholders will often describe problems through their visible effects, such as missed deadlines, low adoption, repeated errors, slow approvals, poor experiences, or increasing costs. These are important, but they may be the result of conditions or issues in other areas that your stakeholders don't have visibility into or aren't aware of.

The techniques in this section can help you investigate those conditions, explore the factors that may be contributing to the problem, and identify where you can make changes to address them. These techniques include:

You do not need to use every technique. Choose the one that fits what you are trying to understand. Five Whys can be a useful starting point because it gives you a simple way to begin looking beneath an observed problem. What you uncover may be enough to clarify the issue, or it may show that you need to explore a broader range of contributing factors with a Fishbone Diagram or look more deeply at recurring patterns and underlying structures using the Iceberg Model.

Five Whys

The Five Whys technique helps you work backward from an observed problem by repeatedly asking why it occurs. Each answer becomes the basis for the next question, helping you explore the chain of events and conditions that may contribute to the problem.

For example, you might investigate why approval requests are frequently delayed by:

• Why? Approvers frequently request additional information.
• Why? Submissions are often incomplete.
• Why? Requestors cannot see what documentation is required.
• Why? Requirements differ depending on the type of request, and requestors are not told which type applies to them.
• Why? The request-type rules are contained in a policy manual that the submission form does not link to or display.

How to Use It

1. Define the problem. Start with a specific and observable symptom or outcome.
2. Ask why it occurs. Use what you already know, along with stakeholder input and available evidence, to explore what may be contributing to it.
3. Continue questioning. Use each answer as the basis for the next question. If several explanations emerge, you may need to follow more than one line of inquiry.
4. Stop when the questions stop producing useful insight. Five questions are a guide rather than a requirement, and you may also need to stop when further answers require more evidence.
5. Validate what you found. Use interviews, observations, process data, documents, or other evidence to check whether the contributing factors you identified are supported.

Fishbone Diagrams

Fishbone Diagrams help you identify and organize possible contributing factors around a problem (Ishikawa, 1990) and are particularly useful when a problem appears to have several possible causes.

The structure of these diagrams resembles a fish skeleton with the "head" the problem, and the "bones" representing categories of potential causes, helping you explore possible underlying issues.

Fishbone diagramming also works well as a workshop activity because it lets stakeholders compare different views of what may be contributing to the problem. To make this effective, you should involve people who represent the different areas of the organization or problem you need to explore.

To develop the diagram you:

1. Define the problem. Write a clear description of the observed issue at the head of the diagram.
2. Choose cause categories. Select categories that fit the situation, such as people and skills, customers, process, technology, data, policy, etc.
3. Identify possible causes. Ask participants to suggest factors within each category that may contribute to the problem.
4. Explore relationships. Discuss whether some causes influence or reinforce others.
5. Prioritize what to investigate. Identify the causes that appear most important, uncertain, or likely to affect the outcome.
6. Gather evidence. Test the proposed causes through further discovery.

Iceberg Model

The Iceberg Model helps you explore problems and identify recurring patterns and ways of thinking that might be causing them. Using the model, you work downward through four layers of events, patterns, structures, and mental models, each layer helping you understand more about why a problem persists and where there may be opportunities to address it.

For example, repeated approval delays may in fact be caused by something other than people providing incomplete information, and looking at what happens over time might show that delays consistently occur at particular review stages. In turn those could be connected to a process requiring multiple approvals, a policy that prioritizes risk reduction over speed, or an assumption that adding another review always improves decision quality.

How to Use It

1. Start with the event. Write down the specific issue or incident you've observed. These events are the things that people typically notice such as missed deadlines, an uptick in support requests, an error in production, low adoption of a new tool, etc.
2. Look for patterns. Consider whether the issue recurs, and if so, when, where and how often it happens. Identifying patterns helps you identify what might be a one-off issue vs more systemic problems.
3. Identify the structures producing those patterns. Next, identify the structures that may be producing or reinforcing the pattern. Structures can include things like technology and infrastructure, processes, policies, the way people are incented, and how the organization itself is structured. For example, delays may be caused by too many approval steps, unclear ownership, competing priorities, or tools that do not surface aging requests.
4. Identify thinking behind the structures. Identify the beliefs, assumptions, and expectations (the mental models) that help maintain these structures. These mental models are often unspoken and widely shared, which can make them hard to identify. Listen for statements about what people believe should happen, what they think is necessary, or what they assume is always true as these can help reveal these mental models. For example, in the approval example, people may assume that more reviewers reduce risk or that additional sign-off demonstrates diligence.

As you work your way down through the iceberg, look for the deepest level where you can make a change to address the issue at the tip of the iceberg. This might mean changing a process, a policy, how a role is defined or implementing a new technology.

Identifying and Defining Opportunities

Look at what you've learned about how the current situation could be better. Use these findings to identify the improvements you want to achieve, without deciding yet how you will achieve them.

Then define each opportunity broadly enough to leave room for different approaches and avoid jumping straight to a particular solution.

For example, "Give care coordinators timely access to complete and reliable client information" describes an opportunity. "Purchase and implement a new case-management platform" is just one idea for addressing it.

A new platform may eventually be the right choice, but other approaches could also address the underlying issue, such as improving existing systems, changing data-entry practices, clarifying information ownership, or redesigning the underlying process. You can explore and evaluate these alternatives before deciding which is the best fit for what you are trying to achieve.

How to Create an Opportunity Summary

Opportunity or envisioning workshops are a useful way to identify and define opportunities with your stakeholders as bringing people together lets you compare different perspectives, challenge assumptions, and identify benefits, gaps, or considerations you may otherwise miss.

I've found that a good, lightweight opportunity summary gives you just enough detail to understand what you are considering, why it matters, and includes:

• Opportunity overviews which describe the unmet needs, gaps, or improvement you want to address.
• Stakeholders that are impacted and who could benefit from the solution.
• Expected benefits which describe what could improve for those stakeholders and the organization.
• Success measures that you can use to help you understand if what you've built was a success and made a difference.
• Questions and anything important about the opportunity that you still need to investigate.

Update the Backlog

As you identify and define opportunities, update the initial backlog to reflect what you have learned, adding newly identified stakeholder needs, constraints, risks, assumptions, and dependencies. These will likely be a fairly high level, which you'll refine as your understanding develops, and remove those that are no longer relevant.

Also, add any research or investigation that still needs to be done so you and the team have a running record of the questions that remain. Together, your refined problem statement, the evidence you've gathered, and your updated backlog give you a strong basis for identifying where change can create value for the organization and its stakeholders.

From here, you can compare possible opportunities to address the issues and gaps you identified, determine which are worth pursuing, and establish the vision, goals, and priorities that will guide the work that follows.

References