The PMBOK Situations Playbook: What to Do, What to Change, What to Write Down

The parent article walked through PMBOK as a vocabulary of inputs and output artifacts. This one is the companion playbook: the situations a project manager actually walks into, what to do in each, and — most importantly — which documents must change, who changes them, and by when.

The documents are not the point. The point is that every real situation fans out into changes in several other parts of the project: a budget cut touches risk, scope, schedule, communications, and procurement all at once. If you only update the thing that moved, the other seven silos drift, and drift compounds into crisis on week nine.

Each situation below follows the same shape. Read the ones that apply; keep the matrix at the end on a shelf.

TL;DR

• 16 situations every PM faces — each with a 4-step response, the documents to update, and best/worst case outcomes.
• The Integrated Change Control loop from the parent article is what binds them: every material change passes through the Change Log and ripples to affected baselines.
• The documents that get touched most across all situations: Risk Register, Issue Log, Change Log, Project Management Plan, and Lessons Learned Register.
• Step 1 in almost every situation is the same: capture the situation in the Issue Log before you do anything else. You will forget details within 48 hours.
• When in doubt: protect the baseline, document the deviation, communicate asymmetrically (more, not less).

How to Read Each Situation

Each section gives:

Throughout the post, one rule applies everywhere: if you change any baseline (scope, schedule, cost), you owe an Approved Change Request, an updated plan, and a communication to stakeholders. No exceptions. That is the Integrated Change Control loop.

Scope-Side Situations

1. Scope Creep — “Could We Also Just Add…”

What’s happening: A stakeholder requests additional work under the guise of “just a small addition”, often directly to an engineer, bypassing your change control.

Signals

• Engineers mention work they are doing that isn’t in the sprint backlog.
• A stakeholder says “I asked them on Friday to just add…”
• Velocity drops with no obvious cause.

Steps

1. Stop the work, kindly but immediately. Ask the engineer to pause. Explain you’ll process the request through change control and get back to them by end of day. This is not about hierarchy — it’s about protecting the baseline.
2. Capture the request as a Change Request. One sentence is fine: who asked, what they asked for, on which date. Log it in the Change Log even before you’ve assessed it.
3. Assess impact across all five baselines within 24 hours. Does it change scope? Schedule? Cost? Risk? Quality? Most small-asks fail this assessment because they quietly steal a week.
4. Take the decision back to the requester with numbers. “This adds 14 hours, moves beta by 3 days, and costs $1,200 in contractor time. Do you want me to take it to the Change Control Board?” Half the time the answer is “actually no, not that urgent”.

Documents affected

Best case · Stakeholder learns your change-control loop is easy, not bureaucratic, and starts routing requests through it. Scope control tightens over the next month.

Worst case · You silently absorb the scope, your team burns out by week 10, and on day 90 you are still shipping features no one remembers asking for while missing the original scope.

2. Requirements Turn Out Wrong — “Users Hate the Design”

What’s happening: A deliverable built against the approved requirements is unusable, unwanted, or solves the wrong problem. Often surfaces at UAT or first user test.

Signals

• UAT feedback is vague but negative (“doesn’t feel right”).
• Beta users stop using the feature within 48 hours.
• A senior stakeholder pushes back on what they previously signed off.

Steps

1. Separate three distinct questions. Is it (a) a requirements error — we built the wrong thing; (b) an implementation bug — we built the right thing badly; or (c) a change in understanding — the world moved? They require different responses.
2. If (a): pause downstream work on this feature. Don’t add more UI on top of a flawed feature. Don’t hide it; don’t try to salvage it via polish.
3. Re-run the requirements loop on just this slice. Brief re-interview of users or the product owner. Produce a revised requirements doc and — this matters — write down what was wrong with the original. Otherwise the lesson evaporates.
4. Make the rework decision explicit. Options: throw away, rewrite, or feature-flag and iterate. Document the decision in the Change Log with the expected cost.

Documents affected

Best case · You catch this at internal UAT, rework costs one sprint, and your requirements process improves for every subsequent feature.

Worst case · You catch it at production, you’ve built three features on top of the rejected one, and now the rework is a quarter.

3. Executive Mandate / Strategic Pivot

What’s happening: Leadership decides the company is going a different direction, and your project is now either less important, differently important, or dead.

Signals

• Your sponsor goes quiet.
• A new “strategic priority” appears on the all-hands slides.
• Your budget review gets postponed twice.

Steps

1. Get the mandate in writing. Email, Slack, meeting notes — but written, attributable, dated. Verbal pivots are how projects get half-killed.
2. Translate the mandate into scope/schedule/cost deltas on a single slide. What exactly changes? Everything in-flight that still applies; everything that doesn’t; estimated cost of the pivot (including the sunk cost being written off).
3. Re-baseline or close. Either the project has a new charter and you run integrated change control, or it closes and you run the Close Project process — including Lessons Learned.
4. Protect your team next. If the project is shrinking or dying, people need clarity on their roles fast. Silence kills morale faster than bad news.

Documents affected

Best case · A clean re-baseline in 2 weeks, no headcount change, and the new direction is a better use of the team’s skills.

Worst case · Six months of half-committed execution before anyone admits the pivot is real, and the team you trained leaves before the new scope is defined.

Schedule-Side Situations

4. The Timeline Is Slipping

What’s happening: Cumulative slippage on multiple work packages indicates the baseline won’t hold. Usually noticed via SPI trending below 0.9 or milestone dates drifting.

Signals

• SPI (Schedule Performance Index) < 0.9 for two consecutive reporting periods.
• Milestone dates move out by more than the reporting cadence.
• Critical-path activities consistently miss their expected finish.

Steps

1. Root-cause, not symptom-cure. Slipping because of bad estimates? Unexpected dependencies? Team capacity? Scope creep? Each root cause has a different fix. Don’t just add people.
2. Re-forecast, don’t lie. Build an honest Schedule Forecast showing the new completion date at current velocity. Share it before it is demanded.
3. Propose trade-offs, not heroics. Pick from: reduce scope, extend schedule, increase cost, reduce quality. There is no fifth option. Present the menu, not a recommendation, to the sponsor.
4. Formally re-baseline once a decision is made. “Working harder” is not a re-baseline. Until the baseline changes, you are still behind it.

Documents affected

Best case · Early honesty + trade-off menu → sponsor picks a sensible re-baseline; project ships 3 weeks late but green.

Worst case · Multiple partial re-baselines, communication fatigue, and a sudden “the project is 4 months late” discovered at week 16.

5. External Deadline Moves In (Not Out)

What’s happening: A contractual, regulatory, or business deadline gets pulled earlier than the current schedule supports.

Signals

• Contract amendment, regulatory notice, or exec decision moving a hard date.
• “We need this for the Q3 earnings call, not Q4.”

Steps

1. Map the gap precisely. Current target vs new target, in days. What’s on the critical path between them.
2. Offer three options for hitting the date. Usually: (a) reduce scope to MVP; (b) add resources; (c) accept a lower quality bar on specific surfaces. Costs and risks each.
3. If none of the three are acceptable to the sponsor, escalate. Sometimes the “new deadline” is aspirational and can be pushed back to “firm-but-later”.
4. Once agreed, re-baseline within 72 hours. Living out of a half-dead schedule demoralises the team and hides reality.

Documents affected

Best case · Sponsor accepts MVP scope; team ships the earlier date with a clear backlog of v2 features.

Worst case · Team tries to hit the earlier date with full scope and full quality, ships late anyway, burned out, with compounded tech debt.

6. Critical-Path Blocker Appears

What’s happening: A task on the critical path is blocked — waiting on a person, a decision, a vendor, an environment, an approval — and every day of delay adds a day to the project end.

Signals

• A standup blocker that persists more than 2 days.
• The work item’s duration estimate is exceeded without progress.
• You hear “I’ve been waiting for…” more than once in a week.

Steps

1. Name it publicly within 24 hours. Explicitly call out that X is blocked, by Y, and the end-date impact is Z days per day of delay. Silence here is how critical-path blockers become month-long delays.
2. Resolve the blocker at the lowest level that can act. Don’t escalate on day one. Escalate on day three if nothing moves.
3. While blocked, reshuffle non-critical work to keep the team productive. A blocked critical path does not mean a blocked team.
4. After resolution, log the root cause. Was this a dependency you should have spotted at planning? Was it an access/approval process that’s too slow? Fix the system, not just the symptom.

Documents affected

Best case · Blocker resolved in 48h, no schedule change required, and the underlying dependency pattern gets documented for future planning.

Worst case · Week-long blocker, critical path pushed, and two more similar blockers arrive the next sprint.

Cost-Side Situations

7. Budget Cut Mid-Project

What’s happening: Leadership removes a portion of the budget — often 10–25% — usually because of broader company-level cost pressure.

Signals

• Finance calendars a “budget review” out of cycle.
• Peer projects are being cut or paused.
• Your sponsor asks “if you had to lose 20%, what would go?”

Steps

1. Don’t propose cuts in the meeting. Ask for 48 hours to return with a proposal. Rushed cuts almost always destroy the wrong thing.
2. Categorise remaining work into must-have / nice-to-have / stretch. Use acceptance criteria, not engineering opinion, to classify.
3. Return with two or three cut scenarios, each with its own scope + schedule + risk profile. “Here’s a 10% cut that costs us 3 features. Here’s a 20% cut that delays launch by 6 weeks. Here’s a 25% cut that ships the MVP and defers the rest.”
4. Once decided, re-baseline cost, scope, and schedule simultaneously. A cost cut without a scope cut is a timeline slip in disguise.

Documents affected

Best case · The cut forces focus; the project ships the highest-value 80% without the hardest 20% — and customers don’t notice.

Worst case · Cuts are made without scope reduction, the team takes the hit, quality collapses, and the “saved” money is spent on remediation by month 10.

8. Cost Overrun Discovered

What’s happening: Actuals are materially above the Cost Baseline. CPI (Cost Performance Index) drops below 0.9. Often discovered two to four weeks after the overrun began.

Signals

• CPI < 0.9 for two consecutive periods.
• Vendor invoices arrive larger than estimated.
• “We’ll just absorb it in contingency” said more than twice.

Steps

1. Calculate EAC (Estimate at Completion) with current performance. Not the optimistic one. Use EAC = BAC / CPI as the starting point. This is the number your sponsor needs.
2. Classify the overrun. Is it a one-off (e.g. a vendor reclassification), systemic (bad estimates, scope creep), or environmental (currency, rates)? Each requires a different response.
3. Bring the ask explicitly. “I need an extra $X to complete. Here’s why. Here’s what we’ve done to reduce future exposure.” Hiding an overrun makes it worse; bringing it with a plan builds trust.
4. Reset contingency or reserve usage rules. If contingency is being consumed faster than expected, decide if the project’s risk profile has changed. That changes the risk register too.

Documents affected

Best case · Overrun caught at ~10% variance, root cause addressed, sponsor approves a modest reserve draw, project finishes within revised envelope.

Worst case · Overrun discovered at 40%+ at handover, funding not available, project ships partially done with a legacy of unfinished commitments.

Resource-Side Situations

9. Key Person Leaves

What’s happening: A critical team member resigns, is pulled to another project, or goes on unexpected extended leave. The knowledge, not the headcount, is the actual loss.

Signals

• “Can we have a chat?” on a Friday afternoon.
• A member of the team becomes noticeably quieter.
• Recruiter calls to random team members increase.

Steps

1. Do knowledge transfer before the last day. A departing engineer who is still paid is worth 3 newly-onboarded ones. Schedule explicit sessions on areas they own: code, decisions, external contacts, gotchas.
2. Document the work in flight in a single handover doc. Not Slack scrolling. A document with status, next step, risks, and stakeholders — per in-flight item.
3. Decide backfill vs reshuffle. A like-for-like backfill is often slower than reshuffling the remaining team. Consider both.
4. Update risk register with the residual knowledge risk. Even after good handover, there will be gaps discovered in month +2. Plan for them.

Documents affected

Best case · 2-week handover, well-documented, team absorbs 80% of the work; morale steady because the exit is handled with grace.

Worst case · No handover, the person owned three critical areas, team morale dips, delivery slips 6+ weeks, and two more people leave behind them.

10. Team Conflict / Productivity Tanks

What’s happening: Team output drops, standups get terse or tense, visible disagreements or passive-aggressive exchanges appear. Often tied to a specific conflict, sometimes to ambient burnout.

Signals

• PRs pile up; review times triple.
• Standup becomes 10 minutes of talking past each other.
• Two people stop talking to each other directly.

Steps

1. Listen, separately, before acting. 1-on-1 with each person involved. Don’t take sides. Understand the root conflict — often it is ambiguity in ownership, not personal.
2. Name the problem publicly, with your own interpretation. A team-wide meeting to say “Here’s what I’m seeing. Here’s why I think it’s happening. Here’s how I want to fix it.” Clears ambient tension fast.
3. Fix the structural cause. Ambiguous ownership? Rewrite the RACI. Unclear technical authority? Appoint a lead. Burn-out? Reduce WIP. The conflict is usually the symptom of something concrete.
4. Revisit the team charter. It was written with the team six months ago and probably no longer matches the team now. Refresh the ground rules together.

Documents affected

Best case · A one-week recovery, clearer ownership, productivity rebounds, team more cohesive afterwards.

Worst case · Latent conflict drags for a quarter, a high performer leaves, team velocity halves permanently.

Risk & Quality Situations

11. Identified Risk Materialises Into an Issue

What’s happening: Something you tracked as a Risk actually happens. It’s no longer uncertain; it’s now an Issue you must manage.

Signals

• The trigger you defined for the risk fires.
• “Remember that thing we talked about in March…”

Steps

1. Move the entry from Risk Register to Issue Log. Don’t delete it — keep the original risk entry and link it. The history is evidence that planning worked.
2. Execute the planned response. This is what the risk response strategy was for. If you planned a mitigation, run it. If you planned acceptance, accept.
3. Reassess related risks. A materialised risk often correlates with others. Update probability/impact on neighbours.
4. Communicate that the planned response is being executed. The fact that you predicted this reduces surprise and preserves stakeholder trust.

Documents affected

Best case · Response works, impact is contained within the contingency reserve, and the risk process is validated.

Worst case · The planned response is inadequate, impact is larger than estimated, and other related risks also materialise.

12. Quality Gate Fails (UAT, Pen Test, Audit)

What’s happening: A deliverable fails a planned quality check — UAT, penetration test, audit, accessibility review — and cannot be released as-is.

Signals

• Formal finding from a tester or auditor.
• UAT sign-off refused.
• Pen-test report with critical / high findings.

Steps

1. Don’t negotiate the findings; remediate them. “Push-back” on legitimate findings is a red flag to auditors and undermines trust. If a finding is truly wrong, document why in writing.
2. Categorise findings by severity and effort. A matrix of (critical / high / medium / low) × (small / medium / large fix) guides sequencing.
3. Build a remediation plan, not a patch list. Some findings indicate a systemic problem (e.g. missing threat model, poor input validation). Fix the system, not the individual bug.
4. Re-test by the same body. If a third-party body found the issue, a third-party body closes it. Self-certification does not replace an audit re-test.

Documents affected

Best case · Findings remediated in one sprint; re-test passes; team and process emerge stronger.

Worst case · Remediation exceeds original build effort; audit re-test fails again; project shipping date slips by months and reputation takes a hit.

13. Critical Vendor Underperforms or Fails

What’s happening: A contracted vendor delivers late, under-quality, or not at all. Usually becomes obvious 2–3 check-ins after warning signs start.

Signals

• Vendor updates become vague or scarce.
• Their team turnover is visible in the call.
• Deliverables slip by ≥ 2× the original estimate.

Steps

1. Invoke contractual reporting rights immediately. Ask for written status, risks, and a credible recovery plan within 48 hours. This is both corrective and evidentiary.
2. Stand up a recovery plan in parallel. Do not bet the project on the vendor’s recovery. Plan what you do if they fail entirely: in-house, replacement vendor, reduced scope.
3. Escalate within the vendor organisation if the account manager is not delivering. Contract terms usually name an executive sponsor. Use them.
4. Make the go / no-go call at a pre-committed date. Don’t let a failing vendor drift. Name the date beyond which you will invoke termination clauses or switch.

Documents affected

Best case · Vendor recovers within 2 weeks, contract amended to tighten reporting, no meaningful schedule impact.

Worst case · Vendor collapse with 80% of their scope undelivered, emergency replacement, 2-month delay, contractual dispute spanning the rest of the year.

Stakeholder Situations

14. Sponsor Gets Replaced

What’s happening: Your project sponsor leaves the company or the role. A new sponsor inherits your project — often with their own priorities.

Signals

• Org announcement, usually on a Friday.
• Your standing 1-on-1 with the sponsor disappears from the calendar.
• A new name starts appearing in steering-committee invites.

Steps

1. Get on their calendar within a week. Not to lobby — to brief. New sponsors are most shapeable in the first 30 days.
2. Prepare a one-page brief. What the project is, why it exists, current state, top risks, top decisions needed, budget envelope. You owe them this.
3. Re-validate the charter explicitly. Ask: “Do you want me to continue with this charter, or do you want to amend it?” Make the choice conscious.
4. Update stakeholder register and engagement plan on the same day as the meeting. The new sponsor’s influence radius is different; plan to it.

Documents affected

Best case · New sponsor confirms the direction, brings fresh executive support, and the project gets an unexpected boost.

Worst case · New sponsor has a different agenda, project becomes unsupported, and you spend two months relitigating decisions the old sponsor already signed off on.

15. Major Customer Escalation

What’s happening: A customer (internal or external) raises a formal complaint or escalation — quality, delivery, commercial — that reaches executive level.

Signals

• Executive forwards a customer email to you directly.
• Support team opens a P1 ticket with “escalated from” field populated.
• Legal requests a summary.

Steps

1. Acknowledge within 4 hours, fix within the SLA, and communicate continuously. Silence during escalations is interpreted as not caring, even when you’re working.
2. Root-cause within 72 hours in writing. What happened, why, and what is being done. This is the document leadership wants.
3. Offer remediation to the customer that is disproportionate to their complaint. A credit, early access, a direct channel. The cost of this is always less than the cost of losing the account.
4. Fix the upstream cause, not just the customer incident. If the escalation revealed a product-wide gap, fix it everywhere — not just for the loudest customer.

Documents affected

Best case · Customer ends up more loyal than before; escalation becomes a case study in “how we respond”.

Worst case · Customer leaves; escalation hits press or procurement filters; other accounts demand the same treatment retroactively.

External Situations

16. Regulatory / Compliance Change Lands Mid-Project

What’s happening: A new regulation, standard, or audit requirement becomes applicable during the project — GDPR update, PDPA, SOC 2 control change, accessibility law, industry-specific rule.

Signals

• Legal or compliance sends an advisory.
• Industry trade body publishes a notice.
• A peer project posts about “new requirement X”.

Steps

1. Get the requirement in writing, from the authoritative source. Not from Twitter, not from a summary — the actual regulation, standard, or contractual clause.
2. Map the impact onto your current artifacts. Which requirements are you now non-compliant against? Which design decisions need to change? Which processes (e.g. data retention) need new evidence?
3. Decide: in-scope now, phased, or deferred with documented risk. Not every regulation is “immediate”. Some have grace periods. Document the decision with legal sign-off.
4. Build a compliance trail, not just the code. Audits care about evidence: policies, training records, approvals. Start the evidence log before the code change.

Documents affected

Best case · Compliance work integrated early, audit passes first time, regulation becomes a competitive advantage.

Worst case · Compliance work is bolted on at the end, audit fails, project ships to a forced launch date still non-compliant, and fines + remediation dwarf the original budget.

17. Parallel Project Conflicts With Yours

What’s happening: Another project in the company depends on something you own, blocks something you need, or ends up building the same thing in parallel. Usually surfaces 1–2 months into both projects.

Signals

• Two teams talking about “our” plan for the same thing.
• Shared infrastructure under contention.
• A colleague mentions “by the way, we’re also…”

Steps

1. Surface it within a week of discovery. Email the other PM and both sponsors. Don’t try to resolve it two-way without visibility.
2. Propose a concrete de-confliction. Most common options: one project owns the shared piece; the projects merge; one defers. Skip “we’ll coordinate informally” — that never works.
3. Re-negotiate dependencies in writing. Interfaces, data contracts, release windows. The disagreements usually live in the implicit assumptions.
4. Monitor the integration points forever. Even a well-coordinated parallel-project pair drifts. Standing check-in every 2 weeks, not ad-hoc.

Documents affected

Best case · Ownership clarified, integration contract signed, both projects deliver on time with no duplicated work.

Worst case · Neither PM budges, a month of parallel duplicate work is thrown away, and trust between the two teams is strained for a year.

Closure Situation

18. Handover Breaks Down

What’s happening: The project is “done” but the operational team won’t accept the handover. Runbooks are incomplete, training wasn’t done, on-call rotation not populated, or the team doesn’t feel ready.

Signals

• Operations team asks “what does this alert mean?” on launch day.
• Support doesn’t have access to the admin console.
• The Tech Lead becomes the de facto on-call for a month after closure.

Steps

1. Don’t declare the project closed. A project that produces artifacts no one can operate is not closed — it’s “handed over the wall”. The closure process is incomplete.
2. Build a handover checklist and walk through it jointly. Runbooks reviewed, access provisioned, rotation populated, monitoring thresholds known, escalation paths signed.
3. Run a real incident drill before closure. “Pretend the DB is down at 3am. Who does what?” If anyone doesn’t know, they aren’t ready.
4. Close formally only once operations signs the handover. The signature matters. It documents who owns what starting when.

Documents affected

Best case · Ops accepts cleanly, incidents in the first month handled without project-team involvement, team closes on a high note.

Worst case · Three months of “shadow support” from the project team, original delivery team unable to move on, and eventually a re-platform because the system is operationally fragile.

The Document Impact Matrix

One last table — the five documents touched most across all situations. If your project has only these five, you’ve covered most of the ground.

The three remaining high-leverage documents, for when the situation touches specific areas:

The Three Moves That Apply to Everything

Across every situation above, three moves are universal:

1. Write it down before you act. Issue Log entry first, action second. You will not remember the detail in 48 hours.
2. Name the baselines affected. Scope, schedule, cost, quality, risk, or none. The answer forces clarity on what you’re really dealing with.
3. Communicate asymmetrically. When something is wrong, default to more communication, earlier, not less. Silence on a slipping project is how you lose the sponsor’s trust.

Closing Checklist

Before any situation above goes from “I should handle this” to “handled”:

• Captured in the Issue Log with date, description, and owner.
• Baselines identified (scope / schedule / cost / quality / risk).
• Change Request raised for any baseline change, even if you expect approval.
• Risk Register updated — new, changed, or closed entries.
• Stakeholders informed via the Communications Plan — including those not yet asking.
• Decision documented in writing with its owner and date.
• Lessons Learned Register entry drafted while the situation is still fresh.
• Affected artifacts identified against the matrix above — none silently left stale.

Further Reading

• Parent article: PMBOK as a Framework: Inputs and Output Artifacts for Every Part of a Project — the vocabulary that the situations above all draw on.
• A Guide to the Project Management Body of Knowledge (PMBOK Guide) — 6th edition’s Integrated Change Control section is the control loop every situation above depends on.
• Making Things Happen — Scott Berkun. Practitioner playbook; survives re-reading every few years.
• The Deadline — Tom DeMarco. Novelised project management; the case studies map 1:1 onto the situations above.
• Project Retrospectives — Norman L. Kerth. How to run the post-project lesson capture that the Lessons Learned Register depends on.

Most projects don’t fail from the situation. They fail from treating the situation as a one-off event rather than a cue to update the right documents. The documents are not the point — but keeping them coherent is how one project’s situations don’t become the next project’s starting conditions.