When work needs a project, and when a list is enough

Every tool that offers projects encourages you to make them, and most people make too many. A project with three tasks and no second participant is a list wearing a costume: it adds a layer of navigation, a place for status to go stale, and nothing else.

The opposite failure is quieter and more expensive. Work that genuinely spans months, several people and a dozen meetings, tracked as scattered tasks on individual lists, cannot be seen. Nobody can answer "where are we on this" without asking three people.

The useful question is not should this be organised but has this outgrown a list.

Four signals it has

More than one person's work. A list is a personal object. The moment the effort depends on somebody else's tasks as much as yours, a list stops being able to represent it — you can see your half and guess at theirs.

A long enough span that you will forget the context. Two weeks is a list. Two months is not, because in month two nobody remembers why the third decision was made and the reasoning exists only in somebody's head or an unopened notes document.

It generates its own meetings. Work that has recurring meetings about it has a body of decisions, commitments and risks attached. Those need somewhere to live that is not the individual meetings, or reconstructing the thread means reading six transcripts.

A finish line somebody will ask about. If a person outside the work will one day ask "is it done", it needs a place where that has an answer. Lists answer "what is next", not "how far through are we".

Two or more of those, make a project. One or none, keep the list — you can always promote it later, and promoting is cheap while un-promoting is embarrassing.

Why early projects go stale

The most common failure is not making too few projects; it is making one, filling it in enthusiastically, and then letting it drift out of date until it actively misleads people. A stale project is worse than none: it looks authoritative while being wrong.

They go stale for a predictable reason. If the project is a second place work is recorded — where you first do the work on your own list, then update the project — the update step is pure overhead and will be dropped inside three weeks.

The fix is structural, not disciplinary. The project has to read from where the work actually happens rather than asking to be told. If the tasks people are genuinely working from are the same objects the project shows, it cannot go stale; if it maintains its own parallel copy, no amount of good intentions will keep it current.

What a project should hold

Most project tools offer far more than the work needs. What earns its place:

• The tasks themselves — not a summary of them, the actual items people work from.
• A one-paragraph brief. What this is and what finishing looks like. Written once, changed rarely, and worth more than any status field.
• The meetings and what they decided. The decision made in week three is the thing people re-litigate in week nine. Keeping the decisions attached to the effort is the single highest-return piece.
• The promises outstanding. What the effort is waiting on from people, so that "blocked" has a name.

What does not earn its place: percentage-complete fields, RAG status, and anything else that requires a human to translate reality into a colour. Those decay fastest and are believed longest.

Do not make it a permission structure

One thing to watch. A project is a way of grouping work, and it is tempting to also make it a way of controlling work — everything in it needs approval, statuses are set by a lead, individuals stop owning their own items.

That is how a useful grouping becomes reporting overhead. The people doing the work should still own their tasks: their dates, their order, their board. A project should let others see the work and contribute to it, not take it over. The test is simple — if creating a project changes who is allowed to move a task, the tool is organising your company rather than your work.

Where DayMarshal fits — honestly

In DayMarshal a project groups work that still lives on personal boards. Filing a task under one shares it with the project's people — they can read it, comment, tick its checklists, mark it complete — but it keeps its owner: only they change its dates or move it between columns. Meetings can be filed under a project too, which brings their decisions, commitments and risks with them, and filing does not reshare anything: a private meeting stays private and simply does not appear for people who could not already see it.

There are no percentage fields, deliberately. Progress is counted from the tasks themselves, which means it cannot be wrong in the way a hand-maintained number can.

For the habit that keeps the decisions worth grouping, see tracking decisions, commitments, and risks after meetings.