Software Quality Journal 1, 9-26 (1992)

Kaizen: the applicability of Japanese

techniques to IT
FAHMIA H U D A and D A V I D P R E S T O N
South Bank Polytechnic, Borough Road, London SE10AA, UK

The initial objective of this paper is to discover the concepts behind Kaizen, which is the Japanese word for
improvements. It implies a gradual and continuous change for the better and occurs within a stable environ-
ment. A Japanese perspective was adopted because the Japanese have experienced particular success using
Kaizen; learning from their structure was then extrapolated on to the particular problems encountered within
the software industry.
The conclusion reached was that Kaizen has no definite cultural dependence, therefore it can be successfully
employed in software development. Its particular appeal lies in the fact that it is people- and process-oriented,
as a result quality is built into the system through the people who work on it and through process control. The
former is established via training and education, participative management and by fostering involvement in the
organization. Psychological constructs such as motivation and satisfaction are examined through the person-
environment fit and job characteristics theory to discover their application to software personnel.
Process control is suggested as a means of building quality by using statistical methods which should be
accessible at all levels of the organizational hierarchy. The importance of management commitment to this
fundamental change in work practices is highlighted. Finally, with regard to software development, a different
perspective on the life-cycle is presented which attempts to amalgamate all the ideas that Kaizen incoporates
to take advantage of the latest technological capabilities.
Keywords: culture, improvement, Kaizen, management, TQC

1. Introduction

In an age of change, quantum leaps have been made in the computer industry with regard to
hardware and software. However, despite this, progress has been fraught with problems, chiefly in
the realm of software development. Granted that fast moving technology leaves little time for
assessment and re-evaluation, it has nevertheless become of paramount importance to approach
problem solving from a new angle, since past failures have shown all too well that trying to use the
same old solutions does not work.
With a view to investigating a novel approach, attention has been focused on Japanese techniques.
Japanese success in all facets of industry has been revelational, not least because of the short
time-span in which it has been accomplished; in just over four decades she has grown from being an
agrarian economy to the second largest economy and third largest trader in the world (Drysdale 1989).
Imported knowledge and the will to change have been the driving force, but commitment to improve
the nation as a whole has been no less important.
0963-9314 © 1992Chapman & Hall
10 Huda and Preston

Central to the issue of change is the philosophy of Kaizen, which is described in the next section.
Although Kaizen is rooted in the cultural heritage of Japan there is much scope for adaptation of
the ideology to the advantage of Western cultures. This paper addresses the question of how best
the philosophy can be used within the IT milieu in order to create a bed rock for improvment and
change.

2. An exploration of Kaizen
It is perhaps pertinent at this point to actually uncover the meaning of Kaizen. At the most basic
interpretation it means gradual on-going continuous improvement. Increments are small enough
not to be disruptive to the environment in which the change is being effected, but simultaneously
the change is enough to be noticeable. However, Kaizen is more akin to a philosophy and defies rigid
definition; rather it is an amalgamation of interrelated principles which singly are inconsequential,
but combined become a powerful method of initiating improvement. Kaizen is a holistic approach
to problem-solving and its difference lies in being people-centred rather than system-centred. It
recognizes the overriding importance of the human element and gives a new perspective to problem
solving by way of minimizing conflict and of eliminating blame, so that people work together instead
of individually towards goals.
The starting point for Kaizen is the recognition of and an admission that a problem exists; the
ultimate goal is to make gradual change. Kaizen should be implemented as a policy that involves
all company personnel. Management should be the driving force behind the change, showing its
visible commitment to it at all times and being supportive to the project. Continuous improvement
may often appear fruitless; it is at these times that management's duty lies in encouraging the project
to continue, advising, and presenting incentives so that there is a renewal of effort.
The Japanese way of implementing Kaizen is initially to maintain a set of current relevant
standards, but at the same time to seek new ways of upgrading those standards so that higher levels
can be achieved. This is where the concept of involving people becomes crucial, because instead of
just following instructions, the worker is able to explore and think and assume responsibility for
improvement. This in turn results in job satisfaction, so that a sense of craftsmanship is imbued into
the product and pride in having achieved provides an incentive to continue to find improvements.
Imai (1986) introduced the concept of Kaizen as an umbrella (Fig. 1) to encompass the wide-ranging
activities which comprise it; given the scope of Kaizen, this appears to be the most satisfactory
diagrammatic representation.
Ways in which Kaizen can be manifested include suggestion systems, the use of quality circles,
total quality control (TQC), statistical process control, and total quality management (TQM).
Attention is focused on the process rather than the results; by getting the process under control,
results should improve automatically because good work practices, employee motivation and the
value of individual contribution will become inherent in company philosphy. The Kaizen umbrella
is merely a way of bringing all these interrelated activities under one roof.
Certainly the road to continuous improvement is not easy to follow because it requires high levels
of commitment of time and effort on the part of management. There is evidence which suggests that
Western management's attention is focused too often on the short term. Most experts believe that
for a philosophy of continuous improvement to work a more long-term perspective would need to
Kaizen: the applicability of Japanese techniques to IT 11

1. Customerorientation small group activities

2. TQC
process control
3. QC circles co-operativelabourmanagementrelations
4. Suggestionsystems productivityimprovement
5. Automation
new productdevelopment
6. Discipline
reductionof waste
7. Qualityimprovement

k.,
Fig. 1. The Kaizen umbrella.

be adopted. Participative management and open communication, implemented by some Western

managers, provide a forum of synergistic discussion and evaluation between management and
personnel; such developments are to be applauded. Input from the worker is a valuable contribution
because it contains insight often beyond the reach of the manager. Experience of such initiatives also
reveals a management and worker relationship of greater harmony than under traditional systems.
Kaizen is as much about altering behaviour patterns and changing ideals as it is about process
control, because momentum for change is built and maintained only in the minds of the people.

3. Total quality control

The philosophy behind TQC is to build into people an awareness that quality exists. This is done
through education training and recognition and reward for effort and achievement. TQC is also a
means of acquiring systematic statistical data so that any strategy adopted is based on objective
criteria rather than conjecture. Another fundamental axiom of TQC is the concept of 'customer in'
not 'product out' as the focus for implementing change. Introducing TQC means breaking down
departmental barriers, so that important areas such as quality, cost and scheduling do not become
areas of conflict.
Cross-communication occurs both horizontally and vertically across the organization; the former
via management directives, the latter through quality circles (QCs). QCs are voluntary groups within
the organization who meet, either in or out of company time, in order to discuss ways of initiating
change and then of introducing it within the context of their work. Methods include using the
Plan-do-check-action cycle or Shewhart cycle (Fig. 2) for identifying areas of improvement such
as cost cutting, safety, productivity etc; this has been refined (Fig. 3) by Imai (1986). QCs are usually
concerned with trivial matters; their primary concern lies not saving money (although this does
12 Huda and Preston

Fig. 2. The original Shewhart cycle.

The revision proposed by lmai (1986) was to explode the 'Do" element of the PDCA by another cycle,
representing worker participation for improvement.
Fig. 3. The revised PDCA cycle.
Kaizen: the applicability of Japanese techniques to IT 13

happen) but in creating greater efficiency and reducing waste. Each member is versed in the use of
tools such as pareto diagrams, control charts and cause-and-effect diagrams, because fundamental
to Kaizen is its solid basis on objective data as well as subjective evaluations.
Another important concept behind Kaizen is the reduction of waste. Necessary for improvement
efforts to succeed is that management should become waste conscious, firstly because it need not
prove expensive, and secondly because the benefits reaped are manifold. This area is of particular
relevance to improvements in software because so much time, effort and money is tied up in activities
outside of actual software engineering.
Since the responsibility for Kaizen lies ultimately at the door of management, a discussion of any
acts of implementation would be incomplete without exploring the milieu in which Kaizen operates
best. It would be safe to say that Japanese management practices, although not difficult to emulate,
are far-reaching in their consequences. This is because they concentrate on human issues first and
then build corporate strategy around them. Furthermore, the long groundwork necessary before
being elevated to the position of manager means that an individual grows into the job and brings
a vast wealth of experience gleaned during his years of job rotation through all of the various sectors
of the organization. The working knowledge of concomitant problems is therefore very great;
Whitehill (1991) refers to this as a multi-specialist rather than the generalist model, which bears an
implied lack of depth in any area. Because of his vast experience, this multi-specialist is able to
understand a wide variety of issues and this seems more important to the running of the organization
as a whole; specialists are imported to deal with problems beyond the manager's capabilities.
Although these methods may realistically be outside the scope of the Western manager, whose
lifespan in any one company may be relatively short, it does point to an area which can be addressed;
namely, that managers should broaden their specialty. Multi-specialism allows for fluidity and
flexibility not enjoyed by the West in its management structure and caters more readily for the
unstable nature of business.
Further examination of the manager's role points to a few outstanding differences from Western
counterparts: a holistic approach to problem solving; the nurturing of relationships, and most
crucially, a whole-hearted commitment to the concept of groupism. The success of the individual
is measured by the success of the group, with the leader adopting the roles of catalyst, source of
inspiration and coach. This recognition of the employee as the company's most valuable asset
reflects the Kaizen philosophy as a whole: all efforts of the company are expended in building quality
awareness into its personnel through the personal commitment of management.
Tethered to the formal structure of the hierarchy is the informal horizontal structure which exists
as the warp and weft of Japanese business and imbues it with its great strength. Loyalties are built
up through a network of contacts developed over years. These contacts can then be drawn upon to
oil the wheels of company machinery and thus lessen areas of conflict by approaching problems
through indirect channels which reinforce company objectives.
The sacred tenets of Japanese management: seniority based wages, lifetime employment and
smooth labour relations, also aid in reinforcing long-term goals. The security conferred to the
individual by these methods allows him to concentrate solely on his work, enhanced by the vast
amount of in-house and external training provided by the company. Two other areas in which the
Japanese excel are in consensus decision-making and in allowing workers to use their initiative.
Much time is expended before decisions are finally taken. Although in most cases there is a
top-down filtering of ideas through senior management, these ideas are discussed thoroughly by all.
14 Huda and Preston

This allows for the lessening of disagreement so that the final solution is accepted cordially by the
participating dements. In this way conflict is reduced, and any new resolutions adopted are more
likely to succeed because people feel they are partly responsible for the decision.
Management is also frugal in providing details of how to adopt objectives. Usually an outline
structure is given, but the individual is allowed to use his own inventiveness in the work, whilst
adhering to company standards. At the same time, staff are actively encouraged to improve
standards, through the suggestion scheme system, which is a successful and rewarding way of
providing job satisfaction and motivation, whilst improving quality and productivity.
In contrast to the humanistic, conflict-reducing policies of the Japanese, Western management has
tended to concentrate more on Taylorism or scientific management, which reduces the person to a
cog in the wheel. Leadership is relegated to the league of carrot and stick mentality with emphasis
being laid on the stick. Under such circumstances it is inevitable that difficulties and breakdowns
in communication arise due to 'them and us' stances being adopted.
Realizing the difficulties of transplanting the functional counterparts of Japanese management to
fit comfortably into current Western business practices William Ouchi proposed a theory called
Theory Z which adopted the best features of the Japanese system to make it more palatable to the
West. The resemblance to Japanese techniques still exists within the broad context.
The main features of Theory Z are that trust should be instilled in people and amongst groups
within the organization; a fostering of intimacy by nurturing subtle relationships should be given
priority. Ways in which Theory Z differs are: that both assessment and promotion are quick, both
implicit and explicit means of control are used, the individual bears final responsibility for group
decisions, and finally that the holistic concern is not a hierarchical but an egalitarian relationship.
Pascale and Athos (1986) have determined that the main objectives to be tackled by the West are
threefold:
1. Managerial practice should be examined since current strategy yields only diminishing returns;
2. There should be a consideration of shifting values which are socially and culturally determined;
3. Organizational effectiveness in terms of goal setting, coordination and motivation have to be
re-evaluated.
In this way common elements of success enjoyed by both Western and Japanese firms can be found.
Kaizen is thus not only an integration of TQC and all the associated adjuncts like quality,
productivity, labour-management relations, feedback from customers etc, it is an inherent con-
sciousness-raising policy initiated and supported by management in order to improve the outlook
for the individual and the company. It requires total commitment and a long-term approach to
corporate goal setting in order to succeed. The rewards are improvement in every aspect of work.
So far the discussion has concentrated on the principle of Kaizen and ways in which it can be
implemented. These range from stronger management control for long-term gains, requiring a
change of attitudes from the managers as well as the workforce, to adopting a responsible attitude
to work on the part of the individual. Training should be provided at all levels, with constructive
encouragement for skill-sharing. Unless management begins by exhibiting real concern for its
employees and establishes long-term objectives, the climate for improvement will not be harboured
to the full.
In order to be able to apply these ideas to software engineering in particular, an examination of
the specific difficulties currently being faced must be made initially. The production of software has
Kaizen: the applicability of Japanese techniques to IT 15

REQUIREMENTS
l"~
iteration AT~I
iteration ~'1 IMPLEMENTATIO']~1
N

Fig. 4. The Waterfall model with iteration.

been beset by varied problems, cumulatively referred to as the "software crisis'. Aggregated under
this heading is the fact that most software has significant cost and time overruns, and in most cases
fails to meet user requirements (99% according to a recent Computer Weekly survey (Computer
Weekly, 1991)
An analysis of specific problems can best be dealt with by examining the various stages of
production through the medium of a popular model. One of these is the waterfall approach, which
is a linear, top-down, modular technique for structured analysis and design of software in a stepwise
manner. It is known as the waterfall because completion of one step automatically leads downward
to the next; this model is described briefly in the next section.

4. The present model

Stages of the basic developmental life cycle of the Waterfall model (Fig. 4) are:
1. Requirements analysis and definition;
2. Program specification;
3. Design;
4. Coding;
5. Integration;
6. Validation;
7. Operation and maintenance.
Initially, in requirements analysis, a careful formulation of the user's needs are recorded, so that
the intent of the desired system and the properties it must possess are communicated by the user to
the developer. Ideally, in the specification stage, a precise specification is formulated, so that every
part of it should correspond to the earlier requirements document. At the design stage, the
specification is analysed and modular representations using precise plans should be used to create
an overview of the finished product. Coding is then performed on individual modules which are
16 Huda and Preston
integrated into the whole as they are completed. Validation is the procedure of examining system
performance by testing before the final release of the system to the user and its final acceptance.

4.1 Drawbacks of the waterfall mode/

Although presented as a linear model, the life-cycle is in fact iterative, with developers moving back
and forth between stages in order to resolve problems as the cycle progresses. As a basis for
increasing the visibility of the whole process, this model, with its emphasis on 'divide and conquer',
is a step in the right direction for formal methodology. The main criticisms appear to fall in three
categories:
1. The sequencing and appropriateness of the constituent elements of the model itself;
2. It is generally outmoded;
3. The perception of an implicit assumption that the model excludes newer paradigms of software
development (Agresti, 1986).
Important areas in which the life-cycle fails to deliver are an inadequate accommodation of
prototyping, of reusability, and the natural intertwining of specification and design. The hardware
limitations that rigidified the reductionist pattern of the systems approach no longer apply, because
it is possible to synthesize behaviour-producing intermediates at a much earlier stage of the life-cycle
than was previously possible. This permits modification and revision at earlier stages of the life-cycle
to become more meaningful, because user requirements are met more fully. Mechanisms which
provide a more flexible development process are presented in (Agresti, 1986) and are discussed later.
The general failings of sofware development have resulted in 'unreliable, inefficient software being
produced late, at high cost' (Somerville, 1989). According to Computer Weekly (1991) 60% of
organizations questioned had at least a one-year backlog of development, with nearly one-third
stockpiling over two years' work. Reasons for this were wide ranging but most pointed to the
indifference of high-level management to an IT strategy and to planning in general.
User participation is mandatory if requirements are to be explored fully and manifested, but
efforts are confounded from the beginning because of the scant attention paid to the user as a valid
and valuable input to the system. It is a fundamental maxim that prevention of errors is better and
less costly than cure. Ad hoc decisions which circumvent difficulties means that mistakes made in
the early stages of development are compounded and leave little room for adjustment, leading
ultimately to an unworkable system. Time spent at the beginning is well served, because clarity is
critical to the whole solution and will lead to systems that conform more closely to user needs.
Errors at the specification and design stage arise initially from the separation of these two parallel
processes into linear ones. Further difficulties are that design is divorced from reality, thereby an
inadequate provision for the real environment is made and restrictive solutions mean that small
amounts of unpredicted error lead to system crash or, worse still, inaccurate results. Lack of
portability is another frequently occurring drawback.
At the coding level incomprehensible unstructured and undocumented code has meant that even
small improvements have had to be abandoned. Byzantine mazes and monolithic code create an
exotic bag of tricks and inflexible code.
Problems with the actual method of production are, however, representative of only a proportion
Kaizen: the applicability of Japanese techniques to IT 17

of the software crisis. No less important (and perhaps far more difficult to resolve) are the difficulties
involving the people concerned with software production. The next section seeks to address this
issue and highlight some of the more familiar situations encountered whereby a serious mis-
understanding or misjudgement can jeopardize the completion of a project.

5. People problems
Most of the reasons for poor quality software have been attributed to the failings of the people
charged with the responsibility for its development. Most of the human factors involved in computing
tend to be psychological in nature, and in some respects are no different from any other sphere of
organizational activity. Thus, a broad spectrum of topics such as morale, motivation and ergonomics,
all play a contributing factor to the human side of software production and it follows that
concentration on tools and techniques should not detract from the importance of people.
It is at this juncture that the value of the Kaizen approach becomes explicit. Kaizen recognizes
the value of each and every individual, and also his or her relationship to his or her work. Different
personality types are evaluated and encouraged to exploit their maximum potential, whilst providing
a solid backup to minimize failure. An attempt to match each person to the environment in which
he or she functions best is made, in order to minimize conflict. Coupled to this is the realization that
a programmer fresh from an environment in which he or she is immersed in details, will not be adept
at dealing with managerial responsibility and its administrative clement. He or she is in effect
de-skilled, and yet another good programmer is lost and an incompetent manager gained. Following
the Kaizen strategy, the programmer would initially have received training and support to be eased
gradually into the role and lessen the culture shock in moving into a different environment from the
accustomed one. Conversely, the situation also arises where a non-technical manager is placed in
charge of technical people whom he or she cannot understand and therefore cannot communicate
with. Again, Kaizen would deal with this by training the manager to appraise the complexities of
the programmers' needs so that neither side feels impotent when dealing with the other.
Workers in the field of industrial psychology have melded their theories into one of person-
environment fit, which is necessarily a common-sense approach, because a person who is absorbed
by the intracies of programming may not always be able to adjust to seeing the structure as a whole.
The trick is to combine the generalist with the specialist so that a synergistic, harmonious relation-
ship is fostered. Where the gap is impossible to fill, adequate training should be provided to reduce
the psychological stress of having to tackle unfamiliar territory.
At the integration stage, where programmers who have been working separately must amalga-
mate their individual efforts, the drawbacks of poor communication will be realized. It is somewhat
surprising, the extent to which this human side of the problem is ignored. As software requires
considerable human interaction, developers must expect dire consequences if they dercgard such
issues as education and training, person-environmental fit and job satisfaction.
Experience has shown that with due consideration for human issues the inherent difficulties of
software production become more manageable; the alternative produces misunderstanding and
conflict at every stage of the cycle.
At the departmental level there may exist squabbles and rivalries between specification and coding
personnel, and between design and testing. There may even be instances where senior staff try to
18 Huda and Preston

by-pass quality assurance. Efforts should be made to encourage teamwork, to build a strong
integrated network where it is the concern of all to produce quality software. Kaizen at the group
level concentrates on helping constituent members of the group to overcome weaknesses and
develop strengths. Concomitantly, the success of the individual is measured by the success of the
group. The advantage of group work is a reduction of the isolating activity of programming or
debugging, but it is not only that. There is an assumption of responsibility towards quality control,
there is a sharing of ideas and a boosting of morale. Since it is also an informal setting for
problem-solving, there is also a non-c~nfrontational milieu in which the various phases of the
life-cycle can be constructively criticized without apportioning criticism to any one individual.
Mistakes are everyone's concern.

6. Standards
Failure to use relevant standards generally across organizations dealing with software production
is a problem, because unless standards have been set, there is no focus for Kaizen strategy to be
implemented. Computer systems from different sources find it difficult to talk to each other,
resulting in duplication of data and resources. As stated earlier, the way in which improvement is
augmented into a system is to establish a current working standard and then set both corporate and
individual goals to try and improve upon them. There are various standard making bodies,
including
1. The International Organisation for Standardisation (ISO);
2. European Computer Manufacturers Association;
3. The British Standards Institution (BSI);
4. American National Standards Institution (ANSI);
5. Institute of Elc~ztrical and Electronic Engineers (IEEE American, IEE British).
Another outcome of the policy of standardization is that it enforces conformity of output and
discipline into the workforce. It can therefore be used as a performance measure to evaluate the
effectiveness of any improvement. One of the chief merits of beginning a Kaizen programme is that
it becomes an opportunity for management to assess the existence of standards within the organiz-
ation, as well as determine when they were last updated (Imai, 1986). The importance of standards
within the software life-cycle lies in the fact that systematic reuse of infrastructure components can
become widespread, external packages can be used with more confidence, and programmers have
a working guide as to the fitness of the code they are producing.
Standard making however, is still much in its infancy in some areas, although some attempts have
been made: ANSI-IEEE 828-1983 for software configuration management, ANSI-IEEE 730-1984
for software quality assurance. There is unfortunately mass inertia to the adoption of them. Some
manufacturers support the standards philosophy but realize that it is inherently difficult to keep pace
with a fast moving technology. Others utilize standards for their own benefit.
Problems associated with introducing standards are due to the fact that manufacturers prefer to
be individualistic until they see the benefits standards bring.
The Software Engineering Institute (SEI) has developed a five-level software process maturity
model ranging from nothing to a well-defined standardization strategy, but at a time of instigation
Kaizen: the applicability of Japanese techniques to IT 19

more than 80% of the software projects surveyed were found to be in the lowest state (Card, 91).
Thus the model is hypothetical, based on few observations but much interference. It is useful as a
starting point but much work remains to be done.

7. Maintainability
A final issue, which encompasses all of the previous issues, is maintainability. At present 70% of
revenue is directed at software maintenance (Computer Weekly, 1991): all of the previous difficulties
contribute to this problem.

8. Ways of implementing Kaizen in software development

8.1 Humanware

Consistent with the philosophy of Kaizen, an apt starting point for recognizing areas of improve-
ment would be to consider the people aspect of software development. There are two areas in which
continuous improvement can make most gains; firstly at the individual level, and secondly at the
group level. We must address the following three related problems affecting human attitude to new
technology:
1. Lack of understanding in how to use it;
2. Lack of shared knowledge due to fear for job security;
3. Lack of infra- and inter-group contact.
First and foremost it becomes mandatory to recognize that training and education provided by
a commited management is the building block for solid personnel development. Caution has been
uppermost in the minds of management because of the relative mobility of Western workers visa
vis the Japanese, but this business of turnover is a two-edged sword. People are perhaps less loyal
to an organization because of the callous hiring and firing attitudes of management who show little
sympathy towards the long-term welfare of its staff. Here lies a lesson to be learnt from the Japanese,
where the company shows immense obligation to keeping in employment its permanent staff, who
enjoy the privilege of trust between management and worker. In return, the worker is loyal to the
organization, believing that his or her interest is that of the company. Thus the company fosters
goodwill in a loyal, stable workforce and is able to invest in training: the worker gains psychologically
and materially from this expansion of personal horizons. One of the methods used for recruitment
of this elite group of workers is a rigorous selection scheme, where personality is assessed as
vigorously as academic credentials.
Much has been made of the theories of Hackman and Oldham (1976) which strives to fit the
individual to a work environment to which they are most suited, thus reducing stress. Harnessed to
this are other psychological constructs such as motivation, esteem, self-actualization, perceived
autonomy and satisfaction. Other workers in the field have contributed towards a job characteristics
theory (Kulik) and motivation theory (Herzberg).
Herzberg found that sources of job satisfaction were environmental, and called these "hygiene'
factors. Removal of these from the workplace reduced job dissatisfaction, but did not necessarily
20 Huda and Preston

Rele.tt.0xgaat~gm latriam.ta.J~
1. Roleconflict/ambiguity 1. Too much~ittte work
2. Responsibilityfor people 2, Poorphysicalworkconditions
3. No participation in decisionmaking 3. Time pressure
4. Decisionmaking

f,a t ~ d / t . ~ e m ~ "" ~ I
1. Under/overpromotion . . ~ INDIV~UAL MANAGER
i
/
2. No job security I
3. Thwarted ambition

I
Organizational Structure Relations with Oi~aniTation |!
1. Officepolitics 1. Poorrelations with boss/colleagueI
2. ResUictionon behaviour 2. Unable to delegate [

Fig. 5. Sources of stress in white-collar workers.

contribute towards satisfaction. The primary determinants of job satisfaction were therefore held
to be intrinsic, dependent on achievement, recognition, responsibility, advancement and the work
itself, i.e. motivators. The way in which Herzberg can be interpreted is that the person is treated as
an individual whose behaviour is assessed in relation to the environment (Fig. 5). The two cannot
exist independently, since it is the environment experienced by the individual which will determine
the reaction to it. Following on from this, Kulik et aL (1987) in their job characteristic theory
(Fig. 6) specified the task conditions under which individuals are predicted to prosper in their work.
This can be united to the theory of person-environment fit (P-E fit), since this perspective analyses
the fit between the characteristics of a job and the abilities and needs of jobholders. Generally,
conditions of 'fit' between the person and the environment are predicted to result in high perfor-
mance, satisfaction and less stress.
At the most general level, five core dimensions are seen as prompting three psychological states
which in turn lead to a number of beneficial personal and work outcomes. Job characteristics theory
posits that all of the three psychological states must be experienced by an individual if desirable
outcomes are to emerge. Thus the meaningfulness of the work, the assumption of responsibility for
it, and knowledge of results are all important factors. Meaningfulness includes skill variety, task
identity (doing a job from start to finish) and task significance (whether the task has global impact
or not). Responsibility is equated with autonomy and knowledge of results is the feedback on
completion.
Ways in which job characteristic theory are applicable to the human side of software development
now fall readily into place. To provide the employee with the confidence to tackle work efficiently
they must be trained, otherwise mismatch will result in the deterioration of the employee to a state
Kaizen: the applicability of Japanese techniques to IT 21

COREJOB H 'PSYCHOLOGICAL
CRITICAL I[ - = . = =_= , ~
....................

OUTCOMES ]
CHARACTERISTICS
STATES I -
I

HIGH INTERNAL
1. Skill variety MOTIVATION
2. Task identity ~ 1. Experienced meaningfulness of work
3. Task s i g n i f i c a n ~ HIGHGROWTH
SATISFACTION

4. Autonomy ~ 2. Experiencedresponsibility HIGHGENERAL

for outcomesof work JOB SATISFACTION

5. Feedbackfromjob ~ 3. Knowledgeof actual results HIGHWORK

of work activities EFFECTIVENESS

Fig. 6. Job characteristics theory.

of apathy and learned helplessness. To provide staff with psychological motivation they must be
given a sense of involvement and their work is meaningful and contributes to the whole. They should
be given responsibility and autonomy and also provided with support, e.g. job restructuring to give
better P-E fit. As the user-developer part of the job involves developing good relationships with a
client, the job holder should be put directly in charge of the client so that feedback and autonomy
become important. This closer level of communication will make the developer more responsive to
the clients' need as well as establishing mutual goals. Skill variety may increase because of the need
to improve interpersonal skills; this also leads to an increase in task variety and significance.
Whilst individual work comprises a substantial part of software development, and can be made
more satisfactory by reducing tedious tasks like testing and debugging to automated methods, the
real advancement in using Kaizen methods lies in groupwork. Thus the use of chief programmer
teams and egoless programming, rather than conventional hierarchic, dictatorial methods can be
advocated. Egoless programming following the principle of abandoning authoritarianism and
surviving in a more democratic arena which advocates egalitarianism and an atmosphere of
cooperation. No defensiveness should then occur when requiring help, nor feelings of incompetence
for lack of knowledge. Attention is paid to helping each team member achieve self-sufficiency in
areas of weakness, and acts as a benefit as a whole for the group.
In reality, egoless programming is dependent upon an equal level of competency of the constituent
members for success to be achieved. Similarly, without some form of leadership, productivity may
flag if one or two of the members are not as conscientious as the rest. In short, egoless programming
should remain an option where team members work exceptionally well together.
Chief programmer teams are a way of retaining competent senior programmers to impart their
experience in programming, whilst at the same time fulfilling a managerial function. It is a synchron-
ization of the two roles, so that the importance of the chief programmer is not undermined by a
relative lack of managerial experience. The chief programmer idea is also devoted to encouraging
cooperation and serves to provide an apprenticeship to more junior members of the team.
22 Huda and Preston

Problems of application do exist, however, mainly concerning the critical reliance on one
individual. If he or she should fail to accomplish the designated task, then this not only reflects badly
on the concept, but may also result in unmitigated disaster in terms of reduced morale and
incomplete projects.
The principles behind egoless programming and chief programmer teams are true to the philo-
sophy of Kaizen because they seek to transcend the goals of the individual in favour of group
recognition. Another advantage of these small working teams is that the number of interactions is
reduced to a workable minimum, but then these are nurtured into strong relationships. The problem
with complex programming environments is that all too often they work on the Mongolian hordes
principle: engaging more programmers the farther off target they are and thus worsening com-
munication diffculfies. As Martin (1984) so succinctly observed, the more people there are toasting
each other, the more time they spend clinking rather than drinking. Project completion time is
increased rather than decreased when there are too many people who are required to be trained up
to the relevant level before commencing work.
At the group level there is interaction between team members via formal and informal channels;
the former is effected through comprehensive and comprehensible documentation, the latter
through the use of software quality circles. Poore (1990) has conducted various field experiments
using the concept of software quality circles to explore their relevance in introducing statistical
quality control to the development process. He found them to be an effective means of elucidating
a working definition for quality which is usable within the appropriate setting. In this way,
adherence to the standard will become more marked because it will have been pre-set by the group
itself, allowing access to autonomous decision-making and control. Furthermore, enhanced com-
munication and dialogue will result in a more objective viewpoint because operational views can be
analysed within the field setting. The consensus on quality will be a path towards creating, and then
improving, the standard.
Managers should imbue the developers with a sense of commitment to producing good work, by
using the concept of 'the next person is the customer', and not passing on low quality work to the
next stage of the life-cycle. This will result in more rigorous checking to comply with requirements
and weeding out errors and inconsistencies at the stages where this will involve least cost. Checking
and cross-checking against the documents produced, will validate the proceedings.
Finally, a feedback stage should be introduced at the end of each project, with an holistic, systemic
outlook, to discover what problems were encountered and how best to overcome these in the future.
This will be a means of avoidance of these pitfalls which resulted in the problem and will herald a
more critical approach when examining solutions. Blame must not be apportioned to any party, but
all of the departments and their employees should be concerned with one main objective, to get the
product right, then to improve on the process so that future products are superior. We now consider
ways of introducing process control to software production.

8.2 Controlling the process

We must first consider what are the ideal qualities of good software. Freeman (1987) cites a series
of factors which are basic and others which can be thought of as extra. Basic quality pertains to the
following: functionality, reliability, ease of use, and in certain aspects, safety. Extra quality may be
obtained through: flexibility, repairability, adaptability, lucidity, documentation and enhancability
Kaizen: the applicability of Japanese techniques to IT 23

of the software. One could argue however that these latter six facets should not be regarded as an
ideal to which to aspire, they are as necessary as Freeman's five basic elements. There seems to have
arisen a tacit agreement in the software industry that shortfalls are excusable. However this seems
a contradiction in an area which seeks to advertise its links to engineering. No self respecting
engineer would build a bridge or a plane and not expect it to fulfil the purpose for which it had been
built. Similarly a software engineer should not compromise on producing the best possible software
they can, given that certain trade-offs will be necessary. Some would argue that this is too idealistic
a concept, but if the intention is there at the outset, then the developer is much more likely to reach
the target of building quality into the product.
These quality factors are known as the external features. The internal quality of a system is
important too, and it is here that good design in terms of a well-structured framework becomes
inherently important. Internal quality factors are: completeness, consistency, parsimony, traceability,
rationality, structure, paradigm, understandability, and documentation.

8.3 Obtaining quality

The objective then is to build in quality at all stages in the life-cycle by the use of appropriate
standards, then check through quality assurance. This involves checking each end product against
its quality specifications and trying to redress the shortfall. Software metrics (Conte et aL, 1986) are
an under-utilized resource; useful to quantify certain quality aspects, such as reliability. Boehm
(1976) conjectured the components of quality to be:
1. Reliability;
2. Portability;
3. Efficiency;
4. Human engineering;
5. Testability;
6. Understandability;
7. Modifiability.
If one were to concentrate improvement efforts by refining the steps of the project life-cycle one
could extend the use of formal methods. Formal specification languages overcome the problems of
using natural language, which is full of ambiguity and is subject to omissions and misinterpretation.
Formal requirements languages are mathematically precise and unambiguous, allowing for veri-
fication and validation through the use of automated proofs. A precise requirements specification
will include reasons for the system being required in technical, economic, maintenance and operating
terms; the function which needs to be fulfilled and the limitations imposed (Smith, 1990).
At the present state of knowledge, this particular approach remains theoretical, but is a useful
pointer to the way in which development methodology can progress.
A novel way in which the problem of requirements specification has been treated, is through use
of animation. Kramer and Ng (1988) describe the use of a tool called the Animator which provides
visual feedback to determine the viability of a particular approach. As such, it provides dynamic
interaction with the user, facilitating valuable insight into the proposed behaviour of a system and
its resultant validity.
24 Huda and Preston

9. The automation-based paradigm

Balzer (1983) suggested that a new paradigm based on automated processes would lead to an
evolutionary change of traditional methods. Automation would augment the effectiveness of using
people to produce and maintain software, through correction of bugs and also enhancement of the
released system. Presently two fundamental flaws are in the spread of optimization information and
in the undocumented development processes.
Balzer's new paradigm would perform maintenance procedures on the specification rather than
the implementation, thus keeping the changes at a conceptual level understood by the user.
Furthermore the user would be able to generate updated requirements and ideally be able to perform
(given adequate training) the maintenance themselves.
A second objective of this paradigm is to ensure that the specified system actually does match the
user's intent and to deliver rapidly through operational specification. The specification itself
becomes the prototype of the system, enabling the user to evaluate how closely needs have been met.
The final objective is to provide a fast, reliable, inexpensive, automated implementation process
which, after each modification, is open to revision. Automated implementation support is based on
formalization and is knowledge-based in order to coordinate individual activities to support overall
development. The advantages of the paradigm are reduction in clerical errors and improved
documentation and reusability of software.
Automated assistance should greatly enhance system maintenance and will eradicate portability
problems. Standard packages can be manipulated for a more personalized manageable creation.

10. The design process

Design covers the conception of a product or service to meet a perceived market need (Webb, 1991)
Although the principal aim of design is to boost sales, other issues which become relevant are
reliability, functional capability and performance (Fig. 7)
Good design is cost-effective because it eliminates the need for rework and contributes towards
later maintainability. Also, errors are easier to amend at the design stage: between ten- and a
hundred-fold more than during later phases (Wallace and Fujii, 1991).
Turner (1984) lists the five most important principles of good design as:
1. Modularity;
2. Abstraction;
3. Hiding;
4. Understanding;
5. Uniformity.
Modules (small independent fragments of the design) should be easy to handle and have simple
well-defined interfaces, with controlled single entry and exit points. Modularity improves reliability
by the use of common routines that have already been tested. It also ensures that concerns about
efficiency and performance can be satisfied by tuning algorithms and code in localized units of the
program after it is working. Abstraction involves the extraction of essential details of a problem,
omitting the non-essential ones. Hiding makes inaccessible certain details of data representation or
implementation that are irrelevant to the module in question. Understanding is a measure of how
Kaizen: the applicability of Japanese techniques to I T 25
Marketing Industrial
issues issues

MANAGEMENT
('silentissues') ~
DESIGN J
Production Engineering
issues issues

Fig. 7.
readily a reader can comprehend the aims and effectiveness of a module. Clearly good documentation
is essential.
Following the design, are the coding, integration and validation stages. It is throughout necessary
to have a method of verifying and validating the design criteria; checking that the product is both
conforming to requirements and standards.
Design reviews range from formal, documented and planned meetings to impromptu informal
ones. Walkthroughs are a popular means of uncovering the majority of defects prior to coding,
testing and release. One form of review, known as 'inspection', has become common since its
introduction by Fagan in 1976. The inspection is a form of process improvement which combines
the concepts of the PDCA cycle and the quality circle into an effective means of error detection.
Each person involved in the circle has a role and a defined workload (Ackerman, et al., 1989). It
is most useful as an adjunct to testing because rework at the design stage is less time consuming;
less than two staff-hours to find a design defect compared with almost nine by testing (Ackerman
et al., 1989).
Finally Booth (1987), disenchanted with the limitations of structured analysis, proposed a system
employing the usability approach to design; the most radical form of user involvement being where
the user designs the system with experts on hand to advise.
The next form of partnership which is seemingly more acceptable is iterative design and prototyping,
where an evolving system is constructed and evaluated at each refinement; the results of each
evaluation forms the next feedback loop in the progressive improvement of the design. Prototyping,
whilst time consuming, provides both user involvement and early detection of faults. Alavi and
Wetherbe (1991) enhanced the prototyping paradigm using data modelling, resulting in fewer
iterations and improved designs. Agrestri (1986) suggested improved use of operational specifications
which, because they are capable of exhibiting behaviour, are attractive to both developer and user;
value lies in the ability to separate the developmental process into problem and implementation
oriented phases.
A word of warning is necessary here. These paradigms should not be embedded in traditional
models; the inherent problems of the latter will still exist. Improved methods of providing control
points and use of intermediate products, as well as adopting orthogonal views of the process, will
permit a new base model to be created. Developmental practices will be determined by process
drivers such as legacy, tool support, requirements understanding and operational characteristics of
software.
A flexible developmental process requires more management effort because control points and
26 Huda and Preston
intermediate products will vary with projects. However they constitute progress from the traditional
scheme of specification, design, code and test; it is a closer matching of the problem to be solved
with the best available methods of solution.
This new approach to software development is really utilizing existing methods most effectively:
process control; striving to implement improvement; exploring standards of quality and productivity.
The presence of standards across the board provides a vehicle available for reuse as well as providing
confidence in software packages.

Conclusion
Kaizen, being culturally driven, would seem to present huge implementation problems. However
individual organizations may easily learn and utilize some of this Japanese philosophy. Given their
'groupist' culture it is not surprising that most of these lessons relate to human activity. Organiz-
ations must focus their resources into developing methods which, by taking a responsible approach
to the human issues, help them to prosper.
It would appear that the knowledge transfer potential within Kaisen is particularly relevant to the
software industry, where its relative modernity poses additional problems. Traditional models seem
of limited potential, whereas recent research into automation-based paradigms seem promising.

References

Agrestri, W. (1986) New Paradigmfor Software Development, IEEE Computer Society.

Alavi, M. and Wetherbe, J.C. (1991) Mixing prototyping and data modeUingfor information system design,
IEEE Software, 86-91.
Balzer, J. (1983) Software technology in the 1990s using a new paradigm, Computer, 39-45.
Booth, P. (1987) The Design and Development Process.
Card, D. (1991) Understanding process improvement, IEEE Software, 102-3.
Conte, Dunsmore and Shell (1986) Software Engineering, Metrics and Models, Benjamin Cummins.
Freeman, P. (1987) Software Perspectives, Addison Wesley.
Hackman and Oldman (1976) Motivation through the Design of Work Behaviour and Human Performance
16.250.
Imai, M. (1986) Key to Japan's Competitive Success, McGraw-Hill.
Kramer, J. and Ng, K. (1988) Animation of requirements specification, Software Practice and Experience, 18,
749-74.
Pascal, R.T. and Athos, A.G. (1986) The Art of Japanese Management, Cox and Wyman.
Poore, J.H. (1990). Derivation of local software quality metrics, Software Practice and Experience, 18,
1017-27.
Smith, D.J. (1990) The traditional approaches to software quality in GowerHandbook of Quality Management,
Lock, D. and Smith, D.J. (eds), Gower Publishing Company.
Somerville, I. (1989) Software Engineering, 3rd Ed, Addison Wesley.
Turner, (1984) Software Engineering Methodology, Keston Publishing Company.
Wallace, D.R. and Fujii, R.U. ( 1991) Software verificationand validation: an overview,IEEE Software, 1O-17.
Webb, J. (1991) Questfor Quality, The Industrial Society.
Whitehill, A.M. (1991) Japanese Management: Tradition and Transition, Routledge.