Draft

To Engineer Is Human

Lorraine A. Pajerek Lockheed Martin Federal Systems 1801 State Route 17C Owego, New York 13850

This paper is a draft, submitted for publication in Systems Engineering: The Journal of the International Council on Systems Engineering (John Wiley & Sons, Inc., publisher). It may be copied for review purposes only. Reproduction for general distribution is not permitted.

Abstract Human Factors in engineering is a well-known concept. Its first application was in hardware design, where it is often referred to as ergonomics. Software designers have also adopted its precepts, and now the field of Human Factors engineering is understood to comprise a wide range of issues from the physiology of workstation design to the psychology of job satisfaction. The study of the human role in systems takes on new dimensions when the ‘system’ in question is actually the process of developing products or systems. This article explores key differences pertaining to the human element in development processes versus traditional systems, and the implications that apply to work currently being done in the areas of process maturity and continuous process improvement.

Processes Are Systems, Too Development processes are now being treated as systems in their own right, systems that can themselves be ‘engineered.’ A systems engineering or software development process, for example, can be viewed as a system with inputs, outputs, ‘processing,’ and interfaces. One author has used the term process meta-system [1] in this context, which I will adopt for my purpose. The meta-system paradigm has evolved to aid in the pursuit of process improvement. We can discuss physical, functional, operational, and behavioral views of process meta-systems. These parallels are useful in helping engineers think about the processes they employ. Most engineers are comfortable with the meta-system metaphor, and it can serve to clarify issues of process maturity and capability for a community of professionals that is trained to value science and precision.

In approaching development processes as systems, one of our goals is to apply proven improvement techniques that make sense when applied to other systems. The idea that a development process can be optimized is a corollary of the theory of process-as-system. But there is one very key distinction between process meta-systems and traditional technology-based systems. This distinction is manifested in the crucial variance of the role played by humans.

Most engineering definitions of the word system acknowledge the human element. Users, operators, and maintainers of hardware and software are generally recognized to be components of the overall system, as much as the equipment itself. Human factors engineers have coined the evocative term personnel subsystem to refer to the human component of a system. [2] In a process meta-system, however, the personnel subsystem assumes an importance that supersedes that of any other component. Thus if we are to usefully study processes as systems, we need a thorough understanding of the characteristics of this all-important subsystem.

In traditional systems the human interaction is often confined to a user interface (UI) that passes inputs and outputs between the personnel subsystem and the other subsystems. Once the personnel subsystem initiates a transaction or operation, the majority of the processing is carried on by other subsystems. Ideally, a user error should never break the system. Challenges in designing UIs are well known; experts in human factors have long noted that people will always do the unexpected. Thus UIs have to be particularly robust, because designers can never fully predict what the users may do.

In a process meta-system, most of the ‘processing’ is actually performed by the personnel subsystem. The personnel subsystem is in fact the central processing unit of the process meta-system. This is a totally different role from that of the personnel subsystem in a traditional system. A human processor has profound implications on the nature of a

Draft 1 Draft process meta-system. These implications impose some limitations on our ability to effectively apply certain engineering techniques to process meta-systems, including standardization, measurement, and optimization.

Classifying the Process Meta-System There are different types of systems, each with its own defining characteristics. In 1956 Kenneth Boulding proposed a classification of systems into nine levels [3]:  static structure  simple dynamic structure  control mechanism  self-maintaining structure  plant organism  animal organism  human organism  social system  transcendental system

Whether one agrees with this particular classification or not, one recognizes that different types of systems exist, and that the behavior of each must be studied for its unique influences and determinants. Of the classes of systems listed above, a process meta-system is clearly most like a social system, or even more precisely, a sociotechnical system. Strictly speaking, a development process itself is distinct from the humans who execute it. It is an over- simplification to present the personnel subsystem as a component of the process meta-system, as I have done above. It is more accurate to say that the development process and the personnel are both subsystems of a superordinate sociotechnical system, viz., the organization.

Kast and Rosenzweig have ably described this view of the organization, one that is “based upon the tasks to be performed and includes the equipment, tools, facilities, and operating techniques. The social subsystem is the relationship between the participants in the organization. The technological and social subsystems are in interaction with each other and are interdependent.... Any production system requires both a technological organization - equipment and process layout - and a work organization - relating those who carry out the necessary tasks to each other.... A work organization has social and psychological properties of its own that are independent of technology. “However, the social system determines the effectiveness and efficiency of the utilization of the technology…. [I]t must be emphasized that these two subsystems, the technical and the social, cannot be looked at separately [present author’s italics], but must be considered in the context of the entire organization. Any change in the technical subsystem will have repercussions on the social system and conversely.” [4]

So while the development process itself can be termed a technical system, and thus an appropriate target for engineers, we see that we cannot treat the process meta-system without considering its interaction with the personnel subsystem. Any study of a social system must be informed by “consideration[s] of the nature and dimensions of value systems…and the complex gamut of human emotion.” [3]

Engineers Rush In Where Angels Fear to Tread Hence, in order to improve the process meta-system we must also enter the realm of the social sciences. As engineers we quickly find ourselves in unfamiliar territory. While there is a tremendous body of precedent in the application of general systems theory to social systems, the specific characteristics of social systems demand a different approach than that to which engineers are accustomed. In fact, attempts to apply systems engineering techniques to social issues have a miserable history of failure when undertaken by individuals who naively presume that all systems problems are amenable to engineering solutions. One exception notable for his success is Jay Forrester, inventor of the magnetic flux core memory and a key player in the Semiautomatic Ground Environment (SAGE) air defense project, who later turned his systems science expertise to industrial and urban studies.

As chronicled by Thomas Hughes, Forrester was successful where others - including SAGE colleagues Bernard Schriever and Simon Ramo - were not. Forrester “simulated social systems by computer modeling, portraying them as sets of interactive equations and feedback loops. He applied these generalized computer models to specific social systems [including industrial processes] by supplying quantitative information specific for the system under study. He took into account political and other qualitative factors by assigning to them quantitative values.” [5] Forrester extracted a valuable lesson, one that should be noted by those attempting to measure and improve engineering

Draft 2 Draft processes: “Our experience, which has been developed from contact with simple systems, leads us to look close to the symptoms of trouble for a cause. When we look, we discover that the social system presents us with an apparent cause that is plausible according to what we have learned from our simple systems. But this apparent cause is usually just a coincident occurrence that, like the trouble symptom itself, is being produced by the feedback-loop dynamics of a larger system.” [6] Hence intuitive judgments about cause-and-effect relationships may not be effective in social systems. Causes may not be proximate in time and space to effects. This conclusion is echoed by Kast and Rosenzweig: “In physical systems there is a direct cause and effect relationship between the initial conditions and the final state.... [S]ocial systems operate differently.” [7]

How Do Process Meta-Systems Measure Up? Inherent in the quantification and measurement of process meta-systems is the assumption that sociotechnical systems can be managed in much the same way as aerospace projects, military missions, and manufacturing facilities. As noted in the late 1960s by Ida Hoos, then a research sociologist at the University of California- Berkeley, “This implies that social systems can be reduced to measurable, controllable units, all of whose relationships are fully recognized, appreciated, and amenable to manipulation. Implicit, too, is that through systems analysis, new insights will be achieved and new solutions will emerge. “In practice, none of the assumptions has found substantiation. Review of completed systems analyses indicates that far from submitting gracefully to quantitative treatment, social systems are by their very nature so laden with intangible, human variables that concentration on their measurable aspects distorts the problem and confuses the issues.” [8]

The concept of Continuous Process Improvement (CPI) is based on measuring the status quo, and using these measurements to determine where improvements can and should be made. The follow-up is to repeat the measurements after a change has been implemented, to assess whether an improvement has in fact occurred. In other words, we measure outcomes and draw conclusions about the process that produced the outcome. In the scientific world, this kind of analysis is generally performed in an experimental environment where all but one variable is held constant. This ensures that one can deduce with confidence that any change in the outcome is due to changes in the single variable that has been altered. These conditions are virtually never encountered in the world of engineering projects.

In reality there are a host of influences, at both the individual and organizational levels, that can and do affect the outcome of any engineering project. A brief compendium of these parameters would include characteristics of the personnel assigned to the project, constraints imposed by management, and the environment in which the project is executed:

Individual Characteristics  competence/knowledge/experience  attitude/personality  motivation/dedication/ conscientiousness

External Constraints  time (schedule)  money (spending profile as well as total development budget)  staffing levels and experience  target cost of end item at point of sale  availability of materials  precision and completeness of definition of expected outcome

Infrastructure/Support  support environment (tools, etc.)  techniques applied

A number of these factors may not be under the direct control of the organization doing the work. For example, the budget and schedule for a defense contract may be determined by the government, not by the contractor. Thus, just as our process meta-system and personnel subsystem are part of a larger system (i.e., the organization), the organization is in turn part of a larger system that includes the procuring agency (whether internal or external); together with its own policies and business plans.

Draft 3