> **DRAFT** — under teacher review. # Plan B Contingency Table — Reusable Template The Hamilton and Alexandra College · Year 12 · 2026 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. --- ## The template 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. ```markdown | 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 | | | ``` --- ## How to fill it in ### What makes a good Contingency / Backup design entry 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" | ### What makes a good Impact if triggered entry Name **two things**: the scope impact (what feature or quality is affected) and the timeline impact (how many days or steps are delayed). > Example: "Login feature delayed by 1–2 days; authentication falls back to a single shared password stored in `config.ini` until resolved." --- ## Completed example (ClubTracker project) | 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 | --- ## Adding your own risks 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" --- ## See also - [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)