The client wants more scope, but the same deadline. How do you respond?

What the interviewer is really testing

• Negotiation. Can you have a difficult conversation about time, cost and scope, calmly and with facts?
• Change control. Do you have a process for new requests, or does scope quietly grow until the release slips?
• Protecting the relationship. Can you say "not like this" without the client feeling refused?

The weak answer vs the strong answer

Here's the answer most candidates give: "We'll try our best to accommodate it."

It sounds positive, but here's what the interviewer hears. You've agreed before you know the impact. Your team will absorb the extra work with late nights, testing will get squeezed, and the risk lands on the release. And when it slips, the client will remember that you said yes.

Being helpful is good. But a yes without a cost is just a delay you haven't announced yet.

The 5-step answer

1. Listen first. Understand the business reason behind the request. Why now? What happens if it waits? Sometimes the real need is smaller than the request, and sometimes it really is urgent. You can't negotiate well until you know which.
2. Do an impact analysis. Work out the effort for development and testing, the risk to the date and to quality, and any dependencies. Do it quickly, within a day or two, so the client isn't left waiting for an answer.
3. Offer options, not a yes or a no. Swap it for a lower-priority item of the same size. Phase it into the next release. Add capacity, at extra cost, if the work can really be split. Or move the date. Show the impact of each option, and give your recommendation.
4. Formalise it. Raise a change request, get the decision approved by the right person, and update the plan, the estimate and the RAID log. If it isn't written down, it didn't happen.
5. Communicate the trade-off. Tell everyone affected what was added, what moved out or what changed, and why. The team, the testers and the client's stakeholders should all hear the same story.

A real example

Let me give you a real example from my own experience. I'll keep the client anonymous.

I was working on a program for a US healthcare payer. About three weeks before a release, the business asked us to add a new validation in the member enrollment flow, and keep the same go-live date.

Instead of saying "we'll try", we took two days for an impact analysis. The change was about ten days of development and testing, and because it touched the enrollment flow, it needed a full regression cycle, not just a quick check.

So we went back with three options. Swap it for a lower-priority item in the same release. Phase it into the next drop, two weeks later. Or add two people at extra cost, with a higher risk to quality.

The client chose to phase it into the next drop. We raised a change request, updated the plan and the RAID log, and told the team and every stakeholder what had changed, and why.

The result: the release went live on the original date, with no critical defects.

The new requirement followed in the next drop, fully tested.

Nobody worked weekends to absorb it, and testing wasn't squeezed.

And from then on, the client started bringing new requests with a different question: not "can you squeeze it in?" but "what will it cost?"