The C05-3 step "Plan B Ready" asks you to show that you have thought about what could go wrong and prepared a specific alternative. The most common problem: students write "I'll think of another way" — which is not a contingency plan, it is a placeholder.

This page gives you a pre-filled Markdown table to copy into your design log. The risk prompts are specific enough to force real thinking, but they do not hint at solutions — that part is yours.

---

Copy this table into your design log or SAT submission document. Fill in the **Contingency / Backup design** and **Impact if triggered** columns for every row. Delete rows that genuinely do not apply to your project and add rows for risks you can identify from your own scope.

| Risk | Trigger (when does this become a problem?) | Contingency / Backup design | Impact if triggered |

|---|---|---|---|

| **Library / package incompatibility** | A required library does not install on the target machine, or breaks after an update | | |

| **Scope creep** | Client or teacher requests a feature not in the original functional requirements, mid-project | | |

| **UI testing failure** | Beta-testing reveals a screen layout or workflow that users cannot navigate without assistance | | |

| **API or data-source change** | An external API changes its format, is rate-limited, or goes offline | | |

| **Client pivot** | The client changes the core purpose or target audience of the solution after designs are approved | | |

| **Time overrun on a critical task** | A core module (e.g. database integration, user authentication) takes longer than the project plan allows | | |

---

A contingency is a **specific alternative action**, not a vague reassurance.

| Weak (no marks) | Strong (marks) |

|---|---|

| "I'll fix it if it happens" | "Revert to the previous pinned library version and document the version in `requirements.txt`" |

| "I'll think of another way" | "Remove the feature from scope and document the decision in the design log; notify client in writing" |

| "I'll ask my teacher" | "Replace the external API with a locally-stored JSON dataset that mirrors the last-known good API response" |

Name **two things**: the scope impact (what feature or quality is affected) and the timeline impact (how many days or steps are delayed).

---

| Risk | Trigger | Contingency / Backup design | Impact if triggered |

|---|---|---|---|

| **Library incompatibility** | `nicegui` fails to install on school computers | Switch to `tkinter` (Python standard library; no install needed); redesign affected screens in the week before submission | UI redesign costs 1–2 days; appearance is less polished but all functional requirements are met |

| **Scope creep** | Client requests a report-export feature not in the original brief | Log the request in the design log; defer to post-submission iteration and document in the contingency section of the evaluation | No timeline impact; manage client expectation in writing |

| **UI testing failure** | Peer-testing reveals the member-search screen is unusable without prompting | Replace the free-text search field with a dropdown populated from the database; re-test with the same tester | 1 day to rebuild the search component; re-test adds half a day |

| **Time overrun** | Database integration takes longer than the 3-day Gantt allocation | Simplify the data model: flatten the member table, remove the `events` table, and hard-code event dates for the demo | Core membership features still functional; event tracking deferred |

---

Think about the specific libraries, APIs, and features in *your* project. Add a row for any risk that would force a design change — not just a bug fix. Good custom risk prompts for student projects:

- "My chosen GUI framework does not support [specific feature]"

- "The school network blocks the API endpoint I rely on"

- "My only tester (client) is unavailable in the final two weeks"

- "I discover mid-build that the data structure I chose makes [key feature] impractical"

---

- [C05 Resources](/sd/Resources/C05-Resources) — external reading on critical and creative thinking in software design

---

← Back to [C05 Home](/sd/C05/C05-home) · [VCE Software Development Hub](/sd/VCE%20Software%20Development%20Hub)