A few years back I was at a conference and attended a talk that opened my eyes to why the majority of my efforts in trying to get management to "Get It" in regards to the need for testing were failing.  It wasn't them, it was me.

I didn't understand the "language" I needed to be speaking to them with.  I was focused on the technical aspects and implications for the project.  Instead I needed to be focused on the economic implications and impacts to the company.  Management deals in money, dollars and cents for you in the U.S., and how much they will make and/or keep from a project/product.

It comes down to "selling" Testing/QA as a "Cost Containment" mechanism (not Cost Savings, that sets a false expectation).  The cost containment comes in checks and balances to make sure the money being spent is done so properly and that if there is any leakage (rework) that it is kept under control.  Project cost leakage (rework) is one of the top reasons why projects go over budget and over time. 

Probably the best tool to use to sell management on Testing/QA is the Cost to Fix curve.  Basically the curve shows that the earlier a defect is found and fixed the lower the cost.  But here in lies part of the sales job problem, most people only go that far.  What needs to be done is to show the relationship between when a defect is introduced and when it is found/fixed and the associated cost with the rework of the system (a cumulative effect).  This definitively shows the relationship in economic terms that will catch managements attention. 

For example, a defect that is introduced in the Requirements phase and not fixed/found until the Testing phase is expensive to repair (longer time in between) and the amount of rework to remedy the defect compounds the overall cost (initial cost + rework cost  = total cost).  Now if a defect is introduced in the Requirements phase and found/fixed in the Design/Coding phase the cost is lower (flatter section of the curve) and its rework cost is now minimized (containing the leakage).  Even if the defect was introduced during the final stages of Coding and found/fixed in the Testing phase the cost is minimized (a steeper part of the curve, but the cumulative effect is minimal) because the rework cost is minimized too.

Now this information can be shown to impact "hidden" money factors that affect the immedite project and the company in the long run.  This leads to impacts on the Profit & Loss (P&L), EBDCITA (Earnings Before Debits Credits Interest Taxes and Amortization), ROI (Return on Investment) and Revenue Stream (short term and long term).  These impacts can be hard dollars (over budget or not making revenue because product is not selling or cost of rework after release) or soft dollars (future business lost due to credibility issues).  This is what the presenter called getting into the GOOB zone (Going Out Of Business).  Showing this will definitely get managements attention.

So how does Testing/QA help to keep this all under control.  Easy, by providing the service of validation of the system (Testing, from the beginning) and monitoring of the project (QA) with review milestones.  This takes the form of the medical principle of "a pinch of prevention is worth more than a pound of cure".  In money terms this makes the statement that a small up front investment can provide a very large return in the end.  How to leverage that small amount of money to counter balance a large one by shifting the balance point.  This is what management understands. 

What Testing/QA needs to do is "sell" this aspect of our contribution to the project; to change the language we talk in to one that management understands and will "buy in" to.  As the old saying goes "Money talks, B.S. walks!"