CAPES common mistakes
CAPES · Understand the traps and how to avoid them.
Treating total float as a property of the activity rather than of the network path, and reporting an activity's float as fixed even after logic or duration changes elsewhere in the network.
Candidates memorize the definition of float and then apply it mechanically, forgetting that float is recomputed on every forward and backward pass and that consuming float on one path can shift float on shared paths. Exam items that change a single duration or relationship exploit this.
What to do instead
Before answering any float question, re-run the forward pass (ES/EF) and backward pass (LS/LF) on the affected network, then recompute TF = LS - ES and FF = min(ES of successors) - EF. State explicitly which path the float belongs to and check whether the change altered the driving path.
Confusing total float with free float and using them interchangeably in answers about delaying an activity without affecting successors.
Both are expressed in the same units and both appear in schedule reports, so candidates under time pressure pick whichever number is on the activity row without checking the successor constraint.
What to do instead
Anchor the distinction: free float is how long an activity can slip before its earliest successor is pushed; total float is how long it can slip before project finish is pushed. For 'no impact on successors' questions, compute free float only; for 'no impact on completion date' questions, use total float.
Selecting Finish-to-Start for every relationship, including cases where the scenario clearly describes overlapping work, a lag for curing or approval, or a start-to-start with lag.
FS is the default in most tools and the most familiar relationship, so candidates default to it without parsing the scenario language about overlap, delay before start, or concurrent execution.
What to do instead
Map scenario keywords to relationship types before answering: 'must finish before the other can start' = FS; 'can start once the other has started' = SS; 'must finish together' = FF; 'can finish only after the other starts' = SF. Treat curing, review, and approval waiting periods as lags on the correct relationship, not as dummy activities.
Building or accepting a WBS whose lowest level mixes deliverables with activities, or whose branches use inconsistent decomposition rules.
Candidates conflate the WBS (deliverable-oriented) with the activity list (work-oriented) because both appear in schedule development, and they do not check that every branch descends by the same logic.
What to do instead
Apply the 100 percent rule and the mutually exclusive rule at each level: children must sum exactly to the parent and must not overlap. Keep the lowest WBS level as a deliverable or work package, then decompose work packages into activities in a separate activity list. Verify every branch uses the same decomposition basis (phase, discipline, or product element).
Leveling resources by simply delaying every activity that has a resource conflict, rather than resolving conflicts within float first and only then extending the critical path.
Candidates treat leveling as 'push activities later' and skip the step of checking float availability, so they over-extend the schedule and misreport the new completion date.
What to do instead
Sequence the response: identify the over-allocation by period, consume free float and then total float before extending the project, document which activities moved, and recompute the critical path afterward. Distinguish leveling (may extend duration, respects constraints) from smoothing (shifts within float, does not extend duration).
Loading cost onto activities without aligning the cost accounts to the WBS, then reporting cost performance that cannot be reconciled to the schedule.
Candidates focus on the mechanics of assigning budget per period and overlook that earned value requires a one-to-one mapping between control accounts, work packages, and scheduled activities.
What to do instead
Establish the control account structure first, map each work package to WBS and cost account identifiers, then distribute cost by activity using a defined resource or cost curve. Confirm that the sum of activity budgets equals the control account budget before computing any earned value metric.
Using the deterministic critical path finish date as the project completion date in answers involving risk, ignoring the distribution produced by schedule risk analysis.
Candidates learn CPM first and treat the longest path as the answer to every duration question, forgetting that risk analysis produces a probability distribution and a contingency reserve rather than a single date.
What to do instead
When a question mentions uncertainty, risk events, or confidence level, run or describe a Monte Carlo or three-point estimate, read the result at the stated confidence (for example P80), and add the resulting contingency to the deterministic date. Keep the deterministic CPM date as the base and the risk-adjusted date as the commitment.
Computing schedule performance index and forecast completion with SPI alone, or applying earned schedule formulas without matching the metric to the question asked.
Candidates memorize SPI = EV/PV and the EAC-type formulas but do not check whether the question asks about time or cost, or whether the schedule is on the critical path, so they produce a plausible but wrong forecast.
What to do instead
Decide first whether the question is about time or cost. For time, use earned schedule concepts (SPI = ES/AT, forecast duration = planned duration / SPI, or the independent estimate at completion) and note that SPI trends to 1.0 at completion, which limits its forecasting value late in the project. For cost, use CPI-based EAC variants and state the assumption behind each.
Accepting a baseline change without recording the change in a change log, revising the baseline version, and re-baselining only after approval.
Candidates treat baseline updates as an administrative afterthought and answer as if the schedule can simply be edited, missing that the exam tests controlled, documented, approved change.
What to do instead
Apply the change control cycle explicitly: submit a change request with impact analysis on scope, schedule, and cost; obtain approval from the authorized level; update the schedule and the change log; issue a new baseline version with a version identifier and effective date. Never overwrite the prior baseline, and never re-baseline without approval.
Judging schedule quality by visual inspection of the Gantt chart rather than by checking open ends, lags, constraints, hard-coded dates, excessive float, and logic density against a defined checklist.
Candidates equate a tidy-looking chart with a valid schedule and do not know the standard checks (for example DCMA-style checks on logic, leads and lags, constraints, float, and critical path validity), so they miss defects that exam items describe.
What to do instead
Run a structured quality review: count open-ended activities (missing predecessors or successors), flag negative or excessive lags, list hard constraints and date constraints, check for activities with unusually high float, verify the critical path is continuous and logical, and confirm resource and cost loading is complete. Report findings against thresholds rather than impressions.