There is an argument, which I am very sympathetic to, that quality lowers cost and increases the speed of software development. Unfortunately, quite often, the proponents of this argument miss out a phrase, “in the long run“. And because they do not tell the whole truth, it avoids dealing with real business concerns. It is dangerous because it leads to throwing out the baby (quality) with the babywater (higher initial costs).
The cause, I think, is that people confuses higher quality now with the transition from low quality to high quality. When your software development team is already working at a high level of quality, you are already saving time and money by avoiding rework and having to fix costly bugs. Maintenance is easier. Adding new features is done faster. So things are good.
But when you are trying to move from your present quality level to a higher quality level, there will be transition costs. This includes the time and money spent on quality personnel, training, new processes, documentation, piloting and so on. And even the best of transitions will involve irrecoverable losses because of mistakes made during piloting and tailoring the new quality processes.
As an organization, you need to budget for these transition costs and have an understanding (formal or informal) about the return on investment, i.e., how long will it take for these quality initiatives to start paying for themselves. Such an exercise can also help you accelerate the launch of the quality initiatives that can offer the fastest bang-for-the buck. For example, while both are important, code reviews have quick returns while automated testing has a more gradual return on investment.
So the real argument is, “Improving quality will cost you in time, effort and money, but it is an investment for the future with some immediate, but other long-term benefits. And here is how and when it will pay off.” That is much more meaningful and truthful. And it has a much greater chance of being accepted by a business manager.