Personal hit parade of IT world biases

Working in software delivery business many years I see several patterns or mistakes we have a tendency to demostrate when it comes to IT projects. Here are some of my pain points. Want to share yours?

1. "Now with this big-fancy-expensive solution I can dismiss half of my personnel, right?"
Wrong, well... in most of the cases. Implementation of such powerfull tool like let's say ERP system gives management incredible visibility into what's happening within the organization and what is going to happen in the future. But it has side effects.
In order to make your operations as clear as mountain stream you need a lot of data captured in the right format and in the right moment. For that you need people who will enter that data. And they need to be qualified and motivated enough.
I would say that in 80% of projects scoped to deliver enterprise-wide solution I saw, there was no huge personnel related costs drop.

2. "There is a panacea to all our problems".
And this as well related to business as to IT guys. How many times all of us heard "Now, when we have this technology\methodology\organization we will rock!"
There's nothing bad in bringing pieces of puzzle together to get to success, but it might be too naive to believe that one single factor will change everything for good.
Thus, some people believe in AGILE that much then they are forgetting what and why they are doing, sacrificing stakeholders expectations, pieces of scope or documentation etc. just to stay "in alignment with best AGILE practices".
And don't get me wrong: AGILE is a very powerfull tool, I use it all the time, but in some cases it just might not bring such clear benefits in comparison with "old school" Waterfall (or some hybrid). For example, when you develop something for regulated environment (such as GxP) you have tons of documents for every step of the process. Following AGILE releases after each sprint it might be a challenge to actually develop something as you will need to prepare as much as hungreds pages of documentation.

3. "Develop, we'll document it later".
As a natural continuation of previous point I must state that delivery without documents is like jumping off a plane without a parachute: you can do it, but chances for happy end are... modest.
Even the most experienced project managers could fall in this battle: business is pushing, deadlines are burning, boss is unhappy, take what you "like" the most.
And then we have poorly documented release, feature, module or the whole solution. After some time nobody remembers "why we do it like that", "what will happen if we activate this liitle checkbox" or even "how do I restore it now when it fell into pieces?". And you're in that circle again, just worse: business is panicking, deadlines are burned to the ground, boss... well, you know.
I trust in balance between code and paper.