Quality Function Deployment

Quality Function Deployment – QFD

Author:

Tony Jacowski

Quality Function Deployment provides the essential link between customer requirements and the available technology required for developing optimized products and services that best suit customer needs and expectations. By using Quality Function Deployment, businesses can now easily make use of existing technology – or even use a completely new technology – for designing and developing products or services without worrying about the negative fallout that is commonly associated with undertaking technology development and product development initiatives, both at the same time.

Quality Function Deployment has made it easier for businesses to make the benefits of newer technology available to their customers through improvements made in the existing product or service.

Importance Of Quality Function Deployment

Quality Function Deployment is important because it offers multiple benefits such as better conceptualization and implementation, increased production efficiency, and increased customer satisfaction. At the conceptualization stage, the main worry of product designers is whether the available technology can be successfully used or not for satisfying customer needs and expectations. It may look good on paper, but problems may start to surface when actual production starts if proper analysis is not done at the conceptualization stage regarding the compatibility of the available technology with the suggested manufacturing processes.

Quality Function Deployment helps because it effectively maps the complete production cycle, indicating exactly when and where to use the available technology to get the desired results. Quality Function Deployment also points out possible problems that may arise in the near future, which in turn helps managers to devise innovative solutions or backup plans well in advance. This not only helps businesses to satisfy customer needs and expectations through optimized products or services, but also helps them to reduce costs though increased production efficiency.

When To Use Quality Function Deployment

Quality Function Deployment is most effective when it is implemented in the early stages of the design phase. The early stages of the design phase is the time when new features are being incorporated based on customer requirements, making it necessary to implement QFD so as to resolve any critical issues before they transform into major problems and become a threat to the project itself. Implementing Quality Function Deployment after the design phase may not help much, because by then it will be very difficult and costly for the business to revert back to another product design if it has been found that the existing product design does not confirm to customer needs and expectations due to faults in the conceptualization stage.

To derive maximum benefits from Quality Function Deployment, businesses should make it a point to undertake proper analysis of all the related aspects and make the information available to all employees associated with the project. For ensuring the success of Quality Function Deployment initiatives, it is also necessary for businesses to manage the operations through a multidisciplinary team, comprising of members from all functional departments within the organization. This is necessary because no matter how good a plan is, there will always be the need for expert advice and suggestions for solving day-to-day problems that are likely to occur during the course of the project implementation.

Article Source: http://www.articlesbase.com/management-articles/quality-function-deployment-qfd-289883.html

About the Author

Tony Jacowski is a quality analyst for The MBA Journal. Aveta Solution\’s Six Sigma Online offers online six sigma training and certification classes for lean six sigma, black belts, green belts, and yellow belts.

Project Management Mistakes with Quality Function Deployment

When it comes to projects someone once said:” If everything is going exactly as planned, something somewhere is going massively wrong.” And it is true, although project managers have difficulty saying it loud, in the everyday workflow of the project, mistakes do happen. But the biggest question is whether these mistakes will be something which team members and project manager could learn from and never repeat or they will be constantly diminished and misjudged. The constant battle between customers’ requirements and time and resources is what makes the project complex and repetitive process In such an environment mistakes are every day routine. But what are the crucial areas where project managers can always try to improve and decrease possible errors?

Here are several proposals:

1. Communication – It could never be too much. In order to know every detail, task or a certain problem, responsibility of project manager is to make sure that everyone involved is constantly updated on what is happening, what their role is, the timeframes and the dependencies. What you think is a vital indication of approaching disaster might appear to your project team as a minor glitch in the system. What you consider to be a major alteration to the customer’s original specification might seem to the designer to be a simple modification. To ensure that you receive the necessary information, one solution is to inform all project staff in advance of what information your require, how often, and in what format.
2. Set goals and expectations – Each stakeholder has a different expectation and picture for the project. In order not to miss customers’ requirements you need to define details, time, and resources and budget properly so each side could get what is expected. And of course, to be sure that your team could deliver what was promised. One of the project goals might be to “increase the overall satisfaction level of clients calling the company helpdesk with support needs“. For example, General Dynamics ensures its PM’s are familiar with the company’s needs by holding weekly meetings to discuss and debate new and ongoing projects, increasing the odds for selecting the best solution, and keeping projects on schedule (Heekens 2002). Banco Itamarati, a privately held Brazilian bank, attributes the success of its IT project to clear vision and documented specific objectives. The company produced an annual net profit growth of 51% and moved from 47the to 15th place in the Brazilian banking industry.
3. Be flexible, but learn to say no – The list of stakeholders whishes could be endless, but what is really applicable and feasible only you and your team know. Yes you need to be flexible and accept changes in the project but never accept something that will carry away the project into over budget zone and having to deal with over allocated resources, time and efforts.
4. Consider Murphy’s Law-Never neglect risk management. Too many project managers treat risk management as optional item rather than a need-to-do recurring event in the planning and controlling phases. Risks need to be brainstormed, properly estimated and calculated, in order not to bring any surprises to the project.
5. Start before you hear the whistle- Often project managers start the project, without having contract signed and terms agreed. This could be a bad idea which may lead to profit loose or dissatisfied customer. You want to build the relationship and the client wants results quickly, so you go against your policy and act. But sometimes customer may change its opinion and leave you in the middle of nowhere. That is why the project manager must document and at least get sign-off on projects features and needs from the client side. That’s some protection, which can be skipped if you have built a long term relationship with your client.
6. Nothing without the Right Resources and the Right Skills – Suitable project staffing is critical, yet inadequately allocated resources is still one of the top common project management mistakes. Not having the right people with the right skills doing the right things on a project, can kill it. A survey conducted by IT Cortex, on “Reasons for Project Impaired Factors” conducted among 365 IT managers from companies of various size and in various economic sectors showed that lack of resources is one of the main reasons for project failure followed by lack of executive support. It is interesting to point out that lack of IT management and technology illiteracy was at the bottom of the list, showing soft skills super ceding technical skills. The best plan or project ever could be ruined with the lack of skills. Therefore project managers should carefully review staff abilities and assignments.
7. Unreasonable Deadlines – Setting deadlines that could not be achieved is a major problem. In order to impress and get project approval from stakeholders project managers often overestimate the team capabilities. Major compromise between budget and time must be made, so either on time delivery of the project or staying within the budget could be central goal. The project manager must develop accurate and realistic time estimates for the project, and use these to convince the sponsor that the timelines can’t be achieved.
8. Losing touch with WBS – Work break down structure is the essential of the project, which provides confirmed scope, inclusive of phases and deliverables. It is useful for creating the bigger picture of project requirements, and then for using it as a reference throughout. WBS should be properly shaped in the scoping phase, completed in the planning phase, and used as the key control document throughout the rest of the project life cycle.
9. Always stay customer focused - When deeply involved within the project, team members, lose sense of customer requirements. The most relevant rule to follow here is that “The customer is always right even when he is not”. The team unique goal should be to attract and retain the customer in the base and make him satisfy. One popular technique is called Quality Function Deployment (QFD). Quality Function Deployment is a systematic procedure that places intense focus on customer needs and translates those needs into detailed requirements. It is one of the best ways to ensure that project requirements are aligned to customer needs. Another technique is called a CTQ (Critical to Quality) Tree. A CTQ tree is used to decompose broad customer requirements into more easily quantified requirements.
10. Always use a Project Management Tool- In today’s dynamic environment the project management tool is a must for every project. One of the biggest mistakes a company can make is using a new technology on a highly visible and large project. Having the right tool is really helpful to keep projects on track, update stakeholders and manage multiple projects at the same time.It makes your work a lot easier and your project more flexible. For example, the task update feature of Seavus Project Viewer could save a lot of time, lost documentation and track the progress of the project immediately.

Recent study of the Faculty of Computer Science & Information Technology, University of Malaya showed the critical factor of project success and failure.  Between the top 10 reasons for failure were: the lack of user input, unclear objectives, project and user focus and constant change of requirements. These pretty much correspond to the proposed errors and fields for progress.

As a conclusion we can say that there are many other mistakes which we can meet on the road of successful project management process, but this field is constantly changing and developing so there will always be place for improvement and learning. Maybe the biggest mistake of all is if you never learn from your mistakes in order to prevent bigger ones. Project managers should take the time and make the commitment to learn from experience, and the learning curves will start to stack up on each other, processes will improve and productivity will increase.

Quality Function Deployment In Use Example

This article analyzes a company’s existing Software System and proposes a concept to develop a better Software System.

I worked for a company where my job responsibility was to develop a new software system based on an existing software system. Based on my experience, I have discussed some methodology, procedures and examined some concept to develop a better software system. I am open to constructive suggestions and useful advice regarding the concept that I have discussed in this article.

1. Foundation:

The company has an existing Sales and Distribution System which is being used by the department. When the system was developed, there was not any proper documentation and Software Engineering process was not followed properly. And as a result design was poor and the solution is slow. The data model was not so effective. And the developers who developed the existing system are out of company and as a result the maintenance is difficult since lack of documents. Along with the design problems, the solution is developed in old technologies and technique like heavy weight data structure was used in the application layer. The information domain that was designed by the former developers do not meets the acceptance criteria of the users. As a result, many tables in the database are out of data. A user of the system is asking for a new user friendly Sales and Distribution System which they can use without any prior training. From the experience of the existing system, the developers have decided to set a development goal for their future Sales Operation.

2. Development Goal:

The goal is to develop a brand new, reliable, maintainable, reusable cost effective Sales and Distribution module to optimize the sales process where the basis will be analyzing the existing sales & Distribution module. The development goal is to emphasize in the Requirement elicitation, Analysis, Model, Specification and validation.

3. Development Objectives:

The objectives of the proposed software development are:

1. To make the sales process fast and efficient by developing a Model Sales and Distribution module where the system will meet all the features and functionality being performed in the company’s Sales and Distribution process.
2. To add new features to make the process more effective.
3. To make extreme User involvement in the Development Life Cycle.
4. To ensure quality control. Quality Function Deployment (QFD) should be used to elicit requirements. “House of Quality” and “Voice of Customer” methods should be established.
5. To ensure that the Analyst, Developer and User s meet regularly.
6. To track the requirements properly.
7. To emphasize the Security requirements.
8. To document functionality, Information and behavior of the system prior to development.
9. To make the Data Architecture faster at data processing.
10. To make the User Interface simpler by making the decomposition of the existing Interfaces means by breaking the functionality of one Interface into multiple ones where Navigation between interfaces must be user friendly by using Evolutionary Prototype.
11. To use latest technologies and methods.

4. Concept to fulfill the Development Objectives:

If we consider the Sales and Distribution System as a product, we need to follow the concept of Product Engineering. Here the goal of Product Engineering will be to develop a working product that will meet all the Customer needs and the customer’s desire will be focused in the Product. The world view of the Product Engineering will be achieved by Requirement Engineering. The world view means the capability of the working Product. The System Engineer will do the System Requirement Engineering and will develop the System Requirement Specification. In Product Engineering there are four System Components. They are Software, Hardware, Data and People. When the System Requirement Specification is made, the job of the System Engineer is to assign necessary function and behavior to the specific System Component. When the allocation is finished, then the individual Component Engineering starts. So, Software Engineering will be done for the System Component ‘Software’. In this article we will focus on the Concepts of Requirement Eliciting, Analysis, Model, Specification and validation which is the elements of Software Requirement Engineering in the Software Engineering Discipline.

In the case of my company, the System Engineering has been done but not properly documented at the time of previous System development. Based on that System role has been allocated to the System Components. My discussion topic is in the role of Software and the concept that I will focus is in the Software Requirement Engineering phase of the Software Engineering. Here I will say what concept should be followed to develop an effective Software Requirement Specification.

4.1. Requirement Elicitation:

Before the Requirements can be analyzed, modeled and specified, the requirements should be gathered by the elicitation process. In the Requirement Elicitation step, we should follow a plan. Since there is an existing system working, we should analyze the existing system. So, one source of requirements can be the existing system’s Software User Interface. Existing System’s Informational domain by examining the Database can be a source of requirements. We should also gather requirements by the behavior of the existing system. We should find out the security requirements or constrains by reviewing the existing system. So, from the existing system we can get a rough idea on the requirements and the developers and analysts can have a basic knowledge base on the System that is going to be built.

One thing we should keep in mind that the early the requirement problem is found, it is easier to fix. So we should find the requirement problems at the time of documenting in the Requirement Engineering Process. Since the existing System is the primary source of requirements, we should keep ourselves busy in finding the existing requirement problems.

Secondly, we should gather requirements from the business experts and users of the existing System. Firstly we should make a list of all Stakeholders of the Desired System. The main source of the stake holders are the Developers, Users and the Customer. Here the users are the end users of the System and the Customers are the management stuff who has asked for the Software for their department. We should make an extreme user involvement in the development process. We should go to the right person to gather requirements means the right stakeholders should be identified. In, the Requirement Eliciting meeting the Customers will say what they ‘want’ and what they ‘need’. From this point the developers will be confident that they are solving the right problem. Since the basic requirements are identified from the existing system, the negotiation should be to the refinement of the existing Requirements and the problems of the System. In the Requirement Elicitation Process no single user has the complete view of requirements rather they have own requirements in a particular situations. So, user involvement is necessary in the Elicitation Process. Effective Communication process should be established in the negotiation phase. It should be noted that User participation is the determinant of System Success.

Quality Function Deployment (QFD) is a formal technique used at the time of elicitation which helps to develop the specification. Researchers have found that this technique provides a better customer satisfaction. QFD aims to listen carefully the customer needs and provide a useful solution to the customer. According to Herzwurm [5] QFD “bridges a gap in the software development process to the customer. This is done using a systematic procedure for teamwork and the ability to prioritize all information concerning product development in a justified way”.

“House of Quality” is a tool, used in QFD links the “voice of customer” with the design decisions. This means the tools make a list of customer “what’s” in one column vertically and in the next column specifies the tasks how the customer what will be implemented. At the roof of “House of Quality” is the discussion in the meeting to assist feasibility and changes that need to be done in the specification document.

Let me discuss some tips which should follow in the Requirement Engineering process. They are that the requirements should be structured; the requirements should be testable, reusable requirements should be identified, source of the requirements should be maintained, along with functional requirements, all non functional requirements or the constraints should be identified.

4.2. Requirement Analysis, Modeling and Validation:

Requirement Analysis will provide the bridge between the System Level Engineering and the Software Design. This means Requirement Analysis will provide the detail “what” of the software that will be built. Software Engineer will design the software by getting information from Specification that the Requirement Engineer will provide at the time of Software Requirement Analysis. Roger Pressman states that,

“Requirements analysis provides the software designer with a representation of information, function, and behavior that can be translated to data, architectural, interface, and component-level designs.”

Once the Software Requirement Specification has been made at the time of Requirement Analysis, the Specification will be used to asses for quality when the Software is built.

In case of my Company, the elicited requirements should be analyzed at this stage. By examining the existing Informational domain and the new elicited information domain, we can get a picture of the functionality of the Software. All the observable data objects should be listed. We should find out the flow of the information or content of the data objects and the behavior of the System that is the processing that happens by external or internal events. All analysis methods are related by a set of operational principles [1]:

1. The information domain of a problem must be represented and understood.
2. The functions that the software is to perform must be defined.
3. The behavior of the software (as a consequence of external events) must be Represented.
4. The models that depict information, function, and behavior must be partitioned In a manner that uncovers detail in a layered (or hierarchical) fashion.
5. The analysis process should move from essential information toward implementation Detail.

At the beginning of the Analysis phase, the process starts at Step one by creating an analysis team where the team member’s skills are assessed, project environment is created. In the second step of the analysis phase is to determine the business requirements and find out the functional requirements. This step is done by techniques like JAD sessions, Interviewing, Storyboarding, Use case diagramming, Data flow diagramming, Prototyping; Walk through, Problem recognition, Structured English, Pseudo coding etc.

In the third step of the analysis process, we have to determine the process model. The techniques used are creating the Work flow diagram, Flow chat diagramming, Use case diagramming, Decision trees, Customer Events diagramming, Prototyping etc. The process model is developed at this stage. In the forth step Logical Data Model is developed. The techniques used are ER Diagramming, Data Normalization, and Denormalization etc.

In the fifth step of the Analysis process is to review the documents of the previous steps. All the derived requirements are assessed at this stage. One thing we have to remember that the requirements that are derived at this stage must be testable. That is we should specify the requirements in structured English like specifying “The system will perform …..” or “The User will be notified by the System ……” I mean that the functional requirements must be validated by the User by some Validation Criteria when the System is built.

At the end of fifth step is to document the Software Requirement Specification. In the document the functional Specification’s logic is expressed by pseudo code, structured English and object oriented logic. Let me give a list of contents that a model Software Requirement Specification will contain.

List of Contents and their Descriptions for Software Requirement Specification

1. Content Name: Goal and Objective

   Reference Document: Software Scope in the Planning Document

   Description: Something more than Scope is documented.

2. Content Name: Information Description

   Reference Document: Documents of Step 4

   Description: Information Content, Flow and Structure are documented.

3. Content Name: Functional Description

   Reference Document: Documents of Step2 and Step 3

   Description: A processing narrative is provided for each function, design constraints are stated and justified, performance characteristics are stated, and one or more diagrams are included to graphically represent the overall structure of the software and interplay among software functions and other system elements. Everything is documented.

4. Content Name: Behavioral Description

   Reference Document: Documents of Step 4

   Description: The operation of the software

   As a consequence of external events and internally generated control characteristics are documented.

5. Content Name: Validation Criteria

   Reference Document: Documents of Step 5

   Description: Validation Criteria must be documented for assessing Quality. Function, Performance and Constrains must be validated.

6. Content Name: Bibliography and Appendix

   Reference Document: Supporting Documents of all Steps

   Description: The bibliography Contains references to all documents that relate to the software. These include other Software engineering documentation, technical references, vendor literature, and standards.

5. Recommendations:

In some cases it is possible that operational principles can be applied using the Analysis process discussed above and build a Software Model and then move to the Design Phase of the Software Development Life Cycle using the Software Model’s Work product which is the Software Requirement Specification. Again in other situations it is possible to use QFD for requirement Elicitation, then operational analysis principles are applied and a model of software called Prototype is build for customer and developer assessment and then move to construction of the production Software.

In case of the Company of this article, they are using an existing Sales and Distribution System. They are using the System for five years but for the lacking of proper documentation in the Software Requirement Engineering, High Level Design, Low Level Design the Software is hard for maintenance. Since proper Software Engineering Process was not followed, results a poor design. But the software is running live and the department’s basic objective is fulfilled with performance lack. My recommendation is that, we can get all the basic and expected requirements from the existing System and find out the exciting requirements by Quality Function Deployment. Then apply the operational analysis principles and develop a software model called Prototyping and move to the design phase.

Quality Management Techniques

Quality management techniques are commonly referred to as TQM (total quality management). The core concepts of quality management are:

- Continuous process improvement
- Customer focus
- Defect prevention
- Universal responsibility
- Quality Function Deployment
Continuous process improvement takes place in incremental steps. It should not stop in any case. The first step in quality development is for employees to look at their work and effort in terms of being part of a continuous business process.

Continuous improvement is a persistent effort. To enhance the quality improvement process select an improvement project with a specific target. Selecting project with specific plan helps in improving the total quality management. After this assign a appropriate project team to improve it. Define the project steps using a flow chart, and define variability and problems in the project. Locate the root causes of the problems and recommend improvements, and implement. Measure the results and proceed to a final implementation. Then start the new project.

The continuous quality improvement process should be driven from the top management, but implemented from the core team member and other staff. The selection of improvement projects needs a pointed focus. The problem areas should be prioritized, serious processes selected for improvement, and improvement goals set for the projects team members. This is a top down procedure. There are various techniques which teams can use for their quality improvement effort. Training should be provided so that the teams know how to use these quality techniques.

Employees who are assigned to project improvement teams need to know how to use these techniques. Managers and superior need to know these techniques too, because it is their job of make easy and drive the quality improvement effort.

Everyone is a customer – External and Internal customer. The external customer is someone who purchases the product or service. Internal customers are those who make use of what another group providers. This has fairly profound implications. It means that every work group has to think about providing value to the people who utilize their product. This involves finding out exactly what the user requirements, and ensuring that the process provides it. The initial point for quality improvement is to determine the customer requirements. When the requirements are fairly simple, this can be done merely by talking to them.

When dealing with an external customer and the product is extremely complex, the determination of the customer requirements can be quite time consuming and requires a detailed analysis. A useful tool for determining the customer requirements and ensuring that these needs are incorporated into the product design is the Quality Function Deployment Matrix. Determining customer requirements accurately is an important aspect of quality control. Obviously, it is less expensive to rectify a mistake in defining customer requirements before a product is produced then it is afterwards. So spending the time and effort to figure out the needs correctly at the start is time well spent.

Defect prevention or avoidance saves money. Process for manufacturing a product begins with a specification. Drawings are created, parts are made and assembled, and the product is delivered to the customer. The cost of rectifying a fault increases by at least a factor of ten as the product moves through each of these stages. Defect prevention or avoidance is concerned with catching the errors as early in the game as possible or preventing them from happening at all.

Universal responsibility deals with the fact that total quality is not only the responsibility of the inspection department but is everyone’s responsibility in the organization. Quality improvement should be totally pervasive. Every work group in the business should be concerned with seeking ways to improve the quality process.

Quality Function Deployment (QFD) Video Example

QFD Example

Quality Function Deployment for a Competitive Advantage

Author:

Tony Jacowski

The understanding of the voice of the customer – internal as well as external – is key to implementing business strategies for a Six Sigma company. VOC data is useful to ensure that the data collated is real and factual and relevant to the goals of the business.

A useful and structured tool that helps to understand the requirements of the customers and translate them into business deliverables is the Quality Function Deployment (QFD) tool.

The Quality Function Deployment tool focuses on the positive qualities that lead to customer delight. It finds objects that may delight the customer and improves upon them. Quality Function Deployment is useful when the business is aware of the customer\’s requirements, but is unable to have internal measurements comparative to the requirements.

It is useful when a large investment is needed for a new product. When there is no agreement on delivering customer requirements and there is stiff competition in the market segment, QFD can be of great assistance.

How Does Quality Function Deployment Work?

The basic idea of Quality Function Deployment is to create a link between the attributes that the customers voice and design them based on parameters from which the specific contributing actions and responsibilities of functions can be identified. The structure is organized and is often termed as the House of Quality. It is useful when there is involvement of cross-functional teams.

The structure of House of Quality is built in four steps:

First house of quality – Customer’s House

The first house is the customer’s house. In this house, the goal is to transform the voice of the customer into simple, clear language. Companies have to understand the metrics on which the customer decides whether their requirements are met, and then develop its internal metrics that determine customer requirements.

The key elements of the first house are customers’ needs, measurable characteristics of the needs, relationship in between the needs and the characters measured in high, medium or low, comparison with competitors, competitive benchmarking and preliminary targets meeting the customer’s requirements.

Once these elements are identified, a relationship to the measurable customer’s needs and their strengths are determined. Finally, the analysis to establish the improvements is done.

Second House Of Quality – Company’s House

The second house is the company’s house. The goal of this house is to decide on the actions that are to be taken to satisfy customer needs. This house is generally constructed in the measure and analyze phase.

Third House of Quality – Process House

This house is the house of the process and constructed in the analyze phase. An analysis is done to find which processes should be implemented to meet the customer’s requirements.

A new process may even be developed if the need is felt.

Fourth House of Quality – Process Control House

This is the house of process control and constructed in the control phase. Its aim is to find the control variables used to satisfy customer needs.

It may not be necessary to construct all four houses of Quality Function Deployment. It should be used to meet customer requirements from the development stage to the delivery stage and it should agree on the measurement systems and performance specifications to improve the company\’s strategic competitiveness.

By including the steps to improve on both spoken and unspoken requirements, it helps gain a competitive advantage.

Article Source: http://www.articlesbase.com/management-articles/quality-function-deployment-for-competitive-advantage-482773.html

About the Author

Tony Jacowski is a quality analyst for The MBA Journal. Aveta Solution\’s Six Sigma Online offers online six sigma training and certification classes for six sigma professionals including, lean six sigma, black belts, green belts, and yellow belts.