Comments on: Quality Costs http://svprojectmanagement.com/quality-costs Project management wisdom from practictioners and the UCSC Extension in Silicon Valley Tue, 09 Mar 2010 15:04:34 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Dina Garfinkel http://svprojectmanagement.com/quality-costs/comment-page-1#comment-5379 Dina Garfinkel Fri, 12 Jun 2009 21:07:02 +0000 http://svprojectmanagement.com/?p=2411#comment-5379 Great post! I think the key words here (you mentioned them in requirements review) is "Early and Often". The chart that I love to reference to illustrate this is the Cost of Defect Prevention from the Construx group: http://construx.com/Page.aspx?cid=1459 This clearly shows the cost to correct a defect found at different stages of the project. Anyone who's had to fix a showstopper bug POST-launch will not need to look at the big spike on the right to remember how costly (money, time, stress) it is to repair something that could have been caught earlier. Great post! I think the key words here (you mentioned them in requirements review) is “Early and Often”. The chart that I love to reference to illustrate this is the Cost of Defect Prevention from the Construx group:

http://construx.com/Page.aspx?cid=1459

This clearly shows the cost to correct a defect found at different stages of the project. Anyone who’s had to fix a showstopper bug POST-launch will not need to look at the big spike on the right to remember how costly (money, time, stress) it is to repair something that could have been caught
earlier.

]]> By: Alan Tsuda http://svprojectmanagement.com/quality-costs/comment-page-1#comment-5016 Alan Tsuda Fri, 29 May 2009 21:37:47 +0000 http://svprojectmanagement.com/?p=2411#comment-5016 Shouldn't really be controversial... As Peter Drucker states: "Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for." It really is about the customer. I think that sometimes, as product developers, we have gotten lucky -- that cool new thing just happens to resonate with enough people. "If we build it, they will come." We can think of a few "buggy" products that still found willing (even enthusiastic) customers (thanks to those "pioneers" and "early adopters!"), can't we? -- at least until expectations and the perception of quality changes (or, we attract new and different customers). Shouldn’t really be controversial… As Peter Drucker states:

“Quality in a product or service is not what the supplier puts in. It is what the customer gets out and is willing to pay for.”

It really is about the customer. I think that sometimes, as product developers, we have gotten lucky — that cool new thing just happens to resonate with enough people. “If we build it, they will come.” We can think of a few “buggy” products that still found willing (even enthusiastic) customers (thanks to those “pioneers” and “early adopters!”), can’t we? — at least until expectations and the perception of quality changes (or, we attract new and different customers).

]]> By: Loyal Mealer http://svprojectmanagement.com/quality-costs/comment-page-1#comment-4984 Loyal Mealer Fri, 29 May 2009 00:35:53 +0000 http://svprojectmanagement.com/?p=2411#comment-4984 Many people consider quality to be just another 'feature' to be traded off against other features for a product, which in turn are balanced with resources and time in the traditional constraint triangle. Burying quality with other features only works for a mature organization where the importance of quality is well understood and managed. For young or immature organizations, quality should be given its own leg on the triangle. One thing to consider, and this may be controversial for some, is that you can have too much quality. Sure, for the most part, quality pays for itself, and therefore, more is better. But, there is always a break-even point where adding more quality (e.g., removing that last low-priority bug) returns less than the lost revenue for being late to market. Many people consider quality to be just another ‘feature’ to be traded off against other features for a product, which in turn are balanced with resources and time in the traditional constraint triangle. Burying quality with other features only works for a mature organization where the importance of quality is well understood and managed. For young or immature organizations, quality should be given its own leg on the triangle.

One thing to consider, and this may be controversial for some, is that you can have too much quality. Sure, for the most part, quality pays for itself, and therefore, more is better. But, there is always a break-even point where adding more quality (e.g., removing that last low-priority bug) returns less than the lost revenue for being late to market.

]]> By: Tâm Nguyen http://svprojectmanagement.com/quality-costs/comment-page-1#comment-4941 Tâm Nguyen Thu, 28 May 2009 00:12:30 +0000 http://svprojectmanagement.com/?p=2411#comment-4941 Thanks for your comments, Kimberly. While the tour of duty is a simple concept, it's rarely implemented because of the constant lack of resource in engineering. In the long run, it has tremendous value because one can't really understand the challenges that another person face until he or she feels the same pain. Intellectual understanding doesn't yield the same level of responsive action. Thanks for your comments, Kimberly. While the tour of duty is a simple concept, it’s rarely implemented because of the constant lack of resource in engineering. In the long run, it has tremendous value because one can’t really understand the challenges that another person face until he or she feels the same pain. Intellectual understanding doesn’t yield the same level of responsive action.

]]> By: Kimberly Wiefling http://svprojectmanagement.com/quality-costs/comment-page-1#comment-4937 Kimberly Wiefling Wed, 27 May 2009 23:50:32 +0000 http://svprojectmanagement.com/?p=2411#comment-4937 Absolutely right in my view, Tâm! These recommendations might seem like common sense, but they are certainly NOT common knowledge or common practice. It's been incredible to me over the years to see the foolhardiness and lack of humility with which people approach launching a product. I started my career in customer service, repairing mass spectrometers and gas chromatographs for HP, and I've seen customers in tears over a broken instrument. When I later worked at the factory in manufacturing engineering you better believe I was passionate about quality! And later when I led an R&D product development project I insisted that the R&D engineers spend time in manufacturing actually helping build the prototypes, which I also insisted be built by the very same people who would build the production versions. At other times I've had engineers do "follow me home" programs where they actually have to watch customers struggling to install, learn and use their system. They are always amazed at how challenging it is for customers. Suddenly that bug that was classified a "feature request" becomes a bug again, and they have more passion for fixing it! But getting engineers to embrace having their work peer reviewed, taking the time to really understand the customer, do a couple of shifts in tech support, in manufacturing, or even a customer visit, has been met with mild enthusiasm in most cases. After all, they have "real" work to do. . . . unfortunately, without a solid understanding of the challenges faced by the whole process, and especially the customer, it is often "full speed ahead in the wrong direction"! - Kimberly Wiefling, Author, Scrappy Project Management Absolutely right in my view, Tâm! These recommendations might seem like common sense, but they are certainly NOT common knowledge or common practice. It’s been incredible to me over the years to see the foolhardiness and lack of humility with which people approach launching a product. I started my career in customer service, repairing mass spectrometers and gas chromatographs for HP, and I’ve seen customers in tears over a broken instrument. When I later worked at the factory in manufacturing engineering you better believe I was passionate about quality!

And later when I led an R&D product development project I insisted that the R&D engineers spend time in manufacturing actually helping build the prototypes, which I also insisted be built by the very same people who would build the production versions. At other times I’ve had engineers do “follow me home” programs where they actually have to watch customers struggling to install, learn and use their system. They are always amazed at how challenging it is for customers. Suddenly that bug that was classified a “feature request” becomes a bug again, and they have more passion for fixing it!

But getting engineers to embrace having their work peer reviewed, taking the time to really understand the customer, do a couple of shifts in tech support, in manufacturing, or even a customer visit, has been met with mild enthusiasm in most cases. After all, they have “real” work to do.

. . . unfortunately, without a solid understanding of the challenges faced by the whole process, and especially the customer, it is often “full speed ahead in the wrong direction”!

- Kimberly Wiefling, Author, Scrappy Project Management

]]>