PMP sample questions — 25 answered and explained

The vision must be kept current: when the business environment changes, the project manager prompts its owners to review it before the plan changes.

A competitor launch and a possible market shift are exactly the triggers for revisiting the vision. The product owner and sponsor confirm whether it changes; only then does the backlog follow. Stopping the iteration is the tempting decisive move, but it acts before anyone knows whether the vision changes.

1. Recognize an external change that may affect the outcome sought.
2. Recall that keeping the vision current is the project manager's job.
3. Involve the people who own the product vision and business case.
4. Defer re-planning until the vision is confirmed.

Exam tip: External change triggers a vision review first; plans follow the reviewed vision.

Phase gates and other review points are natural moments to confirm the vision; changes in intended use are taken there with the sponsor.

The intended use of the asset has changed, so the project's purpose may no longer match its objectives. The upcoming phase gate is the governed place to confirm that with the sponsor. Rewriting the vision alone is tempting because it updates the vision quickly, but it bypasses the sponsor.

1. Note that the intended use, and therefore the outcome, has changed.
2. Note the timing: a phase gate is coming.
3. Use the governed review point to confirm the vision with the sponsor.
4. Reject unilateral rewrites, waiting and treating a fact as a risk.

Exam tip: Use governed review points such as phase gates to keep the vision current, with the sponsor.

Keeping the vision current includes routing vision changes that alter chartered objectives to the sponsor and governance for approval.

The product owner and team agree on the shift, but it changes objectives the sponsor authorized. The right path is to bring the proposal to the sponsor. Updating the charter directly is tempting because everyone in the room agrees, but the authority to change chartered objectives sits with the sponsor.

1. Note that the vision change alters signed charter objectives.
2. Recall who authorized those objectives: the sponsor.
3. Follow the governed path rather than editing or ignoring.
4. Choose the action that brings the proposal to the decision maker.

Exam tip: A vision change that alters chartered objectives goes to the sponsor; it is neither edited in nor ignored.

When people join mid-stream, the project manager re-establishes the vision with them so they understand why work is prioritized as it is.

The questions and off-goal proposals show the newcomers lack the shared vision, not that the ranking is wrong. Explaining the vision and release goal, then reinforcing it through pairing, builds understanding two ways. Sending the documents is the tempting shortcut, but reading produces awareness, not the understanding that explains the ranking. Re-ranking the backlog bends the product to a misunderstanding.

1. Interpret the questions as a missing shared vision, not a ranking error.
2. Choose actions that build the newcomers' understanding, not just their awareness.
3. Prefer an explanation plus reinforcement in daily work over documents alone.
4. Reject actions that change the product or sideline the people.

Exam tip: New people need the vision explained and reinforced; do not reshape the backlog around their gap.

In Scrum, the product owner is accountable for the product goal and the product backlog; the scrum master and project manager help the team understand and use it.

Accountability for the product goal sits with the product owner. The scrum master is the tempting choice because the role coaches the team and helps the product owner with techniques for goal definition, but helping is not owning.

1. Recall the three Scrum accountabilities.
2. Match 'product goal and backlog' to the product owner.
3. Separate helping with the goal (scrum master) from owning it.
4. Rule out organization-level bodies.

Exam tip: The product owner owns the product goal; others help promote and apply it.

Promoting the vision includes using it in planning: iteration goals should visibly trace to what the program is meant to achieve, and the team should make that link itself.

The vision has been communicated, yet the goals still drift, so the gap is in how the team uses it, not in whether they have heard it. Asking the team to explain how each goal advances the vision makes the link part of their own planning. Having the product owner restate it more often is the tempting non-directive option, but it repeats the one-way message that already failed. Setting goals for the team is quick but removes ownership.

1. Note the vision was restated recently and the drift continued.
2. Diagnose: the team hears the vision but does not use it when setting goals.
3. Choose the action that puts the vision into the team's own planning.
4. Reject repeating the message, command-and-control and early escalation.

Exam tip: If people have heard the vision but drift anyway, make them use it, not hear it again.

Symptoms of an unshared vision are about purpose and priority: divergent ranking of the same work and work no one can link to the outcome.

Both correct observations show people using different reasons for their choices: they rank the same work differently and cannot link their work to the outcome. A velocity drop is tempting because vision confusion can slow a team, but it has many other causes and does not point anywhere specific. Design debates and extra status requests concern how work is built and reported, not why it is done.

1. Ask what a shared vision would change: priorities and purpose.
2. Find observations about priority and purpose.
3. Set aside observations that have many possible causes, such as velocity.
4. Set aside observations about design or reporting.

Exam tip: Divergent priorities and work no one can link to the outcome signal an unshared vision.

Breaking down a vision misunderstanding means finding where interpretations diverged before choosing a fix, so the corrective action addresses the actual cause.

Two facts combine. Both parties followed the same approved statement and reached different results, so the divergence must be analysed before a fix is chosen. The deadline makes immediate action tempting, but eight weeks against a five-week build leaves time for a short, focused review. Raising a change request now is the strongest distractor under that pressure, yet it commits the vendor to a fix before anyone knows whether the wording, missing context or the sponsor's expectation is the cause. Revising the statement and escalating also act before understanding.

1. Note that both sides cite the same approved statement.
2. Check the time pressure: eight weeks against a five-week build leaves room to analyse.
3. Apply "analyse before acting" to find where the readings diverge.
4. Choose the fix, change request or escalation only once the cause is confirmed.

Exam tip: Same text, different results: analyse the divergence before rewriting, reworking or escalating.

Critical information requirements are derived from the decisions and obligations the project must support, and specify what data, from where, owned by whom and when.

The stem names two consumers: the steering committee's monthly decision and the regulator's quarterly figures. The plan must define the information each needs and make it reliable. Every option mentions one of the two consumers, but the distractors either start from convenient data (tool exports) or push detailed operational data upward (backlog detail, timesheets), which adds noise rather than serving the decision or the obligation.

1. List who needs information and why: the committee and the regulator.
2. Derive the information from each need.
3. Specify definition, source and owner for regulated metrics.
4. Reject data chosen for convenience or volume.

Exam tip: Derive critical information from decisions and obligations, not from what is easy to collect.

An execution strategy decides how the work is delivered: pilot, phased or big-bang rollout, parallel running, sequencing. The stated constraints decide among workable options.

Several strategies could work in principle. The constraints eliminate them one by one: one cutover at a time rules out big-bang and all-plant module rollouts; no budget for two systems rules out parallel running. Differing plant processes and costly downtime favour proving the solution in one pilot plant before rolling out sequentially.

1. List the constraints: differing plants, costly downtime, one cutover at a time, no parallel budget.
2. Test each strategy against every constraint.
3. Eliminate big-bang and all-plant module rollout on capacity.
4. Eliminate parallel running on budget; choose pilot plus phased rollout.

Exam tip: Pick the execution strategy that survives every stated constraint; pilot plus phased rollout limits risk when capacity is limited.

The execution strategy sequences and organizes work to meet the binding constraints, here a fixed legal date and a shared specialist bottleneck.

Two facts combine: the legal deadline has little slack, and the specialists are a bottleneck shared by both streams. Any strategy that divides their time (alternating sprints, parallel teams) or delays the module (enhancements first) risks the deadline. Sequencing the module first, then using an iterative cadence for the shifting enhancements, fits both streams.

1. Identify the binding constraint: fixed legal deadline with little slack.
2. Identify the bottleneck: two specialists needed by both streams.
3. Reject options that split specialist time or delay the module.
4. Sequence the module first, then iterate on the enhancements.

Exam tip: When a scarce resource serves two streams, sequence work to protect the fixed-date deliverable first.

The performance measurement baseline (PMB) is the integrated scope, schedule and cost baseline used to measure and manage project performance.

Earned value needs to know what work was planned (scope), when (schedule) and at what cost (cost). Those three baselines together form the PMB. Quality, risk and resources are managed through subsidiary plans, not as parts of the PMB.

1. Recall what earned value compares: planned work, timing and cost.
2. Match each to its baseline: scope, schedule, cost.
3. Reject sets that add plans which are not baselines.

Exam tip: Performance measurement baseline = scope + schedule + cost baselines.

The project management plan holds the subsidiary management plans (including the change management plan) and the baselines. Working outputs such as the current schedule, estimates, registers and logs are project documents.

Baselines and subsidiary management plans are approved parts of the plan that change only through change control. The scope baseline and the change management plan both qualify. The project schedule and cost estimates are the tempting near-twins: they look like the schedule and cost baselines, but they are working documents updated as work proceeds. The change log is a project document that records changes; it is not itself a controlled plan component.

1. Ask of each item: is it an approved part of the plan, controlled through change control?
2. Baselines and subsidiary management plans are plan components.
3. Working versions (schedule, estimates) and logs are project documents.

Exam tip: Baselines and management plans are in the plan; the working schedule, estimates and logs are project documents.

Analogous (top-down) estimating uses the actuals of a similar past project to estimate a new one when little detail is available.

The stem gives two clues: little detail and a very similar past project. Together they describe analogous estimating, which is fast but less accurate. Bottom-up needs a WBS; parametric needs a unit-rate model; three-point needs ranges for defined activities.

1. Note the timing: early, few details.
2. Note the available data: one similar past project.
3. Match whole-project comparison to analogous estimating.

Exam tip: Early, little detail, similar past project: use analogous estimating.

Agile teams use relative sizing. Affinity estimating sizes large numbers of items quickly; planning poker is better for refining a smaller set with discussion.

The constraint is volume against time: about 300 stories in one half-day. Affinity estimating groups items by relative size rapidly, giving the rough sizes a release plan needs. Planning poker is the near-twin, another relative technique, but it discusses each item and would not finish.

1. Note the volume: about 300 stories.
2. Note the time box: one half-day, rough sizes only.
3. Pick the relative technique built for speed at volume.
4. Reject planning poker on speed and bottom-up on detail.

Exam tip: Large backlog, rough sizes fast: affinity estimating; smaller set with discussion: planning poker.

Three-point estimating with a beta (PERT) distribution weights the most likely value four times: E = (O + 4M + P) / 6.

Apply the formula: (4 + 28 + 16) / 6 = 8 days. The triangular average (9 days) is the main trap; it gives each value equal weight.

1. Identify O = 4, M = 7, P = 16.
2. Apply beta: (O + 4M + P) / 6.
3. Compute 48 / 6 = 8 days.

Exam tip: PERT (beta) = (O + 4M + P) / 6; triangular = (O + M + P) / 3.

Effort is the labour needed (person-hours); duration is calendar time. Duration = effort / (people x hours each per day).

The two developers supply 8 effort-hours per working day between them, so 80 hours takes 10 working days. The distractors come from ignoring either the allocation or one of the two people.

1. Separate effort (80 hours) from duration (days).
2. Compute daily capacity: 2 people x 4 hours = 8 hours.
3. Divide: 80 / 8 = 10 working days.

Exam tip: Duration = effort divided by the hours actually available per day.

Velocity is a measure of a team's capacity under normal conditions. When capacity changes (absences, holidays), the plan is scaled to the capacity actually available.

Two capacity reductions combine. Two of six people are away (keeping 2/3 of capacity) and one of ten days is a holiday (keeping 0.9). Applying both to the 30-point average gives about 18 points. Each near-twin applies only one of the adjustments; planning to the backlog slice ignores capacity entirely.

1. Take average velocity: (28 + 30 + 32) / 3 = 30.
2. Scale for people: 4 of 6 = 2/3.
3. Scale for days: 9 of 10 = 0.9.
4. Multiply: 30 x 2/3 x 0.9 = 18 points.

Exam tip: Plan to available capacity: scale velocity for every reduction, not just the obvious one.

PMOs differ by the degree of control they exert: supportive (low), controlling (moderate) and directive (high).

Mandatory templates plus compliance audits, without managing projects directly, is the moderate level of control that defines a controlling PMO. The supportive PMO is the near-twin because it also provides templates, but it does not require their use.

1. Note what the PMO requires: use of its templates and compliance audits.
2. Note what it does not do: assign or manage project managers.
3. Match moderate control to the controlling PMO.
4. Reserve directive for PMOs that run the projects.

Exam tip: Supportive suggests, controlling requires and audits, directive runs the projects.

Success metrics are part of governance: defined at the start, agreed with stakeholders and used throughout to steer and judge the project.

Metrics set during initiation give the team a target for planning and give governance bodies a basis for oversight. Setting them later lets the outcome define the target and removes their value for steering.

1. Ask what success metrics are for: steering and judging the project.
2. Steering requires them before work starts.
3. Agreement with stakeholders prevents later disputes.
4. So define them at initiation.

Exam tip: Agree how success will be measured before the work starts, not after it ends.

Project success metrics should measure the outcome or benefit in the business case, not only the outputs produced.

The business case justifies the project by reduced handling time, so success is measured by handling time compared with a baseline. Features delivered and scope completed are tempting because they are easy to count, but they measure output and can look healthy while the outcome fails.

1. Read the business case: the purpose is shorter calls.
2. Separate outcome measures from output and team measures.
3. Choose the measure that tracks the outcome against a baseline.

Exam tip: Measure success by the outcome the business case promises, not by how much was produced.

Success criteria trace back to the business case: the benefit it promises and the constraints it sets.

The business case gives two conditions: a measurable rise in online renewals and delivery inside the approved budget. One metric tracks each. Story points and screens built are tempting because agile teams report them, but they measure effort and output rather than success.

1. Extract each success condition from the business case.
2. Find a metric that measures each condition directly.
3. Reject team planning measures and output counts.
4. Keep one metric per condition.

Exam tip: Each success condition in the business case needs a metric that measures it directly.

A success metric expressed as a change needs a baseline captured before the project alters the thing being measured.

A 30% cut is a relative target, so the current value must be known. Once the new form is live, the old process can no longer be measured, which is why the baseline must be captured now. Using an industry average looks efficient but does not describe this organization.

1. Notice the metric is a relative change.
2. A relative change needs a starting value.
3. The starting value disappears once the release changes the process.
4. Capture it now from the current process.

Exam tip: A metric of change is meaningless without a baseline measured before the change.

Governance thresholds (tolerances) delegate decisions to the project manager inside a limit and require escalation above it.

Three days is within the five-day tolerance, so the decision is the project manager's. Escalating is the tempting cautious choice but it defeats the purpose of a threshold, and doing nothing confuses having authority with having no duty to act.

1. Compare the variance with the threshold.
2. Inside the threshold, the project manager acts.
3. Record the variance so reporting stays transparent.
4. Escalate only when the threshold is, or is forecast to be, breached.

Exam tip: Inside tolerance, act and record; outside tolerance, escalate.

Escalation thresholds are applied to forecasts as well as actuals, and reserves outside the project manager's control require escalation.

Two facts decide this. First, the estimate at completion forecasts a breach, so escalation is due now while the sponsor still has options. Second, with contingency spent, the remaining money is management reserve, which the project manager cannot release. Drawing on it is the tempting fix, and cutting scope looks proactive, but both act outside the project manager's authority.

1. Compare the forecast, not just the current variance, with the tolerance.
2. A forecast breach triggers escalation.
3. Check what the project manager controls: contingency is spent.
4. Management reserve and scope reductions need the sponsor's decision.
5. Escalate now with the forecast and options.

Exam tip: Escalate on a forecast breach, and remember the management reserve is not the project manager's to spend.