From there, I'd start by laying down some process. One of my old workplaces was rife with micro-management, and the only way around it was to define a process for how the development team work, interact, test, etc. We had numerous hiccups, despite all sides agreeing to this method of working, but the strongest team in the company at the time was the dev team, and that quality saw us through.
I like The Joel Test suggestion, because it sets some ground rules for how the dev team should work. I'd go further, and I'd work with your own dev team(s), and the managers of other departments to find out what they want from a unified process. From there, build an internal process document and an external document, and ask for time to implement this process. Treat it like a project and assign time/resource to it, especially if your developers have downtime. At my last place we did this, and naturally ended up filling many of the blanks in The Joel Test through trying to improve our processes. We switched to automated builds and deploys, we created a robust hiring process, and vastly improved how we test software.
Finally, despite your worries, I'd thank your dev team for doing the job they've been doing. Everyone knows when a project is going to shit, but positivity goes a long way towards salvaging it and turning it into valuable lessons. In my view, bugs are a good thing, because it provides another iteration of tests and fixes, and if you can buy time for your team to iterate over your product(s) while building a robust development process, you'll naturally see happiness increase.