Judging the reason changes to a project plan were necessary

Name:

Date:

Class:

Quick Questions

Shade in the A or B circle for each question.

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

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

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

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

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

Match the Pairs

Draw a line connecting each item on the left to its match on the right.

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

Definitions

avoidable or unavoidable change

Fill in the Blanks

Complete each line of code by filling in the missing parts.

IF reason = poorEstimate THEN SET type TO _________ END IF

IF reason = changedRequirements THEN SET type TO ___________ END IF

IF reason _ unexpectedProblem THEN SET type TO UNAVOIDABLE END IF

IF reason = ____________ THEN SET type TO AVOIDABLE END IF

IF type = AVOIDABLE THEN ______ "Improve the estimate next time" END IF

Spot the Error

Shade in the letter of the line that contains an error.

Question 1

A change = "Took 5 days, not 2"

B cause = "poor estimation"

C type = "unavoidable"

Question 2

A change = "Client added chart"

B cause = "new requirements"

C outside_control = TRUE

D type = "avoidable"

Question 3

A change = "Server crashed"

B cause = "unexpected problem"

C outside_control = FALSE

D type = "unavoidable"

Question 4

A change = "Estimate too low"

B cause = "new requirements"

C could_plan_better = TRUE

D type = "avoidable"

Question 5

A cause = "unexpected problem"

B change = "Took 6 days, not 3"

C outside_control = FALSE

D type = "avoidable"

Answer Key

Judging the reason changes to a project plan were necessary

Section A: Quick Questions

B — Avoidable: a poor estimate is a planning problem

A — Unavoidable: the new requirement came from outside the developer

A — The developer forgot to include a testing task in the plan

A — Unavoidable: an unexpected problem outside the developer's control

B — Avoidable: a skills gap should have been planned for

Section B: 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

Section C: Definitions

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.

Section D: Fill in the Blanks

IF reason = poorEstimate THEN
  SET type TO AVOIDABLE
END IF

IF reason = changedRequirements THEN
  SET type TO UNAVOIDABLE
END IF

IF reason = unexpectedProblem THEN
  SET type TO UNAVOIDABLE
END IF

IF reason = poorEstimate THEN
  SET type TO AVOIDABLE
END IF

IF type = AVOIDABLE THEN
  OUTPUT "Improve the estimate next time"
END IF

Section E: Spot the Error

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.

D — A client adding new requirements is outside the developer's control, so the change is unavoidable. The type should be "unavoidable".

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.

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.

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.