Kemko Manufacturing was a fifty-year-old company that had a reputation for the manufacturing of high-quality household appliances. Kemko’s growth was rapid during the 1990s. The company grew by acquiring other companies. Kemko now had more than twenty-five 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 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 of the 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 thirty 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 of the plant representatives must be in attendance as well at the kickoff meeting. At the kickoff meeting, Janet spoke:

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 elongated 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 upfront 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 upon 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 upon the plants. The plants would get what they asked 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 portion of the team was just sitting back smiling. Their job was about to become easier, or at least they thought so. Janet then addressed the IT portion of the team:

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 requirement 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 requirement 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 perfection 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 Janet’s need to do this. However, whether it could work this way was still questionable.

QUESTIONS

1. Was Janet correct in the comments she made to the plant representatives?

2. Was Janet correct in the comments she made to the IT team members?

3. Is it always better on IT projects to make changes using enhancement projects or should we allow changes to be made as we go along?

4. What is your best guess on what happened?