Employers want to see if you follow a structured change control process instead of accepting every request by default, which is a major cause of failed projects.
Structure your answer around define, assess, decide, and communicate. Explain how you compare the request against the scope baseline and escalate when a sponsor decision is needed.
Start by acknowledging the request without committing to anything, and say plainly that you will assess its impact before giving an answer. Explain that you first define the change by clarifying what exactly is being asked, why it is needed, and what the stakeholder expects as an outcome. Then assess it against your scope baseline, your approved timeline, and your budget, checking whether it affects deliverables, resources, or milestones. If the impact is minor and within contingency, you can accept it formally and document it. If it is moderate, present options to the stakeholder, such as deferring it to a later phase or swapping it with a lower priority item, and let them decide the trade off. If it is significant, escalate to the sponsor with a clear impact statement, because a sponsor, not you, should own a decision that changes the project's commitments. Throughout, communicate in a calm, professional tone, and in a Philippine setting, avoid the instinct to say yes just to please. Use Taglish if comfortable, but keep the substance clear, and always document the decision, whether accepted, deferred, or rejected, so everyone is aligned. Remember that saying no with reasons is part of protecting the project, not a personal failure.
A common mistake is saying 'Sige po, gagawin natin kahit wala sa scope' just to please the stakeholder, then the team absorbs unpaid overtime. Instead, say 'Let me check the impact on the timeline and budget first, and I will give you options.'
Situation
In my previous role as a project coordinator for a small software rollout, a client asked for a custom dashboard report two weeks before the go live date.
Task
I had to evaluate whether the dashboard could be added without delaying the launch or exceeding the fixed budget.
Action
I first documented the requested change and checked it against the signed scope statement. I then asked the client three questions about what decision the report would support, who would use it, and whether it could wait until a post launch phase. I estimated effort with the developer and presented two options to the sponsor.
Result
The sponsor agreed to defer the report to a phase two release. The project launched on time, and the report was delivered three weeks later with minimal disruption.
Treat every change request as a business decision, not just a technical add on.
Write your own answer, then get instant AI feedback graded against:
Get AI feedback on your answer — free.
3 free AI-graded answers + 1 free mock interview, no card needed.
Sign Up FreeAlready have an account? Log in
Sign in to join the conversation.
No answers shared yet — be the first to show how you'd approach this.