Total time is determined by the critical path, not the sum of all operation times

What it is

In a parallel model, a task's total time is the length of the longest dependency chain, the critical path: from start to finish, every activity's start depends on the previous one finishing. Time on parallel branches does not stack; only the chain that determines the finishing moment counts toward the total. This card follows directly from "perceptual, cognitive, and motor resources can be occupied in parallel during skilled performance": that card explained why parallelism happens; this one explains how total time should actually be computed once it does — not by adding up every activity's time, but by looking only at the chain that genuinely gates the finishing moment.

Why it happens

Drawing a critical path starts with distinguishing exactly which kind of dependency sits between two activities, because the type determines whether they can run in parallel at all: a data dependency means the next step needs a result the previous one produced — you must see the search results before you can click one of them — and this kind of dependency is inherently serial. A resource dependency means two activities compete for the same processor — the hand cannot move toward the keyboard and the mouse at once, visual focus cannot look at two places simultaneously — and this also forces seriality. An external dependency means an activity must wait on something outside the user's control, like a system response. Only when two activities share neither a data dependency nor a contested resource can they genuinely run in parallel. The critical path is what you get by chaining all these dependencies together and finding the longest one from task start to finish — every delay on that chain propagates directly to the final finishing moment, while an activity off the chain, however long it takes, has zero effect on when the task ends as long as it does not exceed the slack the chain leaves for it.

Where it stops holding

The critical path itself is a result derived from a dependency graph, and if that graph is drawn wrong — mistaking two genuinely independent activities for a resource conflict, or missing a real data dependency — the computed critical path will be wrong too. That is not a flaw in the model; it is a flaw in the modeling input, and it can only be fixed by observing the task closely enough to verify whether each claimed dependency actually exists. The critical path also shifts whenever the user's strategy changes: for the same task, if a user switches from "scan the whole list before deciding what to click" to "click the first roughly matching item seen," the original data dependency may be broken, and the critical path needs to be redrawn. System retries, network fluctuation, and mid-task interruption similarly reshape the dependency structure temporarily — all reminders that a critical path drawn once should not be treated as a fixed truth, and a theoretically derived parallel relationship must be verified against real skilled-user data rather than left as paper analysis.

Applying it

• Draw a complete activity dependency graph for a high-frequency task, labeling clearly for every pair of activities whether the link is a data, resource, or external dependency — do not write a vague "related."
• Compute the critical path from the graph, and also compute how much slack each non-critical branch has, ranking the results by whether slack exists at all.
• Move system responses that can process in the background, and preloading or hint content that can happen ahead of time, off the critical path wherever possible, turning them into non-critical activities with slack.
• How to check: verify the model's derived critical path against a timestamped operation log to confirm it genuinely corresponds to the real finishing moment — if the log's actual finishing time does not match the predicted critical-path length, the dependency graph has an omission or a wrong judgment somewhere, and that needs fixing, not doubt cast on the concept of a critical path itself.

Related

• Same group: B4.13.1 Perceptual, cognitive, and motor resources can be occupied in parallel during skilled performance · B4.13.3 Shortening an operation off the critical path does not change total time · B4.13.4 The model applies only to highly skilled performance; novice behavior is not parallel · B4.13.5 Critical-path analysis explains why removing steps did not make the task faster
• Nearby: B4.04 GOMS · I1 State, Time, and Response
• Search terms: critical path · dependency graph · parallel task time · resource contention