- The Language Gap
- QFD in Use Case-Driven Projects
- Running a QFD Workshop: Mega Motors Example
- Chapter Review
This chapter is from the book
This chapter is from the book
This chapter is from the book
QFD in Use Case-Driven Projects
QFD is a tool that can certainly be used by an individual, but its real value is as a structured approach for team prioritization and decision making. A team that uses QFD for product planning will emerge with a common vision of the business drivers, priorities, assumptions, issues, and questions that need to be addressed.
While the QFD process is fairly standardized for manufacturing, there is no standard for its application in software development in general, much less use cases specifically. QFD has received some discussion in the use case community as a means of prioritizing use cases.3 Used in this fashion, QFD serves as a tool for linking business drivers to use cases by identifying those use cases that are best aligned to the business drivers of the project: in QFD lingo, "deploying" the business drivers to the user requirement level.
What has received less attention in the use case community, however, is the subsequent use of QFD coupled with prioritized use cases to prioritize other aspects of software development, such as alternate design approaches. This is the second transition of Figure 1.1, from what the user requires to what is required of the system to support the user. Used in this way, QFD serves as a tool to identify those aspects of product design best aligned to the use cases, which are in turn aligned to the business drivers.
){kind=link}
Again, while there is no standard, I have found the following combination of QFD, coupled with the hierarchy of Figure 1.1, to be of value:
QFD used as a framework to move vision and its associated business drivers vertically through the project to the user requirement level as a prioritized set of use cases.
QFD, coupled with prioritized use cases, as a framework for prioritizing and decision making in terms of what is required of the system.
This approach is illustrated in Figure 1.2, in which QFD is used as the mechanism to transition vertically from thinking about the business, to thinking about the user, to thinking about the system, a la the hierarchy of Figure 1.1.
In the diagram of Figure 1.2, arrows show the business drivers of a project as input to the first QFD matrix whose output—a prioritized list of use cases—serves as the subsequent input to other QFD matrices, for example, to prioritize alternate designs for a product.
)
Figure 1.2 A general framework for applying QFD to use case-driven projects.
We are going to look at an example of how QFD is used as a tool for product planning, helping a team to make this vertical transition as part of that planning, but first we’ll talk about business drivers a bit more. Given that the adage "garbage-in, garbage-out" applies to QFD, it’s worth spending some time talking a bit more about that first, initial input to the QFD process of Figure 1.2: the business drivers.
Business Drivers in QFD
In standard manufacturing-based QFD, the process starts with the Voice Of The Customer or Customer Needs, couched as what are often called quality requirements; hence, the origin of the "Q" in QFD. These "customer needs" often sound like the ambiguous non-functional requirements we are warned against in software engineering:
System must be easy to use
System must be reliable
System must respond quickly to inputs
In QFD, however, these ambiguous sounding quality requirements eventually evolve into very technical, non-ambiguous requirements. It’s all part of the process.
As Figure 1.2 shows, however, the QFD process as described in this chapter starts with business drivers; it is based on the use of QFD as a mechanism for working vertically through Wiegers’ levels of requirement types, from business drivers, to user requirements, to system requirements, and even design. My experience is that a software project is typically driven by a combination of factors, only some of which are customer needs. For example, I’ve seen projects where the prime objective was to explore technology the company did not understand well as a way to increase understanding and minimize risk in the long term. That approach is very much associated with the risk-driven development style of the Unified Software Development Process or the "Agile" methodologies and is not something one would typically see in a standard manufacturing QFD example as a "customer need." On the other hand, if the business drivers for a project are strictly limited to making the customer happy, the business drivers will be a standard QFD "voice of the customer."
A business driver is something that provides a clear sense of why a project is being undertaken and the ultimate value it will provide; it’s a force to which businesses must respond and drives a business’s direction. A business driver could be a customer need (system must be reliable) or an internal company objective (minimize risk by exploring technology not well understood). Ideally, business drivers are win-win in nature, providing value for both you and the customer. A business driver that makes money for you but produces a product the customer is unwilling to pay for is not terribly useful, and a customer need that does not line up with your profitability is a money-losing situation for you.
Business drivers as used in QFD are a way to make a project’s vision tangible and provide a basis for prioritizing virtually every activity of the project. In a way—and this is very important—in QFD the prioritization of the business drivers is in a sense a business driver itself. As the prioritization of business drives is the crucial beginning of the QFD process (mistakes made here will propagate forward through the rest of the process) it is worth a closer look.
The "Chaos" of Projects and the Importance of Prioritization
QFD boiled down to simple mechanics is in large part about establishing links between things (QFD is an ideal tool for traceability)—in our software project model the links are from business drivers, to use cases, to aspects and parts of the system—and about prioritizing those links.
Prioritization is so ubiquitous to project management that it’s easy to overlook its importance. We prioritize because we can’t do it all (we have time for X or Y, but not both) or because a product can’t be all things (it can be X, or it can be Y, but it can’t be both simultaneously). We prioritize as a way of deciding to follow one path or another.
You may be aware that some systems, both natural and man-made, produce radically different outcomes when started with just slightly different initial conditions. In the relatively new field of chaos theory this is called deterministic chaos. These systems are deterministic: given the same starting state and inputs they produce the same result every time. It is just that even very slight changes in the starting state and inputs can result in radically different results. This is what makes weather prediction so difficult; the weather is chaotic in this very sense.
I’m convinced that software projects are chaotic systems too, and you may well agree! If you could take a software project, clone it, and start the copies with the same business drivers, but with different priorities, you might find the projects producing significantly different products.
Let’s take a very concrete example of this that will set us up for our QFD example. How many of you have bought a car because it is ugly? Raise your hand. I don’t see any hands. OK, how many of you have bought a car because it is fuel in-efficient...uses too much gas? Still no hands. How about cost...have you ever bought a car because it cost too much money? Safety...have you ever bought a car because it’s un-safe? By and large we all buy cars using the same business drivers: we look at the gas mileage, how much it costs, what it looks like, safety, and so on. If we all buy cars using the same business drivers, why don’t we all drive the same car? Priorities. We place different priorities on the business drivers, and those priorities result in radically different decisions about the cars we own and drive.
While it may be OK for us all to drive around in different cars, if we are an engineering team designing next year’s new model car, we must work from the same set of business drivers and with the same priorities.
I was helping facilitate a working session once for a cross-company program composed of several separate product teams working in concert. The group was made up of project managers, product managers and/or technical leads from each product line. I had the group start by listing the business drivers for the program. In just a few minutes the group was able to produce a handful of drivers for the project. Quick agreement. Slam dunk. They were ready to get going with project planning issues! But before letting the group move ahead, I asked them to take just a moment more to prioritize the list of business drivers in rank order. I had each person work alone in silence, then come to the front and write the business drivers on the board in priority order. While the group readily agreed on the business drivers, their priority level was another matter. Nearly an hour later, the group was still trying to reach agreement on this matter of priorities. It had become apparent that unless a consensus was reached, it was unclear whether this program was going to wind up building a Hum Vee, a Harley, or something in between (metaphorically speaking, that is; this was in the oil and gas industry).