DFTS Implementation Framework


This chapter presents the DFTS implementation framework as a 15-step process, as shown in Table 5.1.

Table 5.1. DFTS Implementation Steps

Step #

Description

1.

Creating management awareness and buy-in

2.

Communicating top management's commitment

3.

Recognizing pitfalls

4.

Laying philosophical foundations for a quality-focused enterprise

5.

Building the organizational infrastructure

6.

Understanding roles and responsibilities of the key players

7.

Designing a supportive organizational structure

8.

Establishing an effective communication system

9.

Creating an appropriate reward system

10.

Establishing a Cost of Software Quality (CoSQ) reporting system

11.

Planning and launching organization-wide learning

12.

Implementing the DFTS process

13.

Monitoring and feedback for learning and improvement

14.

Freezing improvements and gains

15.

Integrating and expanding the initiative


The DFTS implementation model, shown in Figure 5.1, is a four-phase PICS framework consisting of Plan, Implement, Control, and Secure. The first ten steps relate to planning, Steps 11 and 12 represent implementing, Step 13 controlling, and Steps 14 and 15 securing. The framework emphasizes the importance of planning to prepare the organization for this major initiative. The time and resources committed to sound planning are essential and invariably pay off in successful outcomes. Even organizations with an established quality culture will do well to go through this process step by step. It provides an opportunity to address issues that are not always obvious. It is a systematic methodology for not only implementing the initiative soundly but also for sustaining it long-term and continually improving it. The two feedback loops provide opportunities for learning, corrective measures, and continual improvement. The framework consists of a variety of tools, systems, and models that constitute the subject of this book.

Figure 5.1. The PICS Implementation Model


The implementation framework can be customized for particular software development contexts. A powerful feature of this framework is that it helps you understand evolving and changing user needs throughout the development process (see Figures 5.6 and 2.6).

The feedback loops also provide updates for continual product and process improvements. The 15 steps are described next.

Step 1: Creating Management Awareness and Buy-in

This is obviously the essential first step. Nothing this significant can be undertaken successfully unless the top management team understands the initiative's business values. The business values most easily grasped by the CEO and top management team often relate to cost reduction, bottom- and top-line growth, market share, and Return on Investment (ROI). Often they are interested not only in DFTS's long-term promise but also in what it delivers in the short term. This is especially true of publicly traded corporations, where the CEOs cannot ignore financial returns beyond a few quarters. This may be a serious impediment to quality initiatives.

The initial interest is usually instigated when the CEO or a member of the top management team becomes aware of DFTS, either from an industry colleague, an academic, or a software professional. Whatever the source of the initial idea, any follow-up depends entirely on the top management team led by the CEO buying in. It happens only if DFTS's potential to create business values involving significant improvements in cost, cycle time, and expanded business opportunities is clearly grasped. This process takes place over a series of formal and informal meetings involving the CEO, the top management team, and, often, other business contacts and consultants.

The DFTS implementation process is essentially an exercise in corporate leadership. Successful implementation depends largely on how well the CEO understands various social forces involved in the implementation process. The Force Field Analysis Model developed by Kurt Lewin[1] is a powerful tool to diagnose major social forces that could be in play when embarking on a DFTS initiative. Figure 5.2 shows some common restraining and driving forces in this context: The restraining forces identified here are fear of change, lack of skills, and peer pressure. The driving forces are incentives, training, management support, and addressing quality problems generally by focusing upstream. Theoretically, the desired changes may be attained by either increasing the driving forces or diminishing the restraining forces. However, it is desirable to introduce changes by strengthening the driving forces (see Figure 5.3) rather than diminishing the restraining ones. The secondary effects of opposing restraining forces often result in higher organizational tension. This may carry unacceptable dysfunctional consequences that may best be avoided.

Figure 5.2. The Force-Field Analysis Model: Driving and Restraining Forces of Change


Figure 5.3. Lewin's Three-Step Model of Permanent Social Change


The objective of the buy-in process is for the top management team to understand that trustworthy software creates not only immense customer value but also bottom-line, growth, and other opportunities for the business. The team may deliberate on major challenges involved in a DFTS initiative using Lewin's twin modelsthe Force Field Analysis Model and the Three-Step Model of Permanent Social Change, shown in Figures 5.2 and 5.3, respectively. If the decision to go ahead has been made, management must set some broad goals at this stage that are primarily customer-focused. Goal refinement can be achieved gradually through the implementation process. Any goal that emphasizes just the software developer's short-term cost or growth objectives is not likely to contribute to the development of trustworthy software. Start with customer in mind! Other objectives will inevitably follow.

At this stage, it may be best to set up a DFTS Steering Committee. This group is responsible for policy guidelines, preparing an implementation plan, mobilizing resources, and overseeing the overall implementation. If the organization already has an equivalent body, these tasks may also be assigned to it to avoid duplication. The committee should have five or six members. It should be chaired by the Vice President of Software Development or the Chief Software Architect and assisted by a DFTS Implementation Project Manager. The CFO, CIO, CTO, Chief Quality Officer (CQO), and Vice President of Human Resources should be the other committee members. We discuss their roles later in this chapter. Additionally, we strongly believe that the CEO should be not only a member of the committee but also an active participant. This is a powerful signal to other senior executives that DFTS is a big deal. The overall direction for the successful implementation can only be provided by the CEO, who should make sure that the committee is up to the task. It is important for the CEO to remain engaged, attend committee meetings regularly, and demand results.

The committee must immediately undertake two important tasks:

  • Assess any existing quality systems, resources, and initiatives within the organization with a view to preparing a DFTS implementation plan. This is part of organizational preparedness, as discussed in Chapter 20. Many valuable resources, ideas, and systems may already be available. For example, if a Cost of Software Quality (CoSQ) reporting system is in place, it could provide quite a jump start.

  • Prepare an outline plan and budget in consultation with the executives concerned and consultants, if any. This is essential to get things started.

It must be emphasized that the CEO and top management do not perceive DFTS as a program to be implemented. It should be thought of more as an initiative undertaken, and then continuously improved as an ongoing process, perfected, and finally expanded and integrated with the rest of the organization. Following that, other quality improvement opportunities might require new initiatives as the organization evolves. "A target to be achieved" or "a program to be completed" mind-set often leads to burnouts and frustrations even if the "program" is successful. As Deming says, quality management requires "constancy of purpose" and should be an integral part of an organization's business process. The senior management team should be active participants in the process rather than being mere observers and auditors. In Toyota, when the president of the company comes to a training session, he has come to learn the role he has to play rather than attending merely as an observer or a ceremonial figurehead. At General Electric, Jack Welch brought similar commitment to Six Sigma. This level of involvement can be powerful and makes a huge difference. The CEO and senior management team must grasp this reality early in the process.

Step 2: Communicating Top Management's Consensus and Commitment

After the top management team has been sold on the value of DFTS and has decided to proceed, it is important to build consensus and communicate it organization-wide. The CEO should communicate the decision to launch the DFTS initiative, its rationale, and its broad objectives and expectations. Such a communique should also mention the creation of the steering committee and its membership. All those who are crucial to the initiative's success should not only understand its benefits but also be its vocal champions. This process of building consensus should be actively led by the CEO, or it runs the risk of being sabotaged. At this stage, there may be noticeable or subtle resistance that must be addressed. A clear communication plan should involve the whole organization so that people clearly understand what's being initiated and how both they and the organization will benefit from it.

Step 3: Recognizing Potential Pitfalls of a DFTS Initiative

Examining and understanding the potential pitfalls of a DFTS intervention is an extremely valuable exercise. It provides a cost-effective opportunity to foresee what could go wrong and how to avoid these potential problems. We strongly believe that this exercise should be carried out by the senior management team before the initiative begins. It should not be avoided, because a failure of even a pilot project can be fatal for the initiative's overall success. The following sections discuss some of the most common pitfalls.

Lack of Management Support

DFTS is a major corporate initiative. As such, it depends particularly on the involvement and enthusiasm of the CEO and the senior management team for its successful execution. It offers the potential for breakthrough results but can easily be derailed by lack of leadership support. The corporate world is ever abuzz with stories of countless failures of otherwise-sound initiatives, such as TQM, BPR, Lean Enterprise, and, of late, Six Sigma and DFSS. For every successful implementation, numerous cases of failures exist. The single most significant cause of such failures is lack of CEO support. Behind every successful initiative, on the other hand, has been a CEO who believed in it, communicated it with the organization as a whole, made the needed resources available, and provided unwavering support and enthusiasm throughout. Clearly, successful deployment of a DFTS initiative calls for similar commitment and support on the part of management. Often the CEO and the senior management team underestimate the time and commitment required for such initiatives. The vital role the CEO plays can hardly be overemphasized. We discuss this further later in this chapter.

Middle Management Antipathy

In spite of delayering and downsizing in recent years, middle management remains a vital building block in the organizational pyramid. These managers are known by a range of designations, from vice presidents, directors, general managers, senior managers, project managers, and supervisors to simply managers, or all of these, depending on the organization's size. In recent years, middle managers have been given additional appellations such as sponsors, champions, black belts, and master black belts, representing their roles and responsibilities in quality initiatives such as Six Sigma and DFSS. Whatever their titles or position in the hierarchy, middle managers play important roles throughout the DFTS process. There are several reasons for middle management antipathy. They may not understand the DFTS process, they have not been sold on its value, they do not believe that the CEO and top management are serious about it and will provide the needed support and resources, they may have had a bad experience in the past, or they are insufficiently motivated to embrace the change because they do not have a personal stake in its success. All this invariably leads to reluctance, fear, and antipathy that may be fatal for the initiative.

Empty Quality Slogans

Often organizations indulge in slogans and catchphrases as motivating and cheerleading doodads. These simplistic exhortations create the wrong impression about the hard tasks and challenges involved in a quality initiative. They can be especially frustrating if the slogans do not reflect the volume and complexities of the tasks involved. Such slogans become inevitable if the initiative is driven by the desire to win an external award rather than produce measurable results. Empty slogans can, in fact, be the only result if the quality initiative is not integral to the enterprise's day-to-day operations. Only when an organization is free of such slogans can it identify real challenges, address them meaningfully, and begin to communicate them effectively and credibly with the various stakeholders. Deming strongly advises against such meaningless buzzwords: "Eliminate slogans, exhortations, and targets for the workforce that ask for zero defects and new levels of productivity. Slogans do not build quality systems." See point 10 in Table 5.2. (Tables 5.2, 5.3 and 5.4 are Zultner's adaptations of Deming's "14 Points," "Seven Deadly Diseases," and "Obstacles to Quality" to software context.)

Table 5.2. The Fourteen Points for Software Managers[2]

1.

Create constancy of purpose for the improvement of systems and service, with the aim to become excellent, satisfy users, and to provide jobs.

2.

Adopt the new philosophy. We are in a new age of software engineering and project management. Software managers must awaken to the challenge, learn their responsibilities, and take on leadership for change.

3.

Cease dependence on mass inspection (especially testing) to achieve quality. Reduce the need for inspection on a mass basis by building quality into the system in the first place. Inspection is not the answer. It is too late and unreliableand does not produce quality.

4.

End the practice of awarding business on price alone. Minimize total cost. Move toward a single supplier for any one item or service, making them a partner in a long-term relationship of loyalty and trust.

5.

Constantly and forever improve the system development process, to improve quality and productivity, and thus constantly decrease the time and cost of systems. Improving quality is not a one-time effort.

6.

Institute training on the job. Everyone must be well trained, as knowledge is essential for improvement.

7.

Institute leadership. It is a manager's job to help their people and their systems do a better job. Supervision of software managers is in need of an overall, as is supervision of professional staff.

8.

Drive out fear, so that everyone may work effectively. Management should be held responsible for faults of the organization and environment.

9.

Break down barriers between areas. People must work as a team. They must foresee and prevent problems during systems development and use.

10.

Eliminate slogans, exhortations, and targets for the work force that ask for zero defects and new levels of productivity. Slogans do not build quality systems.

11.

Eliminate numerical quotas and goals. Substitute leadership. Quotas and goals (such as schedules) address numbersnot quality and methods.

12.

Remove barriers to pride of workmanship. The responsibility of project managers must be changed from schedules to quality.

13.

Institute a vigorous program of education and self-improvement for everyone. There must be a continuing training and education commitment to software managers and professional staff.

14.

Put everyone to work to accomplish the transformation. The transformation is everybody's job. Every activity, job, and task is part of a process. Everyone has a part to play in improvement.

Copyright © 1988 by Zultner & Co. Reprinted with permission.


Table 5.3. The "Seven Deadly Diseases" of Software Quality3

1.

Lack of constancy of purpose to plan systems that will satisfy users, keep software developers in demand, and provide jobs.

2.

Emphasis on short-term schedulesshort-term thinking (just the opposite of constancy of purpose toward improvement), fed by fear of cancellations and layoffs, kills quality.

3.

Evaluation of performance, merit rating, and annual reviewsthe effects of which are devastating on individuals, and therefore, quality.

4.

Mobility of software professionals and managers. Job hopping makes constancy of purpose, and building organizational knowledge, very difficult.

5.

Managing by "visible figures" alonewith little consideration for figures that are unknown or unknowable.

6.

Excessive personnel costs. Due to inefficient development procedures, stressful environment, and high turnover, software development person-hours are too high.

7.

Excessive maintenance costs. Due to bad design, error ridden development, and poor maintenance practices, total lifetime cost of software is enormous.

Copyright © 1988 by Zultner & Co. Reprinted with permission.


Table 5.4. The Obstacles to Software Quality[3]

1.

Hope for instant solutions. The only solution that works is knowledgesolidly applied, with determination and hard work.

2.

The belief that any new hardware or packages will transform software development. Quality (and productivity) comes from people, not fancy equipment and programs.

3.

"Our problems are different." Software quality problems aren't uniqueor uncommon.

4.

Obsolescence in schools. Most universities don't teach software qualityjust appraisal techniques.

5.

Poor teaching of statistical methods. Many software groups don't have good statisticaloriented training in quality or project management.

6.

"That's good enoughwe don't have time to do better"but time will be spent later to fix the errors. Doing the right things right the first time (and every time) is fastest.

7.

"Our quality control people take care of all quality problems." Quality is management's responsibility, and cannot be delegated. Either management does it or it does not happen.

8.

"Our troubles lie entirely with the programmers." Who hired the programmers? Trained them (or not)? Manages them? Only management can do what must be done to improve.

9.

False starts with quality (and productivity). Impatient managers who don't understand that quality is a long term proposition quickly lose interest.

10.

"We installed quality control." Quality is a never-ending task of management. Achieve consistency (statistical control)then continuously improve.

11.

The unmanned computersuch as CASE package used without solid knowledge of software engineering.

12.

The belief that it is only necessary to meet specifications. Just meeting specifications is not sufficient. Continue to improve consistency and reduce development time.

13.

The fallacy of zero defects. Constant improvement does not end with zero defects (all specs met). The mere absence of defects is no guarantee for user satisfaction.

14.

Inadequate testing of prototypes. The primary purpose of testing prototypes is to learnand then apply that knowledge to a robust production system.

15.

"Anyone that comes to help us must understand all about our systems." Software managers may know all there is to know about their systems and software engineeringexcept how to improve.

Copyright © 1988 by Zultner & Co. Reprinted with permission.


Lack of Team Cohesiveness

Organization-wide quality initiatives such as DFTS can be marred irreparably for lack of team cohesiveness. The need for team cohesiveness is profound both within and across various software development teams. Software design and development, especially in large projects such as enterprise software, is a uniquely team-based process. Creating an organization that embraces inherent change with one voice and as a committed team is a challenging task and can hardly be overestimated.

Wrong Implementation Strategies

Wrong implementation strategies can be fatal for a quality initiative. Three strategic issues must be addressed diligently:

  • Strategic clarity

  • Scope of the initiative

  • "Buy or build"

Strategic Clarity

Management may not have thought through the initiative's strategic rationale. It may not have addressed some basic questions, such as the following: Are the current processes firstrate? Can they meet customer requirements consistently? Are we actually listening to the customers? How are our quality, cost, and cycle time vis-à-vis customer expectations? How do these compare with competitors' products and services? Finally, how would the proposed initiative help us enhance customer satisfaction and improve our competitive situation, market share, and the bottom line? In the absence of such analyses, it's difficult to provide commitment, justify resources, and extend support in a sustainable manner. It's critical that not only the top management team but also the board should deliberate these issues and be totally supportive. Decisions resulting from these deliberations must be unequivocal. For corporations that have done their homework, these initiatives have clear strategic value. Many companies, such as General Electric and Caterpillar, are not only implementing Six Sigma and DFSS throughout the organization but also are involving their customers and suppliers in their Six Sigma initiatives, thus extending them further in the supply chain (see Table 5.5). Among Japanese corporations, it's a common practice to engage suppliers in the firm's quality initiative. Failures of many initiatives can be traced to the absence of a raison d'etre. Often, external factors such as awards, certificates, or public relations, not an actual business need, drive a quality initiative. It's impossible to sustain such an initiative if external factors do not create genuine value for the business. Furthermore, even great initiatives must be integrated with the organization's day-to-day work and not be mere add-ons. Toyota's quality management system, for example, is simply known as the Toyota Production System and has become a way of life for the corporation's operations worldwide.

Table 5.5. Implementation Strategies for a Software Quality Initiative

Strategy

Pros

Cons

Incremental

Avoids organization-wide risk

Less disruptive and risky

Opportunity to perfect the process on a small scale

Mistakes are contained

May compete with current practice

Organizational politics and resistance to change may result in suboptimization

One project failure may derail the whole initiative

Overall cost may be higher

Opportunity for transformative results may be lost

May not get top management's attention

Concurrent

Focuses on one approach improves the odds of eventual success

Less resistance to change

Cost and time savings

Transformative and faster results

Benefits from top management's attention and support

Risky if the initiative is inappropriate or is not managed well

May be disruptive if not planned and executed well

The opportunity for debugging on a smaller scale is lost

Errors and wrong practices may be cumulative

Staggered incremental

Planned for organization-wide implementation but introduced incrementally

Avoids organization-wide risk

Less disruptive and risky

Opportunity to perfect the process on a small scale

Mistakes are contained

Opportunity for debugging on a smaller scale

Greater chances of success than with the other two

May still produce transformative results

May compete with current practice

Organizational politics and resistance to change may result in suboptimization

One project failure may derail the whole initiative

Opportunity for transformative results may be lost

May not get top management's full attention

May take much longer than concurrent implementation


Scope of the Initiative

"What should the scope of the initiative be? How deep should it be? Will we deploy a single quality system such as DFTS or an integrated system that includes Six Sigma and the Capability Maturity Model (CMM)? Will we address just software development issues, or will we include transactional processes such as recruitment, marketing, and billing? How wide will the implementation be? Will it be deployed divisionally or enterprise-wide? How should the new initiative be introduced: as a pilot project, on a one-project-at-a-time basis, or enterprise-wide concurrently? What are the trade-offs?" These may seem like perennial questions, but they have important implications and must be addressed. The reasoning for pilot-project incremental deployment is that it provides an opportunity for experimentation, learning, and debugging. It also eliminates the risks of costly mistakes if the initiative is inappropriate. Its downside is that it sends a mixed signal that management is not fully committed, and the existing practice may be reverted to, or some other alternatives may be explored. This may be fatal for the new initiative. Resistance to change may be more entrenched and costly in terms of time, cost, and morale. It may also lead to a situation of two practices competing for resources and attention. This often leads to unwarranted rivalry between the two teams, two agendas, and two sets of development methodologies. Such a situation does not bode well for the new initiative. The alternative to a pilot project is an enterprise-wide concurrent implementation. This may be especially challenging in large organizations and calls for careful planning. In spite of the common belief that this is the norm for successful interventions, many successful quality initiatives have started on a divisional basis or a subsidiary level and gradually expanded to include the rest of the organization. This includes General Electric, DuPont, and Motorola. Caterpillar, on the other hand, introduced Lean, Six Sigma, and DFSS across 110 manufacturing facilities in 24 countries worldwide concurrently. In fact, it was the first company to launch Lean, Six Sigma, and DFSS in all business units simultaneously. Caterpillar is now also committed to helping its suppliers.

The common denominator for successful interventions is the commitment of the top management teameither concurrently or incrementallyacross the organization as a whole. Some corporations, like GE, given their sheer size, have introduced Six Sigma and DFSS, but one initiative at a time, incrementally. The initial focus was on manufacturing activities. Service activities were included only later, where the opportunities are even greater. Jack Welch has often regretted not introducing DFSS and Six Sigma for service activities earlier than he did. The current trend is to go for all-inclusive, organization-wide initiatives that include both manufacturing and service activities. Typically, companies go for one initiative, such as Six Sigma or DFSS, at a time. But Caterpillar, as just stated, introduced Lean, Six Sigma, and DFSS concurrently.

In an enterprise software context, where projects tend to be large, it may be just fine to introduce DFTS on a new software development project and gradually expand it to all incoming projects. There is an alternative to incremental and concurrent approaches; we call it the staggered incremental approach (see Table 5.5). Here management has decided on an organization-wide implementation, has a clear plan to that effect, and introduces it incrementally as appropriate. What's important is that management knows the initiative's business value and has a clear plan for the organization as a whole. This conveys an unmistakable message: "This is what we will do; there's no turning back."

"Buy or Build"

This deals with the issue of whether the expertise for initiating and implementing the quality initiative should be outsourced or provided internally. Most companies in the West have sought outside help in their Six Sigma and DFSS initiatives. Also, all of them seek knowledge transfer and build internal capabilities to sustain these initiatives or expand them further following initial outside help; this is called buy-to-build. The most notable exception is Motorola, the inventor of the Six Sigma methodology, which did everything internally. Many companies, such as General Electric, Motorola, and Honeywell, have developed a high degree of internal competence and now not only drive these initiatives internally but also offer these services to their suppliers, customers, and other potential clients. It may be sensible to go for buy-to-build to jump-start the process and build internal competencies concurrently. "Do it yourself" doesn't always work. General Electric reaped returns of $7.1 billion over five years since its Six Sigma initiative was launched in 1996.[4] However, Xerox's tentative Lean and Six Sigma initiatives since the late 1990s produced only modest results and had to be relaunched in 2003.[5] Competent consultants not only enhance the speed of execution but also bring cross-industry best practices. In addition to creating competitive value, speed and robust deployment are crucial for successful implementation. The extent of initial outside help is contingent on the organization's needs and should be customized accordingly. It's critical to make knowledge transfer and help with building internal capabilities part of any outsourcing engagement. Although considerable cost savings may result, the overriding reason for outsourcing is not one of cost; it's more a question of effectiveness. As Peter Drucker said, "Most look at outsourcing from the point of view of cutting costs, which I think is a delusion. What outsourcing does is greatly improve the quality of the people who still work for you."[6]

Inadequate Reward and Incentives for Change

One major reason quality initiatives fail is an inadequate reward system. Deming has stated clearly on this issue, "Evaluation of performance, merit rating, and annual reviews...are devastating on individuals, and therefore, quality" (see point 3 in Table 5.3). Individual rewards have three negative consequences for quality. First, they undermine teamwork, which is crucial to quality, especially in team-based processes such as enterprise software development. Second, they may encourage short-term goal orientation. Third, they deprive the participants of pride of ownership for a job well done. This topic is discussed further in the section "Step 9: Creating an Appropriate Reward System."

Wrong Success Indicators

Quality initiatives must drive desirable results. It's important that the key objectives and success metrics be correctly identified. These objectives are based on customer requirements, not just the internal organizational goals. Wrong indicators can lead to wrong decisions and can disrupt a quality initiative. In a DFTS methodology, for example, upstream costs typically are higher than in traditional software development systems. The higher initial cost shouldn't bear an adverse judgment on DFTS, because it optimizes overall life-cycle costs.

Wasting Resources on Inconsequential Issues

Often quality initiatives become bureaucratic, paper-driven instruments that are of little relevance to the business. Many quality initiatives document every processeven those that may never be used. Thus, they become cumbersome and expensive, with little quality value. This issue must be addressed carefully.

Failure of Communication

In any major corporate initiative, effective communication is absolutely crucial for a successful implementation. A communication plan should take into account the diverse information needs of various stakeholders; a "one-size-fits-all" approach does not work. The section "Step 8: Establishing Effective Communication" discusses elements of a communication system and roles of various players in the communication process.

Inadequate Training

The importance of training cannot be overemphasized in a DFTS initiative. It's the basis for acquiring best practices and value creation. A learning organization develops the capacity of "generative learning."[7] This means being able to deal continually with changing customer needs and market and competitive environments. The learning should therefore include creative thinking as well as problem solving at all levels of the organization. Furthermore, training and learning should include everyone, including the top management team. The training content and objectives, however, must be differentiated according to the participants' roles and responsibilities.

No Clue About Costs

Finally, the worst offense is failing to measure cost savings correctly. When this is the case, it becomes difficult to justify ongoing costs. Therefore, it's an excellent idea to establish a cost of poor quality (CoPQ) system in any organization that is serious about quality management. (See Chapter 4 for details on CoPQ.)

Sidebar 5.1: Virtuous Teaching Cycle and TPOV

Training and teaching have played a crucial role in GE's massive Six Sigma deployment. Tichy characterizes GE's Six Sigma program as a "Virtuous Teaching Cycle" where teacher and learner roles are intertwined. The roles get continually reversed and enhance learning: "The Six Sigma program is a Virtuous Teaching Cycle, with the black belts teaching quality tools to the workforce, who then use them to generate new ideas and, in turn, teach the black belts."[8]

The "Virtuous Teaching Cycle" can be a powerful instrument of change and leadership development and can be established in any organization where leaders have strived to develop a "Teachable Point of View" (TPOV). Jack Welch saw the virtue of teaching and its potent role in leadership development. He taught at GE's Crotonville Leadership Development Institute throughout his stint as its CEO for two decades. Tichy describes General Electric's as the world's largest teaching infrastructure: "More than 15,000 high-potential middle managers are assigned for two full-time years as 'black belt' teachers of Six Sigma. They are teaching all 300,000+ employees at General Electric and leading over 20,000 Six Sigma projects." The other elements of the teaching infrastructure are quarterly Corporate Executive Council (CEC) meetings, Work-Out program, Change Acceleration program, Crotonville Leadership Development Institute, and GE Operating Mechanism.[9]

Source: Noel M. Tichy, The Cycle of Leadership, HarperBusiness, New York, 2002.


Step 4: Laying Foundations for a Quality-Focused Enterprise

We have witnessed with distress how certain enterprises go about their quality initiatives. Certain gimmicks are downright laughable, like the CEO of a company on the verge of financial collapse talking about a TQM initiative. It's also important to understand that major quality initiatives can be successful only in a stable climate that is free of immediate risks. Another annoying stunt that we recall pertains to a TQM initiative launched as part of a corporation's centennial celebration. In both cases, the CEOs and the senior management team had not invested enough time and commitment. Both the initiatives perished and might have left bad legacies in their wake. This kind of amateurish approach to quality does much harm to meaningful initiatives later. Organizations embarking on major quality initiatives need strong, shared beliefs to which everyone can relate. "Why do we need to embark on this journey?" must be answered.

Deming sought a major transformation of Western management practice in his book Out of the Crisis.[10] (See also Tables 5.2, 5.3, and 5.4 for Zultner's adaptation of Deming's philosophy: "14 Points for Software Managers," "The Seven Deadly Diseases of Software Quality," and "Obstacles to Software Quality.") It can help tremendously in the successful implementation of a DFTS or other quality initiatives. A practical framework for implementing Deming principles is discussed next.

Awareness of Shortcomings of Current Practices

The organization might want to start by organizing a one-day seminar to discuss its current practices for customer satisfaction and product and process development capabilities. Adequate preparation is absolutely crucial so that the seminar discussion is based on a real assessment of the organization's quality challenges. It may be a good idea to seek help from a competent facilitator to help prepare for the seminar. As with any major issue, CEOs play a crucial role in leading such seminars. For the seminar to be successful, they understand the issues, have discussed the implications with the key lieutenants, and bring their commitment and energy. The key to a positive outcome is solid preparation and prior consultation among the senior management team. That's why you need a competent facilitator. We have seen too many corporate seminars on quality turn into a benevolent but detached discussion of everything under the sun. Quality-related issues should be deliberated just like any other important business function, such as finance and marketing, and the CEOs and senior management team should have a clear outcome in mind. In such cases, CEOs very often know or determine the outcome of such conferences. This is not to suggest that the discussions are phony. Only such results-oriented meetings led by the CEOs will bring to light real issues with a view toward addressing them. People will act real because the stakes are high. Such a results-oriented approach to quality is typical of Japanese organizations, in which the CEOs lead the process.

The facilitator works closely with the CEO and the top management team and prepares them for the seminar. A great deal of consensus will be built before the formal seminar. The morning session could start with a presentation on the cost of quality, yield, cycle time, and return and warranty costs if a formal CoSQ is already established or if such data is available. This may be followed by a presentation of Deming's principles, particularly The 14 Points, Seven Deadly Diseases, Obstacles to Quality (see Tables 5.2, 5.3, and 5.4), and a discussion of possible causes. The identified causes may very well resemble the "diseases" and "obstacles." Such a discussion may also reveal some additional obstacles to quality, such as the following:[11]

  • Hope of instant pudding

  • Asking for quantification of every improvement

  • Search for examples elsewhere

  • "Our problems are different/our culture is different"

  • Poor teaching of statistical methods

  • "We installed quality control"

  • Specifications and the fallacy of zero defects

  • Inadequate testing of prototypes

An honest discussion will help identify real issues and how they relate to Deming's teachings, a consensus on their meanings, and implications for the organization.

Contemplate and Adopt Deming's Teachings

The afternoon session could focus on adopting Deming's teachings and identifying the new challenges and responsibilities. Honest discussion leads to shared ownership and pride. The CEOs again play a crucial role. They lead the discussion and want a meaningful outcome. They may choose to announce major decisions such as the appointment of a senior corporate executive as Chief Quality Officer (CQO) and the setting up of a Corporate Quality Council (CQC) consisting of the senior corporate officers. The message that the top management team is committed to quality helps build credibility. The operational responsibility for implementation should be with the CQO.

Organization-Wide Consultation and Communication

After the decision to implement Deming has been made, the rest of the organization should be consulted through a series of seminars and other forms of communication. People should be genuinely consulted rather than just informed. This will help gain acceptance for the initiative, channel valuable ideas, and enhance motivation. Rushing to implement without consultation across the organization is often costly in terms of time and effectiveness.

Plan and Implement Deming's Principles

Although Deming's teachings often seem to be common sense, a closer look reveals that his philosophy is a major departure from contemporary management practice in the West. Appropriate integration with DFTS methodology must be carried out if the implementation is part of a DFTS initiative. The plan should clearly identify responsibilities, milestones, datelines, and monitoring and appraisal mechanisms. It should also identify potential pitfalls, countermeasures, and incentives for change across the organization. Successful implementation of the change process requires considerable time and attention on the part of the top management team. Its challenges can hardly be overestimated. Only the strategy of permanently securing the new level can ensure that the organization will not revert to old ways. This requires cultivating new attitudes, behavior, and skills by deploying various interventions such as training and a reward system. There are numerous examples of organizational life gravitating back to old ways after the "shot in the arm" effect of the initial thrust is gone.

A successful change is carried out in three steps (see Figure 5.3, shown earlier):

1.

Unfreezing the present level (gaining acceptance for the need to change)

2.

Moving to the new level (putting the needed changes into effect)

3.

Freezing the new level (consolidating the changes to guard against reversion)

The essentials of Deming's philosophy can be grouped into three broad issues:

  • Management's commitment to quality (points 1, 2, and 14 in Table 5.2)

  • Application of fact-based (statistical) methodology (points 3, 5, 6, and 13 in Table 5.2)

  • Improve teamwork and be customer-responsive (points 4, 7, 8, 9, 10, 11, and 12 in Table 5.2)

Deming's approach is not a program; it's a philosophy and a system of management. If it's initiated with genuine management support, it will build the foundations of a high-performance organization. Recent quality movements such as Six Sigma and DFSS have tended to touch on Deming as a historic reference and emphasize just the tools and methodologies, such as DMAIC and IDDOV. Effective use of tools can certainly help in individual process improvement and problem-solving, but it can hardly suffice in creating irreversible change and transformative leadership. In the absence of the sound anchoring that Deming's philosophy provides, it is all too easy to revert to old ways. This happens often with a change in leadership, during emergencies, and following temporary setbacks. Several models exist for building transformative organizations. Use them if they work for you. We believe that Deming's model is inherently sound, practical, and time-tested. It can help you lay the foundation for a quality- and customer-driven enterprise. DFTS can deliver truly transformative results only in such organizations. The basic requirement is a change in people's thinking.

Step 5: Building the Organizational Infrastructure

A supportive organizational infrastructure is crucial for a successful DFTS implementation. The following are the key elements:

  • Quality of leadership

  • Strategic planning

  • Operations and process management

  • Management information system

  • Accounting and financial management

  • Human resources management

It is beyond the scope of this book to delve deeper into these issues. Corporations such as Toyota and GE, which have benefited enormously from various quality initiatives, have had excellent organizational infrastructures and best practices in place. The need for a strong organizational infrastructure cannot be overemphasized for a DFTS initiative.

Step 6: Understanding the Roles of the Key Players

DFTS is a transformative process that involves the organization as a whole. The following sections discuss the roles of certain key personnel in implementing and sustaining DFTS. It is possible to combine certain roles, depending on the organization's size and structure and other contingencies. The following key roles and responsibilities identify the leadership challenges in a DFTS process.

Role of the CEOs

The role of the CEOs in a successful implementation of a major quality initiative such as DFTS can hardly be overemphasized. Lack of CEO support will most definitely result in failure. The following are the key roles that the CEOs play in a DFTS initiative:

  • Provide unfailing leadership. CEOs must be the driving force of DFTS. They must, above all, create a sense of ownership and pride in what is being initiated. They recognize that to attain great results the organization as a whole must not only possess technical and leadership skills but also live the DFTS quality philosophy in letter and spirit. They understand that Deming's quality philosophy is essential in such an endeavor and that it requires a new way of looking at things.

  • Ensure involvement of senior management. It's absolutely critical that the CEOs take their senior management teams into their confidence and ensure that they understand the business stakes in the DFTS initiative and support it enthusiastically. The CEOs know that any transformative change requires everyone in senior management to support it. They make that possible by making it absolutely clear that the change is a requirement, that there is no going back to old ways, and that everyone must be onboard. They communicate this with clarity and conviction. Either the CEOs do it, or it doesn't happen.

  • Appoint a senior executive to oversee the implementation process. Appointing the right person to be the CQO may be the CEOs' single most important decision as far as DFTS's eventual success. The person selected must be business-savvy and possess leadership qualities to help implement the DFTS process. He or she will be responsible for the overall quality of the organization's products and services. The CQO reports directly to the CEOs and works in close consultation with them.

  • Chair the CQC. The CEOs should be active participants in the quality process. They should chair the CQC and provide leadership for the initiative through this and other forums as required. The CEOs should also lead the DFTS steering committee. Many corporations also have corporate board committees on quality in which the CEOs must lead as well. Their message and support must be unwavering and well-communicated throughout the organization.

  • Provide resources and unwavering support. The CEOs ensure that financial and personnel resources are made available in a timely manner. They make sure that the most talented people are brought in to launch and lead the initiative. They must talk about it earnestly and enthusiastically whenever possible. In a successful quality initiative, the CEOs become its chief spokespersons. They are genuine, enthusiastic, and direct.

  • Insist on training and continuous learning. The CEOs should understand the value of training across the organization for the success of the DFTS initiative. They need to undergo appropriate training covering both leadership and technical aspects of the initiative. The CEOs also ensure that their top management team undergoes training. They should be enthusiastic about learning and may conduct certain seminars themselves and teach important issues (see Sidebar 5.1). CEOs finding the time to train and teach sets a great example in a learning organization, especially for the black belts (BBs) and master black belts (MBBs). In a software development enterprise, training should be less differentiated because the organizational hierarchy itself is likely to be less differentiated. CEOs and the top management team must understand the DFTS process in its entirety. It will be great asset if they have undergone the black belt training. CEOs and members of their senior management team who are likely to be in concept development and high-level design should undergo black belt training.

  • Provide appropriate incentives. The CEOs should understand that software development is a collaborative effort. As such, the reward system should reinforce teamwork in line with long-term objectives of the DFTS initiative, as opposed to traditional performance evaluations, merit ratings, and annual reviews (see points 2 and 3 in Table 5.3).

  • Simply be in charge. The CEOs must be aware of the enormous payoff from the DFTS initiative, be up-to-date with the progress, and be enthusiastic about its prospects. They have high expectations but should make sure that occasional setbacks do not derail the initiative. They should be seen as the initiative's principal proponents.

Role of the Corporate Quality Council

The role of the corporate council is crucial. It can become a forum for sharing information, making honest appraisals of progress, and creating much-needed top management team cohesiveness for successful implementation. The CEO should chair the CQC and should make sure its smooth and effective functioning becomes the standard by which other executives in the council manage their own DFTS teams. The CQC is responsible for all strategic and policy matters and plays the following crucial roles:

  • Crafts a quality vision. The CQC should be responsible for crafting the organization's quality vision. It should also state clearly whether and how the DFTS initiative confirms and contributes to realizing that vision.

  • Decides on introducing the initiative. Although the CEO may have initially made the first move and has the final say, the CQC must collectively and enthusiastically agree. It should also provide the rationale and go-ahead after an honest deliberation of its potential and challenges. Because DFTS requires commitment from across the organization, the CEO must ensure that the CQC understands the stakes involved and that the buy-in is honest.

  • Approves plans and budgets. The line managers prepare plans and budgets for the quality initiatives. The CQC should approve them only after careful and candid discussion of viability, cost, and benefits of the initiative.

  • Appraises progress. The CQC should be a forum where tough questions are asked and serious business conducted. All the participants should know this and come totally prepared. The CQC should be collectively accountable to produce desired results. Honest discussion of resultsgood and badshould be seen as a crucial part of the process. To fulfill this and other responsibilities, the CQC must meet regularlyat least once every quarter.

  • Provides support. The CQC and the senior managers as a team must provide steadfast support to the initiative and should be vocal about it. Furthermore, they should provide resources and show personal interest in the results on a regular basis.

Role of Chief Quality Officer

Chief Quality Officer (CQO) is an emerging position in many organizations where managing quality is considered essential to organizational success. Such organizations totally believe that quality must be led from the highest levels in the organization, and they live that premise in practice.

The CQO should be a member of the top management team, along with the CEO, CFO, CTO, and CIO, and other senior executives in charge of operations, marketing, and R&D. The decision to appoint a CQO should be made after careful deliberations at the highest levels and only after a clear need has been identified. The appointment itself should be made after the organization has embarked on a major quality initiative or is contemplating one. The CEO and the board of such organizations consider quality the primary building block. They do not seek cosmetic touch-ups but instead look for breakthrough and transformative results through quality. Quality is not seen as a problem to be fixed but as an enabling instrument for attaining corporate ambitions.

The CQO should be someone with great promise and a proven track record. Such a person should be a consummate software engineer with considerable experience with end-user needs as well as senior customer executives. This person should understand the value of software qualitynot only from the customer perspective but also from the standpoint of business success. The CQO needs to understand various quality management systems, but it's even more important that he or she possess leadership qualities. If the person does not possess technical skills of quality management, he or she may seek help from internal or external consultants as needed. The important thing is to learn quickly and be involved in the DFTS process.

Although the CQO primarily serves a leadership role, we foresee an emerging and pressing need for CQOs to be technically savvy as well. Many quality problems can be attributed to senior mangers lacking software development and quality management skills. In the future, more quality professionalsthose with MBB and BB backgroundswill be called on to undertake greater leadership responsibilities, including that of CEO. Jack Welch believes that future CEOs at General Electric will most likely be those who currently work as an MBB or BB. Their specific training and experience provide an excellent vehicle for developing future leaders within an enterprise. The CQO shouldn't be hired for just the DFTS initiative. After DFTS is successfully assimilated, the CQO should identify other quality challenges. This should be a permanent senior position vested with authority and resources. The CQO's major roles are as follows:

  • Help create strategic awareness about quality. The most important role of the CQO is to help create a quality vision and awareness about its strategic significance. Quality should be seen as crucial to business success and not as a problem to be fixed. This is no minor task; it requires a CQO who is respected as a leader and business-savvy. DFTS should be seen as part of an ongoing quality process geared toward helping organizations achieve their corporate ambitions.

  • Lead the change process. DFTS constitutes a major change in organizational practice. The CQO is the key change agent in this process. This person works closely with the Executive Champions (ECs) of the DFTS initiative. This often requires waking up the organization: no more of the same old practices. The organization must shed its tolerance for defects as a cost of doing business. Changing this mindset is formidable. The CQO must have a clear understanding of organizational politics and processes and be able to analyze the quality challenges and communicate them coherently. Above all, this person must be able to address and allay the fear that accompanies any major change. This role can best be played by a company veteran who has earned "capital" and staying power. If the only choice is to hire someone from outside, the person must have a proven record and must be given the required support by the CEO and the senior management team. They must want him or her to succeed.

  • Lead organization-wide learning. The CQO should work closely with the EC, human resources (HR), and consultants to devise an effective and relevant learning program in line with the organization's needs. The training should be organizationwide and differentiated. This learning includes senior executives, including the CEO.

  • Build a quality information system. DFTS relies on a culture of fact-based decision-making. Therefore, it's important that valid measures be available to initiate, manage, and appraise various activities, processes, and decisions. A range of customer and process-centric measures are needed that deal with cost, quality, and delivery schedules. Savvy quality professionals sense intuitively sound decisions and support them even if a valid measurement is not possible. Quality management often requires serious consideration of things that are unknown or unknowable.

  • Communicate effectively. The CQO should establish an effective and fact-based communication plan that is designed to inform and educate various constituents and thus strengthen the DFTS initiative. This topic is discussed further in the section "Step 8: Establishing Effective Communication."

  • Liaise with customers and outsourcing partners. Software development is becoming more like manufacturing in yet another sense: Customers may be end users or software developers themselves who have outsourced all or part of their software development activities. On the other hand, the software developers may outsource some of their activities to an outsourcing partner. This kind of supply chain in software development is now a common industry practice and may have a profound effect on software quality. It needs to be coordinated and integrated with the customer and supplier (outsourcing partner) software quality. DFTS CQOs and ECs should make sure that they have an adequate framework to address such issues.

  • Advise the CEO and the board. The CQO is the chief advisor to the CEOs and the board on quality matters. To do that, he or she must understand how the DFTS initiative fits into the larger scheme of things and how it will help the company attain its short- and long-term objectives. For this reason, many companies choose a seasoned company veteran to be the first CQO. This is probably smarter than hiring a quality professional from outside. CQOs may not be quality professionals themselves, but to be viable, such appointees must master the operational and strategic context of quality management quickly. They should clearly understand the benefits and strategic value of the DFTS initiative and how it can best be implemented, integrated, and expanded within the enterprise smoothly and profitably. They should also be able to advise on all policies and initiatives related to process improvement vis-à-vis competition and evolving customer needs and demands.

Role of DFTS Executive Champion

The Executive Champions (ECs) of the DFTS initiative are usually the executive heads of software development (variously known as Vice President/Senior Vice President of Software Development, Chief Software Architect, and so on). Having line responsibility for software development, they are better placed to fulfill the additional roles of EC. Thus, they are the principal process owner, internal customer, and beneficiary of the DFTS initiative. Being EC has little to do with being a cheerleader. It requires being a strong leader with staying power and conviction to stay the course. ECs provide the support system and motivation to the Project Leaders (PLs) and project teams. They work closely with CQOs, software PLs, and external and internal consultants to ensure that the whole initiative is conceived, planned, and executed flawlessly. Above all, they are accountable to produce results, rather than look for scapegoats at the first setback. ECs play the following crucial roles:

  • Provide implementation leadership. ECs understand the enormous value of DFTS as well as the challenges involved in its implementation. They motivate their team to embrace the change. They lead a team of PLs who, in turn, lead various software development teams. ECs address their concerns and help them with conflict resolution. They communicate with the CEOs and CQOs to ensure that the DFTS project teams have the necessary tools, training, and resources to do the jobwell. They are called on to play a political role of ensuring that organizational power and politics do not impugn the desired change and instead are channeled to help the process. They should possess qualities to steer through ups and downs.

  • Select talented people to be Project Leaders. ECs pick the most talented leaders to be the PLs. It is at this level that success is accomplished, one project at a time. ECs should be provided with BB and eventually MBB training. Another reason for MBB training for PLs in an enterprise software organization is that they often manage large projects in terms of team size, duration, and dollars. ECs along with CQOs must provide PLs with adequate support all through the implementation process. DFTS also provides an excellent opportunity to train future leaders for the organization as PLs and team members work together through various stages.

  • Organize learning. ECs understand that learning, teaching, and mentoring are essential aspects of improvement and change, and they prepare the organization as a whole for training and learning. They insist that the senior management team, including the CEO, sign up for adequate DFTS training. They also make sure that various project team members are trained to be BBs. In a typical Six Sigma or DFSS initiative in a manufacturing environment, team members are trained to be green belts (GBs), and the PLs are trained to be BBs. In a DFTS context, however, various members of the software development team work both within a team as well as individually. They should therefore be better equipped to understand and deal with quality challenges in a DFTS process. Hence, we recommend BB training for all the members of the project team. Furthermore, PLs should be trained to be BBs initially but should be provided with additional training and coaching rapidly so that they can transition to MBBs. They can then also assume mentoring and teaching responsibilities with greater confidence. The senior management team may undergo BB, MBB, or GB training as appropriate. In an enterprise software context, we recommend that senior software professionals undergo at least BB training, with the exception of CQOs, who should train to be MBBs. More advanced training for the senior executives will enable them to deal with the upstream phases of the DFTS process more competently (see Figure 5.4). This will also equip them to lead the overall DFTS initiative knowledgeably. As is well-known, most quality problems can be attributed to lack of top management competence and understanding quality issues. Therefore, top management learning DFTS is even more important. These issues are discussed further in Chapters 20 and 21.

    Figure 5.4. Form Versus Function in a Software Enterprise

  • Provide a strong support system. DFTS PLs and individual team members require adequate support from senior management, especially during the early stages of the DFTS implementation process. Glitches, unforeseen difficulties due to inadequate planning, or other problems may occur. DFTS is a major departure from the conventional software development process. It requires more time and resources at upstream stages (so that quality issues are addressed early rather than having to be fixed later). This requires a change in mind-set. There could be major frustrations if the ECs don't get it. They must understand the process and its eventual value and must be patient and provide steady leadership. The support system requires involvement, appraisal, mentoring, and adequate time and resources.

  • Liaise with customers and outsourcing partners. As stated earlier in this chapter, ECs along with the CQOs work with customers and outsourcing partners to address relevant quality issues. They make sure that these are dealt with within a framework that is consistent with the organization's DFTS philosophy. They develop long-term partnerships that provide an opportunity for mutual learning and support. The emphasis should be on upstream activities, prevention, long-term relationships, and customer needs.

  • Ensure management commitment to the quality philosophy. As senior executives with line responsibility, ECs make sure that DFTS is not perceived merely as a set of tools and techniques. They must emphasize Deming's teachings about the role of management (points 1, 2, and 14 in Table 5.1) and not resort to shortcuts and ad hoc measures that may jeopardize the initiative (see Tables 5.2 and 5.3). Successful ECs understand that the Deming management philosophy is meant to be a way of life and not a one-time intervention.

  • Help create a fact-based decision-making culture. Understanding the causes of variation and eliminating or reducing them is crucial to any sustainable quality management system. Such systems depend on a culture of statistical thinking and getting to the bottom of the source of variation, which often leads to the top management team. These must be addressed upfront rather than swept aside.

  • Emphasize the value of people and a team-based quality system. ECs understand that it's people who are at the core of quality management. As such, they emphasize the need to continuously improve skills and capabilities of people across the organization, beginning with the top management team. They understand the value of teamwork in software development. They should work tirelessly to break down barriers; drive out fear; eliminate meaningless slogans, arbitrary targets, and quotas; and improve relationships with customers and suppliers (see Table 5.2).

  • Liaise with the CEO and top management team. ECs make sure that the CEO, CQO, and other senior executives are duly briefed about the progress of the DFTS initiative, as well as its challenges. They are willing to take responsibility in case of setbacks and ask for help, if needed. They work with the top management team to ensure their continued support.

Role of Software Engineers (DFTS Black Belts)

Software engineers who work individually and those who are members of software project teams should be trained to be DFTS black belts. Their roles and responsibilities are broader and deeper than those of team members in a typical Six Sigma/DFSS project in manufacturing organizations. They require both leadership and quality management capabilities in addition to being technically skilled as software engineers. They must be able to develop trustworthy software individually and as members of project teams and be able to identify user requirements; conceive of and design robust software; and code, test, integrate, and maintain it. For a successful DFTS implementation and integration, the traditional roles of the software engineers should be broadened to include critical additional skills:

  • DFTS process competence: Software project team members should be savvy enough to understand the whole DFTS methodology rather than just the individual pieces of the development process they may be involved in at a given time. By understanding methodologies and tools such as QFD, FMEA, and Taguchi Methods, they can contribute more effectively at a particular stage of the development process, work without a glitch with those working upstream or downstream, and be moved across various stages if needed. Furthermore, with DFTS black belt proficiency, they are better equipped to work as members of a software development team and individually. In a software development team, the members are both its workhorses and technical experts.

  • Understanding and anticipating user requirements: This is a crucial requirement for developing trustworthy software. Software engineers should be able to converse with the system's users in terms of the application and inform them of the trade-offs among the various requirements that often conflict. This requires technical knowledge, critical thinking, and competence with tools such as TRIZ, QFD, and FMEA.

  • Leadership and interpersonal flair: Software engineers should be able to work in a team, coordinate their own pace with that of others, and possess communication and interpersonal skills critically needed in a software development environment.

  • Design and programming deftness: Software engineers should certainly be gifted as programmers, well-versed in data structures and algorithms, and fluent in several programming languages as required. They should also understand various design alternatives and their implications for meeting user requirements in their particular environments.

Role of Project Leaders (DFTS Master Black Belts)

Project Leaders (PLs) are the front-end leaders in a DFTS initiative. PLs lead a team of talented people who might have undergone DFTS training. The PL role in DFTS is essentially that of a leader who can extract the best from a group of educated and accomplished people who may or may not have the natural instincts to be team players. This leadership role can be challenging and requires a person who is a natural leader and who is proficient in software engineering, DFTS methodology, and project management.

PLs are the linchpin between the project teams and the senior management team, reporting to ECs. PLs should be able to work with these people and help shape project objectives. They also coordinate with marketing personnel and customers, as well as the CQOs and their team. The selection of PLs is a critical decision on the part of the ECs. As stated, PLs should be trained to be DFTS master black belts because they need technical expertise as well as leadership and DFTS process competence. PLs play a crucial role, especially in an enterprise software context, where the projects are large in terms of manpower, cost, and duration. Chapter 21 discusses the training needs of MBBs.

The preceding sections have described a variety of roles and responsibilities in a software organization embarking on a DFTS process. DFTS requires the organization as a whole to be up to the task. It needs the involvement and commitment of senior executives from supporting functions such as finance, HR, and sales and marketing. Certain responsibilities can be modified, enlarged, or combined, depending on the organizational contingencies. But every software enterprise, irrespective of its size and needs, must address the issues implied in these roles and responsibilities. One important difference in the DFTS system is the need for greater depth of process expertise among software team members, team leaders, and the executive management team. Hence, we have recommended more intense training and learning than is the case with equivalent DFSS training in a manufacturing organization. Understanding these roles provides the basis for training and building the competence of the personnel needed for the process.

Step 7: Designing a Supportive Organizational Structure

Figure 5.4 shows a typical structure of an enterprise software development organization. It also shows the likely roles of various players along the different phases of the software development process. A well-designed structure must support the organization's key business processes, especially the ones that are crucial to meeting customer requirements. An appropriate organizational structure depends on a number of contingency factors, such as management style, size of the organization, its product and geographic diversity, the availability of managerial and technical skills, and user needs for supportive services.

DFTS requires a structure that is user- and process-focused. In particular, we emphasize three basic requirements:

  • The structure must provide for robust communication between users and software development personnel as well as between various personnel within the organization throughout the development process. It should thus enable a network of internal and external constituents.

  • The structure must be process-based, reflecting the DFTS methodology.

  • The structure must be team-based, the way enterprise software is developed.

Figure 5.5 shows a simple structure based on these basic requirements. The CQC or its subcommittee, the DFTS Steering Committee, is the apex body responsible for the initiative's successful implementation and ongoing improvement. It consists of all the senior executives, chaired by the CEO, and jointly coordinated by the Vice President of Software Development and CQO. The supporting services and systems are a crucial part of the structure and are provided by departments such as Quality, HR, IT, Finance, and Sales and Marketing. CQOs or their representatives coordinate these supporting roles. It's important that all the personnel involved understand user needs as they evolve during the development process. CQOs make sure that an adequate communication mechanism is made available to ensure robust communication with the users.

Figure 5.5. A Process-Based Organizational Structure


Software development is a creative process, but it also involves a lot of labor-intensive mechanical work at downstream stages that must be carried out equally well. The software development process thus can benefit from creativity as well as standardization. Both are needed to meet customer requirements. The structure must provide for both. But it can hardly suffice by itself. It must be supplemented by effective communication and documentation to handle coordination between customers and various personnel involved in different phases of the development process. DFTS methodology provides a number of tools and techniques, such as TRIZ, Pugh, FMEA, and QFD, that help address communication challenges related to evolving needs typical in enterprise software development.

Step 8: Establishing Effective Communication

As stated, a DFTS process has two kinds of communication challenges. The first, relating to communication between the users/customers and the organization, is covered in Chapter 11. The second pertains to communication within the organization.

CQOs and the executive leadership should understand the critical role of communication and ensure that the organization has a sound communication plan in place. It should be planned, monitored, and improved continuously rather than set up as an afterthought. The CQO should work with the ECs and various departments to ensure that appropriate information is made available in a timely manner. It is important that raw data is collected, analyzed, and presented as per the recipients' information needs. The communication system should provide for and encourage information up, down, and across the organization as appropriate.

It may be best to set up a committee to come up with a robust communication plan. This will ensure participation and creativity. Every organization is unique, so it's important to customize the communication plan accordingly. Lack of effective communication can seriously mar the initiative. We cannot overemphasize the importance of robust communication as an integral part of the DFTS initiative. The most important communication tool is personal meetings, including one-on-one, in a problem-solving manner. The decisions and follow-ups are crucial to meaningful communication. A variety of other tools, such as e-mails, bulletin boards, company newsletters, and posters, may be used. Innovative use of the Internet, as well as various formal and informal meetings, media events, books, and publications, can be powerful too.

Step 9: Creating an Appropriate Reward System

A reward system is the totality of reinforcement processes that encourage individuals and teams to believe and behave in a manner that helps the organization achieve its most crucial goals and ambitions. As such, it is more than salary, compensation, and monetary incentives. In fact, monetary rewards may fail to secure the desired results. There is no one best way to reward people. A reward system's effectiveness depends on the type of organization, its culture and beliefs, the goals that the reward system is seeking to achieve, and desired actions, beliefs, and behaviors that need to be reinforced. Involvement, commitment, and a stake in the outcome are essential ingredients for high performance.[12]

The reward system for an organization-wide quality initiative such as DFTS should be designed carefully and should be the following:

  • Assimilated with the DFTS process: The reward system should support and assimilate with the DFTS model. It should reinforce the DFTS learning process, its objectives, and its subsequent integration and expansion. It should be organization-wide in that it involves everyone, from newly recruited software engineers, to HR personnel helping with designing the reward and communication systems, to ECs, the CQO, and the CEO. The surest way to ensure that the reward system will work is to link the reward system for the CEO and senior management to the rigorous and timely implementation of the DFTS initiative and its integration and expansion.

  • Customer-focused: The goals and metrics must be customer-focused. They measure whether the initiative has met or exceeded the customers' spoken and unspoken needs and expectations. That's the crux of trustworthiness. The members of the project team should be taught to interact with external and internal customers on an ongoing basis and understand their evolving needs, concerns, and challenges in measurable terms.

  • Team-based: Enterprise software development is a particularly collaborative process. The reward system should be structured to encourage teamwork and collaboration. This can be achieved by a variety of instruments, such as team-based incentives and feedback on teamwork, process defects, and goals rather than feedback on individual performance. Often, root-cause analysis reveals causes relating to management polices and decisions rather than individual performance.

  • Goal-focused: The reward system should have clear, measurable goals with consistent short-term (quarterly) and long-term (yearly/three-times-yearly) elements. Furthermore, goals should be gradually linked to the ultimate objective of integrating and expanding the DFTS initiative beyond the initial projects. The rewards should be clear, and individuals should be able to redeem them either quarterly or yearly. The rewards should not be part of yearly performance evaluations, merit ratings, or annual reviewsthe effects of which are devastating on individuals and, therefore, quality (see point 3 in Table 5.3).

  • Communicated effectively: Teams and individuals should understand what their roles and contributions are. But the emphasis should always be on how the team can address individual shortcomings. They should be provided with the required skills and resources. Team members must be encouraged and respected for improvement ideas. The PLs and others should be required to regularly provide accurate feedback on team and individual performance. It's important that leaders take an interest in individuals and their teams and encourage team-based high performance.

  • Supported by genuine appreciation: The reward system should be organized so that feedback and rewards are frequent and linked. The value and type of rewards should be tied to the performance and value created by the teams. These should be decided after careful deliberation, should be in line with the organizational culture, and must be substantial and meaningful. They may be gifts for the family, vacations, or financial rewards, including stock options for outstanding performance.

Step 10: Establishing Cost of Software Quality

This is the last of the planning steps before the DFTS initiative is launched. In the absence of Cost of Software Quality (CoSQ), the organization may be ill-equipped to identify various improvement opportunities that pop up during the implementation process. CoSQ serves four useful purposes in a software quality initiative:

  • It helps you focus on activities that discover and correct the root causes of software defects.

  • It helps you determine how you can improve the development process to prevent further defects.

  • It provides a vehicle for communication across all functions supporting the project, regardless of the organizational structure.

  • It communicates in a language that's easily understood: dollars.

CoSQ was discussed in Chapter 4, along with other financial evaluation tools such as ROQI using NPV and IRR, Quality Loss Function (QLF), and Activity-Based Costing (ABC). It is important to establish both CoSQ and financial evaluation metrics before the DFTS initiative so that opportunities for improvement are measured and identified during the implementation process.

Step 11: Planning and Launching Organization-Wide Learning

This is the first step in the implementation process that involves planning, designing, and imparting formal DFTS learning and training for the organization as a whole. Training programs should be customized and differentiated according to the roles and training needs of the people concerned. It takes place in two stages and is described briefly in this step and the next. The details of various DFTS training schedules are provided in Chapter 21.

Step 11 is concerned with imparting learning to all those who will largely be in supportive roles, such as the senior executives, ECs, and various personnel in sales, marketing, finance, and HR. These personnel provide important help in software development, documentation, costing, customer liaison activities, and training and other HR-related matters. They must understand the DFTS process to contribute to its implementation and integration. DFTS training is a lot more inclusive than that for a DFSS program because of the unique design predominance of the software development process. In the preimplementation stage (Step 11), two customized training programs are scheduled. Senior executives and ECs undergo senior executives and champions training, and other support personnel undergo white belt training. Step 12 training involves software developers and PLs. They receive intensive training interspersed with the actual development process. It is scheduled as part of the implementation of the DFTS model, which enables effective learning through project implementation and classroom learning.

The two training schedules in Step 11 are part of preimplementation planning:

  • Senior executives and champions training: This three-day executive seminar provides an overview of opportunities, benefits, and leadership challenges in developing trustworthy software. It's meant for the CEO and senior executives from software development, quality, finance, planning, sales, marketing, internal IS, and HR. The roles and responsibilities of various players in a DFTS process are clarified. It also creates awareness about how DFTS works and how it can help the organization with its business objectives and, subsequently, securing genuine buy-in, commitment, and support. A major outcome of this seminar is identifying the software project(s) that black belt and master black belt trainees will work on.

  • White belt training: White belt training is meant for everyone who supports software developers at the front end. This includes personnel from HR, from sales and marketing who interact with the customers, from finance who help with cost data, and from systems support personnel who provide support for the internal information system. This two- or three-day training introduces them to the basics of the DFTS process and equips them to help software development teams across various stages of the process. White belt participants should be introduced to the metrics, tools, and techniques of the DFTS process and acquire an awareness of the methodology and its immense value.

Step 12: Implementing the DFTS Model

This step is essentially learning and applying the DFTS model (see Figure 2.6) to an actual software development project. Its success depends on how the previous Steps 1 through 11 are planned and implemented. It's the responsibility of the senior management team led by the CEO, CQO, and EC to ensure that these have indeed been carried out carefully. These steps lay the ground-work for successful implementation of the DFTS model. In absence of this preparation, one can hardly realize its full potential. Step 12 consists of training the team members and leaders by having them use the DFTS model in an actual software development project. It consists of DFTS Black Belt Training and DFTS Master Black Belt Training.

DFTS Black Belt Training

All software professionals, from Vice President of Software Development down to young software engineers, must acquire black belt expertise. It should also be required training for all quality professionals, from CQO downward. The need for such organization-wide training is obvious. A rigorous quality management program is hardly ever a part of software engineering curricula in colleges or graduate schools. Furthermore, DFTS covers critical software development activities that provide a solid basis for quality management in the organization as a whole. The team undergoing black belt training should have an approved software development project already assigned to it, together with a project charter. As far as possible, the first project should be small in scope and development time so that it's manageable as a first DFTS project. Classroom learning and its successful application on a real software development project comprise the basic black belt training and are at the heart of the DFTS implementation process.

Black belt training constitutes the core body of knowledge for the DFTS process. We emphasize the importance of acquiring Personal Software Process (PSP) and Team Software Process (TSP) skills.[13] These skills contribute immensely to the DFTS process and also enhance the overall process and people maturity in CMM/CMMI and People Capability Maturity Model (PCMM) contexts. The training is designed as a sandwich program in the implementation process. It consists of five weeks of classroom learning followed by five software development activities that take four to eight weeks each (see Figure 5.6). The actual duration of the development activities between training sessions depends on the specific project. Correctly applying what has been learned during the training seminars is an integral part of the learning process.

Figure 5.6. DFTS Black Belt Training and Project Work Schedule


It is important to develop, apply, and document best practices during the development activity. Knowledge transfer from the classroom to the actual development process is critical and should be carefully planned and monitored. CQOs and ECs work closely with trainers/coaches to ensure effective learning and knowledge transfer.

DFTS Master Black Belt Training

PLs are trained to be MBBs, who provide technical, teaching, coaching, mentoring, and leadership support to the project team. We discussed the roles and responsibilities of PLs earlier. MBB training and certification are also recommended for all software professionals above the PL level, as well as for quality professionals such as CQOs and their direct reports in the quality department. The training and certification plan for DFTS MBBs is discussed in Chapter 21, along with those of other cadres.

Step 13: Monitoring and Feedback for Learning and Improvement

Learning from process and customer feedback is an important aspect of a learning enterprise. Steps 11 and 12 constitute the two-step implementation of the PICS model. These result in delivering the software product to the customer after the project team has carried out Customer Appraisal and Review (CAR) and has complied with predelivery customer requirements (see Figure 5.6). This is an excellent opportunity to get customer feedback upon actual delivery. Here are some important questions to ask at this stage:

  • Have we specifically met the customer's cost, quality, and delivery schedule, as measured by pertinent metrics? Have we exceeded them or fallen short?

  • How capable is our process, as determined by the process feedback loop, in meeting stated and unstated customer requirements, as determined by CAR?

  • What are the opportunities for improvement, as measured by the gap between customer needs and process performance? (Process capability improves as the gap diminishes; this also implies less room for improvement.)

  • What steps should we take to improve the process capability before integrating the revamped DFTS process and expanding it further?

Checking how the plan was implemented and is evolving is a crucial part of the PICS model. Here you use actual data, analyze it to discover the root causes of deviations, and take corrective actions to strengthen the process. To do so, appropriate metrics must be developed as part of the CoSQ initiative taken during the planning stage. Corrective actions complete the Deming cycle. All this must be properly documented.

Step 14: Freezing the Improvements and Gains

In this important stage, the organization takes the necessary steps to solidify the gains from the DFTS initiative (see Figure 5.3). This requires a planned effort aimed at changing people's attitudes, behavior, and beliefs. It should not only encourage the converts but also address the skeptics. You might have diehards who remain unconvinced. Such persons may have valid grounds for doubts, which must be given due consideration. You also might have downright cynics; it may be best to take appropriate remedial measures in such cases.

A variety of measures, such as counseling, a reward system, and training, can be deployed to encourage people to embrace the change. Freezing the gains invariably necessitates new roles and rules, and, above all, leadership that is visibly and vocally supportive of transformation. Many organizations find it crucial to create a strong quality culture, as discussed in Step 4.

Step 15: Integrating and Expanding the Initiative

The success of the DFTS initiative ultimately lies in its seamless integration with the rest of the organization beyond the initial project. This can happen successfully only if the initial project has been planned and executed systematically. We believe that the 15-step implementation framework proposed in this chapter provides a systematic methodology. It will help you successfully execute your first project. It also helps you develop the capability and knowledge base to expand the project further in your organization. Your objective should be for your next projects to be even more successful than the first one. This continuous improvement project after project will have a profound effect on customer satisfaction and corporate performance.

The task of organization-wide deployment can be a lot more challenging and risky. It is therefore critical that a tentative integration plan be prepared and updated as the first project is being implemented. The first project provides a unique opportunity to learn various "dos" and "don'ts." These should be properly documented and can help you develop a repertoire of best practices. The CQO and ECs should work closely and set up a "DFTS Integration and Expansion Task Force" when the first project is being planned. The best guarantee of subsequent success is a successful and systematic implementation of the first project, and learning from it. It is therefore critical that the organization mobilize its resources, including the most talented people, to be involved in the first project.

Finally, there should be a road map and a game plan if the first project does not produce the expected results. Instead of indulging in blame and finding scapegoats, management should analyze the implementation process and find the root causes and take appropriate measures. It's important to remain steadfast in the face of temporary setbacks. Certain setbacks are inevitable when implementing large projects; they are part of the learning process. Chapter 21 discusses DFTS integration and expansion further. Case Study 21.2 deals with integrating a new initiative with an organization's other quality platforms. Glenn Mazur provides a framework for integrating QFD and other quality methods to improve the newproduct development process in Chapter 27.




Design for Trustworthy Software. Tools, Techniques, and Methodology of Developing Robust Software
Design for Trustworthy Software: Tools, Techniques, and Methodology of Developing Robust Software
ISBN: 0131872508
EAN: 2147483647
Year: 2006
Pages: 394

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net