The Suitability of Matrix Management for Development Projects
District Manager, Business Development
Ford, Bacon and Davis Co.
The term “matrix” is probably the most prevalent term currently used in management articles and lectures. One of the results of this proliferation of the term is that the accepted definition of matrix in the context of management or organization structure is apparently moving from being a unique concept toward a position of being only a buzz-word for any kind of team arrangement. Success stories relating improved productivity, product innovation, communications, coordination, etc., to the implementation of matrix are also prevalent. (Who wants to write about failures.) As part of this matrix proliferation many matrix articles focus on very narrow areas of application or desired outcomes without the traditional thoroughness of closely examining the task, the people, and the environment surrounding the two, for any proposed application.
The application of matrix management to development projects is well documented but the factors involved in the process leading to that determination, and matrix management itself, are much more complex than some articles would lead the reader to believe. The development process has some unique requirements from the standpoints of both organization structure and personnel, and the daily interaction of these requirements requires the constant attention of management to insure that both short-term and long-term objectives are met. Most literature fails to segregate the D from R&D; but when considering the suitability of an organization structure, development must be segregated from either research or engineering because of its different goals, constraints and unique personnel.
This article will define organization and personnel needs unique to the development process and how they may be influenced by organization structure. Attention will then be turned to matrix management and what success and problems might be expected when applied to development work.
Development Organization Structures
Several organization structures show promise for replacing or supplementing the functional organization to meet development needs. A product type structure is often found in the development end of the R&D spectrum. In its pure form the product group will consist of a team of technical people assembled in one unit on a semi-permanent basis to cope with whatever problems may arise concerning that product. This structure is well suited when most of the technical problems that arise can be handled within one unique area of product knowledge. Using this type of structure for development work improves the communication of goals between each person and leadership is easier since the product manager has close and direct control over individuals and costs. In addition, this close grouping provides the socialization aspect that is important to many individuals.
A project type structure can also be used in attacking multi-disciplinary development problems by assembling a project team of the necessary disciplines. This team is usually a temporary unit and the people, on completion of the specific project, are sent to another project or back into their specialized units. Project structures are beneficial when clearly identifiable objectives are definable and a project has strict limits with regard to time and cost. Communication is improved and setting priorities is simplified. Coordination and cooperation are key to performance in a project structure.
A process type structure appears to have limited applicability for development tasks except in a few areas where rather large continuing development work is performed on a specific process. This structure is again an attempt to shape the team unit to match the most typical scope of the problems encountered.
It would appear that some form of the product or project structure would be best for development work. Teamwork is achieved on multi-disciplinary problems. Maintenance of objectives and unity of leadership is attained. Expenditures can be controlled, established schedules can be maintained and priorities easily set. Communication between specialists is enhanced and each person is kept up-to-date on the overall project. But there are problems with these structures also. Maintaining satisfaction and preventing turnover of the scientists and engineers can be a problem when they are removed from their specialty groups. Availability of manpower to accelerate work is a problem, as well as equalizing the work among persons on the project, since they are all specialists. Keeping these people up-to-date in their specialties, as well as developing and improving their abilities in their fields is made more difficult by their isolation and isolation from their professional peers also diminishes opportunities for valuable cross-fertilization of ideas.
A study by Marquis(l) of 38 firms doing Government funded R&D projects tends to reinforce the previous findings. The study concludes that projects managed by functional organizations rated higher technically but usually had cost and schedule overruns. Those managed by project teams had improved performance meeting costs and schedules but rated slightly lower on the technical success of the project. The study indicates that some hybrid form of a functional and project organization where a small project team with some portion of the technical personnel remaining in their functional departments would be more likely to achieve technical excellence while also meeting cost and schedule milestones.
Another important factor that must be considered when determining the suitability of an organization structure is that to improve the development process by deeper specialization and closer coupling of people, one must consider both the physical and organizational arrangements by which the personnel are connected. If the personnel feel they are part of a common organization, a bond is invoked which encourages the commonality of purpose for focusing their effort. This barrier and bond concept(2) must be considered in development work since communications and the coordination of effort are so critical to success. Situations that set up both an organizational barrier and a physical barrier must be avoided if it can be done without undue perturbations to the people involved and the organization as a whole.
An in-depth investigation of coordination between R&D and the market(3) contains findings applicable to development and its integration within any firm. Two certainly applicable findings are: first, that the degree of harmony, joint involvement, and felt partnership between R&D and marketing were found to be significant determinants of project success or failure; and secondly, that almost all firms appear to have incidents of R&D and marketing coordination problems, with large firms having significantly higher incidents than the smaller firms. The findings indicate that in general, teams, task forces, and project systems were the most effective ways found to manage the required interfacing. Top-down management with formal, functional structures and paperwork systems were the least effective.
Any organization structure must be designed considering compatibility with the personnel as well as the tasks, and development personnel have some unique requirements. Since it is difficult to find a definitive study on development personnel, a contrast with research personnel in conjunction with my personal observations of development personnel with whom I have worked will provide some insight into their characteristics. The contrast can readily be made by reviewing a characteristic study(4) of research scientists. This study reveals that many scientists begin a pattern of isolation as children. It finds that future researchers typically have only one or two close friends interested in the same things they are interested in and are quite late in developing social activities. These individuals spend a major part of their time in reading and other intellectual activities, homework, listening to music and involvement in science clubs. Most research scientists when grown continue to follow these individualistic pursuits and are not team players. Only a few take an active part in political or civic organizations. Typical traits of the research scientist are: a high degree of autonomy, self-sufficiency, and self-direction; a somewhat distant or detached attitude in interpersonal relations; high ego-strength and emotional stability and a high degree of control of impulse with relatively little talkativeness or gregariousness.
In contrast to the research scientists, the development scientists and highly technical engineers do not need the isolation, freedom and autonomy that is indicated for the research scientists. Assuming they are comfortable in their chosen career path, they are going to have to be more applications oriented, more people oriented, and more goal oriented. If they need the autonomy and isolation a research scientist does, they will not remain in development. They will not be happy there and the development projects could not tolerate them for long.
The difference in research and development personnel can become very evident during the period of transferring technology from research to development. A very effective way to transfer the technology is for a senior researcher to move with the project for a period of three to nine months. During the phase of technology transfer from research to development and throughout the development phase, project leadership is critical to success. The development leaders must have broad technical competence to ensure efficient integration of the varying technical disciplines and continuity of the technical effort. But the development project leaders qualifications cannot stop there. If a project is successful it usually will be because of efficient utilization of people, money and time. Therefore, the project leader must be an individual who is not only scientifically competent, mature, reliable, and willing to work hard, but also knows how to manage people, time and money. Many research people are unwilling to give up the freedoms in their customary roles to perform this task; or if they do accept the assignment, find the time and money constraints, as well as the teamwork aspect, very difficult to handle.
The development personnel and their productivity are also affected by the psychological environment surrounding the project. The psychological environment is affected in part by formal management policies, but more often is controlled by informal social activities and rules within the group. It is the daily staff interaction and the perceptions of management attitude that are the main factors in this environment, so it appears that the organization structure will not have a major impact on this environment.
To summarize what appears to be required for development projects and personnel is a management structure that: ties together all the required specialized human resources but only on an as-needed basis; facilitates goal orientation and communication; enhances coordination and cooperation, and control of priorities, time and money; provides a nonrestrictive environment for personnel; and utilizes project leaders who are broadly competent both technically and managerially. This is quite an order to fill and a combination of all the above ingredients may be impossible to find in a real life situation, but having set the parameters, matrix design can be examined to determine its suitability for development projects.
Matrix Organization Design
The most widely publicized feature of a matrix organization is that some of the managers and other personnel report to two bosses or at least to separate bosses on different subjects rather than through single chains of command. Matrix designs attempt to overcome the difficulties encountered in more functionally structured organizations by reaching across organizational boundaries to integrate the functional activities needed for a particular problem or project. This allows the utilization of specialists without paying the typical penalties for high degrees of specialization.
To develop this form of matrix management requires more than a new organization chart. The simple act of drawing a line across an organization chart does not confer influence on anyone.(5) It establishes legitimacy but project leaders in a matrix structure become more influential because they and the department managers are evaluated by both the project and discipline managers and because the project specialists know they will be jointly evaluated by both their department manager and the project leader. There is joint determination of chances for promotion and salary increases based on joint evaluation of performance within the projects. This is the mechanism by which the matrix brings project influence to bear at lower levels in the organiza’tion. One does not have matrix management unless these joint evaluations take place. The desired effect is to create a power balance between department managers and project leaders, who often champion different sets of goals.
Advantages of a matrix organization are many and varied. Matrix facilitates conflict management by confrontation.(6) The matrix approach encourages technical conflict while bringing personal conflict out into the open where it can be dealt with. It creates an environment where people are willing to express independent ideas rather than conforming to the prevailing view. The advantage most often quoted is that this structure promotes the flexible use of specialized staff on multi-disciplinary programs. The matrix organization enables greater integration of specialized resources without organizing around self-contained programs, projects, or products and thereby avoiding either reduced specialization or the requirement for duplication of resources.
The matrix can facilitate communication between the competing interests of project and support departments and enable the bargaining between these departments to take place. This form of structure permits greater focus of resources allowing personnel to keep their attention directed on tangible performance outcomes. Additionally, the temporary nature and inherent flexibility of the structure provides great challenge and stimulation to some individuals.
The matrix also shares some advantages that are typical to most project organizations: delegation of authority and responsibility to the project leader, rapid exposure of problems and conflict, and better motivation of project team members because of their sense of identity with the group and understanding of their roles. In addition, there is an improved ability to make tradeoff decisions between cost, time, and performance.(7) Communication can be improved, not only among the project team, but also with upper management by putting the project managers in a direct relationship with the top executives and thereby eliminating information dilution and time delays by intermediate levels. This also has the effect of expanding the span of control of the executives.
Other shared advantages include: one person being responsible for all matters pertaining to the project; one point of contact for questions and answers regarding the work; a functional home to which project workers can return when a project is finished; specialized knowledge is not locked up in one project and is easily transmitted from project to project; the clearly defined central decision point makes the project team very responsive to changes in requirements in scope of work; and there is a built-in check and balance between time, cost and performance because of the required interaction between the team and support departments.
Naturally, there are disadvantages with the matrix structure. Constant effort is required by management to insure that neither project nor support staff gain the upper hand and overpower the other; and constant effort is required to insure the time, cost and performance goals of both the functional support and the project elements are balanced so neither favors cost or time over technical performance. Differences between functional managers and project leaders are highlighted when disputes over resources arise. These conflicts will develop, because inevitably a functional manager who is responsible for supporting a large number of projects will sometimes make decisions adverse to a project leader’s claim for support.
There are also disadvantages to the personnel in the matrix organization. The increased ambiguity concerning dual reporting to both a functional and a project manager may create very anxiety-arousing conflicts for the employees. In addition, the fluidity of the organization, while seen as a positive factor to some individuals, is seen by others as creating unnecessary frustration and destroying the stability they need in their environment. In addition, functional specialists with simultaneous assignments under more than one project leader will have their priorities set and re-set by several people. It appears that some individuals simply cannot function under these conditions.
It appears that true matrix management offers substantial improvement over functional structures for managing development projects and significant but lesser degree of improvement over project teams. Whether matrix management is “best” for development projects or not would have to be answered on an individual basis. Matrix management does appear to go a long way toward meeting both the organizational and personnel needs identified previously.
There appears to be two key ingredients in successful utilization of a matrix: first, upper management’s understanding and perception of a matrix and secondly, how it actually gets implemented. The matrix concept is deceivingly simple and therefore, the opportunity exists for erroneous assumptions about what it is and what is required to implement it. As with many management concepts, the matrix cannot be partially adopted if it is to be successful. An instructor of matrix management makes a point of distinguishing between a matrix organization and matrix management(8) by looking for four in-place elements: the organization structure; established procedures clearly spelling out who does what to whom; a matrix culture that encourages managers to follow the procedures; and matrix behavior consistent with company objectives. The first two can be promulgated by management; the second two must be given by the employees.
My own experience with the application of matrix management to development projects is that upper management readily accepts and implements the dual reporting system, because from an administrative standpoint that is relatively easy. But in a large organization upper management is not willing to insist upon the dual evaluation system nor provide the administrative policies to incorporate it. Without this key aspect of dual evaluation, the benefits of matrix management cannot be achieved, and the potential exists for designing an organization that will be much less responsive than a project or product team.
Davis and Lawrence(9) have recognized some of the most prevalent matrix problems and have recommended prevention measures. With regard to people feeling confused about who their boss is, they recommend that the organization not rely on an informal matrix to coordinate critical tasks, that relationships between functional and product managers must be explicit so people are in approximate agreement about who is to do what under various circumstances. Regarding power struggles within a matrix, three things are necessary: the matrix managers must maintain an institutional point of view, seeing the struggle from a shared perspective; they must jointly agree to remove weak matrix managers and replace them with the strongest people available to balance the power within the organization; and friendly competition should be encouraged, but conflict detrimental to the overall organization must be avoided.
The matrix also provides the potential for strangulation of the decision-making process, because personnel may view the matrix structure as requiring all decisions to be hammered out in large group meetings rather than by the key personnel involved. The decision process can be further strangled by an informal requirement that team members clear all issues with their functional bosses before agreeing to team decisions. This will lead to a constant escalation of conflict up through the dual chains of command and virtually bring activities to a standstill while a lengthy process of evaluation and decision making goes on at a higher level.
The advantages of matrix management certainly make it suitable for development projects, and development personnel are well suited to implement and work with it. But to be effective matrix management must be more than just project teams with lines drawn across an organization chart. It must be more than the buzz-word “matrix” stuck on a functional organization or used to describe any form of team arrangement that does not fit a current organization structure. To be successful matrix management requires more than management endorsement, it must have constant management involvement and it must have individuals in the dual reporting roles who are talented, comfortable with the arrangement, and completely committed to making the matrix work.
1. Marquis, Donald. A Project Team + PER T = Success. Or Does It? (Innovation, 1969)
2. Morton, Jack A. From Research to Technology (The R&D Game, Chapter 15. M.l.T. Press, November 1977)
3. Souder, William E. An Exploratory Study of the Coordinating Mechanisms Between R&D and Marketing as an Influence on the Innovation Process (Technology Management Studies Group, University of Pittsburgh, August 1977)
4. Roe, Anne. The Psychology of Scientists (The Management of Scientists, Chapter 2. Beacon Press, 1964)
5. Galbraith, Jay R. Organization Design (Addison-Wesley Publishing Co., 1977)
6. Hampton, David R.; Summer, Charles E. and Webber, Ross A. Organizational Behavior and the Practice of Management (Scott, Foresman and Co., 1978)
7. Blake, Stewart P. Managing for Responsive Research Development (W. H. Freeman and Co., 1978)
8. Sheridan. John H. Matrix Maze – Are Two Bosses Better Than One? (Industry Week, June 11, 1979)
9. Davis, Stanley M. and Lawrence, Paul R. Problems of Matrix Organizations (Harvard Business Review, May-June 1978)
ANALYSIS BAR CHARTING
- makes PERT/CPM as easy as ABC
- a simplified approach to the critical path method, using the new and improved precedence diagram method
- a concise and easy to read 100 page paperback book that is all you need to understand and be able to use modern CPM techniques
- more than 5.000 distributed in the last few years
- an excellent textbook for training programs
- recent quantity purchasers include American Can. Canadian Pacific. Celanese. International Engineers, Union Carbide. U.C.L.A.. U.S. Navy. U.S. Civil Service Commission. University of Wisconsin
- Contents: Introduction; Logic; Timing; Analyzing; Crashing; Scheduling; Control: Line of Balance; Managing: Training
|1-9 copies||$10.00 each|
|10-49 copies||$6.00 each|
|50-99 copies||$5.00 each|
|over 100 copies||$4.00 each|
postage included on pre-paid orders
payment must accompany single copy orders
MANAGEMENT PLANNING AND CONTROL SYSTEMS
5825 Rockmere Drive Washington. D.C. 20016  320-5806
PROJECT MANAGEMENT SUPPORT SERVICES
PROJECT and BUSINESS SYSTEMS
Pragmatic cost saving
Wally Kruse KRUSE, INC.
Sparks, NV 89431
Message relay –