Chapter 25 — Team project studio
Lesson map
Lesson 25 published. Map, example, EX073.
flowchart TD
N0["Learning outcomes"]
N1["25.1 The studio task"]
N2["25.2 Roles and coordination"]
N3["25.3 Peer review"]
N4["25.4 Adapting to context"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Worked example"]
EX --> Q["Exercise EX073"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["25.1 The studio task"]
N2["25.2 Roles and coordination"]
N3["25.3 Peer review"]
N4["25.4 Adapting to context"]
N5["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX073"]
[Learning outcomes]
|
v
[25.1 The studio task]
|
v
[25.2 Roles and coordination]
|
v
[25.3 Peer review]
|
v
[25.4 Adapting to context]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX073]
Learning outcomes
You will (1) work in a team on a network design; (2) divide roles; (3) review each other's work.
25.1 The studio task
In the second year, Ms Okafor runs a team studio. Tomás's team of four designs network security for a fictional primary school with similar needs but no technician, relying on a managed service provider. The team must produce a zone design, needed flows, rules, a monitoring plan and a handover pack for the provider. The task tests whether students can apply what they learned at Ridgeway to a new context with different constraints. Each team presents its design to classmates and Ms Okafor at the end of term for questions and marks.
25.2 Roles and coordination
The team divides roles: one leads the zone design, one the rules, one monitoring and one documentation, with Tomás coordinating. They meet twice a week, track tasks on a shared board and keep decisions in a log. Clear roles avoid duplicated effort, but the team also agrees that everyone reviews everything, so knowledge is shared. Coordination takes time, but without it, pieces designed separately often fail to fit together. Roles rotate halfway through so everyone experiences each part of the design work.
25.3 Peer review
Each team member's work is reviewed by another. Reviewing the rules, Tomás finds a rule allowing the provider remote access to every zone, which contradicts the design's principle of narrow supplier access. The author explains it was a placeholder; it is replaced with specific flows. Reviews catch such errors because reviewers read what was written, not what was intended. The team keeps review comments and responses in the log, showing how the design improved. Reviews follow a short checklist of common errors.
25.4 Adapting to context
The primary school has no technician, so the design must be simpler than Ridgeway's and rely on the provider. The team reduces zones to four, chooses a provider-managed firewall with clear reporting and writes a one-page guide for the head teacher on what to check monthly. Adapting a design to a different context, rather than copying it, is a key professional skill, and the studio deliberately chose a context that forced such adaptation. The guide is tested by a parent volunteer who reads it cold.
Worked example
The team's design uses four zones, eleven flows and a monthly checklist for the head teacher.
Synthetic case. The studio school is fictional.
Errors and limits
Copying a design from one organisation to another without adapting it to staff and context leads to failure.
Exercises
- EX073 — Placeholder rule. What did Tomás find in peer review? Rubric: 3 = provider remote access to every zone;; 2 = broad rule;; 1 = vague;; 0 = none.
- EX074 — Fewer zones reason. Why does the primary school design use four zones? Rubric: 3 = no technician, simpler to run;; 2 = simpler;; 1 = cheaper;; 0 = none.
- EX075 — Everyone reviews. Why does everyone review everything despite divided roles? Rubric: 3 = shared knowledge, pieces fit;; 2 = sharing;; 1 = slow;; 0 = none.
Synthesis
Team studios practise coordination, peer review and adaptation of designs to new contexts.
Continue studying — chapter 25 of 30
← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →