Process mapping makes a workflow visible so people can check how work actually moves between steps and owners. Learn to define the boundaries, observe the current process, show decisions and handoffs, and propose a measurable improvement. This roadmap maps a fictional equipment-repair request. Your output should distinguish the current workflow from a proposed one, including waiting and rework rather than only the tidy sequence described in a policy document.

Set boundaries and observe the current process

Define the start as a customer submitting a repair request and the end as receiving a collection notification. Keep payment and later warranty work outside this first map unless they directly affect the chosen process. Identify the requester, reception, technician, and collection coordinator. A map becomes difficult to review when its scope expands each time someone remembers another related activity.

ASQ describes flowcharts as representations of process steps, decisions, inputs, and relationships Source 1. Begin with that simple vocabulary. Observe or simulate several cases and ask the people doing the work what happens when information is missing. A written procedure may describe the intended path while actual cases include workarounds and repeated clarification.

Draw actions, decisions, and handoffs

Use a start marker, action boxes, decision diamonds, and labelled arrows. Organise lanes by role if ownership matters. Write actions as verbs: receive request, check details, inspect item, notify customer. A box labelled “technician” names a person rather than describing a step. Keep symbols consistent and add a small legend if the audience needs one.

For the fictional current process, reception receives a request, checks the item description, and sends incomplete requests back to the customer. Complete requests go to a technician, who diagnoses the issue and returns the outcome to reception. Reception then sends a collection message. Show the missing-information loop explicitly rather than drawing every request as if it succeeds first time.

AHRQ’s workflow toolkit is designed for health IT, but illustrates the importance of understanding workflow before changing a system Source 2. Apply the general observation habit to this non-clinical exercise. Do not import healthcare-specific rules or imply that a simple repair map qualifies you to redesign clinical processes.

Use fictional timings to locate a question

Assign invented timings to one straightforward case: five minutes of reception work, twenty minutes of technician work, five minutes preparing the message, and two hours waiting between handoffs. Total active work is thirty minutes; elapsed time is 150 minutes. State that these values describe one simulated case, not a service average.

The map suggests investigating waiting, but it does not prove that reception is inefficient. The technician may be batching work, equipment may be unavailable, or the queue may reflect staffing. Record these as possible explanations. Do not remove a checking step merely because it consumes time; it may prevent errors or protect the customer.

Propose one small change: a clearer request form that asks for the item type and problem description before submission. The expected mechanism is fewer clarification loops. Define a pilot measure such as the count of requests returned for missing information, alongside any unintended burden on customers. This is a hypothesis to test, not an already achieved improvement.

Validate the map and compare the proposal

Walk through the current map with each role and trace a normal case, an incomplete request, and a request that cannot be repaired. Label decision exits with meaningful outcomes. If a case reaches a box with no onward route, investigate whether the map is incomplete or the actual process lacks a defined response.

GOV.UK’s guidance on working across organisational boundaries emphasises collaboration when a journey spans teams Source 3. Even in this small exercise, handoffs need shared understanding. Record who owns the request while it waits and who handles an exception. A diagram without ownership can make a problem visible while leaving nobody able to act on it.

Deliver the current map, proposed map, timing assumptions, review notes, and pilot plan. Keep the versions distinct and date them. Your next learning step is mapping an authorised real process with actual observations, where you can compare several cases and test whether the proposed change improves the intended outcome.

Practice sequence
  1. ScopeAgree the start, end, and roles.
  2. ObserveFollow normal and exception cases.
  3. MapShow actions, decisions, waits, and loops.
  4. ImproveTest one change against a defined measure.
Practice decisions and evidence
Checkpoint What to produce How to review it
Boundary Request received to collection notice Payment remains outside this scope
Ownership Reception, technician, coordinator Every handoff has a responsible role
Timing 30 active + 120 waiting = 150 minutes One fictional case, not a benchmark
Pilot Clearer information at intake Measure clarification loops and customer burden
Evidence before advancement
Current state
Missing details cause a clarification loop.
Proposed change
Collect item type and problem description at intake.
Evidence needed
Fewer incomplete requests without creating new access problems.

Common questions

Is a process map the same as a procedure?

A map shows the sequence, decisions, and relationships visually. A procedure may explain detailed instructions for performing a step. They can complement each other. Do not force every instruction into one diagram; link to supporting detail when needed while keeping the map readable enough to reveal handoffs and loops.

Should I map the ideal process first?

Start by understanding the current process so the proposal addresses real problems. Keep the desired future version separate and label it clearly. Otherwise reviewers may mistake an aspiration for an observed workflow. A useful comparison shows which steps change, why they change, and what evidence would demonstrate an improvement.

When should I use swimlanes?

Use lanes when responsibility and handoffs are important to the question. They help show where work moves between reception and the technician in this exercise. A simple single-role process may not need them. Choose the representation that helps the reader inspect the workflow rather than adding notation for its own sake.

Can waiting time identify the bottleneck automatically?

It identifies a place to investigate, not necessarily the cause. Waiting may reflect capacity, batching, dependencies, missing information, or a deliberate control. Collect several relevant observations before making a broad claim. In the fictional case, two hours of waiting is an assumption used to practise distinguishing elapsed time from active work.

Should every checking step be removed as waste?

No. A check may prevent errors, meet a requirement, or protect people and resources. Understand its purpose and evidence before proposing removal. You might simplify duplicate checking or improve its timing, but do not assume that a step is unnecessary merely because it does not visibly transform the item being repaired.

How detailed should the map be?

Detailed enough to answer the improvement question and reveal important decisions, owners, and exceptions. If it becomes unreadable, separate a high-level map from a more detailed sub-process. Avoid mixing one broad stage with tiny keystroke-level actions in the same view unless that difference is necessary to explain the problem.

How do I validate a process map?

Walk through real or clearly simulated cases with the people responsible for each stage. Ask what happens when information is missing, an item cannot be repaired, or a handoff fails. Compare their answers with the diagram and record disagreements. A neat drawing is not validated until its routes match the process being described.

What should the portfolio demonstrate?

Show scope, observations, the current map, a justified proposal, and a way to measure the change. Include a normal case and an exception path. Label invented timings and avoid claiming savings you did not observe. A reviewer should see how the map supported reasoning rather than only your ability to draw process symbols.

Continue your learning

Requirements Gathering Roadmap: Turn Stakeholder Needs into Testable Statements. No-Code Automation Roadmap: Design and Test a Simple Business Workflow.

Sources and further reading