Phases of Quality Function Deployment – Statistics for Projects

Phases of Quality Function Deployment

Statistics for Projects

Last Updated on Thu, 03 Nov 2022

Although there are many implementations and interpretations of QFD that are industry and business specific, the general body of knowledge acknowledges that the deployment of requirements down to detailed specifications requires several steps called phases. Requirements are user or customer statements of need and value. As such, customer requirements should be solution free and most often free of any quantitative specifications that could be construed as “buy-to” or “build-to.” Certainly the process limits discussed in the section on Six Sigma would not ordinarily be in the customer specification. Thus, for example, the Six Sigma process limits need to be derived from the requirements by systematic decomposition and then assignment of specification to the lowest level requirements.

Figure 8-11 presents a four-phase model of QFD. Typically, in a real application, the project manager or project architect will customize this model into either more or fewer steps and will “tune” matrices to the processes and business practices of the performing organization. We see in Phase A that the customer’s functional and technical requirements are the entry point to the first matrix. The Phase A output is a set of technical requirements that are completely traceable to the customer requirements by means of the matrix mapping. Some project engineers might call such a matrix a “cross-reference map” between “input” and “output.” The technical requirements are quantitative insofar as is possible, and the technical requirements are more high level than the specifications found in the next phase. Technical requirements, like functional requirements, are solution free. The solution is really in the hardware and software and process deliverables of the cost accounts and work packages of the WBS. As such, technical requirements represent the integrated interaction of the WBS deliverables.

I J2

Project

Requirements

Phase A:

Requirements to

Requirements

Project Specifications

Phase B:

Requirements to

Specifications

Work Package Specifications and Attributes

(A tz O

Phase C:

1

Specifications

ll

to Low-Level

Specifications

o. in

and Attributes

Project Methods and Processes

Phase D: Work Package Specifications to PfOOess and Methods

Figure 8-11: QFD Phases.

Following Phase A, we develop the specifications of the build-to or buy-to deliverables that are responsive to the technical and functional requirements. We call the next step Phase B. The build-to or buy-to deliverables might be software or hardware, but generally we are looking at the tangibles in the work packages of the WBS. Specifications typically are numerical and quantitative so as to be measurable.

Subsequent phases link or relate the technical specifications to process and methodology of production or development, and then subsequently to control and feedback mechanisms.

Project managers familiar with relational databases will see immediately the parallels between the matrix model of QFD and the relational model among tables in a database. The “output” of one matrix provides the “input” to the next matrix; in a database, the “outputs” are fields within a table, and the output fields contain the data that are the “keys” to the next table. Thus, it is completely practical to represent QFD in a relational database, and there are many software tools to assist users with QFD practices. Practitioners will find that maintenance of the QFD model is much more efficient when employing an electronic computer-based database rather than a paper-based matrix representation.

Continue reading here: Quantitative Attributes on the Quality Function Deployment Matrix

Was this article helpful?

0
0