The translation of ‘whats’ into ‘hows’ is influential on the House of Quality algorithmic transfer function. In a large matrix with many-to-many relationships, which is not uncommon, there is a degree of tolerance to imprecision when scoring the ‘whats’ and ‘hows’ interactions . The effect can potentially mask flaws in the requirements translation. We must therefore take additional steps to assure that the translation is performed well. There should be that certain balance between the ‘hows’ and the ‘whats’. This balancing should be assured before we start any relationships scoring.
There should be proportionality between the importance rating of an individual or related group of customer requirements and the quantity number of design requirements that we translate from it [Mark Atherton, 1999].
Common sense tells us that it would be wrong to establish an enhanced focus, by translating a large quantity of detailed design requirements for our attention, on something that the customer has rated lowly; while simultaneously establish a lesser focus, by translating only a very few design requirements, on something the customer has rated highly. It is not essential that the number is exact, but it should not be too far out either.
If a customer requirement is highly important, but the QFD team in the first instance is unable to translate more than a single design requirement from it, then try breaking this single design requirement down into its more detailed characteristics. Likewise, if the customer importance for a requirement was very low, but the QFD team has managed to identify a disproportionally high number of design requirements for it, then try simplifying or merging the multiple design requirements into a reduced – for the planning purpose. We cannot identify any adverse effects from creating multiple design requirements in relation to a single customer requirement, other than it will increase matrix complexity through more details. Inappropriately few design requirements, on the other hand, could mean too low a matrix resolution or incomplete translation.
We can illustrate the concept by imagining the planning of the development of a ‘workhorse’ paper stapler. The customer requirements ‘many sheets’ and ‘durable’ can be grouped to relate to the mechanical elements of the design requirements. They account for 54% of the total allocated importance scores [(9+4) div (6+9+4+3+2)]. A proportional 60% (6 in 10) of the design requirements are in relationship. The customer does not care much about the stapler’s colour, but blue is just about the most commonly purchased. ‘Colour blue’ is therefore given a low importance that represents just 8% of the total allocated importance scores. A proportional 10% (1 in 10) of the design requirements are in relationship. This example of a workhorse stapler represents what we would call a balanced translation.
Let’s now imagine that our next project is to develop a stabler that will form part of a decorative set of office tools. The customer segment is motivated primarily by the stapler’s appearance and how it blends with other items on an office desk, much more so than by its functional performance. The product must of course be able to staple, but it will be used infrequently and only for a few sheets of paper at the time. The left-hand chart below shows what would happen if we straightforwardly reused the relationship matrix from our ‘workhorse’ project. The output priorities for developing the mechanical design aspects add up to 170, which is more than twice the development priority for colouring (81). Common sense tells that our development team will now risk focusing its resources in the wrong place.
To overcome the problem, we combine and expand the design requirements until a ‘balance’ of proportionality is established. We group the mechanical design requirements into their higher-level headings, reducing their count from 6 to 3, to achieve a better proportionality between 23% and 30%. We expand the 1 colouring requirement into 4 lower-level characteristics, to achieve proportionality between 43% and 40%. The output priorities now correctly tells the development team where to focus their resources.
From experience, I have found that the principle of a balanced translation also applies to design processes that do not use the HoQ. I recall in the past drafting a 22 page design requirements specification for a complex electro-mechanical device. It was a collaborative process, in which the software engineers probably were the most vocal; or maybe I let them have a greater say because software had been a success factor in our existing product at the time. The 22 pages ended up featuring 12 pages of software requirements, 3 on mechanical design, 1 on pneumatics, 1 on user documentation and 1 on the packaging system; plus some pages of introduction, standards and project budget effects.
It should have been unsurprising to me that the project subsequently became overly focused on software development. Having used most our resources on improving our software, we ran out of time for improving the pneumatic design. Whereas the software in our old product was already successful in the market, the pneumatic design had a consumption issue that detracted from sales. The new product launch was critically timed for an international trade fair. In fear of running out of time, we were forced to reuse the old pneumatic design. Root problem: beginner’s error; I had produced an unbalanced requirements specification. It took hindsight for me to draw the parallel to the balanced translation lessons that I had learned in my QFD classes some years earlier.
Since this valuable learning experience, I have maintained a simple rule of making sure that the page count for a design aspect in a requirement specification must be proportional to its customer and commercial importance. Using a translation table and the HoQ can help assure this.
 Jussel, R., Atherton, M., Discussions during student seminar (unpublished), London South Bank University, March 1999. Rudolf Jussel, a fellow student at the time, had for purpose of sensitivity testing ended up completely inverting the input scores in our many-to-many relationships matrix and discovered that it only made a modest difference to the output scores. The ‘Jussel effect’ was unhelpful in validating our translation and we felt a need for an additional assurance. Our lecturer Prof Mark Atherton suggested the effect would diminish when proportionality is established. Although we never actually completed the science of proving the principle, our quick testing suggested he was right. It is common sense really.