Project Manager Interview Questions and Answers

I start by separating the cause from the remaining work, because a slip caused by a late vendor is fixed differently than one caused by an optimistic estimate. If a milestone has already passed, I re-baseline instead of pretending the original date still holds. I ask each workstream lead for the shortest credible path to done, then I look at three levers: move non-critical work out of the window, add people only where onboarding cost is clearly lower than the gain, and phase or cut scope with the sponsor's written agreement. I publish a recovery plan with new dates and the assumptions behind them, and I tell the sponsor early, because a slip they discover is far worse than a slip I report. In my last recovery I resequenced testing and delivered the first phase within [N] weeks of the reset.

I treat every scope request as a trade, never as a free addition. First I ask what problem it solves and whether it can wait for a later phase, because many urgent requests turn out to be preferences. If it is genuinely needed now, I write a change request stating the added work, the schedule impact, the cost impact and what we would drop or defer to absorb it. I bring that to the sponsor or change control board and ask for a written decision rather than a verbal nod. If they approve, I update the baseline, the RAID log and the resourcing plan in the same week so nothing drifts undocumented. If they decline, I record the decision so the same request does not quietly reappear at the end. Scope only moves when someone with authority chooses to move it.

I map the dependency to a named owner and a needed-by date, then confirm in writing that they agree with both, because an unowned dependency is a risk in disguise. If the date is at risk, I ask what they need to hit it, whether that is a decision, a test environment or a reviewer, and I offer to remove that obstacle myself. When the dependency sits on my critical path, I always build a fallback: a stub interface, a manual workaround or a phased integration, so their slip does not automatically become my slip. I escalate through our shared manager only after the direct conversation has failed twice, and I frame it as protecting their commitment rather than reporting them. Throughout, I keep the item in the RAID log with a status I refresh weekly, so the steering committee sees movement long before a milestone is threatened.

I run a short, decision-oriented meeting rather than a reading of the plan. I send the status report a day ahead so people arrive already informed, and the meeting itself covers only three things: what changed since last time, what is blocked and who owns the decision. Each lead speaks to milestones, risks and their next commitment, not to how busy they have been. I keep a visible decision log and assign an owner and a due date to every action before anyone leaves the room, because an action without a name is a wish. I close by confirming the critical path and the next checkpoint. If an update could have been read, I cut it from the agenda. The real test is whether anyone left with a decision they did not have walking in.

I start from deliverables rather than from a task list, because a schedule built on activities tends to miss work nobody named. I decompose until each work package is small enough to estimate in days, then I estimate with the people who will actually do the work, using optimistic, likely and pessimistic points instead of a single number. I map predecessors, sequence the network, and calculate the critical path and total float so we know which tasks can move without hurting the end date. I hold contingency as an explicit line item rather than padding every task, because hidden padding destroys trust in the plan and hides where the real uncertainty sits. I validate assumptions with the technical leads, record them next to the schedule, and publish a baseline with a clear change process. Early estimates carry the widest error bars, so I re-estimate at every phase gate.

My first move is knowledge capture, because the real risk is not the empty seat but the undocumented context walking out with it. I ask the departing person for a prioritized list of open decisions, key contacts and half-finished work, and I pair them with a successor for as long as their notice allows. Then I reassess the schedule honestly and tell the sponsor which milestones the change puts at risk, rather than hiding the gap behind optimism. I look at the work itself: what can be deferred, what can be split across the team, and what needs a contractor. I avoid quietly stretching everyone to cover, because an overloaded team becomes a second risk that shows up as defects and attrition. Finally I record the gap, the coverage decision and the recovery date in the RAID log so it stays visible.

I want the forecast early and honestly, so I track committed spend rather than only invoices that have landed. When I see an overrun forming, I quantify it in money and dates, identify the driver, whether that is a scope addition, an estimate miss or a vendor rate change, and I present options instead of a problem. Those options are usually to fund it with a signed change request, descope an equivalent amount of work, or phase the remainder into the next budget cycle. I bring the finance partner or PMO in before the number is locked, because a late surprise damages credibility far more than the overrun itself. Whatever is chosen, I update the forecast and the change log so the approved figure and the actual figure stay aligned.

I make the conflict visible and let the people who own the trade decide it. I list what each project needs from the same people or systems in the same window, quantify the collision in days or in deliverable impact, and present two or three sequencing options with their consequences spelled out. I never quietly let one project win while another slips without anyone noticing, because that is how teams end up with two disappointed sponsors and one exhausted group of specialists. Then I ask the portfolio owner or sponsor to choose a priority order and I record the decision with a name attached. If nobody will choose, I default to the committed external date and say so explicitly. I also watch team load, since constant context switching is itself a schedule risk that rarely appears on any plan.

I escalate the issue, not the person, and I try the direct route first. I talk to the owner, state the impact on the milestone plainly, and ask what they need from me to clear it, because most blockers are capacity or priority problems rather than indifference. If that fails, I give them a heads-up before going up: I need help removing this blocker, and I am going to ask our sponsor for a decision. That warning is what preserves trust. In the escalation itself I present facts, the impact, the options I have already tried and the specific decision I need. I never frame it as a complaint about a colleague. Afterwards I tell the owner what was decided, so they hear it from me rather than through the hierarchy, and we carry on working together as normal.

Route each request through a written change request that states schedule, cost and the trade-off, and require a named approver before the baseline moves.

Set escalation thresholds in advance, such as a slip of [N] days on a critical-path task, so raising risk early becomes routine rather than a crisis.

Review the RAID log in a standing weekly slot, close stale items, and give every open risk an owner, a trigger and a mitigation date.