40 projects, one structure that holds

An agency running forty client projects doesn’t fall over because forty is too many. It falls over because it’s running forty different structures.

Each project was set up by whoever kicked it off. One uses statuses like “In Progress” and “Review”. Another has “Doing”, “Waiting”, and “Almost”. One nests everything under folders, the next is a flat list a hundred rows long. The work is fine. The shape is different every time.

So when someone asks the simplest question that matters, “what’s at risk this week, across everything”, there’s nowhere to ask it. You can answer it for one project by opening that project. You can’t answer it for forty without opening forty tabs and holding the whole thing in your head.

That’s the real ceiling. Not the volume of work, but the fact that structure is reinvented per project instead of shared across all of them.

The fix isn’t a better-run project. It’s one structure every project gets poured into, and it’s built in four layers. Most teams build the first one, the folder tree, and hope the other three sort themselves out. They don’t.

I’ll use ClickUp as the worked example, because it’s what we run Novrith’s own client delivery on. But every layer maps onto whatever tool you use. The method is the point; ClickUp is just where you can see it.

The first layer is the nesting, and it’s the only one most teams ever build. The principle is simple: every project is the same chain of containers, top to bottom. Account, then client, then project, then deliverable, then the work that builds it.

In ClickUp that’s a single Client Delivery space, a folder per client, a list per project, a task per deliverable, and subtasks for the work underneath. One folder per client, not one space per client: spaces are heavy, and a space per client fragments the cross-project view you’re about to build in layer three. The phase (we run engagements as M1 through M5) isn’t its own container either, it’s a field the deliverables group under, so a project reads as phases without burying everything two levels deeper.

The deliverable-and-its-work split is the one boundary that earns its keep, because it lets the same project be read two ways without being maintained twice: the client reads the deliverable, the team works the subtasks. If that distinction is new to you, it’s worth drawing on its own before you scale it across forty projects.

Same chain, every project. If something doesn’t fit a container, it isn’t a new kind of thing. It’s one of these, mislabeled.

Containers give you the skeleton. They don’t make forty projects readable together. For that, every project has to speak the same language, and this is the layer almost everyone skips.

One status set, defined once and shared by every project. The moment a project invents its own statuses, the cross-project view can’t read it, and you’re back to forty shapes. Same for the fields every deliverable must carry: an owner, a due date, a phase. No item exists without them.

In ClickUp this lives at the space level: statuses set on the space so every list inherits them, custom fields enforced the same way, and custom task types to mark what’s a client-facing deliverable versus internal work. Decide it once at the top, and the fortieth project speaks the same language as the first without anyone re-deciding.

The test for anything in this layer: does it have to be identical across all projects for the portfolio to stay readable? If yes, it belongs to the space, not the project.

Here’s where the shared structure finally pays off. One dataset, read at whatever altitude the reader needs, with nobody building a second tracker.

The same items feed four lenses:

• Oversight: cross-project, top altitude only. Every deliverable across all forty clients, filtered to blocked, due this week, or waiting. In ClickUp this is a Dashboard. It’s the view that finally answers “what’s at risk across everything”, and it only exists because layers one and two made every project legible the same way.
• Delivery: one project, grouped by phase, deliverables with their work underneath. A board or list view on the project. This is where the work actually gets run.
• Contributor: flat. My work, this week, across every project I touch. ClickUp’s “My Work”, or a saved view filtered to assignee and date. No hierarchy, just the next thing.
• Client: the deliverable layer and nothing below it. A guest view showing only deliverable-type items and their status, none of the internal churn.

Four people, four questions, one set of data. The views are saved once and they hold, because the structure underneath them doesn’t move.

A structure with no automation and no rhythm decays into a graveyard of stale statuses within a month. The last layer is what keeps the other three honest.

Automation does the watching. Roll a deliverable’s status up from its work so the oversight view is never a lie, flag anything untouched past its cadence, surface slippage the moment a due date moves. In ClickUp these are native Automations. The machine watches, but a human still decides: closing a phase stays a manual call, because automation should never declare work finished.

Then the human rhythm, because no view reads itself. A weekly delivery review run straight off the oversight dashboard, where every blocked or slipping deliverable leaves with one owner and one date, not a discussion. And a phase gate at each boundary, where the work is reviewed, the client sees the deliverable layer, and the next phase opens. The gate is also where you catch the project that quietly drifted off the shared shape, and pull it back before it becomes the forty-first.

Four layers: the containers, the shared language, the views, and the automation and rhythm that keep them alive. Build only the first and you have forty folder trees. Build all four and you have one structure.

You don’t manage forty projects. You manage one structure, forty times, and let the sameness do the work that headcount and heroics were doing before.

Talk soon,

Marco

Founder / CEO, Novrith