C01 Overflow Activities
Useful but non-essential activities for C01 (Design Brief and Project Management). These can be used as extension work, early finisher tasks, or alternative approaches.
Extension: Feasibility Deep Dive (T.E.L.O.S.)
For students who finish their design brief early and want to strengthen their feasibility argument.
Activity: Work through each T.E.L.O.S. dimension for your project:
| Dimension | Question to answer |
|---|---|
| Technical | Do you have the skills and tools to build this? What will you need to learn? |
| Economic | What resources does this need? Is it achievable with school resources? |
| Legal | Any data privacy issues? Licensing concerns for libraries/assets? |
| Operational | Will your target users actually use this? How does it fit into their routine? |
| Scheduling | Can you build this in the available time? What would you cut if you run out of time? |
Write 2-3 sentences per dimension. This strengthens the feasibility section of the design brief and prepares students for probing questions in the C1-1 presentation.
Time: ~20 min
Extension: Comparative Brief Analysis
For students who want to understand what separates a strong brief from a weak one.
Activity: Read the Adem's Gym example and the NiceQuiz example. Create a comparison table:
| Aspect | Brief A | Brief B | Which is stronger and why? |
|---|---|---|---|
| Problem statement | |||
| User description | |||
| Language justification | |||
| Feasibility argument |
Discuss with a partner. Could you improve the weaker brief? What would you change?
Time: ~15 min
Extension: Mock Interview (Peer)
For students who finish Checkpoint C early and want to practice for the C1-3 interview.
Activity: Pair up. One student is the "teacher," one is the "student." The teacher uses this question progression:
- "Walk me through your project plan from start to finish."
- "Why does [specific task] come before [other task]?"
- "Show me a dependency. What happens if the first task is delayed by a week?"
- "Where is your critical path? How did you identify it?"
- "How will you know if your project is falling behind? What will you do about it?"
Swap roles after 10 minutes. Give each other feedback: what was convincing? Where did you hesitate?
Time: ~20 min (10 min each way)
Extension: Risk Register
For students who want to push into high-level monitoring and planning.
Activity: Create a simple risk register for your project:
| Risk | Likelihood (H/M/L) | Impact (H/M/L) | Mitigation |
|---|---|---|---|
| e.g., "Can't learn API in time" | M | H | "Start with simpler version, add complexity later" |
Identify 3-5 risks. For each, explain how your project plan accounts for it (or doesn't). This is excellent preparation for the C1-3 interview question about monitoring.
Time: ~15 min
Alternative: Hand-Drawn Gantt Chart
If GitHub Projects is causing technical issues or a student works better on paper.
Activity: Draw a Gantt chart by hand on A3 paper:
- X-axis: weeks (Term 2 and Term 3)
- Y-axis: tasks grouped by PSM stage
- Use coloured bars for each stage
- Mark milestones with diamonds
- Draw dependency arrows between tasks
Photograph and commit to GitHub. This satisfies the "using software" requirement if they then transfer it to GitHub Projects, or it can serve as their annotated plan for C1-3.
Time: ~25 min
Alternative: Design Brief as a Pitch
Instead of a formal written brief, the student creates a 1-page "pitch document" — visual, concise, designed to convince someone to fund/support the project. They still need to cover all the same content (problem, solution, users, language, feasibility) but in a more visual format.
This can be done in addition to the formal brief as presentation preparation. The visual format forces students to distil their thinking.
Time: ~20 min
Ongoing: AI Disclosure Log Prompts
Quick prompts students can use to update their AI disclosure log throughout C01:
- "I asked AI to..." — What was the prompt?
- "AI produced..." — What did it generate?
- "I kept / changed / rejected..." — What did you do with it?
- "Because..." — Why?
Example entry:
I asked Claude to draft a feasibility section for my design brief. It produced a paragraph about technical feasibility using Python and fasthtml. I kept the structure but rewrote the specific details because Claude didn't know about Godot's limitations for my game project. I also added scheduling feasibility which Claude didn't mention.
Remind students: the log isn't assessed separately, but it's required evidence and strengthens their interview responses.