Interview Structuring when the Outcome is a Process Model

Operational guide for a process analyst whose deliverable is a BPMN (or similar) as-is model validated by domain experts. Synthesised chiefly from sources/2018-dumas-fundamentals-of-bpm §5.1–5.4 and §6.1, §6.3.1.

The guide is organised as the analyst will actually work: prepare → interview → model → validate → iterate, with cross-cutting advice on question design and anti-patterns.

0. Frame: what makes this interview different

A process-model interview is not open inquiry. The deliverable is a structured artefact (activities, events, gateways, resources, data, exceptions) that must satisfy syntactic, semantic, and pragmatic quality (§5.4). That constrains the interview in three ways:

The schema of what you extract is known in advance — for every activity you must end up knowing: who performs it, input, output, decisions taken, preceding and following activities, exceptions, timers. Your questions exist to fill that schema.
Domain experts think in cases, not in models (§5.1.2) — you are doing a reverse-engineering job, translating episodic narrative into general routing rules.
You cannot show BPMN back to them to confirm — validation must be translated to natural language (§5.1.2, §5.4.2). This is not just prudence: Ottensooser et al. (sources/2012-ottensooser-graphical-vs-textual) show experimentally (n=196) that untrained readers gain no statistically significant understanding from BPMN alone (Wilcoxon p=0.15), whereas written use cases help both trained and untrained readers (p<0.01). The order matters — presenting a written use case first, BPMN second, maximises comprehension for all audiences; BPMN-then-text does not.

1. Prepare

1.1 Pick the right people (stakeholder analysis, §6.3.1)

Five categories, each with a different angle on the process:

Category	Typical concerns / what they can tell you
Customer(s)	Cycle time, defects, transparency — outside view of boundaries and outcomes
Process participants	Handoffs, local workarounds, exceptions, transportation/waiting waste
External parties (suppliers, sub-contractors)	Interface contracts, message flows, predictability
Process owner / operational managers	Performance targets, compliance, policy
Sponsor / executives	Strategic alignment, KPIs, opportunities (not just issues)

Always cover at least customer-side, every participant-role, and the owner. Clear the roster with the process owner first (gets "the right people on board" — line-management buy-in before approaching individuals, §5.1.2 expert box).

1.2 Pre-read before you talk

Start with evidence-based material (§5.2.1): org chart, policies, forms, handbooks, UML/data models, existing process docs. Purpose:

Identify candidate activities and roles (compare: Exercise 5.3 & Solution 5.3 — UML class methods suggest activities; policies suggest decision conditions).
Spot deadlines and timers (completeness cues).
Formulate a short, precise set of working hypotheses at different levels of detail (§5.1.2 expert box). The hypotheses are what you will validate in the structured portion of each interview.

Before the first interview, sketch a TRAC scope model (sources/2014-sharp-using-scope-models): Trigger(s) · Result(s) per stakeholder · Activities (5±2 milestones) · Cases. This gives the interview a target structure to fill in, not an open field to wander. Sharp's rule: "Get on TRAC by scoping before analysing."

1.3 Pre-write the question pack

For each interviewee, prepare blocks from two complementary sources: Dumas for process-mechanics elicitation and Sharp (sources/2014-sharp-whats-wrong-with-this-process) for stakeholder-lens diagnostic questions.

Dumas blocks (mechanics):

Role block — "What tasks are you responsible for?" (Solution 5.2 opener)
For each task: input required, decisions taken, output produced, resource it is forwarded to (§5.2.2 per-interviewee checklist).
Rainy-day block — derived systematically from the exception taxonomy (§5.2.2):
- Internal business exception (e.g. out-of-stock, ineligible application).
- External business exception (e.g. customer cancels).
- Internal technology exception (e.g. system unresponsive).
- Activity timeout (deadlines, and what fires if they are missed).
Completeness block (§5.4.2) — at each stage, "what other processing options exist here?"; "who else is authorised to do this step?"
Frequency block (inspired by §5.6 Solution 5.5) — for each issue raised: "how often does this happen? when did it last happen?" — separates real structural variants from sporadic anecdote.

Sharp stakeholder blocks (diagnostics) — vary the questions by interviewee role; do not ask a performer the owner's questions:

Customer:

Does the process actually deliver what you want?
Are there too many interactions?
Are rules and requirements reasonable?
Can your work be located within the process?
Are you the "human glue" that holds the process together?

Performer: (emphasise this group — owners and customers are already over-represented in most BPM initiatives)

What are your major sources of frustration?
Do you have the necessary tools and support?
Are there steps that serve no purpose?
Are problems caused upstream? Are you constantly correcting or redoing earlier work?
Does the workload vary wildly?
What would you change if you could?
Is there a documented process?

Owner / manager:

Does the process use resources that would be better allocated elsewhere?
Is it a net contributor or a source of problems?
Does the process constrain innovation, growth, or market opportunities?
Does the process provide information for managing it?
Did the process earn your organization an unflattering segment on a consumer affairs TV show? (reputational anchor)

Positives block (Sharp) — ask every stakeholder: "what about the current process do you value and want preserved?" Missing this risks throwing out valued elements during redesign.

Environmental-context block (Sharp's Q2, when assessing why change is needed) — pick from: changing customer expectations · regulatory change · new/emerging competition · workforce changes · economic conditions · socio-political change · business-model change · ownership change · disruptive technology · volume changes · location changes. Extend via PESTLE.

Consequences-of-inaction block (Sharp's Q3) — "What will happen if the process is left as-is?" Only deploy after Q1 (problems) and Q2 (environment) have defused blame.

2. Conduct the interview

2.1 Length and balance

Dumas recommends ~1-hour interviews. Budget:

~45 min structured — walk the hypotheses, fill the schema.
~15 min free-form — "anything I haven't asked about that you think matters?" Guard against pure-structured checklist fatigue and pure-free-form wander (§5.2.2).

2.2 Traversal strategy (§5.2.2)

Two complementary routes — mix across interviewees, not within a single interview:

Forward — start from triggers ("how does your work start?") and follow to outcomes. Natural for participants, good for understanding decision timing.
Backward — start from outcomes ("when is the job done?") and trace inputs needed to get there. Useful when the participant easily names outcomes but struggles with general flow.

2.3 Activity granularity — two levels

Activity level (§5.3 step 2) — main business activities; the granularity of the eventual BPMN model.
Step level (§6.1) — fine-grained steps inside one activity (e.g. "Check invoice" = retrieve PO → compare amounts → verify delivery → verify banking details). Elicit via observation and targeted interview when checklists are absent. Necessary for later value-added / waste analysis, but don't force it during the first pass — it bloats the model.

Dumas warns: a recurrent failure mode is drifting to micro-steps ("put document on fax machine") during discovery. If participants describe micro-steps, lift the abstraction back up; park the fine detail for a dedicated sub-process session (§5.2.3).

2.4 The sunny-day pitfall — and how to break it

When asked how a process works, interviewees almost always describe the normal path. Exceptions vanish unless explicitly asked for.

Rainy-day questions to deploy mid-interview:

"How did you handle your most difficult customer?"
"What was the most difficult case you worked on?"
"What happens if the customer doesn't reply on time?"
"What do you do when [system] is down?"
"Walk me through the last time this didn't go normally."

Derive additional rainy-day questions by going through the exception taxonomy bullet by bullet for the current activity.

2.5 Listening for control-flow patterns (§5.1.2 expert box)

Linguistic tells you should write down verbatim:

"alternative", "exclusive", "either… or…", "depending on" → XOR
"in parallel", "independently", "either order", "both" → AND
"sometimes", "occasionally", "if time permits" → likely OR or optional path (but prefer to model as XOR with a default branch — OR gateways are error-prone per G5 in 7PMG)
"once all X are done" → AND-join / multi-instance completion condition
Passive voice on inputs ("the form is received") → upstream handoff; probe the sender.

3. Model between interviews

Dumas' phase model (§5.2.2 Fig 5.4) is Interview → Modeling → Validation → (loop). Do not try to model live in the first interview — you are listening. Model offline from notes/recording before the next session.

Use the §5.3 five-step method as the modelling discipline:

Boundaries (start/end events).
Activities and events.
Resources and handoffs.
Control flow.
Additional elements (data, exceptions, compensation, annotations).

Mark uncertainty explicitly on the model (e.g. ? or coloured sticky) so the next interview has targeted questions.

4. Validate

Two distinct quality axes to validate separately (§5.4):

4.1 Semantic — validity and completeness (§5.4.2)

Validity: every statement the model makes is consistent with reality. Elicit by translating the model to natural language ("after you check completeness you pass the file to the academic committee, and you wait for their response before doing anything else — is that right?") and letting the expert point out falsifications. Empirically grounded: Ottensooser et al. 2012 (sources/2012-ottensooser-graphical-vs-textual) showed that a Cockburn-style written use case presented before the BPMN diagram produced the highest comprehension scores across all reader communities (BA and BU proxies, H5 p<0.01). A reasonable validation artefact is therefore a structured written use case (trigger, primary actor, main success scenario as numbered steps, extensions for exceptions), optionally paired with the BPMN as a supplement.
Completeness: no essential alternative path is missing. Actively probe: "what other outcome is possible here?"; "who else could perform this?" Don't rely on experts to spot omissions — they won't.

4.2 Pragmatic — is the validation conversation even possible?

If the expert glazes over when you explain the model, the model has failed pragmatic quality. Apply 7PMG (§5.4.4) before showing: verb-object labels, block-structured where possible, ≤30 elements per view, decomposed via sub-processes. Neat layout matters (§5.1.2 expert box).

4.3 Iterations

Expect ≥2 iterations per interviewee (§5.2.2). Complex processes: more. Final approval from the process owner closes semantic validation (§5.4.2).

5. Anti-patterns

Showing raw BPMN to a domain expert for validation → they read activity labels but not gateway semantics; silent misunderstandings slip through. Always translate to natural language first. (sources/2012-ottensooser-graphical-vs-textual shows no significant comprehension lift from BPMN alone for untrained readers.)
One giant free-form interview → you end up with rich narrative and no schema-filled model. Prepare the hypothesis pack.
Letting a single participant define a shared step → fragmented knowledge (§5.1.2 challenge 1); cross-check upstream/downstream assumptions against the person on the other end of the handoff.
Treating every complaint as a structural variant → use frequency questions (§6.3.1) to separate "happens in 30% of cases" from "happened once five years ago".
Modelling during interview 1 → you listen worse, and you prematurely commit to a structure.
Skipping the rainy-day block because time is short → the exceptional paths are exactly what distinguish a useful as-is model from a marketing brochure.

6. When to prefer workshop over interviews

Workshops (§5.2.3) resolve inconsistent perceptions faster than serial interviews because disagreements surface in real time. Prefer workshop when:

Multiple roles disagree on the same handoff or decision.
The organisational culture is open enough to support cross-hierarchy speech.
You can schedule 3–5 sessions of ~3h with ≤12 attendees each.

Prefer interviews when:

Politics prevent candid group discussion.
Participants are geographically distributed or shift-workers.
The process is strictly hierarchical and subordinates will defer to superiors in a room.

sources/2018-dumas-fundamentals-of-bpm-ch5-discovery — primary operational source (ch. 5).
sources/2018-dumas-fundamentals-of-bpm — meta page; ch. 6 §6.1 (step decomposition) and §6.3.1 (stakeholder analysis) fed into section 1.1 and 2.3.
methods/process-discovery-methods — method-level overview.
concepts/process-discovery · concepts/process-model-quality
Related but not yet ingested: Sharp & McDermott; Jeston & Nelis; Berg & Lune on interview technique; Rosemann on 22 modelling pitfalls (all flagged in Dumas §5.8 Further Readings, status: referenced-not-ingested).