There is often more than one way of addressing an input requirement. In order to attain competitiveness, it is important to identify and develop the one with most advantages over the others. The human mind in disposed to draw assumptions from past experience and to copy the behaviour of others. In some way, we are thereby naturally predisposed to want and produce stereotypical solutions. The translation table is a technique for translating a set of input requirements into a set of output requirements. It compels the development team to think laterally and record how else an input requirement can possibly be met. When using the tool, the team will consider other human-made or natural systems where similar kinds of needs are addressed. They will ask themselves: “What are the functions, features or activity that satisfies the input requirement”? and they will document the answers in a language that is as solution neutral as possible. We try to stimulate lateral thinking by considering an abstract or nature analogy. We could also try to consider what solution they would have invented in a science fiction movie. It may not be possible to recreate such an abstract or fictional solution, but the exercise will help to dislodge and widen traditional thinking. Lastly, we should also consider if there are any relevant obligatory or standards requirements that we must adopt.
The translation table will eventually present sets of alternative information in a way that stimulates new thinking across them, as well as presenting it for evaluation and selection. What we finally select as the new output requirements should match the business plan ambition and ‘difficulty budget’ for our planning phase (see the House of Quality in QFD). We must be as creatively inventive or as conventionally conservative as the market and business conditions demand. However, just looking at the wider options helps opening up the team’s collective mind and makes it more receptive to lateral new thinking. Looking across and down the table of example solutions, the QFD team can realise a duality from combining related functions into one multi-functional output requirement. Finally, we must also assure that we obtain a balanced translation – i.e. that the quantity numbers of output requirements are proportional to the importance rating of the input requirement they relate to.
The selected output requirement (right-hand column) can be either:
- New-found way of fulfilling the input requirement, or
- Combining an existing solution with a new aspect, or
- Keeping or strengthening an existing solution.
Let us consider the portion of an example translation table shown above. There is no product standard for “not rusting” in this case; but the customer requirement for “colour red” relates to a product safety standard that says the red colour is classed as a warning indicator and must therefore be clearly distinguishable from the lesser alert level indicated by a yellow colour. What we finally select as design requirements should match the business plan ambition. Trying completely new ideas can be risky. Developing something novel in rust protection, such as using plant-based biological antioxidants to inhibit the galvanic corrosion process, could be too far-stretched for our particular ‘difficulty budget’. However, just looking at such far-fetched option helps opening up the team’s collective mind and makes it more receptive to lateral new thinking. In this scenario, it turns out that ‘borrowing’ part of the solution from state-of-the-art aircraft design is a more realistic solution. Looking across and down at the example solutions, the QFD team can realise that aluminium (not aircraft alloy grade) is easier to work and that anodising has a dual function of providing both colouring and protection. The selected solution remains cost competitive and it will be easier to control in manufacturing.
You can download QFD and HoQ resources here.