How to structure a project

A new client has signed. You open a fresh project and stare at it. Should there be phases? Categories? A list for design and a list for build and a list for the things you always forget? Half an hour later you have a beautiful empty structure and no tasks, and the actual first piece of work — book the kick-off call — is still in your head.

Structure is easy to build and hard to live in. Here is the order that works, and the order in which not to do it.

Start with a name and a key

A project needs one thing: a name. Acme website. From that, sjTasks derives a short key — acme — and shows you what it is going to use while you type, so you can change it before anyone has said it out loud. The key is what makes task references readable: acme-12 in a note, an email or a meeting means one task, and everyone knows which client it belongs to.

Pick a key people will actually say. acme is good. acmewebsiteredesign2026 is a key nobody will ever type. If the client has several projects with you, tell them apart in the key — acme for the site, acmenews for the newsletter — so a reference carries its own context.

Then the first ten tasks

Before any structure, type the work. The box at the top of the project takes a whole task in one line: Kick-off call with Acme @joe tuesday, Write the homepage copy @sandy friday ~3h, Design the homepage @joe !high. Ten of those takes five minutes, and at the end of it the project has a shape you did not have to invent, because the work has one.

Do not try to write down everything that will ever happen. Write down what has to happen in the next two weeks and what you already know is coming after that. The rest goes in as it becomes real. A project with ten true tasks beats one with sixty guesses.

Task lists, only when you have phases

Every project starts with one task list, called Tasks, and everything lands in it. Leave it that way until the page is hard to read.

The moment to add a second list is when the work has genuine phases — Discovery, Design, Build, Launch — and you want the page to read in that order. Add a task list, name it, and it appears as a heading; a picker beside the quick-add box lets you choose which list a new task drops into, and each row has a control for moving one later. Lists can be renamed and reordered by anyone on the project, and archived by an admin, which moves their tasks back to the default list rather than losing them.

What a task list is not: a way to give a group of tasks a date, an owner or a priority. Lists are headings. If you find yourself wanting a due date on a list, that group is a task with subtasks, or it is a project of its own. Subtask or new project? goes into that.

And do not nest to organise. Priority, owner and due date are what the Tasks table filters on; a deep tree of lists is not an answer to any question anyone asks on a Monday.

Who watches it

The one other thing on the new-project form is the watcher list — everyone who will hear about what happens in the project without owning any of it. Everyone who can see the project is ticked already; Select none and add back the two people who need to know is the usual move for a busy studio.

Watchers get the bell, not an email, for broadcast events like a new task or a status change. Anything addressed to a person — assigned to you, mentioned, your work is late — reaches that person by email whatever the watcher list says. So watching a project is cheap for the watcher, and you can be generous with it.

If Acme's marketing lead should be in the room, invite them as a guest scoped to this project. They will see this project and nothing else, can read everything and write notes, and cannot change a task. Clients in the room without charging for them covers what that looks like from their side.

What to leave alone

Estimates, labels, logged time: leave them off until the project asks for them. A project whose first ten tasks each carry an estimate nobody believed is worse than one with no estimates at all, because the arithmetic will look real. Add estimates when somebody asks "are we over?", and not before. Complexity you switch on is the longer version of that argument.

The question this answers

A well-structured project is one where you can answer, without opening it, what is due next week — because the tasks are real, dated, and owned.

Show me what is due next week — across every project, or narrowed to one from the Project menu. If the answer is "nothing", either the project is finished or the tasks are not written yet.