What this clock does not compute, is how much money you leave on the table by reducing your meeting count/time and have your engineers/workers dive straight into the problem without talking enough to each other or with the stakeholders beforehand.
Sometimes it leads the death of many man-month projects, or worse.
If the requirements are weak. These meetings try to shore up weak requirements. If the requirements are strong these meetings are not important and wasteful.
ah yes. Because there is a direct and clear road ahead from requirement to implementation. Requirements don't change and if they do it doesn't have any impact on existing parts of the software. /s
My favorite is when stakeholders don't talk to devs to determine whether something is actually possible given the data we collect, but instead go off the recommendation of a technical manager who has never actually worked on the system or its data.
An assertive dev will look at the requirements, try to figure out how that fits, and then reply back to stakeholders if it's unfeasible. Everyone else will sit there for a week bashing their brains out against a keyboard and have continually increased anxiety because they've been assigned an impossible task. The time for a dev to be involved in the process is during requirements gathering as a partner to the process, not after a contract for work has been signed by the client.
That's not the point of this. You would use this for something like poor management (quite common) that had "stand-up"s on Zoom every day or couple of days that were dragging out and had too many participants listening to irrelevant updates.
Sometimes it leads the death of many man-month projects, or worse.