All jobs / Project / delivery manager
Planning interview questions
Planning questions a Project / delivery manager can be asked, from first job to senior. Open one to see the strongest answer and why it works.
What is the critical path, and why does a delivery manager care about it?
The strongest answer: The longest chain of dependent tasks from start to finish — it sets the earliest finish, so a slip on it slips the whole plan, while tasks off it have slack
Why it works: Exactly — it is about dependency, not importance; knowing where the slack is tells you where you can absorb a slip.
- Longest dependent chain.
- A slip on it slips the end.
- Tasks off it have slack.
- Watch it, and the waits on it.
You notice this slice needs another team’s API and nobody has written that down. What do you do?
The strongest answer: I put the dependency on the board with an owner and a next ask — I do not keep it in my head
Why it works: Exactly. Named, owned, next ask. A silent dependency is a surprise.
- Write the dependency on the board.
- Name an owner and a next ask.
- Do not wait for the block.
- Do not hide a buffer and stay silent.
A PM wants the whole team on delivery this month and “discovery later.” What is the caution?
The strongest answer: If nobody is learning the next slice, next month’s backlog is a guess — we keep a thin discovery thread, we do not freeze learning
Why it works: Exactly. Dual-track is a caution, not a slogan: starve discovery and you starve the next honest slice.
- Keep a thin discovery thread.
- Do not freeze learning for a month.
- Do not stop delivery to “only research.”
- Do not rename tickets for a slide.
A slice is waiting on another team. The team wants to start three more tickets. What do you do?
The strongest answer: We name the wait, we pick one unblock action, and we only pull if we still have capacity — we do not start a pile to feel busy
Why it works: Exactly. Name the wait. One unblock. Pull only with capacity.
- Name the wait on the board.
- One next unblock action.
- Do not start a pile.
- Do not mark waiting work done.
What is the difference between a milestone and a deliverable, and what makes each one useful?
The strongest answer: A deliverable is a tangible output someone can accept; a milestone is a verifiable event, such as “first customer live” — both are useful only when anyone can check whether they happened
Why it works: Right — the test for both is verifiability; “design 80% complete” is neither.
- Both must be checkable.
- Deliverable: an acceptable output.
- Milestone: a verifiable event.
- No percent-complete milestones.
Discovery workshops fill the calendar and the board’s “in progress” is empty. What is the caution?
The strongest answer: Dual-track means both tracks move — we time-box discovery and keep a delivery slice in flight, we do not research until the quarter is gone
Why it works: Exactly. Dual-track is a balance. Discovery that starves delivery is a different failure.
- Keep a delivery slice in flight.
- Time-box discovery.
- Do not research the quarter away.
- Do not count workshops as throughput.
Five “top priority” initiatives share one team. Forecasts keep slipping. Strongest move?
The strongest answer: I make the WIP visible at the initiative level and I ask leadership which two we stop starting — I do not ask the team to go faster
Why it works: Exactly. Portfolio WIP is the constraint. Stop starting. Speed is not the lever.
- Show initiative-level WIP.
- Stop starting; pick what waits.
- Do not split into five theatre teams.
- Do not hide slip in phase 2.
Discovery and delivery keep colliding on the same people in the same week. How do you design the cadence?
The strongest answer: I make the collision visible and I reserve capacity for both tracks — a thin discovery WIP and a delivery WIP — I do not hope people “find time”
Why it works: Exactly. Dual-track needs reserved capacity and visible WIP on both. Hope is not a cadence.
- Reserve capacity for both tracks.
- Show discovery WIP and delivery WIP.
- Do not put discovery on nights.
- Do not hide the collision in one list.
Three teams share a launch. How do you make dependencies usable, not a pretty diagram?
The strongest answer: I map who waits on whom, I pick a next ask and an owner per wait, and I put the waits on the boards — I do not leave a slide in a folder
Why it works: Exactly. Waits, asks, owners, on the boards. A folder slide is décor.
- Map waits, not just boxes.
- Owner and next ask per wait.
- Put waits on the real boards.
- Do not freeze work for a pretty diagram.
A quarter plan for a team of eight reads: eight people times sixty working days equals 480 days of capacity.
What is wrong with it?
The strongest answer: It plans at a hundred percent: leave, on-call, support, meetings and onboarding are missing — I plan from what the team actually finished before, or a realistic focus factor, and keep a buffer
Why it works: Exactly — headcount arithmetic is not capacity; historical throughput already contains all the things the spreadsheet forgot.
- Headcount is not capacity.
- Subtract leave, support, meetings.
- Prefer past throughput.
- Keep a buffer for the unplanned.
Each squad has a WIP limit and the program still starts six launches. What is missing?
The strongest answer: A limit on starts above the squad — program WIP — or the squad limits only hide the pile one layer down
Why it works: Exactly. Squad WIP cannot save a program that starts everything. Limit the starts.
- Limit starts at the program.
- Squad limits are not enough.
- Do not add a status meeting as the fix.
- Do not invent a shared velocity pool.
Four teams must land in the same window and each has its own range. How do you talk about “the” date?
The strongest answer: I show the join as a range of the latest honest end, plus the waits between teams — I do not average four dates into one confident Tuesday
Why it works: Exactly. The join is the latest honest end plus the waits. Averaging is fiction.
- The join is a range.
- Use the latest honest end.
- Show the waits between teams.
- Do not average four dates.
Delivery has run hot for a quarter and the next backlog is copies of last quarter. What is the caution?
The strongest answer: We have discovery debt — I reserve capacity to learn the next slice before we promise another range, I do not keep shipping guesses
Why it works: Exactly. Dual-track caution: starve learning and the next range is a guess. Reserve capacity now.
- Name the discovery debt.
- Reserve capacity to learn.
- Do not promise a range on guesses.
- Do not label copies as validated.
The portfolio starts every good idea. Teams are “busy” and nothing lands. What do you install?
The strongest answer: A visible limit on initiatives in progress, a replenishment that stops starting, and a kill/wait list — I do not ask squads for more velocity
Why it works: Exactly. Portfolio WIP is strategy. Stop starting. Velocity is not the lever.
- Limit initiatives in progress.
- Replenish by stopping starts.
- Keep a kill or wait list.
- Do not invent a velocity pool.
Twelve product teams are told to “do dual-track.” Discovery becomes a central research team with a six-week queue. What is the caution?
The strongest answer: Dual-track dies when learning is a distant queue — I keep discovery close to the squad with a thin WIP, I do not centralise it into a bottleneck and call it mature
Why it works: Exactly. At scale the caution is distance. A six-week queue is not dual-track.
- Keep learning close to the squad.
- Thin discovery WIP, not a distant queue.
- Do not centralise and call it mature.
- Do not count workshops as dual-track.
You are asked for a two-year delivery strategy. What is the WIP page?
The strongest answer: How many bets we will allow in flight, how we stop starting, and how squad limits roll up — not a tool list and not a promise of more output from the same starts
Why it works: Exactly. WIP is strategy: bets in flight, stop-starting, roll-up. Tools are appendices.
- Limit bets in flight.
- Write how we stop starting.
- Roll squad WIP up.
- Do not promise more output from the same starts.
Every launch needs four teams in a fixed order. Forecasts are always a pile of waits. What do you change?
The strongest answer: The shape of the work and the teams — fewer mandatory joins, clearer ownership — I do not only get better at drawing the waits
Why it works: Exactly. Repeating joins are architecture. Change the shape. Mapping is not the strategy.
- Reduce mandatory joins.
- Clarify ownership.
- Do not only map the waits.
- Do not hire a coordinator as the design.