I was once assigned to “manage” a project that involved the conversion of a customers’ billing process system (both computerized and manual operational processes) from one vendor that was handling the process to another vendor. This was my first project management assignment and I was assigned to the project months after it had already begun – a sure sign of trouble at first sight. Among numerous other issues, scope creep was the biggest. My clients represented the product and marketing divisions of the company in three different countries, including the United States. There were approximately forty people in the project; marketing managers, product managers, functional managers, programmers, analysts, testers, call center managers, consultants, and the people from the two vendors we were working with. Prior to my arrival, any request related to the project (new/change) from the clients and other stakeholders had been submitted directly to the functional managers of the development team (with no centralized process for the project). At times, clients would even directly contact the developers (programmers/analysts) to request changes. So when I got on board, despite my objection, the expectation remained the same – request would go directly to the functional manager(s) and the functional manager(s) will fit it in his/her group’s schedule, without any impact analysis to the overall project. And with each request, the scope of the project kept expanding with no clear end in sight. Every meeting I conducted ended up being an issues log review as opposed to an overall project progress meeting. I realized later on that my role was not necessarily managing the project but managing and keeping track of issues. It was frustrating and overwhelming but a learning experience nevertheless.
Looking back at the experience, the project was way beyond my skills and experience as a project manager at the time. It was a big project and my role was not clearly defined. Had I truly been the “project manager” and had had the experience and emotional maturity to stand firm by what I believed was good for the project, I would have requested time to pause and to re-assess the project up to that point. Then along with the influential stakeholders determined a path; i.e., continue with the project by taking corrective actions – which would have meant developing and adhering to a detailed plan that included a scope management process. If agreement could not be reached on the corrective actions, and if I had had a choice I would have advised against pursuing the project. Unfortunately (or may be fortunately), due to a re-organization of my division, I moved on to a different organization before the project was completed. I am not certain what happened to the project at the end.
Scope creep in a project is unavoidable. However, with proper project planning that includes a “change control system” as discussed in (Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008, ch. 11) a PM can manage scope creep effectively and lessen the risk of project failure.
Thank you for reading.
Portny, S. E., Mantel, S. J., Meredith, J. R., Shafer, S. M., Sutton, M. M., & Kramer, B. E. (2008). (ch. 11). Project Management: Planning, scheduling, and controlling projects. Hoboken, NJ: John Wiley & Sons, Inc.