Candice ShubbieConsultant| PROJECT40 ConsultingOntario, Ca, United States
As a manager of creative projects, scope creep is my reoccurring nemesis. We all know that scope creep can pose significant challenges to project success. It leads to delays, budget overruns, etc., and as project managers, it's essential to proactively identify and manage scope creep to ensure project objectives are met within the agreed-upon constraints. I have found success by being extremely thorough in documenting and maintaining a baseline project scope throughout the project life cycle and utilizing my stakeholder engagement/ management/ people skills, as well to “redirect” my clients. Also, having a very clear change control process is essential because the clients I work with tend to be more “idea” focused. My question for the group is related to early identification.
In regard to managing scope creep, how do you recognize the signs of scope creep in a project? What are some common triggers or indicators of scope creep, and how do you stay vigilant to potential changes in scope creep? Saving Changes...
Use your WBS. The required work will expand over time as you provide more details about how to accomplish the objective (To do A requires doing B, C, and D). If you were to organize your WBS into a tree, scope creep occurs when the tree becomes wider rather than more layers of detail. Once you start adding in the "while we're doing A we might as well do B, C and D also...) now you have a larger scope rather than just higher fidelity picture of the original scope. Saving Changes...
Also, make sure your delivery approach matches the degree of certainty regarding scope & the underlying requirements. If it is not possible to nail scope down early on, use a rolling wave or even a fully adaptive approach.
Kiron
...
1 reply by Candice Shubbie
May 30, 2024 3:10 PM
Candice Shubbie
...
Kiron,
Thanks for your reply. I have found it useful in the past to use a rolling wave approach as you suggested. However, you mentioned "ensuring that the delivery approach matches the degree of certainty regarding scope and the underlying requirements." Can you share some insight on how you've utilized this method?
Saving Changes...
Candice ShubbieConsultant| PROJECT40 ConsultingOntario, Ca, United States
May 29, 2024 7:27 AM
Replying to Kiron Bondale
...
Candice -
Also, make sure your delivery approach matches the degree of certainty regarding scope & the underlying requirements. If it is not possible to nail scope down early on, use a rolling wave or even a fully adaptive approach.
Kiron
Kiron,
Thanks for your reply. I have found it useful in the past to use a rolling wave approach as you suggested. However, you mentioned "ensuring that the delivery approach matches the degree of certainty regarding scope and the underlying requirements." Can you share some insight on how you've utilized this method?
...
1 reply by Kiron Bondale
May 31, 2024 12:26 PM
Kiron Bondale
...
Sure - it comes down to understanding the degree of confidence which the team and stakeholders have in what is really needed. The higher the confidence level, the further out we can look. I find by asking questions such as "How likely is it that the core requirements will change over the project's life time?" or "What is the likelihood that we are missing an important requirement?" forces folks to challenge their assumptions of confidence.
And where there might be lower confidence, making smaller bets and getting frequent feedback are both good practices.
Kiron
Saving Changes...
Randall AndersonOwner| Great Ocean SoftwareWinters, Ca, United States
I always assume that stakeholders will want to add to the scope of a project at the outset, and I eventually developed a sustainable method of dealing with it. It's somewhat specific to IT projects, but you might find these thoughts on it useful. https://www.projectemc2.com/post/scope-creep Saving Changes...
Thomas WalentaGlobal Project Economy ExpertHackenheim, Germany
Candice,
I like Sergio's advice about welcoming all changes. This will encourage change requestors to use an established process, and fewer changes will creep in under your radar. It is also because of the mindset and rational view on changes. Changes are not a nemesis; there should not be negative emotions about them (or positive ones). They are a fact of life, like weather.
There are many potential reasons for changes, but the least probable is that people want to annoy you. If you identify a specific cause for changes, you can mitigate it; for example, a key stakeholder is uncertain about what they want. Engage with them, make them feel secure, and establish trust.
Kiron,
Thanks for your reply. I have found it useful in the past to use a rolling wave approach as you suggested. However, you mentioned "ensuring that the delivery approach matches the degree of certainty regarding scope and the underlying requirements." Can you share some insight on how you've utilized this method?
Sure - it comes down to understanding the degree of confidence which the team and stakeholders have in what is really needed. The higher the confidence level, the further out we can look. I find by asking questions such as "How likely is it that the core requirements will change over the project's life time?" or "What is the likelihood that we are missing an important requirement?" forces folks to challenge their assumptions of confidence.
And where there might be lower confidence, making smaller bets and getting frequent feedback are both good practices.
Community Champion
