Thursday, August 2, 2012

Project Scope Creep

I am the director of customer service for a software company in North Carolina. Although I typically do not act as a project manager for our software projects, I do function in an account management role. This means that I manage the customers that are undergoing software projects with us. This gives me an indirect window into our project process. From my perspective, scope creep happens after the project scope and deliverables are defined and commitments in resources, schedule and funds have already been allocated. As our project team works to complete the project deliverables, the customer’s expectations often increase above what was originally defined.
This happens unusually often within our software projects especially with respect to timelines and work statements. For example, the original software development project was projected to take 500 hours to complete. Half way into the 500 hours, the customer realizes that the functionality originally scoped does not “do” exactly what they want it to “do.” The project manager is looking at another 200 hours of work to complete the software design based on the customer’s expectations. Now, the project manager is faced with either delivering less than expected, or the project will be completed much later than planned. Software project managers often call this type of scope creep “feature creep”.
Internally, we often discuss “who is to blame” for certain projects going off track. Sometimes, the customer is blamed because they were not clear on what they wanted. That could be the case I guess, but I see it as an issue with our software development team. (Ok—hear me out). Our programmers and analysts are top notch. They are smart and conscientious about their work. All of them want to do a stellar job for the customer. As they start working on a project, they are constantly thinking about ways to make the design better or more efficient. These are small tweaks, here and there, but creative ideas to help the customer achieve their result in the best way possible. Well, these little tweaks and features add up, and before you know it, the project design exceeds the project scope. It becomes a snowball effect because the customer gets excited about what they are seeing in their new software design. This sparks new discussions about other areas that can be made better and so on. This snowball makes the project run longer and eventually cost more than originally planned. The hardest part for the project manager is that these “feature” conversations can happen outside of standard project communication. When the PM finally hears about the new ideas, it is too late to stop the giant snowball.
Everyone on the team needs to be responsible for scope creep. The project manager certainly does not want to stifle creativity, but the creative ideas need to be brought to the project manger first. Dr. Stolovich (n.d.) advises that when new ideas come up, the team members should fill out a Change of Scope document. By following this communication protocol, the submitter understands that the feature will not added until it is approved. The PM can discuss the changes with the customer and together they can make a collective decision on whether the idea is worth adjusting the scope of the project. This communication protocol makes managing the customer's expectations much easier for the project manager.
Stolovich, H. (n.d.). Project Management Concerns: ‘Scope Creep’. [Video]. Retrieved from


  1. Julie,

    Great post! Scope creep is something that every project manager needs to be aware of and prepared to respond to it. In the example you provided, you mentioned that the project manager hears about the new ideas when the scope creep is already inevitable. This is a sign for the project manager to establish a formal control and monitoring system in the next project to avoid the scope creep from impacting the timeline, resources, and budget in the project. In addition, the project manager should think about creating a risk management and change control system to be prepared for unexpected events that can cause delays in the project schedule, going over budget, or adding more resources to the project. Most importantly, establishing an effective communication system helps in keeping everyone involved informed at all times which gives everyone a chance to deal with changes before is too late. Gube (2008) suggests the following tips to avoid scope creep:
    • Accept that scope creep will happen
    • Commit enough time to requirements-gathering
    • Giving a hand might cost you your arm
    • Be the devil’s advocate when changes are requested
    • Be task-oriented, not vision-oriented
    • Shed the “Customer is Always Right” mentality
    • Research before committing
    • Realize that feature creep is a two-way street

    I believe these are good suggestions for any project manager to know how to avoid and deal with scope creep. Moreover, I believe that we need to accept that scope creep most likely will happen; however, the best strategy is to plan for it and be prepared.


    Gube, J. (2008). Eight tips on how to manage feature creep. Six Revisions. Retrieved from

  2. Julie,
    Sounds like an interesting job. I can see how scope creep can happen with this project especially with the amount of people that are involved with the project. Communication will be a big part into this project. It is important that the PM know every aspect of the project so that each person that is involved in the project is on the same page.

  3. Julie

    It sounds like you work with some very talented programmers, and that they do need additional steps to stay within their "swim lane" as I watch the Olympics :)
    Sometimes talented, motivated people see a need, and decide to fill it. While this is great, and like you mentioned, no one wants to stifle creativity, it does have consequences that could ultimately turn away customers who are having to pay more than originally intended. I also agree with Stolovich (n.d.) when he mentions that even the best laid plans are made, so that they can be changed. So, if the project manager goes into all projects with this understanding, and is a mediator between the customer and programmers when a Change of Scope is requested, then hopefully a win-win situation can be found for all involved.

    Stolovich, H. (2012). [Video Program].Communicating with stakeholders. Laureate Education, Inc.

  4. Hey Julie,

    like you said scope creep is everyone responsibility. From the top down the proper procedures need to be in place. There can't be different rules for those in upper management or for the client. As long as the procedures are in place and used the amount of scope creep can be minimized and monitored.