AI & Business Process consulting.
monday.com Platinum Partner.
monday.com is flexible enough to run almost any kind of project. That flexibility is also the reason so many project boards don’t work the way they’re supposed to. The platform won’t stop you from setting up a board that technically functions but creates more overhead than it saves.
This guide is about the setup decisions that actually matter: the ones that affect whether your board gives you control over a project, or just gives you somewhere to put information.
Start with the structure of your project, not the structure of the board
The most common mistake in project boards: building the board before deciding how the project is actually going to work.
Before you add a single column, answer three questions. Who is accountable for what? What does progress actually look like, i.e. what does “done” mean for each phase? And what does leadership need to see, and how often?
Those answers determine your groups, your status labels, and your column set. A project board built backward from those three questions almost always works better than one built forward from “what columns might be useful.”
Groups: the most important structural decision in any project board
Groups in monday.com are the colour-coded sections that divide your board. Most project managers use them to represent phases (Discovery, Build, Testing, Launch) or workstreams (Design, Development, QA). Both approaches work. The choice should reflect how your team actually reports progress and moves work forward.
What doesn’t work: using groups for everything. Groups as phases, groups as priority buckets, groups as team assignments, and groups as status categories all on the same board creates a board nobody can navigate. Pick one logic and use it consistently.
A practical default for most projects: groups as phases, with items within each phase representing the tasks or deliverables. Status columns handle progress within each phase. This gives you a clean phase-gate view without overcomplicating the structure.
The column set that covers most projects
Every project board is different, but most need a version of the same core columns:
- Status: your primary progress indicator. Set up the labels before you start so they reflect your actual stages, not monday.com’s defaults
- Owner: a People column. One person per task, not a team. Shared ownership is usually no ownership
- Due date: a Date column. Pair it with an automation to flag overdue items
- Priority: a Status or Dropdown column with clear labels (Critical, High, Standard). Not every board needs this, but it’s worth having when your item list gets long
- Notes or description: a Long Text column for context that doesn’t fit in the item name
Add columns when there’s a genuine reason to track that data. Remove them if nobody’s filling them in after two weeks. An empty column isn’t neutral: it signals that the board isn’t being maintained.
Automations that actually move projects forward
monday.com’s automation engine is strong, and most project boards underuse it. Three automations that pay for themselves immediately:
Overdue notification. When a due date passes and status is not Done, notify the owner. This alone reduces the number of things that silently slip without anyone flagging it.
Status-triggered assignment. When an item moves to a specific status (say, “In Review”), notify the person in the reviewer column. This removes the manual step of telling someone their task has arrived.
Phase completion trigger. When all items in a group are marked Done, send a notification to the project lead. This gives you an automatic gate check without having to monitor the board constantly.
Build these before you start the project, not after the first thing slips.
Subitems: use them deliberately or not at all
Subitems let you break a task into component steps. They’re useful when a single item genuinely involves multiple people doing sequential work. They’re not useful as a way to add detail to every item on the board.
The practical test: if the subitem has its own owner, its own due date, and its own status, it should probably be a subitem. If it’s just a note about how to complete the parent task, put it in the item’s update section instead.
Subitems that proliferate without discipline are one of the fastest ways to make a project board hard to read at a glance.
Dashboards: the reporting view your stakeholders actually need
A project board is for the team doing the work. A dashboard is for the people who need to understand progress without living in the board.
Build your dashboard with the audience in mind. A project sponsor usually needs three things: are we on track, are there blockers, and are we on budget. A battery widget showing percentage complete, a chart of overdue items by phase, and a numbers widget showing hours or cost against budget covers most of that in a single view.
Lock dashboard views once they’re configured so a well-meaning team member doesn’t reorganise the widgets before a board review.
Portfolio management: running multiple projects at once
If you’re managing multiple concurrent projects, a portfolio board connected to individual project boards via mirror columns gives you a rollup view without duplicating data entry. Mirror the status, due date, and owner from each project board into a single portfolio board. This is where connect board and mirror column setup discipline from your account structure pays off directly.
Note that mondayDB 2.0 has significantly increased the scale at which this works, raising connected item limits well beyond the old 10k ceiling. Large PMO setups that previously hit platform constraints have more room to work with now.
Where project managers usually need a hand
The setup decisions described above are straightforward for a single project. Where it gets genuinely complex is when you’re building a project methodology across a team: consistent board templates, standardised status labels, shared automation libraries, and a portfolio view that rolls up across ten or twenty concurrent projects. That’s architecture work, not configuration work, and it’s worth getting right the first time rather than retrofitting it when the team is mid-delivery.