Analyzing Scope Creep

Assigned to a project team developing six different courseware programs ICW Level I and ILT/CAI for a client, there were some specific scope creep issues that occurred during the course of the project. One issue was the PM lacked the experience to deal with the size of the project. An inexperienced PM not controlling or managing the project resulted in losing control allowing stakeholders to shift project goals and project scope. Another issue was adding extra hours to complete tasks as each stakeholder provided different features to include in the courseware.  A third issue was the clients requesting courseware functionality for Level II and Level III training at the same cost of Level I training. Lastly, the project requirements, objectives, and scope of the project were not accurately defined resulting in ambiguous or open interpretation of the project. All four issues resulted in scope creep. According to Lynch and Roecker (2007), “Scope creep refers to uncontrolled changes in the requirement of the course as defined in the scope definition of the project management plan (p. 96).”

The stakeholders dealt with the scope creep issues by continuously being indecisive on the design and development of the courseware resulting in changing the project requirements and project scope. The project team began working longer hours to meet the new requirements with the same resources and same time allocated for the project. Scope creep involved additional deliverables and requirements that were not properly reviewed and documented. The PM finally realized that the client’s new requirements were not agreed upon in the project charter or project management plan and the project began drifting away from its original intent impacting the scope, quality, resources, time, and budget. It is almost impossible for changes not to occur on a project, but not properly managing and controlling the changes can cause project failure.

Looking back at the project, if I were assigned the role as the PM, I would first ensure that the scope definition and project requirements were properly defined and agreed upon between all stakeholders and myself (PM). Then, host the project kickoff meeting to establish the roles and project accountability for all stakeholders to keep the project on track. Any new client requirements outside the agreed project management plan, I would clearly communicate the impact of scope creep (any project changes will impact the scope, quality, resources, time, and budget of the original project). Finally, is having a Configuration Management (CM) change control process in place. The POC for the project are the only personnel authorized to make a project change requiring a signed approval and updated project documents.

Sometimes we need to say “no” if the changes have a negative impact and add no value to the training effort. Change of scope is normal; it’s not necessarily a problem. In fact, a scope change can be beneficial when they allow the project team to respond sensibly to changing conditions that exist outside the project (Greer, 2010, p. 35).

Enjoy this humorous video on scope creep and see if you can identify some scope creep issues. The PM has lost control of managing the project. The environment of the organization seems to be a top-down approach.

References

Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects! (Laureate custom ed.). Baltimore: Laureate Education, Inc.

Lynch, M. M., & Roecker, J. (2007). Project managing e-learning: A handbook for successful design, delivery, and management. London: Routledge. Copyright by Taylor & Francis Group, LLC. Reprinted by permission of Taylor & Francis Group, LLC via the Copyright Clearance Center.

YouTube. (2011, January 16). Scope creep – project management. Retrieved from https://www.youtube.com/watch?v=AHSjpFUKQR4