Joseph M Juran

To meet the challenges of solid quality achievement, Joseph M. Juran prescribes the following [10]:

• _{Structured annual improvements in quality;} • _{A massive quality-oriented training program;}

• _{Upper management leadership of the company’s approach to product quality.}

2.3 Joseph M. Juran 39 Insufficient development computers Software development behind schedule Incompetent software manager Inexperienced software development personnel Insufficient support personnel Unavailable supporting software Lack of planning Insufficient funding Incomplete or unclear requirements Excessive documentation Severe complexity Unavailable test benches Effect

In the early 1950s the Japanese faced a grim reality; no alarm signal is as insis- tent to industrial managers as the inability to sell the product. Since their major limi- tation was quality, not price, they directed their revolution at improving quality. They learned how to improve quality and became proficient at it, and they are now reaping the rewards of their efforts. Their managers are equally at home in meeting current goals and in making improvements for the future [10]. The story of the Japa- nese electronics industry, with transistor radios, for example, illustrates the dedica- tion to annual improvements in quality that exists in Japan.

There is a grim reality in product development involving software that qual- ity needs immediate attention and can stand improvement yearly. Too many software-intensive systems never meet their requirements, either because develop- ment overruns financial or time budgets, or because the user is unsatisfied. Product management must plan for and make this same total commitment to quality product improvements from within. Now, software managers of software-intensive product developments must not only be technically aware, but they also need to be commit- ted to annual improvements in quality.

To accomplish these annual quality improvements, Joseph M. Juran advises that a team [10]:

1. Study the symptoms of the defects and failures; 2. Develop a theory on the causes of these symptoms; 3. Test the theory until the cause(s) is known;

4. Stimulate remedial action by the appropriate department(s).

Defects can be separated into those that are worker-controllable and those that are management-controllable. The latter are defects that cannot possibly be avoided by workers. Whether a certain defect should be regarded as a worker-controllable defect or a management-controllable defect depends on the extent to which the fol- lowing conditions are met:

1. The worker knows what he or she is to do. 2. The worker knows the result of his own work. 3. The worker has the means of controlling the result.

If all three conditions are met and the work is still defective, the worker is responsible. However, if one or more of the conditions have not been met, this is a management-controllable defect [11].

W. Edwards Deming makes two relevant points on the responsibility for defects that apply to product development (substitute “product developer” for “worker”) [12]:

To call to the attention of a worker a careless act, in a climate of general carelessness, is a waste of time and can only generate hard feelings, because the condition of gen- eral carelessness belongs to everybody and is the fault of management, not of any one worker, nor of all workers.

Many managers assume they have solved all the problems once they have brought worker-controllable defects under control, when, in fact, they are just ready

to tackle the most important problems of variation, namely, the management- controllable causes [13].

During software-intensive product development many worker-controllable defects can be controlled by software developers. However, there is a wide class of defects in software because the developer does not know what he/she is supposed to do. This occurs because of the inevitable intertwining of specification and imple- mentation. In other words, the problems are that during the software development (the implementation), the requirements (the specification) are continually being changed. Many times the software developer is continually “engineering” some- thing new, without the benefit of “frozen” requirements.

Contrary to claims that the specification should be completed before implemen- tation begins (the idea that “the worker knows what he is supposed to do”), there are two observations that the two processes must be intertwined. First, limitations of available implementation technology may force a specification change. That is, the hardware hosting the computer software may require software workarounds because of hardware limitations. Second, implementation choices may suggest aug- mentations to the original specification. That is, as more is accomplished, more is learned, making it reasonable to augment with a better approach than what was originally specified.

Only because the already-fixed and yet-to-be-done portions of this multistep system development process have occurred unobserved and unrecorded, the multistep nature of this process has not been more apparent [14]. This is especially true of the large software development for prototype (unprecedented) systems where the entire system is pushing hardware and software technology. In most of these systems the hardware does not even exist to test the software, but is under con- current development with the software.

In software development, that “the worker (software developer) knows the result of his own work” is very immediate, and sometimes humbling for the worker who made a stupid mistake, for he or she receives results immediately from the com- puter exactly as he or she commanded, whether correctly or incorrectly. On the other hand, there are the subtle errors that are not found for years. This is a worker-controllable defect, but one where “the worker does not know the result of his/her own work.” Quality software development must continually resolve to remove this type of error.

In software development “the worker has the means of influencing the result.” Assuming a reasonable task assignment, the worker is directly involved in the pro- duction of the result (computer program) and is the first to see that result. Consider as one example a situation where the worker looses that influence, say, when the computer is unavailable. It is usually not worker-controllable to make the computer available.

To summarize this discussion of the annual quality improvements suggested by Joseph M. Juran, it is clear that software developers must first know where they stand before setting up the program for improvement. In this specialty area of prod- uct development, to know where one stands from a quality viewpoint is essential. The only way to know where one stands from a quality viewpoint is that the defects (errors) must be identified and the causes determined. Only when this is accom- plished is movement toward quality improvement possible.

Most recently, selective training in quality sciences in Western companies has been largely confined to members of the specialized quality departments, which con- stitute only about 5% of the managerial and specialists forces in various companies. In contrast, the Japanese have trained close to 100% of their managers and special- ists in the quality sciences.

This massive quality-oriented training program carries the education and train- ing nostrum of Kaoru Ishikawa to its logical conclusion. Joseph M. Juran points out that common quality training needs to include [10]:

1. The universal sequence of events for improving quality and reducing quality-related costs (creation of beneficial change);

2. The universal feedback loop for control (prevention of adverse change); 3. Fundamentals of data collection and analysis.

Particular training for software developers in quality disciplines should include design reviews, reliability analysis, maintainability analysis, failure modes and effects analysis, life-cycle costing, quality cost analysis, and concepts of inspection for design and code.

An example of Japanese upper management commitment to quality is the obser- vation made by Lennart Sandholm to the International Quality Control Conference held in Tokyo. Almost half of the Japanese participants at the conference were from upper management—presidents, general managers, division heads, and directors. At conferences held in Europe or the United States, almost all participants are from the quality profession—quality assurance engineers, reliability engineers, and quality managers—and there are only a few upper managers in attendance [15].

W. Edwards Deming also observed that in Japan top people in the companies took charge of the problems of production and quality. All the reports showing suc- cessful implementation of quality principles quoted in his paper were written by men with the position of president of the company, managing director, or chairman of the board [16].

Dr. Deming said, “All of top management came, not only to listen, but to work. They had already seen evidence from their own engineers that what you’ve got is this chain reaction. As you improve the quality, costs go down. You can lower the price. You capture the market with quality and price. Americans do not understand it. Americans think that as you improve quality, you increase your costs” [17].

The need for upper management leadership stems from the need to create major changes, two of which include annual improvements in quality and a massive qual- ity oriented training program already discussed above. The recommended step for upper management in Western companies is to perform a comprehensive company- wide quality audit to understand what needs to be done.

An organizational weakness in Western companies is the large, central quality department with numerous functions of quality planning, engineering, coordina- tion, auditing, inspection, and testing. In Japan, most of these quality-oriented func- tions are carried out by line personnel (who have the necessary training to carry out such functions). The Japanese do have quality departments, but they are small in terms of personnel and they perform a limited array of functions: broad plan- ning, audit, and consulting services. Upper management quality audits evaluate the

effectiveness of the organization and only upper management has the authority to institute the necessary changes. This principle of Dr. Juran’s, again, is being per- formed when a sponsor (senior executive) commits to having a SCAMPISMappraisal of the development processes.

For product development involving software, senior product development man- agement is the upper management. The commitment, then, of senior product devel- opment management to producing quality products containing software is necessary to accomplish that objective. Also, taking this a step further, putting responsibility for software quality in the software development department is a cor- rect posture for senior software management to enforce. The most obvious benefit of this posture is the close awareness of development quality brought to the various development organizations.