This week our blog topic is the ever-scary topic of scope creep, here’s our blog assignment:
Describe a project, either personal or professional, that experienced issues related to scope creep. What specific scope creep issues occurred? How did you or other stakeholders deal with those issues at the time? Looking back on the experience now, had you been in the position of managing the project, what could you have done to better manage these issues and control the scope of the project?
So let’s first start with the question, “what IS scope creep?”
According to our required text, scope creep is “the natural tendency of the client, as well as project team members, to try to improve the project’s output as the project progresses” (Portny, et al., 2008, p. 350). Another definition that truly hits the nail on the head so to speak is, “the tendency of a project to include more tasks or to implement more systems than originally specified, which often leads to higher than planned project costs and an extension of the initial implementation date” (What is scope creep, 2007).
In my previous position we took part in a deployment of a case management system that was implemented enterprise-wide. This deployment was a high-profile effort and everyone on my team was expected to travel to support the deployment effort. In the end our team was responsible for training the application, supporting that application (providing field support, as well as support via phone/email), providing support documentation, designing/developing/implementing another training module to later replace the in-person training. What is interesting is our contract did not originally include all of these provisions esp. with a staff of only 8 people (most of which were on the road).
These issues, and the many that arose as a result, were almost always dealt with in a defensive and reactive (vs. proactive) manner. It seemed we were always reacting to a new development, and/or a new client request that simply came out of nowhere.
In the government contacting realm this is always precarious territory as a contractor never wants to tell the client “no”. This could possibly result in the client seeking a contract with another organization, and no company wants to lose business (i.e. revenue).
Looking back, I feel a lack of documentation was one important area that could have been done better. Meaning, many of our processes were undocumented including change requests. Without documentation it is difficult to see what is in existence, what is being requested, what has been changed, and the results of the requested change. From a project management stand point our organization left themselves very open for later problems to arise.
In an article entitled, “10 Ways to Tackle The Scope Creep”, Miles Burke provides important ways to avoid scope creep:
References
Burke, M. (2010, November 26). 10 Ways to Tackle the Scope Creep » SitePoint. SitePoint » Web Design, Web Development, Freelancing, Tech News and more. Retrieved October 13, 2011, from http://www.sitepoint.com/10-ways-tackle-the-scope-creep/
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.
What is Scope Creep?. (2007, October 10). FollowSteph.com . Retrieved October 13, 2011, from http://www.followsteph.com/2007/10/10/what-is-scope-creep/
