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.