Management control in an engineering matrix organization: a project engineer's perspective.
Engineering companies commonly use a matrix organization structure for managing their projects. In such an organization, there are the normal well-defined line and staff functions, as well as additional functions that cross traditional lines. What is created is an alternate, dynamic organization within the semi-static one. Matrix organizations are usually created to work on projects in which personnel are borrowed from the various functional organizations.
The implementation and use of these structures differs among companies. The political strength or technical expertise of different groups and people plays an important part in their development. Not surprisingly, even within a single company the matrix organization may be handled quite differently from one project to another.
In this article, we'll look at an engineering matrix organization and the management controls used by its focal person, the project engineer (also called a matrix manager). This person must cope with behavioral problems that result from acquiring personnel from another line function to work temporarily in a project or matrix function. A conflict arises when people report to their line managers but work for and take direction from project engineers who workers may not perceive to be their valid superiors. This is especially the case if the employees cannot adapt to a different management style and when allegiance is still with their line managers. Problems with planning and scheduling occur because of the multitude of projects being worked on simultaneously, each with its own project engineer and functional personnel. Assigning priorities is necessary in order to complete each project on schedule.
A matrix organization is essentially a project-type structure that is superimposed on a functional structure. It is often used in organizations facing environmental uncertainty and is found in technical organizations where technical expertise must be grouped for complex short- or long-term projects. Special teams are formed with the personnel borrowed from functional groups, and when the project is complete the workers return to their respective groups. The matrix organization design provides the flexibility required to work critical projects, while preserving the advantages of classical design and adding the strengths of the neoclassical design. The important principles of the classical organizational design include division of labor, centralization of authority, unity of control, and unity of direction. On the other hand, the neoclassical design approach is less formalized and centralized to allow for individual uniqueness and creativity.
Aerojet ElectroSystems Company is divided by product line and has a division for each major product. Operations, engineering, and various staff report to the general manager. The engineering portion has the most matrix structures (figure 1), and its four key areas are systems engineering (figure 2), design engineering (figure 3), project engineering, and advanced systems and technology. Design engineering consists of mechanical design, analysis groups, drafting, configuration management, and technical publications. Project engineering includes test engineering, whereas advanced systems and technology performs research and development and is frequently involved in the proposal effort. Within each organization are functional groups headed by managers having a number of engineers reporting to them. Basically, work is generated internally by the division or obtained from other divisions need extra help or advice in certain functional areas.
An engineering matrix work flow diagram (figure 4) shows the flow and direction of tasks to be performed. Typically, for a project, customer requirements are negotiated with program management. Then, a program directive is written and a program manager and project engineer are assigned. The project engineer receives direction and guidance from the director of engineering. This director also sets the standards and the policies of the entire engineering organization. Operations also receives direction and coordinates its activities with project engineering.
Project engineers have the responsibility of allocating the work required to the respective functional areas. After an initial meeting, assignments and required overall schedules are given to managers or lead engineers. These people, in turn, assign one or more people in their groups to the project. The appointed matrix manager (project engineer) is responsible for scheduling, cost, and technical performance. Project engineers have authority to ask for a project's status and can give technical guidance, but have no line authority.
Generally, they do not participate in the personnel reviews, nor do they provide input for merit increases. They have no authority to scold engineers for improper behavior, such as coming in late or taking too long for lunch. Many times, because of a closer working relationship, the matrix managers are considerably more aware of behavioral problems than the line managers. However, if undersirable behavior affects their projects, it will be taken to the line managers for appropriate action.
Projects usually require the expertise of a variety of technical backgrounds, and when projects are finished, the team members return to their respective functional groups. Thus, the functional groups are essentially technical pools from which to draw manpower as needed. There are, however, a variety of areas that can be sources of problems.
Matrix organizations can create behavioral problems when people do not understand or refuse to accept their structure. Line managers can be especially troublesome and unreasonable with their demands. For instance, after a subordinate is assigned to a project, the project engineer may be prohibited from working directly with that person and all communication must be routed through the line manager. The project engineer does not have the authority to override the line manager except through elevation (discussed later), and is thus thrust into the unfortunate position of being responsible for a task without the necessary authority. If the project engineer must work with the line manager, rather than the project engineer, about every detail of the project, inefficiency in cost and schedule will prevail. Interference by line management muddles the accuracy and timeliness of communication, causing valuable time to be lost clarifying matters and correcting erroneous information. Still, it is essential that the line managers be consulted on crucial items and be kept updated by the subordinate and the project engineer as well.
To prevent chain-of-command problems from occurring, a clear directive--not open to interpretation by the informal organization--should be issued to all parties affected. The director of engineering must ensure that the formal policy is followed, as well as mandating that line managers be kept informed as to the progress of existing projects and consulted when new projects require workers. Possible exceptions are when the person assigned to the job is inexperienced and not sufficiently competent to make the proper decisions, or if there is a personality conflict--such as when the project engineer is an offensive or unfaur person who bullies workers. Then, by acting as a buffer, line managers can be effective in alleviating potentially explosive situations.
In cases where workers are less-than-delighted about taking orders from someone other than their immediate superiors, the employees become the problem. Flagrant acts, such as not doing the work or completely ignoring the project engineer's requirements, will quickly be referred to the manager for remedial action. However, intermittent stalling and mild uncooperative behavior can be just as disastrous, but harder to bring to the attention of line managers. Because the line manager is not intimately involved in the project, it is difficult for him or her to have an accurate enough picture to know when the workers are sandbagging. The tendency to believe and support subordinates decreases the project engineer's effectiveness. This problem is solved by:
* Establishing rapport with and among workers.
* Allowing the project engineer to participate in employee evaluations.
* Working only with cooperative people, that is, hand-picking the team.
Rapport, the most effective and frequently used solution, takes a lot of practice, but does not always work. Differences in management styles and personalities can create conflicts. Problems frequently arise when the matrix manager is not versatile or flexible enough to handle personality differences. Project engineers are required to change their styles--one style may be highly effective with one person, but not with another. For instance, a program manager demands of the project engineer a resolution to a problem by a certain date. The date may be achievable, but the project engineer may resist because of what is perceived to be abrasive behavior. On the other hand, a less aggressive approach would not be effective with another person as some people require more than a gentle nudge to motivate them to perform. For the most part, people with good personalities and technical backgrounds can earn the respect of co-workers. The ideal situation is for people to want, but not be forced, to work for a specific project engineer.
Line managers may rely only on their own impressions of their employees and not take into account input from the matrix managers when formulating personnel appraisals. Matrix managers may be much more familiar with the quality of work generated by the engineers than the line manager, and should take part in the appraisal program. If the employees know that matrix managers participate in their appraisals and subsequent merit increases, they have more incentive to be cooperative.
If the engineer assigned to a project is not acceptable, a different one can be requested, assuming that the original engineer is not the only one technically competent for the project. Requests for a new person might also be accommodated as a result of schedule delays. Still, attitudes are important, as sooner or later the project engineers have to accept workers who are not quite what they had in mind.
Scheduling is especially troublesome because matrix organizations require borrowed line personnel. Many projects are being worked simultaneously, and a person is likely to be working more than one project at a time, with each project handled by a different project engineer. Scheduling projects and keeping them on track can be very difficult. A standard question is: "How long will it take you to finish the job if it was the number one priority and how long will it take you if it's not?" The answer gives the matrix manager the project's earliest and latest promise dates. A modification is required when the need and the promise dates are incongruent. Possible solutions include talking with the other matrix managers, negotiating for more time, or achieving priority for the project. Higher-level management establishes project priority taking into consideration the company's overall benefit. If top priority cannot be established, escalation or slippage of the completion date may be required. Putting slack in the schedule can be effective, but workers catch on to such a tactic quickly, and if it is used too often they will cease paying attention to established due dates.
Other possible solutions are working overtime, soliciting outside help, or asking the line manager for replacement or additional engineers. Many times, no one is available with the necessary expertise or they cannot be brought up to speed quickly enough to meet scheduling demands.
Mathematical models, utilizing probabilities and simulations, can be helpful in solving complex scheduling problems. Still, the probabilities must be estimated, and the accuracy tends to be highly questionable.
Although good communication is essential, matrix organizations tend to suffer from too many meetings. Politics, power struggles, and establishing authority encourage meetings. Some meetings are very productive, but unfortunately, many meetings are too frequent and unnecessary--the functional group holds a status meeting, the project group holds a status meeting, the program manager holds a status meeting, and on and on. Valuable time could be saved by merging some of the meetings, as most of the same people are involved in all of them.
The chairperson is responsible for creating a productive meeting. A well prepared agenda which is rigidly followed can reduce wasted time. Encouraging quiet people to participate and talkative persons to be quiet increase the quality of meetings. One innovative project engineer cut meeting time by 50 percent when he resorted to "stand-up" meetings with no refreshments.
Controls are more complicated and less formalized in a matrix organization than in a line organization.
Policies and directives: These establish authority in the organization and should be in writing. In the case of Aerojet, a description of each organization's responsibilities are written in the division's engineering directives. Figure 5 explains the project engineering functions. For a particular project or proposal effort, documents called program directives and requests for proposal are generated by the program office. Program directives establish the project's responsible parties. Authority is also established by the company culture and practices, which sometimes can be more powerful than written policy. Although the technical direction officially comes from the project engineer, if that person is not very authoritative or does not have the proper technical expertise, the actual technical direction may come from another member of the project team.
Meetings: As mentioned earlier, meetings can be effective or inefficient. The initial meeting gathers all pertinent personnel together, relays necessary information, establishes authority, and authorizes work to begin. Regularly held status meetings help the project engineers to stay current on activities being performed. Meetings are also scheduled when the project engineer feels that it is necessary to increase communication between different groups, to resolve particular issues, for brainstorming, or to establish the impact of and reasons for schedule or cost overruns.
Schedules: Requesting schedules from people for work they are performing makes them commit in writing to a set of goals and allows project engineers to monitor progress. When key areas or milestones are indicated on the schedules, the project engineers can gauge accomplishments. If the milestones or the time frame is not acceptable, they can be negotiated or changed.
Visibility reports and status reports: These reports sometimes take the place of status meetings and help determine when actual meetings are needed. They direct the project engineer's attention to problem areas. Reports are also required to officially close-out a task.
Cost or schedule variances: Aerojet's system meets the requirements imposed on government contracts. The functional group's cost account manager prepares reports which compares actual with planned activities. Over- or underruns are reported in terms of cost and schedule along with explanations of important variances. Thus, the project engineer can determine if a particular group is overspending or failing to achieve desired results. Possible explanations may be that the job was underbid or the correct people are not working on the job. Underspending or behind schedule accounts may be indicative that the project is not receiving the priority it deserves.
Personal observation and personal contact: Status reports can be camouflaged to relay distorted information and tend to be poor motivators. Personal contact, whether it be for requests, direction, questions, compliments, and even criticisms is usually better than written or telephone communication. Some people respond better to one-on-one oral communication than to group meetings. Individual discussions bring out items of importance, confusion, conflict, and misunderstanding. Most subordinates like to see their superiors; therefore, project engineers can produce favorable responses and increase productivity by just making an appearance periodically.
Choosing the team: Being able to choose the most technically qualified, efficient, and easiest people to work with is an ideal way to meet technical, cost, and schedule requirements. Unfortunately, unless the project is crucial to the well-being of the company, choosing the team personally may not be possible. Project leaders need to recognize that they cannot and will not have perfect human beings on their teams all the time. Flexibility and understanding promote improved working relations.
Elevation: It is generally best to avoid this, but when used properly it is extremely effective. Elevation (also called escalation) is "going over someone's head." Higher-level management is consulted and line managers become involved with the matrix managers. It is often the last resort and should be limited to matters of extreme urgency. If used frequently, it becomes meaningless, extremely inefficient, and it may be lead people to believe that the project engineer is incompetent.
Rewards or "atta-boys": These are control tools used to reward employees by giving them recognition for a job well done. A reward system makes employees strive harder even when not working directly for their line managers because they know that excellence will be noticed. The rewards, which often take the form of a verbal commendation or interoffice memo, are referred by the project engineer to the line managers so that the latter are aware of their employees' contributions and can incorporate them in the formal appraisals.
Personal influence: This category includes diplomacy, respect, rapport, leadership, sense of humor, level-headedness, and other personal attributes needed to do the job. This probably is the most important and the most difficult to learn and use. The project engineers' ability to use diplomacy to resolve issues, to maintain the functional engineers' respect, to establish rapport, to take charge, to bring on resolutions, and yet remain a likeable person, are very important to the success of a matrix organization. Constant pressuring and a tyrannical approach are usually not the best leadership styles, even though sometimes they bring immediate results. Eventually, behavioral problems will surface. Engineers will quit, refuse to work for them, become extremely resentful or not perform at their best. Project engineers must be constantly aware of the fact that they do not have direct authority over the workers assigned and that they are directing highly educated people who have ideas of their own.
Despite matrix organization's disadvantages, large engineering companies rely on them to meet the requirements of numerous projects, each with a different scope and completion date. The varied technical expertise of the project team and the changing projects make the matrix structure an effective addition to the line functions. Although problems of too many bosses and conflicting priorities occur, undesirable repercussions can be minimized with sound management controls.