Why the first answer is never the process
When we started running process interviews, we asked the obvious question: "Can you walk me through how this works?" The answer was always fluent, always tidy, and always the version from the handbook. People know what their process is supposed to look like, and when asked a general question they describe that.
The process as it runs lives in a different place. It comes out in specifics: the case from last Tuesday, the colleague who is actually called, the spreadsheet next to the official system. The questions below are the ones that reliably get there. They work in a one-to-one interview and in a workshop, and they are the kind of follow-up questions patchley asks when responses are switched on.
A general question gets the designed process. A specific question gets the real one.
Start and end
What starts it? Every process has a trigger: a claim is reported, an order arrives, a new employee signs. Ask for the trigger as an event, not an activity. "A customer calls" is a trigger; "we receive the call" is already a step.
When is it finished, and how do you know? The end is less obvious than it sounds. Is the invoice process finished when the payment is booked, or when the supplier has confirmed receipt? Two people in the same team will give two answers, and both are worth recording, because they often reveal that there are two processes.
In the diagram, the answers become the start and end events. Everything between them has to connect, which is the first thing a drawn diagram makes visible: a path that goes nowhere is a question to ask.
The last case, not the typical case
Walk me through the last case you handled. This is the question that does most of the work. A typical case is an abstraction; the last case is a memory. People remember which screen they opened, whom they waited for and what was missing. The sequence that comes out is the real one, including the steps that are "not really part of the process" and are done every time.
What did you open to do that? Each step happens somewhere: a system, a shared folder, an email inbox, a paper form. In the diagram these become the systems and documents attached to the steps. They matter later, when someone asks which steps touch the customer database or where the policy file is read.
Decisions and the rules behind them
Where do you decide, and on what? Every "it depends" in an answer is a gateway. The follow-up is the rule: covered or not covered, above or below a limit, complete or incomplete. Often the rule is clear. Sometimes the answer is "experience", and that is worth writing down exactly as said, because a decision with no stated rule is either a judgement call that needs a person or a rule nobody has written yet.
Who else can make that decision? Deputies, escalations and "when she is on holiday" arrangements belong in the diagram as paths, not in a footnote.
A gateway without a rule is not a modelling error. It is a finding.
Exceptions and workarounds
What happens when it does not go to plan? Missing documents, a system that is down, a customer who does not reply, an amount outside the usual range. Each exception is a path the handbook rarely describes, and it is where most of the waiting time hides.
What do you do that is not in the handbook? This question needs some trust, so we ask it late and ask it plainly. The answers are the workarounds: the extra spreadsheet, the verbal approval, the form that is filled in afterwards. We treat them as the most honest description of where the designed process does not fit, and they go into the diagram as what actually happens, with the pain point attached to the step.
Checks and evidence
Who checks, and what proves it? A four-eyes approval, a plausibility check, a sign-off before payment. These are the control steps, and they deserve two more questions: what is the check looking at, and what evidence does it leave behind? An auditor will ask the same, and it is far easier to answer during the interview than months later. In the diagram the step is marked as a control, so that every later reading of the process can find it. We have written more about this in the post on control steps that survive an audit.
What the answers become
Each answer has a place in the notation. Roles become lanes, steps become tasks, decisions become gateways with labelled paths, systems and documents become elements attached to the steps, and checks become control steps. The BPMN guide explains each symbol; the example models show what a full process looks like once the interview is done.
The order of the questions matters less than the habit behind them: ask for the specific, ask for the exception, ask what proves it. The first interview will still miss things. The diagram shows where, and the second interview starts from the gaps.