AACE PSP common mistakes
AACE PSP · Understand the traps and how to avoid them.
Treating the schedule as a deliverable to be drawn rather than a model to be built, so activities are added as bars on a page without defining the logic network first.
Candidates with hands-on tool experience learn to draw bars and link them visually; the exam rewards the underlying CPM model, and the habit carries over from production work.
What to do instead
For every practice exercise, write the activity list, then the predecessor/successor relationships in a table, then run the calculation, and only then look at the bar chart. Verify the logic is complete (every activity except start/finish has both a predecessor and successor) before reviewing any output.
Classifying constraint types by the tool's checkbox labels rather than by what the constraint actually does to the float or the logic (e.g., calling a 'start no earlier than' date a hard constraint in every case).
Software presents constraints as a flat list of options, so candidates memorize labels instead of reasoning about the effect on the forward and backward pass.
What to do instead
For each constraint type, state in writing what it does to early dates, late dates, and total float, and whether it overrides logic. Practice on a small network by applying each constraint and recalculating, then compare the before/after float values.
Building schedules without a defined calendar strategy, mixing 5-day and 7-day calendars across activities and resources and ignoring weather or holiday calendars.
Default calendars in software are accepted without review, and the effect of calendar mismatches on float and dates is invisible until a calculation is run.
What to do instead
Before building any practice schedule, define the project calendar, resource calendars, and any seasonal/weather calendars explicitly, document which activities use which, and check that lags and relationships crossing calendars produce the dates you expect.
Confusing total float with free float when answering questions about which activities can slip without affecting a successor, or about float ownership.
Both are reported as 'float' in most tool outputs and in casual conversation, so the distinction blurs under time pressure.
What to do instead
Drill the definitions until automatic: total float is slip before project finish is delayed; free float is slip before any successor's early start is delayed. For any network question, compute both by hand for at least the path in question before selecting an answer.
Failing to distinguish a schedule update (progress plus remaining work, logic preserved) from a schedule revision (logic or scope changed), and applying the wrong one in a scenario.
In practice the two are often done in one sitting on the same file, so candidates never had to name the difference.
What to do instead
Memorize the two definitions and the rule that updates are routine and periodic while revisions require justification and approval. When a question describes a change, first ask whether the network logic or scope changed; that answer determines the label.
Recording progress as percent complete on summary or hammock activities instead of on the detailed activities that drive them.
Status meetings report at the summary level, so candidates carry that habit into exam scenarios about updating.
What to do instead
Adopt the rule that progress is captured only at the level where work is performed and measured, and that summaries roll up from detail. In practice exercises, enter progress only on detail activities and confirm the summary reflects it automatically.
Ignoring out-of-sequence progress (work started before its predecessor finished) and letting the tool's default handling silently change the logic or dates.
Tools resolve out-of-sequence logic automatically and quietly; the candidate never sees the decision being made.
What to do instead
Learn the available retention/override options in the tool you use and the scheduling consequence of each. Practice a case where an activity starts early, then inspect how remaining logic and dates changed and be able to explain why.
Using the critical path as the sole performance indicator and not reconciling it against earned value or float consumption when judging schedule health.
The critical path is the most visible output, so it becomes the only lens applied to a status question.
What to do instead
For each status scenario, evaluate at least three signals together: critical path movement, total float trend on near-critical paths, and schedule performance from earned value. Practice writing a short status narrative that cites all three.
Performing a delay analysis without first establishing the as-planned baseline and the contemporaneous updates, or mixing methods (e.g., applying a time-impact analysis to a window that requires an as-built comparison).
Candidates jump to the analytical technique they know best rather than selecting the method the fact pattern supports.
What to do instead
Learn to state the prerequisites of each common method (as-planned vs as-built, impacted as-planned, window/time-impact, collapsed as-built) and the conditions under which each is valid. Before answering, identify what records the scenario says exist, then choose the method those records support.
Presenting reports that show only dates and bars, with no float, no logic density or integrity metrics, and no explicit statement of assumptions, so the reader cannot judge schedule quality.
Reporting is learned as chart production in the tool, and schedule quality metrics are a separate discipline that candidates rarely practice presenting.
What to do instead
Build a standard report package in practice: a logic/quality check summary (open ends, lags, constraints, float distribution), the critical path with float values, and a short assumptions and basis-of-schedule note. Rehearse explaining each element in two sentences.