Doing it Quickly Takes Longer

It's an irresistible expression - we don't have time to do it properly, so just do it quickly. Leaving aside the word 'just', which I dislike, I want you to cast your mind back & think of a time when "doing it quickly" actually was quick.
In the majority of cases, it takes longer to do things quickly. That's simple history, if you go through your catalogue of past failures. In fact, given that half the time any project that is not rushed is done on or under time, it would certainly sound as if it's much more likely that a project that isn't "done quickly" will be.

This is not counter-intuitive. Here's why.

1. Pressure. The reason people want things done quickly is because there is a time pressure. If you apply pressure to something it is far more likely to explode.
2. Corner cutting/risk taking. The first thing that "doing something quickly" doesn't do is follow all of the good processes that are supposed to give a higher likelihood of success.
3. Monitoring. Everyone is under pressure, including management, to ensure that the project completes. Given the tight deadlines, everyone (at once) tries to find out what's going on so that they prove that they're on top of the problem, thus distracting those doing the work.
4. Bad estimates. Most people, if rushed for an estimate & told that a job needs to be "done quickly" will automatically underestimate it. It's a part of human nature, a part of professional pride, & it's the way such things have always been done.

I'm sure there are other things that we automatically do when someone says "do it quickly" that we wouldn't dream of doing otherwise. None of these things will improve productivity. Most will make it worse. Projects "done quickly" rarely are.

So, what do we do about it - as managers or project managers?
If you have a time constraint, then invest more resources with the expectation that no more effort will be delivered. That's a bargain where faster time needs more effort for the same output. It's a simple equation. However, I don't mean putting more people on the task, simply more people on the project. Those people have the job of ensuring that the work gets done, & nothing more.
A manager's role, for example, would be to stand guard at the developers' desks & ensure that the people who need to be informed of progress get their regular updates only from the manager, & with expectations set by the manager. Those doing the work can then get on with the task knowing that they have a schedule of reporting to only the manager once a day (or once an hour), & no more to distract them than that.
Odd bodies added to the project are there as assistants - to get coffee, collect printouts, do research, run tests, chase down experts that need to be consulted (possibly even liaise with them) - but their contribution to the deliverables is effectively zero. That's a tough call for a manager, & it's a big ask for a professional to put their ego aside & simply be at the beck & call of a peer.

That is why it is so hard to change the way that we "do things quickly". There are a lot of bad practices & ingrained habits that we have to throw away. But it will be worth it. Each time you look at how you did something quickly last time, recognise the mistakes, correct them, & get better at it - become more reliable in your "quick" tasks through creating a repeatable process for dealing with emergencies.