Appendices and Tools

How to Use These Appendices

A tool is only useful if it helps someone make a better decision or do cleaner work. If a template becomes another thing people fill out because it exists, it has already started to lose the plot. Use these lightly, but use them consistently, because consistent lightweight structure beats heavy process that everyone avoids until the project is already smoking.

Some of the reference concepts in the original PM Core Knowledge material come from PMP-style language and older process maps, so treat anything certification-specific as a working reference rather than a current exam guide, and verify formal terminology against the standard your organization actually follows before publishing or training from it.

Appendix A: Core Terms

Definitions get boring until people are arguing about the wrong thing. The goal here is not academic precision for its own sake; the goal is to make sure the room knows what kind of work it is managing, who owns what, and what kind of decision is actually being made.

TermWorking meaningProjectA temporary effort created to produce a defined result, deliverable, service, or change. It has a beginning, an end, constraints, and uncertainty.OperationOngoing, repeatable work that keeps the business running. Projects often create or change operations, but they are not the same thing.ProgramA related group of projects managed together because the combined outcome matters more than the individual pieces by themselves.PortfolioA collection of programs and projects used to support larger organizational goals, priorities, investments, or strategic choices.SponsorThe person or group with authority to fund, approve, protect, redirect, or stop the project. Stakeholders can request; sponsors decide.StakeholderAnyone who can affect the project, be affected by it, approve it, block it, fund it, use it, or inherit the consequences of it.Project ManagerThe person responsible for organizing the work, clarifying the path, managing communication, surfacing risks, tracking decisions, and helping the team move through ambiguity.ScopeThe work included in the project, the work excluded from it, and the boundaries that keep the team from accidentally building everything anyone mentions.RequirementA documented need, rule, behavior, condition, or expectation the final deliverable must satisfy.AssumptionSomething the team is treating as true for planning purposes, even though it may later need to be validated or corrected.ConstraintA limit the project has to work within, such as budget, timeline, resources, tools, approvals, compliance, platform rules, or stakeholder availability.DependencyA relationship where one task, decision, approval, person, system, or deliverable affects another.RiskA possible future event or condition that could affect the project. It has not happened yet, which means there is still time to manage it.IssueA current problem that is already affecting the project and needs action, ownership, or escalation.Change RequestA proposed adjustment to scope, schedule, cost, quality, resources, or approval expectations that should be assessed before the team absorbs it.DeliverableA defined output the project must produce, such as a plan, file, campaign asset, system change, report, build, launch package, or approved decision.MilestoneA meaningful point in the project used to show progress, decision readiness, approval, handoff, or completion.BaselineThe agreed version of scope, schedule, or budget that later changes are measured against.RACIA simple accountability map: Responsible, Accountable, Consulted, and Informed. It is useful only when the team actually agrees to it.PMOA project management office or governance function that may provide standards, templates, oversight, tools, reporting, or direct project leadership.

Appendix B: Process Group Quick Reference

Process groups are not meant to make the work sound official. They give the project manager a way to check whether the team has skipped something important because everyone was busy starting, building, or reacting.

GroupMain jobCore outputsWatch forExplore / InitiateDecide whether the work should start and what problem it is meant to solve.Problem statement, sponsor, rough objective, initial stakeholders, first risks, initial decision to proceed.Starting without a clear owner, confusing interest with commitment, or treating a request as approved work before anyone has defined it.PlanDefine the path before the work becomes motion for the sake of motion.Scope, requirements, assumptions, schedule, budget, resources, communication plan, risk plan, approval path.Planning forever, planning only the happy path, or writing a plan that does not match how the work will actually happen.ExecuteDo the work, coordinate the team, manage handoffs, and keep the delivery system moving.Assigned tasks, active workflows, status updates, decision logs, deliverables in progress, stakeholder touchpoints.Confusing activity with progress, letting ownership blur, and allowing side conversations to become unofficial direction.Monitor / ControlCompare reality to the plan and adjust intentionally.Schedule checks, budget checks, risk and issue updates, change requests, quality reviews, escalation notes.Finding problems too late, normalizing drift, or letting small changes accumulate until the plan no longer means anything.CloseConfirm acceptance, capture learning, archive the record, and transition the work cleanly.Final approval, handoff, retrospective, lessons learned, open item closure, archive, release of resources.Treating launch as closeout, skipping the postmortem, or leaving loose ends for the next team to rediscover.

Lifecycle check

Before work starts: can someone explain the problem, sponsor, objective, and first decision needed without needing a second meeting to decode the first one?

Before execution: are scope, assumptions, timing, resources, and approval expectations visible enough that people can work from them?

During execution: does the project manager know what changed, what is blocked, what is late, what is at risk, and who owes the next decision?

Before closeout: has the client, sponsor, or receiving team accepted the work, and has the team captured what needs to be remembered next time?

Appendix C: Knowledge Area Quick Reference

The knowledge areas are useful as a scan pattern. They are less useful when they turn into a giant grid nobody uses after the training session ends. The practical question is simple: have we thought about the major things that usually break projects?

AreaPractical meaningCommon artifactsIntegrationKeeping the work connected so the project is not ten separate conversations pretending to be one plan.Charter, plan, change control, decision log, closeout.ScopeDefining what is included, what is not included, and how changes are evaluated.Scope statement, requirements, WBS or work breakdown, acceptance criteria, change log.ScheduleTurning work into sequence, timing, dependencies, and visible progress.Timeline, milestones, critical path, task list, status updates.CostEstimating, budgeting, tracking, and explaining financial impact.Budget, estimates, burn, forecast, variance notes.QualityMaking sure the work meets the need instead of merely existing by the deadline.Quality criteria, review process, QA checklist, defect log, RCA.Resources / TeamKnowing who is doing the work, when they are available, and where capacity is already thin.RACI, staffing plan, resource calendar, escalation path.CommunicationsMoving the right information to the right people at the right time, without turning the project into noise.Status report, meeting cadence, recap, issue escalation, stakeholder updates.RiskFinding possible problems early enough to do something other than apologize later.Risk register, mitigation plan, contingency, owner, review cadence.Procurement / PartnersManaging external vendors, contracts, handoffs, statements of work, and dependency commitments.SOW, vendor timeline, contract terms, deliverable acceptance, procurement risks.StakeholdersUnderstanding who can influence, approve, block, fund, use, or inherit the work.Stakeholder map, engagement plan, approval path, decision rights.

Field rule: A project does not need a giant artifact for every knowledge area, but it does need a conscious answer for each one. The answer can be small, as long as it is real.

Appendix D: EVM and Estimation Formula Sheet

Earned value and estimation formulas can make performance visible, but only if the inputs are honest. A formula cannot rescue a bad estimate, a vague scope, or a project where the percent complete is being negotiated by mood. Use the math as a signal, not as a substitute for judgment.

TermFormula / meaningPlain-language useWatchoutPVPlanned ValueBudgeted value of work that should be complete by now.What should we have earned according to the plan?EVEarned ValueBudgeted value of work actually completed.How much planned value have we actually earned?ACActual CostActual amount spent for the work completed so far.What did the completed work actually cost?BACBudget at CompletionTotal approved budget for the project.What is the original total budget?CPICost Performance Index = EV / ACCost efficiency indicator.Less than 1 means the project is costing more than planned for the value earned.SPISchedule Performance Index = EV / PVSchedule efficiency indicator.Less than 1 means the project is earning value slower than planned.CVCost Variance = EV - ACDifference between earned value and actual cost.Negative means over budget for the value earned.SVSchedule Variance = EV - PVDifference between earned value and planned value.Negative means behind the planned value curve.EACEstimate at Completion = BAC / CPIProjected total cost if current cost performance continues.Useful when current cost efficiency is likely to continue.ETCEstimate to Complete = EAC - ACProjected cost to finish the remaining work.What do we still expect to spend?VACVariance at Completion = BAC - EACExpected budget variance at the end.Negative means projected over budget.

Estimation quick reference

MethodHow it worksWhen to use itAnalogous estimateUses similar past work as the comparison point.Fast and useful early, but only if the comparison is actually comparable.Parametric estimateUses a rate or model, such as cost per unit, hours per asset, or pages per day.Cleaner than guessing, but the rate has to come from something real.Bottom-up estimateEstimates smaller pieces of work and rolls them into a total.More work up front, usually better once the scope is defined.Three-point estimateUses optimistic, most likely, and pessimistic views to create a more balanced estimate.Good when uncertainty is meaningful and single-number estimates are too neat.ReserveExtra time, budget, or capacity held for known uncertainty.Should be visible and intentional, not hidden in inflated line items.

Three-point estimate

The simple three-point approach is useful when a single estimate feels suspiciously clean. Capture an optimistic case, a most likely case, and a pessimistic case, then use the discussion to understand where the estimate is fragile. The value is not only the number; the value is the conversation that exposes hidden assumptions.

FormulaUsePERT expected estimate = (Optimistic + 4 x Most Likely + Pessimistic) / 6Weights the most likely estimate while still acknowledging best and worst cases.Standard deviation = (Pessimistic - Optimistic) / 6Shows how much uncertainty is sitting inside the estimate.

Appendix E: Templates and Checklists

Templates are not paperwork. They are conversation tools. If a template does not force clarity, ownership, or a decision, cut it down until it does. The best template is the one the team will actually use when the project is moving and everyone is already a little tired.

Project Definition One-Pager

Use when a project is new, vague, inherited, or starting to move before the work has been defined.

FieldWhat to captureProject namePlain name the team will recognize.Problem / opportunityWhat are we solving, improving, creating, preventing, or enabling?ObjectiveWhat outcome should exist when this is done?Success criteriaHow will we know the work is complete and acceptable?In scopeWhat is included.Out of scopeWhat is explicitly not included, even if someone asks for it later.Key deliverablesThe actual outputs that need to be produced.Stakeholders / approversWho needs to be informed, consulted, or asked for approval.AssumptionsWhat we are treating as true for now.Risks / constraintsWhat could limit, delay, complicate, or damage the work.Timeline / milestonesKnown dates, gates, reviews, dependencies, and launch targets.Owner / next stepWho owns the next move and by when.

First 48 Hours Rescue Checklist

Use when you inherit a project that is already moving, already messy, or already politically warm.

FieldWhat to captureFind the sponsorIdentify who can make or confirm the important decisions.Collect the artifactsGather scope, timeline, status, budget, approvals, emails, notes, and prior decisions.Build the current-state mapWhat is done, in progress, blocked, late, unclear, or at risk?Identify the next deadlineKnow the nearest date that matters and what must be true before it arrives.Separate facts from noiseDocument what is known, what is assumed, and what is being guessed.Name the blockersCapture blockers with owners, impact, and required decisions.Stabilize communicationCreate one source of truth and one rhythm for updates.Send the first recapConfirm what you found, what is at risk, what decisions are needed, and what happens next.

Meeting Agenda and Recap

Use for project meetings that need a purpose, not just a time slot.

FieldWhat to capturePurposeWhy are we meeting, and what should be different after the meeting?Desired outcomeDecision, alignment, review, escalation, handoff, or problem-solving.TopicsThe smallest useful list of items to cover.Required decisionsDecisions needed in the meeting or immediately after.Open risks / issuesCurrent items that require visibility or action.Decisions madeWhat was decided, by whom, and any conditions attached.Action itemsOwner, action, due date, and dependency.Next communicationWhen the next update will happen and what it should include.

Status Report

Use when stakeholders need a clean view of where things stand without getting dragged through every internal detail.

FieldWhat to captureOverall statusGreen, yellow, red, or plain-language condition. Do not hide a red project inside polite wording.Progress since last updateCompleted work, approvals, decisions, and meaningful movement.Upcoming workNext tasks, milestones, reviews, or handoffs.RisksPossible problems that need watching or mitigation.Issues / blockersCurrent problems requiring action, ownership, or escalation.ChangesAny change to scope, timing, budget, resources, or assumptions.Decisions neededSpecific decision, owner, due date, and impact if delayed.Ask / support neededWhat help, air cover, clarification, or approval is needed now.

RAID Log

Use when risks, assumptions, issues, and dependencies are scattered across meetings and nobody can remember what is real anymore.

FieldWhat to captureTypeRisk, assumption, issue, or dependency.DescriptionClear statement of the item without burying the lead.ImpactWhat happens if this item is not managed?OwnerPerson responsible for tracking or resolving it.StatusOpen, monitoring, blocked, resolved, accepted, or escalated.Next actionWhat happens next and by when.Decision neededYes/no, and from whom.

Change Request

Use when someone asks for different work, more work, faster work, or work under new assumptions.

FieldWhat to captureRequested changeWhat is being requested, in plain terms.ReasonWhy the change is being requested now.RequesterWho requested it and whether they have approval authority.Impact on scopeWhat work is added, removed, or altered.Impact on scheduleWhat dates, milestones, or dependencies change.Impact on cost / resourcesWhat budget, staffing, or vendor impact exists.Impact on quality / riskWhat gets riskier, thinner, better, or less certain.RecommendationApprove, reject, defer, swap, or fast-follow.DecisionWho decided, what was decided, and when.

Decision Log

Use when decisions are being made in meetings, chats, calls, hallway conversations, or memory-based archaeology.

FieldWhat to captureDecisionWhat was decided.DateWhen it was decided.Decision ownerWho had authority to make or confirm it.ContextWhy the decision was needed.Options consideredWhat alternatives were discussed or rejected.ImpactWhat changes because of the decision.Follow-up actionWhat must happen next.

Lightweight Retrospective / Hotwash

Use after a milestone, launch, incident, difficult handoff, or project closeout while people still remember what actually happened.

FieldWhat to captureWhat workedThings worth repeating, not just things that were lucky.Why it workedConditions, decisions, behaviors, or tools that made it successful.What did not workPain points, delays, rework, confusion, defects, or avoidable stress.Root causeWhat created the issue underneath the visible symptom.What changes next timeSpecific process, communication, staffing, or decision-path improvement.OwnerWho will carry the improvement forward.

Closeout Checklist

Use when the project is done enough that people are trying to run away from it, which is exactly when closeout matters.

FieldWhat to captureFinal acceptanceClient, sponsor, or receiving team has accepted the deliverable.Open itemsRemaining issues have owners, due dates, or formal deferral.HandoffOperational owner knows what they are inheriting.Files / artifactsFinal documents, assets, reports, approvals, and source materials are stored where they belong.Lessons learnedRetrospective completed or at least captured in writing.Financial / vendor closureInvoices, contracts, purchase orders, and vendor obligations are closed or tracked.Team releaseResources are formally released or reassigned.

Final Working Note

The point of all this is not to make project management heavier. It is to keep the work from becoming vague, undocumented, over-promised, under-owned, and weirdly emotional because nobody wrote down what was decided three meetings ago. The lighter the project, the lighter the tool can be, but there should still be a tool. There should still be a record. There should still be a way to look back and understand why the team did what it did, because the timeline remembers what the room forgets, and projects get a lot less mysterious when the work leaves a trail.