These preparation themes come from the questions in this role’s bank. They help you organise your examples; individual employers may assess different things.
Motivation & career fit
Stakeholders
Delivery fundamentals
Scope & change control
Project recovery
Risk & issue management
A useful preparation sequence
Choose your experience level and the round you expect.
Answer one question in your own words before opening its guide.
Compare your reasoning, evidence and trade-offs; adapt the answer to your experience.
Practise the follow-up, then revisit one answer you want to improve.
Representative questions and answer guidance
Open any question to read its answer. The complete guidance is included on this page.
HR · Mid-level / Senior
1. Why do you want to move from project management into delivery or programme management?
Answer guide
Give an honest reason linked to your experience. For example, you have enjoyed looking beyond a single project to the customer relationship, the commercial health and the growth of people, and you have already taken on some of that responsibility. Give one or two concrete examples, such as mentoring a team, handling a customer escalation or managing a budget. Show that you understand the change in the role: less hands-on planning and more influence, judgement and accountability for outcomes you do not control directly.
What this question explores
Motivation grounded in evidence and realism about the change in the role.
Common mistakes
Talking only about title or pay
Showing no evidence you have already done part of the role
2. How would you handle two senior stakeholders who disagree on priority?
Answer guide
I would first find out why each of them holds their view, since priority conflicts often hide different success measures or unstated dependencies. Then I would bring them together with facts: the value, cost, deadline and risk for each option, and agreed criteria to compare them. The aim is a documented trade-off they both understand. If they still disagree, escalate to whoever holds the decision right under governance, presenting the options neutrally, rather than letting the team guess or favour the louder voice. Afterwards, communicate the decision to everyone affected so it stays settled.
What this question explores
Whether you resolve senior conflicts through criteria, facilitation and proper escalation, staying neutral and keeping the team out of the middle.
Common mistakes
They side with the more senior person, or the one who shouts louder, without comparing the options.
They let the team pick between the priorities themselves, leaving people to absorb the conflict.
Practise a follow-up
Who decides when the two stakeholders both outrank you?
How would you record and communicate the final decision?
3. What is the difference between a project, a programme and a portfolio?
Answer guide
A project is a temporary effort with a defined scope, budget and end date that produces a specific result. A programme groups several related projects that are managed together because the combined benefit is greater than the parts, for example a digital transformation made of a new app, a data migration and a training rollout. A portfolio is the wider collection of projects and programmes an organisation runs, managed to balance investment, risk and strategic priorities. Projects deliver outputs, programmes deliver benefits, and portfolios decide which of them are worth funding.
What this question explores
Clear grasp of the basic vocabulary and of who is accountable for what at each level.
Common mistakes
Saying a programme is just a big project
Defining terms without any example
Confusing delivering outputs with delivering business benefits
Practise a follow-up
Which of the three have you managed?
How does a programme manager's day differ from a project manager's?
4. How do you handle scope creep on a fixed-price engagement?
Answer guide
Anchor everything to the signed scope and a change control process agreed at the start. When a new request arrives, separate clarification of existing scope from genuinely new work, estimate the effect on cost, schedule and risk, and give the customer choices: add budget, extend time, swap something out or defer it. Get approval in writing and record it in the change log. Keep the tone collaborative so the customer sees a partner protecting the outcome, not a vendor saying no.
What this question explores
Commercial discipline without damaging the relationship.
Common mistakes
Absorbing extra work silently to keep the customer happy
Saying no without offering options
Agreeing verbally and never documenting it
Practise a follow-up
The customer insists it was always in scope. What now?
5. You have just taken over a project that is already running late. What do you do in the first two weeks?
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 this question explores
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?
6. What is a RAID log and how do you keep it useful?
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 this question explores
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.
7. What evidence would you seek before approving a project business case?
Answer guide
Before approving, I want a sharp problem statement, the options considered including doing nothing, and a cost range with the assumptions behind it. I look for benefits that are specific and measurable, with a named owner who will still be accountable after go-live, plus the main risks, dependencies and the sponsor's commitment. I also ask what would make the case fail, such as adoption or funding gaps, and what threshold would make us stop. A good case lets the decision-maker compare this investment with alternatives, so I would challenge optimistic figures with a sensitivity view.
What this question explores
Whether you can challenge a business case for evidence on options, benefits, ownership and risk, not just approve a well-formatted document.
Common mistakes
They accept headline benefits and a single cost figure without asking for assumptions or an owner.
They compare only the proposed project with itself, never with the alternatives or doing nothing.
Practise a follow-up
How would you test whether the promised benefits are realistic?
What would you do if the sponsor wants approval before the cost range is reliable?
8. Steering meetings receive green status while milestones slip. How do you reset governance?
Answer guide
When green reports coexist with slipping milestones, the reporting is the problem. I would replace opinion-based status with evidence: measurable thresholds for amber and red, milestone completion checked against agreed criteria, forecast dates and the number of unresolved decisions and dependencies. An independent review of one or two key milestones helps calibrate, and the steering group should see trend, not just colour. I would make raising a red safe, escalate exceptions early with options, and track action closure.
What this question explores
Whether you can reset governance with objective thresholds, independent checks and a culture where bad news reaches decision-makers early.
Common mistakes
They keep reporting green to avoid alarming the steering group, hoping the team recovers the time.
They replace the status format but not the thresholds, so the same opinion-based colours continue.
Practise a follow-up
How would you make it safe for project managers to report red?
What evidence would you ask for before accepting that a milestone is complete?
9. Tell me about a time you had to give bad news to a senior customer stakeholder.
Answer guide
Use the STAR structure and keep the focus on how you handled it. Situation: a slipped milestone, a quality problem or a cost overrun. Action: you gathered the facts first, met the stakeholder directly instead of sending an email, stated the impact plainly, took ownership, and arrived with two or three options and a recommendation. Result: the stakeholder's reaction, what was agreed, and what you changed so it would not repeat. Choose a real example where trust was kept or rebuilt.
What this question explores
Honesty, ownership and the ability to bring solutions alongside a problem.
Common mistakes
Choosing a story where you were not responsible
Spending most of the time on the problem instead of the response
10. What belongs in a project charter and how is it used?
Answer guide
A charter is the short document that authorises the project and sets its frame. It records the objectives, what is in and out of scope, the sponsor and the authority the manager holds, success measures, a high-level schedule and budget, key assumptions, and major risks. Its use is alignment: stakeholders agree on what is being attempted before detailed planning begins, and later it is the reference when scope or priorities are disputed. A simple example is a system replacement whose charter says legacy reporting is out of scope. It should be short enough that people actually read it.
What this question explores
Whether you know a charter authorises the project and sets shared boundaries, and can describe how it is used later.
Common mistakes
They describe the charter as a long plan with task lists instead of a short authorising document.
They write it once, file it away, and never use it to settle scope or authority questions.
Practise a follow-up
Who should sign the charter, and why does it matter?
How does a charter differ from a detailed project plan?
11. A project shipped on time but users reject it. Was it successful?
Answer guide
Not fully. Delivering on time shows the team met the plan, but the point of a project is the outcome the users and business wanted. I would separate outputs from outcomes: look at adoption, the acceptance criteria that were agreed, and what users actually say is wrong, then decide whether the gap is a requirement miss, a usability problem or a change-management failure. I would report the schedule success honestly while taking ownership of a corrective plan with the sponsor, including who owns benefit realisation. Calling it a success on dates alone would hide the real problem.
What this question explores
Whether you distinguish delivery outputs from business outcomes and respond to rejection with analysis and corrective action, not defence.
Common mistakes
They point to the schedule and budget and declare success while users refuse to use the product.
They blame the users for resisting change without analysing whether the requirements were met.
Practise a follow-up
How would you find out why the users rejected the solution?
What would you have done earlier to detect the adoption risk?
12. A sponsor adds a feature late but refuses a date or budget change. What do you do?
Answer guide
I would neither refuse nor quietly absorb it. First estimate the effect on scope, time, cost, quality and risk, then bring the sponsor real options: swap the feature for lower-priority work, extend the date, add budget or resources, or defer it to a later release. Show what each option gives up. Whoever has the authority must make the decision in writing through the change process, after which I update the baseline, plan and communication to the team. If the sponsor wants everything with no change, I would explain plainly that quality or risk will absorb the difference.
What this question explores
Whether you handle late scope with impact analysis, options and an authorised decision instead of silent absorption or a flat refusal.
Common mistakes
They agree to the feature and quietly squeeze the team, letting quality and morale take the hit.
They refuse outright without quantifying the impact or offering the sponsor any trade-off options.
Practise a follow-up
How would you present the trade-off options to the sponsor?
What would you do if the team says the change cannot be estimated yet?
Choose one answer containing an example or practical sequence. Explain what you would actually do, what you would check and when you would ask for help. Keep claims about your experience honest.
For technical or regulated work, check current documentation and applicable local requirements alongside this practice material.