Analyzing Scope Creep

This week’s blog assignment is to describe a project that experienced issues related to scope creep. I’m fascinated by people who make money from blogging, but since I’m not there yet, I’m pretty sure that whomever is reading this post is probably in my project management class, so you may have read a bit about the project I have chosen to share, especially if you are part of discussion group 2. The project is one that I have witnessed from the periphery – it is actually a project that my husband is currently on, but since he works from home, and has been on the project for 18 months, I have experienced it as a spectator, and most recently, as a project management student.

The project in question involves a company changing from one accounting system to another. Seems pretty cut and dry, but it has actually been anything but that – this project was originally scheduled to be completed by February 2014, but due to issues related to scope creep, the project is nowhere close to being complete (and since the beginning of this week, things have gotten even more interesting).  Scope creep is defined as “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, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008, p. 346) – “avoiding scope creep is not possible” (Portny et al., p. 347), but it is manageable.

The project began in the spring of 2013, and it was in early 2014 that the project began experiencing scope creep. At that time, it was discovered that not all of the business information was within the current system – the people who used the system utilized spreadsheets and SharePoint to store data as well; therefore, in order to convert to the new system, the project team had to look beyond the current system as their only source of data to convert into the new system. As these extra data points were discovered, the project team kept adding them as project tasks. These extra tasks started to add up, which caused the first delay in the schedule, which in turn impacted the budget (for example, my husband’s contract had to be extended). Scope creep occurred because the project did not have a change control system, something that Portny et al recommend should be included “in every project plan” (Portny et al.,  p. 347) and something that I would have insisted on from day one if I would have been the project manager.  I would also have recommended that there be a formal process to submit any change requests, and that all requests be approved in writing, something that Portny et al recommend as well (Portny et al, 2008).

This one example of scope creep in this project has created a domino effect – the project has been delayed several times, there have been four project managers, and the overall morale of the team is not good. All of this affects the ultimate goal of the project – to convert from one accounting system to another – on schedule, on budget, and within scope.

After this week, I think that I will have enough examples from this one project to take me through my entire project management class. One of the two lead business analysts on the project resigned, the other BA will be on vacation for almost three weeks starting the end of the month (just as the other BA is leaving the company), and the 4th PM has decided not to return once their contract is up at the end of the month. It is my understanding that there is no plan in place to deal with all of this. Scope creep is almost sure to strike again!



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.


10 thoughts on “Analyzing Scope Creep

  1. Jennifer, I enjoyed reading your post. It reminded me of work I did in helping to set up an accounting system for an organization that closed its manufacturing division and moved its sales division about 600 miles up the Atlantic coast. It also relates to some recent job ads I saw in which a director of was sought, as it seems an ERP conversion become more challenging than anticipated. As I have said before, some job ads in this field read like an organization seeking a truck driver who has experience driving a Chevrolet, Ford, or other make. Cheers! Steve

  2. Jennifer, nice post.
    I remember commenting on this in the discussion board last week.
    One thing they need to do is create a requirements traceability matrix, this will outline all tasks and align them to a specific project requirement. Next they need to organize them in a development schedule and probably break them down into mini-releases. Don’t know if he is familiar with the AGILE development approach, but this will allow them to get small wins and see movement as far as completing tasks. The schedule will also allow the PM to manage expectations and provide a clear direction of what is expected. What is the name of this company, if the job is virtual, I should apply to help them out.
    Nice post, tell your husband good luck, and reach out to me if he has questions.
    Derrick –

    • Derrick,
      This project has to get done because it is tied to compliance with federal regulations, otherwise, I think it would have (and should have) been abandoned a long time ago. Thanks for your input!


  3. Jennifer
    I think that is so awesome that you are able to experience your husband’s project as a spectator and student! My husband runs a business from our home so a lot of the things he talks about I can now relate to this course. My husband actually went through something similar with his business trying to transfer information from one system to another, and of course it was NOT SIMPLE AT ALL! This was awhile ago and I do not know much about it. I do know my husband was constantly stressed, talking to people from different companies as well as other people in his business. My husband thought it seemed like the right move for his business, but he did not anticipate all of the hurdles he encountered. It took much longer than he planned or hoped. Thanks for sharing!

  4. Hi Jennifer,
    Your post scared me a little, I couldn’t imagine dealing with so much stress, no end in sight. I am in complete agreement with your emphasis on a formal change process plan, especially since change happens so frequently, no matter how controlled the project may seem. As Lynch & Roecker (2007) indicated, uncontrolled changes happen, which is why the scope needs to be controlled through regular meetings as well as proper definition and documentation of the change. Why were there so many project managers? Did they tend to step on one another’s toes a lot? How did the team handle all of the extra tasks? Were they just assigned to team members as they popped up? Did they have any kind of risk management plan in place?

    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.

    • Andrea,
      The first three were good fits, and the fourth one came to their senses and realized that the project is beyond help.
      As for the extra tasks, they took on what they could in order to keep the project going, but that required quite a bit of re-prioritization, which did have an affect on the schedule and budget.


  5. Jennifer,

    It sounds like this project has come with its challenges. The added data points, and staffing issues, only created to the complexity of this project. Your example reminds me of my own personal experience with conversion from one system to another. It reminds me of the importance having a control system, that incorporated all of the essential project risk management elements recommended by Portny, et. al. (2008). These situations lead me to ask, at what point was it realized that these changes would affect the project schedule and cost, and was that increase in cost going to possible jeopardize the project completion.

  6. Jennifer,
    What a great example of scope creep. It reminds me of this project where I used to work. The project was to internally build a system that would handle our customers internally and externally. So this was a huge project that had to be built from the ground up. There were many setbacks, scope creep, new management, various project managers and too many phases to count. I think what you mentioned about having a formalized place to document changes wanted/needed would have helped this project as well. Sometimes with project delays especially in my case was that it was never fully done right the first time. The amount of work and resources needed to get this project done was more like a 5 year project than 2. I wonder how many times that happens in situations like you have described as well.

  7. Hi Jennifer,

    I really enjoyed reading your post on analyzing scope creep! This sounds like a nightmare. I agree with your assessment that a change control system definitely needs to be put in place for this project. Have they considered freezing all changes so that the project can move forward? In IT, a code freeze is enforced to reduce the frequency of changes and helps the project forward toward a release. A code freeze is utilized to reduce risks and no changes are permitted to the software system (Tekiela, 2013). On some occasions, later versions of the software are released and enhancements and changes to the system are included in these releases.


    Tekiela, R. (2013). Do you need a code freeze? Retrieved from

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s