Shared Problem Definition
Shared Problem Definition is a role-play in which four to six people each represent a different professional or organisation in a multi-actor project and work step by step from their separate views of the issue to one jointly worded problem statement. It was written up by Edith van Ewijk for the Transition Makers Toolbox of the University of Amsterdam and TU Delft, drawing on research into joint problem framing in interdisciplinary projects. The sequence is deliberately slow: tasks first, then each party's version of the problem, then commonalities, differences and interfaces, and only then a shared definition.
Facilitation script
- 1
Introduce the case, the aim and the rules of the role-play; confirm who plays which role.
20 min - 2
Round of introductions in role: who you are and which organisation you represent.
15 min - 3
List each organisation's key tasks and objectives on the flipchart, one role at a time.
30 min - 4
Each role explains why the issue is a problem for them; record every problem view.
30 min - 5
Compare the views and list commonalities, differences and interfaces.
30 min - 6
Draft the joint problem definition from the commonalities and interfaces and test the wording with every role.
15 min - 7
Break, then step out of role.
20 min - 8
Individual written reflection on how well each person understood the others and how the integration went.
15 min - 9
Plenary debrief: what made a shared wording possible, what stayed unresolved, and what to carry into the real project.
40 min
Tips
Hold the group to the order of the steps.
Tables that jump to solutions during the task round end up with a problem statement that is really one party's preferred measure in disguise.
Write the differences down as carefully as the commonalities, because they tell the project where negotiation will be needed later.
If people play their role as a caricature, ask them what that professional would lose if the project went wrong.
Common pitfalls
Skipping the task round to save time, so that problem views arrive without the mandates that explain them and the group reads differences as stubbornness
Letting the most senior or most fluent role write the definition, which produces a statement the others tolerate in the room and abandon afterwards
Drafting a definition so broad that everyone can sign it, which hides the differences and gives the project nothing to work with
Thin role preparation, which turns the session into people guessing what an engineer or a planner would say
Dropping the out-of-role reflection, so participants remember the content of the case and not what they learned about integrating perspectives
Variations
The in-session sequence also works with real stakeholders and no role-play shell: each organisation speaks for itself and the preparation shrinks to bringing its mandate and objectives. With a larger group, run several tables in parallel on the same case and compare the resulting definitions, or let extra people observe one table and report what they saw. Remotely, use one shared board with a column per role and keep to one table per video room. Where two days of role preparation are not realistic, hand out a one-page brief per role and accept a shallower result.
Where it fits
When to use it
A project involves several organisations or disciplines that each describe the problem in their own terms and have not yet noticed that the descriptions differ
A team is about to enter a real multi-party process and needs to practise hearing other mandates before defending its own
Students or new staff need to experience how hard joint framing is before they study the theory
An earlier project stalled because partners agreed on a solution without agreeing what it was meant to solve
You have at least half a day and participants who are willing to prepare a role in advance
When not to use it
A single team needs to sharpen its own problem statement: a Point of View Statement or The 5 Whys is faster and needs no roles
Participants cannot prepare and know nothing about the fields they would represent, since the role-play then runs on stereotypes; use Stakeholder Map to chart the actors first
The real parties are in open conflict: rehearsing them in role can harden positions, and a mediated conversation using Non-Violent Communication is the safer route
You have less than three and a half hours: the comparison and drafting steps get cut and those are the point of the exercise
Related methods
Frequently asked questions
What is Shared Problem Definition?▾
Shared Problem Definition is a role-play for groups of four to six in which each person represents a different professional or organisation in a multi-actor project. The table lists every party's tasks, records how each one sees the problem, compares those views and then writes one jointly worded problem definition. It was published by Edith van Ewijk in the Transition Makers Toolbox.
How long does Shared Problem Definition take?▾
Plan three and a half to four and a half hours in the room. The source version adds about two days of individual preparation in which each participant studies the field they will represent, which is the largest cost of the method.
Can you run it with real stakeholders instead of role-players?▾
Yes. The sequence of tasks, problem views, commonalities and differences, and joint wording works without the role-play shell. Each organisation then speaks for itself, and the facilitator needs to pay more attention to power differences between the parties than in a classroom role-play.
What does a good joint problem definition look like?▾
It is one or two sentences that every party can read aloud without wincing, built from the points the views share and the places where the organisations depend on each other. It names the problem and not a solution. Differences that could not be bridged are listed next to it so they are not forgotten.
How is it different from a normal role-play?▾
A standard role-play acts out a scene and debriefs the behaviour. Here the roles serve a structured analysis: the group produces flipcharts of tasks, problem views and interfaces and ends with a written definition. The acting is light and the output is a document.
Plan your next workshop with AI
Workshop Weaver helps you combine methods like Shared Problem Definition into a complete, timed agenda in minutes.
Try it freeMethod descriptions on Workshop Weaver are original content written by our team, based on established facilitation practices. This method was inspired by work from Edith van Ewijk, Transition Makers Toolbox (University of Amsterdam / TU Delft).