Guide §4 · PRINTED PP. 113–144
Inputs and Outputs
Artifacts are presented alphabetically rather than as a mandatory workflow. A named item can be an output from one activity and become an input to another; its role depends on the decision or work being performed. Management-plan components establish rules, responsibilities, methods, thresholds, and update practices. They should guide action; a plan that merely restates a template adds little control value.
Understand the chapter
Artifacts are presented alphabetically rather than as a mandatory workflow. A named item can be an output from one activity and become an input to another; its role depends on the decision or work being performed. Management-plan components establish rules, responsibilities, methods, thresholds, and update practices. They should guide action; a plan that merely restates a template adds little control value.
Learning objectives
- Distinguish an input, an intermediate project artifact, and an output by how each is used in context.
- Connect plans, baselines, registers, data, forecasts, deliverables, and reports into traceable decision flows.
- Choose an appropriate level of artifact detail and control for a project's needs.
Key concepts
The section is a reference catalog
Artifacts are presented alphabetically rather than as a mandatory workflow. A named item can be an output from one activity and become an input to another; its role depends on the decision or work being performed.
Plans define how work will be managed
Management-plan components establish rules, responsibilities, methods, thresholds, and update practices. They should guide action; a plan that merely restates a template adds little control value.
Baselines create controlled comparison points
Approved scope, schedule, and cost reference points support measurement and change control. Actual results are compared with them, and approved changes update the controlled reference rather than silently rewriting history.
Registers and logs preserve evolving knowledge
Assumptions, changes, issues, lessons, risks, and stakeholders need living records with owners and current status. Their purpose is coordination and decision support, not record creation for its own sake.
Data becomes useful through interpretation
Raw observations are organized into performance information, then communicated through reports designed to prompt awareness, decisions, or action. Forecasts extend current knowledge into a reasoned view of future conditions.
Acceptance is not the same as completion
A team may finish a deliverable, verify that it meets quality requirements, and still need an authorized stakeholder to validate and formally accept it against agreed criteria.
Deeper understanding
Why it matters
Outputs are not interchangeable: verification, acceptance, and operational transition have different decision owners.
Decision questions
- What evidence separates verified work from formally accepted work?
- Why is delivery of the portal insufficient evidence of its intended benefit?
- How could a traceability matrix reveal a completed work package that misses a requirement?
Teach it back
- Distinguish an input, an intermediate project artifact, and an output by how each is used in context.
- Connect plans, baselines, registers, data, forecasts, deliverables, and reports into traceable decision flows.
- Choose an appropriate level of artifact detail and control for a project's needs.
Signals to notice
- Outputs are not interchangeable: verification, acceptance, and operational transition have different decision owners.
- Baseline changes require authorization; a forecast can deteriorate without changing the approved comparator.
- Raw measurements become useful only when analyzed against a current decision context and communicated to the right audience.
Section-by-section reading
Use the printed page references to read each section in the official publication, then explain the idea in your own words.
Accepted deliverables; verified deliverables; transition
Chapter 4 is an alphabetical reference of possible inputs and outputs, not a numbered workflow or a required-document checklist. A deliverable is a verifiable result or capability; verification establishes that completed work meets specified requirements, while acceptance adds an authorized stakeholder’s approval against agreed criteria. The accepting party should be involved early enough to give feedback rather than encountering the product only at handover. Transition is another distinct output: operational responsibility passes to the group that will support the final or phase result. These distinctions matter because a technically correct artifact can still be unaccepted, and an accepted artifact can still lack an effective operating owner.
Understand this item
Why it matters: Technical conformance, stakeholder approval, and operational readiness are separate conditions; confusing them can produce a compliant result that nobody has accepted or can sustain.
Decision to make: Define verification and acceptance evidence, involve the accepting party before handover, and prepare ownership, training, support, and assets for transition.
Do not confuse it with: Verification confirms requirements, acceptance records authorized approval, and transition transfers responsibility for operating or supporting the result.
Teach it back: Using a calibrated sensor system, identify the evidence for verification, acceptance, and completed transition.
Apply it: The lab passes sensor calibration, the client signs acceptance, and maintenance receives training and spares before takeover.
Check yourself: What evidence separates verified work from formally accepted work?
Business case and benefits management plan; charter
The benefits management plan states when expected benefits should arise, how they will be measured, and how they can be sustained after delivery. Its inputs include the business case and needs assessment, while the charter and project plan should remain aligned with it through the life cycle. Benefits are not identical to outputs: a new capability may need adoption, operational ownership, and time before value becomes observable. The charter provides formal authorization and high-level direction, whereas the benefits plan follows the realization logic into operations. The chapter treats maintaining the benefits plan as iterative rather than as an initiation-only ceremony. Assign indicators and post-transition owners before claiming the project succeeded.
Understand this item
Why it matters: Authorization to produce an output does not prove that users will adopt it or that intended benefits will appear and persist after project closure.
Decision to make: Keep the charter and project plan aligned with the business case, define benefit indicators and timing, and assign operational owners before transition.
Do not confuse it with: The charter authorizes and directs the project, while the benefits management plan explains how outcomes will be measured and sustained beyond delivery.
Teach it back: Explain why launching a triage portal is an output and how reduced waiting time would be measured as a later benefit.
Apply it: A clinic charters a triage portal but tracks reduced waiting time only after nurses adopt it and operations own the measure.
Check yourself: Why is delivery of the portal insufficient evidence of its intended benefit?
Scope and requirements: documentation, traceability, baseline
Requirements documentation explains individual needs, while a traceability matrix links them to their origins, elaborations, and verification evidence. The scope baseline is the approved reference for what the project will deliver, including the decomposition into work packages and supporting dictionary information. These artifacts answer different questions: why a feature exists, how its completion will be tested, and which authorized work contains it. A user story can describe a stakeholder outcome without replacing safety or compliance criteria. The chapter’s alphabetical format should not be mistaken for a dependency order; teams may tailor the artifacts while preserving a usable chain from need to result.
Understand this item
Why it matters: A team needs an auditable chain from stakeholder need to authorized work and verification evidence; otherwise completed packages can still miss essential requirements.
Decision to make: Document needs, link each requirement to its origin, work package, test, and acceptance authority, and control the approved scope baseline as the delivery reference.
Do not confuse it with: Requirements explain what is needed, traceability connects need to evidence, and the scope baseline defines approved work; a user story does not replace safety criteria.
Teach it back: Show how a traceability link could reveal that a completed bridge-lighting package lacks proof of one safety requirement.
Apply it: Link each bridge-lighting safety requirement to a design package, test record, and named acceptance authority.
Check yourself: How could a traceability matrix reveal a completed work package that misses a requirement?
Schedule, resources, and estimates: activity attributes to forecasts
Activity attributes enrich the activity list with identifiers, predecessors, constraints, required resources, and other scheduling details as understanding grows. Duration estimates quantify time periods, not imposed waiting lags; a milestone is a significant zero-duration event. Calendars determine working availability, while schedule models and network diagrams make relationships visible. The schedule baseline is the approved comparison point; forecasts use performance evidence to anticipate future conditions. The basis of estimates records assumptions, uncertainty, and methods rather than presenting a naked number as certainty. Physical and virtual resource assignments change with availability, so a plausible plan needs both logical sequence and realistic capacity.
Understand this item
Why it matters: A date is credible only when logic, calendars, capacity, assumptions, and current performance agree; hiding waits or constraints makes forecasts misleading.
Decision to make: Record activity relationships and resource needs, apply working calendars, separate durations from lags and milestones, preserve estimate assumptions, and forecast against the approved baseline.
Do not confuse it with: The baseline is the approved comparison point, the forecast predicts the likely future, and an estimate's basis explains uncertainty rather than turning a number into certainty.
Teach it back: Explain why permit waiting should appear as a lag or dependency rather than being buried inside installation duration.
Apply it: A road closure permit is a milestone; crane availability and night-shift calendars change the feasible installation dates.
Check yourself: Why should a two-week waiting lag not be hidden inside the duration estimate?
Financial controls: estimates, baseline, funding, forecasts
Cost estimates predict likely expenditure from current knowledge and should become more precise as assumptions are tested. The approved time-phased cost baseline excludes management reserve and changes through control procedures; it is not the same as a forecast or a request for cash. A performance measurement baseline integrates scope, schedule, and cost comparison. Funding requirements and strategy concern when money must be available and from which sources, while revenue forecasts and a financial management plan address related financial decisions. Changes to the baseline should be justified and recorded, not silently used to erase a variance. Keep the basis of estimates visible when comparing competing procurement options.
Understand this item
Why it matters: Conflating expected cost, approved budget, cash availability, and forecast performance can hide overruns or trigger unjustified baseline changes.
Decision to make: Retain estimate assumptions, compare performance with the controlled time-phased baseline, forecast likely outcomes, plan funding timing and sources, and route baseline changes through authorization.
Do not confuse it with: An estimate predicts cost, the baseline authorizes a comparison reference, funding supplies cash when needed, and a forecast projects the outcome from current evidence.
Teach it back: Explain why a forecasted tunnel overrun should remain visible until a justified scope or baseline change is formally approved.
Apply it: A tunnel team forecasts a cost overrun but preserves the original baseline pending approval of a change to lining scope.
Check yourself: What differs between a forecasted overrun and an approved baseline update?
Risk, issues, changes, and lessons: living records
The risk register records uncertain future events and candidate owners or responses; an issue log tracks matters that have already arisen. A risk report can summarize wider exposure beyond individual entries. A change request can propose correction, prevention, defect repair, or new work and requires a review and disposition path. The lessons learned register captures knowledge during the work and can later feed an organizational repository; it is not merely a closing report. Environmental factors constrain or shape the project beyond immediate team control, whereas organizational process assets include reusable internal policies and prior learning. Treat updates as evidence of active management, not administrative churn.
Understand this item
Why it matters: Active records preserve decision history and move new knowledge into action; stale registers turn uncertainty, present problems, changes, and learning into disconnected paperwork.
Decision to make: Move occurred conditions into issue handling, assess whether they require controlled change, update exposure and owners, and capture lessons during the work for reuse.
Do not confuse it with: Risks are uncertain, issues exist now, change requests seek authorized modification, and lessons record reusable knowledge; each supports a different decision path.
Teach it back: Trace a forecast flood from risk monitoring through actual water ingress, issue handling, possible redesign request, and captured lesson.
Apply it: A forecast flood remains a risk; discovered water ingress becomes an issue and may trigger a controlled redesign request.
Check yourself: When should a risk become an issue rather than remain only in the risk register?
Work performance data, information, reports; final report
Raw observations are work performance data; analysis in context creates work performance information; reports package that interpretation for decisions. An amount spent alone says little until compared with planned progress and approved reference points. Status reports and dashboards can present performance at useful intervals or by exception, while the final report records overall performance, unresolved matters, and relevant learning. The project management plan and its subsidiary plans define how execution and control will occur, not a guarantee that outcomes happened. Separating these layers prevents a polished presentation from disguising missing measurements or an obsolete baseline. Tailor the level of detail to the decision audience.
Understand this item
Why it matters: Raw measurements do not support decisions until interpreted against plans and baselines, and polished reports can conceal missing or obsolete evidence.
Decision to make: Collect consistent observations, analyze them in context, package decision-relevant conclusions for each audience, and preserve outcomes, unresolved matters, and learning in the final report.
Do not confuse it with: Data are observations, information is analyzed meaning, and reports communicate that meaning; a management plan describes intended control rather than proving performance occurred.
Teach it back: Explain how recorded labor hours and completed work become a forecast and then a sponsor-ready warning about handover.
Apply it: Weekly hours and earned progress become a forecast; the sponsor report flags a likely handover delay and proposed response.
Check yourself: Which transformation turns recorded hours into decision-ready performance information?
Apply it to a project
A sponsor receives a weekly dashboard showing an eight-day delay, but the schedule file, change log, and forecast disagree. No one can explain whether the target date was approved or merely overwritten. Reconstruct the information chain: preserve the approved schedule baseline, record actual progress separately, analyze the variance, create a forecast, and route any proposed target-date change through the authorized change process. The dashboard should cite the same controlled sources and indicate decision status. Traceability turns a collection of documents into a dependable management system.
What to watch for
- Misconception: Every listed artifact is required on every project. Correction: The catalog offers reference options. The team selects and tailors artifacts according to context and governance.
- Misconception: An output is final and cannot become an input. Correction: Artifacts flow across activities. A forecast or approved deliverable can inform later control, acceptance, transition, or closure work.
- Misconception: Updating a baseline is the same as recording actual performance. Correction: Actuals show what happened. A baseline changes only through the project's authorized change mechanism.
Test your reasoning
Why are Section 4 items arranged alphabetically?
Show answer and reasoning
1 Alphabetical presentation helps lookup and does not prescribe process order.
Which statement best distinguishes a baseline from a forecast?
Show answer and reasoning
1 The baseline anchors performance comparison, while the forecast is updated as evidence changes.
When is a completed deliverable accepted?
Show answer and reasoning
2 Formal acceptance depends on validation by the designated authority.
What is the best reason to maintain a risk register?
Show answer and reasoning
1 The register is useful when it supports active management and decisions.
A report contains numbers but leads to no awareness, decision, or action. What is the best next step?
Show answer and reasoning
1 Outputs should serve an information need; unused reporting is a candidate for tailoring.
Study companion only; the official guide is available from PMI.