Waterfall Design (QFD): Looks Good but Watch Your Step
Waterfall design looks so good on paper. You start by defining customer requirements and then each step naturally leads to the next until the service is offered, product produced or new process is launched. A QFD is a waterfall design process and it expresses this natural progression as linked matrices. Anyone who has ever seen a presentation for QFD sees and accepts the logic of the waterfall concept. Why then is it that what seems like a smooth running machine usually ends up a painful and burdensome process?
The problem is that elements of a product or service are usually put through in phases to keep the whole work flow running. If that weren’t done, the Company would have the vast majority of the people in the process idle having either finished, or still waiting for their turn, to contribute to the final work. Such massive underutilization is no way to run a company. So we avoid the poor utilization by breaking things down into pieces and sending them through the process in components. The pressure to maintain utilization and the resulting flow of components creates a tremendous problem in waterfall design processes.
The problem is the series of rework loops caused by gaining buy-in and responding to feedback from internal customers. As each segment flows through the maze of work, each functional area has valuable feedback and expects to be heard. Once again, using the QFD process as an example, as the output of each matrix becomes an input to the next matrix, the new parties have comments. And as such, the input to a particular matrix gets kicked back along with the new functional area’s thoughts and comments. The water is now flowing up the waterfall!
Now the problem starts to compound when you have more than two matrices in the process. When its just two, the rework and new work cross and loop until their joint work product meets exit criteria. They are just handing off to each other like two people having a catch with two balls. Every now and then one player may have both hands full but the waste of his compatriots empty hands is short lived.
But once past two players, problems arise quickly. As a simple example, let’s imagine three matrices starting with product definition. Product definition provides input to design which, in turn, provides input to Service Operation or Manufacturing, as the case may be. Now imagine, just like when there were two matrices, that the output of the first matrix (i.e. product or service requirements) goes to a design team which provides feedback. They remain in equilibrium until the design team’s output goes to a production or delivery team which has its input. As Player 2 passes reworked Cycle 1 to Player 3, they are also receiving reworked Cycle 2 from Player 1. It isn’t long before a ball hits the ground.
Irrespective of how fast everyone can be, if you add enough matrices or steps, the process breaks down. What usually happens is that Player 1 ends up with a stack of balls on the ground around him. The system was designed for one set of requirements to flow smoothly. When multiple rework loops occur, the perfectly designed machine collapses under its own weight.
There is no easy and universal problem for this breakdown. Some possible solutions are for fully integrated teams representing all functional areas to work on components together through all phases. A design “cell” if you will. Another solution might be to design from the back to the front. And yet another might be to simply accept underutilization as a cost. But whatever the case, you should be aware and step outside the box before you drown in the waterfall. If you have comments, please contact me.