The Blitz QFD Process

Figure 11.10 shows the nine steps of the Blitz QFD process. As you can see, the few first steps in Blitz QFD are aimed at understanding the project's context. We will discuss each of the nine steps of the process in the following subsections.

Figure 11.10. The Blitz QFD process has nine steps and no matrices (although it may lead to matrices, such as the "House of Quality" matrix shown behind step 9). From the Maximum Value Table (MVT), a wide range of project-specific concerns can be followed up. Four common ones are shown with branches: FMEA (for detailed analysis of high-risk items), Kansei Engineering (for analysis of interface design and look-and-feel-related issues), essential tasks on a Precedence diagram (for Schedule Deployment with Critical Chain project management), and problems (for solving with Six Sigma DMADV or DMAIC methods).

Step 1: Key Project Goal

Why are we doing this project? In what part of our organization's strategy is this project expected to play? To answer these questions we need to understand some aspects of strategy. One method that can help with strategic issues for software is the New Lanchester Strategy.^[44]

The New Lanchester Strategy

The New Lanchester Strategy is based on the Lanchester Laws, discovered by the British aeronautical engineer, F. W. Lanchester. After the outbreak of World War I in 1914, Lanchester, with great interest, witnessed battles in which aircraft he had worked on were used. He became convinced of the need for a mathematical analysis of the relative strengths of opposing battlefield forces to describe aircraft effectiveness. By conducting quantitative studies of the number of casualties on both sides in land, sea, and air battles, he arrived at the Lanchester Laws.^[45], ^[46]

Lanchester's work was introduced in Japan in 1952 in a book on operations research sent by W. Edward Deming: Methods of Operations Research by P. M. Morse and G. E. Kimball. Dr. Nobuo Taoka restructured Lanchester's military strategies into marketing and sales strategies. The books Dr. Taoka wrote were unprecedented business best-sellers in Japan. The Japanese adopted Lanchester's Laws, his ideas on concentration, and his military terminology in their marketing terminology. The strategies provided unique insights into competition between companies, and rules for selecting a strategy depending upon whether the company was attacking a new market or defending an existing market position were found to be quite useful. The Japanese also extended Lanchester's work to powerful and practical methods for planning market segmentation, market structure, and market position.^[47], ^[48]

From an analysis of the goals of our project, we should have a clear definition of what success means for the project. And we should understand that the team's performance will be evaluated when the project is finished.

Step 2: Key Customer Segment

Which customers or users can help us the most, to achieve our key project goal? Which can block our success? Whomever we must satisfy to succeed, or whomever must not be dissatisfied, we fail as a potential customer in QFD. Therefore, the next step is to consider the types of customers we are aiming to please, and their relative importance to the project, so that we can focus on the key segment.

Customer Segments Table

Because we will usually not have time to interview, survey, or visit all of our customers or users, we will have to work with a subset of them. So it is critical that we understand what subsets, or types, of customers we are dealing with so that we can make sure we investigate some users in each segment.

There are a variety of ways to perform segmentation.^[49] From an analysis of our customer segments, we should understand which customer segments are critical for us to succeed, and whom we must satisfy with our software.

Step 3: Key Process Steps

If we understand the meaning of success and we understand our key customer segments, we need to know where our software should add value to these key customers. To do this we will have to go to the gemba. But first it is useful to model what we already know, or expect to find, in a customer context model. A process model, such as a data-flow diagram, is useful for this.

Customer Process Model

We can use any process modeling method here, but for software developers, methods that are already familiar and are supported by drawing or CASE tools are best. A data-flow diagram is well suited to modeling the situation where the customer or user does whatever we are trying to support with our software.

From an analysis of the customer context, we should understand what customers do, and why, as well as what their problems are and the magnitude of those problems. But at this point our model is based on what we already know. How can we fill in what we don't know and validate what we think we do know?

Step 4: Go to Gemba

We must go the "real place"the gembawhere customers would benefit from the software we will build, and observe firsthand their situation, their problems, and their opportunities. We will use interviews, observations, and situation analyses in the gemba to gather the "voice of the customer."

Gemba Visit Table

Our aim is to observe what our customers do, and to understand why they do these things. We will also talk to our customers, but we won't get requirementswe'll get verbatims, or actual words. With their verbatims, we want to understand what they say (their meaning), and why they say it.

We can use a simple table to record our observations and the customers' actual words when we interview them in the gemba. Audio and video recordings are also valuable, as not everyone will be able to visit every gemba. If we can record what we see and what is said, we can share the experience with others on the team.

Why Go to the Gemba?

Most software developers build software for othersfor customers or users. The developer will have a mental model, or a surrogate, of the customer in his head and will often refer to this model when interpreting requirements or making design decisions.^[50]

But what does this mental model of a customer look like? In the absence of any other influence, it looks just like the developer. And this leads to statements such as, "Our customers won't want to do that; I never do."

The best software developers have accurate mental models of their customers in their heads, and they obtained those mental models because they had direct contact with real customers, in real situations. There is no substitute for seeing the customers firsthand in their work environment, and the means they use to perform their work. You learn about a customer's job, goals, and problems. And this knowledge does not develop without actually visiting the customer.

I have seen many cases where major design decisions were stymied because none of the designers had ever spent any time in the customer's world. When they finally were persuaded to "go see" (instead of "go ahead and guess"), they were able to resolve their quandary, with confidence, in less than an hour.

When key developers have never been to the gemba, inevitably they will make unfortunate assumptions about what the customer needs, or how the customer will use the software. Often this will result in a system that is overburdened with features (just in case they are ever necessary) and is overdesigned for unnecessary performance.

Too often, specification writers work with features rather than benefitsbut customers buy benefits, not features. For example, in writing a specification for a fax machine it may be tempting to specify a stepper motor or servo drive to move the paper or print head. But is that a benefit? Can the customer perceive it directly? If not, we should specify what the customer will actually notice, such as speed, print quality, and noise level.

This is where we get the "voice of the customer" in QFD. Once we have collected the verbatims and observations, the next step is to analyze them so that we get more than just the stated, surface requirements.

Step 5: What Are the Customer Needs?

What does the customer need? We have to analyze their clarified statements before we can clearly understand what we must do to satisfy them. Statements about reliability, cost, technology, usability, portability, and so on, are very different from customer needs, which are solution-independent statements of the benefits customers desire. As such, different people using different tools deal them with at different times during development.

To capture our customers' voices, we must begin by listening to raw customer expressionsthe verbatims. What customers say are not requirements. They are statements that we must understand, classify, organize, and prioritize. Only then do we have customer requirements as rigorously defined by QFD. What are their problems, opportunities, and strategic directions? What does the customer want, or need to do, about these concerns? The answers to these questions are true requirements.

Stated Requirements

Stated requirements begin as verbatims from multiple sources. Direct sources are interviews and observations. Indirect sources are mail and phone surveys. Historical sources are complaints and compliments concerning prior products and processes. You must carefully translate these raw customer expressions into positive, clear, and concise requirement statements using the CVT (or the voice of the customer table in Table 11.1). The customers then review and confirm these requirements, and you must sort statements that are not requirements, such as capabilities, features, functions, data, tasks, costs, schedule dates, technologies, and so on, into appropriate columns. Deployments following quality deployment address each of these thoroughly with a focused series of matrices and tables. You should organize the customer requirements alone by the customer using the Affinity Diagram^[51] to uncover the customer's conceptual organization of their requirements.

Table 11.1. Comparison of CVT and MVT. There are many tables and matrices in QFD, but Blitz QFD uses only tables (no matrices). Although these two tables are "cousins" with many apparent similarities, they have different purposes and produce different outputs.

CVT	MVT
Works right to left	Works left to right
Columns: all the types of customer concerns	Columns: all important project dimensions
Input: customer verbatims	Input: top n prioritized customer need
Output: customer needs	Output: essential items and tasks
Diagnostic: requirements	Diagnostic: project focus

Unstated Requirements

You must uncover unstated requirements by going to the gembathe place where your product/process adds value for the customerand observing with your own five senses the context of product/process use. Then you must organize these observations in a customer context table. Such context analysis techniques are an extension of existing problem analysis approaches. You may uncover additional unvoiced requirements by using some of the five types of relations diagrams.^[52] This tool allows you to discover significant requirements that no customer may have mentioned. Exciting and expected requirements are frequently found in this wayas well as with systems dynamics analysis.

In working through these steps, it is necessary to recognize and define each type of requirement as you encounter it. A requirements dictionary can be invaluable for this.

Changing Requirements?

One common refrain in software development is that the "user's requirements are vague or continually changing." To deal with this various incremental, iterative, and prototyping methods are available. But are the requirements actually changing, or is just our understanding of the requirements changing? Is the ambiguity of the specification due to some fundamental instability of the user's needs, or is it caused by a weak requirements discovery process? Customer needs originate from the customer's problems, opportunities, and the look-good-and-feel-good issues the customer faces in their situation. If the customer's situation is not changing in frequent or unpredictable ways, if their problems or opportunities are not suddenly emerging or vanishing, we cannot blame the problem on "change." (By the same token, unless the customer continues to require changes at the same rate after their system is delivered, the cause of the original "ambiguity" was not "change," but our own weak ways of obtaining requirements.) Part of the power of the requirements discovery methods in QFD is that they don't require or expect the customer to understand or articulate their own needs. They just have to allow us to visit their gemba, observe their situation, and listen to their verbatims. All these are inputs to the "voice of the customer" analysis process.

Customer Voice Table

We use the Customer Voice Table (CVT) for this analysis. (The CVT also acts as a good diagnostic tool: a "requirements Pareto chart").^[53] Figure 11.11 depicts a typical CVT.

Figure 11.11. The CVT is where we analyze the customer verbatims to discover the customer's underlying needs. Customers may tell us anything, but only solution-independent benefit statements represent true customer needs. Using the CVT, we work with the customer to understand what their needs are and why they are asking for them. This table is a powerful requirements discovery tool.

In the CVT we analyze the verbatims (as well as our observations and customer gemba analyses) to uncover the customer need(s) that underlie their verbatims and their actions. The columns consist of all the types of "requirements" that the customers are concerned aboutand thus they represent the dimensions of our project that are critical for success. So the table offers a high-level look at what will be important to address on a project.

Specifications: Features or Needs?

In QFD we don't focus on features. We don't even ask customers what features they want. Instead, we ask about the benefits they desire; their needs. What problems do they need to solve? What opportunities do they need to seize? From understanding such benefits, we can derive by analysis the best set of features to efficiently deliver the most value to our customers.

Certain features may be unnecessary to deliver desired benefits. But if you ask the customer, they may not realize that, and they may insist that they need it. Including such a feature only adds an unnecessary burden on development, with no increased satisfaction for the customer. Features are concrete. They are software capabilities or characteristics implemented in a particular way (with a certain design and implementing technology). The customer is not an expert on design or technology, so we should not be asking them to decide on those issues. The customer is an expert on their needs, and that's what we should be asking about.

When developers concentrate on needs, they understand why a user has a particular need and why it is important to them, and they preserve the full range of options for the design and choice of implementing technology. Customers buy benefits, not features. And when they are presented with a new feature, they try to figure out whether the feature will help them with any problems they have or opportunities they want to seize. But even if they can't see a benefit, they may still ask for it, as it may come in handy upon further analysis. It is much better to direct our inquiry to their problems and opportunities where they are truly knowledgeable and expert.

Perhaps the biggest failure of most software specifications is that they don't clearly distinguish customer needs from software characteristics and capabilities (or features), and they do not indicate what is most important to the customer, and why. Actually, this is not surprising. Developers can put into the spec only what they understand, and what tools and techniques do they have to understand customers' needs and priorities?

The CVT is where the analysis occurs to help developers understand customers, after going to the gemba. The output of the CVT is the column of customer needs, most of which were extracted from the verbatims and observations of the customers (that were in other columns). Only the customer needs are used in the next steps.

Step 6: Structure the Customer Needs

The customer needs in the CVT are just a list, and we know the list is incomplete. What we want to do is somehow bring to the surface the needs we are missing that are important to the key customer segment. How can we do that? Two steps are required.

The Affinity Diagram

After analyzing and sorting out the customer needs, we engage the customer in a simple exercise to bring to the surface the way they think about their needs. The result is an Affinity Diagram produced by using the KJ Method developed by cultural anthropologist, Jiro Kawakita. This nonrational "right brain" method comes from the field of cultural anthropology. Using the KJ Method to produce the Affinity Diagram reveals the natural structure of the customer's needs: the cognitive structure the customer uses to think about their own requirements.^[54]

With the structure of the customer's needs revealed, we will use that structure to refine needs and fill in missing and unstated needs.

Step 7: Analyze Customer Needs Structure

A simple procedure transforms the Affinity Diagram into a first-cut "skeleton" Hierarchy Diagram. You use the Hierarchy Diagram to analyze the structure of the customer's needs and to uncover missing and unstated needs. A key part of the analysis is to quantify the magnitude of the customer's needs. We must know what level of performance is currently available and what improvement is required to satisfy the needs.^[55]

The Hierarchy Diagram

Also known as tree diagrams or systematic diagrams, Hierarchy Diagrams are one of the 7 MP Tools used throughout all QFD deployments.

You can organize almost all key project concerns, including reliability, cost, and customer needs, into hierarchies with primary, secondary, and tertiary levels. Technically these are hierarchies, not trees, as "child" nodes may have more than one parent. They are useful for functional analysis and to show the hierarchy and decomposition of customers, requirements, objects, functions, and so on.

Hierarchy Diagrams make the structure of the high-value customer requirements visible. A three-level hierarchy works well even for very complex situations. Traditionally, requirements are organized in lists. It is difficult with lists to know whether you have a complete set of requirements. A properly organized and prioritized hierarchy can tell us whether we have sufficient requirements to satisfy our customers.

We analyze the hierarchical structure of our customer's needs to uncover unstated requirements, which are requirements that no customer mentioned but that the customers confirm are important. This needs hierarchy analysis is a requirements discovery method especially valuable for new and unprecedented software. It's difficult for customers to provide requirements for software they've never seen or used before, but we still have to develop such software.^[56]

A hierarchy is a natural representation of needs, and it is a very efficient format for analysis. Once we know the structure and magnitude of the customer's needs, we can prioritize them.

Step 8: Prioritize the Customer Needs

Given the customer's needs and their magnitude, we also need to know how important they are to the customertheir priority. And since we will use the priorities as weights, we need ratio-scale priorities. What is the simplest way to get ratio-scale priorities?

The Analytic Hierarchy Process (AHP)

The Analytic Hierarchy Process (AHP) is the simplest prioritization method that provides accurate results on a ratio scale. (Other methods are available, but either they are less accurate or they don't produce ratio-scale numbers. To use the priorities as multipliers, they must be on a ratio scale.)^[57]

You use AHP to prioritize the customer requirements in the Hierarchy Diagram. Although customer requirements were traditionally prioritized with a simple 1 to 5 scale, advances in Japan led to the use of the AHP.^[58] The AHP requires slightly more effort, but it provides superior accuracy of results along with consistency checking and sensitivity analysis.^[59] This method employs pairwise comparisons on hierarchically organized elements to produce a very accurate set of priorities. Developed more than 20 years ago in North America, AHP has been used in a wide variety of settings to establish priorities and improve the accuracy of decision making.^[60], ^[61] Further, users can carry out the calculations required by using a spreadsheet, or through the use of specialized AHP software.

The efficiency of the process comes from using AHP to prioritize the customer needs hierarchy from the top down. That allows us to identify the top 10 or 20 customer needs while analyzing less than 30 percent to 40 percent of the total requirements. We must have a detailed understanding of the vital few high-value customer needs. If we get them wrong, we cannot satisfy the customer, and we will fail. We do not need such detail on the trivial low-value needs. Getting them wrong, or even leaving them out, will not have the same effect on customer satisfaction.

Discover Only Sufficient Requirements

Note that this means that we do not need a complete set of requirements in order to satisfy the customer. In Modern QFD, the aim is to discover a sufficient set of requirements, or the smallest subset of customer needs necessary to satisfy the customer. In other words, can we deliver enough value for enough high-value needs so that the customer will be satisfied with our solution? If so, we don't need anymore requirements. This essential value approach to requirements definition is well suited to very rapid development efforts. We don't waste time building what we don't have to build.^[62]

In traditional QFD, we use Matrix Data Analysis Charts (one of the 7 MP Tools) to present the results of multivariate data analysis. Particularly for customer segmentation, techniques such as conjoint analysis, cluster analysis, factor analysis, multiple regression analysis, and others are useful, when substantial quantitative customer data exists. This is the most mathematically sophisticated quality tool.

In Modern QFD, the AHP has replaced Matrix Data Analysis Charts. Now we know what the customers what. So what should we do to satisfy their needs?

Step 9: Deploy Prioritized Customer Needs

We use matrices and tables to deploy (visibly communicate) value and priority throughout the development process in traditional QFD. We use matrices to explore in depth the relationship between two (or more) key project concerns simultaneously. We use tables to adjust priorities, set performance target levels, and document the details of processes and decisions. In Modern QFD, we use tables for deployment as well.

We use matrices to examine two (or more) dimensions simultaneously in any QFD deployment. Most commonly used to deploy value in QFD, matrices can also be used for prioritization using the AHP to focus on critical items. We can use a variety of matrices beyond the traditional L-matrix (such as the T-, Y-, X-, and C-matrices) for multidimensional analysis in QFD deployments.

With an essential set of high-value customer needs identified (along with their magnitudes and priorities), we then must plan how to deliver them. To do this we can use a table similar to the CVT: the Maximum Value Table (MVT).

The Maximum Value Table

On a CVT we begin with items that can come from any dimension of the development process, and we end up with just customer needs as our output. On an MVT we begin with just customer needs as inputs, and we may end up with items from any dimension of the development process as our output (see Figure 11.12).

Figure 11.12. The MVT is where we analyze the top high-priority needs of our targeted customer segment in terms of whatever vital, special, or difficult items are required to meet the customer's needs. The result is the identification of those items across the project that are essential to satisfying the most important customer needs, and those project tasks where the essential items are worked on. This table is a powerful requirements deployment tool.

When we have identified and connected the relationships between the high-value needs and related items throughout the project, we have discovered the essential items for development. On essential items we should use our best people, our best tools, and our best methods. Here is our best chance to do well and have it matter to the customer.

The MVT gives us a way to plan how to deliver the most important customer needs. This is where we identify the dotted lines in Figure 11.4b. The essential tasks that are the output of the table are where we need to apply consistent best efforts end to end on our project.

Downstream Deployments: Analyze (Only) Important Relationships in Detail

At this point, we can use selected tools from the set of 7 MP Tools to analyze in detail any items of special concern for the project. For example, we can examine the relationship between customer needs and solution capabilities with a "House of Quality" matrix. All of the QFD tools are available for use here, on those items (and columns) that are most important.

Failure Mode Effect Analysis

We use Process Decision Program Charts along with fault trees and failure mode effect analysis to analyze reliability issues. This tool comes from reliability engineering.

Kansei Engineering

Kansei Engineering is a technology that translates human kansei and images into physical design elements for designing a product satisfying kansei. For example, in order to realize kansei as expressed in "spacious western style room," we can analyze what "spacious" means, and using the results we can determine the square footage of the room, ceiling height, total area of windows, ceiling and wall colors, floor colors, and drapery colors that are also relevant to that kansei. Designing the room based on the data obtained through such a procedure will enable us to materialize a western room that makes you feel "spacious."

Today our basic needs for clothes and food are already satisfied. Now people want quality in their products. We are no longer satisfied with simply having a filling meal; rather, we demand delicious food and are willing to spend more for better food and nicer goods. As such, people today are looking for better-quality "goods" that meet their kansei. In this era, pursuing and addressing kansei is a must, and without it no product that meets the needs of the time can be developed. Kansei Engineering has gained attention as a tool to realize this aim.

We can apply Kansei Engineering in industry and in organizations. It provides a scientific analysis as well as design tools for architects to use on the houses and buildings they are working on; for the furniture industry to use in their sofa, bed, or chest designs; for the textile industry to use in fashion design; for auto manufacturers to use in their car designs; for the appliance industry to use in their appliance designs; and so on.

Mitsuo Nagamachi, Hiroshima University

The "House of Quality" and Beyond

Blitz QFD is fast and efficient, but there is a limit to how many items you can address with it. If you must handle a large number of items, matrices are necessary. As such, one of the additional tasks you can perform is to apply the Kano model to your quality characteristics.

The Kano Model

The Kano model, developed in the 1980s by Dr. Noriaki Kano, deals with "attractive quality creation" and the impact on customer satisfaction that a product may have if certain types of quality characteristics are present or absent, and to what degree.^[63] You can apply the Kano model as an advanced technique after you have translated customer needs in quality characteristics, or even features.^[64] It is a useful tool for designers who need to design a superior product in a competitive environment, and have marketing research support.

The Kano model requires that you complete interviews or surveys for a sufficient number of people from a segment, in order to draw a legitimate inference from the sample data to the segment response. The number of interviews or surveys required means that this is not a quick or simple analysis to carry out. It is critical that you validate and test the survey before you use it, as the wording on a Kano survey is very critical to proper evaluation of results. Figure 11.13 depicts the Kano model.

Figure 11.13. The Kano model has three levels of customer satisfaction on the vertical axis: satisfied, neutral, and dissatisfied. On the horizontal axis, a feature is present and meets expectations, or is absent and doesn't meet expectations.

The three main types of "requirements" in the Kano model are as follows:

1. Expected requirements. Features that are expected will dissatisfy if absent, but are neutral if present. Customers usually do not mention such features (unless they have recently experienced their absence). Delivering increased performance of expected requirements does not increase customer satisfaction.

2. Normal requirements. Features that are expected will dissatisfy if absent, but will satisfy if present. Customers usually mention features of this type (but don't expect customers to be able to tell you all of their normal requirements). Delivering increased performance of normal requirements does increase customer satisfaction, and decreased performance decreases customer satisfaction. On normal features relating to high-value customer needs, we want to be competitive and have a few where our performance is superior to the competition.

3. Exciting requirements. Features that are exciting will satisfy if present, but are neutral if absent. Usually customers do not mention these features (because they are often not aware of them, or that it is possible to get them). Delivering decreased performance of exciting requirements does not decrease customer satisfaction. On exciting features relating to high-value customer needs, we have an opportunity for a distinct competitive advantage. These features are often innovative and may be the result of applying new technology.

Precedence Diagrams

Precedence diagrams are the newer relatives of their older cousins, arrow diagrams and activity network diagrams. Project managers have used them for many years, and they are particularly powerful in the schedule deployment component of Software QFD using Critical Chain project management.

For dealing with project schedules and budgets, project managers have a variety of project management tools and techniques. For dealing with value, they have ... what?

Modern QFD identifies the essential path for a project, which comprises the "most value-adding" activities. These determine the value our project can deliver to our customers. The critical path comprises the longest series of dependent activities in the activity network. These determine the project's elapsed time. Which is more important to your success in software development? Project QFD is the continuation of Modern QFD by the project manager to control the project and assure the delivery of value to customers.^[65]

Six Sigma Projects

When the "voice of the customer" analysis identifies a customer problem we must solve, we need to apply a problem-solving method. The QI Story approach from TQM and the DMAIC approach from Six Sigma are effective methods for doing this. In some cases, we may need to use the initial steps of these methods to study the context of the customer and determine what improvements we can make.^[66]

Follow-Up: Apply, Evolve, and Improve the Process

We must continuously improve our development process. With Blitz QFD, we have a basic framework for becoming more sophisticated at delivering value to our customers better and faster. Beyond this lies the entire Comprehensive QFD process and tools. This last step is essential for avoiding arrested development of the QFD process. (Some software organizations have been using "Kindergarten QFD" for years. They have never gone beyond a rudimentary application of QFD, and so today spend more effort than necessary to get fewer gains than what Modern QFD could provide them.)

Blitz QFD is an engineered way to get started with value. Once you have this base, there are many ways to extend it further.^[67] This last step is essential for avoiding arrested development of the QFD process.

Blitz QFD is a better place to start QFD than the "House of Quality" is. If it is appropriate for your project, you will get a better "House of Quality" matrix faster and with less effort than if you started off there. The "House of Quality" matrix will be sized and scoped to fit your project's strategy, your customers, and the relative importance of the relationship of customer needs to functional requirements compared to other relationships of other dimensions of your project.

Rapid Development

In software development there are many approaches to rapid application development (RAD).^[68] Most of these methods lack focusthey have no "aiming mechanism" to customer satisfaction. Although fast feedback, rapid prototyping, iterative development, and other techniques are excellent for "midcourse corrections," they work even better when Blitz QFD helps to reduce the number of unnecessary iterations.

One of the largest software development organizations in the world, when developing its rapid development methodology, was concerned about the "full speed ahead into a brick wall" risk it found in most rapid development methods. It chose Blitz QFD to "aim" its rapid development approach and formally incorporated it into its global methodology. Its experience was that this enhanced the effect of its rapid development software engineering and project management methods.^[69]

Schedule Deployment with Critical Chain Project Management

Perhaps the best follow-up to Blitz QFD, which gives us excellent technical focus on the essential items, and Project QFD, which gives us excellent project management focus on the essential tasks, is QFD Schedule Deployment.

The Schedule Deployment subsystem of QFD uses the Critical Chain approach to project management (from the Theory of Constraints) to reduce the elapsed time of most software projects by 15 percent to 25 percent (15 percent for small projects and 25 percent for big projects).^[70] However, Critical Chain implementation is challenging, as it requires a paradigm shift in project management. There are also some very powerful methods for proactive risk management that are possible only with Critical Chain.^[71]

Although you can use QFD Schedule Deployment and Blitz QFD completely independently, it is important to use Schedule Deployment with Blitz QFD to ensure that projects are shorter and satisfying to the customer.

Several software organizations are currently implementing Blitz QFD with Schedule Deployment, and results to date have been so good that they have so far refused permission to even summarize their results.^[72] This is a very promising avenue for any software group looking to make substantial improvements in their performance.