This paper circulates around the core theme of Continental Computer Corporation case study together with its essential aspects. It has been reviewed and purchased by the majority of students thus, this paper is rated 4.8 out of 5 points by the students. In addition to this, the price of this paper commences from £ 99. To get this paper written from the scratch, order this assignment now. 100% confidential, 100% plagiarism-free.
Continental Computer Corporation “We have a unique situation here at
Continental,” remarked Ed White, Vice President for Engineering. 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? Continental Computer Corporation
(CCC) was a $9 billion a year corporation with worldwide operations
encompassing just about every aspect of the computer field. The growth
rate of CCC had exceeded 13 percent per year for the last eight years,
primarily due to the advanced technology developed by their Eton
Division, which produces disk drives. Continental is considered one of
the “giants” in computer technology development, and supplies equipment
to other computer manufacturers. World headquarters for CCC 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 Eton Division, which manufactures
disk drives, the Lampco Division, which is responsible for Department of
Defense (DoD) contracts such as for military application, satellites,
and so on, and the Ridge Division, which is the primary research center
for peripherals and terminals. According to Ed White: 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 Lampco Division is by far
the oldest, having been formed in 1989. The Lampco Division produces
about $2 billion worth of revenue each year from DoD funding. Lampco
utilizes a pure matrix structure. Our reason for permitting the
divisions to operate independently was cost reporting. In the Lampco
Division, 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, cost-reimbursable
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 Lampco Division.
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 Lampco Division is that because of the technology
developed in some of our other divisions, Lampco must subcontract out a
good portion of the work (to our other divisions). Not that Lampco 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
Lampco Division used to consider themselves as aerospace engineers, not
computer engineers, and were thankful for employment and reasonable
salaries. But now the Lampco 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 Eton Division. 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 Continental. 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 Eton Division. So we’ve
developed a consultant category. Now the word has spread and all of our
engineers are applying for transfer to the Eton Division so as to become
eligible for this new pay grade. In the Lampco Division 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 Lampco
Division. 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 Lamco 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 Eton Division, 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 support 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 Eton Division 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 mangers 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 cany 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 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 Ridge Division 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 division 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 $50,000 for
short-term seed money. That $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
Ed Whte’ 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 Ed White now left people with the notion that
there may be more pressing problems. QUESTIONS 1. Is it common for
companies to maintain two or more sets of books for cost accounting? 2.
Is the matrix structure well suited for the solution to the above
question? 3. Why do most project management structures find the
necessity for a dual ladder system? 4. Should companies with several
different types of projects have a uniform procedure for planning
projects? 5. Is it beneficial to have to take conflicts up two or three
levels for resolution? 6. Should project managers be permitted to talk
to the customer even if the project is in support of a product line? 7.
Should corporate R&D be decentralized? 8. What is meant by seed
money? 9. How does control of seed money differ in a decentralized
versus a centralized R&D environment? 10. Should the failure of a
“grass roots” project affect an employee’s opportunity for promotion? 1
1. If you were the vice president of either engineering or R&D,
would you prefer centralized or decentralized control? 12. In either
case, how would you handle each of the previously defined problems?
