1 1 Lecture 9 Quality Function Deployment (QFD) a method for structured product planning & development Responding to the voice of the customer

2 2 2 Grading criteria for Objectives Trees Well-organized presentation that is easy to read and not jumbled Content provides evidence of team collaboration and substantial thought There are many different objectives listed, more than just the few discussed in class The objectives clearly define all elements of the opportunity statement with wording that is concise and accurate Objectives are grouped together in a fashion that makes sense and with a hierarchy that goes from top level to component level Objectives grouped under a heading clearly belong there Examining the objectives tree provides a concise description and summary of the design objectives

3 3 3 QFD is built around a “House of Quality”

4 4 Quality Function Deployment definitions

5 5 5 Quality Function Deployment (QFD is part of a “Six Sigma Process”) The beginning of design The objectives We need to see how our proposed design solutions address customer expectations

6 6 6 QFD is structured to have 6 design steps 1)Identify the customer(s), users, stakeholders … 2)List customer/client requirements (needs & wants) Things like “Works well,” “lasts a long time,” “looks good,” “incorporates the latest technology” Most of these appear in the objectives tree Include functional requirements (change orbit), spatial constraints (operate in MEO), appearance, time requirements (responsive), cost (affordable), manufacturing and assembly, performance, product standards, codes of practice (meets ISO 3102), safety, environmental 3)Prioritize customer requirements – use pairwise comparisons Question - To whom is the requirement important? Question - What measurement tells us if our solutions satisfy requirements? Which requirements are MUSTS? Which are NICE?

7 7 7 QDD overview continued 4)Benchmark the Competition What already exists that is sort of like our design objective? Compare these existing products with our requirements – is there a feature we can use or copy? 5)Translate customer requirements/needs into measurable engineering requirements (called design specifications) 6)Set engineering targets – like “time=12 hours” or “cost less than $250M” You may specify range of values, but this is dangerous You may specify that a value should be “as large” or “as small as possible” like weight should be less than 5 lbs. Most requirements will be covered by the objectives tree, but some may be added

8 8 8 QFD output from one step becomes input for the next

9 9 9 QFD is structured to go from beginning to the end how long you use it is up to you Figure courtesy of Thiokol

10 Systems based QFD elements and value has to be determined by the team Typical activities Customer surveys Brainstorming Affinity exercises Objectives tree diagrams House of Quality Benchmarking – what do our competitors do? What is it used for? Prioritizing activities Improving quality and reliability Engineering breakthrough product development Improving communication Reducing time to market Benefits Focused on customer requirements Uses competitive information Prioritizes resources Identifies important issues and problems Reduced implementation time Bases decisions on consensus Documents activities and decisions – a living document

11 Matrix selection methods Matrix displays always show data in two dimensions ABCD

12 Modular space example Responsive Modular Collect data Refuelable Repairable Reliable Deployable in segments Client voice Tech response? Engineering characteristics? Your product description at a high level-Compactly packed, Easily deployable, loads on small launch vehicles launched to MEO, components easily joined together, quickly updated, maneuvering, controlled thermal environment, limited system complexity, power generation, storage

13 Technical responses at a high level - the great words people will say about your engineering design Compactly packaged Fits into shroud with little wasted volume Attaches easily to rocket assembly Minimal number of separate pieces Components easily deployable & joined Fittings? Latches? Interfaces simple to use Easy deployment Connectors for power and cooling are easily used Compactly packaged, Easily deployable, loads on small launch vehicles launched to MEO, components easily joined together, quickly updated, maneuvering, controlled thermal environment, limited system complexity, power generation, storage

14 Comments HoQ exercises bring out questions and opinions. A neutral facilitator is useful (if you could hire one then you’d do it). Sometimes voting first speeds up the process When there is a diversity of votes, ask for clarification and opinion. Sometimes the row or column heading need to be modified (“maximize safety” becomes “safety”) Sometimes a technical response (column) is missing (“launch vehicle size” or something similar is missing and was consistently being discussed under “responsive launch”) At the end you have new ideas, better ideas and know where people stand and why they stand there.

15 Airplane example Operate out of small airports Contain fewer than 19 passengers Operate in commuter markets Loading and unloading of passengers in small airports Client wishes Tech response, engineering characteristics Short take-off capability, easy ingress or egress, cabin comfort

16 Not too much and not too little Objectives and design functions are important to know, but… Objectives are statements of what the design must achieve or do, not how well it must do it We need performance specifications to set limits Performance specifications provide boundaries to the solution space Specifications define product performance, not the product itself Specifications can limit our design space or direct team efforts If specs are too broad then there is not guidance about where to go If specs are too narrow or small we may eliminate good design solutions

17 Start the process by …. Look at your objectives tree at the top level systems objectives List the high level objectives and: Rank order the objectives using pair-wise comparison or another method of your choice Rankings will be used for House of Quality weighting factors Think about the engineering problem and HOW we will satisfy our objectives by creating a design The HOW’s are technical objectives or “Engineering characteristics” – called EC’s EC’s should affect the customer’s perceptions of your product this is one criterion to decide if you have the right engineering characteristics Name product features that you use every day impress you? Which don’t impress you?

18 Customer needs are translated into tech requirements with numbers Either 1) Ranked New, Unique & Difficult (NUD) Customer Needs or 2) customer attributes (Rows) Systems Level Technical (engineering/system level) requirements (EC columns) Relationships between NUD customer needs and Systems Level Tech requirements (A matrix) EC/Tech requirements are product specific How do we translate a “need” into a measurable technical requirement? Example – “time-responsive means provide within 24 hours” At the systems level “HOW” doesn’t mean “use a hydrazine rocket” NUD customer needs

19 Requirements comments “HOW” is not expressed in terms of a design concept – “provide a sun-shield” is not a good choice for an EC Functional analysis is important EC’s must convey the right functional and feature performance information – “package within (or be deployed from) restricted launcher volume” – leads to prescription of volumetric size goals Don’t have a requirement that excludes – unnecessarily – a design concept in the future Systems level requirements should not state solutions A correct requirement should be able to be fulfilled by several different design features or components Tech requirements take time – not just a few minutes of effort If you are not arguing then you are not doing it right

20 Requirements example Poor requirement Car acoustic damping materials must be able to maintain internal acoustic noise level at or below 75 dBA This is too “prescriptive” – it is not a system level requirement, it is actually a component requirement Better requirement Maintain internal car acoustic noise level below 75dBA under any set of driving environment conditions This is “descriptive” and suggests a measurement and a measurable objective independent of the design concept – it allows more than acoustic damping materials as a solution

21 Establish relationship between VOC/NUD needs and each requirement Ranked New, Unique & Difficult (NUD) Customer Needs (Rows) EC/Technical (engineering/system level) requirements (EC columns) Relationships between NUD customer needs and Systems Level Tech requirements (A matrix) XX XX XXX X XX X XX Which tech requirements affect the VOC/NUD’s? Put an X in the cell

22 Quantify the strength of relationship between VOV/NUD needs and each X’ed requirement Ranked New, Unique & Difficult (NUD) Customer Needs (Rows) Technical (engineering/system level) requirements (EC columns) Relationships between NUD customer needs and Systems Level Tech requirements (A matrix) How strong is the relationship between each requirement and each VOC/NUD? Put a 0, 1, 3, 9 in the cell 9=strong relationship between VOC and requirement – highly dependent – if you satisfy requirement you’ll make the customer very happy

23 Quantify the strength of relationship between VOV/NUD needs and each X’ed requirement Ranked New, Unique & Difficult (NUD) Customer Needs (Rows) Technical (engineering/system level) requirements (EC columns) =strong relationship between VOC need and requirement – highly dependent – if you satisfy or include this requirement you’ll make the customer very happy 3=moderate relationship between customer need and design requirement 1=weak relationship between need and requirement 0=no relationship at all EXAMPLE - VOC time-responsive “need” and requirement to launch & deploy within 12 hours

24 How important is each tech requirement? Ranked New, Unique & Difficult (NUD) Customer Needs (Rows) Technical (engineering/system level) requirements (EC columns) We can simply sum or do a weighted sum – more later

25 Which requirements are important and likely to drive the system design? All tech requirements must be fulfilled but a few will stand out Requirements that are difficult to fulfill and are critical to customer satisfaction must be given high priority and team attention Some requirements are contradictory Low cost vs. responsive This require a trade Find where conflicts exist Find where synergies exist Make sure that you haven’t accidentally created a conflict

26 Identifying conflicts and support among Tech requirements Ranked New, Unique & Difficult (NUD) VOC Systems Level Technical EC requirements Relationships between NUD customer needs and Systems Level Tech requirements Technical correlation matrix (the roof) The tech correlation matrix (roof) is a set of matrix elements arranged in a triangular fashion

27 Relationships between tech elements How strong? Tech 1Tech 2Tech 3 + _ 0 The roof identifies synergies and conflicts Use + or – 1,3,9 system

28 Do you have competitors? Quantify and document the capability of competitors to currently fulfill each system level VOC/NUD requirement Ranked New, Unique & Difficult (NUD) VOC Systems Level Technical EC requirements Relationships between NUD customer needs and Systems Level Tech requirements Technical correlation matrix (the roof) Planning with customer ranking

29 Planning and customer ranking Benchmarking Find similar designs or designs that compete with yours Look at VOC features Place yourself in the position of the customer Rank how these current designs fulfill requirements 1=highest fulfillment 5=lowest fulfillment Planning matrix ranking Design 1 Design 2 Design 3 Design