Performance Review Examples for Project Managers

Most PM review example posts I’ve seen online have the same shape: a list of phrases (“ consistently delivers on time and within budget”, “strong communicator”, “builds excellent stakeholder relationships ”) with no project context, no actual numbers, and no PM craft underneath. They read as if written by someone who’s never run a steering meeting. The examples below try to do the opposite.

For the framework these examples are built on, see how to write a performance review for a project manager. The four pillars referenced are delivery, risk and foresight, stakeholder craft, process and improvement.

Example 1: senior PM leading a complex multi-team initiative

Maya led an 11-month platform-migration program spanning engineering, data, security, and customer-support, with a $1.4M budget and a steering committee that included two C-level sponsors. The migration landed in scope, 6% under budget, two weeks behind original schedule with a re-baselined plan accepted by the steering committee in month 4.

Maya ran a notably strong program this year and the through-line was risk-and-foresight craft operating at the senior tier. On delivery, the platform migration landed in scope, 6% under budget, and against a re-baselined schedule delivered two weeks behind that re-baseline. The re-baselining conversation in month 4 was itself the strongest single piece of work in the program: she surfaced the engineering-capacity constraint six weeks before it would have forced an emergency reschedule, framed the trade-offs cleanly to the steering committee, and landed an accepted re-baselined plan with no loss of executive confidence.

On risk and foresight, the RAID-log discipline across the program was the cleanest I’ve reviewed in the year. The log was actually used: eleven risks were raised in advance with concrete mitigation, six of those materialised in some form across the program and the mitigations worked, and the three risks that didn’t materialise reflected genuinely uncertain situations rather than padding. The change- control process she ran on three substantive scope-change requests in months 5 through 8 kept the program from absorbing scope silently, which is the failure mode most large programs have.

On stakeholder craft, the steering-committee management was strong and the sponsor partnership with the CTO in particular reflected high trust. The Q3 working group conflict between security and data over the migration sequencing was the political moment of the program; she framed the conversation in a way that landed a workable sequence without burning either relationship. Executive briefings were consistently well- prepared and the steering committee never had a surprise.

On process and improvement, the post-program retrospective she ran produced four substantive practice changes that have been adopted across the PMO. The change-control template she built for the program is now the PMO default. She mentored two earlier-career PMs through specific program phases across the year and both reported the partnership as the development moment of their year.

Why this works: delivery is acknowledged with context (the re-baseline matters, the two-week slip against re-baseline isn’t hidden). The craft work underneath the delivery is named specifically (eleven risks raised, six materialised, mitigations worked). Stakeholder moments are named with the specific political situations. Process contribution is concrete (template adopted across PMO, two mentees).

Example 2: mid-level PM whose project hit a major external setback

Tom led a 7-month CRM-implementation project that was forced to re-platform in month 4 when the original vendor was acquired and announced end-of-life on the chosen product. The project ultimately delivered eight weeks late and 14% over budget, with the steering committee accepting both variances given the cause.

Tom’s year was substantially shaped by an external event he didn’t cause and the assessment reads the project against the craft he showed inside the situation rather than the headline variance numbers. The CRM project hit the vendor end-of-life announcement in month 4 and had to re-platform under time pressure. The eight-week schedule slip and 14% budget overrun both trace to that event; the steering committee accepted both at the time and the variance analysis at close confirmed the attribution.

On risk and foresight, Tom had flagged vendor- stability as a top-three risk in the original RAID log and had run a vendor due-diligence pass in month 2. The acquisition announcement wasn’t on any reasonable risk register; he handled the materialisation of an unforeseen risk well. The replatforming plan he produced in week 17 was substantive: a comparison of three alternative vendors, a clear migration sequence, and a revised RAID log reflecting the new vendor relationships. The plan was accepted by the steering committee without substantive revision.

On stakeholder craft, the communications around the vendor change were the strongest single piece of work in the project. He briefed the CFO directly within 72 hours of the vendor announcement with a credible revised plan rather than waiting for a steering meeting two weeks later. The post-replatform working-group dynamics were managed cleanly; the team didn’t lose cohesion through the transition.

On delivery, the project ultimately landed in scope on the replatformed product with full user adoption. The variance pattern reflects the external cause; the in-project execution against the revised plan was clean.

On process and improvement, the post-project retrospective produced a vendor-risk-assessment template that the PMO has adopted as the default for vendor-dependent projects. The retro itself was facilitated with care; the team came out of it with a usable account of what happened rather than blame-shifting.

Why this works: the external context is named openly and reads as fair rather than excuse- making. The craft Tom showed inside a hard situation is named specifically (72-hour CFO briefing, vendor comparison, revised RAID log, retrospective that produced template work). The variance numbers are stated honestly without anchoring the whole review on them.

Example 3: PM at the end of their first year in the role

Aaliyah joined twelve months ago as her first PM role after three years as a business analyst. Background: ran two small coordination programs and contributed to a larger program under senior- PM supervision. No big standalone wins yet, strong development pattern.

Aaliyah completed a strong first year as a PM and the work she invested in building fundamentals is paying off. On delivery, the two coordination programs she owned end-to-end (the cross-team knowledge-base consolidation in Q2 and the vendor-evaluation program in Q3) both landed in scope and on schedule. The contribution she made to the larger CRM-replatforming program under senior PM supervision was substantive: she owned the change-management workstream and the end-user-training plan, and both shipped cleanly.

On risk and foresight, the development is visible. Her first RAID log on the knowledge-base consolidation was thin and reactive. By the vendor-evaluation program in Q3 the RAID was substantive with eight risks tracked across the program lifecycle, three escalated at the right time. The shift from analyst-pattern thinking (issues are things to investigate) to PM-pattern thinking (risks are things to surface and mitigate before they become issues) is the development that matters most at this stage and is visibly underway.

On stakeholder craft, the relationships she built with the customer-support leadership team across the knowledge-base program were the standout. The team brought her into the next-year operations-planning conversation specifically because of how she ran the program. Generalising that relationship pattern across other functions is the next-year move.

On process and improvement, this year was appropriately learning-focused. The retrospective notes from the two programs are the first piece of process artefact she contributed; the next- year expectation is one template or practice contribution beyond her own projects.

Why this works: first-year context is named. Each pillar is calibrated to expectations at this stage (no big standalone program ownership expected; development pattern visible; relationship build credited specifically). The next-year edge is framed concretely.

Example 4: PM with clean delivery and weak stakeholder craft

Brian is a mid-level PM whose projects ship cleanly but who struggles with steering-committee management and cross-functional partnership. Background: two projects shipped on time and on budget but with steering-committee friction and team-lead feedback flagging the relationship dynamics.

Brian’s year had clearly distinct strengths and a clear development edge that the review names directly. On delivery, both projects landed in scope and on schedule, with the larger of the two delivering 3% under budget. Delivery discipline is a genuine strength: scope management was tight, schedule baselines held, and budget variance reporting was accurate throughout.

On risk and foresight, the RAID-log discipline was reliable. Risks were raised with appropriate timing and the change-control process ran cleanly on the four scope-change requests across the year. The craft on the technical side of project management is solid.

On stakeholder craft, the picture is more mixed and is the development priority for next year. Two distinct patterns surface. First, steering- committee meetings he chaired tended to run long with the working-group team and short on executive sponsor signal, which produced repeated executive frustration that the sponsor-feedback round captured. Second, the cross-functional working-group dynamics on the larger project had ongoing friction; two team leads reported that conflict resolution was often deferred rather than handled, which compounded the difficulty of the second half of the project. Both patterns are coachable and we’ve discussed the framing across the year.

On process and improvement, contributions to the PMO this year were limited to the two retros for his own projects, which is the floor expectation at this band rather than the ceiling.

Why this works: the strengths are named first and credited fully. The development edge is named with specific pattern-level observations and evidence sources (sponsor-feedback round, team- lead feedback). The review gives Brian a clear next-year priority without softening the gap.

Example 5: PM with strong stakeholder craft and weak retrospective rigor

Hannah is a mid-level PM whose stakeholder relationships are exceptional but whose retrospectives produce little practice change. Background: projects with strong sponsor satisfaction but recurring delivery issues that retros didn’t surface usefully.

Hannah has unusually strong stakeholder craft and the development edge sits at the process-and- improvement pillar. On stakeholder craft, the executive-sponsor satisfaction signal across her projects this year was the strongest in the team. The Q2 working-group conflict on the systems- integration project resolved without lasting damage to either of the two leadership relationships involved, which was the political moment of her year. Sponsor briefings were consistently well-prepared and surprises in steering meetings were rare.

On delivery, both projects shipped in scope but with schedule slips (a four-week slip on the systems-integration project and a two-week slip on the reporting consolidation). The slips were handled professionally with steering committees but the recurrence of the schedule pattern is the development thread that retrospectives should have surfaced and didn’t.

On risk and foresight, the RAID-log discipline was inconsistent. The systems-integration RAID was thorough; the reporting-consolidation RAID was thin. The pattern that the four-week schedule slip on systems-integration was foreseeable from the resource-allocation risks she’d identified suggests the foresight was there but the escalation calibration wasn’t.

On process and improvement, the retrospectives ran but they produced little practice change. The recurring schedule-management pattern across her projects this year would have been identifiable from a careful cross-project retro, and that retro didn’t happen. The development priority for next year is treating retros as the highest-leverage activity in the PM cycle, not the closing ceremony.

Why this works: the strength (stakeholder craft) is fully credited with the specific moments that evidence it. The development edge is framed sharply: the pattern across projects suggests the foresight is there, the gap is in the retro-to- practice-change loop. The review gives Hannah a specific frame for next year rather than vague “run better retros” language.

Notes that apply across all five examples

Delivery is the floor across all five; the differentiating evidence lives in risk and foresight, stakeholder craft, and process and improvement. Context matters (Example 2 in particular); variance numbers without context produce false readings.

For the manager-side framework, see how to write a performance review for a project manager. For the PM-side counterpart, see project manager self-evaluation examples. For tactical tips on both sides, see performance review tips for project managers.