Many years ago the Quality Control (QC) discipline was invented. Then came Quality Assurance (QA).
Their target is similar (even if their approach is different): reduction/elimination of quality-related problems, both in products and in services.
What the two disciplines have also in common is their path: they go from downstream up, from the finished product/service back to the production process (and even the design) searching for factors that contribute to problems.
Also the ISO QA approach goes in the same direction.
Also the traditional Quality-Kaizen (Continuous Quality Improvement) approach goes in the same direction.
Somehow, they pay attention also to the process that "designs" products or services.
Moreover, all the above disciplines (and others) focus mainly on existing products or services and their quality features.
What lacks in all the above disciplines, however, is a basic, essential question: "...but, does the client actually want/need/wish those quality features we are trying to assure and perfect by eliminating all evident and latent causes of related defectiveness?"
Quality Function Deployment is one Design Approach discipline that pays large attention to the above question and takes a radically different path: jumping from the upstream end (the "design" end) toward the client and moving from there downstream, up to the operational/production process.
Not only the path is different, but also the accent: from focusing on negative quality (quality that must be improved and assured - traditional accent) the attention shifts on positive quality (or "....doing the wanted things right to begin with, once and forever....").
Quality Function Deployment (QFD) is a core discipline in the development of new products and services. A modern definition/description of it - slightly different from the one given by Y. Akao, the QFD guru - sounds like:
Converting the Client's demands/requirements/expectations into "Quality Characteristics" of the new Product/Service - and developing a Design Quality (quality characteristics of the Design) for the finished Product/Service by systematically correlating the demands (from clients' side) and the characteristics (of the new product/service), starting with the quality of each functional component and extending the deployment to the quality of each part and process behind it.
And, parallel Deployment of all Quality Functions (enterprise's Functions) involved in the development of the Quality System associated with the new Product/Service.
With the aim of satisfying the Client and then translating the Client's demands/requirements/expectations into Design Targets and major QA points to be used throughout the production/processing stage.
The final target is to launch a new Product/Service right from day 1.
Let's translate the above into a practical course of action for the SME.
- It all starts by "listening to the voice of the customer".
The enterprise sets up a strategy in this regard, and a system for collecting, classifying and analysing clients' comments, complaints, etc. - and even verbatims (or blurred, vague sentences, probably meaningless, but possibly meaningful when listened to with the correct degree of attention....).
The clients' voice may express complaints (on negative quality of existing products services), to be translated into "requests" or "demands" for positive quality expected in a new product/service.
Clients may also express direct comments and demands about wanted products/services. In this second case the accent is already on positive quality.
The enterprise's "system" is organised in such a way that the overall "collection" process is methodical, regular, "dedicated" and executed by all persons "in touch" with clients, and not only by marketing/commercial people.
- The output of the system is a well classified and organised list of demanded qualities, or characteristics/features that a new product/service (or a modified existing one) should have.
The output is produced in team by key people, adopting a specific method (and lots of common sense and creativity....).
The demanded qualities (positive, wanted qualities) will fall under 3 main classes:
- Explicit Qualities. Features/characteristics explicitly and clearly requested by customers.
Implied Qualities. Features/characteristics not explicitly requested, simply because "given for granted".
In conclusion, when defining the Positive Quality of a new Product/Service, the enterprise will come up with a list of features/characteristics either demanded by clients, or wanted by them, or expected by them, or part of their dreams......... (generally called Demanded Qualities).
- Attractive (desirable) Qualities. "Unspoken", "latent" quality features/characteristics not expressed (possibly not even thought of) by Clients, but "potentially appealing" to them (under the light of more explicit requests or demands).
To these class of Positive Quality belong those features/characteristics of a new Product/Service that the enterprise may decide to propose and offer to clients (so that for them it will be a pleasant "discovery", a "cherry on the cake".....).
It is important to note that a Demanded Quality is simply a description of a feature that the new Product/Service should have (such as, in the case of an ordinary match, ".....doesn't break...." - or in the case of making a bank deposit, ".....should be done without queuing....").
- The identified Demanded Qualities for the new Product/Service "influence" a number of Quality Elements of the new Product/Service.
A Quality Element is a measurable or un-measurable component of the Product/Service Quality, and may be composed by a number of sub-elements or features.
For instance the Quality Element "sturdiness" of a match stick is an un-measurable component of the match Quality, but it may be broken down into "hardness" (of the wooden stick - measurable), "cross-section" (of the wooden stick - measurable), etc.
Likewise, a Quality Element "rapidity" (of a queue) may be measured through its feature "speed" or "duration of the waiting time".
Practically, all "technical quality domains" of the new Product/Service are somehow influenced by the Demanded Qualities:
This requires that several Quality Functions of the enterprise be involved in the QFD exercise
and be part of the QFD Team.
The net result is the simultaneous deployment of enterprise's key human resources (Organisational Domain) to perform the QFD task of correlating Demanded Qualities with the new Product/Service Quality Elements (Technical Domain). In a traditional QFD approach, the target is new Product/Service Quality in a broad sense: the approach reflects technology, reliability, aesthetics, cost, etc. considerations.
While the traditional QFD approach is sequential (for instance: quality deployment --> technology deployment --> cost deployment --> reliability deployment --> etc.), the modern approach is rather parallel and integrated (Concurrent Engineering style).
- The main QFD tool used in a traditional QFD exercise is the Quality Chart.
This is a thinking tool, by which the Demanded Qualities are put in mathematical correlation with the Product/Service Quality Elements, sub-Elements, Characteristics "influenced" by them.
A correlation may be strong, significant or weak. This can be expressed mathematically.
Each Product/Service Quality Characteristic influenced by the various Demanded Qualities is then given some "relevance" and "weight" parameter representative of the "importance" of each Characteristic. This is done taking into consideration a comprehensive scenario: competition, marketing factors, cost impact, etc.
- The strategic power of the QFD approach now starts showing.
The technical/marketing objectives for the new, proposed Product/ /Service are set taking into consideration the broader panorama of the situation, which is: quantified (not just feelings or opinion) - and deployed in a simple but rather explicative chart.
The Quality Chart construction method should be personalised and appropriate. It would be foolish, especially in the Small Enterprise, to carry out a QFD exercise "by the book". It should instead be simple without loosing effectiveness.
If the QFD team has some valid QFD experience - their judgement abilities are well equilibrated - the coefficients, formulas and parameters are well chosen - and, most of all, the necessary thinking is done - then the QFD approach may represent a conscious, guided process where the Clients' needs and expectations are gradually directed into generating a valid, new Product or Service having the wanted Quality Characteristics.
The QFD Team needs to do a lot of thinking, also in order to escape from "cold", mathematical data and figures. To assign the final "weight" to each Quality Characteristic, adjustment factors may have to be introduced.
The major benefit is in the "consciousness" that the QFD approach brings when tackling the development of a new Product/Service: nothing is casual or neglected - the Clients' voice is loud and clear - vague, un-measurable entities are converted into targets more and more defined and measurable as the process goes on - and if the "translation" work is carried out rationally, there will be less or no need of correction/modification of the new Product/Service after it is launched - the target being:
"product/service recognised valid and successful from day 1"
- Obviously, the QFD approach is not limited to identifying a number of Quality Characteristics "important" for the new Product/Service and to ranking them in order of priority (to satisfy not only clients' needs/expectations but also enterprise's positioning in the market, enterprise's image/reputation, etc.).
A comprehensive approach goes beyond, and considers the entire productive/operational process associated with the new Product/Service.
Today, the real value of QFD is in its simultaneous deployment with other Product/Service Development disciplines like Value Engineering (more »), FMEA (more »), etc. - see also Concurrent Engineering (more »).
BUT, Quality Function Deployment is always the "starting point".