At my firm, we don't really have a QA department. If you've followed some of my other questions you know essentially, we have no automated tests and our 'testers' are the analysts who design the projects.
When I recently brought up the idea of a more formal (I actually used the term 'industry standard') QA department, I was told "The decision was made to go to a lean development process." Turns out that decision was made about 7 or 8 years ago. Only in the last 5 months have I convinced them to move to a 2 week deploy cycle (it was 3-4 months before) and only in the last month are they cutting a 'build' that goes for the 'testers' to test. Also, any changes necessary are made to that 'build' (the code is able to be compiled or interpreted, so modification is easy.) The reason 'build' is in quotes is because it's really just a copy of trunk, with the most recent changes put higher up in the path so they get found first, and it all gets interpreted on the fly.
So, it seems there's a fundamental misunderstanding of what "lean development" is. They had a QA department in the past, but were bothered by their lack of productivity. Of course, we know that a QA department isn't 'productive'. If you look at it from a manufacturing point of view (which they do,) QA by definition hinders productivity by increasing the chance of failed and extended-time projects. (We've tried using the argument that QA for software is like QA for the products they manufacture. They don't see it the same way because there's government mandates for their QA, but not for the software.)
How can I convince them that a formal QA will benefit the company?