Subtask or new project?

Something has grown. What started as one task called Set up Acme's newsletter now has a design, a template, a list import, a test send and a launch date, and it is not clear where any of it should live. Make them subtasks? Start a project? Just leave them as separate tasks in General and hope they stay together?

This comes up every week at any studio with more than one client, and the answer is not "whatever feels tidy". Each shape does something different, and picking the wrong one is how work either gets buried or gets ceremony it did not need.

The one question that decides it

Will somebody ask "how is it going?" about this, by name?

If yes, it is a project. Acme will ask how the newsletter is going. Your own team will ask in the Monday stand-up. Somebody will want to see a progress line — 4 of 7 done — and a place to put the brief, the logo files and the login details. That is what a project is: a body of work with its own page, its own watchers, its own files, and a name a client would recognise.

If nobody would ever ask about it as a thing — if it only matters as part of getting something else done — it is not a project. It is either a task — the three-part test says whether it is one — or a piece of one.

What a subtask is for

A subtask is a piece of a task that needs its own owner, its own date or its own estimate, but only makes sense inside the parent. The test is simple: read the subtask's title on its own, away from the parent. Client review means nothing by itself. Client review under Homepage copy means everything.

The typical shape is a hand-off. Homepage copy is Sandy's, but the middle of it belongs to Acme's marketing lead, who has to read the draft and say yes. So the parent gets three subtasks: Draft (Sandy, Tuesday), Client review (their person, Thursday), Final (Sandy, Friday). Each has its own reference — acme-144, acme-145, acme-146 — its own notes and its own files. The parent shows 1 of 3, and if you mark Client review as blocking, the parent cannot be finished while the review is open.

Subtasks go exactly one level deep. That is not a limit we ran out of time to lift; it is the line between a piece of a task and something bigger. If a subtask wants subtasks of its own, promote it — it was a task, or the whole thing was a project.

What a task list is for

There is a third shape, and it is the one people reach for when they really wanted a project. A task list is a heading inside a project — Phase 1, Design, Backlog. It has no owner, no date and no progress of its own. It exists so the project page reads well once there are thirty tasks on it.

So: if you want to group tasks you can already see, use a task list. If you want a due date on the group, you do not want a task list; you want a task, or a project.

Back to the newsletter

Acme's newsletter has a design, a template, a list import, a test send and a launch. Acme will ask how it is going. It has files of its own. Somebody will want to know it is 3 of 5 done. That is a project — Acme newsletter, key acmenews, with five tasks in it, and how to structure a project is its first hour, step by step. Later, when the launch is done and the monthly sends begin, it becomes the natural home for them too.

Now suppose the same five items had been Test send with the pieces Load the list, Send to internal, Fix what broke. Nobody asks how the test send is going by name; they ask whether the newsletter is ready. Those three are subtasks of Test send, inside the newsletter project.

The mistake in each direction

A project per task is the common one. Projects are heavy on purpose — people, files, a page, watchers. If a "project" would have three tasks and be done in a week, it is three tasks in an existing project, or a task list in one.

Burying a project as a task is the quieter mistake. Set up Acme's newsletter sits in General with nine subtasks, no files of its own, and nobody can find it when Acme rings. Promote it. Moving is cheap: a task moves between projects and keeps a working reference, and a subtask can be promoted to a task in one action.

The question this answers

The sign that something has outgrown its shape is a due date nobody set, because nobody could say when "the whole thing" would land.

Show me open work with no due date — the ones with a crowd of subtasks underneath are the projects waiting to be named.