Archive for July 25th, 2008

• Pay Attention to the Obvious

  Date: 2008.07.25 | Category: Design for Six Sigma, Practices, Voice of the Customer | Response: 0

  The other day we were talking about DfSS and how much training material we were going to produce and what sort of timelines we could commit to. I was having a hard time wrapping my head around the scope of the problem because it seemed very large and undefined. Specifically, I was thinking I had a LOT of original training I needed to create around some Agile code practices. Somewhere along the way I had missed aan important concept about my role on the DfSS rollout team. For some reason, I was under the impression that DfSS was about making better engineers.

  “Noooo. DfSS (DESIGN for Six Sigma) is about taking good engineers (people with good skills and proven engineering aptitude) and training them to become good designers.”

  While had been consistently told that DfSS is the program is about “designing quality into the system”, what I heard was “building quality into the system”. During the implementation (ostensibly the work that happens after DfSS), quality engineering practices are monitored and controlled via the scorecard. It is through the scorecard that good engineering practices like continuous integration, automated unit tests,refactoring, etc., etc. are implied to the Team. During implementation, you have to do “something” which will satisfy the scorecard, that “something” is up to you.

  Call me a bit skeptical about using the scorecard as a control mechanism for good engineering practices. I feel comfortable that the design coming from DfSS will be excellent, reflect the Voice of the Customer and be marketable, but leaving implementation as a black box to be monitored via a scorecard at phase gates ,or through periodic in-process reviews, leaves me less than satisfied. It seems to me that DfSS relies heavily on the ability of the DfSS Black Belt to bring both an excellent design AND quality engineering practices to the implementation team. In many of the environments I have encountered, there is big gap between the skills of the designers and the implementation team. It might be a bridge too far, I don’t know.