Hierarchical breakdown reveals subtasks and preconditions
Aliases: hierarchical task analysis · subtask breakdown · task preconditions
What it is
“File the expense” looks like one step. Broken open it is: gather receipts, receipts must fall inside the dates the system allows, a project code must already exist, and if it does not someone in finance must create it first. Hierarchical task analysis splits a goal into subtasks and writes what must already be true before a subtask can start. A breakdown with no preconditions is a step list. It will record “couldn’t” as “didn’t know how.”
Why it happens
In fluency, people compress preconditions into a feeling: the folder “should” already hold the invoice. Failure is often not a wrong tap but a condition that never obtained—the invoice is in someone else’s mail, the project was never opened. Hierarchy keeps “what for” on the upper level and “which smaller achievements” below, so one level can be checked on its own. A precondition is a gate between levels: if it is shut, skill on the level below cannot enter. Drawing the gate separates missing skill, missing permission, missing material, and missing timing.
Studying it
Build a goal–subtask tree for one real completion (including failure) and mark, at each node, the state that must already be true. Check against observation: did the person stall on an action or on an unmet condition? Compare “steps only” with “steps plus preconditions” on attribution of the same failure. Outcomes: conditions that operated but were never written, and whether operators are still scored as in error when a condition is false.
Where it stops holding
One-off, highly improvised creative work yields a fake stable tree if forced; post-hoc narrative fits better than a normative breakdown. On team tasks, preconditions may be held by different people; the tree should name who holds each condition, or it will be drawn as one person’s skill problem. After automation swallows some subtasks, the visible tree gets shallower while preconditions may get harsher (must be online, must have an account). The breakdown must not shorten merely because fewer actions are seen.
Applying it
- Split every upper goal into subtasks, and write for each “what must already be the case before this starts.”
- In shadowing, log a pause as “condition?” before “can’t”; if missing material, permission, or timing can be named, do not write an operator error.
- In design review, put the tree on the table and ask whether the new scheme kills actions or conditions. Fewer taps with the same gates still will not file the expense.
- Walk one failure down the tree: stop at the first unmet precondition and list that gate as the problem, rather than painting the whole tree red.