AACE CST common mistakes
AACE CST · Understand the traps and how to avoid them.
Builds a schedule with activities such as 'construct building' lasting 18 months, without first decomposing the WBS into work packages, so progress cannot be measured or forecast.
Candidates rush into CPM software and treat summary-level scope as an activity because it fits quickly on one page and looks complete.
What to do instead
Define the WBS and work packages before entering logic; decompose each package into activities short enough to be statused (commonly the 2–4 week rule, adjusted for phase), assign a responsible party, and verify each activity maps to a WBS element.
Assigns one 7-day project calendar to every activity, ignoring that craft crews work 5×8 shifts and that concrete cure or inspection time is calendar-dependent.
Scheduling software applies a default calendar, and candidates rarely inspect calendar assignments because the bar chart looks plausible.
What to do instead
Define a calendar per work pattern or resource, assign calendars at the activity level, and check calendar-driven finish dates before running CPM; confirm non-work periods and weather/seasonal assumptions in the schedule basis.
Models a 10-day lag between 'pour foundation' and 'erect steel' instead of a cure activity, then cannot explain why float disappeared or why the waiting time was never tracked.
Lags are faster to enter than activities, and the software accepts them without warning, so the hidden time is never statused or reported.
What to do instead
Convert long waits that consume real time into activities with duration and, where relevant, resources; reserve lags for genuine technical interfaces and document every lag in the schedule basis.
Accepts a schedule in which several activities have no successor, then reports total float and a critical path derived from that incomplete network.
Attention goes to the driving path, and software does not force the scheduler to close all logic; open ends silently absorb float.
What to do instead
Close every activity to a successor and ultimately to a project finish milestone or contractual completion date; run a dangling-logic/open-ends check before any float or critical-path analysis.
Updates progress by entering a percent complete and allowing the software to recalculate remaining duration, then reports a forecast finish that never moves despite known delays.
Percent complete is a familiar summary metric, and the recalculation option is a default that appears to save time.
What to do instead
Status activities with actual start/finish and a remaining duration forecast by the performing party; derive percent complete from those inputs, and disable automatic remaining-duration recalculation during updates.
Resets the baseline each month to match the current forecast so the project always appears on schedule.
Pressure to show green status plus a misunderstanding that the baseline should reflect the latest plan drives repeated rebaselining.
What to do instead
Maintain an approved baseline under change control; record scope/date changes as approved revisions with an audit trail, and retain original versus current baseline for variance reporting.
Identifies the critical path as the longest chain of activities by duration, overlooking a mandatory finish constraint or calendar effect that makes a different path critical.
The 'longest path equals critical path' shortcut is taught first and is easier than interpreting total float across a constrained network.
What to do instead
Determine criticality from total float (generally the least-float or negative-float path), review constraints and calendars explicitly, and run a multi-path or multiple-float analysis before naming the critical path.
Reports a schedule variance of −$50,000 as '50,000 days behind schedule,' or treats positive SV as proof the project is ahead in time.
Earned value formulas are memorized without their units; SV = EV − PV is expressed in cost or currency, not duration.
What to do instead
State units whenever variance is reported; use earned schedule or schedule variance in time (SV(t) = earned schedule − actual time) for duration-based conclusions, and interpret SPI and SV together.
Tells the client the schedule was 'leveled' when resources were only smoothed, then is unable to explain why the critical path moved or the completion date slipped.
Leveling and smoothing are often used interchangeably in practice, and both appear as resource-driven adjustments in software reports.
What to do instead
Distinguish the methods: smoothing consumes available float without extending the project, while leveling can delay activities and change the critical path; document which method was applied and its effect on dates and float.
Calculates CPI as EV/AC but interprets a CPI below 1.0 as schedule slippage, or confuses SPI with cost performance when explaining project status.
Formulas are memorized as symbols rather than as measures of cost versus schedule, and index names look similar on a dashboard.
What to do instead
Study the earned value definitions and units until the distinction is automatic: CPI and CV measure cost efficiency, SPI and SV measure schedule performance; practice interpreting paired indices in scenario questions.