I have worked in product development and quality assurance in three different industries.
Justifying QA is an education and organizational maturity issue. The value of dedicated QA varies depending on the size of the team (specialization of roles) and the risk associated with problems in the software. Some teams cannot justify it. Every project is unique.
In my experience, the need for dedicated QA comes down to two things:
1) Perspective and Risk.
It is easy to say everyone should check their own work, however this is a utopian construct similar to saying your kid should grade their own math homework. Developers are by nature of their work are almost always removed from the user and product perspective that is critical to good QA. The nature of their job requires them to focus on drilling down into the detail of complex logic problems. If they are providing good code and good throughput, most developers will not be able to also do good QA. Most people can indentify with writing a research paper or thesis, and how when you come back to it after doing something else for several days you to see significant issues in your writing. Developers do not have the luxury of letting code sit around for a few days while they shoot hoops and then look at it with "fresh eyes", and they rarely have the perspective of the end user or client. It isn't even fair to ask them to do their own QA. They are super smart people, but they are not magicians. If the risk of problems in the software is important to your company/product/clients, then how QA is executed needs to be an ongoing discussion during development.
2) Turnaround time and build cycles.
If you want rapid iterations of releases and builds, you will need simultaneous development and testing. It is not possible to code, QA, fix, and QA fixes with fast turnaround without some specialization of roles.
Who should do it then?
A good transition step to a full staff allocation for dedicated software QA is to combine it with a business analyst or product role. Business analysis and testing are two sides of the same coin. Verification of can be done by most anyone with some distance from the code and familiarity with the SDLC of the team, but true validation requires someone on the product side that has the perspective of the end user at the forefront of their mind. Bringing someone from the product side into close collaboration with a software team is a beautiful thing. This person really needs to decide to become an extension of the development team, and learn the way things work on the development side. A good QA person winds up doing a lot of BA in reverse anyway, just to model information to make things testable and consumable by developers.
A last thing to consider is "testing" vs. "QA". Testing is a task, is more easily outsourced, and depending on the work can be completed by developers with some success. On the other hand, QA is a profession/career, and incorporates a lot of testing but takes on a lot of holistic perspective. If you have ever worked in a regulatory driven, manufacturing, healthcare, or financial organization you know QA is a whole profession even without a line of code. In quality professions this is often articulated as quality control vs. quality assurance, and is worth a 10-minute Google tour of the subject matter. Calling QA "testing" really takes it down a bunch of notches, but it might be the best way get your foot in the door with your management team. The value of testing is more tangible to them.
Steps (may take multiple iterations, perhaps over months or a couple years:
1) Define the requirements or user stories or their equivalent for each software iteration. Leverage your business analyst if you have one. This is actually far more valuable than dedicated QA.
2) Define QA deliverables to ensure these are met and divvy them up across the team so the deliverables themselves become justified, regardless of who does them.
3) Engage management in discussions about intelligent use of resources based on skill set. Many managers figure out they need to keep their developers coding and it is easier to have someone else do the QA. After a while, in many environments it becomes clear you need someone who is dedicated to the profession to do a really good job. Your project and company will have unique needs, and these will become clear over time.
4) Sometimes the company culture or the education barrier just cannot be overcome. If you are passionate about good product, and your management team is unwilling work toward that end you might be in the wrong company. Software has an intangible quality, and many companies just can't wrap their heads around the unique challenges in the industry. If you find you are speaking a different language and people are not understanding you, you may have outgrown your environment and need to move on.