The "Creeping Death" of Scope Creep

Oftentimes when you are working on a project, there comes a time when either some new policy or technology is introduced that can change the scope of the project mid-stream.  On other occasions, there is a desire to change the project as it currently stands because either the project manager, the project team or specific clients/stakeholders do not think the output is acceptable in its current form.  This is defined as "Scope Creep" (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008).  Lynch & Roecker (2007) define scope creep as uncontrolled changes in the scope of a project or course as it was originally defined.  Regardless of how you define it, scope creep can cause serious problems with a project if not handled properly.

I have experienced this first hand, as I'm sure many instructional designers have, when designing a course for our cyber security master's degree program.  In this case, we began development of the course with one instructor but he was replaced with another instructor after we had already completed about 40% of the course development.  As you can probably guess, the new instructor wanted to change everything that had been developed previously because he didn't agree with the initial instructor's approach.  Naturally, this was a tad frustrating to myself as the project manager and the rest of the team because we were not given any additional time to complete the project, the deadline remained the same.

Specifically, the scope creep occurred mainly in the areas of assessment design.  As mentioned, we had already completed about 40% of the course, and had designed and developed assessment activities for those completed modules.  Now we were required to design and develop entirely new assessment activities which took longer than we figured it would because the new instructor was very exacting about how he wanted them presented.

As the project manager, I had to take a step back and assess the situation.  First and foremost, I worked to follow the steps laid out by Greer (2010): stay calm and pinpoint the exact change.  I must admit that i did fail somewhat on the first one because of the lack of flexibility on the deadline.  However, I did finally manage to stop throwing a tantrum and get down to work identifying exactly what the change was and defined what it meant.  Portny, et al. (2008) mention creating a change control system to handle scope creep and its ramifications.  This was something I did not do at this time but, having read about it in the text, believe it certainly would have assisted me and the rest of my team in dealing with the creep.  Another factor that Greer (2010) mentions is obtaining sponsor approval of changes and the corresponding changes to the project development plan.  This would have certainly gone a long way to help all of us, especially if the deadline had been revised to accommodate having to go back and re-work large sections, but no approval an altered deadline was forthcoming so we were stuck trying to get everything done in a much shorter span than we had hoped.  The end result was, while the course launched on time, none of us felt that it had the quality it could have had if our deadline had been extended just a week or two.

References

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

Lynch, M. M., & Roecker, J. (2007). Project managing e-learning: A handbook for successful design, delivery, and management. London: Routledge.

Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). Project management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc.