Analyzing Scope Creep

     If you have ever been involved in a project that did not have scope creep, you are one of the few expectations that exist. This is because scope creep is so common in projects due to the desires to add more features, change other features, or rework features that seem inadequate to seemingly improve the project as a whole. Scope creep occurs because individuals have a desire to make a project better based on additional ideas they have that were not originally accounted for at the start of the project. Ironically, scope creep rarely benefits a project without also having drawbacks.
     I have been involved in several projects over the past few years that have experienced scope creep, and one in particular that comes to mind was a project I was working on about two years ago. You may have heard of me talk about this particular project before because it was a doozy with lots of learning opportunities of what to do (and not do) in projects. The company I was working for was developing a Grades 1-6 Social Studies series; this was the first of the four subjects for development. The company had not done anything this large before, so it was testing the waters of curriculum development on a whole new level. After the project planning had been completed, the company hired an external contractor to develop their scope and sequence for all six grades. Without much review or revision, the project started immediately once the contractor said they had finished the scope and sequence. As development got under way, it became evident that the scope and sequence was not as finalized as once believed. Sure, it hit all the basics and would be considered adequate for a first edition, but several designers on our team were not thrilled with the idea of letting it be. When they took their concerns to the PM, she knew there was no money in the budget or time in the timeline to allot for these suggested changes, but went with her desire for creating the perfect product on the first go and requested they all be redone. While the chapters under review were being developed, the objectives pertaining to those same chapters were also being redone. As you can imagine, it was no surprise that these chapters had to be rewritten two or three times. This cost lots of money and time; that is, money and time we didn’t have. 

     Around the same time, the key stakeholder in this project got ahold of the first few chapters from the project for personal review. However, this led to a list of suggested edits and revisions – both small and large – to be made to the work we were currently developing. Instead of spending our time focused on the task of developing the next few chapters, we became sidetracked making revisions to the first few chapters again. Due to the shuffling and diverted focus to unplanned items, the project did not meet a critical milestone for print production. As a result, the same stakeholder requested we move the project forward anyways and print a Version A of the book – a book that contained on the first half of the content. This would cause additional pagination work, several rounds of review, and printing work that was not accounted for in the cost or timeline of the project, but the request became reality the same day it was suggested. As a result, the project’s timeline ended up being extended several months past its intended end date, and the cost of the project greatly surpassed the allotted budget from the stakeholders. Although the designers and stakeholders brought up excellent and important concerns, the immediate attention to these concerns caused severe scope creep that jeopardized many key components of the project.
     Looking back on this project, it is important to note that the PM and stakeholders were doing what they thought was best for the project at the time in these difficult situations. They wanted to ensure the project met the large milestones and was done to the best of their abilities. I am sure if I was a PM at that point of time, I may have made those same decisions. However, knowing what I have learned about project management over these past six weeks, there are a few things I would have done differently to better manage the issues that contributed to scope creep.

1. Set the precedence at the beginning of the project that not every suggestion for bettering the project is a good idea for implementation. It is very unlikely a project will be a smashing success with no improvements needed on its first edition. Most of the time, members of a project realize this part way through the project and make suggested changes. In this example with designers suggesting several large changes to the scope and sequence, it would have been beneficial to set a precedence from the start of the project that not all suggested changes will be necessary changes. Dr. Stolovich (Walden University, n.d.) suggests setting aside time at the start of a project to explain this concept to all members involved in the project. He emphasizes helping others to understand that the PM has the power to veto any idea for the sake of the project’s best interest, and temporarily overlooking a suggested change may be a PM’s decision to prevent scope creep that can damage the project. One way this idea could have been reinforced in this project would have been by utilizing change control processes. In short, if someone wants to request a change to a project, they must submit a change request form via a form set up in our project management software (Ray, 2021). This way, the members submitting the suggested changes must explain why they think this change is necessary while also tracking all the requests that were made. (Interestingly enough, we implemented this exact system for change requests in a later project and it significantly reduced scope creep and distraction from the high-priority tasks.) 
2. Recommend that necessary suggestions for change be held off for a second revision, if possible. Not all suggested changes are dire and necessary changes. In fact, most times these suggest changes do more harm than good by being included. Although there are instances when suggested changes are necessary for the ultimately success or failure of a project, most suggested changes can be shelved for a later edition. In this example, the company knew the first edition of their course would have to be revised after a few years after it had been tested by a select group of customers. When the key stakeholder was suggesting changes to the first few chapters that had already been completed with many more chapters in development, I would have suggested we keep our focus on the tasks with higher priority and either come back to these suggested changes at the end of the project if we had extra time or hold off these changes for a second edition. One of the biggest factors of scope creep is losing focus on task prioritization, and our shift in focus from development to fixing minor issues contributed to scope creep (Rudder, 2022). However, it is always wise in these cases to have suggested changes – especially ones made by stakeholders – that are shelved put down in writing from both parties involved so that everyone clearly remembers who made the decision to refrain from implementing the suggested changes (Walden University, LLC, n.d.).
3. Because change is unavoidable, create a change management plan at the start of a project and use it when needed. As much as you can try to avoid it, you cannot avoid change. Although there are times when it is unnecessary, there are times where it is vital to the success of the project. In this example, the stakeholder realized a book would need to go out at a specified milestone, and creating a different type of book that only had the first half of the project’s content in it would have to do. It was not possible for the PM to say, “I like your ideas, but let’s see if we can hold that off for the second edition.” If this book didn’t go out, there would be no possibility of a second edition. If I was the PM in this instance, I would have created a change management plan at the start of the project and recommended to the stakeholder that we implement their suggested changed but only if it is documented and completed according to the change management plan. In a change management plan, the necessary change is defined, implemented, and maintained according to a specified plan that works best for the project (Taffer, 2023). By doing this, everyone is aware of what changes are taking place, everyone has signed a document in agreeance of the changes taking place, and the PM has it in writing that the stakeholders understand how this change will impact critical factors of the project such as budget and timeline. Although it may feel like you are pulling teeth at times to get everyone to follow a process, it proves fruitful time and time again for the project and the PM’s best interest to follow a process for change that is transparent and planned when change is needed.

References

Ray, S. (2021, May 26). What is scope creep and how can I avoid it?. ProjectManager. 

          https://www.projectmanager.com/blog/5-ways-to-avoid-scope-creep
Rudder, A. (2022, August 25). Scope creep: Definition, examples & how to prevent it. Forbes. 

          https://www.forbes.com/advisor/business/scope-creep/
Taffer, M. (2023, April 14). An effective 3-step change management process for project managers. 

          The Digital Project Manager. https://thedigitalprojectmanager.com/projects/leadership-team-

          management/change-management-process/
Walden University, LLC. (Executive Producer). (n.d.). Monitoring projects [Video file]. Retrieved 

          from https://waldenu.instructure.com
Walden University, LLC. (Executive Producer). (n.d.). Practitioner voices: You can’t win them all 

          [Video file]. Retrieved from https://waldenu.instructure.com