This week we were to look back to project we may have been involved with that ran into scope creep. According to Pinto (2007), scope creep is defined as “the continual reassessment and change of a project’s original specifications” (p. 147).
Early in my career I was involved as a functional team member (planning department) in a large project where the company was implementing an MRP system. My involvement was to gather and document process data from end-users within the department. This was then given to the project team. The only other part of the project that I was involved in was training end users; this happened about a month before we were casually told of the go-live date in an email. Anyway, at this time I was then trained to train the end-users in system transaction and other coding. The system went ‘live’, on the date given, running parallel to the old system, but heard that there were still a number of ‘bugs’ that needed to be worked out. No one actually told us this – no memo, nothing – at the department or end-user level. If I recall, end users had the option to still use the old system, which many did, even while being trained in the new one. This went on for a time (with some users, even the department manager, reverting to the old system and processes completely). And then one day came to work and the old system was gone! Well, you can imagine some of the chaos among the planning department personnel. Training needed to be redone, and I think some sections or modules of the old system were reinstalled temporarily. In short, the training and other jobs were done twice which meant a lot of extra work for the users, and who knows at what cost to the company! Still related, even when the new system was fully running, eventually departments were requesting IT to make ‘modifications’ or tweaks to certain areas within specific modules. Eventually, the system no longer resembled the system that was implemented and a few years later this system was replaced as it was no longer reliable due to too many modifications.
Looking back on the experience I think the management of these issues could have been improved and there could be better control defining the scope of the project. My guess is that some of the issues resulted from a poorly conceived project scope and poorly defined statement-of-work. A well-defined project scope details not only the development of the project plan but also the quality standards to be maintained and outcomes of the project (Pinto, 2007).
Another area was not involving end-users early on or through the phases of the project. Like I mentioned, for the most part, the project was a mystery until the very end. I do not think much consideration was taken to how the end-users would react to leaving on a Friday and coming back on Monday to a new system. As we learn throughout this program involving all stakeholders is important in requirement analysis and throughout the design phases. I think there was also a lack of change control. While there may have been an expectation of scope creep, I am not sure clear processes were in place to anticipate and manage the modification requests or how the modification in one module would affect other modules. For example, one addition of a phantom department so a transaction could be skipped could cause huge inventory discrepancies within the system, which in turn, adversely affect production planning, scheduling and other areas. This could have been managed by implementing a few guidelines (as defined by Portny, Mantel, Meredith, Shafer, Sutton, & Kramer, 2008) :
- Include a change control system in every project plan.
- Insist that every project change is introduced by a change order that includes a description of the agreed-upon change together with any resulting changes in the plan, processes, budget, schedule, or deliverables.
- Require changes be approved in writing by the client as well as by a representative of senior management.
- Amend and update all project plans and schedules to reflect the change after the change order has been approved.
Following this process changes could have been introduced and objectives accomplished without causing a rash of issues (Protny et al., 2008). Control systems can also ensure change is conducted systematically and throughout the lifespan of the project (Pinto, 2007). In the project I was in, certainly design controls would have been helpful, along with configuration control.
Here are some helpful hints from projectmanagervideos to prevent scope creep (projectmanagervideos, 2012).
Pinto , J. K. (2007). Project management: Achieving competitive advantage. Upper Saddle River, New Jersey: Pearson Education Inc.
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. [Kindle Edition]. Retrieved from http://www.amazon.com
projectmanagervideos. (2012, Feb 1). How to prevent project management scope creep. [Video file]. Retrieved from https://www.youtube.com/watch?v=lKcJW1XqY4E