Specifically, in the context of scope creep, I am going to re-analyze the week two blog project. At the University of Southern California (USC) I run the technology for the USC Libraries. One of the groups I manage brings in digital collections of interest to USC as a “cloud archive” service to digitize, preserve, catalog and provide access to collections of interest to USC. This group is called the USC Digital Repository (http://repository.usc.edu). One of the collections we brought in was from a large studio and consisted of all of their TV and Film in digital form.
We had set up a yearlong pilot to prove the design and technologies to be employed would work. However, after we had signoff on the project, a peer studio to the one we were working with got hacked severely (https://www.washingtonpost.com/news/the-switch/wp/2014/12/18/the-sony-pictures-hack-explained/). This generated scope creep as the security team was asked to look at the project and added a number of new requirements and technology changes.
Scope creep can be business related or technical. It can be externally generated or internally generated. In this case it was both, and the downstream scope creep by adding in additional security enhancements was unknown yet significant (Kerzner, 2001, pp. 1145-1150).
The client did not want to go through a yearlong pilot again to prove the technology would work under the new security requirements. A design was created, and the client signed off on the design knowing there was more risk that it might not work. What we should have done at this point was create a full risk management plan (Piscopo, 2015, http://www.projectmanagementdocs.com/project-planning-templates/risk-management-plan.html#axzz44secUFGo). There are a number of items that would have helped with managing the new scope. Just prioritizing the risks would have made the project go faster, as we knew we were heading into rough territory. Interviews between the primary content team and security team would have made many of the issues that came up much smoother. If we had stopped to look at historical projects performed by the security team, some of their requirements could have been relaxed, and we could have understood the repercussions of some of the new requirements in ways that would have let us finish the tasks faster. Labeling the new risks in a risk register and monitoring them in a way that was visible to all of the teams would have been enormously helpful and exposed where additional efforts were starting to greatly extend the project.
In the end, it took us almost an extra year to work through the security issues as we deployed the digital collection system that would bring in Petabytes of data to our archives. Having a proper risk mitigation plan would have made the project far less stressful and possibly move faster.
References
Kerzner, H. (2001). Project management: A systems approach to planning, scheduling, and controlling. New York: John Wiley.
Beach, L. (2006). Leadership and the art of change. Thousand Oaks, CA: Sage Publications, Inc.
Laureate Education (Producer). (n.d.b). Practitioner voices: Overcoming ‘scope creep’ [Video file].
Piscopo, M. (2015). Risk Management Plan. Retrieved June 08, 2016, from http://www.projectmanagementdocs.com/project-planning-templates/risk-management-plan.html#axzz44secUFGo.
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.Bottom of Form
EDUC 6145 