Watch: how to answer Program Manager interview scenarios
Sanjay Saini walks through what Program Manager interview panels test and how to answer. Then write your own answers below.
Answer in your own words before opening a model answer, by typing or by pressing Speak your answer. Your text is saved in this browser only and is never uploaded to us. Voice input uses your browser's speech service to turn speech into text; in Chrome that audio is processed by Google.
Voice input is not supported in this browser. Try Chrome, Edge or Safari, or use your keyboard's dictation (Windows + H on Windows, the microphone key on your phone keyboard).
No scenarios match that combination. Choose another topic or level.
Scenario 1RoleFoundation
How does a program manager differ from a project manager?
What the interviewer is testing: Do you define the role by the business outcome it owns, or by the size of the project?
Model answer, red flags and follow-up
A strong answer
A project manager is accountable for delivering a defined scope on time and budget. A program manager is accountable for a larger business outcome that several projects contribute to, which means managing the dependencies between them, the benefits they are meant to produce, the shared risks and the governance across the whole. The difference shows up in what I optimise. A project manager can succeed while the outcome fails. I cannot, because if every project ships and the benefit never arrives, the program has failed. The trap in the role is becoming a super project manager who micromanages workstreams instead of aligning them.
Answers that lose you the room
Describing it as a bigger project manager with more people
Defining success as every project being green
Talking about status reports and never about benefits
Expect this follow-up: Give me an example where every project was on time and the program still failed.
Scenario 2PlanningPractitioner
How do you plan a multi-team program?
What the interviewer is testing: Planning with the teams rather than for them, starting from outcomes rather than a task list.
Model answer, red flags and follow-up
A strong answer
I start with the outcome and the sponsor's constraints, then plan with the team leads rather than for them, because a plan handed down is a plan nobody owns. We break the outcome into workstreams and milestones, map the dependencies between them and identify the critical path. I then agree a governance cadence and treat the plan as something we re-plan at regular intervals, not a baseline we defend. Early in a program I would rather have a plan that is roughly right and owned by the teams than a detailed one that is wrong by week six.
Answers that lose you the room
Building the plan alone in a tool and presenting it to the teams
Detailing every task months ahead with false precision
Treating the baseline as fixed and never re-planning
Expect this follow-up: How far ahead is your plan detailed, and why that far?
Scenario 3DependenciesPractitioner
How do you manage cross-team dependencies?
What the interviewer is testing: Do you reduce dependencies, or only track them?
Model answer, red flags and follow-up
A strong answer
Tracking is the minimum. I make dependencies visible in one shared map, name an owner and a date for each during planning, and review them weekly with the teams involved, because a slipping dependency is only useful to know about early. The more valuable move is reducing them: resequencing so the dependent piece is not needed until later, moving ownership so one team can deliver end to end, or agreeing a stable interface so teams can work in parallel. If the number of dependencies grows every planning cycle, the problem is the team structure, and I take that to the sponsor.
Answers that lose you the room
Tracking dependencies in a spreadsheet with no owners or dates
Chasing owners for updates instead of fixing the cause
Expect this follow-up: The dependency count keeps rising every quarter. What do you tell the sponsor?
Scenario 4RiskFoundation
How do you manage program risk?
What the interviewer is testing: Is risk management a live practice for you, or a log updated before steering meetings?
Model answer, red flags and follow-up
A strong answer
I keep a live RAID log where every risk has an owner, a likelihood, an impact and a mitigation someone has actually committed to, and I review it on a fixed rhythm rather than when something goes wrong. What matters more than the log is looking for early signals: slipping dependencies, growing queues, people going quiet in meetings. The top few risks go to the steering group with options and a recommendation, not just a warning. A log full of items nobody owns is theatre. I would rather track ten risks that are being worked than a hundred that are only being recorded.
Answers that lose you the room
Recording risks without owners or mitigations
Only reviewing the log before steering meetings
Escalating a list of worries with no options
Expect this follow-up: Which risk on your last program did you see coming, and what did you do about it?
Scenario 5ReportingPractitioner
How do you report status to executives?
What the interviewer is testing: Whether your reports help executives decide, or just reassure them.
Model answer, red flags and follow-up
A strong answer
I keep it short, honest and built around decisions. The report shows progress against the outcome rather than activity, milestones against plan, the few risks that matter with their mitigations, and the specific asks I need from the reader. I use the same measures every cycle so trends are visible, and I explain any change to them. The discipline is refusing to green-wash. An executive who learns about a problem from my report can help; one who learns about it from a customer cannot. If a status is amber I say so, with the reason and the date I expect it to change.
Answers that lose you the room
Reporting activity such as meetings held and tasks completed
Keeping everything green until it turns red
Long reports with no explicit decisions requested
Expect this follow-up: A workstream lead asks you to keep their status green for one more week. What do you do?
Scenario 6Scope CreepPractitioner
Stakeholders keep adding scope to the program. What do you do?
What the interviewer is testing: Making trade-offs visible, instead of saying no or silently absorbing every addition.
Model answer, red flags and follow-up
A strong answer
I do not say no and I do not quietly absorb it. I return to the outcome we agreed, assess each request for its effect on timeline, cost and risk, and run it through change control so the request is visible and owned. The sponsor then decides what to trade: add time or budget, or remove something of equal size. When stakeholders see the cost of a request next to what it displaces, most either disappear or get properly prioritised. The failure I am avoiding is scope growing one small yes at a time until the program is late and nobody remembers agreeing to anything.
Answers that lose you the room
Absorbing changes to keep stakeholders happy
Refusing all changes on principle
Escalating without showing the impact on timeline and cost
Accepting additions without updating the forecast
Expect this follow-up: The request comes from your sponsor's boss. Does change control still apply?
Scenario 7ConflictPractitioner
Two workstream leads have conflicting priorities. How do you resolve it?
What the interviewer is testing: Can you resolve conflict through shared goals when you lack formal authority?
Model answer, red flags and follow-up
A strong answer
I bring the two leads together and ask each to state their goal and their constraint, because most priority conflicts turn out to be two reasonable plans competing for the same people or the same sequence. Then I use the program objectives as the tie-breaker: which choice moves the outcome further. Often there is a sequencing or shared solution neither had considered. If they still cannot agree, I escalate quickly with the options, the trade-offs and my recommendation, so the sponsor decides rather than inherits a dispute. I do not let it drift, since unresolved conflict between leads spreads into their teams.
Answers that lose you the room
Siding with whichever lead is more senior or more vocal
Waiting for the conflict to resolve itself
Escalating the dispute without options or a recommendation
Expect this follow-up: Both leads think the other one is the problem. How do you handle that conversation?
Scenario 8Schedule SlipAdvanced
The program is six weeks behind. What do you do?
What the interviewer is testing: Diagnosis before recovery, and the honesty to re-baseline rather than promise to catch up.
Model answer, red flags and follow-up
A strong answer
First I find out why, on the critical path, because six weeks late could be one blocked dependency or a systemic planning failure and the response differs. Then I lay out the options with their trade-offs: cut or defer scope, add resources where that will actually help, resequence, or move the date. I take a recovery plan to the sponsor with a recommendation, and I re-baseline honestly rather than hoping to claw the time back. The mistake I watch for is a promised recovery that only works if everything goes right from now on, because that just delays the same conversation. If adding people is on the table, I check where they would go on the critical path and how long they would take to become useful. On a program six weeks late, people added now often arrive just in time to slow the experienced team down.
Answers that lose you the room
Promising to make up the time without changing the plan
Adding people late without checking the critical path
Hiding the slip until it can no longer be recovered
Re-baselining without explaining why the original plan failed
Expect this follow-up: The sponsor refuses to move either the date or the scope. What now?
Scenario 9BenefitsAdvanced
How do you make sure a program delivers business benefits, not just outputs?
What the interviewer is testing: Ownership of benefits beyond go-live, not just delivery of outputs.
Model answer, red flags and follow-up
A strong answer
I define the benefits and their measures at the start with named owners, baseline them before anything changes, track leading indicators during delivery and measure the real result after release. Outputs are what we ship; benefits are what changes for the business as a result. If evidence during delivery shows a benefit is not going to arrive, I raise it and adjust scope or stop, rather than finishing the plan out of momentum. The trap is that benefits usually land after the program team has disbanded, so I agree at the start who owns measuring them and when.
Answers that lose you the room
Treating delivery of the scope as delivery of the benefit
Defining benefits after the fact
Having no owner for measuring benefits once the program closes
Expect this follow-up: Six months after go-live the benefit has not appeared. Whose problem is that?
Scenario 10GovernancePractitioner
How do you set up governance for a large program?
What the interviewer is testing: Governance designed backwards from the decisions the program needs, not forwards from a template.
Model answer, red flags and follow-up
A strong answer
Governance exists to make decisions faster and safer, so I design it backwards from the decisions the program needs. A steering group with small, stable membership for funding, scope and escalated risk. A working-level cadence for delivery where the leads resolve dependencies. Decision rights and escalation paths written down, so people know who decides what and how quickly. Lightweight reporting that reuses data the teams already produce. If a forum has had no decisions on its agenda for a few cycles I remove it, because meetings that only receive updates slow teams down.
Answers that lose you the room
Adding forums and reports without a decision each one serves
Unclear decision rights so everything escalates
Steering groups that only receive status updates
Expect this follow-up: The steering group meets monthly but decisions are needed weekly. What do you change?
Scenario 11ConstraintsAdvanced
You have fixed budget and people but growing demand. How do you manage?
What the interviewer is testing: Turning a capacity squeeze into an explicit prioritisation decision for the people who own priorities.
Model answer, red flags and follow-up
A strong answer
I make the constraint the starting point of the conversation, not a problem to absorb. With the sponsor I prioritise the demand by value and risk, phase delivery so the most valuable work ships first, and cut or defer the lowest-value items explicitly. I show what current capacity can deliver by when, and what each extra request displaces. What I do not do is quietly stretch the teams to cover the gap, because overloaded teams produce delays and defects that cost more than the work they were trying to fit in. The honest answer to more demand with the same capacity is a decision about what does not happen.
Answers that lose you the room
Absorbing extra demand by overloading the teams
Saying yes to everything and hoping it works out
Cutting scope without the sponsor's explicit agreement
Asking the teams to absorb the demand through overtime
Expect this follow-up: The sponsor says everything on the list is essential. What do you do?
Scenario 12VendorsPractitioner
A third-party vendor is late and blocking the program. What do you do?
What the interviewer is testing: Facts before escalation, and keeping options open while you work the problem.
Model answer, red flags and follow-up
A strong answer
I start with root cause and real impact on the critical path, since a late vendor is not always a bad one and unclear requirements or late inputs from our side are common causes. Then I engage their leadership, agree what recovery looks like with dates, and add visibility through joint planning, shorter milestones and quality gates. In parallel I keep the contractual position and alternatives ready, and I warn our stakeholders early so nobody is surprised. Formal escalation comes after the facts are agreed, not as a first reaction, because the vendor still has to be able to work with us afterwards.
Answers that lose you the room
Blaming the vendor without checking our own inputs
Escalating contractually before agreeing the facts
Having no alternative or fallback prepared
Expect this follow-up: Their leadership promises a fix but nothing changes. What is your next move?
Scenario 13Scaling AgilePractitioner
How do you decide between frameworks like SAFe, LeSS and Scrum of Scrums?
What the interviewer is testing: Knowledge of the scaling options, and whether you choose from the integration problem rather than a favourite framework.
Model answer, red flags and follow-up
A strong answer
I start from the problem: how many teams, how tightly their work is coupled, how much regulation applies and what already works. For a handful of teams on one product, a Scrum of Scrums or Nexus is usually enough; Nexus is worth knowing because it adds one integration team and a few events on top of Scrum, so adoption is cheap. LeSS suits larger groups willing to restructure around one product. SAFe brings the most structure and the most overhead, and it can make sense in a large, tightly coupled, compliance-heavy portfolio. As a program manager I care most about integration: how work from many teams comes together into one usable Increment, because that is where scaled programs usually fail. Whatever I choose, I adapt it and drop anything that is not solving a problem we actually have.
Answers that lose you the room
Recommending a favourite framework regardless of context
Not knowing the practical differences between SAFe, LeSS and Nexus
Leaving cross-team integration until the end of the program
Expect this follow-up: Leadership has already bought SAFe training for everyone. How do you proceed?
Scenario 14PI PlanningPractitioner
How do you run an effective PI or quarterly planning event?
What the interviewer is testing: Awareness that most of a planning event's value is created before it starts and lost after it ends.
Model answer, red flags and follow-up
A strong answer
Most of the value is decided before the event. I make sure priorities are agreed, pre-work is done and the right people are in the room, including those who own dependencies. During the event I make dependencies visible on a shared board, timebox discussions and finish with team commitments that include the risks they see, ideally confirmed with a confidence vote. Afterwards is where planning usually dies, so I keep the plan alive with regular syncs, update the dependency map and re-plan when reality moves. A planning event that produces a plan nobody looks at again was an expensive meeting.
Answers that lose you the room
Treating planning as a two-day event with no follow-through
Running it without the people who own the dependencies
Letting management set the plan and present it to teams
Expect this follow-up: Teams commit but you do not believe the plan. What do you do?
Scenario 15ChangePractitioner
How do you help people adopt the change a program delivers?
What the interviewer is testing: Do you treat adoption as part of the program's scope, or someone else's problem after go-live?
Model answer, red flags and follow-up
A strong answer
Delivery is not success until people use what we built, so I treat adoption as part of the program from the start. I identify who is affected and involve them early, explain the why in terms they care about, and give them training and support before go-live rather than after. I use champions inside the affected groups to carry the message and surface friction. After release I measure actual adoption and fix what is getting in the way. When adoption is low, the cause is usually something in the change that does not fit how people work, and I would rather learn that from a pilot group than from the whole organisation.
Answers that lose you the room
Assuming a training email is enough
Treating go-live as the finish line
Blaming users for low adoption
Expect this follow-up: Adoption is at 30 percent three months after go-live. What do you do?
Scenario 16EscalationFoundation
When and how do you escalate an issue?
What the interviewer is testing: Escalation as a structured request for a decision, not a complaint.
Model answer, red flags and follow-up
A strong answer
I escalate when an issue is beyond my authority, threatens a critical milestone, or its owners have not resolved it in the time we agreed. I bring facts, impact, options and a recommendation, and I tell the people involved first so nobody is surprised. Escalating is not failure; escalating late or without a clear ask is. A recurring pattern of escalations tells me something structural needs fixing.
Answers that lose you the room
Escalating without options or a recommendation
Escalating without telling the people involved
Expect this follow-up: Your peer sees your escalation as going over their head. How do you repair that?
Scenario 17MetricsPractitioner
Which metrics show the health of a program?
What the interviewer is testing: A small set of program measures that answer real questions, read as trends.
Model answer, red flags and follow-up
A strong answer
I want a small set that answers three questions: are we delivering the outcome, will we deliver on time, and is the delivery sustainable. So outcome and milestone progress, forecast against plan, dependency and risk status, delivery predictability, quality and team health. I look at trends rather than single numbers, because one data point rarely tells you anything, and I pair the numbers with conversations with the leads since dashboards lag reality. Anything I report I am prepared to explain, and I retire measures that people start managing to instead of using to decide.
Answers that lose you the room
Reporting a single percentage complete
Using metrics to rank teams against each other
Measuring activity because it is easy to count
Expect this follow-up: One metric is green but the team leads say the program is struggling. Who do you believe?
Scenario 18ResistancePractitioner
Teams resist the program's reporting process as overhead. What do you do?
What the interviewer is testing: Willingness to cut your own process when the teams are telling you something.
Model answer, red flags and follow-up
A strong answer
I treat the complaint as information. I ask what specifically is painful, and often it is duplicated effort, reports nobody reads or requests arriving in different formats. I cut anything that does not feed a decision, reuse data the teams already produce and automate collection where I can. Then I explain what the reporting protects them from: surprises, last-minute escalations and having to justify themselves without evidence. If a report survives that scrutiny and teams still resist it, I look at whether I have explained its value. If it does not survive, it should be removed.
Answers that lose you the room
Insisting on the process because it is the process
Adding more reporting to solve the resistance
Dismissing team complaints as not understanding governance
Expect this follow-up: Leadership insists on the report. How do you make it cheaper for the teams?
Scenario 19KickoffFoundation
How do you run a program kickoff?
What the interviewer is testing: Whether your kickoff produces agreement or just a slide deck.
Model answer, red flags and follow-up
A strong answer
I use the kickoff to create agreement, not to make announcements: the outcome and how we will know we reached it, roles and decision rights, the high-level plan, the biggest risks and how we will work together. I ask the sponsor to explain the why in their own words. And I leave with owners and dates, because kickoff enthusiasm fades within a week if nobody knows what to do on Monday.
Answers that lose you the room
Using the kickoff for presentations with no discussion
Leaving without owners and dates for next steps
Expect this follow-up: A key stakeholder does not attend the kickoff. What do you do?
Scenario 20DecisionsPractitioner
How do you keep decisions clear across many stakeholders?
What the interviewer is testing: How explicit you make decisions, so they do not depend on memory and goodwill.
Model answer, red flags and follow-up
A strong answer
Unclear decisions cost more than imperfect ones, so I make them explicit. I keep a decision log recording what was decided, by whom, when and why. For key areas I agree a RACI so people know who decides and who is consulted. Significant decisions go to a named meeting with named deciders, and I send written follow-up within a day. When someone reopens a settled decision I go back to the record and ask what has changed since. If something material has, we revisit it properly; if not, we move on. It protects the team from constant re-litigation.
Answers that lose you the room
Decisions made in hallway conversations and never recorded
Everyone consulted but nobody clearly deciding
Expect this follow-up: A senior stakeholder reverses a decision in a corridor conversation. What do you do?
Scenario 21Merging ProgramsAdvanced
Two programs from a merged company overlap. How do you consolidate?
What the interviewer is testing: Do you handle the people side of a merger as seriously as the scope side?
Model answer, red flags and follow-up
A strong answer
I would first map both programs: scope, dependencies, customers, teams and commitments, because the overlap is rarely as neat as the org chart suggests. Then I agree the target outcome with the merged company's leadership and decide what to merge, what to stop and what to keep separate for now. I phase the transition so delivery commitments are protected while it happens. The people side matters most. I involve both teams early, use joint planning, and avoid decisions that look like one side winning, because an us-versus-them dynamic will cost more time than any duplicated scope.
Answers that lose you the room
Treating it as a scope merge and ignoring the people
Deciding the outcome without the leaders of both programs
Merging everything at once and putting commitments at risk
Expect this follow-up: Both program leads want to lead the merged program. How do you handle it?
Scenario 22AI in PMPractitioner
How can AI help a program manager, and what must you verify?
What the interviewer is testing: Practical use of AI for drafting and pattern-finding, with accuracy and confidentiality still on you.
Model answer, red flags and follow-up
A strong answer
AI is useful for the drafting and pattern-finding parts of the job: first drafts of status reports, meeting summaries, scanning the RAID log or delivery data for risks I might have missed, and suggesting dependencies from plans. What it cannot do is know whether any of that is true. So I verify facts with the owners before anything is sent, I keep confidential program and client data out of tools that are not approved, and I remember that I stay accountable for anything that goes out under my name. The time it saves should go into conversations with people, which is where programs are actually rescued.
Answers that lose you the room
Sending AI-drafted status reports without verifying them
Pasting confidential program data into public tools
Presenting AI risk analysis as fact rather than a prompt for discussion
Expect this follow-up: An AI meeting summary misstates a decision. How do you find out, and how do you stop it happening again?
Scenario 23AmbiguityAdvanced
How do you run a program when the desired outcome is still uncertain?
What the interviewer is testing: Planning for learning when the outcome is unclear, instead of faking certainty.
Model answer, red flags and follow-up
A strong answer
When the outcome itself is uncertain, a detailed long-range plan is false comfort. I plan in short horizons with learning milestones, treat early phases as experiments and set explicit decision points where the sponsor chooses to continue, pivot or stop. I share ranges instead of fixed dates and say which parts of the plan are firm and which are hypotheses. The sponsor stays close to what we are learning, so a pivot is a decision made with evidence rather than a surprise. The discipline is agreeing in advance what evidence would make us stop, since it is very hard to stop a program once it has momentum.
Answers that lose you the room
Producing a detailed fixed plan for an uncertain outcome
Never defining what would cause a stop or a pivot
Keeping the sponsor at a distance from what is being learned
Expect this follow-up: The sponsor wants a committed date anyway. What do you offer?
Scenario 24Close-outFoundation
How do you close a program well?
What the interviewer is testing: Closing on benefits and a real handover, not on the go-live date.
Model answer, red flags and follow-up
A strong answer
A good close-out confirms that the work was accepted and that the intended benefits have a path to being realised. That means confirming acceptance criteria, handing over operations and support with real knowledge transfer, and documenting lessons learned in an honest retrospective with the whole team rather than only the leads. I release the team deliberately, recognising what they did, and communicate the results to the stakeholders who backed us. Then I follow up several months later to check the benefits arrived, because that is the only way to find out whether the program actually worked.
Answers that lose you the room
Closing the program on the day of go-live with no handover
Skipping the retrospective because the team is already moving on
Expect this follow-up: Operations say the handover was inadequate after you have closed. What do you do?
Scenario 25SponsorAdvanced
Your executive sponsor has lost interest and decisions are stalling. What do you do?
What the interviewer is testing: Managing upward without going around the sponsor.
Model answer, red flags and follow-up
A strong answer
Stalling decisions usually mean the program has slipped down the sponsor's list, so I start by reconnecting it to what they care about now. I share a concise view of the risks of inaction, the specific decisions I need and by when, and the cost of each week of delay. I make it easy to decide: options and a recommendation on one page. If they will not engage, I ask whether a delegate with real authority can decide on their behalf. Only if that fails do I raise it with their peers or leadership, openly, with the sponsor informed first.
Answers that lose you the room
Continuing to deliver without decisions and hoping
Going around the sponsor without telling them
Complaining about the sponsor to the team
Expect this follow-up: The sponsor's delegate has no real authority. What now?
Scenario 26Financial ControlAdvanced
The program's forecast shows a 15 percent overspend at the current burn rate. What do you do?
What the interviewer is testing: Root cause, an honest forecast and real options for the sponsor while choices still exist.
Model answer, red flags and follow-up
A strong answer
I first find out where the overspend comes from, because the response differs: scope growth, an underestimate, a vendor cost, or inefficiency inside the program. I forecast to completion from what I actually expect, not from the budget, so the number I present is one I believe. Then I take options to the sponsor early: reduce scope, phase delivery, reallocate from elsewhere, or seek more funding with a clear case. Each option shows what it costs in outcome and risk. The worst time to raise a forecast overspend is after the money has been spent, so I raise it while there are still choices.
Answers that lose you the room
Waiting until the money is spent to raise the forecast
Presenting a single option to the sponsor
Quietly cutting testing or quality to fit the budget
Waiting for the overspend to be confirmed before raising it
Expect this follow-up: Finance says the budget cannot move and the sponsor wants full scope. What do you propose?
Scenario 27Status IntegrityAdvanced
Every workstream reports green, but you sense the program is in trouble. How do you find out?
What the interviewer is testing: Evidence beyond self-reported status, and awareness of how your own process shapes what people tell you.
Model answer, red flags and follow-up
A strong answer
Green from every workstream alongside a nagging feeling is a signal to go and look, not to trust the reports. I look at evidence that does not depend on self-reporting: whether milestones are actually being met, how long work waits, the state of the dependency map, defect and quality trends, and whether anyone is still raising risks. I have small informal conversations with people below the leads and ask what would worry them. Often the pattern is that leads do not feel safe reporting amber. If so, the fix is in how I respond to bad news, because people report whatever earns a good reaction. Practically, I go and look: attend a team's Sprint Review, check a working Increment, look at the defect trend and ask the people doing the work what worries them. I also ask whether my own reporting process punishes amber, because if it does, I have taught people to report green.
Answers that lose you the room
Trusting green reports because the process says to
Questioning leads about their status in front of others
Never talking to anyone below the workstream leads
Adding more fields to the status report
Expect this follow-up: What have you done that made people feel safer reporting bad news?
Scenario 28Shared ResourcesPractitioner
Your program shares key people with two other programs and they keep being pulled away. How do you handle it?
What the interviewer is testing: Cross-program capacity handled through visibility and decisions, not favours.
Model answer, red flags and follow-up
A strong answer
I make the contention visible with facts: which people, how much of their time each program has claimed, and what my program loses when they are absent. Then I take it to whoever owns the portfolio priorities, since two programs competing for the same person is a prioritisation decision neither can settle alone. In the meantime I reduce the exposure: documenting what these people know, pairing them with others and sequencing work that needs them into agreed windows. I avoid relying on personal favours from the other program managers because they do not survive the first deadline.
Answers that lose you the room
Relying on personal relationships to keep the people
Letting the individual decide which program wins
Escalating without data on the cost of the absence
Expect this follow-up: The other programs are higher priority. How do you plan around that?
Scenario 29Agile and Fixed PlansAdvanced
The sponsor wants a fixed-scope, fixed-date plan, but the delivery teams work in Scrum. How do you reconcile them?
What the interviewer is testing: Can you bridge a fixed plan and an empirical one without breaking either?
Model answer, red flags and follow-up
A strong answer
I start by understanding what the sponsor actually needs, which is usually predictability and confidence rather than a fixed scope. I give them a plan they can steer by: an outcome-based roadmap with milestones, a forecast range from the teams' real throughput, and a clear split between scope that is firm and scope that is flexible. The teams keep working in Scrum and their sprint results feed the forecast, so the sponsor sees updates based on real data. If the date is truly immovable then scope is the variable, and I make that explicit so it is a decision rather than a surprise.
Answers that lose you the room
Forcing the teams to plan the whole scope up front
Telling the sponsor that agile means no dates
Promising fixed scope and fixed date with no way to flex
Expect this follow-up: The sponsor's contract with their customer fixes both scope and date. What do you do?
Scenario 30BehaviouralAdvanced
Tell me about a program that delivered its outputs but not the benefit it promised.
What the interviewer is testing: Do you understand that outputs are not outcomes, and can you own a benefits gap without blaming the business?
Model answer, red flags and follow-up
A strong answer
Structure it as the business case, what the program shipped, what the benefit measures actually showed and your own part in the gap. Strong examples are specific: a system delivered on time that users worked around, or a cost saving that disappeared because the old process was never switched off. The credibility comes from naming what you could have seen earlier, such as benefits nobody owned after go-live or adoption that was never measured, and from the change you made afterwards, like owning benefit measures from the start or keeping the program open until adoption was proven. Avoid blaming the business for not using what you built; making it usable was the program's job too.
Answers that lose you the room
Describing a late delivery rather than a missing benefit
Blaming users or the business for not adopting it
Expect this follow-up: Who owned the benefit after go-live, and should it have been you?
0 of 30 attempted
Keep going
Practise the neighbouring roles, or see every question in one place.