PMP flashcards

People

• The vision is the why; scope is the what. Every trade-off is tested against the intended outcome, on predictive and agile projects alike.
• The charter formally records purpose, measurable objectives and success criteria and authorizes the project; a product vision statement, product box and roadmap carry the vision on agile work.
• Commitment comes from co-creation: facilitate live sessions, and use silent individual idea generation to stop a senior voice anchoring the group.
• Competing visions are reconciled with the sponsor early, before the charter or design locks in one reading.
• The sponsor owns the business case and chartered objectives; the product owner owns the product goal; the project manager facilitates, promotes and coaches.
• Promote the vision by making it part of decisions (radiators, iteration goals, work packages traced to objectives), not by repeating it one-way.
• Revisit the vision when strategy, market, regulation or user evidence change; schedule slips and cost variance are planning problems.
• Changes to chartered objectives go to the sponsor; refinements within them are the product owner's call.
• In hybrid work, report and plan every stream against one shared outcome and resolve cross-stream trade-offs jointly.
• Analyse a vision misunderstanding before fixing it: compare interpretations, use a fishbone or five whys, and correct the source.

• Find the cause before choosing a response: personality clashes often hide resource, priority or role conflicts.
• Context decides the technique: importance, urgency, relationships, authority and culture.
• Collaborate when there is time and openness; compromise when power is equal and time is short; force for emergencies and safety or legal non-negotiables.
• Smoothing and withdrawing never resolve the substance; use them for low-stakes issues or a cool-down only.
• After forcing, repair the relationship with the person who was overruled.
• Speed Leas' levels run problem to solve, disagreement, contest, crusade, world war; intervene more directly as the level rises.
• Self-organizing teams get the first chance to resolve their conflicts; step in when it turns personal or their attempt fails.
• Record agreed resolutions in the issue log, support them and follow up; meet the parties first if an agreement breaks down.
• Ground rules the team writes are the ones it follows; rectify violations privately and early, escalate only after that fails.

• The team writes its own charter or working agreement; the project manager facilitates it and revisits it with the team whenever members, locations or work change.
• When someone misses a team expectation: talk privately to understand the cause, clarify, agree a specific improvement plan, and escalate only if that fails.
• Empowered teams decide how to do the work and who takes which item; stakeholders get visibility, not control over assignments.
• Make decision rights explicit: the team owns what it can, and governance-mandated approvals stay with the named authority.
• Servant leadership removes obstacles and grows people; situational leadership matches direction and support to each person's competence and commitment on the task.
• Forming, storming, norming, performing, adjourning: new members or new work can send a mature team back to storming.
• Self-awareness recognises your own emotions, self-management controls them, social awareness reads others', relationship management acts on that.
• Solve problems with data and root-cause analysis with the team before choosing a fix; represent the team to the person who can fix its problem, with options.
• Change meeting formats, not people, so every voice is heard; blameless reviews and leaders who admit mistakes make problems surface early.
• One accountable person per activity in a RACI; the product owner orders the backlog, developers plan the sprint and judge how much fits.

• Stakeholder engagement is a loop: identify, analyze, plan, execute, then reassess whenever something changes.
• Identify stakeholders as soon as the charter exists, using many sources (existing stakeholders, lessons learned, experts), and keep identifying them all project long.
• A newly found stakeholder is recorded and analyzed first; if they control an imminent event, engage them before it.
• Power/interest grid: manage closely, keep satisfied, keep informed, monitor; re-rate when informal or indirect influence matters.
• The engagement assessment matrix shows current versus desired levels (unaware, resistant, neutral, supportive, leading); act on the largest, most urgent gaps.
• The stakeholder register records identity and assessment data; keep sensitive judgements in a restricted record.
• Tailor communication: push for targeted summaries, pull for large audiences looking things up, interactive for working things through.
• When engagement actions fail, ask why and change the method; with resistant stakeholders, understand the concern before acting.
• Align competing needs against the business case or product goal, and let the sponsor or product owner make the trade-off.
• Trust comes from early bad news, no concealment and realistic forecast ranges; influence comes from understanding others' priorities before escalating.

• Power/interest grid: manage closely (high/high), keep satisfied (high power, low interest), keep informed (low power, high interest), monitor (low/low).
• Salience model: power, legitimacy and urgency; all three make a definitive stakeholder, legitimacy plus urgency without power make a dependent one.
• Directions of influence: upward (sponsor, senior management, customer organization), downward (team and contributing specialists), outward (suppliers, end users, regulators, the public), sideward (peer managers); align sideward peers by negotiation.
• Re-categorize as soon as a stakeholder's power, interest or expectations change, and split a group whose expectations diverge.
• Unstated and tacit expectations come out through conversation, workshops, observation and early demos, not documents or later sign-offs.
• Make vague expectations measurable and record them as acceptance criteria; route expectations that arrive after the baseline through change control.
• Understand each party's needs first, then facilitate a joint session on the shared objective with inclusive techniques.
• Fist of five checks support for one proposal and seeks consensus; MCDA scores options against agreed weights; plurality is not majority.
• In agile, MoSCoW aligns competing scope and the product owner decides backlog order; align predictive-minded stakeholders with burnup charts, reviews and narrowing forecast ranges.
• Escalate with options and impacts only after facilitation fails and the decision is beyond your authority; mentoring fits ongoing role judgement, training fits a specific skill.

• External customers are outside the organization and receive or use the outcome; internal customers operate, support or work with it inside the organization, and their readiness expectations are part of success.
• Gather expectations from the real customers and users (interviews plus observation) before requirements are written, reaching them through any contractually agreed contact.
• Kano: basic needs go unstated but cause strong dissatisfaction when missing; delighters decay into basics, so revalidate old classifications with current customers.
• Alignment is judged by the outcome the business case expects, not by features delivered; when the outcome is missing, investigate with customers before acting.
• Use an MVP and small increments to test uncertain expectations with real use; on hybrid projects plan stable deliverables predictively and uncertain ones incrementally.
• Customer changes go through impact analysis and change control on baselined work, and through the product owner and backlog on adaptive work; never quiet fixes or flat refusals.
• Gold plating (team-added, unrequested work) is not good expectation management; offer ideas to the customer through change control.
• Control quality verifies deliverables; validate scope obtains the customer's documented acceptance. A traceability matrix keeps each requirement linked to deliverables and tests.
• Monitor satisfaction with customer evidence (review feedback, NPS, CSAT, usage) and report it per customer group; delivery metrics can look healthy while customers drift away.
• Respond to gaps by finding the specific cause with the affected customers, and reset expectations early, on a checked basis, with the sponsor and product owner involved.

• Knowledge transfer has three enablers: identify critical knowledge, gather it, and foster an environment where people share it.
• Explicit knowledge goes into repositories and documents; tacit knowledge moves through shadowing, pairing, coaching and joint work, not manuals or courses.
• Identify critical knowledge first: rank it by impact, how few people hold it and how exposed it is, and map it to the people who actually hold it.
• Knowledge held by one person is a risk: respond early by pairing a backup inside the team, within the stated constraints, before escalating.
• Gather knowledge with techniques that reach real practice: observation, interviews, facilitated workshops, walkthroughs and practice on real cases.
• Capture knowledge as it is created (decision rationale, definition of done, markups, runbook updates in the story), not at the end of a phase or project.
• Make vendor knowledge transfer a contracted deliverable with acceptance criteria; use a contract change if it is missing and withhold acceptance if the criteria are unmet.
• Operations teams learn by doing: involve them in testing, rehearsals or the delivery team before handover.
• Psychological safety comes first; address hoarding by understanding its cause, such as job insecurity or incentives, never by order or punishment.
• Communities of practice thrive on member-set agendas and real cases; sponsors should offer support without control.

• Analyze each stakeholder group's information needs first; tools, templates and meetings come after.
• Communication channels = n(n − 1) ÷ 2, counting the project manager; for a change in team size, subtract the two totals.
• Pull suits large audiences and large volumes; push suits specific recipients; interactive suits urgent, complex or sensitive matters; combine a meeting with written minutes when you need both understanding and a record.
• The communications management plan records requirements, content, frequency, owners, methods, escalation and how the plan is updated; update it when stakeholders or cadence change.
• Acknowledgement is not understanding: ask receivers to summarize back or explicitly confirm they will act, and remove noise such as jargon, poor connections and cultural barriers.
• Information radiators, open backlogs and iteration reviews give transparency without extra reporting; distributed teams need live discussion in overlap hours, and hybrid teams need joint touchpoints.
• Measure communication by stakeholder understanding and outcomes (interviews, issue log), not by reports sent or emails opened.
• Confirm contractual, PMO and regulatory reporting obligations before designing reports, and consolidate overlaps from one data source.
• Report against tolerances exactly: handle what is within delegated authority, escalate a breach or forecast breach with the recovery plan, and never hide bad news or a known error.

Process

• Magnitude is size; complexity is uncertainty. Requirements and technical uncertainty, not budget or headcount, drive the delivery approach.
• Predictive = fixed requirements, single delivery; iterative = evolving requirements, single delivery; incremental = known, stable-enough requirements, frequent delivery; agile = both evolving and frequent.
• Hybrid projects integrate through dated milestones, capacity-based cost baselines and shared governance, and can be tailored component by component. Record the approach in the plan's development approach.
• Critical information is designed in during planning: definition, source, owner and cadence, starting from what each decision or obligation needs.
• Execution strategy comes from the binding constraints; installation and cutover can be separated, and constrained work with shared specialists goes first.
• The performance measurement baseline is scope + schedule + cost. Baselines and management plans change only through change control; the schedule, estimates and logs are project documents.
• PERT beta = (O + 4M + P) / 6; effort becomes duration through allocation; agile plans scale velocity by every capacity reduction; re-estimate when the assigned people change.
• Resolve cross-plan conflicts before baselining; only discretionary dependencies can be relaxed.
• Judge continued value on remaining cost versus remaining benefit, ignore sunk costs, and take the analysis to the sponsor to decide.
• Rolling wave detail within a planning package's budget is maintenance, not a re-baseline; choose EMV, what-if, variance or trend analysis by the question being asked.

• Pick the elicitation technique by the problem: can't describe the work, observe; can't specify the product, prototype; groups conflict under a deadline, run a facilitated workshop.
• The scope statement holds the product scope description, deliverables, acceptance criteria and exclusions; the charter authorizes and the scope management plan describes the method.
• Make every expected item explicit before sign-off: confirmed out of scope is an exclusion, still uncertain is an assumption.
• Acceptance criteria are per item and must be objectively verifiable; the definition of done applies to all work; the definition of ready is the entry condition for an iteration.
• Several teams on one product need one shared definition of done.
• The scope baseline is the approved scope statement, WBS and WBS dictionary; after approval, changes go through change control whoever raises them.
• The WBS is deliverable-oriented, follows the 100% rule (including project management work) and stops at work packages; activities live in the schedule.
• Detail near-term work now and later work later: rolling wave and planning packages in predictive work, just-in-time backlog refinement in agile work.
• Verify internally before the customer formally accepts; in agile, a story that misses a criterion returns to the backlog for the product owner to reprioritize.
• Requested and unapproved is scope creep; unrequested and team-initiated is gold plating. Route changes to change control or the product owner according to how the component is managed.

• Value is defined with the stakeholders who hold it, in measurable outcomes, before work is prioritized; reconcile competing definitions with them and the sponsor before escalating.
• Intangible value such as trust or morale stays in the business case and is tracked through an agreed indirect measure with a baseline and target.
• MoSCoW protects a fixed date: could-haves give way first, then should-haves, never must-haves, and too many must-haves leave no margin.
• Kano: basic features are expected and missed when absent, performance features scale satisfaction, delighters differentiate, and delighters drift into basics as the market catches up.
• WSJF is cost of delay divided by duration; value that expires with time goes first.
• The product owner reorders the agile backlog from feedback; baselined predictive work changes through change control; hybrid projects use each route for its own part.
• Release any part that delivers value on its own (an MMF or a phased handover); constraints hold back only the parts they govern, and a fixed per-release cost makes batch size an economic choice.
• The business case is reviewed at phase gates and whenever assumptions change; green CPI and SPI say nothing about benefits.
• A benefits measurement system needs a baseline captured before go-live, an operational owner and a handed-over data source; outputs are not outcomes, and a leading indicator must keep predicting the lagging benefit.
• Demonstrate value with measured evidence that matches the doubt and respects the constraints, not with opinions or votes.

• The resource management plan covers how team and physical resources are identified, acquired, developed, managed, recognized and released.
• Resource needs are derived from requirements; when requirements change, update the resource plan and start acquisition ahead of the lead time.
• WBS breaks down the work, OBS the organization, RBS the resources; a resource calendar shows when a specific resource can work.
• A resource histogram compares planned load with availability and is how overallocation is confirmed before choosing a response.
• Smoothing stays within float and never moves the finish date, so it can leave residual overallocation; leveling may extend the date and create a new critical path.
• With a fixed date, smooth what has float and add qualified capacity on critical work; a leveled date beyond the baseline goes through change control.
• In a matrix, negotiate with the functional manager first; escalate with impacts and options only when negotiation is exhausted or the trade-off is strategic.
• Stable, dedicated teams give predictable capacity; plan from velocity adjusted for availability, and expect new members to lower velocity at first.
• Spread scarce skills by pairing and swarming, and close skills gaps before the work depends on them.
• Deliver materials just in time, book shared and rented equipment against lead times, explain variances before correcting them, and agree release with the resource's owner when the need ends, with a handover.

• Make-or-buy comes before any bid document and counts opportunity cost and non-cost factors, not just the price.
• RFQ for fully specified items compared on price; RFP when sellers must propose an approach; RFI to learn the market.
• Widely varying proposals point to an imprecise statement of work.
• Defined scope means fixed price and seller risk; undefined scope means cost-reimbursable or T&M and buyer risk.
• Incentive fee = target fee adjusted by the seller's share of the variance; FPIF is capped at the ceiling price.
• Score proposals with the agreed weighted criteria, share every clarification with all bidders and step aside from evaluation when you have a conflict of interest.
• Know the BATNA and walk-away point before negotiating; the project manager participates, procurement commits.
• Changes to a seller's work go through contract change control; informal direction creates a claim to administer.
• Settle claims by negotiation, then the contract's ADR clause; aim to settle every claim before formal closure.
• Match contract type to how defined each package is, and use agile contracting tools (master agreement, NTE T&M, fixed-price increments, early cancellation) for adaptive work.

• Analogous scales a past project's total, parametric multiplies a reliable unit rate by a quantity, and bottom-up rolls up work packages for the most accuracy.
• Cost baseline = work package estimates + contingency reserve, and it equals BAC; project budget = cost baseline + management reserve.
• Contingency by EMV is the sum of probability × impact with opportunities offsetting threats, sized on residual risk; with Monte Carlo it is the cost at the target confidence minus the base estimate.
• Identified risks draw contingency and leave BAC unchanged; unidentified work needs an approved release of management reserve, which raises BAC.
• Release contingency for closed risks per policy, and request more through change control when open exposure outgrows what is left.
• Actual cost is recorded when work is performed (accruals included); signed orders are commitments tracked against funding, not actual cost.
• When spend exceeds a period's funding limit, move work with float into the next period and raise funding breaches before they happen.
• Agile remaining cost = burn rate × iterations remaining; with a fixed budget, the product owner fits the highest value into the iterations it buys.
• Use EAC = BAC ÷ CPI when the cause persists, AC + (BAC − EV) for a one-off, and AC + new ETC when estimates were flawed; a TCPI far above CPI goes to governance.
• Analyze a variance before acting, rebaseline only for approved changes, and check earned value before calling an underspend a saving.

• Quality is meeting requirements; grade is the feature level. Low grade can be acceptable, low quality never is, and lowering grade is how to cut cost without cutting quality.
• Gather quality requirements during planning, from every user group, regulations and standards, not only from functional acceptance criteria.
• A quality metric has a target and a tolerance and reflects what the customer values; anything inside the tolerance conforms.
• Execute the approved quality management plan; skipping or replacing a quality activity is a change that needs approval. A hybrid project tailors one plan per approach.
• Manage quality examines the process (audits, process analysis); control quality examines the output (inspection, testing). Recurring defects call for process work, not more inspection.
• Control limits describe the process, specification limits describe the requirement. Investigate a point outside the control limits or seven in a row on one side; improve a stable process that is not capable; never tamper.
• Cost of quality: prevention and appraisal are conformance, internal and external failure are nonconformance. Shift effort toward prevention, but only to the economic level.
• Identify regulations early, build compliance checks into the definition of done, and keep documented evidence as the work is done.
• Sustainability criteria are measurable quality requirements: they change only through change control, and missing one is a nonconformance to resolve formally.
• Improve continuously during the project: root cause analysis before fixes, small measured PDCA trials, and lessons applied to the remaining work.

• Detail follows certainty: network and critical path for stable, interdependent work; iterations or flow for changing work; milestones plus cadence for hybrid.
• Iterations are fixed timeboxes: unfinished items go back to the product backlog rather than extending the iteration.
• A lead overlaps activities and a lag adds a wait with no work; pick FS, SS, FF or SF by which end of each activity is actually constrained.
• Milestones have zero duration and are achieved or not achieved; the activity before them carries the time and the percent complete.
• Story points are relative and team-specific, so velocity is not comparable across teams and breaks when used as a target.
• Weight the organization's own actuals and the doers' estimates most, adjust analogous data for scope, and use benchmarks to challenge, not replace, an estimate.
• Total float protects the finish date and free float protects the next activity; crashing past a near-critical path makes that path critical.
• Crash critical, resource-driven activities at the lowest cost per day within limits; fast-track only discretionary dependencies when money is unavailable but risk is acceptable.
• The baseline changes only through approved change control; performance slips stay as variance with corrective action.
• SPI can look healthy while the critical path slips and drifts to 1.0 after the planned finish; forecast adaptive work as a range and, for a fixed date, commit scope at the slow end.

• Outcome metrics show whether the project delivers value; output metrics only show activity. Add leading indicators when stakeholders need early warning.
• Velocity is a single team's planning measure: count only accepted work, never turn it into a quota and never use it to rank teams.
• Credit progress by an agreed objective rule: fixed formula for short packages, weighted milestones for long staged ones, level of effort only for genuine support work.
• SPI = EV / PV and CPI = EV / AC. A favourable SPI can hide a late critical path, SPI returns to 1.0 at completion, and a high CPI with a low SPI usually means work not yet performed.
• A burnup separates scope from progress; parallel burnup lines mean the release never finishes. A widening CFD band is a bottleneck, and lowering WIP shortens cycle time.
• Forecast as a range with its basis: velocity range for iterations, cycle-time history for flow work.
• Inside the threshold is not the same as fine: analyse a worsening trend and its root cause before acting, and reconcile conflicting sources before reporting.
• In hybrid status, map each stream's own forecast onto the shared milestone; a joint date is only as early as its latest critical dependency.
• Status reports carry progress against plan, a forecast with basis, trends, causes and responses, risks and decisions needed, and report slips when they happen.
• Each artifact needs one owner and one controlled, accessible version; tailor the set with governance, and retire artifacts nobody uses once you confirm no one needs them.

• Closure criteria are measurable, agreed during planning by the sponsor, customer and receiving owner, and limited to conditions the project can meet before it ends; long-term benefits are tracked after closure.
• When a stakeholder disputes completion, review the agreed criteria and the evidence with them; new expectations raised at closure are changes or follow-on work.
• An agile project ends when the product goal is met or remaining value no longer justifies cost, not when the backlog is empty; the authority in the charter decides, using the product owner's value forecast.
• Accepting every deliverable is not project completion: formal completion approval comes from the sponsor, customer or board the governance plan or contract names.
• A phase closes at its gate, where the governance body decides go, change or stop; unmet exit criteria are analysed and presented, never waived unilaterally.
• Transition readiness is proven by the receiving team doing the work (dry runs, its own tests, accepted runbooks); gaps are analysed with the receiving owner first, and hypercare must be time-boxed with exit criteria.
• Final lessons learned consolidate the register kept all project, are reviewed with stakeholders, written neutrally and archived in the organizational repository; a final retrospective covers the whole project for future teams.
• Every contract is formally closed, with claims settled and contractual payments made, before the project closes; costs are reconciled, cost accounts closed and unused reserves returned.
• Release people as their work ends, honour transition commitments, and give functional managers performance input.
• A cancelled project is still closed: record why and the state of the work, hand usable outputs to an owner, terminate contracts under their terms and capture lessons.

Business Environment

• Governance decides who decides, who oversees and what the project manager may decide alone; project management plans and delivers within it.
• Start from the organization's process assets (policies, templates, procedures, lessons learned) and tailor them; culture and regulations are environmental factors, not OPAs.
• Give each decision type one accountable owner; when someone acts outside their rights, refer back to the agreement before escalating.
• Supportive PMOs advise, controlling PMOs require and audit compliance, directive PMOs manage the projects and project managers.
• Define success metrics in initiation with stakeholders, traced to the business case, measuring outcomes against a measured baseline.
• Inside a threshold, act and record; on an actual or forecast breach, escalate now with options; never self-fund from management reserve.
• Escalate level by level, using named alternates, decision owners and response times at each level.
• Governance reports are tailored, by exception, forward-looking and truthful: a known future problem changes the status now.
• Gates decide go, conditional go, rework or stop against the current business case; agile governance uses guardrails with exception review.
• Disclose conflicts and step back, follow gift limits, and report true status after raising concerns with the sponsor.

• Confirm compliance requirements early with qualified legal, compliance, safety or privacy experts; earlier lists, the sponsor's view or the team's own research are inputs, not confirmation.
• Re-confirm obligations whenever scope adds a new jurisdiction, site or type of data, before the change is finalized.
• Classification decides who can change an obligation: law only by the authority, contract only by the parties, internal policy through the organization's governance. A voluntary standard written into a contract is binding.
• A threat to compliance is an uncertain condition that could cause a breach; a gap that has already happened is an issue to act on now.
• Match the method to the obligation: train before new procedures, check daily obligations daily, and build controls and evidence into agile workflows instead of tailoring them away.
• A compliance register links each obligation to its control, owner and evidence; use it for audits, for impact analysis when a rule changes and hand it to operations at closure.
• Never trade a mandatory requirement off on expected value; fines are only one consequence of noncompliance, alongside shutdown, harm, liability and reputation.
• When a gap is found, contain the harm first, inform the compliance owners, fix the cause, then update plans through change control.
• Accountability for compliance cannot be transferred to a vendor; audit suppliers against their contract clauses.
• Records and attestations must be true; measure compliance by verified evidence and test results, not by effort or closed activities.

• Every proposed change to approved scope, schedule, cost or design becomes a documented change request in the change log, whoever asks and however.
• Analyse first: no change reaches a decision-maker without an integrated impact analysis covering every affected stream and the risks of any recovery tactic.
• Delegated approval needs every threshold met; one breached condition sends the change to the next authority, and urgency changes the speed of a decision, not who makes it.
• In agile delivery the product owner absorbs change through backlog ordering, and the sprint goal protects work in progress.
• On hybrid projects, story-level changes inside a commitment stay in the backlog; changes to contracted dates, baselined scope or the cost baseline need a change request.
• Emergency authority applies only when the plan's emergency criteria are met, covers only the emergency, and is followed by documentation and review.
• Unauthorized changes discovered after the fact are documented and assessed through change control before anyone accepts or removes them.
• Implement approved changes exactly as approved, return them for a decision if they outgrow the plan's limits, and verify them before closing the log entry.
• Board approval changes the plan, not a contract: procured work changes through the contract's change procedure and contracting authority.
• Change control decides a change; configuration management makes sure everyone uses the right version. PMI names identification, status accounting, and verification and audit; version control puts configuration control into practice.

• Evaluate first: find out what an impediment blocks, for how long and whether float absorbs it before choosing a response.
• A delay beyond an activity's float can create a new critical path; parallel path delays do not add up, the milestone moves by the largest net delay.
• Rank impediments by their effect on the goal, commitments and value, not by age, noise or who raised them.
• Make blockers visible, in priority order, to whoever can clear them while there is time to act.
• Remove external blockers yourself, coach the team on problems it can solve, minimize what cannot be removed, and escalate only after direct attempts fail.
• Never route around a required control; shorten it with its owner or through its own rules.
• An impediment is resolved when the work moves; recurring blockers need root-cause work with the system's owners.
• A risk becomes an issue when the event happens or is certain; triggers and higher probability do not count.
• Identified risk occurs: execute the planned response, fund it from contingency, log the issue and update the register. Unidentified problem: workaround, management reserve with approval.
• Every issue needs an owner and a target date in the issue log, and cross-boundary issues are resolved with the stakeholders involved.

• The risk management plan sets the approach (methodology, roles, funding, timing, categories, scales, thresholds, reporting); the register holds each risk with its owner, trigger, response and status.
• Thresholds decide which risks need active responses: a zero-tolerance rule overrides a low matrix score, and a missed confidence target calls for responses to overall project risk.
• Write risks as cause, uncertain event and effect. Something that has happened is an issue; a certain fact can be the cause of new risks.
• Use the probability and impact matrix to prioritize many risks, check the data quality behind a rating before acting, and keep low risks on a watch list.
• Monte Carlo and the S-curve answer "how likely are we to hit the date or budget overall"; sensitivity analysis and the tornado diagram show which uncertainties drive it.
• Threats: escalate, avoid, transfer, mitigate, accept (active or passive). Opportunities: escalate, exploit, share, enhance, accept. Only exploit makes an opportunity certain; transfer never removes a threat.
• Escalate risks outside the project's scope or authority; once the receiving owner accepts, mark the entry escalated and stop monitoring it.
• When a trigger fires, the risk owner runs the contingency plan; a fallback plan follows if it fails; a workaround is for risks that were never planned for.
• Residual risk remains after a response; a secondary risk is created by it, including the chance a transfer fails, and gets its own response.
• Risk reviews keep the register current; risk audits test whether the process works. Report exposure, impact and decisions to the people who can act, when the risk demands it.

• OPAs (templates, checklists, procedures, policies, lessons repositories, historical data) are the organization's own assets and can be updated by their owners; EEFs (culture, regulation, markets, infrastructure, purchased databases) are conditions the project responds to.
• Review lessons and historical data from similar work before plans are baselined, and let evidence override an unsupported estimate.
• Record lessons in the lessons learned register whenever they emerge, including from each retrospective, tagged so others can find them.
• A useful lesson states what happened, its impact, the analysed root cause and a recommendation, without blame.
• Apply lessons to the rest of the current project now; anything that changes a baseline still goes through change control.
• Retrospective improvements need an owner and a place in the backlog; pick a few, follow up, and take outside constraints to whoever owns them.
• Change shared processes through their owner and keep following the current process until the change is approved; repeated tailoring is evidence the standard needs revising.
• Check a trial's measured results before standardizing: adopt clear wins, analyse mixed results, and pilot in contexts that differ from the trial.
• Update historical estimating data and risk checklists with project results and their context, and alert affected projects promptly when a shared asset is defective.

• Assess culture by watching and asking how decisions really happen; when surveys and behavior disagree, believe the behavior.
• A pattern repeated in past projects' lessons learned is culture to plan around, not bad luck.
• Culture varies by unit, location and acquisition: assess separate units on their own and tailor to each within a minimum common framework.
• Tailor the approach to the culture you have: a mixed agile-suitability result points to hybrid plus a plan to close the culture gaps.
• When the organization changes, analyze the impact on the project first, then prepare options; don't wait for certainty or jump to one fix.
• A new sponsor needs early re-engagement on the vision and business case; a missing sponsor must be formally replaced, not informally substituted.
• A strategy shift triggers a value reassessment with the owners and a continue, adapt or stop decision by governance.
• After a reorganization, re-agree capacity with new resource owners and update the RACI, resource plan, stakeholder register and governance bodies.
• Kotter leads organizations, ADKAR finds the missing individual element, Bridges guides the emotional transition, Satir explains the performance dip.
• Resistance is information: understand its cause first, and in uncertainty share what is known and unknown without breaking confidentiality.

• External changes come from outside the organization (laws, technology, geopolitics, markets); reorganizations, staffing and internal process changes are internal and handled by other tasks.
• Survey outward with a structured scan such as PESTLE, fed by the experts who watch each area; classify by the kind of thing that changed (a change in preferences is Social whatever its subject).
• Review continually: build the check into refinement, iteration reviews or phase gates, give every watch item an owner and review date, and define triggers for evolving changes.
• Analyze an external change's impact across everything it touches before acting, and scope the response to the markets, features and releases it really affects.
• Proposed changes are risks to monitor, ideally with low-cost options that keep flexibility; enacted or dated changes are requirements or issues to deliver.
• When a watched risk occurs, execute the planned response and fund it from the contingency reserve; the management reserve is for unknown-unknowns.
• Mandatory external changes still go through change control on predictive baselines; in agile, the product owner reprioritizes using the date and impact the project manager makes visible.
• Prioritize by certainty, impact and urgency, and use cost of delay to sequence competing backlog items.
• Route each impact to its owner: change control for baselines and contracts, the product owner for the backlog, the sponsor for the business case.

Yes — the whole PMP deck is free and needs no account, as is every PMP revision lesson. Create a free account to save progress and drill practice questions; full-length mock exams are a one-time unlock per certification.