In this article
Before you start
Delivery questions are one part of the leadership interview questions that engineering managers face.
Why interviewers ask this
A project that slips tells an interviewer more than one that ships on time, because the candidate's choices become visible. Candidates report questions such as managing hard deadlines you expect to miss, or delivering a project early against an agreed date. Candidates at Amazon also report being asked about a team that gave up and was pushed to deliver.
Amazon's Deliver Results principle says leaders deliver the key inputs "with the right quality and in a timely fashion". So the criterion is quality plus timeliness, not speed alone.
A weak answer is a story of effort: long hours, a heroic weekend. A strong answer names the fixed date, the early signal, the trade, the person who agreed and the result. A Staff-level answer adds how the team's planning changed so the next slip is smaller.
Delivery under pressure from first principles
- Delivery under pressure
- Delivery under pressure is the practice of reaching an agreed outcome by a fixed date when time, people or information turn against the plan, by raising risk early and trading scope or date by agreement instead of silently working longer or lowering quality.
- Scope cut
- A scope cut is a deliberate, agreed removal of planned work from a delivery, so the remaining work still meets the date and the quality bar. Unlike a silent drop, the removed items are recorded and either moved to a later cycle or dropped on purpose.
- Re-forecast
- A re-forecast is a new finish estimate computed from the work actually completed so far instead of from the original plan, so a slip shows up as a number early. It is shared with stakeholders together with the options for closing any gap.
In plain words
Picture a truck booked for moving day. The day is fixed and the truck has a size. When packing runs late, you do not make the truck bigger. You decide what stays behind, and you tell the people who need those boxes.
The analogy breaks in one place. In a project, other people have a say in what stays behind, so you must ask them before you leave anything out.
In one precise sentence: when the date and the quality bar are fixed, scope is the variable, and the job is to change it early, openly and with agreement. Everything else on this page is that sentence, applied step by step.
Step 1: Fix the goal and the date, and name what can flex
The first step is to write down what is fixed and what can move. A time box is a fixed period in which the work must be finished. The Scrum Guide's Sprint Goal is the single objective of that period, and the guide says the scope behind it can be clarified and renegotiated with the Product Owner as more is learned.
You do not need Scrum to use the idea. Input: a date, an outcome and a list of work. Output: a short note saying the date and goal are fixed, the quality bar is fixed, and the listed items are ordered by value, so the last ones are the first to go. You now know what you may trade before pressure arrives.
Step 2: Slice the work and watch for the first slip
A slip is cheapest to handle when it is small and early. The Scrum Guide describes decomposing backlog items into work items of one day or less, which is a common practice rather than a rule. It also says shorter time boxes bring more learning cycles and limit risk to a smaller time frame.
Input: the ordered list. Output: items small enough that finished versus planned is visible every few days. After the first slice of time, compute a re-forecast: divide the work remaining by the pace you actually achieved, not the pace you planned. A gap that shows in week two is a conversation; a gap that shows in the last week is a crisis. You now have an early number to bring to someone.
Step 3: Cut scope, not quality, and get it agreed
When the re-forecast shows a gap, the lever is scope. Start from the bottom of the value order and remove whole items, keeping the checks that protect quality, such as tests and reviews. Do not shave a little from every item, because that leaves several half-built features and no finished one.
Ask the owner of the outcome to agree, in writing, and record each removed item as a scope cut with a note on where it goes next. The 2017 Scrum Guide describes the team negotiating the scope of the Sprint Backlog with the Product Owner without affecting the Sprint Goal, which is the same move. Choosing what to remove is prioritisation done under time pressure. You now have a smaller plan that still delivers the outcome.
Step 4: Tell stakeholders early, with options and a new forecast
The last step is communication. Send one message that holds four things: what changed, the re-forecast, two or three options, and your recommendation. Options might be cutting named items, moving the date, or accepting a stated risk.
Say it as soon as the number is real, not when it is comfortable. Then repeat the forecast on a fixed rhythm, so that nobody has to ask. People who rely on your date can only replan if they hear early; the stakeholder management page covers how to keep that trust. You now have the whole loop: fix, measure, cut, tell. Then it repeats with the new forecast.
Step-by-step description
- Name the fixed goal and date.
- Small items show a slip early.
- Remove low-value scope by agreement.
- Share options and a new forecast.
- A fixed date and goal leave scope as the flexible part.
- Small work items show the first slip early.
- Cut scope by agreement and keep quality.
- Tell stakeholders early with options and a new forecast.
Knowing it is half the job. Saying it is the other half.
Interview Clozo is an AI interview copilot for real interview rounds: it hears the question and puts a strong answer on your screen, and you say it in your own words. See the features or how it works.
Start Free Trial →Worked example
This example is illustrative, with no real company behind it. A team of four engineers has ten weeks. Each engineer has five working days a week, and 80% of those days are focused project work, so the team has 16 focused person-days a week. The plan keeps a 15% buffer. The work is six items: two must-haves (24 and 40 person-days), two should-haves (20 and 20) and two optional items (14 and 12), 130 person-days in all.1
Ten weeks give 160 person-days, of which 136 are usable after the buffer, so the original plan fits. Then the date is pulled forward by two weeks. Eight weeks give 128 person-days and 108.8 usable. The must-haves and should-haves total 104, which fits, so the plan cuts both optional items, 26 person-days.1
Now the slip. The plan needs 13 person-days a week (104 over eight weeks), so after two weeks 26 should be done. The team has finished 21, a pace of 10.5 a week. At that pace the 104 person-days finish in 9.9 weeks, past the date.1
Remaining work is 83 person-days, but six weeks at 10.5 give only 63. The gap is 20 person-days, which equals one should-have item. Cutting it brings the remaining scope to 63 and leaves no buffer, so the message to stakeholders names that risk.1
| Quantity (illustrative inputs) | Value |
|---|---|
| Usable capacity, ten weeks | 136 person-days |
| Full scope | 130 person-days |
| Usable capacity, eight weeks | 108.8 person-days |
| Must-have and should-have scope | 104 person-days |
| Optional scope cut | 26 person-days |
| Planned pace | 13 person-days a week |
| Actual pace after two weeks | 10.5 person-days a week |
| Forecast finish at actual pace | 9.9 weeks |
| Gap against remaining capacity | 20 person-days |
Text description of the diagram
- Full scope is 130 person-days against 136 usable in ten weeks.
- After the cut the scope is 104 person-days against 108.8 usable in eight weeks.
The numbers are made up, but the method carries over: capacity, scope, pace, forecast, gap, cut.
Trade-offs and edge cases
Four responses exist when a plan slips, and only two of them change the plan. Working longer puts quality and the team's health at risk. Adding people may slip the date further: Brooks's law, from Frederick P. Brooks Jr., The Mythical Man-Month (1975), says that "adding manpower to a late software project makes it later", because new people need time to learn before they help, so ask how soon they can contribute. Cutting scope holds the date and shrinks the scope. Moving the date holds the scope. The last two need someone else's agreement.
Text description of the diagram
- Cutting scope holds the date and shrinks the scope.
- Moving the date holds the scope.
- Working longer puts quality at risk, and adding people may slip the date further.
Edge cases. First, scope sometimes cannot shrink, for example when a contract or a rule names every item. Then the honest options are the date, the risk, or extra help, and you say which one you recommend. Second, cutting quality is a silent, unagreed scope cut; it creates debt that the tech debt versus features trade-off explains. Third, a slip caused by another team's dependency needs a joint plan, as in driving a big cross-team change. Fourth, a mid-period change of priorities is a different case, covered in when priorities change mid-quarter.
Reported practice differs on how often to re-forecast; the Scrum Guide's own answer is to keep time boxes short so learning comes sooner.
How to answer it in an interview
The answer below is an illustrative composite, not a real case. Replace the details with your own project.
How do you manage a project with hard deadlines if you expect it to slip?
I treat the date and the quality bar as fixed and scope as the variable. I order the work by value and slice it small, so a slip shows early. When my re-forecast, based on the pace we actually achieved, passes the date, I go to the owner that day with options: cut named items, move the date, or accept a stated risk. I recommend one. Once we agree, I record the cut items and send a weekly forecast. Last time we shipped the core on the date, and the cut work went into the next cycle.
The spoken structure: say what is fixed, say how you detect a slip, give the options with a recommendation, then the result.
Common mistakes
- "We worked nights and weekends and made it." (wrong) It describes effort, not a decision, and hides the risk of burnout. (right) "We cut two items, agreed with the owner, and held the quality checks."
- "I waited until I was sure before telling anyone." (wrong) Late news removes the other person's options. (right) "I raised it when the re-forecast showed the gap, with three options."
- "We shaved a bit off every feature." (wrong) That leaves everything half done. (right) "We removed the lowest-value items whole and finished the rest."
- "I added people to catch up." (wrong) New people need time to learn before they help. (right) "I checked how soon new people could contribute before recommending it."
- "The sprint scope was a promise, so we missed it." (wrong) The Sprint Goal is the commitment, and the scope behind it can be renegotiated. (right) "We kept the goal and renegotiated the scope."
Follow-up questions
How do you answer "Tell me about a time your team gave up but you pushed them to deliver"?
Re-scope to a slice the team believes it can win, make progress visible so each finished item shows the goal is reachable, and protect the team's hours instead of asking for more of them. Close with what was delivered and what moved to the next cycle.
How do you communicate a slip to stakeholders?
Send one message with what changed, the new forecast, two or three options and your recommendation, then repeat the forecast on a fixed rhythm. The stakeholder management page goes deeper.
Tell me about a time you had to deliver a project urgently, two weeks earlier than the agreed date?
An illustrative structure: the fixed date, the signal that it was at risk, the trade you made and who agreed to it, the result, and what changed in your planning afterwards. Use the value order to cut scope by agreement, as in the worked example above.
How do you set up a new project: scheduling, milestones?
Agree the outcome and the fixed constraints, write the goal and date, and order the work by value. Make each milestone a small, usable slice owned by a named person so progress is measurable. Keep a buffer, and keep the horizon short, since the Scrum Guide links shorter time boxes to more learning cycles and less risk. The same steps start a new program from scratch.
What was the most significant roadblock you encountered recently?
Structure it as the blocker, the early signal you saw, the escalation or trade you made, and the result. Choose a real blocker where you acted before it became a crisis.
What if both the date and the scope are fixed?
Then the remaining levers are risk and resources. Say plainly what you would add (people with a ramp-up cost, or a tighter review loop), what could go wrong, and who must accept that risk.
- Delivery under pressure is a chain of decisions: fix, measure, cut, tell.
- When the date and quality are fixed, scope is the variable you negotiate.
- A re-forecast from actual pace turns a feeling of slipping into a number.
- Cut whole low-value items by agreement; do not thin every item.
- Tell stakeholders early with options and a recommendation.
Sources
- Amazon Leadership Principles — Amazon (aboutamazon.com); the page is undated, so the date is the read date, 26 Oct 2026
- The 2020 Scrum Guide — scrumguides.org (Schwaber and Sutherland), 18 Nov 2020
- The 2017 Scrum Guide — scrumguides.org (Schwaber and Sutherland), 1 Nov 2017
- The Mythical Man-Month: Essays on Software Engineering, anniversary edition (ISBN 9780201835953) — Addison-Wesley (Frederick P. Brooks Jr.; first published 1975), 1 Jan 1995
