Running projects without buying a project tool

The question about a project tool arrives at the same moment every time. Three or four bigger things are running at once, somebody misses a date, and the conclusion is that the company needs a project system.

Before buying one, work out what it would hold. Usually all of it exists somewhere already — just in pieces.

A project is a view, not a thing#

Take any project apart. What's left is tasks, dates, people, files and decisions.

None of them belongs to the project exclusively. Tasks exist whether or not you call the set a project. Dates are fields on tasks, people are the team that does everything else, files sit somewhere already, decisions are notes somebody wrote down or didn't.

"Project" is a label saying which of those belong together, plus a way of looking at them. That is a view, not an object.

A dedicated tool assumes the opposite: a new compartment you copy the same information into. A task inside a project then lives somewhere other than one outside it, though the same person does both on the same Monday.

Five things that genuinely have to be recorded#

Scope. What is in the project and — more usefully — what is not. One sentence on the goal, plus a list of what you are deliberately not doing.

Owner. One person, not a team or a department. A project with no name against it has nobody to ask.

Deadline. A date, not "in a couple of weeks". If the date is a guess, mark it provisional — an empty field carries nothing.

Status. A closed set of states, four or five, each saying what happens next. A status that doesn't imply a next step is just a colour.

Decisions. What was agreed and on what basis. The only field nobody can reconstruct afterwards — the rest can be rebuilt from the system, the reasoning cannot. Format is covered in making decisions without meetings.

Those five are the whole mandatory record. Everything else is optional, and much of it is decoration.

What counts as decoration#

The Gantt chart. It looks good in the meeting and stops being true by the first Thursday. Keeping it accurate needs somebody entering every change of date and dependency; where priorities shift weekly, that person stops after a month and the chart carries on producing wrong conclusions.

Story points. Estimating in abstract units works when you have a long history with a stable team to compare against. Without it you translate "three days" into "five points" and back, paying twice for one estimate.

Extended status sets. Eight states instead of four do not carry twice the information. They add twice as many places for a task to stall, and a recurring argument over whether something is "in review" or still "in progress".

Percentage complete. A task is done or it isn't; "seventy percent" in practice means "started".

Doing it on a database with views#

One table of tasks and one property called "project". The rest is saved filters.

The by-project view. A filter on a single value — the whole "project page": tasks, owners, dates and statuses in one place.

The by-person view. Everyone sees their own tasks across all projects and outside them. A dedicated project tool cannot give you this, because half of anyone's work sits beyond its reach — and that half decides whether the project date holds.

The by-date view. What falls due this week, project or not. The Monday meeting runs off this one.

A rough sum for scale: three projects of twenty tasks plus twelve pieces of ongoing work is seventy-two items. In a dedicated tool, three boards and a list with nowhere to live. In one table, seventy-two rows and three filters.

Asking for status instead of opening the view#

A database where the project is a filter has another property: you can ask it questions in plain language instead of opening a view and scanning it — "what in this project is overdue and who is it waiting on".

The mechanism is MCP, an open protocol by which an AI application talks to a system exposing data and operations: the application is the client, the system is the server. The model does not get access to the database — it gets a list of operations and can ask for one to be called, and the client makes the call on behalf of the signed-in user. More on the protocol itself.

Two consequences matter for running a project, and both are settled outside the protocol. An answer covers exactly what the account used for the connection can see, which makes it a question about permissions rather than about technology. And every additional system connected makes it harder to land on the right operation, which is the subject of too long a list of tools.

When a separate tool genuinely pays#

The answer is not always no. Three cases where a dedicated tool earns its keep:

The project is the product. An agency, a design practice, a construction firm — you bill hours against the project and it carries a budget and a margin. Then it really is a separate object.

Dependencies are hard and numerous. Installation or manufacturing, where step three cannot start before step two and one slipped date moves forty others. Recalculating by hand stops making sense.

The other side requires it. The client works in a particular tool and expects reports in its format — a cost imposed from outside, not a decision about how you work.

The common thread: a dedicated tool pays when it holds something you cannot express as a column on a task. Otherwise it is a second home for the same data.

Summary#

A project is a way of looking at tasks, dates, people, files and decisions, not a thing needing its own home. Record five fields — scope, owner, deadline, status, decisions — and treat the rest as options that must justify themselves. One table with a few saved views handles most of what a company of 11–200 people runs; keep the dedicated tool for projects with a budget, a dependency network, or an imposed reporting format.

Choosing tools for a distributed company is covered more widely in the guide on remote work tools.