---
title: "Hierarchical Task Analysis vs. Cognitive Work Analysis — Theory, Methodology and Contribution to System Design"
type: source
tags: [task-analysis, human-factors, observation, elicitation, hta, cwa, methodology]
authors: [Salmon, Paul; Jenkins, Daniel; Stanton, Neville; Walker, Guy]
year: 2010
venue: "Theoretical Issues in Ergonomics Science 11(6):504–531"
kind: paper
raw_path: "raw/Task Analysis & JTBD/Hierarchical task analysis (2010).pdf"
sources: []
key_claims:
  - "HTA describes systems normatively via goals, plans, activities; CWA describes formatively via constraints."
  - "HTA procedure (Stanton 2006 Fig 1): state overall goal → state subordinate operations → state plan → check adequacy → recurse on subops until redescription not required."
  - "HTA data collection: observation + SME interviews + walkthroughs + user trials + documentation review — no single method; iterate."
  - "Task decomposition categories (Kirwan & Ainsworth 1992): initiating event/cue · information requirements · interface features (controls/displays) · actions and decisions required · complexity/difficulty · outputs · feedback."
  - "Granularity choice is load-bearing: HTA can decompose to button-press level; for BPM discovery that's far too fine — for error prediction or SHERPA it's appropriate."
  - "HTA is NORMATIVE (how task should/does unfold); CWA is FORMATIVE (how task could unfold under constraints) — complementary, not substitutes."
  - "HTA is better for design *modification* (an existing system to refine); CWA is better for design *specification* (first-of-a-kind system)."
  - "HTA has 17+ downstream analysis extensions (SHERPA, team task analysis, workload assessment, allocation of functions); CWA has ~5 phases and no formal extensions."
  - "Both methods require multiple iterations with SMEs before the output is accepted — single pass is never enough."
created: 2026-04-16
updated: 2026-04-16
---

# Hierarchical Task Analysis vs. Cognitive Work Analysis

## Summary
Comparative methodology paper from human-factors / ergonomics literature. Compares the two dominant task-analysis frameworks — **HTA** (Hierarchical Task Analysis; Annett et al. 1971, Stanton 2006) and **CWA** (Cognitive Work Analysis; Vicente 1999, Rasmussen 1986) — across theoretical underpinning, methodology, and contribution to system design. Empirical case study: a military helicopter **Mission Planning System** (MPS) software tool, analysed with both approaches.

Relevant for the BPM wiki primarily as a **reference source for observation-based elicitation protocols** — HTA's data-collection mix (observation + interviews + walkthroughs + document review) and its iterative observe → draft → refine-with-SME cycle are directly portable to process-model discovery.

## HTA — how it works

**Theoretical core:** decompose an overall goal into sub-goals, operations, and plans. An operator (human or machine) is "required to do X" to achieve a super-ordinate goal. Roots in scientific management (Taylor, Gilbreths) via Miller, Galanter & Pribram (1960) *Plans and the Structure of Behaviour*. HTA developed in the 1960s specifically to describe **cognitive** aspects of task attainment (previously task methods focused only on physical/observable behaviour).

**Procedure (Stanton 2006, Fig 1):**
1. State the overall goal.
2. State subordinate operations.
3. State the plan (sequence/conditions for operations).
4. Check adequacy of redescription → revise if not OK.
5. Consider first/next suboperation → recurse if further redescription required, else terminate.
6. Repeat until all operations terminated.

**Data collection techniques** — not a single method:
- Observation (shadowing operators)
- Questionnaires / structured interviews with SMEs
- Walkthroughs (talk-aloud while doing the task)
- User trials
- Documentation review

**Iteration:** "high degree of reiteration, often with appropriate SMEs, before the analysis is completed to a satisfactory level." Single-pass is never adequate.

**Granularity** is load-bearing: in the paper's case study, HTA went to button-press level (e.g. "click on intervisibility drop-down menu, click right mouse button to activate mapping menu, click mouse on map to drop waypoint"). For error prediction (SHERPA) this granularity is appropriate; for BPM discovery it is far too fine and would obscure the end-to-end flow.

## Task-decomposition categories (Kirwan & Ainsworth 1992)

For each low-level task step, HTA captures:
| Category | What to note |
|---|---|
| Initiating event/cue | What triggers this step |
| Information requirements | What the operator needs to know |
| Interface features (controls / displays) | Where the information is and how it is accessed |
| Actions required | Physical/cognitive actions |
| Decisions required | Choices the operator must make |
| Complexity / difficulty | Is it routine, error-prone, cognitively heavy |
| Outputs | Result of the step |
| Feedback | How the operator knows it worked |

This template **is directly usable as an observation field-note structure** for BPM discovery — per observed activity, capture these 8 fields.

## HTA vs CWA — when to use which

| | HTA | CWA |
|---|---|---|
| Nature | Normative (how it does/should unfold) | Formative (how it could unfold) |
| Granularity | Fine (button-press) | Coarse (functional) |
| Strength | Design modification, error prediction, training design | First-of-a-kind design specification, coping with unanticipated events |
| Phase | Later (evaluate/refine existing system) | Early (idea forming / concept) |
| Output | Goal-subgoal hierarchy + plans | Abstraction hierarchy + decision ladder + contextual activity template |

**Paper's verdict:** they are complementary. Apply CWA early (formative, specification) and HTA later (normative, refinement). Both need multiple SME iterations.

## Utility for BPM discovery (our angle)

- **Observation-protocol template** → the 8-field decomposition table above.
- **Iteration discipline** → observe → draft hierarchy → validate with SME → revise, analogous to Dumas's Interview → Modeling → Validation cycle ([[sources/2018-dumas-fundamentals-of-bpm-ch5-discovery]] §5.2.2).
- **Granularity warning** → HTA's button-press case study illustrates exactly what Dumas §6.1 warns against ("put document on fax machine"). Keep BPM discovery at activity or subprocess level.
- **Multi-method default** → no serious task analysis uses observation alone; observation + interview + document-review is the standard combo — aligns with Dumas §5.2.4's "mix methods" recommendation.

## Connections
- [[concepts/hierarchical-task-analysis]] — concept page.
- [[methods/process-discovery-methods]] — observation method.
- [[sources/2018-dumas-fundamentals-of-bpm-ch5-discovery]] — Dumas §5.2.1 observation treatment (much thinner than HTA).
- [[syntheses/qualitative-discovery-method-selection-matrix]] — observation candidate in the matrix.
- [[syntheses/interview-structuring-for-process-models]] — iteration cycle parallels.
- References not ingested: Annett et al. 1971 (HTA origin); Kirwan & Ainsworth 1992 *A Guide to Task Analysis*; Embrey 1986 (SHERPA); Vicente 1999 *Cognitive Work Analysis*.