Everyone finished, and the result is still late
A pattern repeats in companies where every work handover crosses a department boundary. Asked individually, every team reports its own part complete and can show the evidence. Measured end to end, the order is days late and nobody can point to the day it was lost.
The usual conclusion is that the teams are not cooperating. The more precise conclusion is that the time was not lost inside any team. It was lost between them, at the handover - and a handover is the one piece of work that appears on no assignment chart.
An assignment chart divides by person; work travels across them
An assignment chart answers one question well: who is responsible for which block of work. It is drawn by partitioning people. Work, however, does not stay inside a partition - it enters at one boundary and leaves at another, and the boundary itself belongs to nobody.
Put the four beats of delegation from the first article in this series against that boundary - request, agreement, performance, acceptance - and the structure becomes visible. The acceptance beat of the person upstream is the request beat of the person downstream. They are the same moment seen from two sides.
A handover is one event that two people experience as two different things: the end of mine, the beginning of yours.
That is why the gap has no owner. The person upstream considers the work finished at the moment they stop; the person downstream considers it started at the moment they are told. Between those two moments the work exists, unassigned, and the organisation has no field in which to record it.
One event seen from two sides, with the waiting in between.
Three shapes of a broken work handover
The silent handover
Upstream finishes and changes nothing that downstream can see. The work waits until somebody happens to ask. Measured in a log, this is the single largest source of lost days.
The handover with no criteria
Downstream is told to start but not told what finished means upstream. They begin, discover a missing input halfway, and send it back. The loop runs twice.
The conditional handover
The work may only move after a check or an approval. Nobody owns the waiting, so the condition is discovered late, usually by the person who needed the result.
Three shapes, one shared property: the state lives in a memory.
All three share one property: the state of the handover lives in somebody's memory rather than in a field. Nothing turns red, nothing appears in a list, and the only detection mechanism is a person deciding to ask. In each case the work handover exists only as a memory.
Measure the waiting before changing anything
Two numbers settle most arguments about handovers. The first is touch time: the hours somebody actually worked on the item. The second is elapsed time: the hours between the order arriving and the order leaving. The gap between them is waiting, and in a flow that crosses three or four departments the waiting is usually the larger half by a wide margin.
Both numbers can be taken from data a company already has. Touch time is the sum of hours logged against the work. Elapsed time is the distance between the first and the last timestamp on the record, and the stage changes in between say where the time went, because each change is recorded with its date. Ranking the joints by waiting time takes an afternoon and decides which one to fix first.
The ranking matters because waiting does not spread evenly. One or two joints usually hold most of it, and they are rarely the ones people complain about - a loud dispute between two teams often marks a joint that is being watched, while the expensive one is quiet precisely because nobody is watching it.
Why adding a coordinator does not fix it
The common response is to appoint someone to chase the joints: a coordinator, a planner, a project assistant. The role works, and it has two properties worth naming before the budget is approved.
First, it is a polling loop run by a human. The coordinator learns that a handover is ready only by asking, so the delay is bounded by how often they ask, not by when the work became ready. Second, the cost grows with the number of joints, not with the volume of work - double the departments and the asking roughly doubles.
The structural alternative is to make the work handover itself a record: a state the system sets and clears on its own, and an obligation addressed to one person the moment the upstream work closes.
How Viindoo makes the joint run on its own
Four steps, none of which depends on anyone remembering.
The state of the joint is set by the system, not by memory
A task carries a Blocked By list and, on the other side, a Block list. While a blocking task is open, the dependent task sits in the state Waiting, and that state is computed rather than chosen - nobody sets it and nobody has to remember to clear it. When the last blocking task closes, the dependent task returns to In Progress by itself. The feature is switched on in Settings under Task Dependencies, per project.
The state changed to Waiting on its own, and the history records the change.
The same mechanism runs in the parts of the business that are not projects. In manufacturing, a work order whose predecessor is unfinished shows Waiting for another WO and turns ready on its own. In the warehouse, a transfer that depends on an earlier one shows Waiting Another Operation, and completing the first one reserves stock for the second without anyone intervening.
The same mechanism outside projects: the transfer waits until the one before it closes.
Finishing one piece of work creates the next
An activity type can be configured to trigger the next activity: marking the current one done creates the following one automatically, with its due date counted either from the completion date or from the previous deadline. For a sequence with more than two steps there are activity plans - a named list of steps launched in one click, where each step states who it goes to: a fixed person, or a role such as the employee's manager or coach.
Two filters that turn the joints into a list anyone can read.
Addressing the joint to one person
The piece that turns an automatic state into an owned obligation is an automation rule. The trigger Stage is set to fires when the upstream task reaches its final stage; the action Create Activity then creates work for the next person, and the assignee can be taken dynamically from a field on the record rather than fixed in the configuration. From that point the work handover has a name, a due date and a place in somebody's activity bell.
The rule that turns an automatic state into an obligation with a name on it.
Seeing which joints are stuck
The task list ships with two filters that exist for exactly this question: Blocked, for work waiting on something else, and Blocking, for unfinished work holding others up. The second list is the one to read in a stand-up, because every row on it is a joint with a queue behind it. On the Gantt view the dependencies are drawn as links, which turns the longest chain - the critical path - into something visible rather than inferred.
Drawn as links, the longest chain stops being something to infer.
Three limits belong here, because a plan built without them will leave the same gap in a new place.
The block is soft
A task in Waiting can still be marked done. The dependency keeps the sequence honest and visible; it does not physically prevent anyone from skipping it.
The next person is not notified by default
When the blocking work closes, the dependent task changes state quietly. Notification is not automatic in the standard configuration - it is the automation rule above that turns the change into a message addressed to someone.
An approval does not hard-stop the next step
Approval requests can be attached to a task, a transfer or a manufacturing order and their coverage is shown, but the standard behaviour does not physically block the next stage until the approval is granted.
Read together, the three say the same thing: the system removes the memory work and makes the joint visible, while the decision of who owns each joint stays a design choice the company has to make once.
Four questions to assess the current state
- For the last order that ran late, how many hours did it spend between two departments rather than inside one?
- When an upstream task finishes, what changes that the next person can see without being told?
- Can you produce, right now, the list of unfinished work that is holding other work up?
- Who owns the waiting time at your most frequent handover - and does that person know it?
Frequently asked questions
Cooperation determines how quickly a work handover is handled once it is noticed. It does not change how long it takes to be noticed, which is the part this article is about.
A stand-up is a polling loop with a period of one day, so a handover ready at nine in the morning waits until the next one. It is a good forum for the exceptions, provided the list of blocking work is on the screen rather than in people's heads.
No. Use dependencies where the sequence is real and the waiting is costly. Declaring dependencies everywhere produces a graph nobody maintains, which is a different way of losing the same information.
The same structure applies with one change: the obligation is addressed to the internal person who owns the relationship, not to the external party. Somebody inside has to own the waiting, or it is owned by nobody again.
With one joint: the handover that appears most often in late orders. Make its state automatic, give it a named owner, and measure the waiting time before and after. One joint is enough to show whether the mechanism pays.
Next in this series: why a company retypes work the system already holds, and what it costs when a card and an order start living two separate lives.
Measuring it on one joint
The argument is testable on a single work handover. Send the one that appears most often in late orders and we will set up its dependency, its automatic state and its named owner on a live system, then compare the waiting time against what it is today.
