It's Thursday morning. The portfolio review deck says the integration workstream is green. It has said green for three weeks. But on Monday afternoon, a vendor engineer left a comment on a Jira ticket saying the API contract had changed and they'd need another sprint. The tech lead saw it. The delivery manager saw it. Nobody moved it into the status report, because the status report was already written.

So the room spends forty minutes making decisions against a picture of the world as it existed last Friday. Someone eventually says the quiet part out loud — this deck is always a few days behind — and the fix everyone reaches for is a process fix. Tighten the update cadence. Add a Wednesday checkpoint. Remind people to keep their tickets current.

It never works for long. Not because your people lack discipline, but because you're asking humans to do, by hand and on a schedule, something that is structurally a data problem.

Trace the path a single fact takes

Follow that vendor comment from the moment it became true to the moment it reached a decision-maker:

  • Monday, 2pm — the comment lands on a Jira ticket.
  • Tuesday — the tech lead mentions it in a stand-up. It is now in someone's memory and, if you're lucky, in a Slack thread.
  • Wednesday — the delivery manager, assembling the weekly update, either remembers to ask or doesn't. Say they do. They write a line in a Confluence page.
  • Wednesday evening — the PMO analyst pulls the Confluence pages, the Smartsheet plan, and last week's deck into this week's deck.
  • Thursday, 9am — it reaches the room. If it survived every hop.

That's three days of latency in the good case, where every human in the chain does their job correctly. Each hop is a manual copy between two systems that don't talk to each other, and each hop is a place where the fact can be dropped, softened, or aged out.

The lag isn't a symptom of a sloppy team. It's the sum of the handoffs. And handoffs are architecture.

Reporting lag — the time between a fact becoming true in a delivery system and that fact appearing in the artifact leadership actually reads. It is almost never measured, because measuring it means admitting the number.

Why "just keep the tool updated" doesn't scale

If everything lived in one tool, the process fix would work. One tool, one source, one refresh — status is a query, not an assembly job.

But that is not what an enterprise portfolio looks like. Count the systems that hold a piece of the truth about a single programme: the engineering tracker, the plan of record, the vendor's tracker that you can see but not control, the shared drive with the signed scope, the risk log someone keeps in a spreadsheet, the mailbox where the escalation actually happened, the calendar that shows the steering committee slipped by two weeks. Seven systems is a conservative count. None of them is wrong. None of them is complete.

Now the ask isn't "keep the tool updated." The ask is: have a human read seven systems, hold them in their head, reconcile the contradictions, and write down what's true. Weekly. Across every project. That's not discipline. That's an unfunded full-time job that you've distributed in slivers across people who were hired to deliver.

And the moment you distribute it, you get the second-order problem: nobody owns the reconciliation, so when two systems disagree, the version that reaches the deck is whichever one the person assembling it happened to open.

Your status report isn't late because people are slow. It's late because it's a manual join across systems that were never designed to be joined.

What the lag actually costs

A three-day lag sounds tolerable. It isn't, for a specific reason: the lag doesn't apply evenly to good news and bad news.

Good news travels fast. People volunteer it. Bad news has to survive a chain of humans, each of whom has a rational incentive to wait one more cycle — maybe it resolves itself, maybe we fix it before anyone asks, maybe it's not confirmed enough to escalate yet. So the lag on a risk is systematically longer than the lag on a milestone.

What you get is not a portfolio view that is uniformly three days old. You get one that is current on progress and stale on risk. Which is precisely inverted from what a steering committee needs, and it's why so many programmes appear to go from green to red in a single reporting cycle. They didn't. The red was accumulating in a comment thread for a month; it just never cleared the handoffs.

The cost isn't the staleness. It's that the decisions with the longest lead times — reallocating budget, renegotiating a vendor SOW, moving a go-live — are the ones that depend on the signal that arrives last.

The architectural fix, in three moves

If the lag comes from handoffs, the fix has to remove handoffs rather than schedule them more tightly. In practice that means three changes to how the reporting layer is built.

Pull instead of push. Stop asking systems of record to be updated for reporting. Read them where they already are. A tool that connects to Jira, the plan, the docs, and the mailbox doesn't need anyone to re-enter anything — the fact that landed at 2pm Monday is visible at 2:01pm Monday. The vendor's tracker you can't control becomes readable rather than a blind spot.

Synthesize instead of collect. A dashboard that shows you seven tools side by side has moved the reconciliation problem onto a single screen, not solved it. The work that the analyst was doing — noticing that the ticket comment contradicts the plan date, and that the contradiction is the story — is the part that has to be automated. Aggregation is not synthesis.

Cite everything. The reason organisations tolerate the manual chain is that a human in the loop is accountable for the number. Remove the human and you have to replace that accountability with something. The replacement is provenance: every statement in the report links back to the specific ticket, message, or document it came from. Then a claim can be checked in ten seconds instead of defended for ten minutes, and people will actually trust a report they didn't assemble themselves.

None of this removes judgement from the process. The steering committee still decides what to do about a slipped API contract. What it removes is the three days spent discovering that the contract slipped — and the systematic bias that made the risk arrive later than the progress.

The question worth asking on Thursday

Next time a status deck goes up, don't ask whether it's accurate. Ask a narrower question: what is the oldest fact on this slide, and how old is it?

Most PMO leaders we've asked don't know. The few who do have usually measured it once, been unsettled by the answer, and gone looking for a structural fix rather than a stricter cadence. That number — your actual reporting lag — is the honest baseline for everything else in this series.

We're building Soriela because we think the reporting layer is the wrong shape, not because the people operating it aren't trying hard enough. Next in this series, we'll get concrete about the seven systems: what each one actually knows about a project, what it can't know, and where the contradictions between them tend to hide.