How would you handle client or stakeholder feedback that comes in after a feature has been delivered, or, one that is completely out of scope?
In software development, both scenarios are examples of possible scope creep which can pose serious problems to the timeline or budget of a project. The interviewer wants to be assured that you can recognize and mitigate scope creep. Talk to them about how you would prevent it from occurring and specific steps you would take if it did occur.
"Both scenarios sound like they could blow up into scope creep. In my experience, scope creep needs to be nipped in the bud before it starts to impact the project negatively. I certainly appreciate feedback; in fact, I encourage it. However, when it comes along with additional requests that use up resources, especially labor hours, there needs to be a conversation about what return we expect from the activity or new feature. Further, I will also need to bring up whether the stakeholder's expectation from this additional request aligns with the business goals for the project. If we justify the cost associated with the change, only then will I add this to the project scope. As an experienced project manager, I have learned that it is key to definitively scope the project at the beginning, spell out as much of the tasks involved and make it invulnerable to going off-course, as much as possible. In the instances when scope creep does occur, I move quickly to establish and communicate new expectations."
