Study guide
This chapter completes the Process domain by covering the work of delivering, monitoring, and finishing a project: managing budget and reserves, building quality in from the start, developing and adjusting the schedule, reporting status honestly, and closing out a project or phase in a way that supports what comes next.
Financial Planning and Reserve Management
Cost planning goes beyond estimating a total budget; it includes setting aside reserves to absorb the unexpected without derailing the project. A contingency reserve covers known risks that have been identified and analyzed, sized based on the probability and impact of those specific risks, and it is typically owned and released by the project manager as those risks occur or pass. A management reserve, by contrast, covers unknown-unknowns, risk that has not and cannot be specifically identified in advance, and it is normally controlled by management or the sponsor rather than the project manager, requiring a formal request to access. Confusing the two is a common exam trap: if a scenario describes a specific, previously identified risk materializing, contingency reserve is the more precise answer; if a scenario describes a surprise no one could have reasonably anticipated, management reserve fits better. Reserve levels are not set once and forgotten. As the project proceeds and some risks are retired without occurring, contingency tied to those risks can sometimes be released; as new risks are identified, additional reserve may need to be requested. Consider Yuki, managing a construction project, who set aside contingency for a known risk of permit delays. When the permit delay occurs and costs three weeks of idle labor, Yuki draws down the contingency reserve already earmarked for that risk rather than requesting new funds from the sponsor. Later, an unrelated shortage of a specialty material that nobody had flagged forces Yuki to formally request access to the management reserve. On the exam, the language 'previously identified risk' points to contingency reserve, while 'unforeseen event' points to management reserve.
Quality Planning and Continuous Improvement
Quality on a project means conforming to requirements and fitness for use, and PMBOK Guide principles emphasize building quality into processes and deliverables rather than inspecting for defects after the fact. Planning for quality means defining acceptance criteria upfront, deciding how conformance will be verified, and designing the work process itself to reduce the chance of defects, rather than relying solely on a final quality check to catch problems. Prevention is generally cheaper and more effective than inspection: catching a design flaw during review costs far less than discovering it after a customer has the product in hand. Continuous improvement extends this idea across the life of the project and beyond it, using techniques such as retrospectives, root-cause analysis, and process audits to identify systemic issues and adjust how the team works, not just to fix one instance of a problem. A single defect might be corrected with a quick fix, but if the same type of defect recurs, the better response is to examine and adjust the underlying process that keeps producing it. Consider Ben, a quality lead on a software project, who notices the same category of bug, a missed edge case in date handling, appearing across three different releases. Rather than only fixing the latest instance, Ben proposes adding a specific test case template to the team's definition of done so future stories cannot be marked complete without checking that edge case. On the exam, when a defect recurs, favor answers that address the underlying process over answers that only correct the immediate instance.
Schedule Development, Baselining, and Variance Response
In predictive projects, schedule development typically involves sequencing activities, estimating durations, and identifying the critical path, the longest sequence of dependent activities that determines the shortest possible project duration; delay to any activity on the critical path delays the whole project, while activities with float can slip somewhat without effect. Once approved, the schedule becomes a baseline against which actual progress is measured, and deviations are assessed through variance analysis, sometimes formally through earned value management, which compares planned work, actual work performed, and actual cost incurred. In adaptive projects, the schedule concept shifts to velocity, the amount of backlog work a team completes per iteration, typically measured in story points or similar relative units. Velocity is used to forecast how many more iterations are likely needed to complete a given amount of remaining backlog, and a sudden drop in velocity is a signal worth investigating rather than ignoring, since it may indicate a blocked team member, unclear requirements, or scope creep within stories. A key situational skill is knowing how to respond to variance rather than just detecting it: minor variance within tolerance thresholds may simply be monitored, but variance that threatens the baseline typically calls for root-cause analysis and, if needed, a corrective action or a formal change request rather than silently reworking the plan. Consider Halima, a scrum master, who observes the team's velocity drop from thirty-two points to eighteen points in one sprint. Rather than assuming the team is underperforming, Halima investigates and discovers a key team member was pulled onto a production incident for most of the sprint. The corrective step is addressing the resourcing conflict, not simply demanding the team work harder next sprint.
Evaluating and Communicating Project Status
Reporting status well means giving stakeholders an accurate, digestible picture of where the project stands, not just a summary of activity. Common tools include burndown charts, which show remaining backlog work over time in adaptive projects, burnup charts, which show completed work against total scope and can reveal scope growth that a burndown chart might mask, and dashboards summarizing schedule, cost, risk, and quality indicators together. A status report is only as useful as it is honest; a persistent exam theme is that a project manager who discovers bad news, such as a missed milestone or a budget overrun, should communicate it promptly and transparently rather than delaying disclosure in hopes of a recovery. Metrics should also be chosen to reflect what stakeholders actually need to know and to support decisions, not simply because they are easy to produce; a report full of activity counts that does not indicate whether the project will hit its objectives is not truly informative. Consider Oscar, managing a marketing platform rollout, who discovers midway through a reporting period that a vendor delay will likely push the go-live date by three weeks. Rather than waiting for the next scheduled steering committee meeting two weeks away, Oscar raises the issue immediately with the sponsor, along with options for responding to it. On the exam, when a scenario describes a project manager sitting on unfavorable information until the next routine report, that is almost always the wrong path; timely, transparent communication of both good and bad status is the expected standard.
Managing Closure, Transition, and Retrospectives
Closing a project or a phase is a deliberate process, not something that simply happens when the work runs out. Closure activities typically include confirming that all deliverables meet acceptance criteria, obtaining formal sign-off, finalizing contracts and procurement records, releasing team members and resources, archiving project documents and lessons learned, and completing knowledge transfer to whoever will operate or maintain the result going forward. Transition readiness means checking, before closure, that the receiving team, whether operations, support, or a customer, is actually prepared to take over, which may include training, documentation handoff, or a defined support period. Retrospectives, held at the end of a phase, release, or project, are structured reflections on what went well, what did not, and what should change going forward; their value depends on psychological safety, since a retrospective where people are afraid to name real problems produces only surface-level findings. A common exam trap is skipping or rushing closure activities under time pressure, particularly lessons-learned capture, because the immediate pressure to move on to the next assignment feels stronger than the long-term value of documenting what was learned. Consider Priya again, now finishing the claims-processing project from earlier in this guide. With the team eager to move to their next assignment, there is pressure to skip the retrospective. Priya holds a short one anyway, capturing that unclear acceptance criteria caused rework twice, and files that lesson where the next project's planning team will actually see it. On the exam, look for answers that complete proper closure and capture lessons learned even under time pressure, rather than answers that treat closure as optional once deliverables are handed over.
Key terms
- Contingency reserve
- — Budget set aside for known, identified risks, sized by their probability and impact and typically managed by the project manager.
- Management reserve
- — Budget set aside for unforeseen work within scope, controlled by management or the sponsor and accessed through formal request.
- Critical path
- — The longest sequence of dependent activities in a schedule network, which determines the shortest possible project duration.
- Float (slack)
- — The amount of time an activity can be delayed without delaying the project's overall finish date or a subsequent milestone.
- Earned value management (EVM)
- — A method of measuring project performance by comparing planned work, actual work completed, and actual cost incurred.
- Velocity
- — The amount of backlog work, typically measured in story points, that an agile team completes on average per iteration.
- Burndown chart
- — A chart showing remaining work over time in an iteration or release, used to track progress toward completion.
- Burnup chart
- — A chart showing completed work against total scope over time, useful for revealing scope growth.
- Definition of done
- — The team's agreed checklist of conditions a work item must satisfy before it can be considered complete.
- Retrospective
- — A structured, recurring reflection session where a team examines what went well, what did not, and what to change going forward.
- Transition readiness
- — The state of preparedness of a receiving team or customer to take over operation, support, or maintenance of a project's deliverables.
Exam tips
- Distinguish contingency reserve (for known, identified risks, PM-controlled) from management reserve (for unknown-unknowns, sponsor-controlled) — the exam often signals which one by whether the risk was 'previously identified.'
- A dropping velocity or a schedule variance should trigger investigation into root cause before any corrective action; do not assume the team is simply working less hard.
- When a defect or issue repeats across iterations or phases, favor process-level fixes (updating the definition of done, adjusting a checklist) over one-time patches.
- Bad news about cost, schedule, or quality should be communicated as soon as it is known, not held for the next scheduled status meeting.
- Closure and retrospectives should happen even under time pressure to move to the next project; treat 'skip the retrospective, we're out of time' as a tempting but usually wrong answer.