Programme recovery interview questions and answers
Practise diagnosing delivery trouble, stabilising the work and rebuilding a plan that sponsors can trust. These questions distinguish genuine recovery from changing a status colour or moving a deadline without addressing its causes.
Diagnosis: separate symptoms, unreliable reporting and the causes of missed commitments.
Controlled recovery: explain options, capacity, dependencies and the authority needed to change commitments.
Evidence of improvement: use completion evidence, risk reduction and customer confidence alongside schedule measures.
How to approach your answer
Establish the current position from delivery evidence, financial exposure and conversations with the team and sponsor.
Choose immediate containment actions and develop feasible options with explicit trade-offs.
Agree decision owners, a credible revised plan and short review intervals. Describe how you would test whether recovery is holding.
A programme is red and nobody trusts its completion date.
Illustrative approach: I would first reconcile the scope, milestones, outstanding acceptance work and dependency dates rather than promise a new finish date. I would identify the critical constraints and agree immediate containment with the sponsor. Next I would present options such as reducing scope, sequencing releases or funding a specific constraint, with their costs and risks. The approved option would become a controlled plan with owners and evidence-based checkpoints. I would judge recovery by completed, accepted outcomes and fewer unresolved dependencies, not by the revised date alone.
Mistakes to avoid
Rebaselining before validating scope, capacity and dependencies.
Presenting overtime as the main recovery strategy.
Declaring success because reporting has become green.
Questions and answer guidance
Start with the level closest to your experience. Each question links to its exact practice exercise; the answer is also available here without opening the app.
Foundations
Start with the concepts and explain them using a small example.
Managerial · Fresher / Mid-level
1. What is a RAID log and how do you keep it useful?
Read the answer guide
RAID stands for Risks, Assumptions, Issues and Dependencies. Each entry needs an owner, a date, an impact, a rating and an action. It stays useful only if it is reviewed on a fixed rhythm, closed items are cleared out, assumptions are tested and anything beyond the team's control is escalated. A RAID log that is filled in once at kickoff and never opened again is not managing anything.
What the interviewer is assessing
Practical familiarity with basic project control.
Common mistakes
Treating it as a one-time list
Entries with no owner or date
Confusing a risk (might happen) with an issue (already happening)
Practise a follow-up
Give me an example of an assumption that later became a risk.
Show how you would apply the idea to a constraint, disagreement or failure.
Technical · Mid-level
2. How do you distinguish a true critical path delay from an activity slipping with float?
Read the answer guide
Start with a schedule that is up to date, with progress entered and the logic checked. Look at how activities link to each other, and remove any constraints that hide the real picture. Then look at float, which is how long an activity can slip without delaying the finish. If an activity is on the longest path with no float, its delay moves the end date. If it has float, watch it but it may not matter. Check the effect on later work and the completion date.
Rebaselining is for real change, not for hiding slippage. I would do it after an authorised material change, such as an approved scope increase or a major external delay, when the old baseline no longer describes a fair target. I keep the original baseline and the current one, with variance history, the reason and the decision record, so the story stays visible. If a team simply resets dates each time it slips, performance data becomes meaningless. A useful rule is that repeated rebaselining without an agreed cause signals a planning or control problem that needs addressing.
What the interviewer is assessing
Whether you use rebaselining only for authorised material change and keep the history of variance visible.
Common mistakes
They rebaseline whenever the project is late so the report shows no variance and the sponsor never sees the slip.
They overwrite the old baseline, so nobody can compare original commitments with the current forecast.
Practise a follow-up
Who should authorise a rebaseline and what evidence should they see?
How would you report performance after a rebaseline?
4. What evidence would make you choose crashing over fast-tracking a delayed project?
Read the answer guide
Crashing adds people or money to work on the critical path to shorten it, while fast-tracking overlaps tasks that would normally run in sequence and often creates rework. I would choose by looking at evidence: whether the delay sits on the critical path, which dependencies are hard, how much extra resource would actually be productive, and the risk each option adds. For instance, adding people to a task that is already crowded may give nothing. I would pick the option with a credible net benefit to the finish date and explain its cost and risk.
What the interviewer is assessing
Whether you can compare crashing and fast-tracking using critical path, dependency constraints, productivity and risk, and pick the option with real net schedule benefit.
Common mistakes
They add more people to every late task, ignoring whether the work can be split or whether it is on the critical path.
They overlap dependent tasks to save time without assessing the rework risk that fast-tracking creates.
Practise a follow-up
How would you estimate the extra cost of crashing a particular task?
What would you do if both options together still miss the deadline?
Explain trade-offs, wider consequences and the evidence behind your decision.
Technical · Mid-level / Senior
5. Explain the critical path and how you actually use it while running a project.
Read the answer guide
The critical path is the longest chain of dependent tasks from start to finish, and it decides the earliest possible completion date. A delay to any task on it delays the whole project, while tasks off it have float and can slip without effect. In practice I use it to decide where to focus attention, which risks matter most, and where extra resources or a change in sequence would actually shorten the schedule. I review it regularly, because the critical path can move as tasks finish early or late.
What the interviewer is assessing
Practical understanding of scheduling, not only the textbook definition.
Common mistakes
Defining it without explaining what you do with it
Assuming the critical path never changes
Adding people to non-critical tasks and expecting the date to move
Practise a follow-up
What is float, and who should know about it?
How do you shorten a critical path without adding cost?
6. Tell me about a time a project you led was at risk of missing its deadline.
Read the answer guide
Choose a real project with a clear deadline and a clear risk. Situation and task: what was due, why it was slipping and what you were accountable for. Action: how you found the true causes, what you re-planned or cut, whom you brought in, and how you kept the customer informed. Result: whether you delivered, what it cost and what you learned. Be honest if the outcome was partial, because a candid account of a hard recovery is more convincing than a flawless story.
What the interviewer is assessing
How you recover a slipping project with facts and communication, and whether you own the outcome.
Common mistakes
Blaming the team or the customer for the delay
Describing the plan but not what you personally did
7. You have just taken over a project that is already running late. What do you do in the first two weeks?
Read the answer guide
Start by listening and gathering facts before changing anything. Review the scope, plan, budget burn, open risks and the customer's expectations, and talk to the team and the customer separately. Find the real causes of the delay (estimation, dependencies, people, changing scope), then rebuild a realistic plan around the critical path. Take that plan to the customer early, with clear options and trade-offs, and set a tighter reporting rhythm until the project is stable.
What the interviewer is assessing
Whether you take ownership calmly, work from facts and communicate early instead of hiding a problem.
Common mistakes
Promising a fast recovery before understanding the causes
Blaming the previous manager or the team
Telling the customer nothing until the new plan is perfect
Practise a follow-up
What if the customer refuses to move the date?
How do you tell a late project from an under-estimated one?
8. Your subcontractor misses a key milestone. What is the recovery sequence?
Read the answer guide
First establish the facts: what was actually completed, what evidence exists, and what the contract requires. Then assess the downstream impact on dependent tasks, the critical path and cost. Talk to the subcontractor to understand the cause and agree a dated recovery plan with named owners, interim checkpoints and evidence of progress, not verbal assurances. Inform the sponsor early if the end date is at risk, with recovery options such as extra resources or resequencing. Escalate and use contractual remedies in proportion.
What the interviewer is assessing
Whether you respond to a supplier miss with facts, impact analysis, an evidenced recovery plan and proportionate escalation.
Common mistakes
They go straight to penalties or blame before establishing what happened and what the impact is.
They accept a verbal promise to catch up and only look at progress again at the next milestone.
Practise a follow-up
Which contract terms would you read first when a milestone is missed?
How would you protect the schedule while the vendor recovers?
9. Two projects each report green but a shared integration date is impossible. What do you do?
Read the answer guide
Green on each project can still hide a red program. I would build a cross-project dependency map with dates, owners and the exact hand-off each side expects, then confirm the integrated critical path. If the shared date is impossible, I make it visible to program governance now, not at the integration point. Then replan together: resequence work, add resources, reduce scope of the integration, or move the date, with each option's cost and risk. The program owns decisions across projects, and I would agree how dependencies are reported so this surfaces earlier next time.
What the interviewer is assessing
Whether you find cross-project conflicts through dependency mapping and integrated planning, and take them to governance with options.
Common mistakes
They trust each project's green status and take no action until the integration date is missed.
They ask one project to absorb the delay without showing the impact on the other or on the program.
Practise a follow-up
How would you make dependencies visible in regular program reporting?
Who should decide which project gives way when both dates cannot be met?
10. A multiyear program is red with disputed status and no credible completion date. What is your first month?
Read the answer guide
In the first month I would establish facts before promising anything. That means a single independent view of status, an integrated baseline of remaining work, spend and dependencies, and protection of critical operations from further disruption. Fix decision rights so disputes about status are settled with evidence and the right people decide. Then re-estimate what remains with the teams, and prepare recovery options, such as reduce scope, phase delivery, add capacity or reset the date, each with cost, benefit and a confidence level. Present them to the sponsor for a decision.
What the interviewer is assessing
Whether you can stabilise a failing program by establishing facts, decision rights and a credible re-estimate before committing to a new date.
Common mistakes
They announce a new completion date in the first week, before establishing facts or re-estimating the work.
They replace the team or the tools straight away, without resolving the disputed status and decision rights.
Practise a follow-up
How would you settle a dispute between teams over what the true status is?
What would you tell the sponsor in the first two weeks, before you have a new plan?
11. Describe how you would recover a delivery that has lost sponsor trust.
Read the answer guide
Trust returns through evidence and repeated small proofs, not through promises. I would begin with an independent fact base: current progress, real quality, remaining work and the actual forecast, ideally reviewed by someone the sponsor trusts. Then I share a credible forecast with its assumptions, even if it is unwelcome, and show near-term wins the sponsor can verify. Decisions are given clear owners, and I report on a steady rhythm with the same measures so progress is visible. Over several cycles, consistent delivery of what was promised does more than any reassurance.
What the interviewer is assessing
Whether you rebuild sponsor trust through an independent fact base, honest forecasts and repeated visible delivery.
Common mistakes
They promise a quick turnaround and more effort, then miss again because the fact base was never reset.
They defend past decisions and blame others, which convinces the sponsor nothing has changed.
Practise a follow-up
How would you tell a sponsor that the recovered forecast is later than they hoped?
Who would you ask to provide the independent view of the project?
12. How do you measure project health beyond a red-amber-green status?
Read the answer guide
A single colour hides too much, so I combine a small set of measures across five areas: schedule (variance against the baseline, milestone hit rate), effort and cost (burn against plan, forecast to complete), quality (defect trend, rework), risk (age and severity of open risks and issues) and people and customer (attrition risk, escalations, satisfaction). Each colour has written thresholds so two managers would rate the same project the same way. I watch leading indicators, such as rising risk age or falling throughput, because they warn earlier than missed dates.
What the interviewer is assessing
Whether you run delivery on evidence and can separate leading from lagging indicators.
Common mistakes
Listing many metrics with no thresholds
Using a status colour as a matter of opinion
Tracking only lagging measures such as missed milestones