Introduction
This post explains how Quality Function Deployment (QFD) could be used in a software company. QFD makes (some) sense for improving existing products, but not for new products, unless that new product is a copy of a competitor’s product. For this thread it is assumed that the goal is to improve an existing product.
For this example, imagine we work for a software company called Gaggle dot Com, and one of our products is an online email service called GaggleMail, which is completely not a copy of Google’s Gmail. In this post the Quality Function Deployment (QFD) method is applied to GaggleMail to improve its quality and increase customer satisfaction.
The Problem with QFD’s Math
Goetsch & Davis state “The math used to establish priorities lacks the precision necessary for a Six Sigma company” (p. 289). A “Six Sigma company” is not defined, nor is the actual meanings of the calculations involved in QFD. Take for example the value engineering equation (Goetsch & Davis, p. 290):
V = F/CWhere V represents value, F is function, and C is cost. What exactly are the units on these three variables, and how exactly are they measured? The purpose of this, along with the other calculations in QFD, is to give the appearance of quantitative understanding, and would be immediately rejected by the technical employees involved as being nothing but smoke and mirrors.
This post takes a different approach, using popularity for ranking the desired features of a software product, which is similar to the approach taken in Wong et al, (2023). This method may be incorrect, but at least technically minded people can remain engaged.
Step 1: Developing the Set of Customer Needs
Because there are so many parts to an online email service, it is decided that the focus will be on improving the user interface (UI) of GaggleMail.
After the scope is determined, the next step is to choose a cross-functional QFD team with members from development, customer support, graphic design, marketing, sales, and other relevant departments. All the team members should be somehow invested in the product under review. This is a problem at large software companies like Gaggle dot Com – there can be so many products that some employees do not use them all.
This team would prepare an online questionnaire, which can include initial guesses from the team about what the users want or need, along with free-form input for unanticipated needs. Team members who work in customer support will provide the most valuable input. For each of the initial guesses, we wish to determine two pieces of information: importance of improving the feature for the customer, and customer satisfaction with the existing feature.
The number of users to which this questionnaire is sent depends on the total size of the user base: if there are hundreds of thousands of GaggleMail users, then there would be too many responses to analyze. It would make sense to choose the users carefully. The users should be what are called “super users” – users that use GaggleMail heavily and are enthusiastic about the product. A second, separate, qualification to receive the questionnaire is that the recipient will not pass information on to competitors, and that they do not enter misleading information that would degrade the quality of the product. This type of security is hard to control except (maybe) in an in-person focus group.
The responses to the questionnaire represent the voice of the customer (VOC).
The QFD team will then sort and prioritize the responses to the questionnaire, including user input that doesn’t fit into the predefined questions. The responses can be written onto three-by-five cards and then arranged into an affinity diagram (Goetsch & Davis, p. 291) or into a tree diagram. An affinity diagram would be best, as the three-by-five cards can either be physically grouped or tallies can be written on them to record the number of people who are interested in a feature. This can then be translated into a table listing the customer needs (WHATs) and the corresponding importance for each need, rated on a 1 to 5 scale – where the numbers (ranks) come from the popularity of the requests for improvements.
Since the UI of GaggleMail is the thing under consideration, requests for changes to non-UI features (like over-abundance of spam in the In Box and valid emails in the Spam folder) can be ignored. This information should not be thrown away, but instead should be saved for non-UI improvements.
Step 2: Planning the Improvement Strategy
The second step is to compare our product against the competition. This can be done by a focus group or by sending a questionnaire to users of a competing product, using the same customer needs matrix from stage 1. This should be done for two prime competitors (Goetsch & Davis, p. 293).
The competitors’ customer satisfaction (CS) on each feature is again ranked 1 to 5.
This information is entered into the Planning Matrix: the first column should be the CS rating of our own product, and the second and third columns are for the CS ratings for the two competitors.
The company should then decide what should be the desired ranking (called level of improvement on p. 293 of Goetsch & Davis) for each customer need. There isn’t an objective way of determining this, but several factors must be considered: the time and money required to implement this feature, how valuable it is to the customer, and the CS rankings of the two competitors for the same feature. These rankings are entered into the Planning Matrix in the fourth column, called “Our Planned CS Rating.”
Step 3: Selecting the Technical Requirements
This step can be called creating the "voice of the company" (Goetsch & Davis, p. 295). In it, technical requirements are generated from the VOC findings. These requirements are descriptions of HOW to implement the desired changes to GaggleMail.
Step 4: Evaluating Interrelationships Between WHATs and HOWs
At this step, the relationships between the customer needs (step 1) and the technical requirements (from step 3) are made. The interrelationships between the two are placed into a matrix (Goetsch & Davis, p. 297), ranked 0 of 5, where 0 means that there is no relationship between a particular customer need and a particular technical requirement, and a 5 means that there is a direct relationship between the need and the requirement.
Step 5: Evaluating the Correlation Between the HOWs
The fifth step involves the creation of the Correlation Matrix that indicates the relationship between each pair of technical requirements. These relationships can be classified into being supporting, impeding, or no correlation. (Goetsch & Davis, p. 298). A Correlation Matrix would be useful if the changes involve multiple teams (in the text’s example this would be the authors, graphic designers, book binders, etc.). In the context of a software company like Gaggle.com, these correlations would be better understood if a dependency graph were used. Using such a graph, the dependency between each task would be obvious, tasks that can be done in parallel can be identified, critical paths can be determined, and so on (Tannenbaum, p. 274-309).
Step 6: Setting the Design Targets
In this last stage, targets for improvement (design targets) are specified. As in earlier steps, none of the calculations in this step (Goetsch & Davis, p. 298-303) make any sense.
Conclusion
Now, after all this is done, work can (finally) proceed on making the desired changes. In a company with minimal bureaucracy, development can proceed following the completion of step 1 and step 2, saving weeks or months in a highly competitive industry.
As mentioned in the introduction, QFD would work best for improving existing products. However, there are some situations that are not addressed in Goetsch & Davis.
First, there is no explanation of how to manage cases of conflicting VOC needs (Xiao & Wang, 2024). For example, suppose some customers want the text in Gaggle Mail to be larger, others want it to be smaller, and some customers want the text to be visible to those who are color blind. In a real software company, the developers and graphic designers would devise a solution that allows all customers to be happy.
A second missing aspect, at least in Goetsch & Davis, is the situation where a competitor has a feature that is not in Gaggle Mail. It could be addressed in the questionnaire designed in Step 1, but what if it goes unnoticed?
Finally, the success of the improvements to Gaggle Mail are not considered in Goetsch & Davis. This is not unexpected since actual work only begins after the QFD analysis is complete. With Gaggle dot Com, or really any company, the changes would be evaluated by some of the people that determined the VOC in step 1. Without this, the QFD analysis as well as actual work on Gaggle Mail can result in what software engineers call “ready-fire-aim.”
References
Goetsch, D. L. & Davis, S. B. (2021). Quality management for organizational excellence: Introduction to total quality (9th ed.). Pearson.
Tannenbaum, P. (2007). Excursions in Modern Mathematics with Mini-Excursions (6th ed.). Pearson.
Wong, J. et al. (2023). New approach for quality function deployment based on social network analysis and interval 2-tuple Pythagorean fuzzy linguistic information. Computers and Industrial Engineering 183. https://doi.org/10.1016/j.cie.2023.109554
Xiao, J. & Wang, X. (2024). An optimization method for handling incomplete and conflicting opinions in quality function deployment based on consistency and consensus reaching process. Computers and Industrial Engineering 183. https://doi.org/10.1016/j.cie.2023.109779
No comments:
Post a Comment