I often see people talk about the effects of games being delayed with the stress, crunch, and time pressures - but I don't think many people understand why delays happen. So I'm going to explain that, and to do that, we need to go back to the 1890s manufacturing days and then to a 1950s Japanese car company.
Back in the 1880s and 1890s, Frederick Taylor came up with Scientific Management (aka Taylorism) for use in manufacturing steel, which he defined as "knowing exactly what you want men to do, and then seeing that they do it in the best and cheapest way". One of the largest business costs are wages, so if manufacturing steps can be aligned right after each other with minimal time between them, owners can have workers make more product in less time which equates to more profit.
This boost in productivity that Taylor helped bring about came at the expense of downtime for workers. Taken to its logical conclusion, all downtime for workers is removed and they become a cog in the machine of manufacturing and you can see this with how Amazon treats its workers in their distribution centers. Workers end up paying for this with their bodies. No downtime can mean more mistakes and serious injury or death on the job, but it does mean more profit for capitalists, so there's that upside!
Fast forward a number of years and after WW2, Toyota popularized another business practice called Kaizen, aka Continuous Improvement. The theory is that workers can continuously improve their efficiency or fix problems so they can produce more. With Kaizen, Toyota also implemented something they called the Andon cord. Workers could pull it on the manufacturing line to immediately halt all production to address issues. This causes delays and costs money to fix the issues, but for a manufacturing line that builds the same thing over and over, these micro-optimizations can help produce things quite a bit faster in the long term.
Game Development
So finally coming back to game development, you can see some of this history in how we make games. We often use scrum, which consists of defining work which is tracked in Gantt charts to see if we can hit a particular release date, and then we prioritize and optimize schedules to cram all the work in that amount of time. We then make micro-optimizations to the schedule over time to try to improve reliability of the date.
There's a huge flaw in the way we plan for work, though. We're not a manufacturing business, we're a creative and research business. So optimizing schedules doesn't matter nearly as much as whether major decisions for the game are changed late in the process. For games, major delays happen for a couple of reasons, but the biggest one I've seen is that leadership changes their mind for large areas of the game mid-development. This may be for good reasons or less good reasons, but the impact that has is tremendous.
If you think of the previous micro-optimizations that were being made - for each of those made, the game becomes more set in its path and less able to pivot. This is good when you know what you're building on a factory line, but makes the cost of changes even more pronounced in games when it happens late into development.
When everything is completely scheduled out in timelines in a waterfall type method to hit a date (which is effectively what Gantt charts are), any large change in direction invalidates that schedule. And very often, the ship date hasn't changed, only the work has. The other thing an optimized schedule does not allow for is a buffer for unknown things to happen (ie: the research). We don't have a manufacturing process for games, each one is bespoke. So when unexpected stuff comes up, and that happens all the time, it again breaks the schedule.
If engineering takes longer on a feature than expected, that can impact art, which could impact design and QA, etc. When delays happen, management often crucially fails at this point. They try to "unblock" people. Why is that an issue you might ask? Because the people blocked may not be the bottleneck for the whole project. If engineering is the bottleneck because they have the most work for the game (and they usually are), then giving them MORE work to unblock art or design actually delays the game rather than making it quicker. It's better to have art or design do literally nothing or start cutting areas or features, otherwise unblocking them could delay the schedule further by adding work for the bottleneck discipline.
Management wants everyone working all the time to minimize labor costs, but they often do this only in disciplines because it's easier to estimate than looking at the whole team. If they wanted to do it even better, they'd evaluate which discipline is the bottleneck and optimize around that. This, however, is also fraught with issues because there's still so much unknown in shipping games. You can never remove the risk of something coming up.
TL;DR - management in the games industry took ideas and theories from manufacturing and misapplied them to a creative and research industry and didn't add the fail safes that manufacturing has. You can't fill a schedule out months in advance and expect to hit the date and yet that's what every team I've been on has done.
THAT is why games are always late, over budget, and so hard on workers to make.