Your critical release is slipping by two weeks. What do you do?

What the interviewer is really testing

• Your judgement under pressure. Do you panic, or do you get the facts?
• Transparency. Will you tell the client early, or will you hide the problem and hope it goes away?
• Options thinking. Do you see more than one way out?

The weak answer vs the strong answer

Here's the answer most candidates give: "I'll ask the team to work late and on weekends to meet the date."

It sounds committed, but here's what the interviewer hears. You didn't ask why the release is slipping. You're hiding the problem from the client. And tired teams make more mistakes, so you're probably creating defects that will hurt you after go-live.

Overtime can be part of a solution, but it should never be the whole answer, and never the first one.

The 5-step answer

1. Get the facts within 24 hours. How big is the slip really? And what is the root cause? Is it scope growth, a third-party dependency, a defect backlog, or a capacity problem? What is done, and what is left? You can't fix what you haven't measured.
2. Build options, not excuses. For example: phase the release, and deliver the must-have features on the date while the rest follows. Add capacity, but only where the work can genuinely be split. Run development and testing in parallel where it's safe. Or move the date. For each option, show the impact on scope, cost, quality and risk.
3. Tell the client early. Go to the sponsor before they discover the problem themselves, with the facts, the options and your recommendation. Clients can handle bad news. What they can't handle is surprises.
4. Protect quality. Never cut testing silently to make the date. If the scope changes, agree in writing exactly what is in the release.
5. Re-plan and track daily. Publish the revised plan, hold short daily check-ins, keep the RAID log updated, and once you're back on track, run a retrospective so it doesn't happen again.

A real example

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

We had a release with a large number of complex requirements, and several of them depended on a third-party software vendor. The problem was that we were getting very little information from them: incomplete specifications and slow responses.

So we followed exactly these steps. We separated the requirements into two groups: those that depended on the vendor and those that didn't. The team built the independent features first, so no time was wasted waiting.

I put the vendor dependency at the top of our RAID log and set up a fixed sync call with them. When answers still didn't come, I escalated through the right channel, the vendor's account manager and our client sponsor.

Where we couldn't get specifications, the team built stubs and mocks, so development and testing could carry on in parallel. And I kept the client fully informed with honest status updates and a contingency plan.

The result: we delivered the release on the committed date, with no critical defects in production. The client appreciated how openly we handled the risk, and that dependency approach became our standard for later releases.