PSP — AACE Planning & Scheduling Professional Scenario Practice Guide

Scenario questions on the AACE Planning & Scheduling Professional (PSP) exam often reward disciplined project controls reasoning. The best answer is usually not the fastest reaction, the most aggressive recovery action, or the option that sounds most authoritative. It is the answer that fits the facts, respects the schedule process, and produces a defensible planning or scheduling decision.

Use this guide as an independent exam-preparation resource for reading PSP-style scenarios. The goal is to slow down, identify what the question is really asking, and choose the answer that a planning and scheduling professional could justify from the information provided.

The PSP scenario mindset: protect the schedule record

A strong PSP scenario answer usually does one or more of the following:

• Maintains the integrity of the schedule model.
• Separates the approved baseline from the current update or forecast.
• Uses logic, calendars, constraints, progress data, and critical path information correctly.
• Analyzes schedule impact before recommending a major action.
• Documents assumptions, causes, and changes.
• Communicates schedule implications to the correct stakeholder at the correct time.
• Avoids changing the baseline, assigning blame, accelerating work, or escalating issues before the facts support that step.

Think of the scenario as a project controls decision. Your task is to decide what a competent planner or scheduler should do next based on the available facts.

Start with the command in the question

Before studying every detail, read the final question carefully. Scenario stems often include information that matters only after you know the required decision.

Look for command words such as:

• First / next: choose the immediate professional step, not the final solution.
• Best / most appropriate: choose the option that best fits the whole situation.
• Most likely: infer the cause or implication from the schedule facts.
• Should do: identify the action that fits the role and process.
• Indicates / demonstrates: interpret what the schedule data means.
• Except / not: identify the option that does not belong, then verify the wording carefully.

For a “next step” question, the answer is often to validate, analyze, document, or communicate before taking a larger corrective action.

For a “best action” question, the answer should solve the actual issue without exceeding the authority of the role in the scenario.

Identify your role in the scenario

PSP scenarios may describe the project manager, scheduler, planner, project controls analyst, contractor, owner, subcontractor, or client representative. The role matters because it limits what the person can properly decide.

Ask:

• Am I creating the plan, maintaining the schedule, reporting performance, analyzing delay, or advising management?
• Do I have authority to approve a baseline change, or only to recommend one?
• Am I responsible for collecting progress data, validating logic, evaluating impacts, or communicating results?
• Is the scenario asking for a technical scheduling action or a project governance action?

A scheduler can typically:

• Validate activity status, actual dates, remaining durations, and logic.
• Update the schedule according to the data date and agreed method.
• Analyze the critical path, float, variance, and schedule impact.
• Identify schedule risk or recovery options.
• Document findings and assumptions.
• Recommend actions to the project manager or appropriate decision body.

A scheduler usually should not independently:

• Change an approved baseline without authorization.
• Ignore contractual or project control procedures.
• Promise a revised completion date without analysis.
• Direct major resource changes outside their authority.
• Decide entitlement, fault, or commercial responsibility unless the scenario clearly gives that responsibility.

When two answer choices both sound reasonable, the role often decides which one is more defensible.

Determine the project and schedule context

PSP scenarios are commonly set in predictive, engineering, construction, shutdown, turnaround, infrastructure, or capital-project environments, but the reasoning can apply to hybrid or rolling-wave planning as well. Do not assume every question is about final execution. Identify the schedule context first.

Common scenario contexts

• Planning and baseline development: scope is being decomposed, activities are sequenced, durations are estimated, resources are considered, and the schedule is prepared for approval.
• Schedule review: the model is being checked for logic, constraints, calendars, open ends, excessive lags, unrealistic durations, or missing scope.
• Progress update: actual starts, actual finishes, remaining durations, percent complete, and status dates are being incorporated.
• Forecasting and control: variances, critical path changes, negative float, missed milestones, or recovery needs are being evaluated.
• Change impact analysis: a new scope item, owner direction, design change, late information, or changed sequence may affect the schedule.
• Delay or disruption analysis: the scenario asks how to evaluate the effect of an event on the critical path or project completion.
• Resource or cost-loaded schedule issue: the facts involve crew availability, productivity, resource leveling, cash flow, earned value, or planned value.
• Stakeholder communication issue: the technical schedule result must be explained to management, a client, a contractor, or the project team.

The best answer must match the context. For example, an action that is appropriate during baseline development may be inappropriate after a baseline has been formally approved.

Find the actual problem, not just the loudest fact

Scenario questions often include several facts: a delayed activity, a frustrated stakeholder, a milestone date, a change request, and a report deadline. One of those facts is usually the core decision point.

Classify the issue before choosing an answer.

If the issue is schedule integrity

Look for facts such as:

• Missing predecessor or successor relationships.
• Excessive constraints.
• Large negative float without explanation.
• Activities with actual dates after the data date.
• Open-ended activities.
• Unusual lags or leads.
• Calendar mismatch.
• Out-of-sequence progress.
• Critical path driven by an artificial constraint.

The best next step is usually to review and correct the schedule logic or data according to the project’s scheduling procedures, not to make a management recommendation based on an unreliable model.

If the issue is progress status

Look for facts such as:

• Updated percent complete does not match remaining duration.
• Field-reported progress conflicts with actual dates.
• The data date is not clear.
• Activities are started or finished out of sequence.
• A subcontractor reports completion but successor work cannot begin.
• The forecast completion changed after the update.

The best next step is usually to validate the progress data, update the schedule consistently, and then analyze the resulting critical path and forecast.

If the issue is a change event

Look for facts such as:

• Added scope.
• Revised design information.
• Late owner decision.
• Changed means or methods.
• New regulatory, permit, or access condition.
• Direction to resequence work.
• A request to change a milestone.

The best answer usually involves documenting the change, evaluating its schedule impact, and following the project change control process before modifying approved baseline dates.

If the issue is delay analysis

Look for facts such as:

• A delay event occurred during a specific time window.
• The affected activity may or may not have been critical.
• There are concurrent delays.
• The schedule was updated before or after the event.
• A time impact analysis, fragnet, or contemporaneous schedule period is referenced.
• The question asks whether project completion was affected.

The best answer usually focuses on the critical path at the time of the event, contemporaneous schedule status, reliable data, and documented assumptions. Avoid deciding impact based only on the duration of the delayed activity.

If the issue is communication

Look for facts such as:

• A stakeholder challenges the schedule.
• Management wants a completion date.
• A client asks for recovery options.
• The project team disputes activity status.
• A report shows variance but not cause.

The best answer usually combines analysis with clear communication. Explain what the schedule shows, why it changed, what assumptions were used, and what decisions are needed.

Separate facts from distractors

Do not treat every number or stakeholder opinion as equally important. Sort the scenario facts into useful categories.

Schedule model facts

These are facts about the actual schedule structure:

• Activity logic.
• Durations.
• Calendars.
• Constraints.
• Critical path.
• Float.
• Data date.
• Baseline dates.
• Forecast dates.
• Resources or cost loading.

These facts usually drive the technical answer.

Project control facts

These are facts about process and authority:

• Baseline approval status.
• Change control requirements.
• Reporting cycle.
• Contract or procedure reference.
• Required documentation.
• Assigned responsibility.
• Review or approval workflow.

These facts usually determine what action is allowed next.

Stakeholder facts

These are facts about people and communication:

• A project manager requests a recovery plan.
• A subcontractor disputes the sequence.
• A client wants a milestone maintained.
• Management is concerned about a variance.
• The field team reports a different status than the schedule.

These facts matter, but they rarely override schedule logic. A stakeholder demand does not make a schedule forecast valid. The professional response is to analyze, document, and communicate.

Decide whether analysis, communication, or action comes first

Many PSP scenarios are “sequence” questions. They ask what should happen first, next, or most appropriately. Use this decision order.

1. Is the schedule data reliable?

If the facts suggest incomplete, inconsistent, or unreliable data, validate before analyzing.

Examples:

• Actual dates conflict with the data date.
• Activity progress appears overstated.
• Remaining duration does not support the reported percent complete.
• Logic does not reflect the actual construction sequence.
• A milestone is constrained without a clear reason.

A forecast based on poor data is not defensible.

2. Is the schedule model valid for the decision?

If the schedule has missing logic, improper constraints, calendar problems, or unsupported lags, correct or document the issue before relying on the result.

This does not mean every schedule must be perfect before analysis. It means the defect must not be ignored if it affects the decision being asked.

3. Is there a change, delay, or variance to analyze?

If a change or delay is the central event, determine impact using the appropriate schedule record and method described or implied by the scenario.

Ask:

• What was the status of the schedule when the event occurred?
• Was the affected work on, near, or off the critical path?
• Did the event consume float or delay completion?
• Are there concurrent impacts?
• Is the analysis prospective, retrospective, or contemporaneous?
• What assumptions must be documented?

4. Who must be informed or approve the next step?

After validation and analysis, communicate the result to the correct stakeholder. If approval is needed, the answer should respect that process.

For example:

• Recommend a recovery plan to the project manager.
• Submit a change impact for review.
• Present schedule variance with cause and corrective options.
• Escalate only when the scenario shows the issue exceeds normal authority or requires management decision.

5. What action is proportionate?

The best action should match the severity of the issue.

• A minor data inconsistency calls for verification, not a full rebaseline.
• A missed noncritical activity may require monitoring, not immediate acceleration.
• A critical delay may require impact analysis and recovery options.
• A stakeholder disagreement may require a schedule review meeting, not unilateral schedule manipulation.

Avoid premature escalation

Escalation can be correct, but it is rarely the first professional move when the scheduler has not yet validated the facts.

Escalate or seek management direction when:

• The issue exceeds the scheduler’s authority.
• A formal decision is required.
• The schedule impact affects contractual, commercial, or approved baseline commitments.
• Recovery options involve cost, scope, safety, quality, or major resource tradeoffs.
• Stakeholders cannot resolve a material schedule disagreement through normal review.

Before escalating, the scheduler should usually be ready to explain:

• What changed.
• What the current schedule shows.
• Whether the critical path was affected.
• What assumptions were used.
• What options are available.
• What decision is needed.

A defensible answer escalates with analysis, not with confusion.

Interpret common PSP scenario facts correctly

“The baseline has been approved”

Treat the baseline as the reference for performance measurement. Do not change it casually. If the project has changed, evaluate and document the impact, then follow the approved change control process.

“The data date has moved”

The data date is the status cut-off. Progress before and after the data date must be handled consistently. Activities with actual dates beyond the data date or remaining work scheduled in the past should trigger review.

“The activity has float”

Float is a scheduling result, not a complete decision by itself. Ask whether the activity is on the critical or near-critical path, whether float is shared, whether constraints are creating misleading float, and whether the project procedure defines how float is treated.

“The activity duration increased”

A longer duration matters most if it affects the critical path, consumes available float, changes a milestone forecast, or indicates a productivity issue. Do not assume every duration increase delays the project.

“The critical path changed”

A changed critical path may be normal after progress updates, but it must be understood. Identify whether the change is driven by actual progress, revised logic, resource constraints, calendar changes, or artificial constraints.

“A milestone has negative float”

Negative float indicates the current forecast does not meet a required or constrained date. The next step is usually to identify the driving path and cause, then develop options. Do not simply compress the schedule without understanding what drives the variance.

“The owner or client requests an earlier completion”

A requested earlier date does not automatically become the schedule baseline. Analyze feasibility, resource needs, sequencing, risk, and cost implications, then present options for decision.

“A subcontractor reports a different sequence”

Field knowledge matters, but the schedule must remain logically sound. Review the sequence with the responsible parties, update logic if it better reflects planned or actual execution, and document the rationale.

“A change affects future work”

For prospective impact, model the change in the current schedule context, consider the data date, and evaluate whether the change affects the critical path or milestone forecast.

“A delay affected work that was not critical”

A noncritical delay may still consume float, create near-critical risk, or become critical later. The answer should analyze the schedule effect rather than assume no consequence.

Use a compact scratch-pad method

For longer scenarios, write a short decision map before reading the answer choices closely.

Use this sequence:

• Role: scheduler, planner, project controls, project manager, contractor, owner, or analyst.
• Phase: baseline planning, update, control, change, delay analysis, recovery, or reporting.
• Schedule artifact: baseline schedule, current update, fragnet, recovery schedule, lookahead, report, or claim analysis.
• Time reference: baseline date, current data date, event date, forecast date, or milestone date.
• Problem: data quality, logic, change, delay, resource, variance, stakeholder conflict, or approval issue.
• Decision needed: validate, analyze, update, document, communicate, recommend, or escalate.
• Authority limit: what can this role properly do next?

This short map keeps you from choosing an answer based on one attractive phrase.

Choosing between close answer choices

When two options seem plausible, test each one against the scenario.

A defensible PSP answer should be:

• Fact-supported: the scenario gives enough information to justify it.
• Role-appropriate: the person has authority to perform or recommend it.
• Process-aware: it respects baseline, update, change, and reporting procedures.
• Technically sound: it uses schedule logic, critical path, float, and data dates correctly.
• Proportionate: it does not overreact to a limited issue.
• Documented: it preserves assumptions, causes, and decisions.
• Communicable: it produces information stakeholders can use.

If an option jumps directly to acceleration, rebaselining, blame, or escalation, ask whether the scenario has already provided enough analysis to justify that step. If not, a validation or impact-analysis answer is often stronger.

Short scenario examples

Example 1: Baseline schedule review

A draft baseline schedule is ready for approval. During review, several construction activities have no successors, and a required turnover milestone is being met only because of a finish-no-later-than constraint.

A strong next step is to review and correct the schedule logic and constraint use before relying on the milestone forecast. The issue is not just whether the milestone date appears achievable. The schedule model may not yet provide a reliable basis for approval.

Example 2: Progress update inconsistency

The field team reports an activity as 100 percent complete, but the actual finish date is after the schedule data date. The project manager asks for the updated completion forecast immediately.

A strong next step is to validate the actual finish information and update the schedule consistently with the data date before reporting the forecast. The forecast must be based on reliable status data.

Example 3: Added scope after baseline approval

After the baseline is approved, the client adds work that must occur before commissioning. A stakeholder asks the scheduler to simply extend the baseline completion date.

A strong answer is to document the change, model its schedule impact in the appropriate schedule update, evaluate the critical path and milestone effect, and follow change control before altering baseline dates.

Example 4: Negative float to a required milestone

The current update shows negative float to a required completion milestone. Management asks whether the project team should add crews immediately.

A strong answer is to identify the driving path and cause of the negative float, then develop recovery options with schedule, resource, cost, and risk implications. Adding crews may be one option, but it should follow analysis.

Example 5: Delay event during execution

A design clarification arrived two weeks late. The affected activity had float at the start of the period, but later became critical after other progress issues occurred.

A strong answer evaluates the delay using the schedule status at the time of the event and the contemporaneous critical path, while documenting assumptions and other impacts. Do not decide impact only by looking at the final as-built condition.

Practice habits for final review

Use scenario practice to train decision sequence, not memorized reactions.

For each missed or uncertain question, write one sentence for each of the following:

• What role was I in?
• What schedule artifact was being used?
• What was the actual problem?
• What fact determined the best answer?
• What action came first: validate, analyze, document, communicate, recommend, or escalate?
• Why was the chosen answer more defensible than the next-best option?

Then group weak areas by topic:

• Schedule development and logic.
• Baseline control.
• Progress updates and data dates.
• Critical path and float interpretation.
• Change impact analysis.
• Delay analysis.
• Recovery planning.
• Resource and cost-loaded schedule interpretation.
• Stakeholder communication and reporting.

Final exam-day decision checklist

Before selecting an answer, confirm:

• I know the role and authority of the person in the scenario.
• I know whether the schedule is being planned, updated, analyzed, or changed.
• I identified the actual decision point.
• I separated schedule facts from stakeholder pressure.
• I checked the data date, baseline, critical path, float, and constraints when relevant.
• I chose a next step that is technically sound and process-aware.
• I avoided assuming facts that were not stated.
• I can explain why the answer is defensible from the scenario.

Practical next step

For efficient PSP final review, combine topic drills with timed scenario sets. After each set, review not only whether your answer was correct, but also whether your decision sequence was sound. Then take a full mock exam to practice applying the same reasoning under time pressure.