Codified Knowledge

In bureaucracies, procedures define the functions of every job and who re­ports 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 pro­cedures for the organization of R&D.

Failure spurred the development of systems management. In the first mis­sile 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 typi­cal 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 meth­ods, 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 individu­als from external criticism. Organizational and process changes typically fol­lowed technical problems rather than preceding them. Documenting the les­sons learned from success and failure, and standardizing successful practices, created consistency across the organization. To distinguish this kind of knowl­edge 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 mili­tary 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 posi­tion 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 them­selves to their academic colleagues. Engineering researchers in academia de­fined 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 engi­neers. Systems engineers needed creativity to solve problems, but the pro­cesses that led them to the problems and the methods to coordinate the solu­tions 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 his­tory of systems management shows that bureaucracy can be useful to ensure that all parties involved with R&D—the funders, the managers, and the tech­nical experts—have a part in the process. Systems management provides a framework in which R&D flourishes as a stable part of organizations. Further­more, 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 in­novation 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 corpo­rate planning and communications at the end of the nineteenth century and scientific management rationalized manufacturing processes in the first de­cades 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 man­agement, 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 man­agerial authority over scientists and engineers. In systematic and scientific management, upper-level managers typically appropriated skills and knowl­edge 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 mil­itary 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 prog­ress without having to rely completely on the technical workers. Configura­tion management forced technical experts to give the cost and schedule in­formation 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 con­trol 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 manage­ment and configuration control. Project management gave one manager con­trol over project funds. Working teams designed the system and periodi­cally 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 tech­nical 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 proj­ect management and systems engineering. On highly technical projects such as the military’s weapons programs or NASA’s space projects, the govern­ment’s ability to command industry became powerful indeed. Systems analy­sis, 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 sched­ule 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 devel­oped a managerial system based on quality. This system, according to pro­moters 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 manufac­turing 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 produc­tion 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 manufactur­ing 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 produc­tion 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 Ameri­cans 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 aero­space. As early as 1972, Ida Hoos described numerous government organiza­tions that adopted systems analysis and probably other elements of systems management as well. She decried this as the unwarranted spread of techno­cratic 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 hard­ware as the glamour product. Yet software development is exactly where sys­tems management methods developed in the computer industry. In the late 1950s, the largest software company was the System Development Corpora­tion (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 pro­cess, and the final product is itself a process. Current methodologies in soft­ware development, such as structured or object-oriented programming, are variations on systems themes: simplifying interfaces, enhancing communi­cations, 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 ap­proaches prevent computer programmers and computer scientists from find­ing 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 man­agement 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 com­modity 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 standard­ized product of systems management.