Home IT Project Manager Interview questions
IT Project Manager interview questions
The questions people actually get asked for this role, and what each one is really testing.
What to expect
IT Project Manager interviews usually test three things: whether you understand formal delivery methodology, whether you can manage people and competing demands when a project goes off track, and whether you can talk to both technical teams and business sponsors in language each of them understands. Expect a mix of process walkthroughs, past-experience questions and hypothetical scenarios rather than pure technical quizzing.
- Process: Questions asking you to walk through how you'd run a project phase, such as scoping, budgeting or closure, to check you know a recognised methodology and can apply it practically.
- Behavioural: Past-experience questions about handling scope creep, stakeholder conflict or a project that didn't go to plan, looking for evidence rather than opinion.
- Scenario/judgement: Hypothetical situations, such as a late-stage change request, to see how you'd prioritise and communicate under pressure.
- Stakeholder/client-facing: Questions about managing sponsors, executives or end-users with different priorities, since a large part of the role is translation between technical and non-technical groups.
Most processes start with a recruiter screen focused on methodology and tools, followed by a panel interview with a delivery lead or sponsor covering behavioural and scenario questions, and sometimes a case-study exercise where you're asked to sketch a project plan or respond to a mock stakeholder brief on the spot.
- 1
Walk me through how you'd take a new IT project from an initial business request to a signed-off project plan.
Why they ask: Checks whether you have a repeatable methodology for scoping, planning and getting stakeholder sign-off, rather than working ad hoc.
How to structure your answer: Answer as a sequential walkthrough: intake and requirements gathering, defining scope and success criteria, drafting timeline and budget, risk identification, then sign-off. Name the tools and artefacts you'd use at each step.
Example answer
“I'd start by running requirements workshops with the business sponsor and key users to pin down what success actually looks like, then document that as a scope statement with clear deliverables and exclusions. From there I'd build a schedule and budget in Microsoft Project, map dependencies across the IT teams involved, and put together an initial risk register. I'd bring that draft plan back to the sponsor and steering group for review before treating anything as locked in, because getting sign-off early avoids scope arguments later in the build.”
- 2
Tell me about a time you had to manage significant scope creep on a project.
Why they ask: Scope creep is one of the most common failure points in IT delivery, so interviewers want evidence you can spot it early and push back constructively.
How to structure your answer: Use STAR: describe the situation and the specific change being requested, your task in controlling it, the action you took to assess impact and negotiate, and the result for the project.
Example answer
“On one project, the business sponsor kept requesting small additions during development that individually seemed minor but together were adding weeks to the build. I logged each request against the original scope statement and put together a short impact assessment showing the cumulative effect on timeline and budget. Rather than saying no outright, I gave the sponsor a choice: defer the additions to a phase two, or extend the deadline and budget. They chose to defer, and we delivered the core scope on the original timeline with the extras captured as a follow-up project.”
- 3
A key stakeholder wants to add a major feature two weeks before go-live. How do you handle it?
Why they ask: Tests judgement under pressure and whether you protect the delivery date and quality rather than just agreeing to keep the stakeholder happy.
How to structure your answer: Talk through your immediate response, the trade-offs you'd weigh, who you'd consult, and the decision you'd land on, being explicit about the risk you're managing.
Example answer
“I wouldn't say yes or no on the spot. I'd first understand why the request has come up so late and what happens if it's not delivered, then get the technical lead to give me a fast estimate of effort and risk to the existing go-live date. If adding it threatens the release, I'd take those options to the sponsor: delay go-live, cut something else from scope to make room, or ship the current build and schedule the feature for the next release. I'd rather have that direct conversation than quietly absorb the risk and put the go-live date in danger.”
- 4
How do you track budget and forecast spend across a project, and what do you do when you see a variance?
Why they ask: Budgeting and forecasting is a named specialist skill for this role, so interviewers will probe whether you actively monitor spend rather than just report it after the fact.
How to structure your answer: Explain your regular tracking cadence and tools, then describe your escalation process when a variance appears.
Example answer
“I set up a budget baseline at the start of the project and review actual spend against forecast at least fortnightly, usually in Microsoft Project alongside vendor invoices and timesheet data. If I see a variance building, I don't wait for it to become a crisis. I dig into whether it's a one-off cost or a trend, then bring it to the sponsor early with options such as re-scoping, reallocating resources, or requesting additional budget, so there are no surprises at the next steering committee.”
- 5
Tell me about a project that didn't go to plan. What did you learn from closing it out?
Why they ask: Closing projects and capturing lessons learned is a core task for this role, and interviewers want to see honest reflection rather than blame-shifting.
How to structure your answer: STAR, with particular focus on the reflection and what changed in how you work afterwards.
Example answer
“I ran a project where we underestimated integration testing time because the requirements didn't fully account for a legacy system's quirks. It pushed the timeline out and strained trust with the sponsor. At close-out, I ran a proper lessons-learned session with the team rather than a quick sign-off, and we identified that our estimation process needed input from the legacy system owner earlier in planning. I built that into my scoping checklist for every project since, and it's caught similar risks before they became timeline problems.”
- 6
How do you keep technical teams and non-technical sponsors aligned when their priorities conflict?
Why they ask: This role sits between delivery teams and business stakeholders, so interviewers want to know you can translate and mediate rather than just relay messages.
How to structure your answer: Describe your general approach to communication and conflict, illustrated with a brief concrete example.
Example answer
“I try to give each group information in the format they actually need. Developers get detailed technical requirements and a realistic backlog in Jira or Azure DevOps; sponsors get a plain-language status update focused on scope, budget and risk, not ticket counts. When priorities clash, I bring both sides together rather than shuttling messages between them, because most conflicts I've seen come down to each group not understanding the other's constraints. Once that's visible, the trade-off conversation usually gets a lot easier.”