A project that comes to mind that involved an issue with scope creep is a project where a campus housing application/assignment system was being implemented. The project process (bidding on and choosing a vendor) began in December of 2008 but really got on its feet in April of 2009. The main objective was to have the system in place in time in order to take housing applications and make campus housing assignments for the Fall 2010-Spring 2011 academic year. Things were running pretty smoothly, therefore stakeholders became very interested in pushing to have the system in place to take applications for the Summer 2010 session as well. Pushing for this early of a release was an issue because the project was to be implemented in certain phases. And there were certain components and integrations that where scheduled to be implemented during the time that applications and assignments for summer housing would normally be taken and made. In other words, if the stakeholders wanted to move forward with using the new system for the Summer session, it would cause the remaining originally scheduled project processes to be hurried in order to have all components functioning in time for Summer 2010 usage.
Some of the stakeholders at the time were disappointed that the possibility of advancing the system that early was slim to none because the new system had been the buzz for a while and they were very amped up about making the new technology available to users as soon as possible. Therefore, it a little difficult for them to accept "no" as an answer. I think that the PM of this project, handled this situation of scope creep fairly well. The PM immediately made it evident that the risk of jumping so far ahead was too high. Rushing to integrate with this new system, systems that were very important to the campus' operations, was not the best thing to do and if anything went wrong while trying to do so, it could really set the project back and even possibly cause the original deadline to be missed.
If I were in control of the project the only thing that I probably would have done differently was constantly remind the stakeholders and team members of the project's goals and why the objectives and schedules were set as they were. It's important to refresh one's memory of the project's goals and boundaries and make sure he or she has a clear of what the desired results should be at points relative to deliverables, schedules, costs and quality (Greer, 2010).
References
Greer, M. (2010). The project management minimalist: just enough pm to rock your projects. Laureate Education Ed. Retrieved February 10, 2011, from http://sylvan.live.ecollege.com/ec/courses/56607/CRS-CW-4744643/educ_6145_readings/pm-minimalist-ver-3-laureate.pdf
