Current-State Process Map

What this does

Turns interview notes and documents into a written current-state description of how a process actually runs today - stages, who does what, where work changes hands, where it hurts, and where time or quality leaks out. It maps the process as people described it, not as the procedure manual says it should be, and it flags every stretch nobody could explain.

What you give it

• Interview notes from the people who run or touch the process, pasted or attached
• Any documents - procedures, forms, system screenshots, emails that show how work really moves (optional)
• The process boundaries - where it starts and where it ends, in a sentence (optional - you'll be asked if it's unclear)
• Known trouble spots you already want examined (optional)

How it does the work

1. Read every source before mapping anything.
2. Ask up to 3 short questions if essentials are missing - where the process starts and ends, which variant to map if there are several, or whose account to weight when two sources conflict. Then proceed.
3. Fix the boundaries first: the trigger that starts the process and the outcome that ends it. Everything in between is in scope; everything else is noted and set aside.
4. Identify the stages - the 4-8 major chunks of work between trigger and outcome. Name each one by what happens in it, in the words the interviewees used, not textbook process language.
5. For each stage, capture from the evidence: who does the work (roles, not just names), what they actually do, what they need to start, and what they pass on. Where sources conflict - and they will - record both versions and mark the conflict [to confirm] rather than picking a winner.
6. Map the handoffs explicitly - every point where work moves between people, teams or systems. Handoffs are where processes fail, so each one gets its own row: what's handed over, how, and what the receiving side said about what arrives.
7. Log the pain points where the evidence puts them: rework loops, waiting, double entry, workarounds, things done "because we've always done it". Attach each to its stage and quote or cite the evidence.
8. Assess where time and quality are lost. Use only figures from the evidence - if someone said "that sits in the queue about a week", report it as their estimate. Never calculate or invent durations, volumes or error rates.
9. List the unknowns - stages nobody could describe, systems nobody named, the gap between the documented procedure and what people say happens. Mark each [to confirm]; these are the follow-up questions.
10. Draft using the output layout, then do a client-readiness pass: no blame on individuals, workarounds described as symptoms of the process rather than sins of the people. Show the draft and flag the biggest unknowns.

Output layout

# Current-State Process - [Process name]

**Scope:** starts when [trigger]; ends when [outcome]
**Based on:** [sources - e.g. 5 interviews, procedure doc, system screenshots]
**Date:** [date]

## The process at a glance
[Three or four sentences: what the process does, who's involved, and the one-line health check.]

## Stages
| # | Stage | Who | What happens | Pain points |
|---|-------|-----|--------------|-------------|
| 1 | [Name] | [Roles] | [Plain-words description] | [Pain, or "-"] |
| 2 | [Name] | [Roles] | [Description] | [Pain] |

## Stage detail
### Stage 1 - [Name]
**Who:** [roles]
**Needs to start:** [inputs]
**What happens:** [description, in the interviewees' terms]
**Hands over:** [output, to whom, how]
**Pain points:** [evidence-backed, or "None raised."]

[Repeat per stage.]

## Handoffs
| From | To | What moves | How | What the receiver says |
|------|----|-----------|-----|------------------------|
| [Stage/role] | [Stage/role] | [Item] | [Email / system / verbal] | [Evidence, or [to confirm]] |

## Where time and quality are lost
- [Loss, located at its stage, with the evidence - e.g. "sits about a week" per the team lead]
- [Loss]

## What we don't know yet
- [Unknown] [to confirm]
- [Documented procedure says X; interviews describe Y] [to confirm]

Rules

• Australian English with contractions - organise, prioritise, we'll, they've.
• Map what people described, not what should happen. The gap between the two is a finding, not an error to smooth over.
• Never invent durations, volumes, error rates or steps. Estimates are attributed to whoever gave them; everything else is [to confirm].
• Text only - tables and numbered steps, no diagram syntax. The written map is the deliverable; a drawn version comes later if wanted.
• Name roles, not people, in pain points. "Approvals wait on one role" is client-ready; "approvals wait on Sarah" is not.
• Keep interviewees' own words for stage names and pain points where possible - the client recognises their process faster in their own language.
• This skill describes the current state. Future-state design and recommendations are a separate piece of work - offer it, don't smuggle it in.