How to Run a Process Discovery Workshop

Discovery workshops are where process knowledge lives. Someone explains how work gets done, and a facilitator captures it in notes, recordings, or sticky notes on a wall.

The problem comes afterward. Most process improvement projects fail before the first diagram is finished. Not because the modeling tool was wrong, but because the modeler never talked to the right people, asked the wrong questions, or mapped what they assumed instead of what actually happens.

This guide covers the most common format: a facilitated workshop with 3 to 8 participants.

Step 1: Pick the process and define the scope

Before you invite anyone, decide what you are discovering. A discovery session that tries to cover "everything the operations team does" will produce nothing useful. Pick one process. Give it a name. Define where it starts and where it ends.

Use the trigger-to-outcome pattern: "This process starts when [trigger] and ends when [outcome]."

If the process is large, break it into sub-processes and run separate sessions for each. A 90-minute workshop can usually cover 10 to 20 steps with reasonable depth.

Step 2: Invite the right people

The room needs people who do the work, not just people who manage it. Managers describe the designed process. Frontline workers describe the real one. You need both, but start with the people who do the work.

Aim for 3 to 8 participants. Fewer than 3 and you miss perspectives. More than 8 and the session becomes a meeting where half the room checks email.

Role	Why they need to be there
Frontline workers	They execute the process daily
Team lead / supervisor	They see the bigger picture
Upstream / downstream contact	They hand work in or receive it
Process owner	They are accountable for the process

Step 3: Prepare your questions

Good discovery is structured conversation, not free-form brainstorming.

Opening questions:

• "Walk me through what happens when [trigger]. Start from the very beginning."
• "Who touches this process? In what order?"
• "How do you know when this process is done?"

Drill-down questions:

• "What happens if [step] goes wrong? Who handles it?"
• "Is there a decision point here? What determines which path is taken?"
• "How long does this step usually take? What causes delays?"
• "What information do you need to start this step? Where does it come from?"
• "Is this step always done the same way, or does it vary?"

Validation questions:

• "Let me play it back: [summarize]. Does that match how it works?"
• "What did I miss?"
• "If a new hire joined tomorrow, what would surprise them about this process?"

The best question for uncovering the real process: "What would you tell a new colleague on their first day?" People drop the official language and describe what actually happens.

Step 4: Run the session (90-minute structure)

Minutes 0 to 10: Frame the scope. State the process name, trigger, and outcome. Confirm participants agree on the boundaries.

Minutes 10 to 50: Walk through the happy path. Ask one participant to describe the process from start to finish. Do not discuss exceptions yet. Park them visibly.

Minutes 50 to 70: Add exceptions and decisions. Go through the parking lot. For each exception, ask: "How often does this happen? Who handles it?"

Minutes 70 to 85: Validate and assign roles. Read the process back to the group. Mark who owns each step.

Minutes 85 to 90: Wrap up. Summarize open questions. Assign who creates the clean diagram.

Step 5: Capture notes in a way that translates to BPMN

Each sticky note or line item should answer: Who does what, when, and what happens next.

Some teams model live during the workshop using a projected BPMN tool. Others prefer sticky notes first and model afterward. Both approaches are valid. The key is that whoever models the result was in the room.

Step 6: Clean up and validate

Within 48 hours of the workshop, produce a clean diagram. The longer you wait, the more context fades. Send it to all participants and ask: "Is this what we discussed?" and "What did we miss?"

Five mistakes that derail discovery workshops

1. Jumping to solutions. Discovery maps what IS, not what should be.
2. Inviting only managers. Frontline workers describe the real process.
3. Boiling the ocean. One process, one session.
4. No visible capture. Make the model visible throughout.
5. No follow-up. A workshop without a clean diagram within a week was a wasted meeting.

Discovery workshop checklist

1. Process name, trigger, and outcome defined
2. 3 to 8 participants invited (including frontline workers)
3. Opening, drill-down, and validation questions prepared
4. Capture method chosen (sticky notes, projected tool, or recording)
5. Happy path mapped before exceptions
6. Parking lot for improvement ideas
7. Roles and handoffs marked on the model
8. Clean diagram produced within 48 hours
9. Validation review scheduled within one week

FAQ

How many processes can I discover in one workshop?
One. A 90-minute session can cover one process with 10 to 20 steps.

Should I model live during the workshop or capture on sticky notes?
Both work. Modeling live is faster if the facilitator is comfortable with the tool. Sticky notes are better when participants are not familiar with BPMN notation.

What if participants disagree about how the process works?
This is expected and valuable. Document all variants as separate paths. Do not force consensus during discovery.

Can I do process discovery remotely?
Yes. Use a shared screen. Record the session (with consent). Keep remote sessions to 60 minutes.

What is the difference between process discovery and process mining?
Discovery uses interviews to map how people describe their work. Process mining uses system event logs. They are complementary.