How should I choose between predictive, agile and hybrid delivery?

Assess how stable the requirements are, how costly change would be, how often stakeholders can provide feedback and whether work has fixed dependencies or approvals. A regulated installation with defined acceptance criteria may suit predictive planning. A customer interface with uncertain needs may benefit from short feedback cycles. If both are present, a hybrid plan can set fixed approval points while allowing iterative design within them. Reassess the choice when the evidence changes.

What is the difference between a deliverable, an outcome and a benefit?

A deliverable is something the project produces, such as a scheduling system. An outcome is the change that follows its use, such as faster appointment booking. A benefit is the value of that change, such as fewer abandoned bookings or lower operating cost. Completing the system confirms delivery; adoption and performance measures show whether the intended benefit is occurring. Agree on those measures and their owners before treating completion as success.

When does a project risk become an issue?

A risk is an uncertain event that could affect objectives. An issue is a condition that has already occurred or currently blocks work. If a supplier might miss a delivery, record and monitor a risk with a response trigger. Once the supplier confirms the missed shipment, manage the delay as an issue: assign an owner, assess the schedule impact, act through the agreed escalation path and update the remaining supplier risk.

PMP Study Guide: People, Process and Business Value

Start with concept 1 Choose a topic

A project manager makes decisions with incomplete information, competing expectations and limited resources. For the PMP, study the reasoning behind those decisions: establish a shared outcome, choose a delivery approach that fits the work, make tradeoffs visible and check whether the result creates value. This guide moves from leading people to managing delivery and then to governance, risk and the wider business environment. Each concept pairs a decision rule with a concrete situation so you can see what evidence changes the next action. Predictive, agile and hybrid practices appear throughout because a project may need different controls for different parts of its work. Pay particular attention to the difference between finishing a deliverable and achieving the outcome it was meant to support.

People

1. Build a shared project vision

A project vision describes the change people expect to experience, not simply the output the team will deliver. Start by asking each key stakeholder what problem matters, who experiences it, and what improvement would count as success. Then write one outcome statement that can guide choices when requests compete. Pair it with a small set of measures, including a measure of use and a measure of the intended benefit. Check that stakeholders interpret the statement in the same way; agreement on words alone can hide different expectations. During delivery, use the vision to test whether proposed work contributes to the outcome. The July 2026 PMP examination content outline identifies developing and maintaining a common vision as People work. It does not prescribe a particular vision template.

Worked example: A sponsor requests a customer portal, while service staff want fewer routine calls. The group agrees on a vision of customers completing routine requests without assistance. They track successful online completions and calls about those same requests, using the month before launch as a comparison. If the portal launches but completions remain low and calls do not fall, the output is delivered but the intended outcome is unproven.

Watch the distinction: Treating launch as success confuses a deliverable with its effect. Customers may avoid a confusing portal, so adoption and service demand must be checked after release.

Reference: [1]

2. Diagnose vision drift

Vision drift appears when teams make individually sensible choices from different assumptions about the project's purpose. Look for incompatible priorities, repeated scope arguments, or decisions justified by an old document. Trace each interpretation to its source: a sponsor statement, approval record, customer finding, or later external change. Ask what changed and whether the original outcome remains achievable and desirable. Refresh the vision with the people who own or are affected by the outcome, then assess consequences for scope, measures, commitments, and the delivery plan. Communicate the revised decision rule where work is actually selected, such as planning and review sessions. In a predictive project, a revised vision may lead to a formal change request. In adaptive work, it may change backlog priorities, subject to existing commitments.

Worked example: A service project initially emphasized fast enrollment. A later policy requires stronger identity checks, but the approval note still says speed is the chief goal. The manager confirms the conflict with compliance and service staff, revises the shared outcome to timely enrollment with complete checks, and examines which workflows must change. The team updates its measures before deciding whether the changed scope needs approval.

Watch the distinction: Repeating the old slogan will not resolve a real change in conditions. Find the conflicting assumption and update the decision criteria before asking teams to align.

Reference: [1]

3. Identify the source of conflict

Identify what people are contesting before selecting a conflict response. A task conflict concerns how work should be done; a priority conflict concerns which outcome comes first; a resource conflict concerns scarce people, equipment, or time; and a relationship conflict concerns trust or behavior. These can overlap, so separate the immediate constraint from the emotions it has produced. Hear each party's account, verify dates and dependencies, and ask what would happen if either request were delayed. The first intervention might be sequencing work, changing a decision rule, or clarifying authority. Facilitation is more useful when the parties can jointly explore options; escalation is appropriate when a decision lies outside their authority. Address harmful behavior even when a resource shortage helped trigger it. Record the agreement and check whether the conflict recurs.

Worked example: Two specialists accuse each other of blocking testing. Their plans show that both need the same laboratory on Tuesday, and each test takes a full day. The immediate constraint is laboratory capacity, not evidence of a personal dispute. The manager confirms both deadlines, checks for another available day, and sequences the tests with the affected owners. A separate conversation addresses any disrespectful conduct.

Watch the distinction: Calling every heated disagreement a personality problem misses the constraint that caused it. Resolve the verified work or resource issue while addressing unacceptable behavior directly.

Reference: [1]

4. Resolve conflict through interests

Positions state preferred solutions; interests explain the needs beneath them. When people appear deadlocked, ask each side what risk it is trying to prevent and what evidence would make another option acceptable. Restate the interests without judging them, generate options together, and test each option against operational, technical, and contractual constraints. Choose a resolution that specifies actions, owners, timing, and a way to detect failure. This turns an agreeable conversation into an executable decision. Collaboration often yields a more durable answer than imposing a compromise that leaves both underlying risks untouched, but urgency or authority limits may require escalation. After implementation, review actual results and reopen the agreement if its assumptions fail. Do not treat agreement as permanent proof that the risk has disappeared.

Worked example: Operations fears a service outage; developers want to release a completed feature. They agree to deploy first at one low-volume site. Operations defines acceptable error signals, developers prepare a rollback, and both attend the review after the initial run. Expansion occurs only if the agreed signals pass. This preserves a route to release while giving operations evidence before wider exposure.

Watch the distinction: Splitting the difference mechanically can leave both needs unmet. A smaller release is useful here because it tests service stability and creates a controlled path to deployment.

Reference: [1]

5. Use and enforce team ground rules

Ground rules make expected team behavior observable. Agree on practical rules for reviews, response times, meetings, decisions, and disagreement, including why each rule protects the work. Keep them accessible and apply them consistently across roles. When someone breaches a rule, establish the facts and impact first. Discuss a first or limited violation privately, invite the person's explanation, and agree on a corrective action. Escalate repeated or serious conduct through the appropriate people process while protecting confidentiality. Also test whether the rule is clear and workable; frequent breaches can indicate a flawed workflow. If the team changes a rule, record the new version and communicate it. A rule helps only when members can recognize compliance and trust that exceptions receive fair treatment.

Worked example: A developer repeatedly sends changes directly to deployment, bypassing the team's review channel. The manager privately confirms why this happened and explains the missed defect check. The next change goes through review, and the team clarifies who covers reviews during absences. The updated rule names a backup reviewer, so a valid need for speed no longer depends on bypassing the control.

Watch the distinction: Public blame may damage trust without restoring the review step. Address the behavior and its impact promptly, then check whether the rule needs a practical exception.

Reference: [1]

6. Adapt leadership to team needs

Leadership style should respond to the team's capability, confidence, and the consequence of error for the specific work at hand. Give clear direction when a task is unfamiliar or tightly controlled. Coach when people can perform much of the work but need to reason through a new decision. Delegate when they have the skill and authority to decide, while agreeing on the outcome and review points. These choices can differ within one project and even for the same team. An experienced team may need little help with product design yet substantial guidance on a new approval obligation. Observe whether decisions are accurate and timely, then adjust support. Delegation transfers decision space, not accountability for required oversight or sign-off. Conversely, excessive direction can slow capable contributors and hide useful expertise.

Worked example: A product team has delivered similar interfaces before but has never assembled evidence for a safety approval. The project manager lets the team choose routine design details, arranges coaching with the safety specialist, and schedules an evidence review. The designated approver retains sign-off. This matches support to the unfamiliar approval work without taking ordinary design decisions away from the team.

Watch the distinction: One leadership style does not fit every task. Product experience supports design autonomy, but it does not establish competence or authority to approve unfamiliar safety evidence.

Reference: [1]

7. Empower decisions within boundaries

Empowerment works when people know both the decisions they can make and the boundary beyond which they must escalate. Define the objective, available resources, constraints, decision owner, and signals that trigger a review. Make the limits concrete: a team might change story order inside an agreed release goal but cannot alter a contractual date. Provide timely access to information, since nominal authority is useless when the team lacks the facts needed to act. Review outcomes rather than requiring approval for every small choice. If a proposed action crosses a boundary, present options and impacts to the named authority instead of letting work stall silently. Revisit the boundary as risk or capability changes. Clear authority supports initiative while preserving control over commitments made outside the team.

Worked example: A product team learns that customers struggle with password reset. It moves that story ahead of a cosmetic change while retaining the agreed release goal and date. Later, a proposed redesign would delay a contractual delivery date. The team estimates the delay and benefit, then takes the decision to the sponsor named in its decision rules. Routine reprioritization proceeds; the external commitment receives review.

Watch the distinction: Empowerment does not mean every team decision is unrestricted. If changing a commitment exceeds delegated authority, the team should explain the impact and seek the proper decision.

Reference: [1]

8. Clarify roles and accountability

A role description should distinguish who performs work, who answers for its result, who provides specialist input, and who accepts the deliverable. A responsibility matrix can expose gaps and overlaps, but its value lies in the conversation that resolves them. For each important result, name a clear accountable owner and define what completion evidence that person must assemble. Identify contributors and the stakeholder with authority to accept the outcome; accountability for delivery and authority to accept can belong to different people. Check interfaces between teams, since work often fails where each side assumes the other owns a handoff. Revisit assignments when scope or team membership changes. Requirements techniques in a business analysis study guide can help clarify acceptance needs, but the project still needs explicit delivery ownership.

Worked example: Two engineers are assigned to migrate customer records, but neither owns acceptance. The manager names one migration lead to coordinate reconciliation and evidence. Both engineers perform extract and load work; testers check record counts and samples; the data owner approves the migrated data against agreed criteria. The handoff is complete only when the evidence and approval are recorded, not when the load script finishes.

Watch the distinction: Assigning several people to do the work does not identify who ensures its result is ready. Explicit accountability prevents an acceptance gap at the handoff.

Reference: [1]

9. Draw on varied team perspectives

Different perspectives reveal assumptions that a technically capable group may share without noticing. Identify whose experience touches the proposed change: users, support staff, operations, security specialists, and people affected indirectly. Invite concrete observations and ask what conditions make the current design fail. Test the concern with a scenario or prototype rather than treating every suggestion as a requirement. Record the resulting decision and the evidence behind it, especially when a tradeoff remains. Make room for quieter contributors before a dominant view becomes the default. Varied viewpoints improve decisions when the team integrates them into design and validation, not merely when attendance lists look diverse. A project manager should also notice whose absence could systematically hide an important operating condition.

Worked example: Developers design a sign-in flow that keeps a user logged in for convenience. A frontline colleague explains that customers often use shared devices. The team tests a shared-device journey, finds that personal details remain visible to the next user, and changes the session behavior. It then checks the revised flow with customers before finalizing acceptance criteria. The colleague exposed a context the developers had not modeled.

Watch the distinction: A design that works on each developer's device may fail in the user's setting. Seek the missing operating perspective and test its implications before declaring the solution ready.

Reference: [1]

10. Solve team problems systematically

A useful problem-solving sequence begins with a specific gap between expected and observed results. Define its size, location, and timing before proposing a cause. Gather a small sample of records or observations, compare cases where the problem occurs with cases where it does not, and test plausible explanations. Select an action that addresses the supported cause, assign an owner, and choose a measure that can reveal whether the action worked. Keep immediate containment distinct from a lasting process change. If the measure does not improve, revisit the diagnosis instead of adding more controls at random. Scenario practice can reinforce this sequence: PMP practice questions are most useful when you explain why the chosen action targets the evidence. A cleanly stated problem makes that reasoning possible.

Worked example: Handoff defects rose from 3 to 9 per cycle. The manager reviews the nine recent cases and finds that seven lack acceptance notes, while earlier handoffs usually included them. The team adds a short note checklist and checks the next comparable cycle. If handoff defects fall to 4, that is an improvement of 5 from the recent cycle, though more cycles are needed to judge durability.

Watch the distinction: A checklist is not automatically the answer to rising defects. First locate the defect pattern, then measure whether the selected fix reduces it.

Reference: [1]

11. Represent the team accurately

Representing the team means conveying its assessment faithfully to people who control priorities or resources. Ask contributors for estimates, assumptions, dependencies, and confidence before presenting a recommendation. Separate observed facts from forecasts and explain what would change the forecast. Offer feasible options with consequences, such as a smaller release or a later date, rather than promising an outcome the team has not assessed. State where the decision belongs and record it. Bring the decision back to the team so planning reflects what was actually authorized. This role also protects upward communication: a sponsor should hear material uncertainty early, while the team should hear the sponsor's objective without it being recast as an unqualified command. Accurate representation can preserve trust even when stakeholders dislike the available choices.

Worked example: A sponsor asks for release two weeks earlier. The team estimates that keeping all features requires the original date, and a vendor interface is still unconfirmed. The manager presents two choices: keep the date and full scope, or release the verified core earlier and schedule the remaining feature after integration. The sponsor chooses the smaller release. The manager returns that decision to the team for a revised plan.

Watch the distinction: Agreeing to an earlier date before checking the team's evidence creates a promise without a credible plan. Present the dependency and viable choices first.

Reference: [1]

12. Find affected stakeholders

Stakeholders include people who authorize work, supply resources, perform it, use its outputs, influence acceptance, or experience its effects. Begin with the business process and trace each output through its users and downstream handoffs. Ask who gains, loses, approves, operates, supports, or could block the change. Add external parties where their decisions or experience matter. Record each stakeholder's interest and the specific project decision that may need their input; a list of names alone does little. Revisit the map when scope changes or a prototype reveals an overlooked group. Consider indirect users carefully: they may never log into the new system yet still depend on the timing or accuracy of its data. Early discovery reduces late requirements surprises and improves the fairness of tradeoffs.

Worked example: A warehouse system's initial register lists the sponsor, warehouse staff, and software supplier. During workflow mapping, the manager learns that drivers rely on dispatch times produced by the system. Drivers are added as affected stakeholders. Interviews reveal that late schedule changes cause missed collection slots, so dispatch timing becomes an explicit requirement before the design is accepted.

Watch the distinction: Limiting the register to funders and direct users omits people affected downstream. Follow outputs through the full workflow to find consequential stakeholders.

Reference: [1]

13. Set stakeholder engagement priorities

Engagement effort should reflect more than a person's title. Assess influence over decisions, degree of impact, current support, information needs, and how quickly their position could change. A highly influential approval body may need structured evidence at planned gates; people with little formal power may need close involvement because usability or adoption depends on them. Decide the desired engagement state for each group, then choose actions that move from the current state toward it. Review the assessment as new concerns or decisions arise. Do not equate frequent messages with useful engagement: a prototype session can reveal more than repeated status emails. Likewise, withholding detail from a powerful stakeholder can create avoidable late objections. The aim is timely input and informed decisions, with effort proportional to consequence.

Worked example: A regulator must review evidence before opening, so the manager schedules evidence reviews and tracks unresolved requests. Occasional users cannot approve the opening, but they face a redesigned booking flow. The team invites them to test a prototype and records failed tasks. These different activities match each group's decision role and impact; giving both groups the same status email would serve neither well.

Watch the distinction: Low formal influence does not mean low project importance. Users can expose adoption failures, while approval bodies need the evidence required for their decisions.

Reference: [1]

14. Tailor communication to the audience

Communication is useful when its recipient can understand and act on it in time. For each audience, identify the decisions it makes, the detail those decisions require, the preferred channel, and the latest useful delivery point. Executives often need exceptions, options, and requests for decisions; implementers need changing specifications, interfaces, and owners. Specify who prepares each message and where its authoritative version lives. Include a feedback route so recipients can correct errors or raise missing information. A report cadence should fit the speed of change: an urgent interface change cannot wait for a monthly summary. Test communication by asking recipients what they understood and whether it supported a decision. If they still rely on informal side channels, revise the content, timing, or format instead of simply sending more.

Worked example: An integration team receives a daily interface change log with version, owner, and test impact. Executives receive a monthly summary of milestone confidence and decisions needed. When an interface change threatens the next milestone, the manager sends an immediate exception update to the affected decision makers. A named contact collects corrections, and the next published log reflects them.

Watch the distinction: Sending everyone the same detailed report can bury urgent decisions and still leave implementers short of specifics. Tailor content and timing to the action required.

Reference: [1]

15. Build trust through visible follow-through

Trust grows when claims can be checked and commitments are followed through. Ask stakeholders what experience drives their concern, then show relevant evidence, remaining uncertainty, and the planned response if assumptions fail. Make commitments specific enough to verify: who will provide a test result, by when, and what decision it informs. Report missed commitments promptly, with a corrective action. Invite affected people into meaningful reviews so their knowledge can change the decision, not just witness it. Transparency includes tradeoffs; a favorable test result should not conceal a failed readiness condition. Over time, consistent behavior makes influence easier because stakeholders can distinguish a sound recommendation from an unsupported assurance. Trust does not require agreement with every request, but it does require explaining decisions and closing the loop.

Worked example: A department doubts a migration after a previous outage. The manager shares the latest reconciliation results, the remaining failed test, and the rollback conditions. Its representative attends the readiness review. Because the failed test is a stated release condition, deployment is deferred and a retest date is recorded. Reporting that failure as promised strengthens the basis for the later decision.

Watch the distinction: A confident statement that migration is safe cannot replace readiness evidence. Disclose failed criteria and act on the agreed response, even when that delays deployment.

Reference: [1]

16. Align competing expectations

Competing expectations often arise because stakeholders use different definitions of success. Make each definition explicit, including the benefit sought, the risk feared, and the deadline or quality condition that matters. Separate essential conditions from preferences, then test options against available capacity and the project's outcome. Facilitate a decision on the smallest coherent set of work that meets the essential conditions. Record acceptance criteria, deferred work, and who owns later prioritization. Avoid presenting deferral as a promise that every requested feature will eventually be built; later choices should use evidence of customer value. Recheck alignment at reviews because needs can change during delivery. A durable agreement specifies what will be released, what will be measured, and what would justify changing the plan.

Worked example: Sales asks for eight launch features; support says only five have stable help procedures. The group identifies three features essential to the launch outcome and gives them explicit acceptance and support criteria. Two more proceed only if they pass the same readiness checks. The remaining three return to the backlog for ranking after customer feedback. Both groups agree on the launch decision rule rather than an unsupported promise of all eight.

Watch the distinction: Calling every requested feature essential avoids the tradeoff and can undermine release stability. Define the minimum useful launch and the evidence needed for later additions.

Reference: [1]

17. Use mentoring to close capability gaps

Mentoring closes a capability gap when the learner performs the work and receives feedback, rather than merely watching an expert. Define the skill needed and the decision or deliverable that will demonstrate it. Pair the contributor with someone experienced in that specific skill, agree on a short progression from observation to supported practice to independent practice, and protect time for review. Give feedback on observable behaviors and results. Check transfer by having the learner explain choices or complete a similar task, then adjust support if needed. Mentoring also benefits the project by reducing dependence on one specialist. It should complement, not blur, decision rights: the learner can lead an activity while a required approver still authorizes its outcome. Capture reusable methods where future contributors can find them.

Worked example: A new analyst can draw process maps but has not facilitated a workshop. An experienced facilitator models how to handle conflicting requirements in the first session. The analyst leads the next workshop, records decisions and open questions, and receives feedback on whether each decision has an owner. A later session without the mentor tests whether the skill transferred.

Watch the distinction: Assigning a mentor's name does not prove learning occurred. Give the contributor a chance to perform the task and review evidence of independent capability.

Reference: [1]

18. Monitor customer expectations

Customer expectations concern the experience and result promised by the project, which can differ from whether a release passed its acceptance tests. Identify internal and external customers and record what each expects the change to improve. Combine direct feedback with behavior measures that reveal friction, such as completion rates, delays, or repeated support contacts. Segment findings when one group has a distinct experience; an overall average can conceal a serious gap. Compare the evidence with the promised outcome, investigate the cause with the product owner and affected customers, and reprioritize work through the chosen delivery approach. Keep monitoring after a fix, since satisfaction can lag a technical change. Meeting a release criterion establishes that agreed work was delivered; it does not by itself establish that the customer's problem was solved.

Worked example: A checkout update passes its agreed tests, but complaints about slowness rise. Journey data show that mobile customers pause at address entry and abandon orders more often there than desktop customers. The product owner prioritizes a shorter mobile address flow and tests it with users. The team then checks completion and complaint trends before claiming the checkout outcome improved.

Watch the distinction: Passing release tests does not settle whether customers received the promised benefit. Examine their journey and response, then verify that the improvement changes actual use.

Reference: [1]

19. Transfer critical project knowledge

Critical project knowledge is information whose loss would delay delivery, weaken decisions, or make the output hard to operate. Find single-person dependencies, unusual interfaces, undocumented assumptions, and recovery steps that rarely get practiced. Choose a transfer method suited to the knowledge: a decision record for reasoning, a runbook for repeatable operations, paired work for tacit skill, or a demonstration for failure recovery. Identify the recipient and when that person will need the knowledge. Verify transfer through a teach-back or supervised execution, since storing a document is weaker evidence than successful use. Keep material accessible and current as the system changes. Before closure, confirm operations can recognize failure signs, execute the agreed response, and find the right escalation contact without relying on the original project specialist.

Worked example: Only one engineer understands a legacy interface. The engineer walks a successor through normal processing and two common failure signs, then records recovery steps and contact points. Under supervision, the successor diagnoses a staged failure and restores processing. The team corrects an unclear instruction found during the exercise. The handover is evidenced by successful use, not by the existence of a document alone.

Watch the distinction: A folder of notes cannot show that successors can recover a failing interface. Have another person perform the essential task and correct gaps found during that exercise.

Reference: [1]

20. Create a communication feedback loop

A communication strategy needs a way to learn whether its reports reflect reality and support decisions. Define what each report is meant to reveal, where its data comes from, who reviews it, and how recipients can challenge it. Invite feedback from people close to the work and compare their observations with status metrics. When a discrepancy appears, reconcile definitions and records before repeating a status label. Add the missing measure or explanation, assign an owner to the underlying issue, and show its trend in later reports. Feedback should change both the project response and, when needed, the reporting method. A status color is a summary, not evidence by itself. If people repeatedly discover problems outside the formal report, the reporting loop is failing even if the document arrives on time.

Worked example: The weekly report marks integration green, while users describe unresolved errors. The manager checks the issue log and finds six open errors, two of which block a key workflow. The next report shows the count, affected workflow, owners, and recovery dates, and changes the status assessment. A named feedback channel lets users challenge future reports before a misleading green label persists.

Watch the distinction: Publishing reports on schedule does not make them accurate. Reconcile conflicting evidence, show material issues, and use stakeholder feedback to improve the next report.

Reference: [1]

Process

21. Select a delivery approach

Choose the approach by examining how much can be specified now and how cheaply the team can learn later. Predictive planning suits work with stable requirements, costly changes, and ordered approvals. Adaptive delivery suits uncertain needs when a usable increment can generate frequent feedback. Hybrid delivery combines these patterns, but its interfaces need explicit dates, specifications, and decision owners. Map dependencies before selecting an approach: an experimental software feature may still rely on a fixed installation or approval. Also ask what evidence stakeholders need to authorize spending and accept results. The PMP examination content outline includes predictive, adaptive, and hybrid approaches across its domains. The useful decision is how to manage each part of the work and its connections, rather than applying one method uniformly.

Worked example: A housing project needs approved structural foundations before tenants can move in, but the tenant app's most useful features are uncertain. The manager schedules foundation design, approval, and construction as dependent predictive work. The app team tests features in short iterations. At each integration checkpoint, both teams confirm building access, network readiness, and the app functions needed for opening. App feedback can change features without silently moving the approved construction sequence.

Watch the distinction: Calling the whole project agile because it contains an app ignores fixed approvals and physical dependencies. Assign an approach to each work stream and manage their interfaces.

Reference: [1]

22. Integrate plans and dependencies

An integrated plan connects deliverables, activities, resources, costs, risks, communications, and approvals so a change in one area is visible elsewhere. Begin with the intended outcome and scope, then identify work packages or backlog releases and the conditions each needs to start. Record dependencies with an owner, required output, and expected date. Check whether resource calendars and procurement lead times support the schedule. A milestone list alone may hide a training course that depends on a working environment, approved materials, and available instructors. Review the plan with the people responsible for those inputs, then reconcile conflicting dates. During delivery, assess the effect of new information on the whole plan, including continued business value. A local schedule improvement is not useful if it creates an unstaffed handover or an unapproved cost increase.

Worked example: Training is booked for week 6, while the test environment will be validated at the end of week 7. The course needs that environment for exercises, so week 6 is infeasible. The manager moves training to week 8, confirms instructor and learner availability, and updates both teams' schedules. If the later course affects launch readiness, that downstream milestone is reforecast too.

Watch the distinction: Updating only the training calendar leaves the integrated plan inconsistent. Trace the dependency through resources, readiness, and downstream milestones before communicating the revised date.

Reference: [1]

23. Estimate effort and resources

Effort is the amount of work, commonly expressed in person-hours; duration is elapsed working time. Estimate effort from the deliverable, past comparable work, and assumptions about complexity. Then divide shareable effort by realistic available capacity, not by the number of names assigned. Account for meetings, other commitments, holidays, and any specialist or equipment bottleneck. Adding people may not shorten work that must be sequential or requires coordination and review. State the estimate's uncertainty and what would change it, such as poor source data or a delayed approval. For adaptive work, use observed throughput when items are sufficiently comparable; for unfamiliar work, a range or short discovery task may be more honest than a single precise duration. Recheck the estimate when actual performance exposes a faulty assumption.

Worked example: A data cleanup is estimated at 80 person-hours. Two analysts can each devote 20 hours per week, giving 40 person-hours of weekly capacity. If the records can be split evenly and review time is already included, estimated duration is 80 ÷ 40 = 2 weeks. If one analyst alone must perform final reconciliation, that separate dependency needs its own duration estimate.

Watch the distinction: Dividing 80 hours by two full-time workers assumes 80 hours of weekly capacity. Their actual combined availability is 40 hours, so that shortcut halves the duration incorrectly.

Reference: [1]

24. Revise plans using evidence

A plan is a set of assumptions to test against delivery evidence. Compare actual completion with the forecast using consistent definitions of finished work; started or unaccepted items should not inflate throughput. Investigate whether a gap reflects temporary disruption, underestimated complexity, capacity loss, or a changed scope mix. For adaptive work, observed throughput can forecast remaining iterations, but the estimate should show its assumptions and uncertainty. For predictive work, revise the current forecast while preserving the approved baseline until an authorized change occurs. Reconcile schedule, resource, and financial effects in the integrated plan, then tell affected stakeholders what decision is needed. An apparently faster team may still miss a milestone if a dependency, approval, or scarce specialist sets the finish date.

Worked example: A team expected 30 accepted items per month but completed 18 and 20 in two comparable months. Its observed average is (18 + 20) ÷ 2 = 19 items per month. With 76 similar items remaining, the working forecast is 76 ÷ 19 = 4 months, rather than about 2.5 months at the original rate. The manager checks why throughput fell and updates dependent forecasts.

Watch the distinction: Keeping the 30-item rate because it remains in the original plan confuses a target with evidence. Reforecast using comparable completed work and explain any reason to expect improvement.

Reference: [1]

25. Define the scope boundary

A scope boundary describes the deliverables, their exclusions, and the criteria for acceptance. Start with stakeholder needs, translate them into observable requirements, and confirm that the resulting scope supports the project objective. Explicit exclusions matter where adjacent functions are easy to assume. Trace each agreed requirement to a deliverable and acceptance check so the team can detect both missing work and unrequested additions. In predictive delivery, a change to the approved scope is assessed for effects on schedule, cost, risk, and benefits before authorization. In adaptive delivery, details may evolve in the backlog within agreed product goals, while external commitments still require appropriate control. The business analysis guide offers related practice in clarifying requirements. A well-drawn boundary supports negotiation; it does not prevent stakeholders from proposing new work.

Worked example: A payment project includes online refunds to the original card and excludes store-credit refunds. Acceptance requires an authorized user to issue a card refund and see its status in the transaction record. Midway through delivery, a retailer requests store-credit refunds. The manager records it as a new requirement, assesses design and testing effects, and routes the decision through the agreed scope process before adding it.

Watch the distinction: Treating a reasonable request as automatically included invites hidden work. Check the agreed deliverables and exclusions, then assess and authorize any genuine scope addition.

Reference: [1]

26. Break scope into manageable work

Break agreed scope into pieces small enough to estimate, assign, and verify. A deliverable-oriented work breakdown structure starts with the final outputs and decomposes them into components and work packages; its parts should cover the agreed scope without duplicating it. Each work package needs a clear result and completion evidence, not merely an activity label such as “work on migration.” Decomposition reveals missing interfaces, specialist needs, and estimates that are too broad to defend. Stop when a responsible team can estimate and control the package at a useful level; excessive detail raises maintenance effort. In adaptive delivery, a product backlog serves a different planning function: items can be refined as learning increases. Either way, connect the work to acceptance criteria and account for integration work between components.

Worked example: A customer-data migration is divided into extraction, cleansing, loading, and reconciliation. Extraction ends with a readable source file; cleansing ends with documented corrections; loading ends with records in the target system; reconciliation ends with approved counts and exception handling. Owners estimate each package, then add the dependencies between them. The team can now report completed results instead of a vague percentage for “migration.”

Watch the distinction: A list of activities is not enough if nobody can verify their outputs. Define what each package produces and how its completion will be demonstrated.

Reference: [1]

27. Validate completed scope

Quality control and scope validation answer different questions. Quality checks examine whether a deliverable meets technical requirements and whether defects remain. Scope validation asks the authorized stakeholder to accept the completed deliverable against agreed acceptance criteria. Passing internal tests can provide evidence for acceptance, but it cannot replace the stakeholder's decision. Identify criteria early, make them testable, and keep a record of results and exceptions. If a deliverable fails, determine whether the team omitted agreed scope, produced a defect, or encountered a new expectation. That classification guides correction or change control. In adaptive work, frequent reviews can surface acceptance problems early, provided the person giving feedback has clear authority and the team records what was accepted. Formal sign-off may still be needed for a contractual milestone.

Worked example: A reporting team verifies that totals match source transactions, but the agreed acceptance criteria also require filtering by region. The report passes its arithmetic test yet remains incomplete against scope. The team adds the filter, tests totals for each region, and demonstrates both functions to the sponsor. The sponsor can then accept the report against the original criteria, with the decision recorded.

Watch the distinction: A defect-free technical test does not prove that all promised functions were delivered. Compare the result with acceptance criteria before asking the stakeholder to approve it.

Reference: [1]

28. Map outputs to benefits

Value requires a chain from output to use to outcome. A project may deliver a working tool, yet the intended benefit depends on people adopting it, changing their process, and sustaining the change. Name the benefit owner, baseline, measure, target, data source, and review date. Separate measures of production, such as invoices generated, from measures of effect, such as processing time or errors. Consider outside causes: volume, case complexity, and staffing can change a metric even if the tool has no effect. A benefits map makes these assumptions visible and gives the team a reason to adjust delivery priorities when expected value weakens. The project manager can establish measurement and transition arrangements, while an operational owner often continues measurement after the project closes. Completion on time is only one part of judging success.

Worked example: An invoicing project delivers automation, and Finance owns adoption. Manual processing averaged 10 minutes per invoice before launch; the agreed target is 6 minutes for comparable invoices after use stabilizes. The measured reduction would be 10 − 6 = 4 minutes per invoice, or 40% of the original time. Finance must collect post-launch timings before claiming that benefit; installing the software alone proves none of it.

Watch the distinction: Counting installed licenses as the processing-time benefit skips adoption and actual use. Measure the outcome against a suitable baseline after the workflow changes.

Reference: [1]

29. Prioritize work by value

Prioritization compares what work is expected to achieve with the capacity it consumes. Estimate benefit, effort, urgency, risk reduction, dependencies, and stakeholder feedback on consistent scales. A value-to-effort ratio can help when capacity is scarce, but it does not capture a mandatory obligation, an enabling dependency, or a severe risk. Check whether candidate items are similarly sized and whether the benefit estimate is credible. In adaptive delivery, the product owner can reorder backlog items as evidence arrives, while the team explains technical dependencies and capacity. For a predictive release, changing priorities may alter the approved scope or milestone and require a decision through governance. Revisit the ranking when user evidence changes rather than preserving an old order for its own sake.

Worked example: With equal delivery risk and no dependencies, feature A offers 80 hypothetical value units for 20 effort units; feature B offers 60 for 30. A's ratio is 80 ÷ 20 = 4 value units per effort unit, while B's is 60 ÷ 30 = 2. If capacity is the binding constraint, A is the stronger first choice. A mandatory deadline for B would require a separate priority check.

Watch the distinction: The highest ratio is not an automatic choice. Verify mandatory work, deadlines, dependencies, and the uncertainty of the value estimates before committing capacity.

Reference: [1]

30. Deliver value in increments

An increment should let users complete a meaningful task and produce evidence about value. Choose a narrow end-to-end slice, including the interface, processing, support, and measurement needed for actual use. A partial component hidden from users may reduce technical risk, but it will not test the intended customer outcome. Set a hypothesis and success measures before release, then compare use, errors, and feedback with expectations. Limit the initial audience when that contains operational risk without making the findings unusable. Decide whether to expand, improve, or stop based on what the increment shows. This approach is especially useful when requirements are uncertain, but each release still needs appropriate quality and approval checks. Incremental delivery also helps expose integration problems before a large final launch.

Worked example: A service team first releases online appointment changes at one branch, leaving new bookings for later. Customers can complete a full change, and staff can see the updated schedule. During a hypothetical first month, 120 change attempts produce 96 successful self-service changes, a completion rate of 96 ÷ 120 = 80%. The team examines the 24 failures before choosing the next increment.

Watch the distinction: Releasing half of a workflow does not necessarily create customer value. Select a small task users can finish, then measure its use and problems.

Reference: [1]

31. Plan resource capacity

Resource planning matches required skills, timing, and effort with usable capacity. Begin with the work and its dependencies, then identify who or what can perform each part. Subtract existing commitments, leave, and essential support work from nominal availability. Compare demand and capacity by time period, since a monthly total can conceal a one-week overload. Skills matter as much as hours: an available developer cannot automatically replace a qualified tester or a specialized machine. When demand exceeds capacity, move work, change sequence, obtain suitable help, or revise the commitment. Check the resulting effect on the schedule and cost before promising a date. Material availability can create a similar constraint; the production and inventory management guide extends this reasoning to supply and inventory.

Worked example: A tester has 30 project hours available next week. Two planned tests need 18 and 20 tester-hours, for total demand of 38 hours. The shortage is 38 − 30 = 8 hours. If another qualified tester can take 8 hours of independent work, both may finish; otherwise the manager sequences or reschedules a test and updates its dependent milestone.

Watch the distinction: A 40-hour workweek does not mean 40 project hours are available. Use capacity after existing commitments and check whether substitute resources have the needed skills.

Reference: [1]

32. Resolve resource overload

An overloaded resource creates a schedule problem even when individual task estimates are sound. Resource leveling changes task dates to fit actual availability and may extend the finish date. Resource smoothing moves work within available float while preserving a target date, but it cannot solve an overload with insufficient float. First identify which tasks truly require the same person and whether they can be split or performed by another qualified resource. Then compare sequencing, added capacity, and reduced scope for cost, risk, and milestone effects. Recalculate dependencies after choosing an option; moving one task can shift work on a critical path. Explain the tradeoff to the decision maker when a committed date or budget is affected. Assigning simultaneous work to one person does not create more capacity.

Worked example: One specialist is assigned two independent tasks, each requiring three full working days, both scheduled for Monday through Wednesday. The demand is six specialist-days, but capacity is three. With no substitute, the manager places the lower-priority task on Thursday through the following Monday, assuming a five-day workweek. Its finish moves three working days, so any dependent milestone must be recalculated.

Watch the distinction: Showing overlapping bars on a schedule does not make one specialist available twice. Level the work or add qualified capacity, then update dependent dates.

Reference: [1]

33. Choose a procurement strategy

A build-or-buy decision compares more than acquisition speed. Define the required capability and which parts are strategically important to control. Estimate total cost, including development or license fees, integration, data migration, training, support, changes, and exit. Assess delivery urgency, supplier stability, security, intellectual property, and whether the product can meet essential requirements. A combined solution may buy a standard component while building the differentiating workflow around it. Test assumptions through demonstrations or a limited pilot, then document the evaluation criteria and ownership of supplier risks. Procurement timing itself is a dependency: selection, negotiation, and access may take longer than expected. Choose the option that best supports the intended outcome within constraints, not simply the one with the earliest advertised start date.

Worked example: An internal reporting tool would take an estimated six months to build. A commercial product could deliver core reports in two months, but needs four weeks of integration and has an annual support fee. The manager checks whether those periods overlap, verifies data access and export needs, and compares total costs over the intended use period. If the product meets mandatory needs, buying may improve delivery timing; the remaining custom workflow can be built separately.

Watch the distinction: A vendor's two-month setup estimate is not the full delivery comparison. Include integration, data obligations, support, and exit costs before selecting the option.

Reference: [1]

34. Match contract type to uncertainty

Contract structure should reflect how clearly the work can be specified and who can manage uncertainty. A fixed-price agreement offers price predictability for defined outputs and acceptance criteria; unclear scope can lead to costly disputes or change requests. A time-and-materials arrangement pays for actual time and agreed rates, allowing exploration but requiring a cap, work authorization, and frequent review. Cost-reimbursable structures place more cost uncertainty with the buyer and need clear allowable-cost rules and oversight. No contract type removes delivery risk. Define measurable outputs, reporting, change handling, and remedies regardless of price structure. For uncertain work, a discovery phase can clarify scope before committing to a later fixed-price implementation. Choose based on the nature of the work and the parties' ability to control the relevant risks.

Worked example: A supplier can price installation of 50 specified devices against drawings and acceptance tests, so the buyer seeks a fixed price for that package. The user-interface design is still exploratory. For a hypothetical 80-hour discovery phase at 2 cost units per hour, a time-based cap is 160 units. Reviews at 40 and 80 hours determine whether to continue and whether the later design can be specified.

Watch the distinction: Fixed price does not make uncertain design free of uncertainty. Poorly defined outputs can return as claims, rework, or expensive changes.

Reference: [1]

35. Evaluate bids and negotiate terms

Evaluate bids against the criteria set before offers are opened. Separate mandatory requirements from scored preferences: a low price cannot compensate for failure of a genuine minimum requirement. Check that suppliers interpreted the same scope and assumptions, and investigate unusually low bids for omissions or unrealistic staffing. For eligible bids, compare total cost, delivery capability, quality evidence, support, and risk using the agreed method. Negotiation then turns a preferred offer into enforceable obligations: define acceptance tests, dates, reporting, remedies, data rights, and change procedures. Record concessions and their cost so the final agreement can be compared with the evaluated bid. The project manager should involve procurement and subject specialists where their authority or expertise is needed. Award follows the organization's approval route.

Worked example: Two bids cover a recovery service. Vendor A prices it at 90 hypothetical cost units but cannot meet the mandatory recovery requirement; Vendor B prices it at 100 and demonstrates that it can. A is ineligible despite being 10 units cheaper. The team checks B's evidence, then negotiates how recovery will be tested, when results are due, and the remedy if the agreed test fails.

Watch the distinction: A weighted score must not let a cheap bid offset a mandatory failure. Screen minimum requirements first, then score eligible bids and negotiate measurable terms.

Reference: [1]

36. Manage supplier performance

Supplier management compares actual performance with the agreement, not with a general impression of progress. Track quantities, quality, dates, service levels, evidence, and open obligations at the review points defined in the contract. Verify what has been accepted separately from what has merely arrived. When performance deviates, record the facts, determine the effect on dependent project work, and use the agreement's notice, correction, and remedy provisions. Collaborate on a credible recovery plan while preserving the contractual record. Do not approve an incomplete milestone to keep a status report green; doing so can obscure the remaining work and affect payment rights. Conversely, a minor deviation may be handled through an agreed correction without escalating beyond its impact. Recheck performance after the corrective action.

Worked example: A supplier must deliver 100 tested devices by Friday but supplies 92. The shortfall is 100 − 92 = 8 devices, or 8% of the order. The manager verifies the 92 against acceptance tests, identifies which installations need the missing eight, checks the agreement's notice and remedy terms, and obtains a recovery date. The full-delivery milestone remains incomplete until its agreed conditions are met.

Watch the distinction: Treating shipment as acceptance overlooks testing and quantity requirements. Compare performance with the contract's actual milestone conditions before approving completion or payment.

Reference: [1]

37. Build a financial plan

A financial plan separates estimated delivery cost from allowances for uncertainty and from funds held for unforeseen work. Estimate work costs from the scope, schedule, rates, and procurement commitments. Add contingency for identified risks using documented assumptions and planned responses; this normally forms part of the cost baseline. Keep management reserve distinct from that baseline, with its use subject to the designated authority. Track commitments as well as payments so future liabilities are visible. During delivery, compare actuals and forecasts with the appropriate baseline and explain whether a variance comes from price, quantity, scope, or risk. The risk management guide provides related study of risk assessment and treatment. Reserve labels do not create money automatically: the funding plan must show what is authorized and when it is available.

Worked example: Estimated work costs are 400 hypothetical cost units. Documented contingency for identified risks adds 30, making the cost baseline 400 + 30 = 430 units. A separately authorized management reserve of 20 brings total funding to 430 + 20 = 450 units. A manager reporting against the baseline uses 430, while a funding request explains the full 450 and the separate reserve control.

Watch the distinction: Adding management reserve to the performance baseline hides the distinction between planned risk allowance and separately controlled funds. Report the baseline and total funding explicitly.

Reference: [1]

38. Interpret earned value

Earned value compares three amounts at the same review date, all expressed in the same cost units. Planned value, PV, is the budgeted value of work scheduled by then. Earned value, EV, is the budgeted value of work actually completed. Actual cost, AC, is what that completed work has cost. Schedule variance is EV − PV, and cost variance is EV − AC; negative values indicate less work than planned and spending above the budgeted value of completed work, respectively. Schedule performance index is EV ÷ PV, while cost performance index is EV ÷ AC when denominators are nonzero. These figures identify a condition, not its cause. Check completion rules, data timing, and critical dependencies before forecasting the finish date or prescribing recovery.

Worked example: At a review point, PV is 100, EV is 80, and AC is 90 hypothetical cost units. Schedule variance is 80 − 100 = −20 units; cost variance is 80 − 90 = −10 units. SPI is 80 ÷ 100 = 0.80, and CPI is 80 ÷ 90 ≈ 0.89. The project has earned less work than planned and spent more than that work's budgeted value.

Watch the distinction: A negative schedule variance is measured in cost units, not days. Investigate the schedule network before translating the earned-value signal into a completion-date forecast.

Reference: [1]

39. Forecast and govern spending

Forecast final cost by combining actual spending with a defensible estimate to complete. A bottom-up estimate to complete revisits remaining tasks, rates, contracts, and known risks; estimate at completion then equals actual cost plus that estimate. A performance-based formula may help when past cost efficiency is likely to continue, but its assumption must be stated. Compare the resulting forecast with the approved budget and identify the cause of any gap. Consider options such as reducing optional scope, changing sequence, negotiating supply costs, or requesting more funding, including their effect on value and schedule. Route decisions through the assigned financial authority and update forecasts after authorization. A budget variance is useful management information before it becomes a final overrun; early reporting preserves more choices.

Worked example: A project has an approved budget of 500 hypothetical cost units, actual spending of 250, and a revised bottom-up estimate of 300 to finish. Estimated final cost is 250 + 300 = 550 units, which is 550 − 500 = 50 units over budget, or 10% of the budget. The manager explains the remaining-work estimate and takes recovery or funding options to the authorized decision maker.

Watch the distinction: Subtracting actual cost from the original budget gives remaining authorization, not the cost of remaining work. Forecast that work independently before judging the expected overrun.

Reference: [1]

40. Design quality into delivery

Design quality by translating needs into observable acceptance and test criteria before production begins. Plan prevention activities, such as clear specifications and automated checks, alongside appraisal activities that detect defects. Compare their costs with internal failure costs, such as rework, and external failure costs, such as customer disruption and correction after release. A prevention investment is attractive when its expected avoided failure cost exceeds its own cost, but the estimate depends on defect frequency and effectiveness. Apply checks at points where feedback is still cheap enough to act on, and review results to improve the process. Quality criteria may also include accessibility, security, sustainability, or regulatory obligations relevant to the deliverable. Passing a test supports confidence only for the conditions that test actually covers.

Worked example: For two planned releases, a hypothetical automated check costs 12 cost units once. Based on past comparable releases, the team expects it to avoid 20 units of rework per release. Expected avoided rework is 2 × 20 = 40 units, giving a net expected saving of 40 − 12 = 28 units. The team adopts the check and compares actual defects and rework with that assumption.

Watch the distinction: A projected saving is not a guaranteed saving. Verify that the check detects the relevant defects, then update the estimate using actual failure and maintenance costs.

Reference: [1]

41. Review quality and improve the process

Inspection checks whether a deliverable meets its acceptance or quality criteria. Process improvement asks why defects arise and changes the work system so they occur less often. Use both when a defect repeats: identify affected outputs, contain or correct them, then trace where the defect entered the workflow. Compare defect records by batch, shift, supplier or handoff to distinguish a pattern from an isolated mistake. Test a plausible cause before changing the procedure. A revised check, clearer input specification or automated validation should have an owner and a measure of effectiveness. Track later defects and the cost of checking so the remedy does not create more burden than value. The PMP examination content outline places ongoing quality reviews and continuous improvement within project quality work.

Worked example: An inspection of 200 packaged units finds 12 with missing labels. The team labels those 12 before release, then checks records and finds that all came from the same printer changeover. It adds a first-unit label check after each changeover. In the next comparable 200-unit batch, no labels are missing. That result supports the fix, although later batches should still be monitored.

Watch the distinction: Correcting the 12 units does not establish that the process is fixed. Inspection protects the current batch; a tested change to the labeling step addresses recurrence.

Reference: [1]

42. Find schedule dependencies and the critical path

A schedule dependency states which activity must finish or start before another can proceed. To find the critical path, trace every valid route through the network, add activity durations using the same time units, and identify the longest route to project completion. That route determines the earliest finish under the stated assumptions. A shorter path has total float equal to the difference between its finish and the controlling finish, provided it has no other date constraint. Activities on the critical path normally have zero total float, so delay there moves the finish unless work is recovered or the network changes. Recalculate when durations, dependencies or resource limits change. A simple path calculation assumes activities can proceed as drawn; a shared specialist or mandatory external date may make the practical schedule longer.

Worked example: Two independent paths start together and converge at completion. Path A has activities of 4 and 6 working days, totaling 10. Path B has activities of 3, 5 and 4 working days, totaling 12. The earliest finish is day 12; A has 2 days of total float under these assumptions. A one-day delay on B changes its duration to 13 days and moves completion to day 13 unless recovered.

Watch the distinction: The path with the most activities need not be critical. Add durations along each dependent route and check constraints; counting tasks alone gives no reliable finish date.

Reference: [1]

43. Forecast adaptive work and manage baselines

Adaptive forecasts use completed work from comparable iterations, not an initial wish about team speed. First define what counts as complete and keep backlog items similar enough for an item count to be useful. Divide remaining items by observed throughput, round up to whole iterations, then give a range if throughput varies. Changes in team capacity, item size or acceptance rules weaken the forecast and deserve explicit assumptions. Reforecasting informs a decision; it does not itself authorize a change to a committed date or predictive schedule baseline. The team and product owner can adjust work within their decision rights, while a milestone governed by an agreement or change process needs the designated approval. PMP practice questions can help you rehearse that distinction in scenarios.

Worked example: A team has 45 similarly sized accepted backlog items remaining and has completed 9 per two-week iteration across several comparable iterations. At that rate, 45 ÷ 9 = 5 iterations, or about 10 weeks. If a signed milestone is eight weeks away, the forecast shows a two-week gap. The team examines scope and capacity options, then seeks approval before moving that milestone.

Watch the distinction: A new forecast is evidence, not a revised baseline. Quietly replacing the committed date would hide the variance and bypass the people authorized to accept its consequences.

Reference: [1]

44. Read project status from useful artifacts

A status artifact is useful when it supports a decision and its numbers can be reconciled to an agreed definition. A burnup chart can show accepted scope over time, an issue log can show blockers and owners, and a decision log can explain why priorities changed. Before reporting, ask what each measure counts: built, tested, accepted and released work are different states. Compare chart totals with acceptance records and investigate discrepancies rather than selecting the more favorable figure. Add a forecast when the current trend threatens a milestone, and identify the assumption behind it. Keep the relevant records accessible to stakeholders who must act on them, while tailoring the summary to their decisions. Review whether the artifacts still reveal progress, risks and next actions as the project evolves.

Worked example: A burnup chart shows 40 items complete, but the acceptance record lists only 35. Investigation finds that 5 passed team testing but await customer acceptance. Report 35 accepted items and 5 pending acceptance, then assign an owner and date for the review. Update the chart label or counting rule so future reports distinguish completed development from accepted scope.

Watch the distinction: A chart is not authoritative merely because it is current. If its definition differs from the acceptance record, reconcile the states before claiming delivered scope.

Reference: [1]

45. Close and transition the project

Closure confirms that agreed work is accepted and that responsibility for the result has moved to the right owner. Start with the completion criteria: accepted deliverables, unresolved defects, contractual obligations, financial reconciliation and records required for the next phase or operations. Operational readiness is more than a handover meeting. The receiving group may need access, support instructions, recovery procedures, training and named contacts. Record any remaining work with an owner and authorized treatment, since an open obligation cannot disappear through a closure form. Finish supplier and resource release activities, capture lessons while evidence is fresh, and obtain the agreed approval for phase or project completion. In an adaptive project, a release can be accepted while the broader product continues; make the closure boundary explicit.

Worked example: A sponsor accepts a scheduling system, but support lacks recovery instructions and a supplier invoice remains disputed. The manager assigns the recovery guide to an engineer, has support perform a supervised recovery, and resolves the invoice against the agreement. The team records lessons and transfers open support items to named owners. Only then does the designated approver confirm project closure.

Watch the distinction: Sponsor acceptance alone does not prove operational readiness. Closing while the receiving team cannot recover the system leaves an unmanaged obligation even if the deliverable works today.

Reference: [1]

Business Environment

46. Define governance decision rights

Governance turns authority into usable decision rules. Identify which decisions the team can make, which require a sponsor or steering group, and what triggers escalation. The rules should cover scope, funding, schedule commitments, risk exposure and exceptions, with thresholds defined for the particular project rather than assumed from a generic template. Pair each decision right with evidence: an impact analysis, recommendation, decision record and communication to affected parties. A clear route prevents routine choices from waiting for executives while preserving oversight of material commitments. When authority is unclear, resolve it before implementing a consequential change. Governance also defines reporting cadence and ethical expectations, so decision makers receive comparable information and can see who approved what. Revisit the structure if the project's scale or external obligations change.

Worked example: A charter lets the delivery team reorder tasks but reserves any increase to approved funding for a steering group. A proposed supplier change adds a hypothetical 18 cost units. The manager records its cost, schedule and benefit effects, then sends the request to the steering group. The team may continue unaffected tasks, but it does not commit the extra funding until approval is recorded.

Watch the distinction: A project manager's ability to coordinate work is not unlimited spending authority. Identify the documented decision right before treating a useful proposal as an approved commitment.

Reference: [1]

47. Set success measures and ethical controls

Success measures should connect deliverables to outcomes and specify the population, period, data source and owner. A measure such as adoption can mislead if a report omits difficult sites or changes its denominator. Agree on the calculation before results arrive, report exceptions alongside favorable results, and explain uncertainty or missing data. Ethical governance also requires decision makers to identify interests that could impair impartiality, especially in selection and procurement. Disclosure allows the organization to decide whether someone should recuse themselves or whether another safeguard is needed. Do not wait for proof of misconduct before making a potential conflict visible. Accurate reporting and a documented response protect the credibility of decisions and let stakeholders judge whether the project is delivering the value they approved.

Worked example: Four sites have 80, 70, 30 and 20 active users out of 100 eligible users each. Reporting only the first two gives 150 ÷ 200 = 75% adoption. Across all agreed sites, adoption is 200 ÷ 400 = 50%. The manager reports 50% and the site variation. They also disclose their ownership stake in a bidding supplier before bid evaluation.

Watch the distinction: Selecting only strong sites changes the question being measured. A correct calculation on a biased subset is still misleading, and an undisclosed supplier interest can compromise trust in the award.

Reference: [1]

48. Map compliance obligations

Compliance planning begins by identifying obligations that actually apply to the project, then translating each into a verifiable control. Separate categories such as privacy, information security, worker safety, accessibility, contract conditions and environmental requirements because they can have different owners and evidence. Build a trace from obligation to affected deliverable, control, test or review, accountable owner and required decision point. Place checks before activities that could create an irreversible exposure, such as moving real data or opening a site. Specialists interpret technical and legal requirements; the project manager integrates their work and ensures the evidence is available for decisions. Recheck applicability when scope, location, suppliers or technology changes. A checklist marked complete without evidence gives weak assurance, especially where one failed control could block release.

Worked example: A project migrates customer records and installs kiosks. Its compliance map assigns privacy review of the migration design to a data specialist before real records move, and installation safety inspection to a site specialist before kiosks open. Each check has evidence and an approval owner. Passing the privacy check does not satisfy the separate installation obligation; both gates must be completed.

Watch the distinction: A single 'compliant' label hides distinct obligations. Map each applicable requirement to evidence and timing, because a successful data review says nothing about site safety.

Reference: [1]

49. Respond to a compliance gap

When a control fails, establish what happened, limit further exposure and determine the consequence before resuming the affected work. Record the failed requirement, affected data or equipment, location, time window and people who may have access. Engage the responsible privacy, security, safety or other specialists to assess the impact and follow applicable notification and remediation procedures. The project manager coordinates containment, owners and schedule effects without substituting a personal legal judgment for specialist review. Correct the immediate condition, investigate its cause and test the changed control with representative evidence. Track the event as an issue, including actions, decisions and residual risk. If the gap affects a release gate, do not treat a cleanup claim as proof of readiness; require verification that the control works before repeating the activity.

Worked example: A test export containing personal data is found in an unapproved shared folder. The team stops further exports and restricts folder access, then records who could access it and when. The privacy and security owners assess exposure and direct removal under the applicable procedure. A revised export setting is tested with nonpersonal sample data, and its evidence is reviewed before another real-data export.

Watch the distinction: Deleting the file alone does not establish that exposure was contained or the cause fixed. Access history, the applicable response procedure and a verified control change still matter.

Reference: [1]

50. Evaluate sustainability in project choices

Sustainability belongs in option analysis when it affects stated requirements or the value a project is expected to deliver. Compare alternatives across relevant environmental and social effects as well as cost, schedule and quality. Examples include energy use, waste, reuse, working conditions and access for affected users. Define the measure, boundary and evidence first: a reusable component can have a higher purchase price but different disposal and replacement costs. Distinguish a mandatory requirement from a preference. If an option fails a mandatory requirement, a cheap price does not make it eligible; if both comply, present the tradeoff to the authorized decision maker. Avoid claiming a benefit from a label alone. Production and inventory management concepts such as material flows and stock assumptions can help frame evidence about sourcing and reuse.

Worked example: Two materials meet a project's strength requirement. Material A costs 100 hypothetical units and cannot meet the agreed reuse requirement; B costs 105 and can. If reuse is mandatory, B is the eligible choice despite its 5-unit premium. If reuse is only a preference, compare documented reuse benefits, lifecycle costs and schedule effects, then present the tradeoff for the authorized decision.

Watch the distinction: Choosing the lowest purchase price can violate an agreed requirement or ignore later costs. Establish whether reuse is mandatory and what evidence supports each option before comparing prices.

Reference: [1]

51. Control changes to a predictive baseline

A predictive baseline is the approved reference for measuring scope, schedule and cost performance. A proposed change first needs a clear description and an impact analysis across deliverables, dependencies, resources, funding, risk and expected benefits. The designated authority can approve, reject or defer it. Until a decision is recorded, the team should not quietly replace the baseline or promise the new work. After approval, update the affected baseline and supporting plans together, communicate the authorized version and retain the decision trail. This protects the distinction between a forecast, which describes what is likely, and a baseline, which records an approved commitment. For a hybrid project, an adaptive team may refine its backlog within delegated limits while a change to a contractual milestone still follows formal control.

Worked example: A sponsor requests an extra report. Analysis finds 15 hypothetical cost units and two weeks of additional work on the controlling schedule path. The manager submits the scope, funding and date effects to the designated change authority. If approved, the team adds the report, revises the cost and schedule baselines, and tells dependent teams the new milestone. If rejected, the original baseline remains.

Watch the distinction: A sponsor's request is not automatically an approved baseline change. Assess its full effect and use the defined authority before updating commitments or starting consequential work.

Reference: [1]

52. Handle change in an adaptive backlog

An adaptive backlog is a ranked set of candidate work, so new evidence can change order without treating every refinement as a formal baseline change. The product owner weighs customer value, risk, urgency, dependencies and the product goal, then makes the priority visible to the team. Check what is already committed for the current iteration and whether a proposed swap would disrupt a protected goal. If an item enters the next iteration, confirm capacity and acceptance criteria rather than assuming priority creates time. Some boundaries sit outside the backlog: contractual dates, approved funding, mandatory controls and other governance commitments may require a separate decision. Record the reason for a material reprioritization so stakeholders understand why work moved and can test whether the expected value appears after delivery.

Worked example: User testing reveals that keyboard users cannot complete checkout. The product owner ranks an accessibility fix above a cosmetic banner for the next iteration and agrees on an acceptance test with the team. If the swap fits capacity and leaves the contract date intact, it proceeds within backlog authority. If it moves that date, the manager submits the effect for the required approval.

Watch the distinction: Backlog flexibility does not erase external commitments. A product owner can change item order within delegated authority, but a resulting contract-date change needs the appropriate governance decision.

Reference: [1]

53. Remove an impediment

An impediment blocks or materially slows work that the team is otherwise ready to perform. Identify who is affected, which work is stopped, the time sensitivity and whether a workaround creates new risk. Prioritize by effect on flow and outcomes, not by who complains most loudly. Assign a specific intervention and owner: obtain access, resolve a dependency, negotiate capacity or escalate a decision the team cannot make. Make the blocker visible in an issue or impediment record with its age and next action. Then verify that work actually resumed; an approved request or promised account is not the same as usable access. Repeated blockers may reveal a process cause, such as late provisioning, that deserves an improvement after the immediate constraint is removed.

Worked example: Three teams cannot run planned integration tests because one shared test account is missing. A separate report defect inconveniences one reviewer but does not stop testing. The manager prioritizes account provisioning, names the access administrator as owner and escalates its impact. When the account is delivered, each team signs in and runs a sample test. Only then is the blocker marked resolved.

Watch the distinction: Closing an impediment when someone promises a fix confuses action with outcome. Confirm the affected teams can perform the blocked work and record any remaining constraint.

Reference: [1]

54. Convert a realized risk into an issue

A risk describes an uncertain future event; an issue is a condition that has occurred and needs action now. When the event happens, stop managing it solely as a probability. Record the facts, affected objective, owner, immediate response and decision deadline in the issue process. Activate any planned risk response, but test whether it still fits the real circumstances. Reforecast the schedule or cost impact and communicate it through the appropriate route. Keep distinct future uncertainties on the risk register, such as another review delay after a corrected submission. This separation prevents double counting while preserving useful warnings. The trigger and response should be clear enough that the team can act promptly, especially when an external decision controls the next step.

Worked example: A permit application was at risk of late approval. The authority now rejects it because a drawing is incomplete. Rejection is an issue: assign the engineer to correct the drawing, estimate a three-working-day resubmission effort and revise the affected milestone forecast. A possible further review delay remains a separate risk with its own trigger and response.

Watch the distinction: Keeping a rejection only as a high-probability risk delays active resolution. Once it occurs, track correction as an issue and retain only genuinely uncertain future events as risks.

Reference: [1]

55. Assess and prioritize risks

Risk assessment combines likelihood with consequence so the team can choose where to spend attention and response effort. Define scales consistently and use evidence about causes, exposure and timing. A probability-impact matrix can rank risks quickly, but multiplying ordinal ratings gives a screening score, not a monetary expected loss or a precise measure of severity. Review high-consequence events separately even if their likelihood is lower. Urgency also matters: a modest risk whose response window closes tomorrow may need earlier action than a larger risk months away. Record assumptions and owners, then revisit ratings when new information arrives. For a quantitative decision with reliable probabilities and monetary outcomes, use expected monetary value instead. An associate in risk management guide offers related risk vocabulary, while project priorities still depend on project objectives.

Worked example: On a hypothetical five-point likelihood and impact scale, risk A has ratings 4 and 3, giving 4 × 3 = 12. Risk B has ratings 2 and 5, giving 2 × 5 = 10. A ranks higher by this simple score, but B's maximum impact could threaten a mandatory launch condition. Review B's response urgency and severity before allocating all attention to A.

Watch the distinction: A matrix score of 12 is not a 12-unit expected loss, and it does not automatically settle priority. Ordinal scales and extreme impacts need judgment.

Reference: [1]

56. Use expected monetary value

Expected monetary value estimates the average financial consequence of an uncertain event using probability multiplied by its monetary impact. For a threat, compare the expected loss without a response with the response cost plus the residual expected loss. Use the same currency and time horizon, and include only consequences that belong in the comparison. A response is economically attractive when its expected total cost is lower, assuming the probabilities and impacts are credible. EMV is an average across repeated comparable situations, not a prediction of the amount one project will actually pay. A low-probability severe event may still be unacceptable for safety, compliance or liquidity reasons. Document assumptions, consider multiple outcomes when appropriate, and update the estimate as evidence changes.

Worked example: A hypothetical threat has a 30% chance of a 100-unit loss, so its expected loss is 0.30 × 100 = 30 units. A response costs 10 units and reduces the chance to 10%, leaving 0.10 × 100 = 10 expected loss units. Total expected cost with the response is 10 + 10 = 20 units, an expected improvement of 10 units.

Watch the distinction: The response does not guarantee a 10-unit saving on this project. EMV compares averages under stated assumptions; the actual loss may be zero or 100 units.

Reference: [1]

57. Choose and monitor risk responses

Choose a threat response by asking which part of exposure can be changed. Avoidance removes the threatening activity or condition; mitigation reduces likelihood or impact; transfer assigns some financial consequence to another party through an agreement; acceptance retains the exposure with or without a contingency plan. Transfer rarely removes the project's operational consequences. For each selected response, name an owner, action date, trigger, evidence of effectiveness and residual risk. A trigger is an observable condition that starts a predefined action, such as a failed security test before release. Monitor both implementation and outcome: completing a review does not prove the risk has fallen if failures persist. Escalate when the response exceeds team authority or residual exposure crosses the project's agreed tolerance.

Worked example: A release could expose data through incorrect access roles. The team mitigates the threat by requiring a security review and role tests before production. Failed tests are the trigger to hold release, correct permissions and retest. Passing tests supports release readiness, but the owner still records residual exposure and monitors access events after launch. The review reduces risk; it does not eliminate it.

Watch the distinction: Buying insurance or assigning a security review does not make every consequence disappear. Check what exposure remains and define the trigger and owner for further action.

Reference: [1]

58. Turn lessons into organizational improvement

A lesson becomes organizational improvement when it changes repeatable practice and produces evidence that the change helps. Describe the observed problem precisely, identify its likely cause and choose a small intervention that another project can use. Establish a baseline measure, pilot the intervention under comparable conditions and inspect the result for side effects. If it works, update the organization's template, checklist or guidance, assign an owner and explain when the step applies. A retrospective note alone is easy to lose; a reusable process asset puts the learning into future decisions. Avoid attributing all improvement to one change if workload, staffing or project complexity also shifted. Continue to monitor the measure so a once useful rule does not become unnecessary overhead.

Worked example: Three projects had late interface reviews and averaged 8 working days of resulting delay each. The next comparable project pilots a review checklist at design start and records 2 days of interface-review delay. The observed reduction is 8 - 2 = 6 working days against that historical average. The manager checks for other differences, then updates the standard template and monitors later projects.

Watch the distinction: Writing 'review interfaces earlier' in a lessons log does not change practice. Put the tested step into a reusable workflow and verify that later projects use it.

Reference: [1]

59. Support organizational change

A project can deliver a functioning system while the organization continues to behave as before. Assess readiness by looking at affected roles, incentives, skills, workload and local norms. Identify who must change a decision or habit, what support they need and what may pull them back to the old method. Work with operational leaders to align measures, training, job aids and reinforcement with the intended process. Track adoption and the outcome it should produce, not just attendance at training or software logins. Segment the data: one department may adopt while another faces a different barrier. Feedback from users can reveal friction that requires a product change rather than more communication. Agree who owns adoption after project handover so the benefit remains visible.

Worked example: A new approval workflow passes technical tests, but supervisors still reward staff for using the old spreadsheet. Operations changes its performance measure, trains supervisors and tracks approvals by channel for four weeks. Spreadsheet use falls from 60 of 100 approvals to 20 of 100, or from 60% to 20%. The team checks errors and user feedback before calling the change embedded.

Watch the distinction: Technical acceptance and training completion do not prove adoption. If incentives still favor the old workflow, staff may keep using it despite knowing the new one.

Reference: [1]

60. Respond to external business change

External changes can alter a project's value, feasibility or obligations while delivery is underway. Monitor relevant regulation, technology, market conditions, suppliers and geopolitical factors through named owners and review points. When a signal appears, first verify what changed and whether it applies to the project's locations, users and timeline. Trace the effect to requirements, backlog items, dependencies, cost, schedule, risk and expected benefits. Rank the resulting work by urgency and consequence, while distinguishing a required response from an optional market opportunity. The team can refine work within delegated authority, but changes to committed scope, funding or dates go to the appropriate decision maker. Keep scanning after the decision because external facts may evolve, and communicate the rationale so stakeholders understand changed priorities.

Worked example: A newly announced market rule may require a service to retain an additional data field. The project manager asks the compliance owner to confirm applicability and timing. If applicable, the team identifies the affected capture, storage and test items and estimates two hypothetical iterations of work. It reorders available backlog capacity, then seeks approval if the work changes the committed release date or funding.

Watch the distinction: An external announcement should neither be ignored nor implemented from a headline alone. Verify applicability, assess project effects and route any change to a protected commitment through governance.

Reference: [1]

Official references and further reading

PMI PMP Examination Content Outline, July2026

All study guides

People

1. Build a shared project vision

2. Diagnose vision drift

3. Identify the source of conflict

4. Resolve conflict through interests

5. Use and enforce team ground rules

6. Adapt leadership to team needs

7. Empower decisions within boundaries

8. Clarify roles and accountability

9. Draw on varied team perspectives

10. Solve team problems systematically

11. Represent the team accurately

12. Find affected stakeholders

13. Set stakeholder engagement priorities

14. Tailor communication to the audience

15. Build trust through visible follow-through

16. Align competing expectations

17. Use mentoring to close capability gaps

18. Monitor customer expectations

19. Transfer critical project knowledge

20. Create a communication feedback loop

Process

21. Select a delivery approach

22. Integrate plans and dependencies

23. Estimate effort and resources

24. Revise plans using evidence

25. Define the scope boundary

26. Break scope into manageable work

27. Validate completed scope

28. Map outputs to benefits

29. Prioritize work by value

30. Deliver value in increments

31. Plan resource capacity

32. Resolve resource overload

33. Choose a procurement strategy

34. Match contract type to uncertainty

35. Evaluate bids and negotiate terms

36. Manage supplier performance

37. Build a financial plan

38. Interpret earned value

39. Forecast and govern spending

40. Design quality into delivery

41. Review quality and improve the process

42. Find schedule dependencies and the critical path

43. Forecast adaptive work and manage baselines

44. Read project status from useful artifacts

45. Close and transition the project

Business Environment

46. Define governance decision rights

47. Set success measures and ethical controls

48. Map compliance obligations

49. Respond to a compliance gap

50. Evaluate sustainability in project choices

51. Control changes to a predictive baseline

52. Handle change in an adaptive backlog

53. Remove an impediment

54. Convert a realized risk into an issue

55. Assess and prioritize risks

56. Use expected monetary value

57. Choose and monitor risk responses

58. Turn lessons into organizational improvement

59. Support organizational change

60. Respond to external business change

Official references and further reading

Frequently Asked Questions

Related Study Guides

Associate in Risk Management (ARM)

Certified in Production and Inventory Management (CPIM)

Certified Investment Management Analyst (CIMA - Investments)