PIP examples for project managers
This page shows illustrative examples of what performance improvement plan goals often look like for project managers in U.S. workplaces — measurable versions next to vague versions, with what to check and how to respond.
If you're a project manager on a performance improvement plan, the plan you were handed probably reads like it was pulled from a template — because it usually was. What matters is not the shape of the document but how measurable each goal is, and whether the timeline is fair for the work you actually do.
Project management PIPs often follow a slipped launch, a stakeholder escalation, or a re-org that changed reporting lines mid-project.
Three example goals — measurable versus vague
The three pairs below are examples, not statistics. Each shows a measurable version of a goal that a project manager might reasonably be asked to meet, alongside a vague version of the same intent — the kind that leaves both sides arguing at the end.
Deliver the [project name] milestones on the agreed timeline: [milestone A] by [date], [milestone B] by [date], with a status update every Monday by 10 AM.
Deliver projects on time.
Which projects, whose timeline, and what counts as "on time" — none of these are defined, so any slip on any project can be cited.
Reduce open critical risks on your active projects to fewer than two by end of month one, with mitigation owners named in the risk register.
Manage risk better.
"Better" has no threshold. Without a register and named owners, risk becomes something you're personally graded on but can't unilaterally resolve.
Run every project meeting with an agenda sent 24 hours in advance and notes with owners and due dates published within one business day.
Improve stakeholder communication.
Meetings, agendas, and follow-ups are the visible surface of PM work. Without a rhythm, "communication" is judged on impressions.
What to check in a project manager's PIP
- Whether the plan holds you accountable for outcomes that require another team's delivery to complete.
- Whether the project scope named in the plan is the scope you were actually staffed for.
- Whether escalation paths for blocked dependencies are documented — or you're expected to unblock them yourself.
How a project manager should respond
Project management is a coordination role: much of your output is other people's output. When you accept a plan, name the cross-functional dependencies for each goal in writing. If a dependency later slips, the record shows why.
Weekly status reports become your evidence log. Send them on the same day each week, with the same structure — that consistency itself is defensible.
The general playbook is the same across roles: ask for the vague goals to be rewritten as measurable ones in writing, name the dependencies you don't control, and keep a dated log of what you did each week. If the plan is a way of documenting an exit that's already been decided, that log is what gives you leverage in the severance conversation.
Turn this into a response
When you're ready, three tools do most of the mechanical work: the PIP Decoder flags vague or unmeasurable goals in your plan text, the PIP response letter builder drafts a written reply, and the severance calculator puts a number on the exit if it comes to that. If you want the wider picture, the PIP survival playbook covers the full 30-day arc.
Built for U.S. employment norms. Rules vary by state and country.
Related
FAQ
Glidepath provides general information and document tools, not legal, financial, or tax advice. Employment rules vary by state and country. For advice about your situation, consult a licensed professional.