ICDL Project Planning (ICDL) common mistakes
ICDL Project Planning · Understand the traps and how to avoid them.
Treating the project charter and the project plan as interchangeable, so scope, deliverables and constraints are not separated from the schedule and resourcing detail when answering scenario questions.
Candidates learn the documents as a list of names and never map which document authorises the project versus which one describes how it will be executed, so they pick whichever term looks familiar.
What to do instead
Build a one-page comparison table: authorisation vs execution, high-level vs detailed, who approves each, and what content belongs in each. Test yourself by classifying sample content items into the correct document.
Confusing a project with ongoing operations, answering that routine repetitive work with no defined end date is a project.
Definitions are memorised as phrases rather than as tests (temporary, unique output, defined start and end), so any organised activity gets labelled a project.
What to do instead
Apply a three-question test to any scenario: does it have a defined start and finish, does it produce a unique deliverable, and is it temporary? If any answer is no, it is operations, not a project.
Leaving work packages at too high a level or including activities that are not deliverables, producing a WBS that cannot support estimating.
Candidates write task lists from memory of what gets done rather than decomposing deliverables, and they stop decomposing as soon as the list looks long enough.
What to do instead
Decompose top-down from deliverables, not bottom-up from activities, and apply the 8-80 rule as a sanity check on work package size. Every leaf must be a noun (a deliverable), not a verb (an action).
Confusing the WBS with the schedule, expecting the WBS to show sequence, dates or dependencies.
Both artefacts list work, so candidates assume the WBS is a timeline and answer that it shows task order.
What to do instead
Memorise the division of labour: the WBS shows scope decomposition only (what), the schedule shows sequence and timing (when). The WBS has no arrows and no dates.
Reversing the meaning of finish-to-start, start-to-start, finish-to-finish and start-to-finish when reading a dependency scenario.
The names are read as descriptions of the predecessor rather than of the relationship between two activities, so the second half of the name is ignored.
What to do instead
Read each relationship as 'successor X cannot [second word] until predecessor Y [first word]s'. Practise by writing the plain-English sentence for each of the four types before choosing an answer.
Treating all dependencies as mandatory, so discretionary (preferred) or external dependencies are classified as hard logic.
Candidates see an arrow on a diagram and assume all arrows are equally binding, missing the distinction between contractual/natural logic and chosen sequencing.
What to do instead
Classify every dependency on two axes: mandatory vs discretionary (is it physically or contractually required, or just preferred?) and internal vs external (does it involve a party outside the project team?).
Adding durations arithmetically along a path without accounting for parallel work, or using the longest path rather than the one with zero float, when identifying the critical path.
Candidates sum numbers on the visually longest chain and ignore that float, not length, defines criticality once dependencies and lags are involved.
What to do instead
Always perform a forward and backward pass, compute total float for each activity, and define the critical path as the chain of activities with zero total float. Verify by checking that delaying any activity on the path delays the project end date.
Applying a productivity or effort-to-duration conversion without accounting for the number of resources, part-time allocation, or non-productive time.
Candidates treat effort in person-days as equal to duration in days, forgetting that duration depends on how many people work on the task and how much of their time is available.
What to do instead
Use duration = effort / (number of resources x availability factor), then add contingency for non-productive time. State the assumption explicitly in any calculation answer.
Confusing resource levelling with resource smoothing, answering that levelling shortens or preserves the project end date.
Both techniques resolve overallocation, so candidates treat them as synonyms and pick whichever sounds more technical.
What to do instead
Anchor the distinction on the end date: levelling may extend the critical path because it respects dependency and resource limits; smoothing uses float only and never extends the end date. If the question mentions a changed finish date, the answer is levelling.
Confusing the baseline with the current schedule or with actual progress, so progress is measured against a moving target.
Candidates see the baseline as a snapshot of the plan that is updated alongside the schedule, rather than the approved reference point that only changes through formal change control.
What to do instead
Treat the baseline as frozen at approval and compare actuals to it, not to the latest revised plan. Remember that re-baselining requires an approved change request and should be recorded as such.
Reporting percentage complete by effort spent rather than by work accomplished, or declaring a task 90 percent complete for an extended period.
Candidates equate time or cost consumed with progress delivered, which hides remaining work and produces misleading status reports.
What to do instead
Measure progress against defined completion criteria (deliverable accepted, milestone met) using a stated method such as 0/100 or weighted milestones, and record remaining duration alongside percent complete.