Tell me about handling scope creep
Model answer
Use the STAR structure.
Situation. On a customer portal project, a sponsor kept adding "small" requests in weekly meetings: extra reports, a new user role, an export format. The release date was fixed.
Task. Protect the deadline and quality while keeping the sponsor's trust.
Action. I logged every request in a change log with an estimate and the impact on schedule and cost. I met the sponsor and showed that the accepted requests no longer fit the date. I asked them to rank the new items against the original scope. We agreed to take two requests now and move the rest to a second release, and I formalized this through the change control process.
Result. We shipped on time, the sponsor felt heard, and later requests went through the same visible process.
The lesson: do not just say no, show the trade-off and let the decision owner choose.
Key points
- Log every request with its impact on schedule and cost
- Show the trade-off and let the decision owner prioritize
- Use a formal change control process
Likely follow-ups
- What would you have done if the sponsor refused to prioritize?
- How do you tell scope creep from a legitimate change?
Common mistakes
- Absorbing every request silently until the deadline slips
- Refusing without showing the impact or alternatives