Keep each project’s Action Steps physically separate from other projects

Mixing action steps from different projects in a single list increases context-switching cost and makes progress harder to see.

Why it works

Context-switching between projects carries cognitive overhead proportional to how different the projects are. A combined list forces the user to mentally filter by project every time they scan it — a small but repeated cognitive tax. Separate project containers remove this overhead: when working on Project A, only Project A’s Action Steps are visible. This also makes project-level progress measurable — you can see what proportion of a project’s action steps have been completed.

How to do it

1. Give each active project its own page, folder, or section in your system.
2. Within each project, maintain the three-bucket structure: Action Steps, References, Backburner.
3. Review project-level lists when working on that project; review all projects at a weekly or biweekly planning session.

Evidence

Task-switching costs increase with the conceptual distance between tasks. Keeping related work in a single container is consistent with the principle of reducing context-switching overhead. GTD uses a similar project-level organization for the same reason. (mechanistic)

The project-isolation principle is consistent with switching-cost research; the specific three-bucket structure within each project is the Action Method’s design choice.

Common mistake

Maintaining only a global "all projects" list and tagging by project — tags require an extra filtering step each time you access the list, which is less effective than physical separation.