Part 03
The risk was visible three weeks before anyone escalated it
The signals behind a late risk are rarely weak. They're scattered — across systems, across weeks, across people — and nobody puts them side by side.
The Soriela founders5 min read
The escalation lands ten minutes into the steering call. The data migration will miss its date: the vendor needs two more weeks to deliver a test environment the whole plan was waiting on. Someone asks the question every post-mortem starts with — how long have we known?
So someone goes back through the record, and the answer is uncomfortable. Not this week. Not last week. The first sign was there three weeks ago, and so was nearly every sign after it.
Reconstructing the three weeks
Nobody hid anything. Every one of these signals was recorded, by someone doing their job, in the system where that kind of thing lives.
Six signals, four systems, three weeks. Each one is small on its own. A ticket that slid back to Waiting without a comment. A question in a channel that nobody answered. A due date edited without a note. An email read by the one person who wasn't in the next stand-up.
Raised alone, any of them would have sounded like noise. Read together, they tell one story: a dependency has stalled, and the plan hasn't noticed.
Weak signals are a myth. Scattered ones aren't.
The usual explanation for a late risk is that the early signs were weak — too ambiguous to act on, too easy to dismiss. Go back through the record and that's rarely what you find. We'll need two more weeks is not ambiguous. Neither is a ticket that has gone back to waiting on a vendor.
What made them easy to miss is that they never appeared in the same place at the same time. The strength of a signal isn't a property of the signal. It's a property of what it sits next to.
The vendor's email, read beside the edited due date and the unanswered question, is an alarm. Read alone, in an inbox, between forty other emails, it's a status update.
Why nobody puts them side by side
It's tempting to make this a people problem: someone should have connected the dots. But look at who would have had to. The tech lead saw the ticket. The delivery manager ran the stand-up. Someone on the team asked in the channel. The vendor manager read the email. Each of them held one piece, and none of them had a reason to think it mattered more than that.
Connecting the pieces takes someone whose job is to read all four systems, every day, looking specifically for things that rhyme. Most organisations don't have that person. The ones that do have usually handed them twenty projects and a Thursday deadline.
And there's the asymmetry from Part 01: bad news travels slower than good news. Each of those four people had a perfectly rational reason to wait one more week before calling a single data point a risk. Four reasonable waits, none of them long, and nobody holding more than one piece — that is how a visible risk stays invisible for three weeks.
Reading the record forwards
Every post-mortem reads the record backwards, starting from the escalation, and finds the trail. The trail was always there. The fix is to read the record forwards — continuously, across systems — so the trail is visible while it's still being laid. In practice that asks for three things.
- Read every system the project lives in. Not just the one designated as the source of truth. The plan is where the date lives; the chat, the inbox and the meeting notes are where it starts to move.
- Look for corroboration, not volume. Two quiet signals from different systems about the same dependency matter more than ten loud ones from the same place. Agreement across sources is what turns noise into a pattern.
- Raise the flag with the trail attached. A risk raised with its evidence gets acted on. A risk raised on instinct gets debated — usually until the next steering call.
How Soriela handles this. Soriela reads the plan, the tracker, the channels and the mailbox together, and raises a risk when signals from different places start telling the same story — with every signal linked, so the trail arrives with the flag instead of three weeks after it.
Try this on your last escalation
Pick the last risk that reached your steering committee late. Go back through the record and write down the first date each system showed a sign of it — the tracker, the channels, the inbox, the meeting notes.
Then measure the gap between the earliest of those dates and the day it was escalated.
If the gap is measured in days, your reporting layer is doing its job. If it's measured in weeks, the signals weren't weak. They were just apart.
Next in this series: “The AI said so” doesn't survive an audit →