monday.com in practice: making projects and routines visible

Where things usually come unstuck

Most companies know perfectly well what needs doing. The problem is that the knowledge sits in five places at once. The job status lives in the project lead’s head, the deadlines sit in a spreadsheet, the queries are in an inbox, the files are on a server, and the rest is somewhere in a chat group. As long as a settled team is doing the work, this holds together for a surprisingly long time.

It shows its cracks elsewhere: when somebody is off sick, when a project grows beyond its original size, when a new colleague has to be brought up to speed. Every simple question then costs a follow-up, and status meetings fill up with information that ought to be available on demand.

The request that comes out of this is usually “we need a tool”. The actual need is different: it should be visible, without asking anyone, who is working on what, what comes next, and where something is stuck.

How we approach this kind of project

We do not start with the software. We start with two or three recurring routines that genuinely hurt. Often these are quoting, order handling, or onboarding new staff. For each one we ask the same questions: which steps actually exist, as opposed to the ones on the org chart? Who decides? What triggers the next step? And when is something considered finished?

This is the uncomfortable part, because differences surface. Two departments frequently describe the same routine in different terms, and both are right from where they stand. That clarification is the real benefit. Only afterwards is it worth asking which tool should carry it.

What monday.com has proved useful for

monday.com is a work platform in which each item sits as a row on a board, carrying its status, owner, due date, attachments and comments. In our projects it has earned its place for three reasons.

First, a routine can be modelled and then changed without development work. Columns, status values and views such as table, kanban, calendar or timeline are a matter of configuration rather than a project phase. That lowers the barrier to rebuilding something in the first month, which is when you learn what you got wrong.

Second, the information sits with the item rather than in an email about it. Whoever opens the job sees the last thing that was agreed. Status meetings lose most of their content, which is the point.

Third, colleagues who are not close to IT usually find their way around quickly. That does not mean training can be skipped. People who are not shown the structure will invent their own, and then you are back to five versions of the truth.

A board does not replace a process

The most important limitation: a board reflects decisions that were already made. If responsibility was unclear before, it stays unclear afterwards, only in brighter colours. Boards that nobody maintains are worse than a spreadsheet, because they imply a reliability they do not have. Once a status cannot be trusted, nobody decides anything on the strength of it, and the effort was wasted.

The second limitation concerns automations. Rules for standard cases are sensible: a reminder before a deadline, an assignment on a status change, a notification when something is approved. But if every exception gets its own rule, after a few months you have a web nobody can follow. Tasks appear and no one can say why, and tracing the cause takes longer than the manual step that was being replaced. So we write down which rule triggers what, and we prune regularly. A handful of automations everyone understands is worth more than a long list nobody reads.

When we advise against it

A small team with one clear routine rarely needs a platform. A shared list carries further than the market would have you believe. Where the real work happens in a specialist system, such as inventory management, accounting or industry software, that system should stay in charge. A board alongside it quickly creates duplicate data entry, and duplicated data drifts apart sooner than people expect.

Two points belong before the decision rather than after it. Costs are charged per user and per plan, and the terms change, so check them directly with the provider and calculate with the team size you expect in two years. And if personal data will be processed in the platform, then processing agreements, storage locations and access rights belong in your own review. That assessment is one no vendor promise, and no blog post, can make on your behalf.

A realistic first step

One routine, one board, four to six weeks, then an honest look at the result. If people ask for status updates less often and the entries hold up, add the next routine. If not, the routine rather than the tool was usually the problem.

If you would like to work out whether this is worth it for your company, we will go through your routines with you. Book an introductory meeting; we will also tell you when something simpler will do.