Implementing Software QFD

In the first ten years of the use of Software QFD in North America, QFD was refined and fit to the special needs of software development. But how have software organizations fared in implementing Software QFD? Figure 11.14 shows where QFD adds value in the software development process.

Figure 11.14. Where does QFD add value in software development? Primarily at the "fuzzy front end."

The People Side of QFD

QFD addresses the entire software development process, end to end. As software development is a managed, socio-technical system, so QFD considers management, social, and technical aspects (see Figure 11.6). QFD works best if managers empower their development teams. QFD works best with full, cross-functional representation on the project teamincluding customers. QFD works best with a concurrent sequencing of project phases. QFD works best if the team spends time in the gembathe place where the software adds value to the customer. QFD works best with heavyweight project managers with authority over cross-functional resources for the entire project. Although the technical aspects are most commonly addressed in QFD literature, some of the most successful Software QFD organizations use only the social side of QFD (so far). It is also easier, once started, to maintain the social aspects of QFD throughout the duration of the project. You should neither neglect nor underestimate the power of the people side of QFD.

With a limited number of items of great importance to the customer, it is possible for a team to focus its efforts on only social mechanisms. Software startups often use this approach. Once they succeed and begin to grow, they must add formal and technical tools in order to maintain their ability to deliver customer-satisfying software with a rapidly increasing workforce.

QFD Challenges and Pitfalls

Software organizations have taken a variety of approaches in implementing QFD. The three large organizations profiled in the following subsections were selected to illustrate the range of implementation possibilities, not best or worst practices. In most cases, a software organization implementing QFD does not have open to it an "ideal implementation" path as described in some of the QFD articles published recently. They must make do with their situation, and their organization, as they find it. They must use an opportunistic approach to implementation.

Case 1: Basic QFD

In this case, QFD was brought in by the Software Development Group in 1988. They saw QFD as a way to improve their requirements-gathering process. In this organization, they started with the basic "House of Quality" matrix and began using it for software. They developed a short course for developers and proceeded to broadly roll out QFD among their development community. Training and consulting assistance was available on a limited basis from a handful of part-time QFD practitioners. Software QFD spread, and stagnated at a basic level.

The strength of this approach is that QFD has become a routine part of software development. QFD has been "installed" in the software development process. The penetration of QFD in this organization is truly impressive. The weakness of this approach is that since developers did not see QFD as an area of expertise, no experts arose to lead the organization beyond their initial use of what today can be called "Kindergarten QFD." Today, although they have had good overall success with QFD, in certain competitive sectors they have been beaten by competitors using a more comprehensive, more sophisticated, and more powerful QFD process.

Case 2: Facilitator QFD

In this case, the Quality Group brought in QFD in 1988. They saw QFD as another service their facilitators could offer to their internal customers, the software development teams. Developers were already accustomed to requesting assistance with team building, decision making, testing, standards, and other quality-related tools and techniques, so QFD became just another offering. The process started with the Quality Group's decision to adopt QFD as an "official" quality technique. Then, some members of the Quality Group were trained in Software QFD. These QFD facilitators then began working with project teams and attending conferences to learn more about QFD.

In this organization, QFD is considered a quality technology, and teams wishing to use QFD arrange for a QFD facilitator to work with their team on an as-needed basis for the duration of the project. When the facilitators are not busy, they engage in "QFD evangelism" to spread the word about QFD and line up future projects to work with. The Quality Group highlights projects using QFD, and publicizes successes internally and externally. Every year, some people on the teams that used QFD become enthusiastic about it and request a transfer to the Quality Group to become QFD facilitators.

The strength of this approach is that a small group of trained QFD experts works with project teams. This is a good way to get a small number of high-quality QFD efforts going quickly. The weakness of this approach is that since the project teams are led through the QFD process, they often don't learn it themselves, and they become dependent on the facilitators for any QFD use. Rarely is any formal developer training performed. Further, the process is critically dependent upon the knowledge of the facilitators. In some cases, facilitators were pressed into service without adequate training and experience. For those projects fortunate enough to get a knowledgeable facilitator, the results can be most impressive. But the small number of facilitators prevents that from being the case for the majority of project teams. (Also, the best facilitators tend to leave and become consultants...)

Case 3: Guerrilla QFD

In this case, top management had very little understanding of quality, especially quality systems such as QFD. They did permit their project managers and project teams wide latitude in selecting their approach to software development. Such empowerment extended to obtaining training and consulting assistance without the express approval of higher-level managers. Thus, at the team level, any particular project manager and team could choose a "new and radical" approach (such as Software QFD in 1988) and use it on their project.

In this organization, the spread of QFD is very much in the spirit of Francis Marion ("the Swamp Fox" circa 1780), Mao Tse-tung,^[73] and Ernesto (Che) Guevara. Developers or team leaders with good experience with QFD persuade their colleagues to give QFD a try. Some training and consulting assistance is obtained, if possible, and the most appropriate parts of QFD are applied to the project. Rarely is the term QFD applied to their efforts, and generally no effort is made to highlight that they are using any new tools or techniques. Depending on the degree of success that results, more developers become QFD partisans, and some become actual QFD provocateurssecretly spreading QFD throughout their organization.

The strength of this approach is that it is virtually unstoppable. People who use QFD tend to do better than those who do not (even with partial mastery), and so they spread out and rise up in the organization. Even if management wished to, they could not suppress this "no name" QFD approach. To suppress it management would first have to be able to recognize it in its many forms and variations, and that would require extensive training. (In that training, they would see the benefits of QFD and cease their persecution of it, we hope.) The weakness of this approach is that since the spread of QFD is unplanned, unmanaged, and unsupported, it occurs haphazardly as the partisans move from one project to the next. Also, some of the provocateurs tire of the lack of support and appreciation from their management and leave to work at other organizations which embrace and value their QFD experience. This is a setback for the partisans in that particular area of the firm, and more time is lost until a new provocateur emerges.

In each of these cases, software organizations were faced with a new and powerful method: Software QFD. In all cases the initial champions within the organizations had limited knowledge of QFD and faced unique challenges in implementing it in their organization. All three organizations "succeeded" in implementing QFD in the view of those who initially brought it into the organization. All three have now reached a plateau, where further progress appears to require that they change their implementation approach.

How to Implement Software QFD

How you implement Software QFD depends on a number of factors. Where is the highest "QFD Champion" in the software organization? Has there been any exposure to QFD in other areas of the company, or by managers who came from other organizations? Are competitors using QFD to good advantage? (That is what drove the North American automotive community quickly and deeply into QFD in the mid-1980s.) How many project teams are just starting a development or enhancement project, and how many would volunteer to try QFD? Is there an accepted software engineering process (also known as a methodology, or system development life cycle)? Are software engineering analysis and design activities done according to current best practices? How are project managers trained? What is their authority? What tools do they use?

All of these issues, and more, answer a number of questions:

• Who needs to know what about QFD so that we can get started?

• What projects should pioneer QFD? (More than one is highly recommended.)

• Where do you start with QFD? (The "House of Quality" is not the best place to begin for software.)

• When do you start using QFD on a project? (It's nice to start at the beginning, but much value can be gained by applying QFD to a project already underway.)

• How do you start with QFD? (What combination and sequence of training and consulting are required?)

• How much QFD should you use on your first project? (You will not be able to do "all of QFD" on a first project.)

It is also important to understand why the organization is considering QFD, so the decisions on the aforementioned issues result in a positive final assessment of the pioneer QFD projects.

By examining the experiences of some of the software organizations that have pioneered QFD in North America, we can learn to reduce the initial effort required and increase the rate of success.