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.
References
Stolovich, H. (n.d.). Project Management Concerns: ‘Scope Creep’. [Video]. Retrieved from http://mym.cdn.laureate-media.com/Walden/EDUC/6145/02/downloads/WAL_EDUC6145_02_C_EN-CC.zip
