Purpose: We need innovation, when problems are increasingly complex, traditional approaches are not working, institutions need to work together, when what we have done in the past is no longer working, what we have tried has not succeeded, current organizations, policies, programs or institutions are not ready or able.
However, not all problems are the same:
Technical problems are not contentious. People agree on how to define the problem. Experts may be needed to analyze and solve the problem.
Crisis situations demand immediate action to prevent the loss of life or capital.
Complex, ill-structured problems have no clear definition or boundaries. Experts disagree on what the real issue is. Existing solutions and best practices are unable to make progress.
A well framed problem:
Points to barriers
Indicates how you’ll know a solution works
Materials: Slidedeck for Problem Framing, which is on the google drive. Each team will need blank paper to workshop their Problem Framing statements and/or a piece of flipchart paper to record their first iteration of their HMW statement.
Time: 90-120 minutes
Step one: Outline the purpose of problem framing for participants (use the slidedeck), and the common problem framing mistakes:
What is presented as a problem is really a solution
What is presented as a problem is really a symptom
What is presented as a problem is really a collection of problems
What is presented as a problem is located too far downstream toward solutions and not sufficiently upstream toward causes
Solving the problem involves moving them onto someone else's plate or changing their shape
Step two: Give participants some questions to support problem definition:
What is the known background to this problem?
Who is most harmed by this problem?
What are the problem’s symptoms or root causes?
Are those affected by this problem able to define its root causes?
How big is the problem?
How is it measured?
What is its unit of analysis?
What data is accessible to help us understand the problem?
What data is not accessible that we would like to have?
What are the barriers to making that data available and useable?
Who are the data users that can add value to resolving the issues?
What solutions to this problem have been attempted in the past?
Why did they fail or succeed?
Step three: Give participants ~30 minutes to fill out the following template - either individually first - or together.
Step four: Following the work on the Problem Statement, invite participants to frame up their problem or challenge in a ‘How Might We’ format. The How Might We question purposely maintains a level of ambiguity, and opens up the exploration space to a range of possibilities. It's a re-wording of the core need, which you have uncovered through a deeper interrogation of the problem in your research phase, the Empathise mode in Design Thinking – and synthesised in the Define mode in Design Thinking.
How suggests that we do not yet have the answer. “How” helps us set aside prescriptive briefs. “How” helps us explore a variety of endeavours instead of merely executing on what we “think” the solution should be.
Might emphasises that our responses may only be possible solutions, not the only solution. “Might” also allows for exploration of multiple possible solutions, not settling for the first that comes to mind.
We immediately brings in the element of a collaborative effort. “We” suggests that the idea for the solution lies in our collective teamwork.
Step five: Expand and Re-Frame, by asking the following questions
How might we…meet a user need/achieve an organizational objective? (This is the commonly structured framing phrase used to express the essence of the challenge at hand.)
What would happen if...?
In What Ways Might We…. (Expand on HMW to add the possibility of multiple approaches)
What's stopping us from...?
In what ways could we...?
From there, you can ask follow-up questions such as:
Why would we…?
Why wouldn’t we?
What has changed to allow us to...?
Who would need to...?
When should we...?