Creating and Structuring Projects

Creating one

Open Projects from the sidebar. The project switcher sits at the top of the board; use it to change projects, or create a new one from the New Project control.

Give it a name your teammates would recognize without explanation, and a description that says what 'done' would mean. The description is not decoration — it is read by the agent when it is reasoning about where a task belongs, and a project whose description says 'Website redesign — new marketing site live on the new stack, old site retired' produces much better routing than one that says 'Website'.

Once created, the project has its own board, its own team, its own KVN charter, and its own rollup in the portfolio and planning surfaces.

How many projects, and how big

The instinct of most new workspaces is one project. The instinct of most over-organized ones is a project per feature. Both are wrong for the same reason: the project is the reporting and access unit, so it should be the size of a thing you would want a report about and would want to control access to separately.

A useful test: could you imagine someone asking 'how is X going?' and meaning this project? If the answer is 'nobody would ask that, it is too small', merge it. If the answer is 'they would, but the answer would be a paragraph about four unrelated things', split it.

For a team of five to fifteen, three to seven active projects is a normal shape. Client work usually maps one project per client engagement. Product work usually maps one per product area or one per initiative, depending on whether your teams are stable or formed per initiative.

What else a project switches on

Access control. Kavanah has per-project membership on top of workspace membership: a project has a Team tab, and someone not on it does not see the project at all. This is the mechanism behind almost every 'I can't see the board' report, and it is also how you run client work and internal work in the same workspace without one leaking into the other.

Reporting. Status reports, velocity, burndown, bottlenecks and cycle time are all computed per project. The portfolio rolls projects into programs and objectives. Budgets are per project.

Planning. Sprints, capacity and the timeline view organize by project.

Charter. A project can carry its own KVN — including a 'false friends' field that the workspace charter does not have — and the agent checks the project charter as well as the workspace one before it creates work there.

Issue configuration. A project has a key prefix, which is what gives tasks keys like ENG-114.

Archiving, not deleting

When a project ends, archive it. Archiving is non-destructive: it takes the project out of the daily view without losing the history, which matters because the history is what your velocity and estimate calibration are computed from. Deleting throws that away.

The same logic applies at task level. Tasks archive from their detail panel — again non-destructive, again reversible, and archived tasks are browsable and restorable from the board's Archived view. Deletion exists, goes to Trash, and is recoverable there for a while; but archive is what you want nine times out of ten.

The three expensive mistakes

One: the catch-all project. Everything in 'General'. The cost is not aesthetic — it is that every report is about everything, so no report is about anything, and access control becomes all-or-nothing.

Two: projects that mirror your org chart rather than your work. 'Marketing', 'Engineering', 'Design' feels tidy and produces reports that cannot answer 'is the launch on track', because the launch is spread across all three.

Three: creating projects for things that are really tasks. If it has one owner and finishes in a week, it is a task, possibly with subtasks. A project with four tasks in it is overhead with no rollup worth reading.

All three are fixable, but fixing them means moving tasks between projects, which resets nothing but does mean your historical reports were about the old shape.