Map both data dependencies and resource dependencies…

When mapping workflow dependencies, draw arrows for both input-output dependencies and resource dependencies (shared attention, tools, or collaborators), since steps sharing scarce resources are effectively sequential even if outputs are unrelated.

When This Fires

When a parallelized workflow still takes as long as a serial one (hidden resource contention)
When mapping dependencies and wanting a realistic rather than theoretical critical path
When delegating work and needing to understand who or what becomes the bottleneck
Complements Dependency test for adjacent steps — does step B require… (data dependency test) with the resource dimension of dependency

Common Failure Mode

Treating theoretical parallelism as actual parallelism: "These three tasks are independent, so I'll do them in parallel and save 60% of the time." But all three require deep focus from the same person (you), so they serialize anyway. The workflow diagram shows parallelism; the execution shows context-switching overhead that makes it slower than serial execution.

The Protocol

(1) After identifying data dependencies (Dependency test for adjacent steps — does step B require…), do a second pass for resource dependencies. (2) For each pair of "parallel" steps, ask: "Do these steps compete for the same scarce resource?" Resources to check: your focused attention, a specific tool or system, a specific collaborator's time, a physical space. (3) If yes → draw a resource-dependency arrow (use a different color/style than data-dependency arrows). These steps are effectively sequential for scheduling purposes. (4) Identify the true critical path: the longest chain considering both data and resource dependencies. This is your realistic minimum duration. (5) Resource dependencies can be broken by adding capacity: delegating one task, getting a second tool license, or batching low-attention tasks alongside a high-attention one.