PMP study guide

• Build the vision with stakeholders, not for them, a charter workshop, a project kickoff, an inception.
• Revisit it when the business changes. A stale vision is worse than none.
• Adaptive tools: product vision box, elevator statement, product goal.

• Set expectations, then empower. Clear roles and responsibilities (RACI), then get out of the way.
• Represent the voice of the team upward and outward. You are their shield.
• Support varied experience and perspective. Diversity questions want inclusion and psychological safety, not sameness.
• Choose a leadership style to fit, servant leadership dominates adaptive contexts; directive is for crises; laissez-faire is almost always the wrong answer.

Tuckman

Motivation, compressed

• Power/interest grid. High power + high interest: manage closely. High power, low interest: keep satisfied. Low power, high interest: keep informed. Low/low: monitor.
• Salience model. Power, urgency, legitimacy, a stakeholder with all three is definitive and gets your attention now.
• Stakeholder register holds who they are; the engagement plan holds what you will do about them; the engagement assessment matrix tracks current vs desired engagement (unaware / resistant / neutral / supportive / leading).
• Missed a stakeholder? Add to the register, analyze, engage. Do not just start copying them on email.

• Identify internal and external customer expectations specifically.
• Keep outcomes aligned to them as things drift.
• Monitor satisfaction and respond. Not annually, continuously. Surveys, feedback loops, review sessions, NPS-style checks.

• Explicit knowledge: documented, transferable, wikis, runbooks, lessons learned register.
• Tacit knowledge: in someone's head, moved by pairing, shadowing, mentoring, communities of practice, osmotic communication.
• A key person leaving is a knowledge risk. It belongs in the risk register before they resign, not after.

• Define a communication strategy: who needs what, in what form, how often, why.
• Promote transparency and collaboration, information radiators, open backlogs, visible boards.
• Establish a feedback loop. Communication without one is broadcasting.
• Understand reporting requirements and build reports that match what sponsors and stakeholders asked for, then support governance with them. That last clause is new and it points straight at Business Environment.

Methods

Choosing the approach

• Define it, get stakeholder agreement on it, break it down.
• Predictive: scope statement → WBS → work packages → activities. The lowest level of the WBS is a work package. The WBS dictionary holds the detail. The scope baseline = scope statement + WBS + WBS dictionary.
• Adaptive: product backlog → epics → features → user stories, refined continuously. Prioritized by the product owner.
• Scope creep: uncontrolled additions from outside. Gold plating: extras you added because you thought they would be nice. Both are wrong; gold plating is worse because it is self-inflicted.
• 100% rule: the WBS contains all of the work and nothing but the work.

• MVP, smallest release that delivers usable value and generates learning.
• MBI, minimum business increment; the smallest chunk worth releasing to the business.
• MoSCoW, must / should / could / won't have.
• Benefits realization often lands after the project closes. Verify someone owns measuring it, usually not you.

• Define and plan resources from requirements; then manage and optimize need against availability.
• Resource leveling: respect resource limits; the critical path can move and the end date usually slips.
• Resource smoothing: only uses float; the end date does not move.
• Resources are people and materials, equipment, facilities.
• Physical resource shortages: check the plan, then procurement, then the sponsor. Not the team's overtime.

• Contingency reserve: for identified risks. Inside the cost baseline. The PM controls it.
• Management reserve: for unknown-unknowns. Outside the cost baseline, inside the budget. Management controls it. You need approval, and using it changes the cost baseline.
• Cost baseline = work estimates + contingency. Budget = cost baseline + management reserve.
• "Anticipate future finance challenges" is proactivity again: forecast with EAC, flag the burn rate before it bites.

• Gather quality requirements, plan processes and tools, execute the plan, help ensure regulatory compliance, manage cost of quality and sustainability, run ongoing reviews, implement continuous improvement.
• Quality = meets requirements. Grade = category of features. Low grade can be fine; low quality never is.
• Prevention over inspection. Always. Cost of conformance (prevention, appraisal) is cheaper than cost of non-conformance (internal and external failure).
• Validate scope = customer accepts deliverables. Control quality = you verify correctness. Control comes first.
• Seven basic tools: cause-and-effect (Ishikawa/fishbone), flowchart, check sheet, Pareto (80/20), histogram, control chart, scatter diagram.
• Control charts: rule of seven, seven consecutive points on one side of the mean means the process is out of control even inside the limits. Specification limits come from the customer; control limits come from the process.
• Sustainability now sits inside quality. Expect the cost of environmental impact treated as a cost of quality.

• Build the schedule to suit the chosen approach, coordinate with other projects and operations, estimate (milestones, dependencies, story points), use benchmarks and historical data, create it, baseline it, execute it, analyze variance.
• Critical path: longest path, shortest possible duration, zero float. Float = LS − ES = LF − EF. Free float delays the successor; total float delays the project.
• Crashing: add resources. Costs money, adds risk of communication overhead.
• Fast-tracking: overlap activities. Free, but adds rework risk. Try it before crashing if the stem says budget is fixed.
• Neither happens without impact analysis and approval.
• Estimating: analogous (top-down, fast, least accurate), parametric (rate × quantity), bottom-up (slow, most accurate), three-point (PERT).
• Adaptive scheduling: release plan → sprint plan; velocity from story points; the team estimates, not you.

• Develop metrics and reconcile them; identify and tailor the artifacts you actually need; make sure they get created, reviewed, updated, and are accessible; assess progress; update metrics; communicate status; and continually assess whether your artifact management is working.
• Tailoring is the point. Producing every artifact in the book is a wrong answer.
• Predictive measurement: EVM, milestone charts, variance analysis.
• Adaptive measurement: burndown, burnup, velocity, cumulative flow diagram, cycle time, lead time, throughput.
• Percent complete reported by the person doing the work is not a measurement. Adaptive answer: done is done, the increment either meets the definition of done or it does not.

• Get stakeholder approval of completion, determine the criteria for closing, validate readiness for transition (to operations, or the next phase), then conclude, final lessons learned, retrospectives, procurement, financials, resources.
• Close every project, including canceled ones. A terminated project still gets closed out and still produces lessons learned. This is a classic question.
• Order: validate scope → transition deliverables → close procurements → release resources → final lessons learned → archive.
• Transition readiness is more than "it works." Training, runbooks, support model, warranty period.

• Establish the structure, rules, procedures, reporting, ethics, and policies, using organizational process assets.
• Define success metrics. Up front. Not schedule and budget alone, outcome and value.
• Outline escalation paths and thresholds. Decide before the crisis who decides what, and at what number it leaves your hands.

• Compliance is never negotiable and never traded against schedule or budget. If a stem offers "ship now, remediate later" on a regulatory item, it is wrong.
• Non-compliance is a risk with legal, financial, and reputational impact, quantify it.
• Safety overrides everything, including the sponsor.
• Sustainability and ESG are compliance now, not a nice-to-have.

• Execute the change control process, request, log, impact analysis, decision, communicate.
• Communicate the status of proposed changes. People are waiting on an answer.
• Implement approved changes and update the documentation. An approved change that never reaches the plan will hurt you later.
• Integrated change control: assess impact across all baselines (scope, schedule, cost, quality, risk) not just the obvious one.
• Emergency change: some organizations allow it, but it still gets logged and ratified afterward.
• Adaptive equivalent: change is expected. It goes in the backlog, the product owner reprioritizes, and it enters at the next sprint boundary, not mid-sprint.

• Evaluate impact, prioritize and make impediments visible, apply an intervention strategy, and reassess continually that blockers are actually being cleared.
• Recognize when a risk becomes an issue, a risk is future and probabilistic; an issue has happened. When it fires, it moves from the risk register to the issue log.
• Collaborate with stakeholders on the resolution. You do not resolve it alone.
• Removing impediments is the servant leader's core act. Impediment backlog, radiated visibly, worked daily.

• Identify, analyze, monitor and control, plan, maintain the register, execute responses, and communicate risk impact status.
• Note PMI's own examples: poor IT security, and risk response for security and managing sustainability risks. Those are the flavors to expect.

• Qualitative first: probability × impact matrix, subjective, fast, prioritizes. Quantitative second and only for what qualitative flagged: EMV, Monte Carlo, decision trees, sensitivity (tornado diagram).
• Appetite: how much risk you'll take. Threshold: the measured level where it becomes unacceptable. Tolerance: the range you can live with.
• Secondary risk: created by your response. Residual risk: left over after it. Both go in the register.
• Trigger: the early warning sign. Risk owner: the person accountable for the response, never "the team."
• Identification is continuous and everyone participates.

• Use lessons learned, not just record them. The question "we hit this last time too" is a failure of this task.
• Keep the improvement process itself updated.
• Update OPAs. Your project's learning belongs to the organization.
• Lessons learned register lives during the project; the repository is the OPA it feeds at closure.
• Retrospectives every iteration; kaizen; PDCA; process improvement plans. Improvement is a cadence, not an event.

• Assess organizational culture, the project sits inside it and cannot outrun it.
• Evaluate the impact of organizational change on the project and act.
• Resistance is information, not insubordination. Find the cause.
• Frameworks worth knowing: ADKAR (awareness, desire, knowledge, ability, reinforcement), Kotter's 8 steps, Bridges' transition model (ending → neutral zone → new beginning), Satir change curve, Virginia Satir's late-stage chaos being normal.
• Deliverables do not create benefits. Adoption does.

• Survey the external environment for changes.
• Assess and prioritize the impact on scope/backlog, note it is scope or backlog; this applies in both worlds.
• Continually review. Not at the kickoff. Continuously.
• Tools: PESTLE (political, economic, social, technological, legal, environmental), SWOT, market analysis, competitor scanning, regulatory horizon scanning.
• The archetype question: the project delivers exactly what was asked, on time, on budget, and the market moved. What should have happened? Someone should have been watching, and the scope or backlog should have moved with it.