Project Manager Interview Questions

My first step is to understand exactly why the project is behind. Is it a planning problem, a resource problem, a dependency that slipped, or a scope issue that was not anticipated? The root cause determines the response. Once I know the cause, I reassess the critical path and identify which activities are truly blocking delivery versus which can be parallelised or descoped without compromising the outcome. I then have an honest conversation with stakeholders as early as possible: surprises at the deadline are far more damaging than early warnings. The options I present are usually some combination of extending the timeline, reducing scope, adding resource, or accepting a phased delivery. I document whatever trade-off is agreed and update the project plan.

Prevention is better than cure. I establish a clear scope document at the start of every project describing what is in and what is explicitly out, signed off by key stakeholders. When new requests come in, I use a change request process that requires the requestor to document the ask, the business justification, and the estimated impact on timeline and budget. This creates a natural pause that filters out low-value additions. For requests that do pass that filter, I present the impact transparently to the project sponsor: additional scope must be paired with additional time, resource, or a reduction elsewhere. I never silently absorb scope changes.

I start by making sure I understand each stakeholder's underlying goal, not just their stated position. Often conflicting priorities are a symptom of different success metrics, and once those are visible, alignment becomes much easier to facilitate. I bring conflicting stakeholders together in a structured conversation rather than trying to negotiate separately. I use data and project constraints to frame decisions objectively: given our timeline and resources, which sequencing best serves the project goal? I document agreements in writing immediately after each discussion. Stakeholder alignment is not a one-time event: it needs regular maintenance.

I led a software implementation project that ran four months over schedule. The core problem was that we had underestimated the complexity of migrating legacy data and had not identified the migration workstream as critical path until week six. In the post-mortem I identified three root causes: insufficient discovery before planning, no dedicated resource for the migration workstream, and a risk register that was maintained but not actively reviewed. As a result, I now build a structured discovery phase into every project before baseline scheduling, treat data migration as a first-class workstream by default, and hold a weekly risk review as a standing agenda item.

Halfway through a product launch project, our primary external vendor informed us they could not deliver a key integration by the original date. Rather than waiting for the next steering committee, I requested an urgent meeting with the project sponsor the same day. I came prepared with three options: delay the launch by six weeks, launch without the integration and add it in phase two, or find an alternative vendor. I presented the data on each option without pre-selecting one. The sponsor chose a phased launch. Delivering bad news early with clear options is almost always better received than delivering it late with no alternatives.

During a long infrastructure migration project, the team hit a demoralising period around the halfway mark. I did three things. First, I broke the remaining work into two-week milestones and started celebrating each one visibly with specific acknowledgement of what the team had done. Second, I ran individual one-to-ones to understand what each person found motivating and adjusted task allocation where I could. Third, I created a visible progress tracker that showed how far we had come, not just how far we had to go. By the final quarter the team's energy had noticeably recovered and we delivered on time.

I am experienced with both Waterfall and Agile, and in practice most projects I have led use a hybrid approach. I use Waterfall-style planning when the scope is well-defined upfront and the cost of late changes is high. I use Agile or Scrum when requirements are likely to evolve and rapid iteration is more valuable than predictability. In hybrid projects I use Agile for the delivery workstreams and Waterfall for the governance layer: fixed milestones and budget reviews, with iterative execution in between. The methodology should serve the project, not the other way round.

I build the plan collaboratively with the delivery team, not in isolation. The people doing the work are best placed to estimate effort, and involving them early creates ownership. I start with the deliverables and work backwards, identify all dependencies, assign owners to each task, and establish the critical path explicitly. I use a RACI to make accountability clear for every workstream. Once baselined, I update the plan weekly at minimum and flag any change to the critical path as a risk immediately. A good project plan should let any stakeholder understand at a glance where the project stands and what the risks are.

I maintain a live risk register from the first week of every project. Each risk has an owner, a probability and impact rating, a trigger event, and a mitigation action. Crucially, I review the register in every project status meeting rather than just updating it. I also distinguish between risks (uncertain events that might happen) and issues (problems that have already happened), because they need different responses. For high-probability, high-impact risks I build mitigation into the project plan directly. I encourage the team to raise risks without judgement: a culture where problems surface early is far easier to manage than one where people wait until a risk becomes a crisis.