Updated 5 October 2026 by Ben Gallagher. Sources below.
This page covers project manager interviews in any industry. The APM and GovS 002 standards described in the first section are UK bodies and are labelled, while PRINCE2, Scrum and MoSCoW are used worldwide. Project manager panels do not want a tour of your methodology. They want to hear what you did when a plan stopped matching reality: when a milestone slipped, a sponsor kept adding scope, a supplier went quiet, a risk landed or the business case stopped adding up. Expect questions built on those moments, and expect follow-ups about your own part in them. Prepare real projects with real numbers, say what you decided, who you told and what you would change.
These are common questions for this job. Your panel will also ask about the advert and about you.
What they're testing: Owning a whole project and showing how you replanned when the first plan broke.
What they're testing: Choosing and justifying an approach from the constraints, not from habit or preference.
Look at what is fixed and what is uncertain. A fixed date with vague requirements suggests agile delivery inside a firm overall frame: a stage plan and governance for the deadline, short iterations to discover detail, and a clear must-have core protected first.
For a regulatory reporting change due on a legal date, the rules were only partly published. I planned the overall frame as stages with a board review and a fixed date, then delivered inside it in two-week sprints. The first sprints covered the Must haves we already knew, the data feeds and the submission format. As the regulator published more detail, I added items to the backlog and asked the product owner to rank them against the date. I showed the sponsor a burn-up chart with the date and the Must have line, so she could see whether we were on course. We tailored the process: sprint reviews with compliance, and a change log for anything affecting the date. We submitted a week before the deadline.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: A practical takeover routine: baseline, people, risks and a plan you can stand behind.
What they're testing: Defending an honest estimate with evidence and offering options instead of just saying no.
What they're testing: Mapping dependencies and critical path and choosing signals that warn you before a deadline is missed.
What they're testing: Diagnosing slippage first, then bringing the sponsor causes, options and a recommendation.
Find out why before I tell anyone. I would check the data, talk to the team, work out whether the slip is real or recoverable, and prepare options. Then I tell the sponsor early with the cause, the impact and my recommendation, because surprises damage trust far more than late news.
On a billing system upgrade, two weeks before a go-live milestone, the burn-down said we would finish a week late. I spent a day with the lead developer and the tester and found the cause: test environments had been unavailable for four days, so testing had stacked up. I did not go to the sponsor with only a problem. I prepared three options: add a second tester for a fortnight, drop two low-priority reports to a later release, or move the date by a week. I recommended the first because the budget allowed it and the risk to the date was lowest. I rang the sponsor that afternoon, explained the cause and the options and asked for a decision by the next morning. She chose the extra tester. We hit the milestone with a day to spare. I also asked infrastructure for a booking system for environments so it would not recur.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Making the cost of each addition visible and using change control as a decision, not a refusal.
Do not say no. Write each request down, show what it would cost in time, money or other work, and ask the stakeholder to decide with that in front of them. Agree a simple route for changes so small asks still get a fair hearing and the sponsor sees the total.
A department head kept asking for small additions to a reporting tool, a new filter here, an extra column there. Each one looked trivial, but my developers told me the last six had taken about nine days between them. I booked fifteen minutes and showed him a one-page list: six requests, nine days, and the date that had moved as a result. I said, 'I want to say yes to these, so tell me which of the planned items you would swap out.' He had not realised the total. We agreed that new asks would go on a change log I reviewed weekly with him, and each would show its effect. Over the next month he withdrew three requests himself and swapped one for a planned feature he cared less about. The relationship improved because he felt informed, not blocked.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Assessing impact on time, cost, benefits and risk, then getting a decision from the right authority.
What they're testing: Prioritising with a method such as MoSCoW and holding stakeholders to the consequences.
Put every requirement through MoSCoW with the stakeholders in one room. Ask what happens if each is missing. Anything that would make the solution pointless is a Must. Agree what moves to Won't have this time, record it, and have the sponsor confirm it.
When a cut took twenty per cent off a staff app's budget, stakeholders called twenty-two of twenty-eight requirements Must have. I ran a workshop and asked one question of each: if we launch without this, is there any point launching? That moved eleven to Should or Could. Then I showed the estimate: the Musts alone used all the reduced budget, with nothing left for overruns. Nobody liked that, so we cut the Musts to those that fed payroll and compliance and moved the rest down. I wrote a one-page record of what was in, what was out for this release, and who had agreed. Some Should haves returned in the second release. When a manager later asked why the dashboard was missing, I could show her signature on the page and the trade-off she had accepted.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Delivering inside fixed limits by trading scope and quality openly rather than quietly.
What they're testing: Understanding the interest behind a position and building a working relationship.
What they're testing: Escalating a genuine trade-off with options and consequences so a sponsor can decide.
What they're testing: Influencing through evidence, relationships and shared goals when you cannot instruct.
What they're testing: Honesty and courage with a senior person, backed by evidence and a way forward.
Tell them privately and early, with the evidence and a recommendation. Say what has changed, what the numbers show and what options exist, including stopping or reshaping. Make clear that raising it is part of protecting their reputation, and that the decision is theirs.
Six months into a customer portal, the main benefit was a reduction in phone calls. A pilot showed calls had hardly moved, and the costs had risen. I knew my sponsor had championed the project. Before the stage review I asked for a private half hour. I brought the pilot data, the revised cost and three options: carry on as planned, reshape the scope around the one feature the pilot showed customers did use, or stop and keep what we had learned. I said that I thought the second option gave the best chance of benefit, and that I would rather she heard it from me than in the board room. She was quiet, then asked for the numbers again. At the board she presented the reshaped plan herself, with a reduced budget. The project delivered the feature customers used, and she thanked me for not letting her walk in unprepared.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Managing a supplier through contract, relationship and contingency without losing the date.
Start with a direct conversation to find out why, check the contract for the commitments and remedies, and build a contingency while I wait. Agree a dated recovery plan in writing. Escalate through their account manager if there is none, and keep the sponsor informed of the options.
A supplier building an integration was two weeks late and replied to my emails with one line. I phoned their delivery lead and asked what was blocking them. It turned out their developer had been moved to another client. I checked the contract: it set delivery dates and a clause for service credits, but I did not want to open with penalties because I needed the work. I asked for a named developer and a dated plan, and said I would involve their account manager if I did not have one within two days. At the same time I asked my own team what we could do without the integration, and found we could test with a mock service. I told the sponsor the date was safe if the supplier recovered within a fortnight, and what the fallback was. The supplier provided a developer and delivered nine days later.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: A living risk process with owners, scoring, actions and review, not a one-off exercise.
What they're testing: Turning a risk into an issue calmly: containing impact, telling people and replanning.
What they're testing: Escalating early under manage by exception, with options, rather than waiting for the report.
Escalate now, not at the next report. Forecasting fourteen against a tolerance of ten is an exception, so I would tell the board chair promptly with the cause, the effect on time and benefits, and options for bringing it back or approving the extra. The decision belongs to them.
On an office move, I forecast cost fourteen per cent over after the cabling contractor re-quoted. Our tolerance was ten. I did not wait for the monthly highlight report. I called the chair of the project board that day and followed up with an exception report the next morning. It gave the cause, the forecast, and three options: accept the overspend, descope the second-floor meeting room fit-out, or re-tender the cabling and risk delay. I recommended descoping the fit-out because it carried no safety or legal impact and could be done after the move. The board approved it and reset the tolerance for the revised plan. The chair told me afterwards that the early call let them decide in a week rather than react to a surprise in a month. I recorded the lesson in the log: get second quotes before approving a baseline.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Continued business justification and the nerve to recommend stopping a project you lead.
What they're testing: Resolving conflict early and privately while keeping delivery on track.
Speak to each person separately first to understand what is going on, then bring them together around the work, not the personalities. Agree specific behaviours and a check-in. Watch whether the delivery risk is rising, and involve their line manager if it does not improve.
Two senior developers on my team stopped speaking after a code review row, and the sprint's handovers began to fail. I met each privately for twenty minutes. One felt his work had been criticised in public, and the other felt his advice was ignored. Neither had meant harm. I brought them together with the sprint board and no audience. I said the issue was handovers, not who was right, and asked each what they needed from the other. They agreed that reviews would take place in the pull request, not in stand-up, and that they would pair on the next difficult ticket. I checked in a week later and the board was moving again. I also told the team lead, in case it came back, and moved the stand-up review comments to a separate session.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Raising performance concerns through the right route without authority.
What they're testing: Introducing change by showing value, starting small and listening to resistance.
What they're testing: Understanding benefits ownership, adoption and handover beyond the delivery date.
Delivery is not the same as benefit. I would find out why people are not using it: training, process, trust or design. I would own the gap with the business owner, because benefits need an owner and an adoption plan before go-live, not after.
A booking system went live on time and on budget, but six months later half the teams still used spreadsheets. I interviewed ten users. Most had not been trained beyond a demonstration, and the system added two steps to a common task. I met the business owner, who agreed that adoption was our shared responsibility, and we ran short sessions in each team, fixed the two steps with a small change and asked managers to stop accepting spreadsheet bookings. Use rose in two months. The lesson I took was to put a benefit owner and adoption measure into the plan from the start, to run user testing on real tasks, and to keep a small budget for support after launch. On the next project, I made benefits a standing item on the board agenda.
Your answer will be different. Say yours out loud and see what it's missing.
What they're testing: Owning your share of a failure and showing what changed in your practice.
What they're testing: Making reflection safe and specific so the team acts on what it learns.
In the UK, the Association for Project Management and the government's GovS 002 standard are the reference points below. In an interview, use the vocabulary of the employer, and ask which method the team follows.
The Association for Project Management defines project management as the application of processes, methods, skills, knowledge and experience to achieve specific project objectives within agreed parameters, and says it differs from general management because its deliverables are constrained to a finite timescale and budget. APM adds that it means satisfying the differing needs of a project's stakeholders and that projects needing formal management require the management of risks.
The government's project delivery standard, GovS 002, sets out the same ground for public sector work: risk and issue management with named owners, stakeholder engagement plans, change control with recorded requests and impact assessment, benefits management with owners, assurance and learning from experience. Even if you apply for a private sector post, panels listen for these habits.
PRINCE2 7th edition has seven principles: ensure continued business justification, learn from experience, define roles, responsibilities and relationships, manage by stages, manage by exception, focus on products and tailor to suit the project. Two matter in interviews. Manage by exception means authority is delegated within agreed tolerances and a forecast breach is escalated to the next level for a decision. Continued business justification means that if a project can no longer be justified it should be stopped in a controlled way.
Scrum is a lightweight framework with three accountabilities (developers, product owner and Scrum Master) and five events including the sprint, which lasts a month or less. The Agile Manifesto's principles say to welcome changing requirements, deliver working software frequently and reflect at regular intervals on how to become more effective. A good answer never recites these. It says why you chose an approach for a particular project and what you tailored.
MoSCoW is the prioritisation method panels mention most. The Agile Business Consortium describes Must have as the minimum usable subset of requirements which the project guarantees to deliver, Should have as important but not vital, Could have as wanted or desirable but less important, and Won't have this time as excluded from the current timeframe. It also says that a requirement that is a Must at project level may be a Should or Could for an early increment.
The test for a Must is simple: if it is not delivered, is there any point in implementing the solution? Tempo's glossary gives the same four categories. Use the language, but give the example: what you moved to Won't have, who agreed and what it cost.
Careers advice agrees that the end of an interview is your turn. The National Careers Service says to bring your own prepared questions about the role or the organisation, and Prospects publishes a short list of good ones. The Muse recommends asking about day-to-day work, training and how you would grow, and Indeed says to base your questions on your research so that they show you have looked.
For this job, good questions come from the work itself:
Asking about the last project that went off plan shows that you are comfortable with reality.
Starting out is normal in this job, and panels know it. The Muse advises showing willingness to learn and using examples from study, volunteering and everyday responsibilities, and the National Careers Service recommends preparing examples from your past and telling them with the STAR method. If a question is about something you have not done, the University of Arizona's career service suggests saying so honestly and describing what you would do. Freshers, as new graduates are called in India and elsewhere, can use the same approach.
Panels value honesty about delays more than a perfect record.
Employers set their own requirements, so read the person specification. Many posts list PRINCE2, APM or agile qualifications as desirable. Panels care more that you can explain how you chose and tailored an approach on a real project.
Avoid picking a side. Say that the choice depends on what is fixed and what is uncertain, then give a project where you used one, the other or a mix, and why it fitted.
Use the biggest piece of delivery you have owned, such as a system change, an event or a process rollout. Panels want the same behaviours at any size: planning, escalation, handling change and learning.
Prepare four or five real projects that between them cover a slipped date, a scope dispute, a difficult stakeholder, a risk that happened and something that failed. One strong story can answer several questions.
Related topics: Behavioral interview questions, Common interview questions.
Related: Data analyst, Business analyst, Software developer, Sales executive.
