Delivering Successful Workshop Outcomes

Delivering successful workshop outcomes is no small feat. I think back to the innumerable workshops that I’ve attended and note how often intended outcomes were never delivered. On the other hand, I have been part of, and led, high-impact workshops that made a real difference to the sponsoring organization. Planning, creativity, enagement and accountability make the difference.

Workshop Lifecycle

Delivering successful workshop outcomes requires a four-phase life cycle.

Planning. This phase includes defining the sponsor, participants, facilitators, desired outcomes, scope, constraints, agenda linked to workshop building blocks, and invitations.

Initiation. Once planning is complete and the workshop date arrives, several important steps must occur. For an in-person workshop, prepare the room with flip charts, table orientations, office supplies, food, snack, and beverages. While these things may seem minor, comfort plays a big role if one expects participants to productively engage over the course of a day or more. Conversely, for a virtual workshop, initiate video calls, launch online tools such as Trello and online whiteboards and generally allow plenty of time to resolve technical glitches.

Execution. After initiation, the facilitator begins leading the participants through the agenda. I recommend building the agenda with workship building blocks which I describe below. Each building block follows a four-step pattern: inputs, active collaboration, debrief and capture. By repeatedly following this pattern, participants can capture, consolidate and crystallize the knowedge and decisions as the workshop progresses. On the other hand, if the facilitator waits until the end of the day to debrief, much of the early work is by way of information overload.

Follow-up: Finally, delivering successful workshop outcomes typically requires follow-up. Depending on the outcome goal, I often recommend organizations assign a project manager to drive and track progress. Otherwise, it easy, even natural, for particpants to leave the workshop and go back to their regular routines. Workshop goals essentially represent change. Consequently, workshops should have a change management perspective and result in a plan to help the organization make their desired changes.

Workshop Building Blocks

Every workshop is different. Consequently, delivering successful workshop outcomes requires customization and tailoring. However, I always start with modular building blocks; some of which I always use and others as optional, depending on the situation.

Each workshop building block, or module, follows a four-step pattern to reinforce learning or effective decisions: inputs, active collaboration, debrief and capture.

I group building blocks into module categories:

1. Early grounding on who and why
2. Focus on the outcome
3. Risks and challenges
4. Participant engagement
5. Action plan

Inputs include content such as handouts, questions, activity props and prepared flip charts or Trello boards for virtual workshops.

Active collaboration consists of activities, conversations and simulations. I prefer a healthy mix of table-top work and having participants stand and engage. Getting people moving helps maintain focus and energy. For virtual attendees, I include standing opportunities for stretching and fun physical expression such as hand gestures.

Debrief is the process of workshop groups sharing the results of the active collaboration activity.

Finally, the facilitator summarizes and captures debriefing results, actions, and agreements.

Delivering Successful Workshop Outcomes Requires Early Grounding on Who and Why

Introductions Module

In-person – Nametags: Name and Role (no title)

For Zoom meetings, have participants rename themselves as first name – role.

Move slowly through introductions with a bit of detail so that people have a chance to register who people are. For example: give your name, your team (and what they do), your title/role, your role at inception. Pause for questions from the room.

The icebreaker should be a fun, kinetic (out of your seat if possible) way of getting people to know each other and get in the mindset of an open and engaging activity.

Ideas for games & icebreakers: https://gamessimonplays.com/

Workshop Overview Module

It is important to answer these questions for attendees:

• Why are we having this workshop?
• Why does it take so long?
• What are the outputs, results of the workshop?
• What are we doing? (overview of exercises and how they build to a result)

These expectations should also be set:

• Workshops are difficult. There are moments of agony and moments of glory.
• When in doubt, give in to the process – trust that it will get results.
• The agenda will change beginning on day 1. Flexibility is key to a successful inception.

Review the Day 1 Agenda. It’s best to prepare a visual agenda with stickies that can be moved as each item is completed. For virtual workshops, create Trello board cards that can be reordered and moved to “done.”

Ground Rules and Sanctions Module

The team collectively suggests and agrees to ground rules and sanctions. Examples include

• No screens (for in-person settings)
• Safe environment
• No such thing as a stupid question
• No role or hierarchical restrictions
• Be timely

Write these items on a flipchart or Trello card.

Sponsors Module

Goals and Objectives

Executive sponsors explain the project – why it is important (describing business, customer, financial context), what the objectives are and are not.

Can include larger program scope as well as what the first launch will include (ie, MVP)

Duration: 30-60 minutes

When to Use: most workshops

Impact Mapping Module

Goals and Objectives

Impact mapping is a structured path to drive a conversation through a set of questions to answer the ‘Why’, ‘Who’, ‘How’, ‘What’ of the project.

Duration: 1 – 2 hours

When to Use: This is an exercise that covers quite a few others in one go: it will identify the goal, actors and high-level features of the project. It’s a visual and very structured exercise that make great leaps forward in understanding. The exercise can be used as a validation exercise to recap an approach, to cut exercises down if there is limited time, as a breakout exercise for several subgroups in order to compare impact maps, etc.

Delivering Successful Workshop Outcomes Requires Focus on the Outcome

Elevator Pitch Module

Goals and Objectives

Develop a one-line description that encapsulates the project intent – convey the purpose of the project to people inside and outside the team. The elevator pitch exercise is an important exercise in getting the team aligned around the core purpose of the project. Remember to focus on the end user problem you are trying to solve, not the technical problem you are trying to solve.

Duration: 60m

When to Use: most workshops

Details

Develop an elevator pitch following this format: For [target customer], who has [customer need], [product name] is a [market category] that [one key benefit], unlike [competition], the product [unique differentiator].

Show the format of the desired sentence and an example from a previous workshop.

Create columns on a whiteboard or Trello board – one for each of the words to be filled in (e.g. one for target customer, customer need, product name etc.)

As a group brainstorm and then agree on a target customer.

Have the team stand around the whiteboard (or use Trello board) and, using sticky notes or Trello cards, brainstorm possible answers for each column. You can also break into teams and have each team brainstorm and suggest their answer for one of the terms.

Have a facilitator work with the group to choose the best word from each column to assemble the sentence. This is tricky.

Scope Module

Goals and Objectives

Assure everyone is super, super clear what is, and is not in scope for the project

Duration: 30-60m

When to Use – Always

Details

Prepare (preferably in advance of meeting) two lists on easel paper: in scope, and out of scope

Product Management/Owner walks through each item describing it and why it is in/out of scope

End with a Q&A session intended to: a) challenge items in/out of scope and b) add to or clarify scope.

Changes to scope should be scribed and the scope should remain up on the wall for the duration of the inception

Notes

This is NOT the place to debate what is MVP (Minimal Viable Product) because that will lead to premature speculation about specific features and whether they should be implemented or not. Once all the stories are generated for the full scope, there will be a separate exercise to determine which ones are actually MVP.

Decision Making Module

Decision making is one of the more challenging aspects of delivering successful workshop outcomes. Workshop decisions can resemble the infamous decision-by-committee trope. As Fred Allen once said, “a committee is a group of people who individually can do nothing, but who, as a group, can meet and decide that nothing can be done.” If not carefully managed, a workshop will embody this joke. One of my preferred decision-making frameworks is the RAPID^® from Bain and Company. When using this framework it’s simple to remember the RAPID mnemonic:

• Recommend: the person recommending a decision.
• Agree: inputs must be incorporated into the recommendation.
• Perform: accountable for implementing the decision
• Input: decision input is provided but does not necessarily need to be included in the recommendation
• Decide: makes the decisions and commits the organization to action

Goals and Objectives

Lead the workshop team through a sustainable decisions, supported by the organizaton.

Duration: 60 m or more depending on the decision complexity

When to Use – when the workshop scope includes a complex, organization decision

Success Metrics Module

Goals and Objectives

Define what business measures will define the success of this project. This exercise will help clarify what results are desired.

Duration: 30-60m

When to Use – when success measures are ambiguous, numerous, unclear or debatable.

Details

• Have the team brainstorm on possible measures being clear both on what specifically is being measured and the definition of success for that measure. Simple ones like “increased conversion” are fine, but push for precision and details “increase 30-day repeat purchases by >5%” as an example. Be sure to consider safety metrics where “success” is no change. E.g. “no decrease in account creation rates”.
• Group and de-dupe the measures. Discuss them so people understand.
• Vote and select the top vote winners (probably no more than 5)
• Assure people agree that if these measures are achieved that the project would be a success

Delivering Successful Workshop Outcomes Requires Attention to Risks and Challenges

Anchors and Engines Module

Goals and Objectives

Identify what could prevent progress (anchors) and what positive things (engines) move the project forward. Project leaders should take actions to leverage positive or mitigate the negative.

Duration: 30-60m

When to use: This exercise is a great “out of your seat” exercise to break up day 1 which is typically presentation heavy.

The workshop (generally follows the “Brainstorm, Group, Vote” pattern)

• On a whiteboard, draw a horizontal line through the center.
• Label the top half as “engines” and the bottom as “anchors”
• Have team stand around the board and, using sticky notes,
• Brainstorm on things that are, or could be, anchors or engines. (For example: communication, management support, time zones, experienced team, etc.)
• Have the team group related sticky notes
• Have the team vote with pens on their top anchors and engines (e.g. 3 votes each for anchors + 3 for engines)
• Circle Top Items and read out to group. Discuss briefly as time and interest allow.

Notes

It is very common to have the same item appear as both anchor and engine. For example. leadership support mightm show as both meaning – if you have it it is an engine, but if you don’t it’s an anchor. That is expected. There is no concrete “follow up” from this session, but project leaders should take note of the top items and take action during project execution.

Sliders Module

Goals and Objectives

Determine the priority of various competing objectives for the project (e.g. time vs functionality)

Duration: 30-60m

When to Use: almost always

Details

• Project owner should determine the key, competing objectives. 5 MAX.
• List each of these “sliders” along with a horizontal line to the right (these lines are sliders like on a sound board – see previous inception outputs for examples).
• Choose the 3-5 key project owners in the room to determine the relative order of the sliders. Typically: product management, UX, Tech leader, project mgmt.
• The above owners place a sticky note “slider” on the horizontal line for each slider with input/comments from the room.
• No two “sliders” can have the same importance.

Notes

Great care must be taken to choose/name sliders such that “low” and “high” can be compared across the sliders. For example “low quality” and “low latency” would be a poor match because one is good and one is bad. The project leaders should also think carefully about possibly conflicting agendas/goals and determine if any of these can be surface via a slider so that the team can see an explicit decision about that objective. For example, how important is the goal to support some next capability vs. delivering asap?

Example Sliders: Quality, Speed to market, Innovation, Bug-free (functional quality), UX quality, Performance, Feature Depth/Breadth, Future Proof, Scalability

Thinking Hats Module

Thinking Hat is a great exercise to give participants permission to play different roles using the concept of parallel thinking. Here is a podcast I recorded covering the approach.

Delivering Successful Workshop Outcomes Requires Participant Engagement

Safety Check Module

Goals and Objectives

To determine (especially early in the inception) if people are on board, understand why THEY are there, believe in the process etc.

Duration: 15-30m

When to Use

When you have participants that may be there against their will, or are openly skeptical, or you when you simply want a way to gauge how engaged people are.

Typically only used on day 1 of the inception or if there are on-going engagement issues.

Workshop Details

Ask each team member to rate their situation from 1-5 where 1 = this is the stupidest waste of time ever and 5 = I’m so excited I can’t wait for tomorrow!

Have them write on a paper (everyone use the same color) and fold in half to make as anonymous as possible.

Tally the results and draw a quick histogram on the board

On the low end, ask people to speculate what could be holding people back (don’t ask for people to explain themselves!)

Repeat for the high end – why is there enthusiasm?

Mood Map Module

Goals and Objectives

Give people a chance to be heard about the process, to feel like they can impact the process

Give feedback to facilitators on what people liked, didn’t and why

Duration: 15-30m

When to Use

This is a quick, easy, end of the day closer. It’s optional but easy and helps connect the leaders with the participants.

Details

• On a whiteboard, draw a timeline at the bottom (e.g. 9am on the left, 5pm on the right). On the left axis is zero/unhappy at the bottom to”happy” at the top.
• You may want to summarize the agenda/activities across the top
• Ask each person to take a marker and graph their mood during the day. This will be a simple line scrawled from left to right going up/down with their mood.
• After everyone has gone, look for patterns of highs/lows and ask for comments about why people felt good/bad about what was happening at that time

Delivering successful workshop outcomes requires planning for participant difficuli

I always warn workshop participants we’ll experience moments of frustration, even hopelessness. I call it the “valley of death.” When particpants know it’s coming, managing through it is easier. For more, read Navigating Change’s Death Valley.

Action Plan

Once the workshop defines the who and why, expected outcomes, risks and challanges while keeping participants engaged, it’s time to build an action plan.

Action plan module selection depends on whether execution consists of software delivery or another type of execution plan.

As-is and To-be Process

Goals and Objectives

Define the high-level process steps for the “to be” (future) process. These logical steps become the basis against which teams will write stories. For example, taking a “logged in user” role and writing stories for the “collect payment information” process step.

This is the most important foundational step for generation of user stories.

Duration: 2-4h

When to Use: almost always

Details

As-Is

1. Hand out three colored cards: 1) process step, 2) attributes displayed or collected, 3) pain points
2. Starting with the happy path, have the team brainstorm on the existing process steps and attributes displayed or collected at each stage.
3. Have a long table cleared off and put the process cards in sequence on the table
4. Break into teams (4-7 people/team). Each team takes a role and extends the “as-is” process to handle that persona, happy + unhappy paths, and attributes displayed or collected.Note: don’t get too hung up on process details.
5. For example, pain-points can capture a lot of the unhappy path issues without having to create a process flow.
6. Attribute cards should be grouped with their respective process steps
7. Have the team brainstorm on pain points – probably by breaking into teams and having them take role cards to write pain points for.

To-Be

1. Pick a simple user role and, as a group, define the happy-path to-be process as a group (using the same colored cards as above)
2. Break into teams, and have teams take a user role each. For each user role, the team should extend the to-be process to support that role and add attribute cards for that role.
3. Have teams swap roles and review/extend/clarify the other teams’ work.
4. Repeat until all the user roles have been covered.
5. Review the pain points from as-is to assure the pain points have been addressed to the extent possible.

Notes

• You may need more than one as-is or to-be process. For example, you would have separate processes for diverse audiences or customer segments. You want to keep the number of discrete processes to an absolute minimum.
• Processes should be logical and not describe systems or processing. They should be high level with number of steps in single digits.
• This is a challenging session to lead. It helps to have someone who is pretty familiar with the current and intended processes to take the help and focus the activity.

Write Stories

Goals and Objectives

Generate the list of stories that is the core encapsulation of the work for this project.

Duration: 4h-2d

When to Use: when developing software using agile techniques

Details

• Story Format: On a poster or whiteboard write the canonical structure of a story “As a <role> I want to <do something> so that <some result is achieved>”. Provide a concrete example.
• Card template. Explain to people how you want them to complete the story cards and post a written example showing where on the card to place information. Common attributes to capture:
• Role name for the story
• One-line story sentence “As a …”
• MVP Yes/No or Priority (best guess by story writer)
• Dependencies

Story writing

• Break into teams of 4-6 people each.
• This can be sequenced multiple ways.
• OPTION 1
  • Assign roles to teams (or let them self-select roles)
  • Have teams write stories for those roles (e.g. for all process steps).
  • Have teams switch roles. Now teams will focus on reviewing stories already written, seeking clarification, and identifying additional stories.
• OPTION 2
  • Assign Steps in the process (or groups of steps) to teams.
  • Have teams write stories for those parts of the process for all roles
  • Have teams switch process steps. Now teams will focus on reviewing stories already written, seeking clarification, and identifying additional stories.
• Repeat until all roles and process steps have been covered.
• You should set time limits for each story writing section. (Decrease the time for each subsequent rotation).
• In the end, you need to have stories written and reviewed for every combination of role and process-step.
• You also need to cover both HAPPY and UNHAPPY (or ALTERNATE) paths.

Story capture. You should have a plan for getting all the stories and their attributes entered into Excel or anAgile software tool by the end of each day at the latest.

Notes

When breaking into teams, force them to be diverse. Avoid people’s tendency to group by people they know as this will cluster expertise and you want people to hear and learn from diverse perspectives.

Along the same lines, there are some user roles that few people in the room will know enough to write stories for. Make plans to assign those difficult roles to the team that has the resident expert. (customer service stories to the team with the customer service representative)

It is important to capture the stories in a spreadsheet or tool such as Jira. One easy way to do this is recruit 5+ volunteers to take the stories (on post-its) and enter them into a excel template or shared google spreadsheet.

Minimum viable product (MVP) determination

Goals and Objectives – determine which stories are the “minimum viable product” (determine what stories must be shipped before the project is considered complete)

Duration: varies

When to use: when developing software products

Details

Define the term MVP. MVP = entire scope of the project. When you ship MVP there may be follow-on work, but the project is complete. It is the absolute minimal needed to complete the project.

Determine which stories are MVP There are two approaches:

• Product Owners go through the stories and make the call (this happens offline)
• Product owners participate in the estimating process and the first step is to determine if a story is MVP/in-scope.

Notes

The definition of MVP for projects hasn’t always followed this definition. Whatever the definition you use, just be sure this exercise clearly defines what “done” is for the project and is HARDCORE on the minimal needed to ship.

Incremental delivery is a separate topic. Most teams find benefit from shipping something ASAP even if it works for only a subset of users on limited traffic.