Make work visible: tracking status and turnaround time
You documented your processes, decided who owns each step, then connected the steps into an approval chain that moves on its own. You now have a well-designed path. One question the design alone cannot answer remains: is the path really flowing the way you drew it? Where is each request right now, and how long does it take to finish? This lesson is about making work visible and measuring its turnaround — the first step in operating what you organized, not merely sketching it.
What visible work means
Work is visible when, at any moment, you can answer three questions about any request without asking anyone: where is it now, who is it waiting on, and since when. If the answer needs a phone call or a hunt through scattered chats, the work is invisible, and you are managing from people's memory instead of a written reality. The first thing visible work buys you is catching a stuck request before its owner complains, not after.
Turnaround time: the metric that exposes bottlenecks
Turnaround time is the span from the moment a request opens to the moment it closes for good. But a single number is not enough on its own, because what matters is how it splits across the steps: how long the request sat in each step separately. The total says the process is slow; the split says exactly where it slows, and therefore where to fix it.
A concrete example
A purchase request comes in Sunday 9:00 and leaves approved Tuesday 11:00 — about two working days. Split the time across the steps and the truth appears:
| Step | Entered | Left | Duration |
|---|---|---|---|
| Receipt and check (Purchasing) | Sun 9:00 | Sun 10:00 | 1 hour |
| Line manager approval | Sun 10:00 | Sun 11:00 | 1 hour |
| Finance manager approval | Sun 11:00 | Tue 10:30 | ~1 full working day |
| Issue purchase order | Tue 10:30 | Tue 11:00 | 30 minutes |
Three steps finished in two and a half hours; one step took a whole day. The total blames the entire process, but the split reveals that a single step — finance approval — is the bottleneck. You cannot fix what you do not measure: without this table you might redesign the whole path while the problem is one step.
The status board: where every request stands now
Turnaround measures the past; a status board shows you the present. Give each request exactly one known status from a fixed, agreed list, so a glance tells you where everything stands:
- Incoming: received, not yet picked up.
- Under review: someone is checking it now.
- Awaiting approval: sitting at an approver's gate.
- Approved and in progress: cleared and being executed.
- Done: closed, nothing left.
- Rejected or returned: sent back with a written reason.
The golden rule: every request has exactly one status at any moment, and every status change records who changed it and when. Then the board becomes the single source of truth, and no two people disagree about where a request has reached.
What to do with the numbers
Measurement without a decision is ink on paper. Turn what you see into improvement:
- Set a target time for each step, not only for the whole path — a single overall target hides the slow step.
- Watch the step that always misses its target, not the one that was late once; repetition is a structural flaw, not chance.
- At a bottleneck, pick one clear remedy: a backup approver for the absent one, a raised limit that needs no approval, or branching the path by size.
- Review the numbers at a fixed weekly time — a metric nobody reviews dies.
Quick checklist
- Does every request have exactly one known status right now, from a fixed list?
- Is every status change recorded with who and when?
- Do you know the time of each step, not just the total?
- Does each step have a target time to compare against?
- Do you review the numbers at a set time and act on them?