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