Keeping Track of What Has to Be Done

No affiliate links on this site, and nothing here is ranked.

Why this category is the worst offender

The average company runs eleven project management tools. (Zylo — a SaaS management vendor; the figure comes from a company selling consolidation.)

Nobody chose eleven. Each was chosen once, by somebody with a task, who searched and arrived at a category — and the category is enormous because it serves construction programmes and product organisations and marketing agencies with the same name.

Which makes this the clearest case for starting from the task, because the distance between "I forget things" and "programme portfolio management" is the whole problem in one line.

The three sizes

One person, private. A list. On paper, in a notes app, in a text file. Where it stops: anything somebody else needs to see, and anything with a date that must chase you.

A few people, shared. A shared list or board. Where it stops: dependencies between items, workload across people, and anything you need to report on.

Work that moves between people, with dates that matter. This is where the category earns its price — and the honest test is whether handovers currently fail, not whether the current arrangement feels untidy.

What the task actually requires

Four things, and most tools sell forty.

A list that both parties see. The single largest failure is two people with different pictures.

A next action per item, in words, rather than a status label. "Waiting on Sam" is actionable; "In progress" is not.

A date only where a date exists. Assigning dates to everything trains people to ignore dates, which is the commonest way a system stops working within a month.

And a way to see what is not moving. Anything older than a fortnight with no change is the useful view, and it is the one people build dashboards to approximate.

What you already have

A shared document or spreadsheet. Genuinely adequate for a small team, and it fails only at scale or at concurrency.

A shared mailbox with consistent subjects, which is worse than it sounds and better than nothing.

And whatever is in the office suite you already pay for — most bundle a task tool that people never open because it was not what they searched for.

Where the money goes wrong

Buying for the workflow you would like to have.

A tool with dependencies, sprints, capacity planning and reporting will be used as a shared list for six weeks and then abandoned, because the shape of the tool did not match the shape of the work.

Adoption is the constraint, and a simple thing everybody updates beats an elaborate thing half the team ignores — because a task system holding half the work is worse than no system at all.

The test before buying

Run it as a shared list for a month.

A document, a board, anything free. If it works, that is the answer, and you have saved a subscription.

If it fails, note how. "Two people did the same thing." "It slipped because nobody was chasing." "We could not see whose it was."

Those failures are a specification, and they point at a small number of features rather than at a category.

The features that look essential and are not

Dependencies. Genuinely useful on work where one thing cannot start until another finishes, and that is a smaller share of small-business work than the tools assume. Where it does not apply, dependencies are maintenance without benefit.

Time tracking inside the task tool. Two tasks joined because a vendor sells both — recording hours is its own job with its own requirements, and doing it inside a task system is usually worse at both.

Automation and rules. Powerful, and they encode a process before the process has settled. Rules built in month one are wrong by month three and nobody unpicks them.

And reporting. Frequently the reason a larger tool is bought, and frequently a report nobody reads after the first month. Ask who will look at it and how often before paying for it.

Moving between tools

People change task systems more often than any other category, and the move usually loses the history.

What matters is not the closed items — those are archive — but the open ones with context attached: who was waiting on what, and why something stalled.

Export it as text before switching, however crudely, because the alternative is starting from a blank board and rediscovering the same stalled items over the following month.

And expect a fortnight of both systems, which is normal and should be time-boxed rather than allowed to become permanent. Running two indefinitely is how a company gets to eleven.

The thing that actually keeps a list working

Somebody looking at it on a fixed day.

No tool supplies this, and its absence is why systems die regardless of which one was chosen. A shared list reviewed every Monday works in any format; one reviewed when somebody remembers works in none.

Fifteen minutes, same slot, out loud if there are several of you. What moved, what did not, what is next.

That habit is the product. The software is where the list happens to live, and choosing it carefully while skipping the review is optimising the wrong half. For broader context, see Notion.

The short version

• The average company runs eleven of these, chosen one at a time by people who arrived at a category
• Three sizes: a private list, a shared list, and a real system where work moves between people
• The task needs four things: a shared view, a next action in words, dates only where real, and a view of what is not moving
• Assigning dates to everything trains people to ignore dates, which kills a system within a month
• Buy for the work you have rather than the workflow you would like, because adoption is the constraint
• Run it as a shared list for a month first; the failures you record are the specification