A tool that derives risk from your work instead of asking someone to type it solves a real problem. It also introduces a new one, and it is worth naming plainly rather than discovering it the hard way.
A derived signal is a claim about the world, produced from data. If the data is thin, stale, or simply absent, the claim is wrong. But it does not look wrong. It looks exactly like a correct one, because it was computed a moment ago from whatever was available, and freshness of computation is not the same thing as completeness of input. That is the trap. A green project can mean the work is healthy, or it can mean the system cannot see the work at all, and by default those two render identically.
Stale data used to announce itself
The old way had one accidental virtue, and it is worth naming before writing it off entirely: a typed status came with a timestamp.
Updated three weeks ago. That line was doing quiet work: it told you how much to trust the label. A card marked on track and last touched in April was obviously not evidence of anything, and everyone reading it knew to discount it without being told. The record was unreliable, but it was legibly unreliable.
A computed signal has no such tell. It is recalculated on every change and every schedule, so it is always freshly stamped, always confident, always the same shade of green whether it was derived from a complete picture of the project or from three tasks somebody imported in March and nothing since. The unreliability got hidden rather than fixed. You traded a signal that was late and looked late for one that is fast and looks certain, and the second failure is harder to catch precisely because it is quieter.
The three ways the data goes thin
In practice the input problems are not exotic. They are the same three every time.
Work that lives outside the tool. The blocker is a client who has not replied to an email. The dependency is a subcontractor’s timeline in a spreadsheet. The decision everything is waiting on is in a Slack thread. That work outside the pane of glass is a familiar complaint, but the consequence for a derived signal is specific and worse than a gap in reporting: the tasks it is blocking do not appear as unknowns. They appear as ordinary open work proceeding normally, and they will be counted as evidence of health.
Dates that are fiction. If everything on a project is due the last day of the sprint because that is what the import script did, then no date carries information, and every signal derived from dates is noise wearing a suit. The same applies to estimates nobody believes and priorities where everything is high.
Coverage gaps. One team logs everything, another team works out of their own board and syncs occasionally. The tool has a rich, detailed view of the first team and a sparse one of the second, and it will confidently report on both. It will usually report the second one as healthier, because fewer recorded tasks means fewer things that can trip a flag.
Notice that all three fail in the same direction. Absence of data reads as absence of problem. A missing blocker is not a blocker. A task nobody entered is not overdue. A team that does not log its work has nothing at risk. Every gap in coverage makes the picture look better, which means the parts of your business you have the least visibility into are the parts the dashboard is most reassuring about.
Trust is spent faster than it is earned
Miscalibrated thresholds lose a team’s trust gradually, through accumulated noise. Bad inputs lose it in one go, and it is worth being honest about the exchange rate.
Ten correct warnings buy a modest amount of credibility. One confident flag on a project that was demonstrably fine costs more than those ten earned, because the wrong one is memorable, repeatable and funny. It gets quoted in the standup. It becomes the thing someone says every time the tool speaks after that.
Worse is the miss in the other direction. If a project goes visibly sideways while the tool was showing green, nobody has to argue about whether to trust it again. That question is settled. And the miss is usually not a bug in the logic. It is that the thing which went wrong was never in the data to begin with. The system reasoned perfectly over an incomplete world and produced a confident, useless answer.
A system should be able to say it does not know
This is the part that almost nothing in the category does, and it is the whole fix.
There are three states a project can be in, not two. Or rather, the usual three colours are the wrong three. On track. At risk. Not enough signal to have an opinion. Most tools collapse the third into the first, because green is the default and a project with no data trips no rules. That collapse is the bug. A system that can distinguish them can tell you something far more useful than a health score: it can tell you where its own vision is poor.
What that looks like in practice is unglamorous. Flagging projects where a large share of tasks have no dates, or the same date. Surfacing teams whose recorded activity dropped off a cliff two months ago. Marking a project as low-confidence rather than healthy when its last real update predates the current phase of work. Showing, next to any flag, the specific facts it was derived from, so you can see at a glance whether it reasoned from something substantial or from scraps.
That last one does double duty. It makes individual warnings arguable, which is what stops a wrong one from costing trust. You can look at the chain and say ah, it thinks this is blocked because of a link nobody closed, and fix the input rather than writing off the tool. And it means that over time you are not just consuming signals, you are getting a running report on the quality of your own records.
The bar to hold a tool to
Not is it right when it speaks, which every vendor will claim. The harder bar is whether it can tell you when it should not be speaking at all, because a blank dashboard makes nobody complacent and a confident green over an invisible project does.
SRP raises signals with the facts they were derived from attached, so a green project and a project it cannot see enough of are not the same colour. The first is good news. The second is a problem with your records, and you should be able to tell which one you are looking at.