The Matrix Organization

personnel, four individuals from R&D, and perhaps others not shown. These individuals come from their respective functional divisions and are assigned to the project full-time or part-time, depending on the project's needs. It should be emphasized that the PM controls when and what these people will do, while the functional managers control who will be assigned to the project and what technology will be used.

With heavy representation from manufacturing and R&D, Project 1 might involve the design and installation of a new type of manufacturing process. Project 2 could involve a new product or, possibly, a marketing research problem. Project 3 might concern the installation of a new, computerized, financial control system. All the while, the functional divisions continue on with their routine activities.

There is no single executive to whom PMs generally report. If a project is merely one of several in a specific program, the PM typically reports to a program manager, if there is one. It is not uncommon, however, for the PM to report to the manager of the functional area that has a particular interest in the program, or an interest in the project if it is not part of a program. If several projects on mathematics are being conducted for the Office of Naval Research (ONR), for instance, it would be normal for the PMs to report to the ONR section head for Mathematical Sciences. It is also common for PMs to report directly to the chief executive officer, the chief operating officer, or an executive vice-president in smaller firms with only a few projects.

At the other end of the spectrum of matrix organization is the weak matrix, one more like the functional organization. A project might, for example, have only one full-time person, the PM. Rather than having an individual functional worker actually assigned to the project, the functional departments lend capacity to the project. The PM might require engineering assistance, special software, product testing, or any other service that would be provided by the relevant functional unit. For example, the PM of a project set up to create a new database for personnel might request that the basic design be done by the systems analysis group in the administrative division. The personnel job would then be added to the normal workload of the systems group. The priority given to the design might be assigned by senior management or might be the result of negotiations between the PM and the head of the systems group. In some cases, the systems group's charges for the job might also be subject to negotiation.

Between these extremes, there are many different mixtures of project and functional responsibilities. When a functional group's work is frequently required by projects, it is common to operate the group as a functional unit rather than to transfer its people to the project. For instance, a toxicology unit in a cosmetic business, a quality assurance group in a multiproduct manufacturing firm, or a computer graphics group in a publishing firm might all be functionally organized and take on project work much like outside contractors. While the PM s control over the work is diminished by this arrangement, the project does have immediate access to any expertise in the group, and the group can maintain its technological integrity.

The impetus for the matrix organization was the fact that firms operating in high-technology areas had to integrate several functional specialties to work on a set of projects and wished to time-share expertise between individual projects in the set. Further, the technical needs of the projects often required a systems approach |11). In earlier times, when a high-technology project was undertaken by a firm, it would start its journey through the firm in the R & D department. Concepts and ideas would be worked out and the result passed on to the engineering department, which would sometimes rework the whole thing. This result would then be forwarded to manufacturing, where it might be reworked once more in order to ensure that the output was manufacturable by the firm's current machinery. All of this required a great deal of time, and the emergent project might have scant resemblance to the original specifications.

In the meantime, another firm would be doing much the same thing on another project for the customer. These two projects might later have to be joined together, ; or to a third, and the combination was then expected to meet its intended function. For example, the first project might be a jet aircraft engine, the second a weapon system, and the third an airframe. The composite result rarely performed as originally conceived because the parts were not designed as a unified system. Military aircraft buffs may recall several World War 11 aircraft that used the Allison in-line engine (designed by Rolls Royce). The P-39 (Airacobra) was a mediocre combat aircraft The P-38 (Lightning) was a fairly good plane. The P-51 (Mustang) was an outstanding combat machine. In all three cases, the engine, armament, and airframe were designed separately. In one case this approach to design worked well; in one it did not. A systems approach to design would require that engine, airframe, and weapon system be designed as a unit. The attempt is to optimize the composite System rather than the parts. This improves the chance of developing a P-51 and decreases the likelihood of making a P-39. Indeed, given the complexity of the systems going into a combat aircraft today, it is doubtful if a plane could be designed using the old methods.

The systems approach was adopted as an alternative to the traditional method described above. This did not mean that the same firm had to manufacture everything, but it did mean that one organization had to take responsibility for the integrity of project design—to make sure that the parts were compatible and that the combination would function as expected. This required that R&D, engineering, manufacturing, etc., work closely together, and that all these work closely with the client, all the while coordinating efforts with other firms that were supplying subsystems for the project.

Housing the project in a functional organization was simply too constraining. Setting it up as a pure project was workable but expensive because of the need to duplicate expensive technical talent when more than one project was involved. The matrix organization, which allows the PM to draw temporarily on the technological expertise and assistance of all relevant functions, was a way out of the dilemma. The effectiveness of the systems approach is well-demonstrated by the success of the Chrysler Corporation in designing and bringing to market their LH sedans (as A well as by their new, small car, the Neon, and their sports car, the Viper). The LH de- ^ sign was the product of a process called "concurrent" or "simultaneous" engineering i or design that involves marketing, engineering, manufacturing, design, quality assurance, and other departments working together from the outset. This process not only produced designs that have been widely rated as "outstanding," it also shortened the design-to-street process by about 18 months. Quite apart from the value of a fine design, the economic value of the time saved is immense. The value derives from two sources: less design labor and overhead as well as earlier sales and return on the investment. For a more complete description of the use of design teams at Chrysler, see (49|.

The matrix approach has its own unique advantages and disadvantages. Its strong points are:

1. The project is the point of emphasis. One individual, the PM, takes responsibility for managing the project, for bringing it in on time, within cost, and to specification. The matrix organization shares this virtue with the pure project organization.

2. Because the project organization is overlaid on the functional divisions, temporarily drawing labor and talent from them, the project has reasonable access to the entire reservoir of technology in all functional divisions. When there are several projects, the talents of the functional divisions are available to all projects, thus sharply reducing the duplication required by the pure project structure.

3. There is less anxiety about what happens when the project is completed than is typical of the pure project organization. Even though team members tend to develop a strong attachment for the project, they also feel close to their functional "home."

4. Response to client needs is as rapid as in the pure project case, and the matrix organization is just as flexible. Similarly, the matrix organization responds flexibly and rapidly to the demands made by those inside the parent organization. A project nested within an operating firm must adapt to the needs of the parent firm or the project will not survive.

• 5. With matrix management, the project will have—or have access to—representatives from the administrative units of the parent firm. As a result, consistency' with the policies, practices, and procedures of the parent firm tends to be preserved. If nothing else, this consistency with parent firm procedures tends to foster project credibility in the administration of the parent organization, a condition that is commonly undervalued.

6. Where there are several projects simultaneously under way, matrix organization allows a better companywide balance of resources to achieve the several different time/cost/performance targets of the individual projects. This holistic approach to the total organization's needs allows projects to be staffed and scheduled in order to optimize total system performance rather than to achieve the goals of one project at the expense of others.

7. While pure project and functional organizations represent extremes of the organizational spectrum, matrix organizations cover a wide range in between. We have differentiated between strong and weak matrices in terms of whether the functional units supplied individuals or capacity to projects. Obviously, some functional units might furnish people and others only supply capacity. There is, therefore, a great deal of flexibility in precisely how the project is organized—all within the basic matrix structure—so that it can be adopted to a wide variety of projects and is always subject to the needs, abilities, and desires of the parent organization.

The advantages accruing to the matrix structure are potent. Unfortunately, the disadvantages are also serious:

1. In the case of functionally organized projects, there is no doubt that the functional division is the focus of decision-making power. In the pure project case, it is clear that the PM is the power center of the project. With matrix organizations, the power is more balanced. Often, the balance is fairly delicate. When doubt exists about who is in charge, the work of the project suffers. If the project is successful and highly visible, doubt about who is in charge can foster political infighting for the credit and glory. If the project is a failure, political infighting will be even more brutal to avoid blame.

2. While the ability to balance time, cost, and performance between several projects is an advantage of matrix organization, that ability has its dark side. The set of projects must be carefully monitored as a set, a tough job. Further, the movement of resources from project to project in order to satisfy the several schedules may foster political infighting among the several PMs, all of whom tend to be more interested in ensuring success for their individual projects than in helping the total system optimize organizationwide goals.

3. For strong matrices, problems associated with shutting down a project are almost as severe as those in pure project organizations. The projects, having individual identities, resist death. Even in matrix organizations, projectitis is still a serious disease.

4. In matrix-organized projects, the PM controls administrative decisions and the functional heads control technological decisions. The distinction is simple enough when writing about project management, but for the operating PM the division of authority and responsibility inherent in matrix management is complex. The ability of the PM to negotiate anything from resources to technical assistance to delivery dates is a key contributor to project success. Success is doubtful for a PM without strong negotiating skills.

5. Matrix management violates the management principle of unity of command. Project workers have at least two bosses, their functional heads and the PM. There is no way around the split loyalties and confusion that results. Anyone who has worked under such an arrangement understands the difficulties. Those who have not done so cannot appreciate the discomforts it causes. To paraphrase Plato's comment on democracy, matrix management "is a charming form of management, full of variety and disorder."

Surefire Negotiation Tactics

Surefire Negotiation Tactics

Shockingly Simple But Powerful Negotiation Strategies Save The Ordinary Joe Thousands Of Dollars Of Foreseen Expenses. Discover How You Too Can Save More, Keep Under Your Budget, And Make More Money With These Simple Negotiation Tactics You Can Apply In Any Business!

Get My Free Ebook

Post a comment