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 plantrepresentatives, 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 : 1. The . mpp file 2. Risk Management Plan