Project Manager Interview Questions and Answers

A project moves through five process groups: initiating, planning, executing, monitoring and controlling, and closing.

• Initiating: define the business need, write the project charter, find the stakeholders, and get approval to start.
• Planning: define the scope and the WBS, estimate effort and cost, build the schedule, and plan risks, communication, quality and people.
• Executing: build the team, do the work, manage what stakeholders expect, and hold regular meetings.
• Monitoring and controlling: compare progress with the baseline, manage risks and changes, report status, and fix problems.
• Closing: get acceptance, hand over to operations, release the team, write down lessons learned, and archive records.

In software projects these groups overlap. In agile, the cycle repeats every sprint or release.

What they are checking: Do you know a clear project lifecycle, and can you explain what happens in each phase?

A project charter is a short document that formally approves the project. It gives the project manager the right to use resources. The sponsor usually issues it.

Typical contents:

• Project purpose and business case
• Goals and measurable success criteria
• High-level scope and main deliverables
• Major milestones and a rough timeline
• Summary budget
• Key stakeholders, sponsor and project manager
• High-level risks, assumptions and constraints
• Approval signatures

It is short (one to three pages) and stays stable. The project plan is detailed and changes often. Without a charter, the team has no agreed reason for the project.

What they are checking: Can you tell the difference between approval of a project and detailed planning?

The charter approves the project at a high level. The plan describes how the work will be done.

The plan is a set of smaller plans: scope, schedule, cost, quality, resource, communication, risk and procurement. It also has baselines for scope, schedule and cost.

What they are checking: Do you know both documents and why each one exists?

Scope management defines what is in and out of the project. It makes sure only that work gets done.

• Collect requirements and write a clear scope statement with exclusions.
• Break the scope into a work breakdown structure (WBS).
• Get written sign-off on the scope baseline.
• Send every new request through change control. Log it, check the effect on time, cost and quality, and get approval from the sponsor or change board.
• Check deliverables with the customer at acceptance points.

To control scope, compare the actual work with the baseline. Say "yes, with this impact" or "not now". Never quietly accept extra work.

What they are checking: Do you protect scope with a process instead of random yeses?

A WBS breaks the total scope into smaller, easy-to-manage deliverables. It shows what must be produced, not when or by whom.

• Level 1 is the project. Level 2 is the major deliverables or phases. Lower levels break these into work packages.
• Work packages are small enough to estimate, assign and track (often 8 to 80 hours of effort).
• The 100 percent rule: the WBS includes all the work in scope and nothing outside it.
• A WBS dictionary describes each element.

Example for a website: Design, Development (frontend, backend, database), Testing, Deployment, Training. The WBS is used for estimates, schedules and the budget.

What they are checking: Can you break down scope, and do you know why a WBS is used?

Scrum has five events inside the sprint.

• Sprint: a fixed time box (one to four weeks) that contains all the other events.
• Sprint planning: the team picks backlog items and agrees on a sprint goal and a plan.
• Daily scrum: a 15 minute check by the developers. They look at progress toward the goal and adjust the plan for the next 24 hours.
• Sprint review: the team shows the work done to stakeholders and gets feedback to update the backlog.
• Sprint retrospective: the team looks at its own process and agrees on improvements.

Backlog refinement is an ongoing activity, not a formal event. As a PM, I use these events to keep things visible without extra status meetings.

What they are checking: Do you know the events of the framework and why each one exists?

I estimate bottom-up from the WBS and use more than one method. I treat estimates as ranges, not promises.

• Ask the people who will do the work.
• Use analogous estimates from similar past projects for early numbers.
• Use three-point estimation: (optimistic + 4 x most likely + pessimistic) / 6.
• In agile, use story points and relative sizing with planning poker.
• Add contingency for known risks and a management reserve for unknown ones.
• Improve estimates as we learn more (the cone of uncertainty).

I write down the assumptions behind each estimate. I also compare actuals with estimates to make the next ones better.

What they are checking: Do you use clear estimation methods and explain uncertainty?

A risk register is a living list of risks. It also holds the analysis and the response plan for each one.

Each entry usually has:

• ID and description (cause, event, impact)
• Category (technical, resource, external, schedule)
• Probability, impact and a score
• Owner
• Response strategy: avoid, mitigate (reduce), transfer, or accept for threats. Exploit, enhance, or share for opportunities.
• Actions to reduce the risk, a backup plan, and a trigger
• Status

I review it every week with the team. I add new risks and close old ones. A register nobody reads is useless, so the top five risks go into the status report.

What they are checking: Do you manage risk actively instead of listing it once?

The critical path is the longest chain of dependent tasks in the schedule. It sets the shortest possible project length.

• Tasks on it have zero float. A delay in any of them delays the end date.
• Tasks off it have float (slack) and can slip a little.
• Use CPM. Build a network diagram. Do a forward pass for early start and finish, then a backward pass for late dates. Float = late start minus early start.

To make a project shorter, you must shorten the critical path. You can crash it (add resources, which costs more). You can also fast-track it (do tasks in parallel, which adds risk). Watch for a second path becoming critical.

What they are checking: Do you understand schedule logic, not just the colors on a Gantt chart?

Every change goes through integrated change control. This way we understand the effect before work starts.

I list everyone who is affected by the project or can affect it. Then I plan how to work with each group.

A status report gives stakeholders a quick and honest view of the project. I send it weekly to the team and sponsor, and monthly to executives.

The triple constraint is scope, time and cost, with quality in the center. Changing one changes the others.

• Shorter schedule: add cost (more people) or cut scope.
• More scope: more time or more cost.
• Smaller budget: cut scope, or accept a longer schedule or lower quality.

Scope creep is uncontrolled growth of scope after the baseline. Time, cost and resources do not change to match it.

A risk is a possible future event that could affect the goals. An issue is a problem that has already happened.

• Risk: "The vendor may deliver late." It has a probability, and you plan responses.
• Issue: "The vendor delivered late." It is certain, and you must fix it now.

• Project: a temporary effort with a defined start and end. It creates a unique product or result.
• Program: a group of related projects managed together. This gives benefits you cannot get by managing them one by one. An example is a platform migration with several workstreams.
• Portfolio: a collection of projects and programs chosen and managed to meet strategic goals. They do not need to be related.

Each role owns a different outcome. On small teams the roles overlap.

I build a dashboard so anyone can see project health without asking me.

I compare real progress with the baseline at regular times. I use measures that are not opinions.

I measure success against both delivery and business results.

A project manager owns delivery of the whole project: scope, schedule, budget, risk and stakeholders. A Scrum Master is a servant leader. They help the team follow Scrum, remove impediments (blockers) and improve.

The PMP (Project Management Professional) is the PMI certification that proves project management knowledge. The exam covers three domains: people, process and business environment. It includes predictive, agile and hybrid approaches.

A dependency is a link where one activity relies on another.

Types of logical link:

• Finish-to-start (FS): B starts after A finishes. This is the most common.
• Start-to-start (SS): B starts when A starts.
• Finish-to-finish (FF): B finishes when A finishes.
• Start-to-finish (SF): rare.

The kickoff gets everyone to agree on why the project exists and how it will run. I prepare ahead, then keep the meeting short and focused on decisions.

I look for risks early, repeat this often, and follow each risk until it is closed.

• Identify: team workshops, lessons from past projects, checklists, assumption checks, and interviews with vendors and stakeholders.
• Analyze: score probability and impact on a matrix. For big projects, use expected monetary value.
• Plan responses: avoid, reduce, transfer or accept. Give each one an owner and a trigger.
• Monitor: review the register in weekly meetings. Watch for new risks and side effects.
• Fund: use a contingency reserve for known risks and a management reserve for unknown ones.

Example: a key integration depends on a third-party API. To reduce the risk, I build a mock early and test it in sprint one. I also note a fallback in the register.

What they are checking: Is your risk process continuous, and does it lead to action?

Earned value compares planned work, finished work and actual spend. It shows schedule and cost performance in one method.

• Planned Value (PV): the budgeted cost of work scheduled so far.
• Earned Value (EV): the budgeted cost of work actually finished.
• Actual Cost (AC): what you really spent for that work.

Both make the schedule shorter without cutting scope, but they trade different things.

I build it from the WBS, then manage it against a baseline.

I match skills and availability to the work. I watch for overload early.

I set a regular rhythm and keep communication written, clear and overlapping.

The main approaches are waterfall (predictive), agile (adaptive: Scrum, Kanban, XP), and hybrid. PRINCE2 is a predictive framework based on processes.

I estimate the cost bottom-up, set a baseline, and control it with regular reviews.

Software work is intangible and requirements change. This changes how I manage it.

Most failures come from management and communication, not from technology.

A baseline is the approved version of the scope, schedule and cost plan. It is the reference for measuring performance.

• Scope baseline: scope statement, WBS and WBS dictionary.
• Schedule baseline: the approved schedule.
• Cost baseline: the budget by time period.

The project management plan is one document that describes how the project will be done, monitored and closed.

Quality is planned in first. Then it is checked and controlled.

In waterfall, scope is fixed, and time and cost change when estimates are wrong. In agile, time (sprints) and cost (team) are fixed, and scope is flexible.

Project governance is the set of roles, decision rights, rules and reports. It keeps a project in line with business goals and under control. It answers who decides what, how progress is checked and how problems are escalated.

I make the conflict visible and link it to the project goals. Then the right decision-maker chooses with full information.

I protect the date by talking about scope and priority early. I do not push the team into burnout.

First make things stable and tell people. Find the root cause after that.

Work through the formulas.

• SV = EV - PV = 150 - 200 = -50, and SPI = 150 / 200 = 0.75. The project is behind schedule.
• CV = EV - AC = 150 - 180 = -30, and CPI = 150 / 180 = 0.83. The project is over budget.

I start with a private talk to understand the cause. Then I set clear expectations and give support.

Find out why before reacting. Then present options.

Escalate early with facts and agree on a recovery plan. Protect the project at the same time.

Get an honest picture first. Then re-plan and reset expectations.