Analyzing Scope Creep

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.


One thought on “Analyzing Scope Creep

  1. Marta,

    What an excellent example of problems often faced by project managers, coming in the middle of a project. In an ideal world we would get the time to plan the project from the start, assess all the risks, establish communication paths, and control scope creep. Portny, Mantel, Meredith, Shafer, Sutton, and Kramer (2008) note that exponentially more time needs to be allotted for communication as the size of the project team grows. With forty people on the team and no clear communication lines, you seem to have inherited a project that was doomed for failure. You might have benefited from a couple of tools recommend by Stolovich (n.d.) had they been provided for you. A scope sign-off sheet and requiring each request in writing might have reign the project back in. As with may projects I have worked on you seem to have been thrown in to this situation without the necessary time for planning. Sounds to me like you did a great job with what you were given.

    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.
    Stolovich, H. (n.d). Monitoring Projects. Presented for Laureate Education, Inc. Retrieved April 10, 2013, from /portal/frameset.jsp?tab_tab_group_id=_2_1&url=%2Fwebapps%2Fblackboard%2Fexecute%2Flauncher%3Ftype%3DCourse%26id%3D_2652514_1%26url%3D

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