Start a hopes and fears workshop with two questions: “What do you hope this project makes possible?” and “What are you concerned could happen?” Give people time to write individually, discuss the meaning of their notes, and group related themes. Then choose a few concerns or expectations that need a concrete response before work begins.
The activity works well at a project kickoff when people share a goal but may have different ideas about success. Use a shared Boardmix whiteboard to keep the hopes, concerns, and resulting agreements visible together. A concern can remain open; the session does not need to turn every fear into a positive statement.
What the workshop is for
Hopes and fears makes expectations discussable. A team may agree to “launch a new knowledge base” while one person hopes it will reduce repeated work, another hopes it will improve answers, and a third worries it will add an unsustainable maintenance burden. Those differences influence how the work should be organized.
IBM's Enterprise Design Thinking toolkit describes the activity as a way to surface a group's goals and concerns at the beginning of a commitment. Its basic format uses separate hopes and fears areas, individual notes, theme grouping, and a shared review.
The board is not a survey of the whole organization, a probability model, or proof that the team agrees. A single concern may matter even when nobody else mentions it. Treat the notes as a starting point for clarification.
Give the group something specific to respond to
Write the project, the period under discussion, and the decision the session can influence. “Our future” is too broad. “The first month of using a shared support knowledge base” gives people a common situation to imagine.
For this example, the team includes support agents, a content editor, a team lead, and an engineer who helps maintain the search experience. The facilitator opens with:
We are preparing a small knowledge-base rollout for one support queue. Today we will discuss what we want that first month to achieve and what could make it difficult to use. We can change the pilot's working arrangements. Wider staffing and budget questions will need a separate decision.
Explain who can see the board and what will happen to it after the workshop. Invite people to pass or to raise a sensitive concern privately through an appropriate channel. Do not promise anonymity on a shared editing surface or ask participants to post private personnel information.
Collect individual views before the discussion
Ask participants to add one thought per note. A few minutes of quiet writing gives people time to formulate a view before the conversation follows the first speaker. The facilitator can use prompts such as:
- “I hope this project helps us…”
- “A useful result for the people doing the work would be…”
- “I am concerned that…”
- “Something I would need in order to contribute is…”
Do not require equal numbers of hopes and fears. Some people will have several concerns and one strong hope. Nor should a leader immediately answer every note. Let the team see the range before deciding what a response should be.
If someone writes “communication,” ask what that means in this project. “I want an easy way to tell whether an article has changed since my last shift” is a workable expectation. It points toward a specific discussion without prescribing a tool or solution.
Work through the meaning before choosing actions
The following notes are an illustrative knowledge-base kickoff, not findings from a customer study. They show how a facilitator can move from a broad sentiment to a question the team can answer.
| Original note | Clarifying question | What the team learns |
|---|---|---|
| Hope: “We stop writing the same answer repeatedly.” | Which recurring question would make the pilot useful? | Agents want a dependable answer for failed setup, not a large library of rarely used content. |
| Fear: “The articles will become out of date.” | Which changes are difficult to notice today? | Product wording changes are not consistently reaching the support queue. |
| Hope: “New agents can find answers without interrupting someone.” | What should they be able to do independently? | They need to find the right article and recognize when escalation is necessary. |
| Fear: “Maintaining this will become extra work after our shifts.” | Where would maintenance time come from? | The pilot needs an agreed allocation of time; enthusiasm alone cannot supply capacity. |
| Fear: “People will use an article when a case needs judgment.” | What would help someone recognize that boundary? | Articles need a visible exception or escalation note, rather than an instruction for every possible case. |
Group notes only after their meaning is clear. The concerns about stale wording and maintenance time may both relate to upkeep, but they have different causes. Keep the individual notes under the theme so the distinction survives.
Ask before combining two notes that sound similar: “Are these describing the same problem?” If a participant says no, preserve the difference. A tidy board is not a sufficient reason to erase a minority concern.
Choose a few working commitments
Now identify the expectations or concerns that the team can respond to before the next stage. Avoid vague commitments such as “communicate better” or “keep content updated.” Write an observable action, a person who accepts responsibility, and a point when the team will check whether it helped.
| Theme | Agreed response | Responsibility and review |
|---|---|---|
| Useful first content | Start with the failed-setup answer and include when to escalate. | The content editor and an agent review a draft before the pilot begins. |
| Changing product wording | Add relevant wording changes to the team's existing release handoff. | The engineer identifies the current handoff owner; the team checks the first update together. |
| Maintenance capacity | Ask the team lead to allocate maintenance time before agreeing to expand the pilot. | The lead returns with an answer at the pilot-planning meeting. Expansion stays unresolved until then. |
Not every note needs an action. Some hopes describe a desired outcome; some concerns need more information. Mark those distinctions in words so “open question” is not mistaken for “agreed action.” If a concern is outside the team's authority, record the route for obtaining a decision.
Use a simple Boardmix layout
Put the project prompt across the top of a Boardmix board. Below it, draw two large areas labeled “Hopes” and “Fears or concerns.” Leave a third area to the side for “Agreements and open questions.”
Participants add notes in the first two areas. During the discussion, move related notes near one another and give each group a plain-language heading. Use text labels to distinguish an agreement from a question; color can help orientation but should not carry the meaning alone.
Add the final commitments beside the notes they address. Comments can hold a clarification without making the original note unreadable. A participant should be able to trace a commitment back to the concern that prompted it, while still seeing what has not been resolved.
The areas, theme groups, and commitments are arranged by your team. You do not need automatic sentiment analysis or risk scoring to run this activity.
When a different workshop is needed
If a concern becomes “What might cause this project to fail, and what would warn us?”, take it into a project premortem. If the question is “Which belief should we test first?”, use assumption mapping. Those methods ask different questions and should not be compressed into a kickoff conversation.
At the next project checkpoint, return to the agreed commitments and the unresolved questions. Ask whether any expectation has changed now that work is under way. Keep the original notes so people can see the change, rather than rewriting the kickoff to make it look as if everyone predicted the outcome.
To prepare your session, open a Boardmix board and write the specific project prompt first. The two columns come next; the important preparation is deciding which working arrangements the group can actually influence.
