Xynet Development Incorporated Zacharey Stevens, Vice President for Engineering said "We have three divisions within throwing distance of one another, and each one operates differently. This poses a problem for us at corporate headquarters because career opportunities and administrative policies are different in each division. Now that we are looking at project management as a profession, how do we establish uniform career path opportunities across all divisions?" Xynet Development Incorporated (XyDevInc) was a USD 9 billion a year corporation with worldwide operations encompassing just about every aspect of the computer field. The growth rate of XyDevInc had exceeded 13 percent per year for the last eight years, primarily due to the advanced technology developed by their Falls Spring Section, which produces disk drives. XyDevInc is considered one of the "giants" in computer technology development, and supplies equipment to other computer manufacturers. World headquarters for XyDevInc is in Concord, Illinois, a large suburb northwest of Chicago in the heart of Illinois's technology center. In addition to corporate headquarters, there are three other divisions: the Falls Spring Section, which manufactures disk drives, the Mayhem Section, which is responsible for Department of Defense (DoD) contracts such as for military application, satellites, and so on, and the Fine Prints Section, which is the primary research center for peripherals and terminals. According to Zacharey Stevens: Our major problems first began to surface during the early nineties. When we restructured our organization, we assumed that each division would operate as a separate entity (i.e., strategic business unit) without having to communicate with one another except through corporate headquarters. Therefore, we permitted each of our division vice presidents and general managers to set up whatever organizational structure they so desired in order to get the work accomplished. Unfortunately, we hadn't considered the problem of coordinating efforts between sister divisions because some of our large projects demanded this. The Mayhem Section is by far the oldest, having been formed in 1989. The Mayhem Section produces about USD 2 billion worth of revenue each year from DoD funding. Mayhem Section utilizes a pure matrix structure. Our reason for permitting the divisions to operate independently was cost reporting. In the Mayhem Section, we must keep two sets of books: one for government usage and one for internal control. This was a necessity because of DoD's requirement for earned value reporting on our large, costreimbursable contracts. It has taken us about five years or so to get used to this idea of multiple information systems, but now we have it well under control. We have never had to lay people off in the Mayhem Section. Yet, our computer engineers still feel that a reduction in DoD spending may cause massive layoffs here. Personally, I'm not worried. We've been through lean and fat times without having to terminate people. The big problem with the Mayhem Section is that because of the technology developed in some of our other divisions, Mayhem must subcontract out a good portion of the work (to our other divisions). Not that Mayhem can't do it themselves, but we do have outstanding R&D specialists in our other divisions. We have been somewhat limited in the salary structure that we can provide to our engineers. Our computer engineers in the Mayhem Section used to consider themselves as aerospace engineers, not computer engineers, and were thankful for employment and reasonable salaries. But now the Mayhem engineers are communicating more readily with our other divisions and think that the grass is greener in these other divisions. Frankly, they're right. We've tried to institute the same wage and salary program corporate-wide, but came up with problems. Our engineers, especially the younger ones who have been with us five or six years, are looking for management positions. Almost all of our management positions in engineering are filled with people between thirty-five and forty years of age. This poses a problem in that there is no place for these younger engineers to go. So, they seek employment elsewhere. We've recently developed a technical performance ladder that is compatible to our management ladder. At the top of the technical ladder we have our consultant grade. Here our engineers can earn just about any salary based, of course, on their performance. The consultant position came about because of a problem in our Falls Spring Section. I would venture to say that in the entire computer world, the most difficult job is designing disk drives. These people are specialists in a world of their own. There are probably only twenty-five people in the world who possess this expertise. We have five of them here at XyDevInc. If one of our competitors would come in here and lure away just two of these guys, we would literally have to close down the Falls Spring Section. So we've developed a consultant category. Now the word has spread and all of our engineers are applying for transfer to the Falls Spring so as to become eligible for this new pay grade. In the Mayhem Section alone I have had over fifty requests for transfer from engineers who now consider themselves as computer engineers. To make matters worse, the job market in computer technology is so good today that these people could easily leave us for more money elsewhere. We've been lucky in the Mayhem Section. Most of our contracts are large, and we can afford to maintain a project office staffed with three or four project engineers. These project engineers consider themselves as managers, not engineers. Actually they're right in doing so because theoretically they are engineering managers, not doers. Many of our people in Mayhem Section are title-oriented and would prefer to be a project engineer as opposed to any other position. Good project engineers have been promoted, or laterally transferred, to project management so that we can pay them more. Actually, they do the same work. In our Falls Spring Section, we have a somewhat weird project management structure. We're organized on a product form rather than a project form of management. The engineers are considered to be strictly supported for the business development function, and are not permitted to speak to the customers except under special circumstances. Business development manages both the product lines and R&D projects going on at one time. The project leader is selected by the director of engineering and can be a functional manager or just a functional employee. The project leader reports to his normal supervisor. The project leader must also report informally to one of the business development managers who is also tracking this project. This poses a problem in that when a conflict occurs, we sometimes have to take it up two or three levels before it can be resolved. Some conflicts have been so intense that they've had to be resolved at the corporate level. The Falls Spring Section happens to be our biggest money maker. We're turning out disk drives at an incredible rate and are backlogged with orders for at least six months. Many of our top R&D engineers are working in production support capacities because we cannot get qualified people fast enough. Furthermore, we have a yearly turnover rate in excess of 10 percent among our engineers below thirty years of age. We have several engineers who are earning more than their department managers. We also have five consultant engineers who are earning more than the department managers. We also have four consultant engineers who are earning as much as division managers. We've had the greatest amount of problems in this division. Conflicts continuously arise due to interdependencies and misunderstandings. Our product line managers are the only people permitted to see the customers. This often alienates our engineering and manufacturing people, who are often called upon to respond to customer requests. Planning is another major problem that we're trying to improve upon. We have trouble getting our functional managers to make commitments. Perhaps this is a result of our inability to develop a uniform procedure for starting up a program. We always argue about when to anchor down the work. Our new, younger employees want to anchor everything down at once, whereas the poor project managers say not to anchor down anything. We, therefore, operate at all levels of the spectrum. We can carry this problem one step further. How do we get an adequate set of objectives defined initially? We failed several times before because we couldn't get corporate agreement or understanding. We're trying to establish a policy for development of an architectural design document that will give a good front-end definition. Generally we're O.K. if we're simply modifying an existing product line. But with new product lines we have a problem in convincing people, especially our old customers. The Fine Prints Section was originally developed to handle all corporate R&D activities. Unfortunately, our growth rate became so large and diversified that this became impractical. We, therefore, had to decentralize the R&D activities. This meant that each division could do their own R&D work. Corporate then had the responsibility for resolving conflicts, establishing priorities, and ensuring that all divisions are well-informed of the total R&D picture. Corporate must develop good communication channels between the divisions so that duplication of effort does not occur. Almost all of our technical specialists have advanced degrees in engineering disciplines. This poses a severe problem for us, especially since we have a pure traditional structure. When a new project comes up, the project is assigned to the functional department that has the majority of the responsibility. One of the functional employees is then designated as the project manager. We realize that the new project manager has no authority to control resources that are assigned to other departments. Fortunately, our department managers realize this also, and usually put forth a concerted effort to provide whatever resources are needed. Most of the conflicts that do occur are resolved at the department manager level. When a project is completed, the project manager returns to his or her former position as an engineering member of a functional organization. We've been quite concerned about these people that continuously go back and forth between project management and functional project engineering. This type of relationship is a must in our environment because our project managers must have a command of technology. We continuously hold in-house seminars on project management so as to provide our people with training in management skills, cost control, planning, and scheduling. We feel that we've been successful in this regard. We are always afraid that if we continue to grow, we'll have to change our structure and throw the company into chaos. Last time when we began to grow, corporate reassigned some of our R&D activities to other divisions. I often wonder what would have happened if this had not been done. For R&D projects that are funded out of house, we generally have no major management problems for our project managers or project engineers. For corporate funded projects, however, life becomes more complex mainly because we have a tough time distinguishing when to kill a project or to pour money into it. Our project managers always argue that with just a little more corporate funding they can solve the world's greatest problems. From the point of view of R&D, our biggest problems are in "grass roots projects." Let me explain what I mean by this. An engineer comes up with an idea and wants some money to pursue it. Unfortunately, our division managers are not budgeted for "seed monies" whenever an employee comes up with an idea for research or new product development. Each person must have a charge number to bill his time against. I know of virtually no project manager who would out-and-out permit someone to do independent research on a budgeted project. So the engineer comes to us at corporate looking for seed money. Occasionally, we at corporate provide up to USD 50,000 for short-term seed money. That USD 50,000 might last for three to four months if the engineer is lucky. Unfortunately, obtaining the money is the lesser of the guy's problems. If the engineer needs support from another department, he's not going to get it because his project is just an informal "grass roots" effort, whereas everything else is a clearly definable, well-established project. People are reluctant to attach themselves to a "grass roots" effort because history has shown that the majority of them will be failures. The researcher now has the difficult job of trying to convince people to give him support while continuously competing with other projects that are clearly defined and have established priorities. If the guy is persistent, however, he has a good chance to succeed. If he succeeds, he gets a good evaluation. But if he fails, he's at the mercy of his functional manager. If the functional manager felt that this guy could have been of more value to the company on a project basis, the he's liable to grade him down. But even with these risks, we still have several "seed money" requests each month by employees looking for glory. Everyone sat around the gable listening to Zacharey Stevens' comments. What had started out as a meeting to professionalize project management as a career path position, uniformly applied across all divisions, seemed to have turned into a complaint session. The problems identified by Zacharey Stevens now left people with the notion that there may be more pressing problems.

Questions

1. Examine the implications of keeping two or more sets of books for cost accounting.

2. It is not uncommon for companies to have multiple projects, should they have a standard procedure for planning projects? Why or why not?

3. Should project managers be permitted to talk to the customer even if the project is in support of a product line?

4. R&D is vital to keep the company's competitive edge. If you were the vice president of either engineering or R&D, would you prefer centralized or decentralized control? Explain exhaustively.

5. In either case, how would you handle each of the previously defined problems?