Project Manager interview questions and answers

A project charter is the document that formally starts a project and gives the project manager the authority to use the organisation's resources on it. The sponsor issues or signs it.

It usually covers the purpose and business case, measurable objectives and success criteria, high-level scope and what is out of scope, key milestones, a summary budget, the main stakeholders, known risks and assumptions, and the names of the sponsor and project manager. It stays short and high-level; detail comes later in the scope statement and plans. Interviewers like it when you add that the charter is what you go back to when people disagree about why the project exists.

A work breakdown structure, or WBS, breaks the project's total scope into smaller deliverables, level by level, until each lowest piece, a work package, is small enough to estimate, assign and track. The 100% rule applies: together, the pieces must cover all the work, and nothing outside it.

For a website, level one might be project management, design, content, development, testing and launch. Design splits into wireframes, visual design and approval; content into page copy, images and SEO details; launch into hosting, domain and go-live checks. A WBS is built around deliverables, not dates; the schedule is made from it afterwards.

Scope creep is work added to a project without adjusting time, cost or resources, usually in small pieces: an extra field here, another report there. It comes from vague requirements, stakeholders going straight to team members, and team members adding extras on their own, which is called gold plating.

To control it: agree a clear scope statement that lists what is excluded as well as included, get it signed off as the baseline, and run every change through a change request. Each request gets an impact analysis on schedule, cost and quality, and the sponsor or change board decides. Approved changes update the baseline, so the plan always matches reality.

I'd welcome the request but not agree to it on the spot. First I'd check the contract or statement of work to confirm the reports are really outside scope. Then I'd log a change request and have the team estimate the effort and the effect on the delivery date.

I'd go back to the client with options: add the reports as a paid change with a revised date, swap them for lower-priority items of similar effort, or move them to a second phase. Whatever we agree goes in writing before anyone starts. Doing "quick" extras quietly on a fixed-price project eats the margin and sets an expectation for every future request.

The critical path is the longest chain of dependent tasks from the start of the project to the end. Its length is the shortest time the project can take, and its tasks have zero float: if any of them slips by a day, the end date slips by a day, unless something else is changed.

For example, if design (5 days) leads to development (10 days) and then testing (4 days), while content (8 days) runs alongside, the path through design, development and testing is 19 days and critical; content has float. So I'd watch critical tasks most closely and put the best people and any extra effort there first.

A Gantt chart is a bar chart of the schedule: each task is a bar on a timeline, with arrows for dependencies and diamonds for milestones, which are points with zero duration such as "design approved".

There are four dependency types. Finish-to-start, the most common: testing can't start until development finishes. Start-to-start: documentation can start once development starts. Finish-to-finish: testing can't finish until development finishes. Start-to-finish, which is rare: the old system can't be switched off until the new one starts. Lead and lag adjust them, for example testing starts five days after development starts. Tools like MS Project, Jira or Smartsheet draw them.

First find out why it slipped and whether the delay is on the critical path; a late task with float may not matter. Then look at the options. Fast tracking runs tasks in parallel that were planned one after another, such as starting testing on finished modules early, which adds risk. Crashing adds resources to critical tasks, which costs money and only works if new people can be productive quickly. Reducing scope, with the sponsor's agreement, moves lower-priority items to a later release.

Usually it's a mix. I'd tell the sponsor early with a recovery plan and a realistic date, rather than hoping to catch up silently.

I'd ask the people who will do the work, and use more than one method. Analogous estimates use similar past projects. Three-point estimates ask for an optimistic, most likely and pessimistic figure; the PERT formula weights them as (O + 4M + P) ÷ 6. With 4, 6 and 14 days, that gives 7 days, longer than the most likely 6, because the risk of delay is higher than the chance of finishing early.

Then I'd add a contingency reserve based on the risk register, give a range rather than a single date early on, and refine the estimates as the work becomes clearer.

A risk is an uncertain event that hasn't happened yet but could affect the project's goals if it does. An issue is a problem that is happening now and needs action. Risks can also be positive, opportunities, such as a vendor finishing early.

Example: "Our only database expert may leave during the project" is a risk; you might reduce it by having a second person learn the work. If he hands in his resignation, it becomes an issue: it moves from the risk register to the issue log with an owner and an action plan. A good project manager spends time on risks so there are fewer issues later.

A risk register is the list of identified risks and what's being done about each. Typical columns: an ID; a description written as cause, risk and effect ("Because the vendor has other clients, they may deliver late, which would delay testing"); probability and impact, often on a 1-5 scale; a score (probability × impact) to rank them; an owner; the response strategy and actions; a trigger or warning sign; and the status.

It only helps if it's kept alive: review the top risks every week with the team, close old ones and add new ones. A register written at the start and never opened again is a common mistake.

For threats: avoid, by changing the plan so the risk can't happen, such as dropping an untested technology; transfer, by passing the impact to someone else, such as insurance or a fixed-price contract with a vendor; mitigate, by reducing probability or impact, such as finishing outdoor work before the monsoon; accept, either doing nothing or keeping a contingency reserve; and escalate, when the risk is beyond the project's authority, to the programme or sponsor.

For opportunities the matching responses are exploit, share, enhance, accept and escalate. A strong answer explains how you choose: by the risk's score, the cost of the response and who can act on it.

It's now an issue, so I'd act on it the same day. First get the facts: how late, which data, and why. Then work out the options with the team: go live with the data that is ready and migrate the rest in a second wave, add people from our side to help clean the data, run the old system in parallel for longer, or move the go-live date.

I'd take those options, with their cost and risk, to the sponsor and the client's lead for a decision, not just report the problem. Afterwards, update the plan and risk register, and note the lesson: data readiness needs its own early checkpoints.

I'd start by listing everyone affected by the project or able to affect it: sponsor, client, users, team members, other departments, vendors, and sometimes regulators. Then I'd place them on a power and interest grid. High power and high interest: manage closely, with regular meetings. High power, low interest: keep satisfied with short updates. Low power, high interest: keep informed. Low on both: monitor.

I'd record it in a stakeholder register with each person's role, expectations and preferred way of communicating, and revisit it as the project changes, since a quiet stakeholder can suddenly become very interested near go-live.

A communication plan sets out who needs what information, how often, in what form and from whom. For example: a daily stand-up for the team; a weekly status report to the sponsor and client, with an overall RAG (red, amber, green) status, progress, the next week's plan, top risks and decisions needed; a fortnightly or monthly steering committee for senior stakeholders; and a shared tracker or dashboard for anyone who needs detail.

It should also say how escalations work: what goes to whom and how fast. The aim is that no one is surprised. I'd check with key stakeholders after a few weeks that the reports are actually useful to them.

I'd talk to the stakeholder privately first, assuming good intent: often they're worried about something or feel they aren't getting information fast enough. I'd explain the effect: "When the team gets requests directly, the planned work slips and I can't tell you its true impact." Then agree a better route, such as a short weekly call or a direct line to me for urgent items, with changes going through the change process.

I'd also ask the team to pass such requests to me politely, without refusing the person. If it continues, I'd raise it with the sponsor, calmly, with examples of the impact.

Scrum works in fixed-length sprints, usually two weeks, with defined roles: Product Owner, Scrum Master and Developers. It has set events: Sprint Planning, the Daily Scrum, the Sprint Review and the Sprint Retrospective. The team commits to a sprint goal and changes to the sprint are limited.

Kanban has no sprints or prescribed roles. Work flows continuously across a board with columns such as To do, In progress and Done, and work-in-progress limits stop too many items being started at once. It's measured by lead time and cycle time. Scrum suits product development with regular releases; Kanban suits support and operations work that arrives unpredictably.

Velocity is the amount of work, usually in story points, a team completes in a sprint. Averaged over a few sprints, it helps forecast: a backlog of 120 points with a velocity of around 30 needs about four sprints. A burndown chart plots the work remaining against the days of the sprint, with an ideal line for comparison. If the actual line stays flat, work is stuck or was underestimated, which is worth raising in the Daily Scrum.

Two cautions: story points mean different things in different teams, so don't compare teams' velocities, and don't turn velocity into a target, or the estimates simply inflate.

In many organisations, especially service companies delivering to clients, the project manager still owns things Scrum doesn't cover: the contract and budget, release dates agreed with the client, dependencies across several teams, vendor management, risk, and reporting to senior stakeholders. The Product Owner decides what to build and the team decides how; the project manager makes sure the wider project around them works.

In practice that means turning velocity into release forecasts, removing blockers outside the team's control, and keeping the client informed, without assigning tasks to developers or running the Daily Scrum as a status meeting. Mention a hybrid model if you've worked in one.

Good uses are first drafts: turning rough notes or a meeting transcript into minutes with decisions and actions, drafting a weekly status report, rewriting a difficult email more clearly, or brainstorming risks I might have missed for a new type of project. I'd always edit and check the result myself.

I'd never paste client-confidential material, contracts, pricing, personal data about employees, or anything covered by an NDA into a tool the company hasn't approved, because some free tools may keep or learn from what you type. I'd use the company's approved tool, such as an enterprise version with data protection, and follow its policy.

I'd treat it as a draft and check it against the transcript and my own notes. I'd verify every decision and action item: is the owner right, is the date right, was it really agreed or only discussed? AI summaries often turn a suggestion into a decision, drop disagreements, or get names wrong when speakers aren't clearly identified in the transcript.

It helps to ask for the output in a fixed format, decisions, actions with owner and date, open risks, and to ask it to quote the transcript for each decision. For sensitive decisions, I'd confirm the wording with the chair before sending. I'm accountable for the minutes, not the tool.

I'd give it a role, the audience, the format and clear limits. For example: "You're helping a project manager write a weekly status report for the client's sponsor, a senior manager with little time. Using only the notes below, write: an overall RAG status with one line of reason; this week's achievements; next week's plan; the top three risks or issues with owners; and decisions needed from the sponsor. Keep it under 250 words in plain business English. If something is missing from the notes, write [TBC] instead of guessing."

The "only the notes" and "[TBC]" instructions reduce invented details. I'd still check the RAG status myself.

Show that you already enjoy the actual work: planning, coordinating people and getting things finished. "In my final-year project / at [company] I ended up coordinating the team: I made the plan, tracked who was doing what and kept our guide updated, and we delivered [result] on time. I enjoyed that more than [other part of the work]. I'm now preparing for [CAPM / a project management course] and want to start as a [project coordinator / associate project manager] to learn how larger projects are run."

Avoid saying you want to manage people or stop doing technical work; talk about delivering results.

Answer honestly and show you understand what each one means. For someone starting out: "Not yet. I'm preparing for CAPM, which is designed for people early in their careers, and I've completed [a course or Scrum training]. I plan to take the PMP once I have the project experience it requires." PMP needs several years of experience leading projects, so freshers can't take it yet; PRINCE2 Foundation and a Scrum certification are also common.

Then add that a certificate teaches the vocabulary, while the job is learned by running real projects, and give an example of what you've already managed.

Choose a real project, own your part, and show how you recovered it. Use STAR: "We were building [system] for [client], and by month three we were four weeks behind because the client's requirements kept changing (situation). I had to bring the date back under control (task). I froze the scope for the first release, set up a weekly change review with the client, and moved two developers from a less critical module (action). We released two weeks late instead of six, and the client renewed for phase two (result)."

End with the lesson: "I now agree a change process in the kick-off meeting."

Show that you find the cause before judging. I'd talk to them privately and ask what's getting in the way: unclear tasks, too much work, a skill gap, or a personal problem. Then act on the cause: break tasks into smaller pieces with check-ins, rebalance the workload, pair them with someone experienced, or arrange training.

Example: "A developer kept missing dates; it turned out he was also supporting the old system for another team. I agreed with that team's manager to limit his support hours, and his delivery was back on track within a sprint." If nothing improves, involve their manager or HR, with clear examples.

Say it early, say it plainly, and come with a plan. Structure: what has happened, why, the impact, the options and your recommendation. "I want to flag that the release will be about two weeks late. The payment integration took longer because [reason]. We can release on the original date without [feature], or release complete on [new date]. I recommend [option] because [reason]."

Don't hide it until the last day or blame the team in front of the client. Interviewers want to hear that you protect the relationship with honesty, and that you follow up in writing.