Focus on Value with Project QFD

Learning from what software teams have learned as they applied QFD over the past ten years, let's consider the project manager as our "customer for QFD," and offer him the smallest subset of QFD that can deliver major benefits in better project management. The best place to start with QFD is Blitz QFD. What is it, and how can the project manager use it?

When someone "does Blitz QFD," it does not mean he has simply done the "House of Quality" really fast. Some teams have tried to reduce the time it takes to do QFD (really just the "House of Quality") by doing QFD work in joint application design (JAD) sessions. In this approach, a QFD facilitator rushes the team through the "House of Quality" in one or two days. The team feels good about doing QFD ("great, got that over with...") and is impressed with the facilitator's skills. Often a severe case of facilitator dependency develops, where teams must schedule their QFD work around a facilitator's availability. (Can you imagine having to wait for a "data flow diagram drawer" to become available so that you can complete your process models?) That is not good QFD.

Such a "Soviet-style" approach to implementing QFD is counter to the spirit of QFD. A multiskilled, cross-functional project team is the ideal vehicle for QFD. The project manager and his team should learn, and then be able to do, QFD by themselves (just like they do with their other software engineering and project management work). QFD is for project managers and developers, not just for QFD specialists. Where is the benefit of having development teams that do not know how to more efficiently deliver value and satisfy their customers?

So, what are the steps the project manager can use to discover and deliver value?

Seven Steps to Better Projects

The Blitz QFD path consists of a series of seven steps that use several tables, diagrams, and a mathematical method for sound prioritization [Zultner 1995]. See Figure 26.6 for a gestalt of the overall process.

Figure 26.6. Project QFD is an application of Blitz QFD to the special needs of the project manager. It is fully upward compatible with Comprehensive QFD, and it gives the project manager the largest return for his efforts. Note that there are no matrices. Blitz QFD shows the project manager the essential path.

The first step is to start with customers. We start by thinking carefully about who we are trying to satisfy with our project: Who are our customers? This is a basic but crucial step that we must complete before we investigate customer needs. If we investigate the wrong people, the wrong customers, everything else will be wrong.

Step 1. Go to the Gemba

The gemba is the "actual place" where our product will add value to the customer (see Figure 26.7)where our product will help solve our customer's problems and help them seize their opportunities. We must go there to learn what we cannot learn by any other method.

Figure 26.7. Gemba means the "actual place." By going to the gemba, we listen to the "voice of the customer" and observe the context of the customer. Only then can we fully understand the customer's needs.

We can observe only by going to where our customers have their problems and opportunities, and seeing firsthand the context for our software. The context creates much of the opportunity for us to add value to our customers' work. By understanding the context, we can see opportunities to add value beyond what any customer might think of. We would use structured methods, such as in-context market research and contextual inquiry, at this point.

What we get from customers is not requirements, but verbatims, or statements that we must interpret and act on correctly. Customers don't give us needs; they give us hints that we must follow to find their needs.

Step 2. Discover the Customer's Needs

Our customers will tell us many things, but they are untrained as requirements sources. It is our job to understand what they mean by their statements, and to understand why they are saying what they are saying. If we don't understand our customers, we have little chance of satisfying them. We must take their words and sort out what kind of statement they have made, and then discover the needs behind their words.

The Customer Voice Table (CVT) is the tool we use for this analysis (see Figures 26.8 and 26.9). The CVT provides a very simple but powerful way for us to see what kind of statements we have, and what could lie behind those statements. When we infer or generate an underlying need, we always confirm it with a real customer.

Figure 26.8. The CVT is a tool for sorting verbatims to discover underlying customer needs. We must understand what the customers mean by what they are saying, and why they are saying it. The result is a customer- and project-specific operational definition of value.

Figure 26.9. The CVT contains columns for any dimension of the project that the customer might mention. We can use it as a discovery tool, and as a diagnostic tool for "completed" requirements documents. The flow is from right to left, from verbatim to the underlying customer need.

Now that we have sorted our customer's needs from everything else, the next step is to take the list of customer needs that wind up in the Customer Needs column on the CVT and work with just those needs.

Step 3. Structure the Customer's Needs

From the list of customer needs, we must understand the way our customers think about their needs. Understanding the structure of their needs, as it is in their own mind, is a powerful basis for discovering unstated needs, or needs that they have implied by what they have said.

The customers produce an Affinity Diagram using the KJ Method (see Figure 26.10). This method from cultural anthropology is a fast and fun way to make visible how customers feel about the method they are performing. We want the actual customers to perform the KJ Method on their needs (and only on their needs).

Figure 26.10. The Affinity Diagram, when created by actual customers, reveals the natural structure of their needs. Once we understand this structure, we can use it to uncover unstated but implied needs, which we can then confirm.

It is important that our customers perform the KJ Method and produce the Affinity Diagram. We want to know how they organize their needs. The way we think about our customer's needs is of only academic interest. We want to discover what we don't know about our customer's needsnot document our own irrelevant thoughts. (After all, the team isn't going to buy or use the software; they aren't the customers!)

The Affinity Diagram gives us the framework for how our customers think about their needs. Now we want to analyze that structure further.

Step 4. Analyze the Customer Needs Structure

Using the Affinity Diagram as a base, the team must now analyze the revealed structure, and fill in the missing needs.

The Hierarchy Diagram is the result of a simple transformation of the Affinity Diagram (see Figure 26.11). The Affinity Diagram shows us the skeleton structure of our customers' needs. Now we must analyze that structure, understand it deeply, and use it to uncover unstated (but implied) needs. The key is the rationale for why the items are arranged the way they are. We must carefully clarify and strengthen the natural structure.

Figure 26.11. We use the Hierarchy Diagram to analyze the Affinity Diagram's structure and find the missing needs that the structure implies. Then we can prioritize this structure efficiently with the Analytic Hierarchy Process (AHP).

A properly analyzed hierarchy is one of the best and easiest methods to discover exciting customer needs that can provide a substantial competitive advantage.

Step 5. Prioritize the Customer's Needs

Blitz QFD is guided by a fundamental fact of project management: It is very difficult to focus on more than a few concerns throughout a project. To determine which few concerns would be most profitable for us to focus on, we must get our customers to prioritize their needs. Recognizing that priorities follow Pareto's Principle, we just want to know which vital few needs will deliver the most value to our customers.

The Analytic Hierarchy Process (AHP) is an elegant, efficient procedure that provides accurate ratio scale priorities of customer needs (or anything else; see Figure 26.12). With real customers, we work through the hierarchy of their needs from the top down. We pursue the high-priority branches first so that for a minimum of effort we can determine the highest-value needs of our customers. In many cases, we will not need to evaluate the majority of these needs because the structure of the hierarchy (and the priority of the primary and secondary needs) can't mathematically be of high value (see Figure 26.13).

Figure 26.12. Pairwise evaluation is done on customer needs at the same level in the hierarchy, and ratio scale priorities are calculated by taking the row average of normalized columns. This is an approximation of the eigenvector, which you can determine exactly with AHP.

Figure 26.13. We use AHP to prioritize the hierarchy of customer needs from the top down. This allows us to find the highest-value needs without having to look at all the items, or even all the branches. A check on the consistency of the judgments is also part of the method.

You can use any spreadsheet to fairly closely approximate priorities using AHP. For exact answers, several AHP software products are available. (The lite or educational versions are more than adequate for QFD [for example, Expert Choice].)

Because we plan to use the priorities as weights to focus our best efforts, they must be accurate (tested and validated) and ratio scaled (so that we can properly multiply by them). The AHP is the simplest procedure known that meets these two criteria.

Step 6. Deploy High-Value Customer Needs

Once we have identified the highest-value needs, we can select the top n needs (where n is a small number that you can actually focus your best efforts on end to end).

You use the Maximum Value Table (MVT) to deploy the highest-value customer needs (and their priorities) to whatever you must do during the project to deliver the most value you can to your customers (see Figures 26.14 and 26.15).

Figure 26.14. The MVT uses a framework similar to the CVT, but the MVT contains a column for all the project dimensions we must address to satisfy the highest-value needs. The flow is from left to right, from highest-value needs to the project tasks necessary to deliver those needs to the customer.

Figure 26.15. The MVT is the fastest way to identify which activities add the most value to customers. It summarizes on one page all the items that are most important to the project in terms of value. Now the project manager can identify what matters most; what is essential to success.

When you have identified the relationships between the prioritized needs and you have identified the items in the other columns by drawing linking arrows, you have identified the most important items in every other column in the table. This project-wide definition of value makes the MVT the single most powerful piece of paper in the QFD process. It shows all the most important items for all dimensions of the entire project.

The final result of the MVT is that we know which project tasks are essential to satisfying the customerwhich tasks deliver the maximum value to the customer. On these tasks the project manager must do his best to plan and deliver the team's best efforts. On the performance of these tasks rests the best chance to satisfy the customer, and therefore the success or failure of the development project.

Step 7. Analyze Essential Tasks in Detail

A project manager should consider three basic analyses once he has defined the essential tasks. He must make sure the QFD analysis results are integrated into the master project plan; he must make sure he understands in detail how to perform the high-value activities; and he must consider how to avoid failure in performing the high-value activities. Three tools can help.

1. Work Breakdown Structure (WBS). The MVT shows us the most essential tasks. But some of these will not be in the project plan. (Because the project plan was created without any analysis of value, this is to be expected.) It is absolutely essential that the essential tasks be included in the project plan. After all, they are more important than any other tasks. We must update the WBS and/or the Precedence diagram with the high-value tasks. Project QFD does not replace existing project planning methods; it supplements them to include value, which is most the important issue on development projects.

2. Project Task table. Some of the essential tasks may be new to the team. They will require careful definition and detailed planning. The Project Task table is a simple, one-page framework for detailed task definition (see Figure 26.16). The checkpoints and control points are valuable contributions from the Quality field to the project manager. We should consider how the person performing the task can self-check his work so that he knows it is correct and complete, and what results the project manager can examine to control the performance and/or completion of the task. A comprehensive project management software package should support all the items in this table, and manage the relationships between them.

   Figure 26.16. The Project Task table provides the project manager with a way to define in detail the new high-value project tasks. The 5Ws, 3Hs, and 2Cs cover all the basic elements of a project task. The checkpoints and control points are especially important for detailed planning of essential tasks.

   

3. Failure Modes and Effects Analysis (FMEA) table. Managing risk is an important part of any development project, so which project activities should we examine first for risk? The essential tasks. One simple and well-tested tool for this purpose is the FMEA table (see Figure 26.17). Long used in reliability engineering, this tool is very useful when applied to high-value project tasks. The careful analysis of potential failure modes, and the preparation to prevent them, is one of the greatest strengths of a superb software development project manager. Active measures to mitigate risk are not new, but they are not applied widely enough in software development.

   Figure 26.17. The FMEA table gives the project manager a tool for risk management for high-value tasks. Anticipating problems and preplanning the prevention and mitigating actions is a powerful way to protect the essential tasks on the project, and to minimize loss of value.

   

Further Analysis

At this point, we can use any of the Seven Management & Planning (7 MP) Tools, including matrices, to analyze in depth any aspect of the project, if we have the time and resources to act on such analyses. For example, for many (but not all) projects, the relationship between customer needs and functional requirements is important. To examine in precise detail how all the top n customer needs relate (and how strongly) to the functional requirements, we can use the "House of Quality" matrix effectively. But there is no point in performing any detailed analysis, unless you believe your time and resources are sufficient to get the necessary results during your project.

With a well-stocked toolbox of QFD tools, it is easy to overanalyze. QFD can support more analysis than any single project can put to use. The project manager must discover the high-value customer needs, the important items on all dimensions of the project, and what tasks are essential to delivering the defined value. With limited time and resources, any analysis must provide a clear payoff. Don't fall into analysis paralysis.

The Blitz QFD process is designed to get projects off to a better start than just jumping in with a "House of Quality," which provides no direct benefits to the project manager. If it is appropriate for your project, you will get a better "House of Quality" matrix faster and with less effort from the foundation the Blitz QFD process provides. Prioritized customer needs allow you to control the size and scope of the "House of Quality" matrix, and avoid one of the leading causes of QFD project deaths: matrix gigantus.