Map both data dependencies and resource dependencies — steps sharing scarce resources (attention, tools, people) are effectively sequential
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.
Why This Is a Rule
Dependency test for adjacent steps — does step B require the completed output of step A? If not, they can run in parallel's dependency test ("Does B require A's output?") catches data dependencies — step B needs step A's information to proceed. But there's a second category of dependency that's equally binding and far easier to miss: resource dependencies. Two steps can be logically independent (neither needs the other's output) but practically sequential because they compete for the same scarce resource.
The most common scarce resource in personal workflows is attention. "Draft the proposal" and "review the budget spreadsheet" have no data dependency, but both require focused cognitive attention. You can't literally do both simultaneously — one must wait while the other runs. Similarly, steps requiring the same physical tool (a shared instrument, a single-user software license), the same collaborator (waiting for the same person's input), or the same physical space are effectively sequential regardless of data independence.
In project management, this is the distinction between finish-to-start constraints (data flow) and resource leveling (resource contention). Ignoring resource dependencies produces workflows that look parallelizable on paper but serialize in practice because the executor is a single-threaded processor for high-attention tasks. Goldratt's Theory of Constraints applies here: the binding constraint is often not information flow but resource availability.
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 the completed output of step A? If not, they can run in parallel (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 the completed output of step A? If not, they can run in parallel), 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.