Thursday, December 4, 2014

Scope Creep

Over the last few weeks, I have learned a great deal about project management and its perils.  One such peril is scope creep.  I wasn’t aware of that term until just recently, but I believe that it is one of the most important terms I have learned in a long while!  My experience with scope creep resulted from my own enthusiasm for a project and for wanting to do the best, most amazing and spectacular job that I could.  The “client” was a joint state and federal grant program for the creation of open source curriculum.  The requirements were rather simple and three years seemed like such a long time.  

I was not the project manager, but rather a team member responsible for developing and creating curriculum in my subject area.  To be truthful, there was no project manager and I believe that this is what contributed to the problem most of all.  Without that single point of control, that single point of grounding in reality, I was able to go beyond what was expected without regard to cost or time. 

The response to my spectacular offerings (and they really were spectacular!) was very good!  Rather than having a project manager to put on the brakes, I went full steam ahead with the encouragement of the stakeholders.  They had no idea of the amount of time and effort that these modules consumed, however.  I continued to work on this project until I realized that I had spent several months working on only a small part of a huge project!  The reality was that each module should have had days allotted, not weeks and months.  I panicked when I realized that I had lost a huge amount of time going beyond the requirements.  I spoke to my manager, scaled back my efforts to meet the grant requirements, and tried to catch up to the next milestone.

While I may not have met the unrealistic expectations that I created for the stakeholders, I did manage to fulfill the requirements of the grant on schedule.  I also learned some valuable lessons.

Portney, et al. (2008) discuss the need to manage scope creep by requiring a process be followed before any change is made to the scope.  All changes must be approved and the schedule must be adjusted as necessary to allow for the changes.  By managing scope, schedule, budget, expectations, and risk, the project manager can control scope creep (Lynch & Roecker, 2007). 

The most important lesson that came from that project is that somebody has to be the project manager.  There must be somebody who is keeping track and making sure that the project stays on course and doesn’t explode into a bigger project.  Or implode and fail.  I think that my near misses and failures of the past will come in handy if I am ever in a position to manage a project.  While project management has some aspects that can be learned in books and in seminars, I think the most important lessons are learned on the job in each success and misstep made along the way. 


Lynch, M. R. (2007). Project managing e-learning: A handbook for successful design, delivery, and management. London: Routledge.

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.

1 comment:

  1. There were a few lessons in your example. One is keeping adequate communication between team members to prevent what you experienced. Another is to properly define roles, the most important being the project manager to keep the team focused and grounded. Next is that scope creep isn’t necessarily due to bad luck or poorly handled tasks but can come from motivated, well-intentioned members of the team. This one stood out to me the most. I previously thought that scope creep was an intentional act of someone trying to get more out of a project than what they had originally negotiated (or pay less or do less work).

    The best news is that you learned these lessons and are now well-armed to lead teams to success without confusion or frustration.