How to Write a Performance Review for a Project Manager

Project manager reviews are easier to get wrong than they look. The headline question (did the project land on time, on budget, in scope) is the most visible signal but also the one most heavily shaped by context the PM didn’t fully control: the engineering capacity that was over- committed before the PM arrived, the vendor that changed scope mid-project, the executive sponsor who shifted priorities in Q3. A review that anchors on the delivered-or-not state without reading the context will routinely over-credit lucky PMs and under-credit strong ones running harder projects.

The fix is a framework that looks at the PM’s craft underneath the outcome: how they surfaced risk, managed stakeholders, calibrated escalation, and ran the kind of post-project learning that makes the next project go better. That’s the ceiling. Delivery is the floor.

This guide gives you a four-pillar framework designed for project-manager work, the 90-minute drafting flow that produces a usable first pass, and the traps that make PM reviews particularly easy to get wrong.

What makes project manager reviews hard

Four distinguishing features.

Project outcomes are heavily shaped by context the PM doesn’t control. Vendor behaviour, executive-sponsor stability, engineering capacity, market shifts, scope changes forced from outside the project. A strong PM running a hard project can have a worse headline outcome than a weaker PM running an easier one. The review needs to read context, not just outcome.

The strongest PM work is preventive and invisible.The risk that didn’t materialise because the PM flagged it eight weeks ahead. The scope creep that didn’t happen because the PM ran change-control discipline. The stakeholder conflict that resolved at the working- group level because the PM framed the conversation right. None of it leaves a trail in the Gantt chart. The reviewer needs a method for surfacing it.

PMs are often evaluated by people who weren’t in the project.Functional managers reviewing PMs assigned to projects they didn’t sponsor often have only the status- report layer of visibility. That layer is deliberately polished. Strong reviews require going below it through conversations with the actual sponsors and team leads.

Status-report quality is itself a signal that’s easy to misread. Clean status reports can mean the project is healthy or can mean the PM is over-smoothing. Messy status reports can mean the project is in trouble or can mean the PM is being honest about a hard situation. The status reports are evidence, but triangulated against the actual outcomes and stakeholder feedback.

The four pillars of a project manager review

1. Delivery

The execution work. Scope, timeline, budget, quality. Did the project ship what was scoped, in the timeline that was agreed, within the budget approved, and at the quality bar required. Strong PMs hold the line on all four; weak PMs let one or two slip silently.

What to capture: variance against original scope, schedule, and budget baselines, with the context for any variances. A 12% schedule slip with a documented external cause and a re-baselining conversation handled professionally is different from a 12% slip that surprised the steering committee.

2. Risk and foresight

The work below the surface. RAID-log discipline, escalation calibration, surfacing risks early, flagging dependencies, change-control rigor. Strong PMs run a clean RAID log that’s actually used; weak PMs run a RAID log that lives in a tab nobody opens.

Evidence: the risks the PM raised in advance that either materialised (and were already mitigated) or didn’t materialise (because the mitigation worked). The escalation calls that landed at the right time, not too late or too early. The change requests that got run through change-control rather than absorbed silently. The RAID-log artefacts themselves, read for whether they tracked the actual risks of the project.

3. Stakeholder craft

The communication and relationship work. Steering- committee management, sponsor partnership, working- group facilitation, executive briefings, conflict resolution within and across teams. Strong PMs make their stakeholders feel informed without overloading them, and they handle the political moments without burning bridges. Weak PMs either over-communicate (everyone tunes out) or under- communicate (surprises in the steering meeting).

Evidence: steering-committee minutes, sponsor feedback, the stakeholder-conflict moments where the PM’s framing changed the outcome, the executive briefings that landed.

4. Process and improvement

The capability work. Retrospectives that produce actual change, methodology improvements, templates and artefacts the PM contributed beyond their own project, mentoring of other PMs or coordinators, contributions to PMO practice. Strong PMs make the next project go better. Weak PMs run each project as a one-off.

Evidence: retro outputs that became practice changes, template work the PM contributed, cross-project lessons documented and shared, mentorship of earlier-career PMs.

The 90-minute drafting flow

Block 90 minutes per PM you’re reviewing. Split into two sittings.

Sitting one: evidence collection. Pull the projects the PM led across the year with variance against scope, schedule, and budget baselines. Read the RAID logs for the two largest projects. Read three or four status reports sampled across the year. Pull steering-committee minutes for the two largest projects. Have brief conversations with two project sponsors and one team lead. Forty-five minutes total.

Sitting two: drafting. One paragraph per pillar. Delivery first (the floor), then risk and foresight (the differentiating craft), then stakeholder craft (the relationship signal), then process and improvement (the contribution beyond the project). End with two or three specific development priorities. Forty- five minutes.

Traps that make PM reviews particularly easy to get wrong

The shipped-on-time-as-everything trap. The project landed in scope, on time, on budget. Good. None of that differentiates a strong PM from a lucky one. The differentiating evidence is in how the PM ran the work: the risks they surfaced, the change requests they ran through change-control, the stakeholders they managed, the retros they ran. A PM whose project landed cleanly because the surrounding teams happened to execute well is a different practitioner from one whose project landed cleanly because their risk discipline prevented three potential delays.

The status-report-as-truth trap. Status reports are the polished surface. Strong reviews go below that surface through conversations with sponsors and team leads. The gap between status-report claims and actual team experience is often the most informative thing in the review.

The methodology-as-craft trap. PMP, Agile, Waterfall, hybrid, SAFe. Methodology familiarity is table-stakes. It doesn’t in itself evidence senior PM craft. Strong PMs adapt methodology to the project context; weak PMs run the methodology even when the project context argues for something different.

The clean-Gantt-as-control trap. A pristine Gantt chart can be evidence of strong planning craft or evidence of over-smoothing. The chart needs to be read against actual project reality, not in isolation. Charts that map to actual delivery patterns are useful artefacts; charts that look immaculate but bear no relationship to the project’s actual flow are theatre.

The escalation-volume-as-judgement trap.Some PMs escalate every decision; others escalate nothing. Both patterns are usually fixable but they’re different problems. The PM with strong escalation calibration (escalating the right things at the right time) is doing senior-level work and deserves credit for it.

The shape of a PM review that ages well

Read the review twelve months from now and ask whether you could picture the year of project work it described. The strong reviews pass. They have specific projects named, specific scope and timeline context, specific risk-management moments, specific stakeholder situations, specific retro-to-practice loops. The weak reviews could be about any PM at any company on any project, which means they’ll be treated that way at the next round of calibration.

For the worked examples that show this framework applied to five different PM scenarios, see performance review examples for project managers. For the self-evaluation counterpart, see project manager self-evaluation examples. For tactical tips, see performance review tips for project managers.