Every project tool works at ten tasks.
One project, one team, ten things to do. You can see the whole thing at a glance, and nothing slips without you noticing. So you buy in. Then the work grows: more projects, more people, more tools in the mix. And somewhere along that curve you realize you’ve quietly become the tool’s query engine, scanning boards every morning, remembering which project was fragile last week, holding the whole risk map in your head because the software won’t hold it for you.
That’s not project management. That’s you doing unpaid labor for software that was supposed to do it for you.
Picture the shape of it. A six-person agency runs fifteen client projects at once. On Monday morning, someone opens fifteen boards to work out what’s on fire. An hour later they’ve assembled a picture in their head, and it’s already stale, because keeping fifteen projects current by hand is nobody’s actual job. The client whose deadline quietly moved on Wednesday? Nobody’s watching that. Not because the team is careless, but because no human reliably scans hundreds of tasks across a dozen boards every day looking for the three that matter.
This isn’t a flaw in any one product. It’s structural. Almost every mainstream tool is a pull system: the answer to “what’s at risk?” exists somewhere, behind a filter, in a burndown chart, in someone’s head, and it’s your job to go pull it out. Pull works fine when there’s little to pull. It collapses when there’s a lot. The status meeting is just the pull query with a calendar invite attached.
Here’s where it breaks, and in what ways.
Attention doesn’t scale, even when storage does
A task list is very good at holding tasks. What it can’t do is tell you which of the four hundred it’s holding is the one about to blow up a deadline. The overdue task and the one due next quarter look identical in the list: same row, same styling, both just sitting there. Everything is stored at equal weight, which means at scale the system effectively surfaces nothing. The burden shifts to you, and your attention is the one thing that doesn’t scale.
One board is fine. Fifteen boards is a part-time job
Every “see everything in one place” tool quietly assumes everything is in its place, in that tool. The moment some of your work lives elsewhere, engineering in a git platform, sales in a CRM, a side project in a spreadsheet, the single pane of glass has cracks in it. The usual fix is consolidation: migrate everyone into one tool. But that’s a tax, not a solution. You spend weeks moving work and political capital forcing teams off tools they chose for good reasons, and the reward is a single view that’s already out of date.
The manual upkeep collapses under its own weight
Every pull tool runs on a hidden assumption: a human keeps the status current. Someone drags the card, updates the percentage, flips the field to “At Risk.” At ten tasks that’s invisible. At scale it’s a second job nobody has time for, so it doesn’t happen, and the board starts lying to you. It says “on track” because that’s what someone typed three weeks ago, not because anything checked.
Some of the ritual that grows up around this earns its place. Planning, refinement, and retros are real work that makes teams better, and nothing here argues against them; a tool that surfaces risk doesn’t replace good practice. But a good slice of the calendar exists only to answer one question the tool won’t: what’s behind right now? The status round at standup, the Friday report, the meeting you call purely to find out what’s slipping. That part isn’t planning, it’s the manual labor of pulling status out of a tool that won’t push it to you, and it’s the part that grows in direct proportion to the work.
Dependencies compound invisibly
The quiet killer. A single late task is easy to see. What’s hard to see is that this initiative is now at risk because that task is late, and a second task is waiting on it, and a decision three levels up has gone stale as a result. At small scale you hold that chain in your head. At scale the chains cross projects and teams, and no board draws them.
A few dependencies stay legible. Multiply them across projects and the chain no board draws becomes a knot nobody can trace.
So, does SRP actually solve this?
Mostly by refusing to work the way the tools above do. SRP is a push system, not a pull one: instead of waiting for you to go dig, it computes health continuously from the work itself and surfaces what’s slipping. Nobody types “at risk.” It’s derived from objective signals (an open blocker, a passed date, a stale decision, a late iteration), recomputed in the background, and rolled up so one initiative can gather work from across your projects and even other tools. And when something is at risk, you get the reason with it: this is late, that’s waiting on it, here’s the chain.
That’s the whole promise, and it’s deliberately a small one. SRP won’t run your projects for you or catch literally everything. It takes the hunting off your plate and warns you earlier, so “go find out what’s behind” becomes “you’ll be told while there’s still time to fix it.” If you’ve ever watched a tool that felt great at ten tasks fall apart at two hundred, that’s the gap it was built for.