"Most improved processes in all parts of the company can no[t] be directly tied to an increase in revenue or a decrease in costs, so even though people understand that Quality Assurance is something beneficial, they don't know how to quantify how beneficial it is."
Then they don't know their craft. Not knowing _how_ doesn't mean it isn't both possible and necessary.
There was a study performed by The Boston Group (reported in the Wall Street Journal of a few years back) about the appalling failures of "quality programs" across a wide sample of companies in various industries, which revealed these failed efforts shared one common trait: "quality was not tied to the bottom line". Those companies that did make this vital tie were also the ones that saw the continuing, measurable benefit.
And that's the key. Unmeasured benefit is no benefit at all, and cannot display its value when cost/benefit decisions must inevitably be made.
If your top management is involved, and is able to see verifiable numbers that show them a real cause-and-effect relationship between actions to improve quality, on the one hand, and the lowering of costs (with increase in reliability and shortening of delivery time), on the other, you'll be taking your life in your hands if you try to yank the quality program out of their hot little hands.
The problem, of course, is that most top managements give quality only the barest lip service -- pompous utterances and catch-phrases -- which will inevitably assure failure.
If your top management is faint-hearted and disinvolved, abandon all hope that any sustaining improvement will ever occur. Attend the meetings, smile a lot, nod enthusiastically. But don't believe for a single moment that it's anything more than another temporary hysteria sweeping the organization like all the others that periodically come and go.
The IT industry is fond of talking "QA" while it spends all its energy focussed on "QC" (testing). QA is a buzzword having almost no meaning in this industry, where testing is the de facto holy grail. Eventually, some smart folks are going to realize that testing is the implacable enemy of quality -- certainly not its handmaiden. Now that everyone is less distracted by all that cash floating around, maybe they'll get serious.
Most people who use the word "quality" have no real clue what they are talking about, and inevitably tend to speak in terms of quality of product rather than quality of the process by which the product is created. Engineers especially.
It isn't a question of whether a product can be made "really nice"; it's a question of how much time and effort will be required to make it so.
The observation that a band of monkeys on typewriters could eventually produce the Encyclopedia Brittanica (the really nice product) was not to suggest the goal will have been achieved in the presence of "quality" -- which has only to do with the effectiveness and end-to-end speed of the process that gets that job done right. (Add multiple testing cycles to this process, and it will take even longer. But the prevailing view seems to be that it all pays the same.)
A related notion, popular if misled, is that "more quality" requires "more input" of time, energy, and money. In the very short term, this can be true. But very soon, the balance shifts the other way. And the more it shifts, the more it shifts. And if process costs aren't falling, then you aren't getting improvement in quality -- even if every other "metric" insists that you are.
Speed of process has nothing to do with the speed of people involved in it. Indeed, if people are really rushed and pushed into long hours for months, end-to-end throughput time will likely increase sharply. There are many people who believe that you can arbitrarily shorten a project schedule without raising its costs. There are also people who still believe in the Tooth Fairy. Processes go faster when and because they are well-oiled and well engineered. They do not go faster simply because some salesman or manager made an air-headed promise to a customer.
It is appropriate to recall that Richard Stallman starts his thesis with the premise that having countless programmers endlessly iterating new code to do the same old stuff adds little wealth to the pot -- and a great deal of trash. As others in this discussion have rightly pointed out, the investment of a bit more effort to create a robust program (or any other) module that is portable to future use pays off like a cash register, again and again.
You can measure the benefit. You can most certainly tie the results to the bottom line. And you absolutely must do so to get any recognizable, positive change.
Slashdot Mirror
"Most improved processes in all parts of the company can no[t] be directly tied to an increase in revenue or a decrease in costs, so even though people understand that Quality Assurance is something beneficial, they don't know how to quantify how beneficial it is."
Then they don't know their craft. Not knowing _how_ doesn't mean it isn't both possible and necessary.
There was a study performed by The Boston Group (reported in the Wall Street Journal of a few years back) about the appalling failures of "quality programs" across a wide sample of companies in various industries, which revealed these failed efforts shared one common trait: "quality was not tied to the bottom line". Those companies that did make this vital tie were also the ones that saw the continuing, measurable benefit.
And that's the key. Unmeasured benefit is no benefit at all, and cannot display its value when cost/benefit decisions must inevitably be made.
If your top management is involved, and is able to see verifiable numbers that show them a real cause-and-effect relationship between actions to improve quality, on the one hand, and the lowering of costs (with increase in reliability and shortening of delivery time), on the other, you'll be taking your life in your hands if you try to yank the quality program out of their hot little hands.
The problem, of course, is that most top managements give quality only the barest lip service -- pompous utterances and catch-phrases -- which will inevitably assure failure.
If your top management is faint-hearted and disinvolved, abandon all hope that any sustaining improvement will ever occur. Attend the meetings, smile a lot, nod enthusiastically. But don't believe for a single moment that it's anything more than another temporary hysteria sweeping the organization like all the others that periodically come and go.
The IT industry is fond of talking "QA" while it spends all its energy focussed on "QC" (testing). QA is a buzzword having almost no meaning in this industry, where testing is the de facto holy grail. Eventually, some smart folks are going to realize that testing is the implacable enemy of quality -- certainly not its handmaiden. Now that everyone is less distracted by all that cash floating around, maybe they'll get serious.
Most people who use the word "quality" have no real clue what they are talking about, and inevitably tend to speak in terms of quality of product rather than quality of the process by which the product is created. Engineers especially.
It isn't a question of whether a product can be made "really nice"; it's a question of how much time and effort will be required to make it so.
The observation that a band of monkeys on typewriters could eventually produce the Encyclopedia Brittanica (the really nice product) was not to suggest the goal will have been achieved in the presence of "quality" -- which has only to do with the effectiveness and end-to-end speed of the process that gets that job done right. (Add multiple testing cycles to this process, and it will take even longer. But the prevailing view seems to be that it all pays the same.)
A related notion, popular if misled, is that "more quality" requires "more input" of time, energy, and money. In the very short term, this can be true. But very soon, the balance shifts the other way. And the more it shifts, the more it shifts. And if process costs aren't falling, then you aren't getting improvement in quality -- even if every other "metric" insists that you are.
Speed of process has nothing to do with the speed of people involved in it. Indeed, if people are really rushed and pushed into long hours for months, end-to-end throughput time will likely increase sharply. There are many people who believe that you can arbitrarily shorten a project schedule without raising its costs. There are also people who still believe in the Tooth Fairy. Processes go faster when and because they are well-oiled and well engineered. They do not go faster simply because some salesman or manager made an air-headed promise to a customer.
It is appropriate to recall that Richard Stallman starts his thesis with the premise that having countless programmers endlessly iterating new code to do the same old stuff adds little wealth to the pot -- and a great deal of trash. As others in this discussion have rightly pointed out, the investment of a bit more effort to create a robust program (or any other) module that is portable to future use pays off like a cash register, again and again.
You can measure the benefit. You can most certainly tie the results to the bottom line. And you absolutely must do so to get any recognizable, positive change.