Kemko Manufacturing BACKGROUND Kemko Manufacturing was a 50-year-old company that had a reputation for manufacturing hig

[answerhappygod]

Kemko Manufacturing BACKGROUND Kemko Manufacturing was a
50-year-old company that had a reputation for manufacturing
high-quality household appliances. Kemko's growth was rapid during
the 1990s. It grew by acquiring other companies. Kemko now had more
than 25 manufacturing plants throughout the United States, Europe,
and Asia. Originally, each manufacturing plant that was acquired
wanted to maintain its own culture, and quite often each was
allowed to remain autonomous from corporate at Kemko provided that
work was progressing as planned. But as Kemko began acquiring more
companies, growing pains made it almost impossible to allow each
plant to remain autonomous. Each company had its own way of
handling raw material procurement and inventory control. All
purchase requests above a certain dollar value had to be approved
by corporate. At corporate, there was often confusion over the
information in all of the forms since each plant had its own
documentation for procurement. Corporate was afraid that, unless it
established a standardized procurement and inventory control system
across all plants, cash flow problems and loss of corporate control
over inventory could take its toll in the near future. PROJECT IS
INITIATED Because of the importance of the project, senior
management asked Janet Adams, director of information technology
(IT), to take control of the project personally. Janet had more
than 30 years of experience in IT and fully understood how scope
creep can create havoc on a large project. Janet selected her team
from IT and set up an initial kickoff date for the project. In
addition to the mandatory presence of all of her team members, she
also demanded that each manufacturing plant assign at least one
representative and that all plant representatives be in attendance
at the kickoff meeting. At the meeting, Janet said: I asked all of
you here because I want you to have a clear understanding of how I
intend to manage this project. Our executives have given us a
timetable for this project and my greatest fear is scope creep.
"Scope creep" is the growth of or enhancements to the project's
scope as the project is being developed. On many of our other
projects, scope creep has lengthened the project and driven up the
cost. I know that scope creep isn't always evil and that it can
happen in any life cycle phase. The reason why I have asked all of
the plant representatives to attend this meeting is because of the
dangers of scope creep. Scope creep has many causes, but it is
generally the failure of effective up-front planning. When scope
creep exists, people generally argue that it is a natural
occurrence and we must accept the fact that it will happen. That's
unacceptable to me! There will be no scope changes on this project,
and I really mean it when I say this. The plant representatives
must meet on their own and provide us with a detailed requirements
package. I will not allow the project to officially begin until we
have a detailed listing of the requirements. My team will provide
you with some guidance, as needed, in preparing the requirements.
No scope changes will be allowed once the project begins. I know
that there may be some requests for scope changes, but all requests
will be bundled together and worked on later as an enhancement
project. This project will be implemented according to the original
set of requirements. If I were to allow scope changes to occur,
this project would run forever. I know some of you do not like
this, but this is the way it will be on this project. There was
dead silence in the room. Janet could tell from the expressions on
the faces of the plant representatives that they were displeased
with her comments. Some of the plants were under the impression
that the IT group was supposed to prepare the requirements package.
Now Janet had transferred the responsibility to them, the user
group, and they were not happy. Janet made it clear that user
involvement would be essential for the preparation of the
requirements. After a few minutes of silence, the plant
representatives said that they were willing to do this and it would
be done correctly. Many of the representatives understood user
requirements documentation. They would work together and come to an
agreement on the requirements. Janet again stated that her team
would support the plant representatives but that the burden of
responsibility would rest solely on the plants. The plants would
get what they ask for and nothing more. Therefore, they must be
quite clear up front in their requirements. While Janet was
lecturing to the plant representatives, the IT team members were
just sitting back smiling. Their job was about to become easier, or
at least they thought so. Janet then addressed the IT team members:
Now I want to address the IT personnel. The reason why we are all
in attendance at this meeting is because I want the plant
representatives to hear what I have to say to the IT team. In the
past, the IT teams have not been without some blame for scope creep
and schedule elongation. So, here are my comments for the IT
personnel:  It is the IT team's responsibility to make sure that
they understand the requirements as prepared by the plant
representatives. Do not come back to me later telling me that you
did not understand the requirements because they were poorly
defined. I am going to ask every IT team member to sign a document
stating that they have read over the requirements and fully
understand them.  Perfectionism is not necessary. All I want you
to do is to get the job done.  In the past we have been plagued
with "featuritis," where many of you have added in your own bells
and whistles unnecessarily. If that happens on this project, I will
personally view this as a failure by you, and it will reflect in
your next performance review.  Sometimes people believe that a
project like this will advance their career, especially if they
look for perfectionism and bells and whistles. Trust me when I tell
you this can have the opposite effect.  Back-door politics will
not be allowed. If any of the plant representatives come to you
looking for ways to sneak in scope changes, I want to know about
it. And if you make the changes without my permission, you may not
be working for me much longer.  I, and only I, have signature
authority for scope changes.  This project will be executed using
detailed planning rather than rolling wave or progressive planning.
We should be able to do this once we have clearly defined
requirements. Now, are there any questions from anyone? The battle
lines were now drawn. Some believed that it was Janet against the
team, but most understood her need to do this. However, whether the
project could work this way was still questionable
Using the Kemko Case, you will need to perform the below
actions:
1. Make a Microsoft Project Task Sheet, assign resources to the
tasks - create the Task Sheet, and include the durations (assume
the project begins today), create fictitious team members, assign
them the tasks, and include the Predecessors column.
2. Perform risk analysis on the case provided.
2. Determine the probability and impact of at least 6 risks.
3. List the risk descriptions, the risk owner, contingency
plans, response strategies, triggers
I want the following deliverables :