In bureaucracies, procedures define the functions of every job and who reports to whom. Procedures specify the communication channels, the data to be communicated, who analyzes data to create information, and who makes decisions based on that information. Systems management defined such procedures for the organization of R&D.
Failure spurred the development of systems management. In the first missile and space projects, few procedures or standards existed, for the simple reason that no one had built space vehicles before. Individuals used methods with which they were familiar, until they found them ineffective. As is typical in pioneering work, individuals made mistakes and did not want to repeat them or have others make the same errors. They developed and documented new processes that avoided their initial errors. Later projects used these methods, sometimes modifying them in accordance with new circumstances.
Procedures served two purposes: to pass on good scientific, engineering, or managerial practices; and to protect the organization and its individuals from external criticism. Organizational and process changes typically followed technical problems rather than preceding them. Documenting the lessons learned from success and failure, and standardizing successful practices, created consistency across the organization. To distinguish this kind of knowledge from other, more familiar forms such as mathematical, scientific, or tacit knowledge, we may call this codified knowledge.6
Codified knowledge is knowledge put into verbal or “algorithmic” form, typically documented in explicit written instructions. For example, the military relies upon regulations and procedures because officers frequently rotate to new tasks and positions. The military would degenerate to chaos if it did not have explicit written procedures to document the functions of each position and its processes. Small organizations where each individual understands all tasks need few procedures. However, beyond a certain organizational size, no individual can understand all tasks or processes, and written procedures become more important.
Individuals write procedures to accomplish a specific function. This helps to explain why systems engineers had such a difficult time explaining themselves to their academic colleagues. Engineering researchers in academia defined themselves through a body of theoretical or empirical knowledge. More importantly, they prized the creative process, which cannot follow set rules or strict procedures. Although academic engineers performed specific tasks, such as writing proposals, performing research, and teaching, procedures had little meaning to them, because their research created new knowledge for which no procedures existed. By contrast, systems engineers performed a specific function, and their unique knowledge consisted of algorithm-like processes and procedures to analyze and coordinate the designs of other engineers. Systems engineers needed creativity to solve problems, but the processes that led them to the problems and the methods to coordinate the solutions could be standardized. Hendrick Bode, a systems engineer with Bell Laboratories, compared systems engineers to architects, acting as the bridge between builders and users, designing the overall system, and coordinating the entire effort.7
Contrary to the observations of some management theorists, bureaucracy is not inherently antithetical to creativity or to R&D in general. In fact, the history of systems management shows that bureaucracy can be useful to ensure that all parties involved with R&D—the funders, the managers, and the technical experts—have a part in the process. Systems management provides a framework in which R&D flourishes as a stable part of organizations. Furthermore, elements of systems management, such as change control for design coordination, are essential elements of the technical processes in technology creation.
Systematic, Scientific, and Systems Management
Systems engineers and operations researchers often traced the lineage of their techniques to Frederick Taylor’s scientific management movement in the early twentieth century. To these mid-twentieth-century spokespeople, Taylor’s innovation was the application of scientific methods to the analysis of processes. So too, systems engineering and operations research applied rational thinking to the processes of R&D. Just as systematic management standardized corporate planning and communications at the end of the nineteenth century and scientific management rationalized manufacturing processes in the first decades of the twentieth century, systems management bureaucratized the R&D process in the middle of the twentieth century.8
One way to view these three management movements is to identify each with the group over which managers gained authority. In systematic management, executive managers developed methods to coordinate and control lower-level managers and office workers. Scientific management extended their authority over industrial workers. Systems management expanded managerial authority over scientists and engineers. In systematic and scientific management, upper-level managers typically appropriated skills and knowledge from lower-level workers. Systems management did not appropriate skills but rather developed proxy measures to assess R&D workers.
Without the ability to develop technologies themselves, managers and military officers developed schedule and cost measurements to assess progress against a plan. The Program Evaluation and Review Technique (PERT) and the critical path method became popular in management precisely because they gave managers for the first time methods to assess technical work progress without having to rely completely on the technical workers. Configuration management forced technical experts to give the cost and schedule information necessary for managers to develop reasonable plans. Armed with relatively accurate schedule and cost data, managers could then monitor these factors as a proxy for technical progress. Because funding was the primary resource they controlled, managers finally had the means to monitor and control the scientific and engineering teams.
Managers did not eliminate working groups or appropriate the technical knowledge of scientists and engineers. Instead, management superimposed hierarchy over technical teams through the imposition of project management and configuration control. Project management gave one manager control over project funds. Working teams designed the system and periodically reported their progress through design reviews. The products approved in design reviews became baselines, changeable only through management approval tied to cost and schedule. “Management by the numbers’’ became popular at this time in part because these numbers served as proxies for technical knowledge. In earlier times, managers could directly understand and control their workers. With knowledge workers, this was no longer possible, and ‘‘the numbers’’ became the substitute of choice.
Through systems management, government officials could assess future technologies with systems analysis and control current projects through project management and systems engineering. On highly technical projects such as the military’s weapons programs or NASA’s space projects, the government’s ability to command industry became powerful indeed. Systems analysis, project management, and systems engineering have become standard techniques throughout the government and indeed throughout much of American industry.
People today often criticize NASA for its bureaucratic ways, yet when NASA has relaxed its grip, it has endured failures such as the Challenger accident or the Hubble telescope’s embarrassing optical problems.9 The ‘‘faster, better, cheaper’’ mantra of the 1990s is of questionable value for space programs. How many of the bureaucratic methods of systems management can be eliminated before there are large-scale failures? Recent events, such as the loss of recent Mars probes, show that NASA cannot eliminate many systems management methods. It is folly to think that it could be otherwise for space projects.
Proponents of the ‘‘faster, better, cheaper’’ approach want to return NASA
to the days of frequent, relatively inexpensive spacecraft and launchers built by small, informal teams. As we have seen, however, the ‘‘good old days’’ were also times of frequent failures, huge cost overruns, and common schedule slips. NASA managers and engineers created the formal mechanisms of systems management explicitly in response to the problems of ‘‘ad-hocracy.’’ Systems management, as recent spacecraft failures once again prove, is cost- effective on a per-successful-flight basis for space projects.
Another criticism comes by comparison with Japan. The Japanese developed a managerial system based on quality. This system, according to promoters of methods such as total quality management (TQM), is superior to the American system because it focuses on the ‘‘voice of the customer’’ and because workers on the factory floor have a voice in improving the manufacturing process. The Japanese method is a direct outgrowth of American-style Taylorism and has often been roundly criticized in Japan as being too rigid and controlling. The quality methods developed in Japan stem from the same concerns with reliability that the American aerospace industry had. Whereas Japanese managers and engineers focused on the reliability of mass production processes, their American counterparts concentrated on the reliability of R&D. Both approaches used inputs from the working teams, in the United States with R&D scientists and engineers, and in Japan with the manufacturing engineers and production line workers. The TQM promoters believe that paying more attention to ‘‘the customer’’ and to quality will solve American ills.10
The Japanese approach, bred in the ‘‘stable-tech’’ automotive and similar mass production industries, may well be suitable for American mass production industries but is not well suited to R&D. Japanese industry has been quite successful at copying American innovations and mass-producing them but far less successful at producing its own innovations. The Japanese are far more likely to gain from American systems management for their R&D than Americans are to gain from applying manufacturing-based TQM to R&D, for the simple reason that systems management developed as an R&D process and TQM did not.
One last consideration points to the broader importance of systems management. Systems management methods have spread far beyond aerospace. As early as 1972, Ida Hoos described numerous government organizations that adopted systems analysis and probably other elements of systems management as well. She decried this as the unwarranted spread of technocratic methods to areas in which they were inappropriate. That is undoubtedly true.11
One significant place where systems management spread is the computer software industry. The information industry is now the current exemplar for American industrial dominance. Computer software has supplanted hardware as the glamour product. Yet software development is exactly where systems management methods developed in the computer industry. In the late 1950s, the largest software company was the System Development Corporation (SDC), which spun out of the RAND Corporation to develop software and training programs for air force air-defense systems. Programmers trained in systems methodology at SDC on air force programs diffused throughout the United States, spreading the systems approach for programming far and wide.12
More than with any hardware artifact, software development is a pure process, and the final product is itself a process. Current methodologies in software development, such as structured or object-oriented programming, are variations on systems themes: simplifying interfaces, enhancing communications, considering the entire product, and dividing tasks into simple work packages. Whatever might be said about software, the industry is rarely deemed overconservative or lacking in innovation. Perhaps systems approaches prevent computer programmers and computer scientists from finding a radically better way of developing software. Or perhaps they are the only thing preventing software from sinking into total chaos.
The officers, managers, engineers, and scientists who created systems management in the first two decades of the Cold War did so because they believed in the efficacy of technology to protect and promote the values of the United States. After this time, the apparent effectiveness of these methods in creating missile, space, and computing technologies led technologists and managers in other nations to mimic Americans. Through the combined efforts of these groups of people, technological innovation has become a standardized commodity throughout the Western world. Systems management has tamed R&D.
Political, military, and business leaders now plan for new technologies years in advance, using the services of scientists and engineers to promote their visions of the future. Systems management has become one of the primary tools of our technological civilization. Change is now the norm, a standardized product of systems management.