My projects mostly revolve around training development, either as a PM on a training initiative or as a training consultant on a larger project. In the latter case, fast-tracking is very common, especially when we're talking about an IT project involving development of a new system or tool. Because the project sponsors often want the product delivered at the earliest possible date, we often can't wait for the product development to be completed before we start developing the training. This means we do a lot of our work based on the design requirements, not the actual product, and while that allows us to complete the training development in parallel with the technical development, we often find ourselves scrambling to retrofit our training materials to account for a late-stage design changes, bug workarounds, etc.
As for crashing projects, that happened quite a bit when I was managing a training team. Because we were an internal support team that didn't bill other departments for our services, time was our primary concern. We held regular team meetings to gauge everybody's status, and would regularly move people around to add extra resources to make sure we could make a deadline, but at an opportunity cost - every resource I put onto project A meant taking a resource away from project B, and while that didn't cost us actual money, it was definitely an opportunity cost that had to be accounted for.