Questions to Ask When Mapping a Process
These are questions to ask when mapping a process with the people who do the work, whether you are a business analyst, an improvement lead or a manager facing a blank wall and a pack of sticky notes. They follow the order a session usually takes: the trigger and the finish line first, then each step and the role behind it, the handoffs and systems in between, the decisions and odd cases, the times and volumes, and last what the group would change. The wording is aimed at the person who does the step, because the map you want is the process as it runs on an ordinary Tuesday and not the one in the manual.
Want questions from the whole vault instead? Try the random question generator.
The questions
Each question, and why to ask it
Start and end
What starts this process: what has to happen before anyone begins work on it?
Why ask it
The answer is the trigger, and it becomes the first box on the map. Push for something you could watch happen, such as a form arriving, a phone call or a date on the calendar. If two people in the room name different triggers, you may be looking at two processes that share a name.
Where does the process end, and how do you know it is finished?
Why ask it
People tend to stop at the point where their own part ends, which is often well short of where the customer would say it ends. Ask what exists at the finish that did not exist at the start: a paid invoice, a shipped order, a closed ticket. That thing is your last box.
What is this process for, and what would go wrong if nobody did it?
Why ask it
The second half usually gets the sharper answer, because people can picture the unpaid supplier or the late order more easily than a mission statement. Write the purpose in one sentence under the title. If the room offers several, keep them all for now and notice which team holds which, since a step that puzzles one team often serves another team's purpose.
Who receives what comes out of this process?
Why ask it
The receiver might be a paying customer, another department or a regulator, and each one judges the result differently. Write them on the right-hand edge of the map. When you later ask whether a step is worth doing, this is the person you measure it against.
What does the customer, or the next team, need the result to look like for it to count as right?
Why ask it
You are collecting the standard the whole process is held to: complete, by a certain time, in a certain format. If nobody in the session can say, do not guess. Go and ask the receiver before the next session, because their answer often differs from what the team assumes.
Who owns this process from end to end, and who can approve a change to it?
Why ask it
Silence, or three different names, is a finding in itself, because a process with no owner has nobody who can say yes to an improvement. Put the name in the corner of the map if there is one. If there is not, take that back to the sponsor and do not let the session appoint somebody on the spot.
What do you call this process, and does everyone here use the same name for it?
Why ask it
What sales calls onboarding, finance may call account setup, and a map titled with the wrong team's word tends to get filed and forgotten. Put the working name at the top and the other names underneath. Different names can also be a hint that teams disagree about where the thing begins.
What sits just outside what we are mapping today?
Why ask it
Saying out loud what is excluded stops the session from spreading into every neighboring process. Keep a visible 'not today' list on the wall, so a point that is out of scope is written down and not argued over. Go through that list at the end and decide what deserves a session of its own.
Are there different versions of this process for different customers, products or sites?
Why ask it
Map the most common version first and mark where the others branch off. A variant that splits early and never rejoins the main route usually needs a map to itself. Ask roughly what share of the work each version carries, so the effort goes where the volume is.
Which process feeds this one, and which one picks up the work afterward?
Why ask it
Trouble inside a process often starts in the one before it, as a form half filled in or an order promised too early. Write the upstream and downstream names at the edges of the map without mapping them. They tell you who to invite if the cause turns out to live next door.
The steps
Before we get into detail, what are the five or six big stages the work goes through?
Why ask it
A short row of stages across the top of the wall gives every later note a place to land, and shows early whether the group agrees on the overall shape. Hold people to a few words per stage and do not let anyone open one up yet. If the list keeps growing well past six, you are hearing steps, so ask which of them belong together.
What is the very first thing you do when the work reaches you?
Why ask it
Once the stages are up, drop down to one person's hands. The first action is often an informal one, such as checking the request is complete or sorting by urgency, and it seldom appears in the written procedure. Write it down in their words, verb first.
And then what happens?
Why ask it
You will ask this more than anything else in the session, and it should stay this plain. Resist suggesting the next step yourself, since people tend to agree with a facilitator's guess. When the reply is 'it depends', you have found a decision point: mark it and come back to it later.
Who does that step, by job title and not by name?
Why ask it
Swimlanes are named for roles so the map survives a change of staff. When the answer is always somebody's first name, ask who does the step while that person is on vacation. If nobody can say, the step hangs on one individual, and that earns a note on the map.
How do you know it is time to do your part?
Why ask it
The reply shows the signal that moves work along: a system alert, an email, a paper tray, a colleague walking over. Signals that rely on someone remembering or noticing are where work can sit unseen for days. Draw the signal on the arrow between the two steps.
What do you need in front of you before you can start this step?
Why ask it
These are the inputs: documents, data, an approval, a part. For each one, find out where it comes from and how often it turns up incomplete. A step that regularly starts without everything it needs explains a good deal of the rework you will hear about later.
What do you produce at this step, and where does it go?
Why ask it
Every output should be somebody's input further along. If the person cannot say who reads the report or opens the file, check with the supposed recipient after the session. An output with no reader is one of the easiest things to stop producing.
Can you show me the last one you did?
Why ask it
A real case beats a remembered one, because people leave out the steps they no longer notice themselves doing. Watch at the desk or over a shared screen and say what you see: 'you just opened a second window, what was that for?' If the work involves personal or confidential records, check first what you are permitted to look at.
Is there a written procedure for this, and how closely does the real work follow it?
Why ask it
Make clear this is not an inspection, or you will be told the procedure is followed to the letter. A gap usually means the document has aged, not that people are careless. Get a copy and mark the differences on it together with someone who does the work.
Which steps can happen at the same time, and which have to wait for another to finish?
Why ask it
A numbered list of steps hides this, and it changes both the shape of the map and the total time. Steps done one after another only out of habit are an opening for improvement. Where one truly depends on another, write the reason beside the arrow.
What do you do here that nobody told you to do, but that keeps things from going wrong?
Why ask it
This draws out the private checks that hold a process together: the call to confirm an address, the second look at a total. A redesign that does not know about them removes them by accident. Give each one its own box, even if it takes ten seconds.
Handoffs and systems
When you pass the work on, how does the next person find out it is theirs?
Why ask it
A handoff with no announcement is a place where work goes quiet. Compare this with what the next person told you about knowing when to start, since the two accounts should describe the same signal. Where they do not match, you have found a gap neither side can see.
What does the next person most often come back and ask you for?
Why ask it
Repeated questions across a handoff mean the work arrives short of the same thing every time. Put the question to the receiver as well and see whether the two lists agree. The remedy is often small, such as one more field on a form.
Which systems or tools do you open during this step, and in what order?
Why ask it
List each one against the step where it is used, email and the phone included. Count the switches: a step that needs four applications has four chances to copy something across wrongly, however quick each screen is. Record the name people actually say for each system, because the official one may mean nothing to them.
Where do you type in something that already exists in another system?
Why ask it
Rekeying is easy to miss because the people doing it have stopped thinking of it as a step. It costs time, and it is where typing errors get into the record. Note which two systems are involved, as that is the first thing an IT team will want to know.
What do you keep outside the official system, such as a spreadsheet, a notebook or sticky notes?
Why ask it
Ask without judgment, because a side spreadsheet nearly always covers something the system does not do. Find out what it tracks and who else relies on it. That is a requirement nobody wrote down, and the spreadsheet belongs on the map as a step.
Which forms, templates or documents travel with the work?
Why ask it
Collect a blank copy and a filled-in copy of each. The filled-in one shows which fields are skipped, which are used for something other than their label, and what gets written in the margin.
Who is told or copied in along the way, even though they do not act on it?
Why ask it
Information moves through a process as well as work, and it rarely gets drawn. A long copy list sometimes records an old grievance, where someone was once left out and has been copied ever since. Ask one of those recipients what they do with the message.
Where does the work sit between you and the next person: an inbox, a queue, a shared folder?
Why ask it
Every resting place is a spot where items can age unnoticed. Ask who watches it and how they choose what to take first, whether oldest, loudest or easiest. Draw the queue with a symbol of its own so the waiting shows on the map.
At which points does the work go outside the organization, to a supplier, a customer or an agency?
Why ask it
Once work leaves, your team can only wait and chase, so these points often set the pace for everything else. Record how the request goes out, how the reply comes back and who follows up when it does not. Response times depend on the agreement with that party, so ask whoever manages the relationship what the agreement actually says.
Decisions and exceptions
Where in this process does someone have to choose what happens next?
Why ask it
Each choice is a diamond on the map, with one arrow out for every possible answer. Go back to any step where you heard 'it depends' or 'usually' and ask it there. A process described with no decisions in it has probably been told to you as the ideal case.
What exactly do you look at to make that decision?
Why ask it
You want the rule in a form someone else could apply: an amount, a date, a customer type. 'I just know' is honest and means the rule lives in experience, so ask for two recent cases that went different ways and what set them apart. Write the criteria on the arrows leaving the diamond.
Who has to approve this before it can move on, and what are they checking for?
Why ask it
An approval is a decision made by someone outside the flow, and it comes with a wait. Ask the approver how often they send something back. If the answer is almost never, find out what the sign-off is there to prevent before anyone proposes removing it, because a policy may require it.
Which checks or inspections happen along the way, and how often do they find something?
Why ask it
Ask what is compared with what, who does the checking, and what happens to an item that fails. A check that keeps catching the same fault is working, and it is also pointing at the earlier step where the fault is made. Note how far the item had traveled before it was caught, since a late catch means more to undo.
What do you do when what you receive is wrong or incomplete?
Why ask it
Listen for whether the person sends it back, fixes it themselves or works around it. Quiet fixing keeps things moving and hides the fault from the step that caused it, so the same error keeps arriving. Draw the return loop even if it is used only now and then.
Which cases do not fit the normal route, and what happens to them?
Why ask it
Rush orders, special customers and odd product types tend to follow a path that lives in one person's head. Get a name for each exception and one sentence on how it is handled. Then decide with the group which ones are common enough to draw.
How often does that exception come up: daily, weekly or a few times a year?
Why ask it
Frequency decides how much room an exception earns on the map. Something that happens twice a year gets a footnote, while one that turns out to be a third of the work is really a second process. Treat the figure as an estimate until you can check it against a log or a report.
When something goes wrong that you cannot fix yourself, who do you take it to?
Why ask it
This draws the escalation path, which is often a person and a phone call and not a procedure at all. Ask what that person can do that the asker cannot: override a system, approve a cost, call the customer. It also gives you one more reviewer for the draft map.
What happens when the system is down or the person who normally does this is away?
Why ask it
Backup arrangements show how fragile a step is. Paper forms kept in a drawer, a colleague who 'sort of knows how', or work that simply stops are all worth recording. Ask when it last happened and what catching up looked like.
Is there a rule, policy or regulation that says this step has to be done this way?
Why ask it
Some steps exist because a law, a contract or an auditor requires them, and some because of a memo nobody can find. Do not try to settle which in the session. Mark the step and ask whoever owns compliance or policy at your organization to point to the source, since requirements differ by industry and place.
Time and volume
How many of these come through in a typical day or week?
Why ask it
Volume turns a complaint into a size. A ten-minute annoyance on five items a week and the same annoyance on five hundred are different problems. If the system can report the count, use that and keep the room's estimate only as a cross-check.
How long does this step take when you are actually working on it?
Why ask it
This is hands-on time, and people usually know it well for their own step. Ask for a normal case and a hard one instead of an average, and write the range under the box. Say plainly that you are timing the work and not the worker.
How long does one case take from start to finish, counting the time it spends waiting?
Why ask it
Add up the hands-on times you collected and set the total beside this figure. The difference is waiting, and it is often much the larger part. Pull the dates for a handful of real cases if you can, since memory favors the smooth ones.
Where does work wait the longest, and what is it waiting for?
Why ask it
The room usually agrees on the spot within seconds. The second half matters more: a wait for a person, a batch run, a signature or outside information each calls for a different remedy.
How often does work come back to you to be redone, and what is the usual reason?
Why ask it
Rework is drawn as a loop back to an earlier step, and it makes the real process longer than the one on paper. Ask for the top two or three reasons, not every one. A rough share, such as one in ten, is enough to rank the loops against each other.
Are there busy times of the day, month or year, and what changes when they come?
Why ask it
Month-end, a seasonal rush or Monday mornings can turn a process that works into one that does not. Find out which steps get skipped, shortened or handed to temporary help under pressure. If the map shows only a calm week, say so on it.
How much unfinished work is usually sitting in this process at any one time?
Why ask it
A count of open items, taken on the day, is a quick health measure that needs no stopwatch. Set it against how many are finished in a week to see roughly how long a new item should expect to wait. A pile that only ever grows means more is arriving than leaving.
Does anyone measure this process today, and what do they count?
Why ask it
Existing measures save you from building your own, and they show what management watches. Check what the number includes: a turnaround time that starts when the file is opened leaves out however long the request sat before that. Ask the people in the room whether they trust the figure.
What to change
Which part of this process frustrates you most?
Why ask it
Save this until the map is mostly drawn, so the answer can be pinned to a step. Frustration points at waste the person can feel but may not be able to name. Mark the spot in a different color and move on without debating the fix yet.
If you could change one thing about this process tomorrow, what would it be?
Why ask it
Limiting it to one forces a ranking and keeps the session from becoming a wish list. Go around the room so quieter people get a turn, and notice where several of them pick the same step. Ideas go on a separate sheet, so the map stays a record of what happens now.
Is there a step here that you think nobody would miss if it stopped?
Why ask it
It gives permission to name work that looks pointless from the inside. Sometimes the person is right, and sometimes the step protects someone downstream they have never met. Take each nomination to whoever receives that step's output before deciding.
What has been tried before to improve this, and what became of it?
Why ask it
Earlier attempts explain both the scars and the skepticism in the room. Learn why a past fix faded, whether the system could not support it, a manager left or it added work for one team. Proposing the same idea again without knowing that history costs you credibility.
What works well here that a redesign must not lose?
Why ask it
Asking it shows the session is not only a hunt for faults, which makes people more open for the rest of it. The answers are often relationships and judgment calls, such as a clerk who knows which customers to phone. List them beside the map as things to protect.
Looking at the map now, what did we get wrong or leave out?
Why ask it
Ask it standing at the wall with the whole map visible, and wait longer than is comfortable. People correct a drawing more readily than they volunteer a description. Every correction made here is one that will not be made in front of the sponsor.
Who else should see this before we call it finished?
Why ask it
A map built with one shift, one site or one team shows that group's version. The names you get are your review list: send the draft, or walk it past them at their desks. Date the map and state who contributed, so readers know whose account it is.
How to run a mapping session with these questions
Practical guidance for the conversation itself
Before anyone picks up a marker
Settle the edges with the sponsor first
Put the first two questions on this page to whoever requested the map before the session, and write the trigger and the end point at the top of the invitation. A session that opens by debating scope spends its first hour there. If the team later disagrees with the sponsor about the edges, that is worth knowing, and it goes back to the sponsor to settle.
Invite the people who do the work
One person from each role that touches the process is the aim, including the roles on either side of every handoff. Managers help with the Start and end group and with policy, but a room where the manager answers for everyone produces the process as it was designed. If a manager's presence quiets the room, talk to them separately and map with the doers.
Choose the level of detail
A map that explains the process to a new director needs a dozen boxes. A map for finding lost time needs every handoff and every wait. Decide which you are drawing, tell the group, and use it to turn detail away politely: 'that is below today's level, and I have noted it.'
Say what the map is for
People answer more freely when they know whether this is about a new system, a cost target or a recurring complaint. If jobs could be affected, do not promise otherwise: say what you know and who decides. A reassurance that nobody is being graded only helps if it is true.
Ask for two real cases
Have someone bring one recent, ordinary item with its emails and forms, and one that went badly. Following the ordinary one keeps the step questions concrete. The bad one will carry you through the Decisions and exceptions group.
While the map is going up
Draw what happens, not what should
The current state comes first, flaws and all. When someone says 'well, we are supposed to', write both versions and mark which one is real. A workaround that everybody uses is the process, however unofficial, and it goes on the wall in the same color as everything else.
One step per note, verb first
'Check credit limit' is a step. 'Credit' is a department. Sticky notes, or their on-screen equivalent, let the group move a step when someone remembers that it comes earlier, which will happen several times.
Leave the numbers for a second pass
Stopping at every box for durations and counts breaks the rhythm of 'and then what happens'. Get the sequence, the roles and the handoffs up first. Then walk the wall again with the Time and volume group, writing hands-on time under each box and waiting time on each arrow.
Give exceptions somewhere to wait
The first exception anyone raises can swallow twenty minutes if you let it. Write it at the side with a name, finish the usual route, then return with the frequency question to decide which exceptions get drawn.
Go and look
When a step is described vaguely, ask to watch it being done, at the desk or on a shared screen. A few minutes of watching tends to add things the discussion left out, such as a lookup in a second system or a note kept on paper.
From the wall to a finished map
Separate measured from estimated
Volumes and times given from memory are useful and soft. Label them as estimates on the map, and replace the ones that matter with figures from a system report or a small sample of real cases before anyone builds a business case on them.
Check each handoff from both sides
For every arrow that crosses from one role to another you should have the sender's account and the receiver's. Where you have only one, get the other before the map goes out. The places where the two accounts differ are usually the most useful findings on the page.
Walk the draft back to the people in it
Redraw the map cleanly, then show it to the participants and to the names the last question on this list gave you. Have each of them trace a recent case along it with a finger. Anywhere the case leaves the lines is a correction.
Hand over the map and the ideas as two things
One is the current-state map with the pain points marked on it, and the other is the list of changes people proposed. Choosing what to change belongs to a later conversation with the process owner, and that conversation goes better when nobody is still arguing about what happens today.
Where mapping sessions go wrong
Mapping the procedure document
Be a little suspicious of a map that matches the written procedure exactly. Either the process is unusually well kept, or the room told you what it thought you wanted to hear. Ask to see the last real case.
Solving while mapping
As soon as a problem shows, someone proposes a fix and the room starts to debate it. Note the idea and return to the map. A fix designed before the whole flow is visible often just moves the problem one step downstream.
Letting one voice draw the whole map
A confident person can narrate the entire process, including the parts they have never done. Send each question to the role that does the step: 'this one sits with accounts payable, so what do you do first?'
Going too deep too soon
A wall covered in notes with no end point in sight helps nobody. If the wall is full before you are halfway through the process, you are a level too deep. Finish the route at a higher level first, then pick the one or two stretches that deserve a closer map.