Waiting, Blocked and Dependent
Time that does not appear as work and is not free either. The category most records handle worst and the one that explains the most about long projects.
You cannot proceed until somebody answers, approves, delivers or decides. The hours exist, they are not yours, and no ordinary tracking method handles them. Teams investigating the same pattern can use the e-commerce overview to see where working time is being absorbed, then discuss the surrounding process; the record should reveal friction without turning ordinary pauses into a performance verdict.
Why they are hard to record
They are not an activity, so a diary has nothing to write.
They overlap with other work — you do something else while waiting — so they are invisible in any method that records one thing at a time.
And the cost is not the duration of the wait but the switching and re-entry it forces.
A three-day wait costs almost nothing if you moved on cleanly and costs a great deal if you kept checking.
Recording them usefully
Track them as states, not as activities: a separate list of what is currently blocked, with a date.
Two figures per item: how long blocked, and how many times you touched it while blocked.
The second number is the real cost, and it is invisible in any time total.
This list takes a minute a day and is the only way to see the problem.
What it reveals
The same dependency recurring: one person, one approval, one system.
Work that was started before it could proceed, which is a planning finding rather than a waiting one.
And the pattern of how long things actually take to come back, which is the input to realistic estimates and is usually much worse than assumed.
The multitasking illusion
Waiting time feels free because you fill it.
But the filling is unplanned, fragmented work — the worst kind — and the interruption when the answer arrives costs again.
Which is why weeks with many blocked items feel exhausting and produce little, and why the time totals do not explain the feeling.
What actually helps
Batch the chasing. One pass a day over the blocked list instead of checking continuously.
Ask for a date rather than an answer when you first request something. "When can I expect this" converts an open wait into a scheduled one.
Start fewer things. Most blocked lists are long because too much was begun in parallel.
And have a designated second task so that being blocked moves you to a known place rather than to whatever is nearest.
What does not help
Following up more often. It rarely accelerates and reliably fragments your own day.
Working around the dependency, which frequently produces work that has to be redone.
And treating it as a personal efficiency problem when it is a dependency structure problem.
The finding for long projects
Elapsed time on a long project is mostly waiting, and effort is a small share of it.
Which means a project that took three months may contain two weeks of work, and estimating the next one from elapsed time will be wildly wrong in one direction and from effort wrong in the other.
Record both separately. Its own note in the work section covers estimating from your own data.
What to check
Do you have a list of what is currently blocked, with dates?
How many times did you touch the top item this week without progressing it?
Does the same dependency appear repeatedly?
And when you last requested something, did you ask when to expect it?
The number that is the real cost
Not how long something was blocked, but how many times you touched it while blocked.
That figure is invisible in any time total and explains why weeks with many blocked items feel exhausting and produce little.
Worth keeping in mind
Ask for a date rather than an answer when you first request something. When can I expect this converts an open wait into a scheduled one, and it costs nothing at the moment of asking.
In short
Ask for a date rather than an answer, batch the chasing into one daily pass, and start fewer things.
Most blocked lists are long because too much was begun in parallel rather than because other people are slow.
The point
Track blocked items as states rather than activities: a list of what is currently blocked, with a date and a count of how many times you touched it.. For a complementary perspective on work, measurement or planning, consult Harvard Business Review.