This chapter presents the DFTS implementation framework as a 15-step process, as shown in Table 5.1.
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 ModelThe 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-inThis 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 ChangeFigure 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:
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 CommitmentAfter 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 InitiativeExamining 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 SupportDFTS 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 AntipathyIn 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 SlogansOften 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.)
Copyright © 1988 by Zultner & Co. Reprinted with permission.
Copyright © 1988 by Zultner & Co. Reprinted with permission.
Copyright © 1988 by Zultner & Co. Reprinted with permission. Lack of Team CohesivenessOrganization-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 StrategiesWrong implementation strategies can be fatal for a quality initiative. Three strategic issues must be addressed diligently:
Strategic ClarityManagement 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.
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 ChangeOne 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 IndicatorsQuality 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 IssuesOften 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 CommunicationIn 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 TrainingThe 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 CostsFinally, 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.)
Step 4: Laying Foundations for a Quality-Focused EnterpriseWe 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 PracticesThe 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]
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 TeachingsThe 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 CommunicationAfter 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 PrinciplesAlthough 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):
The essentials of Deming's philosophy can be grouped into three broad issues:
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 InfrastructureA supportive organizational infrastructure is crucial for a successful DFTS implementation. The following are the key elements:
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 PlayersDFTS 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 CEOsThe 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:
Role of the Corporate Quality CouncilThe 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:
Role of Chief Quality OfficerChief 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:
Role of DFTS Executive ChampionThe 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:
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:
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 StructureFigure 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:
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 StructureSoftware 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 CommunicationAs 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 SystemA 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:
Step 10: Establishing Cost of Software QualityThis 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:
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 LearningThis 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:
Step 12: Implementing the DFTS ModelThis 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 TrainingAll 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 ScheduleIt 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 TrainingPLs 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 ImprovementLearning 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:
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 GainsIn 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 InitiativeThe 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. |