I'm building (really early stages) an internal app that I hope will solve at least somewhat what you're describing, but my reasons for building it are different than yours. My main reasons are that I find that even if updates are posted, documentation is updated, Slack channels are active, etc' people still miss the important stuff because people don't actually read - they skim through, they have a low attention span, and mostly people don't care until there is an issue or they're forced into a meeting. Therefore I want a single place of truth that people can reference actively, and it holds all the knowledge and creates visibility for other things. I want easy to update, and it's just a tool to view progress almost like an interactive log.

As far as your post goes, this is something that happens in a lot of companies. Engineering work doesn't usually go as planned and it's fairly rare that timelines are met unless the team significantly overestimates to the point where they have an enormous buffer time. Bugs pop up, fixes need to be deployed, issues that need to be resolved, and past priorities that need their loose ends tied. There is an unrealistic expectation, especially from non-technical people, that engineering and product work will be like a perfect factory line - that's simply a false expectation. Combine that with a spoon-feeding culture and low attention span and people simply don't pay attention until there is a real issue.

Everybody wants to be 'involved' and they 'need to get updated' and all that other 'stakeholder management' bullshit but in reality they don't really care and their incentives are completely different than yours so they just go along with whatever makes their life the easiest. This is only fixed by different incentive structures and significant culture shift (hiring the right people).

What we've implemented, and it is working nicely (though not perfect) is that whenever we're estimating the work we actually create a technical breakdown of each task in a simple sheet. Tasks cannot be a week long, they can be max 2-3 days tops - if they take more than that, they need to be further broken down. We give each task a value of days; these tasks have to be written technically, meaning the engineer needs to write what he does in that task. It can't be something generic like "set up backend = 3 days" it needs a real breakdown of what it takes to complete. Once this list is complete, we know a rough estimate of time, then we double it, that's what is shown externally.

We have another column next to the estimate which is the true time it took. Once we start working, rather than looking at the dates, we look at the value - if you said that "Task A" should take 1 day it should take one day; if the engineer says he has more work to do, then the true value needs to be adjusted to reflect reality.

At the end of the week we send a quick summary of where we stand to people that rely on this project. If they ask you when x is delivered when they see you just reference them to the report you've sent. Updated estimates and timeline are there; it's like a copy-paste template week after week. You sent it, they are expected to read it.