Thursday, October 13, 2011

Project Management 6145 Week 6-Analyzing Scope Creep

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:


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

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). . Retrieved October 13, 2011, from


  1. Audrea:

    I do empathize with you, and the other members of your team, for the extra work which resulted from the additions to the project deliverables and work processes. You indicated that “new client requests simply came out of nowhere”. Greer (2010) and Portny et al (2010) recommend the establishment of a change control system for dealing with changes in scope requested by project stakeholders (p. 35; p. 346). In fact, you cited lack of documentation is an area that could be improved. This is consistent with the literature on the subject as both Portny et al (2008) and Greer (2010) indicate that changes in scope should be formally documented and approved by the client/sponsor (pp. 346-346; pp. 35-36). Additionally, Dr. Budrovich, and Greer (2010) also alluded to the tendency of sponsors to suffer from temporary amnesia, where changes of scope are concerned. They strongly emphasized that these stakeholders should “sign a document acknowledging the scope change and its rationale (Laureate Education Inc.; pg. 36). Thanks for providing us with the 10 ways for tackling scope creep. It actually reminds me of the steps to handle scope creep presented by Greer (2010) on page 36. Hope you would find the time to read the section of the text. Thanks for sharing your experience with us.
    Greer, M. (2010). The project management minimalist: Just enough PM to rock your projects! (Laureate custom ed.). Baltimore: Laureate Education, Inc.

    Laureate Education, Inc. Walden University. (2011).“Practitioner Voices: Overcoming ‘Scope Creep’” [Video Webcast]. Retrieved from:

    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.

  2. Yes, documenting the impact of potential risk along with change requests is an important step. The next step that I would recommend is the implementation of the Communication Plan. The communication plan will allow the PM to identify and deliver information to the necessary sponsors and stakeholder using a preferred method. “Alerting the sponsors and stakeholders to potential changes in the project is preferable to having them become aware of the changes when they become a major problem” (Lynch & Roecker, 2007).

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

  3. Thank you both for the feedback!

    Sonia, you are correct change control methods were never/rarely ever in place within our contract. I am unsure how/why this originated but our projects did not contain an WBS, an SOW, or a contingency plan. I am unsure if this is due to the nature of our work or the relationship with the client.

    Interestingly there was definitely one moment in which "temporary amnesia" occurred on the part of the client. I specifically remember a meeting in which the client stated "A" and the next meeting he stated "B", luckily I had notes from the previous meeting in which I could present and note the change on behalf of our team, but a formalized method of documentation would have been better. The look on the client's face when I pointed out their error was priceless, and I'm sure I could have deployed a bit more diplomacy as Dr. Stolovitch recommended in the Communicating with Stakeholders video. This leads me to the the point(s) D. Stephens presented.

    D. Stephens, I definitely agree that a communication plan would have been very effective in this situation. As a contractor we often have so many "bosses" and "POCs" its hard to know/remember how to communicate and with whom. In the Project Management Concerns: Communication Strategies & Organizational Culture video a key point that was made was "document the outcomes of meetings". Dr. Stolovitch also includes this important point as one of the two things to remember-document everything!

    As I briefly mentioned above, I feel a reason these formal steps were not done is due to the foundation that was already established. Not to make excuses of course, but with the pressure of the project and an anxious client this may have been a reason to "cut corners"