Switched off on purpose
A studio ran several service lines out of one project tool and couldn't tell, from any screen, which projects were quietly on their third or fourth revision. We rebuilt the delivery system so rework can't hide, then left the automations turned off.
What they had
Several service lines, a front office in one country and a delivery team in another, and every project living in a tool that could describe work but couldn't describe state.
The failure worth naming: a set of drawings on its fourth round of revisions looked identical, on every screen, to one that sailed through first time. The work was happening. It just wasn't visible as rework, so nobody could see where the time was going.
One approval, and what follows
A person approves. Everything downstream comes unblocked in one move, and the admin follows on its own. Then feedback arrives, and the same board runs backwards: the work reopens, the milestone drops out of approved, and the flag goes up where everybody can see it.
How it's put together
Each service line has its own space, and each project is a set of stages that match the way the work actually runs.
Two decisions do most of the work.
Milestones carry the dependencies, not the tasks. Every task in a stage blocks its milestone, and the milestones chain to each other. So an approval is a single human act that releases everything downstream at once, instead of somebody hand-assigning the next batch.
A review is its own task, not a status. That means "waiting on the client" becomes something you can filter, count and put on a screen, rather than something people remember.
One piece of work, two homes
Some people work across every project rather than inside one. Building them per-project folders would have given them a lot of folders and no queue.
The rule we settled on: two people doing two different things is two tasks with a dependency. One piece of work that two places need to see is one task in two lists. It lives in the project, so the project template captures it, and it also appears in that person's own queue. Same task, two homes.
An earlier version used paired tasks and cross-space dependencies. It drifted, and we threw it out.
Automations react, people decide
Automations in this tool can only act on the task that fired them. They can't reach across and change a different one.
That constraint is what makes the dependency graph load-bearing rather than decorative: the cross-task effects come from dependencies unblocking, and the automation only reacts to that.
So no automation decides anything. A person moves every status. The automation does the admin that follows. The moment a team suspects the board is moving itself, they keep a private spreadsheet, and then you have two systems.
The limit we said out loud
Nothing in the tool can prevent somebody marking a milestone approved while rework is still open on it.
We said that at the start rather than letting them find out later. The system makes rework visible. It does not make it impossible. A tool that quietly fails to enforce something you were told it enforces is worse than one that never claimed to.
Why it's switched off
The rules are written, grouped and turned off.
They chose to build the templates before anyone was onboarded, which is a fair call, but it means the rules are written against imagined behaviour rather than observed behaviour. So: build them, leave them off, run the pilot with people moving statuses by hand, watch for a couple of weeks, then enable a few at a time starting with the ones that just move work along.
Switch one on in week one and find out in week two that it's wrong, and you've already taught the team the system lies to them. The same rule switched on in week three, after watching, gets adopted. The delay costs a fortnight. Getting it wrong costs the project.
Where it stands
Structure built across every service line, dependencies wired, automations written and staged. The pilot is what turns a good structure into a system, and until a real project has run through it with real people, that is exactly what we will call it.