Project+ — CompTIA Project+ (PK0-005) Exam Scenario Practice Guide

How to Approach Project+ Scenario Questions

Scenario questions on the CompTIA Project+ (PK0-005) exam often describe a realistic project situation and ask what the project manager, team, sponsor, or stakeholder should do next. The key is not to choose an answer that sounds broadly good. The key is to choose the answer that best fits the role, timing, delivery approach, and facts given.

A strong scenario-reading habit is:

1. Identify your role in the scenario.
2. Determine the project context: predictive, agile, or hybrid.
3. Find the actual problem, not just the visible symptom.
4. Decide whether analysis, communication, action, documentation, or escalation comes first.
5. Eliminate answers that skip the appropriate process.
6. Choose the most defensible next step based on the facts provided.

This guide is independent exam-preparation guidance and is not affiliated with CompTIA.

Read for the Decision Point, Not Just the Topic

Many Project+ scenarios contain familiar project management terms: risk, scope, schedule, stakeholder, change, quality, issue, procurement, or communication. Do not stop at recognizing the topic. Ask: “What decision is the question testing?”

A scenario may mention a schedule delay, but the decision point might be about communication. It may mention a stakeholder complaint, but the correct response may be to confirm requirements or follow change control. It may mention a team disagreement, but the best next step may be facilitation rather than escalation.

Before reading the answer choices closely, complete this sentence:

“The project manager needs to decide whether to _____.”

Examples:

• Decide whether to analyze impact before approving a scope change.
• Decide whether to escalate a resource conflict or first discuss it with the affected parties.
• Decide whether to update the risk register, implement a planned response, or create a change request.
• Decide whether a communication issue requires a stakeholder meeting, status report, or updated communication plan.
• Decide whether the scenario is asking for the immediate next action or the final outcome.

This keeps you from choosing an answer that is correct in general but wrong for the moment.

Identify the Role in the Scenario

The best answer often depends on who is acting. In Project+ scenarios, pay close attention to whether the scenario names a project manager, sponsor, team member, customer, product owner, vendor, or stakeholder.

If You Are the Project Manager

The project manager usually coordinates work, communicates status, manages issues and risks, follows project plans, and helps the team stay aligned. In many scenarios, the project manager should:

• Gather and verify information before reacting.
• Use the project management plan, communication plan, risk register, issue log, or change process.
• Facilitate discussion among stakeholders or team members.
• Analyze impact to scope, schedule, cost, quality, risk, and resources.
• Escalate only when the issue exceeds the project manager’s authority or cannot be resolved at the project level.

If the Sponsor Is Involved

A sponsor typically provides authority, removes major obstacles, approves major business decisions, and supports funding or strategic direction. If the answer choice has the project manager making a sponsor-level decision, be cautious.

Sponsor involvement may be appropriate when:

• A decision exceeds the project manager’s authority.
• Funding, priority, or business justification is affected.
• A major conflict cannot be resolved through normal project channels.
• Governance or change control requires sponsor approval.

If the Product Owner or Customer Is Involved

In agile or hybrid contexts, the product owner or customer often clarifies value, prioritizes backlog items, and accepts or rejects deliverables. The project manager should not usually reprioritize customer value unilaterally.

Look for cues such as:

• “Backlog”
• “Iteration”
• “Sprint”
• “Product owner”
• “User story”
• “Increment”
• “Review”

These cues can change the best answer from formal baseline change control to backlog refinement, prioritization, or team discussion, depending on the scenario.

If a Team Member Is Involved

Team-member scenarios often test communication, conflict resolution, quality ownership, or task accountability. The best answer is usually collaborative and direct before it is punitive or escalatory.

A project manager may need to:

• Clarify expectations.
• Facilitate a conversation.
• Remove blockers.
• Confirm resource availability.
• Review task status and dependencies.
• Update the issue log if the matter affects the project.

Determine the Delivery Approach

Project+ scenarios may describe predictive, agile, or hybrid work. The delivery approach affects what “good project management” looks like in the answer choices.

Predictive Project Context

Predictive scenarios often include:

• A defined scope baseline
• Work breakdown structure
• Formal schedule and budget
• Phase gates or milestones
• Change control process
• Detailed requirements established early

In a predictive context, scope, schedule, or cost changes usually require impact analysis and approval before implementation. If a stakeholder requests a new feature after baselines are approved, the best next step is rarely “start the work.” It is more likely to document the request, analyze impact, and follow the change process.

Agile Project Context

Agile scenarios often include:

• Backlog items
• Iterations or sprints
• Daily standups
• Product owner prioritization
• Incremental delivery
• Retrospectives
• Frequent customer feedback

In an agile context, the best answer often involves collaboration, backlog prioritization, team self-organization, customer feedback, or adapting future work. However, agile does not mean uncontrolled change. The question may still expect you to protect the current iteration, involve the product owner, or consider team capacity.

Hybrid Project Context

Hybrid scenarios combine elements of both. For example, a project may have fixed budget and governance requirements but deliver features iteratively.

When the scenario is hybrid, ask:

• Which part of the project is being tested: governance or delivery?
• Is the issue about formal approval, funding, and baseline control?
• Or is it about backlog refinement, iteration planning, and customer feedback?
• Does the answer need to satisfy both flexibility and control?

A hybrid answer may involve analyzing impact through governance while allowing iterative delivery decisions within approved boundaries.

Find the Actual Problem

Scenarios often describe symptoms. Your job is to identify the underlying project management issue.

Common Scenario Events and What They Usually Require

Use these categories to classify the scenario quickly:

• New request: Determine whether it is in scope. If not, document and evaluate it through the change process or backlog prioritization.
• Risk identified: Analyze probability and impact, assign an owner, plan a response, and update the risk register.
• Risk occurred: Treat it as an issue, implement the planned response if one exists, communicate impact, and update project records.
• Schedule delay: Identify the cause, analyze impact, review dependencies, communicate status, and consider corrective action.
• Budget concern: Validate the numbers, compare to baseline, analyze variance, and communicate through the appropriate reporting path.
• Quality defect: Determine severity, follow quality processes, correct the defect, and address root cause if needed.
• Stakeholder conflict: Clarify interests, communicate directly, facilitate resolution, and escalate only if necessary.
• Resource issue: Confirm availability, assess impact, work with functional managers or sponsors if authority is limited.
• Vendor issue: Review contract terms, document performance, communicate formally, and follow procurement or escalation procedures.
• Communication breakdown: Identify who needs what information, when, and through which channel. Update the communication plan if the pattern persists.

Separate Facts from Distractors

A scenario may include extra detail to make the situation feel realistic. Not every fact should drive your answer.

Facts That Usually Matter

Pay close attention to facts that affect authority, timing, urgency, or process:

• Who is requesting the action?
• Has the change already been approved?
• Is there an approved baseline?
• Is the project predictive, agile, or hybrid?
• Is the issue a risk, an issue, a defect, or a change request?
• Is the work already in progress?
• Is there a deadline, dependency, or milestone?
• Does the project manager have authority to decide?
• Are stakeholders aligned or in conflict?
• Is customer acceptance affected?
• Is there a contractual or vendor obligation?
• Has the team already tried to resolve the issue?

Details That May Be Distractors

Some details may add context without changing the best next step:

• Names of departments unless authority or stakeholder impact matters.
• Emotional wording unless it signals conflict or urgency.
• Technical details unless they affect scope, quality, risk, or dependency.
• A large number of stakeholders unless communication planning is the issue.
• A preferred solution from one stakeholder if it has not been evaluated.

Do not ignore details, but do not treat every detail as equally important.

Decide What Comes First: Analyze, Communicate, Act, Document, or Escalate

Many Project+ scenario questions ask what the project manager should do first or next. The correct answer often depends on sequencing.

When Analysis Comes First

Analysis usually comes before action when the impact is unknown.

Choose an analysis-oriented answer when:

• A requested change may affect scope, cost, schedule, quality, or risk.
• The scenario gives incomplete information.
• A delay or variance is reported but the cause is unclear.
• A stakeholder proposes a solution before the problem is understood.
• The project manager needs to compare the situation to the baseline.

Good analysis actions include:

• Assess impact.
• Review the project plan.
• Validate the issue.
• Determine root cause.
• Evaluate options.
• Consult the risk register, issue log, schedule, or budget.

When Communication Comes First

Communication comes first when the issue is about alignment, expectations, or awareness.

Choose a communication-oriented answer when:

• Stakeholders have conflicting expectations.
• A team member is blocked and needs clarification.
• A sponsor needs to know about a material issue.
• The customer has not accepted a deliverable because expectations differ.
• The communication plan appears insufficient.

Good communication actions include:

• Meet with the stakeholder to clarify needs.
• Facilitate a discussion with affected parties.
• Send status according to the communication plan.
• Confirm understanding and document decisions.
• Escalate communication only when normal channels fail or authority is exceeded.

When Action Comes First

Immediate action is appropriate when the scenario shows an active issue that must be contained or a previously planned response should be executed.

Choose an action-oriented answer when:

• A known risk has occurred and a response plan already exists.
• A critical blocker is stopping project work.
• A quality issue must be contained before more defects are produced.
• A safety, compliance, or business-critical matter requires prompt attention.
• The team needs a clear next step after a decision has already been made.

Action should still be controlled. “Act” does not mean bypassing approvals, ignoring documentation, or making unauthorized commitments.

When Documentation Comes First

Documentation matters when the scenario introduces a request, decision, risk, issue, lesson, or approval that must be tracked.

Choose a documentation-oriented answer when:

• A new risk is identified.
• A new issue is discovered.
• A stakeholder requests a change.
• A decision needs to be recorded.
• Acceptance, sign-off, or approval must be captured.
• Lessons learned should be retained for future work.

Documentation is often paired with analysis or communication. For example, a change request may be documented first, then analyzed for impact.

When Escalation Comes First

Escalation is appropriate when the issue exceeds the project manager’s authority, cannot be resolved at the project level, or requires a decision from a higher authority.

Escalate when:

• Funding or strategic priority must be decided.
• A resource conflict cannot be resolved with normal coordination.
• A vendor dispute requires formal contractual handling.
• A major risk or issue threatens project objectives and needs sponsor action.
• A policy, legal, security, or compliance concern requires the proper authority.
• Stakeholders remain deadlocked after reasonable facilitation.

Escalation should be purposeful, not reactive. In many scenarios, the project manager should first gather facts, assess impact, and attempt appropriate resolution.

Use the “Best Next Step” Test

When answer choices all sound plausible, ask which one is the best next step, not which one is eventually useful.

A strong next step is:

• Within the role’s authority.
• Appropriate for the delivery approach.
• Based on the facts provided.
• Sequenced correctly.
• Collaborative where possible.
• Documented when the situation affects project records.
• Escalated only when needed.

A weaker next step often:

• Skips impact analysis.
• Implements an unapproved change.
• Bypasses the product owner, sponsor, or change process.
• Escalates before clarifying the issue.
• Makes a permanent decision from incomplete information.
• Focuses on blame instead of project resolution.
• Updates a plan before approval or before the facts are known.

Read the Wording of the Question Carefully

The final sentence of the question controls your answer. Watch for these wording differences.

“What should the project manager do first?”

This asks for the earliest appropriate step. If the facts are unclear, verify or analyze before acting. If the process requires documentation before evaluation, document the request. If the risk response is already planned and the risk has occurred, implement the response.

“What should the project manager do next?”

This implies something has already happened. Use the scenario’s timeline. If the team has already analyzed impact, the next step may be to present options or seek approval. If approval has already been granted, the next step may be to update the plan and communicate.

“What is the best way to address the issue?”

This may allow a broader answer than “first.” Choose the option that resolves the root problem, not just the symptom.

“Which document should be updated?”

Focus on the type of event:

• Risk identified: risk register.
• Issue occurred: issue log.
• Stakeholder information changed: stakeholder register or communication plan.
• Approved scope/schedule/cost change: relevant project baseline or plan.
• Lessons captured: lessons learned register or repository.
• Requirement clarified: requirements documentation or backlog, depending on approach.

“Who should make the decision?”

Match the decision to authority:

• Product value and backlog priority: often product owner or customer representative in agile contexts.
• Funding, business priority, major approval: often sponsor or governance group.
• Task execution details: often project team.
• Project coordination and status communication: project manager.
• Contractual interpretation or vendor remedies: follow procurement and organizational processes.

Scenario Mini-Examples

Example 1: Scope Change in a Predictive Project

A customer asks for an additional reporting feature after the scope baseline has been approved. The feature is valuable, but it will require extra development and testing.

Best reasoning:

• The request may affect scope, schedule, cost, quality, and resources.
• The work is not automatically approved because it is valuable.
• The project manager should document the request and analyze impact through the change process.
• The team should not begin work until the appropriate approval is obtained.

Most defensible next step: document the change request and assess its impact according to the change control process.

Example 2: New Priority During an Agile Iteration

A stakeholder asks the team to add a new feature during the current iteration. The product owner has not prioritized it.

Best reasoning:

• The scenario uses agile cues: iteration and prioritization.
• Stakeholder requests should be evaluated through the product owner or backlog process.
• The team should avoid disrupting committed iteration work unless the situation is urgent and the proper decision-maker agrees.
• The project manager should facilitate the right conversation, not unilaterally insert work.

Most defensible next step: direct the request to the product owner for prioritization and discuss impact with the team.

Example 3: Risk Becomes an Issue

A supplier delay that was previously identified as a risk has occurred. The risk register includes a planned contingency response.

Best reasoning:

• The risk is no longer only potential; it has occurred.
• A response has already been planned.
• The project manager should implement the planned response, communicate impact, and update project records.
• Reanalyzing from scratch is less defensible if a suitable response plan already exists.

Most defensible next step: implement the planned response and update the issue/risk information as appropriate.

Example 4: Stakeholder Conflict

Two department leads disagree about a requirement. Each believes the other department’s preferred approach will reduce business value.

Best reasoning:

• This is a stakeholder alignment problem.
• The project manager should not choose a side without analysis.
• Direct communication and facilitation are appropriate before escalation.
• If the conflict affects scope or priority and cannot be resolved, sponsor or governance input may later be needed.

Most defensible next step: facilitate a discussion to clarify requirements, impacts, and decision criteria.

Build a Fast Scenario Checklist

Use this checklist during final review and practice exams:

• What role am I playing?
• What delivery approach is described?
• Is this a risk, issue, change, conflict, defect, resource problem, or communication problem?
• Has the event already happened, or is it only possible?
• Has anything already been approved?
• Does the project manager have authority to act?
• Is the question asking for first, next, best, document, or decision owner?
• Do I need more facts before acting?
• Should I communicate before escalating?
• Should I document before analyzing?
• Should I analyze before approving?
• Which answer best follows the project process without overreacting?

Practice Method for Final Review

For each Project+ scenario you practice, do not immediately look at the answer choices. First, write a short decision statement:

• “This is a change control question.”
• “This is a stakeholder communication question.”
• “This is a risk response question.”
• “This is a delivery approach question.”
• “This is an authority and escalation question.”

Then predict the best action in your own words. After that, compare your prediction to the answer choices. This habit prevents answer choices from pulling you toward a response that sounds attractive but does not match the scenario.

When reviewing missed questions, focus on the reasoning sequence:

• Did you identify the correct role?
• Did you notice whether the project was predictive, agile, or hybrid?
• Did you classify the event correctly?
• Did you choose an answer that happened too early or too late?
• Did you escalate before the project manager had enough information?
• Did you act before approval was required?
• Did you update the correct document?

Practical Next Step

Use this guide while completing a short set of Project+ scenario drills. For each question, label the role, delivery approach, problem type, and best next step before selecting an answer. Then move into topic drills for weak areas, followed by a timed mock exam to practice the same decision sequence under exam conditions.