Multiple Systems: Matrix Management

While air force officers funded government R&D, industry performed most of the work. Because of industry’s dependence upon the military for R&D and production contracts, changes in the air force’s organization and procedures had significant ramifications for industry. Industry managers grappled with government directives and technical problems, resulting in a variation of the military’s model for technical organization: matrix management.

After World War II, aircraft companies shrank with the reduction in gov­ernment contracts and observed the services’ organizational and technologi­cal changes with interest. For missile programs and complex aircraft, aircraft companies built entire systems that included ground equipment, armament, and electronics. Aircraft companies began to reorganize their efforts around the complex new products. When the air force reorganized on a systems basis in 1952, aircraft contractors were well prepared. Each company, with a num­ber of complex projects under way, had to reconcile the new project-based organization with their traditional discipline-based, functional structure.

The Martin Company developed one of the first project management orga­nizations in the years 1952-53. William Bergen, an engineer who headed the pilotless aircraft group and the contract for the Naval Research Laboratory’s Viking rocket in the late 1940s and early 1950s, was an early promoter of sys­tem management. As he wrote in a 1954 Aviation Age article, ‘‘Within the com­pany we have created a number of miniature companies, each concerned with but a single project. The project manager exercises overall product control— in terms of an organization of all skills.’’ Martin quickly implemented Bergen’s innovation and expanded it to ‘‘cover all functions from design through man­ufacturing and distribution.’’76 The Martin Company’s systems approach in­cluded three elements: systems analysis to determine what to build, systems engineering to design it, and systems management to build it.77

Another example was McDonnell Aircraft Company’s F-4 Phantom pro­gram. In the 1940s, McDonnell designed aircraft by committees staffed with engineers from the functional departments, with owner J. S. McDonnell ar­bitrating disputes. When the navy awarded the company a contract to de­velop the F-4 in 1953, the company made young engineer David Lewis its first project manager. Lewis assigned three project engineers outside of the func­tional departments’ jurisdiction to make design decisions, while he built the project organization and acquired resources.78

Project management involved the separation of engineers from their func­tional departments so that the engineers reported directly to a project man­ager whose sole task was to run the project. As projects grew, the number of managers and engineers also grew, but all reported to project managers, not functional department managers. As explained by a business school pro­fessor in 1962, ‘‘The primary reason for project management organization is to achieve some measure of managerial unity, in the same way that physical unity is achieved with the project.’’79

With numerous projects under way, military contractors faced the prob-

lem of developing several of them concurrently. The old line-and-staff or­ganization no longer sufficed, as communication lines across functional de­partments became too long for effective coordination. H. F. Lanier, a project engineer for Goodyear Aircraft’s Aerophysics Department, explained:

The problem can perhaps be best illustrated by considering the difficulties of trying to fit a number of creative people into the precise and orderly line orga­nization shown in [the “traditional line organization’’ figure]. Under this plan, all work is thoroughly organized and all assignments rigidly controlled. Each individual has a definite area to cover, definite data to work with, and a schedule to meet. He also has a boss who tells him what to do and subordinates whom he tells what to do. This organization once set up is soon limited to the creative output of a few men who lead. Any innovation is difficult to introduce because it requires detailed instruction at all levels.80

Lanier concluded that the long lines of communication needed breaking down. Ad hoc means did not suffice over the long term or for large projects: ‘‘The usual solution was to allow a great deal of ‘co-ordination’ and ‘liaison’ to be handled informally. Effectively, supervisors unleashed their men and gave the program general direction but let detailed instructions be formulated after the fact. The loose method has been reasonably successful. The next obvious step is to attempt to systematize the process.’’81

Often the first attempt at systematization was to form committees of func­tional supervisors. This did not work once meetings became too large or too frequent: ‘‘Usually the committee members are also line supervisors and hence can meet only for a fraction of the time required for efficient system de­velopment. In other words, actual development by a committee is employed most effectively on an occasional relatively huge problem. When large systems problems are the prime business, then a permanent fix must be made.’’82 For this purpose, Lanier explained, ‘‘The solution seems to be a committee of project or systems engineers — individuals trained to be jacks of all trades, and who are relieved of line responsibility for administering operating sec­tions.’’ Project management aligned engineers to the project but left undeter­mined their relationship to the rest ofthe organization. Lanier recognized that engineers had relationships to both the project and the remainder of the orga­nization, where the engineers had to go when the project ended. Engineers

Traditional line organization and lines of communication. For complex projects, the communication lines become too long. Adapted from H. F. Lanier, ‘‘Organizing for Large Engineering Projects,’’ Machine Design 28 (1956): 54.

therefore reported to both project and line management. Lanier called this dual reporting the project-line combination organization. The new organiza­tional form had a “two-dimensional” or “matrix” form.83

The evolution of General Dynamics’ Astronautics Division, responsible for the Atlas missile, typified the organizational changes brought on by the divi­sion’s involvement in several military projects. For most of the 1950s, Con – vair ran Atlas as a single-project organization. Initially, Atlas (then known as Project MX-774) was directed ‘‘by a project engineer who was assigned a small team of designers and technical specialists plus an experimental shop for fab­rication of the hardware.’’ By 1954, one year after the acceleration of the Atlas

Project-line method of organization, later known as the matrix organization. Adapted from H. F. Lanier, ‘‘Organizing for Large Engineering Projects,’’ Machine Design 28 (1956): 57.

project, Convair reorganized the project around the program office and had a force of 300 personnel, mostly engineers. In 1955, the company created the Astronautics Division to carry out the work of the Atlas program. By 1958, the work force had increased to 9,000, and by 1962, it was up to 32,500. General Dynamics made Astronautics a full division in 1961. Astronautics managed this rapidly expanding organization as a single project throughout the period.

However, with the development of different versions of the Atlas, and the development of new projects such as the Centaur upper stage and the Azusa tracking system, ‘‘priority problems were created in functional line depart­ments, with resultant conflicts over authority and the jeopardizing of perfor­mance, scheduling, and cost.’’ The Astronautics Division responded to this problem by ‘‘utilizing a program control plan called the ‘matrix’ system which provided a director for each program undertaken by the company.’’ Program directors and department managers resolved priority conflicts.84

By 1963, Astronautics organized every new major program with the project system using the matrix structure. Atlas Program Director Charles Ames de­scribed the organization in the following way: ‘‘Under this system, the pro­gram director… is responsible for the successful accomplishment of the project. . . Generally, personnel working full-time on a project are assigned to the project line organization. The project line activities are organized to fit the specific task. . . Personnel not assigned to the project line organizations work in functional or ‘institutional’ departments. Institutional engineering maintains strong scientific and applied research groups as well as preliminary design and systems analysis groups.’’85

Required by the military, and prompted by their own complex projects, to institute project management, the contractors fit the weapon system con­cept and its project management into their organizations through the cre­ation of matrix management. Matrix management provided companies with the means to move engineers across projects while maintaining disciplinary expertise, becoming the industry standard by the 1960s. Matrix management allowed the government to manage each project with systems management while also permitting each corporation to coordinate and control the multi­plicity of projects in a way that was consistent with the corporation’s overall strategy.86

Conclusion

The air force policy of concurrency kept the ballistic missile program on the fast track, in keeping with the perceived urgency of the Soviet threat in the 1950s. Industry reacted by developing matrix management, allowing several projects to be managed simultaneously. Unfortunately, in the desire to elimi­nate red tape and bureaucracy, Schriever’s organization also removed many of the checks necessary to coordinate technical details and budget for large systems. The result was a series of missile failures, compounded by huge cost overruns.

To remedy this situation, the WDD’s successor, the BMD — along with R-W and its successor, TRW — developed methods to improve missile reliability. These included exhaustive testing, component inspection and tracking, and configuration control to ensure that the design matched the hardware that was launched. Schriever’s group expanded the methods of configuration control into configuration management, an important process that tied cost estima­tion to engineering changes. The air force modified contracts based upon the accepted changes.

By the early 1960s, the air force integrated these concepts into AFSC and its administrative processes for weapon system development and procure­ment. These processes incorporated systems engineering, systems analysis, re­liability, and configuration control. Schriever’s authority grew, soon encom­passing the air force’s space programs, but at the same time he gave up his independence from the air force bureaucracy. AFSC made systems manage­ment the standard for large-scale systems.

Schriever soon found that McNamara’s centralizing changes, particularly phased planning, eroded his independence and slowed the pace of develop­ment. With one hand he fought the changes, and with the other he rolled with the punches and promoted managerial innovation within AFSC. Just as Schriever and his technical officers promoted standardization to better con­trol their organizations, so too did McNamara, promoting standardization across the entire DOD. Schriever’s methods, developed to centralize manage­ment of large-scale projects, provided the basis upon which McNamara could then control all military R&D programs.

The problems and solutions faced by the air force were not unique. Dur­ing the 1950s, the army’s JPL was a leader in missile development, confronting similar problems and developing similar solutions to its air force and navy competitors. JPL provides a good point of comparison with the air force ex­perience, as it transitioned from military missiles to civilian satellites, and from Army Ordnance to NASA.

FOUR