← VCE Data Analytics U4O1

Judging the reason changes to a project plan were necessary

A change is avoidable if better planning, such as a poor estimate, could have prevented it. It is unavoidable if it came from outside the developer's control, like new requirements.

Part of: VCE Data Analytics - U4O1 - Development and Evaluation — Module 104

Understanding Judging the reason changes to a project plan were necessary in VCE Data Analytics U4O1

What it does: Leaving out testing time is a planning failure within the developer's control, so the later change was avoidable. A late file from an outside supplier cannot be controlled by the developer, so the resulting delay was unavoidable. A sudden fault the developer could not predict is an unexpected problem, so it is unavoidable. Having regular backups would only reduce the damage. Careful estimation would have prevented the overrun, so it should be judged as avoidable.

Common mistakes: The task took longer than planned because the developer estimated badly. Better planning could have prevented it, so the change is avoidable, not unavoidable. A client adding new requirements is outside the developer's control, so the change is unavoidable. The type should be "unavoidable".

Class: _____________________  ·  Name: _____________________  ·  Date: _________

Free printable worksheet with full answer key — or add this module to a class and your students practise it interactively.

🖨 Print worksheet + answer key Add Judging the reason changes to a project plan were necessary to a class →

This module's key terms are also in a printable crossword (Modules 85–105) and word search (Modules 63–105).

Take this worksheet further — free with Cloodit

Each concept is reinforced from every angle — learned, then applied, then tested.

Learning
Duo
A developer guessed a data-cleaning task would take 1 day, but it took 4 days, so the plan was changed. How should this change be judged?
Unavoidable: it was outside the developer's controlAvoidable: a poor estimate is a planning problem
Matches
Change: the client changed the requirements. Judgement: avoidable, because the developer should have planned better
↓
Changed requirements come from outside the developer's control, so the change is unavoidable, not avoidable
Applying
Meanings
Term
avoidable or unavoidable change
Meaning
A change is avoidable if better planning, such as a poor estimate, could have prevented it. It is unavoidable if it came from outside the developer's control, like new requirements.
Practice
Change 1: Cleaning took 5 days, not 2 - poor estimate - AVOIDABLE
Testing
Gaps
SET type TO
Check Answer
Spots
2cause = "poor estimation"
3type = "unavoidable"

Cloodit turns curriculum-aligned coding content into journeys students work through one biome at a time.

The 'Snowy Owl' badge — List Slicer, one of Cloodit's 106 collectible badges
Students earn collectable badges

Over 100 of them, across seven natural biomes.

Study Buddy
Students build a real study resource

Turns their work into revision material ready for Flash Cards and Exam study.

Diamond Dash — one of Cloodit's live, competitive Sprint games
Students lock in with Sprints

Live, competitive practice for the start of the lesson or a teacher-led lesson finisher.

A Cloodit certificate of achievement, ready to personalise and print
Custom printable certificates

Honour your top performers, or encourage a student who's trying hard — ready to print in seconds.

Add to class →

Quick Questions

1. A developer guessed a data-cleaning task would take 1 day, but it took 4 days, so the plan was changed. How should this change be judged?
A. Unavoidable: it was outside the developer's control
B. Avoidable: a poor estimate is a planning problem ✓
Poor estimation is within the developer's control. Better planning, such as checking how messy the data was, could have prevented the change.
2. Midway through the project, the client asks for a new dashboard page and the plan is changed. How should this change be judged?
A. Unavoidable: the new requirement came from outside the developer ✓
B. Avoidable: the developer should have predicted it
Changed requirements from a client are usually outside the developer's control, so the change is unavoidable.
3. Which reason would make a plan change AVOIDABLE?
A. The developer forgot to include a testing task in the plan ✓
B. The data supplier sent the file two weeks late
Leaving out a needed task is poor planning, so it was avoidable. A late file from a supplier is outside the developer's control.
4. The spreadsheet software crashes and corrupts the file, so tasks are repeated and the plan is adjusted. How is this change usually judged?
A. Unavoidable: an unexpected problem outside the developer's control ✓
B. Avoidable: it was caused by poor estimation
A sudden fault the developer could not predict is an unexpected problem, so it is unavoidable. Having regular backups would only reduce the damage.
5. A developer set aside no time to learn pivot tables, then needed an extra 3 days to learn them. What kind of change is this?
A. Unavoidable: new skills can never be planned
B. Avoidable: a skills gap should have been planned for ✓
Identifying the skills needed and allowing time to learn them is part of good planning, so this change was avoidable.

Match the Pairs

Task 3 took 6 days, not the 2 days estimated → Avoidable change: poor estimation could have been prevented with better planning
Client adds a new report after sign-off → Unavoidable change: changed requirements from outside the developer's control
A change is avoidable when better planning, such as checking task times first, would have prevented it → Reason: poor estimate, no time added for testing, so avoidable
A change is unavoidable when an unexpected problem outside the developer's control forces it → Reason: data supplier sent the file 5 days late, so unavoidable
Change: the client changed the requirements. Judgement: avoidable, because the developer should have planned better → Changed requirements come from outside the developer's control, so the change is unavoidable, not avoidable
Change: tasks ran over because the developer guessed the times. Judgement: unavoidable → Guessing task times is poor estimation within the developer's control, so the change is avoidable, not unavoidable

Key Term

avoidable or unavoidable change
A change is avoidable if better planning, such as a poor estimate, could have prevented it. It is unavoidable if it came from outside the developer's control, like new requirements.

Fill in the Blanks

1. IF reason = poorEstimate THEN SET type TO AVOIDABLE END IF
Hint: Type the label for a change that better planning could have prevented.
2. IF reason = changedRequirements THEN SET type TO UNAVOIDABLE END IF
Hint: Type the label for a change that came from outside the developer's control.
3. IF reason = unexpectedProblem THEN SET type TO UNAVOIDABLE END IF
Hint: Type the operator that compares the reason with a value.
4. IF reason = poorEstimate THEN SET type TO AVOIDABLE END IF
Hint: Type the reason name for a task that was given too little time at the planning stage.
5. IF type = AVOIDABLE THEN OUTPUT "Improve the estimate next time" END IF
Hint: Type the pseudocode keyword that shows a message to the user.

Spot the Error

Question 1
A change = "Took 5 days, not 2"
B cause = "poor estimation"
C type = "unavoidable"
Line C — The task took longer than planned because the developer estimated badly. Better planning could have prevented it, so the change is avoidable, not unavoidable.
Question 2
A change = "Client added chart"
B cause = "new requirements"
C outside_control = TRUE
D type = "avoidable"
Line D — A client adding new requirements is outside the developer's control, so the change is unavoidable. The type should be "unavoidable".
Question 3
A change = "Server crashed"
B cause = "unexpected problem"
C outside_control = FALSE
D type = "unavoidable"
Line C — A server crash is an unexpected problem the developer could not control. outside_control should be TRUE, which is what makes the change unavoidable.
Question 4
A change = "Estimate too low"
B cause = "new requirements"
C could_plan_better = TRUE
D type = "avoidable"
Line B — The change happened because the estimate was too low, so the cause is poor estimation. Naming new requirements as the cause contradicts line 1 and the avoidable type.
Question 5
A cause = "unexpected problem"
B change = "Took 6 days, not 3"
C outside_control = FALSE
D type = "avoidable"
Line A — The task took twice as long as planned, which is a poor estimate. The cause should be "poor estimation", which fits an avoidable change that was within the developer's control.

Student with a class code? Join your class →