Chapter 25 — Team project studio
Lesson map
Lesson 25 published. Map, example, EX073.
flowchart TD
N0["Learning outcomes"]
N1["25.1 The project"]
N2["25.2 Dividing work"]
N3["25.3 Reviews"]
N4["25.4 Communication"]
N5["25.5 Client voice"]
N6["25.6 Result"]
N7["Working agreement"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX073"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["25.1 The project"]
N2["25.2 Dividing work"]
N3["25.3 Reviews"]
N4["25.4 Communication"]
N5["25.5 Client voice"]
N6["25.6 Result"]
N7["Working agreement"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX073"]
[Learning outcomes]
|
v
[25.1 The project]
|
v
[25.2 Dividing work]
|
v
[25.3 Reviews]
|
v
[25.4 Communication]
|
v
[25.5 Client voice]
|
v
[25.6 Result]
|
v
[Working agreement]
|
v
[Worked example] --> [Exercise EX073]
Learning outcomes
You will (1) work in a team on a shared security improvement; (2) divide work; (3) review each other's output.
25.1 The project
Priya joins two other placement students to build a client-ready security summary page generated from the inventory and baseline results. The page answers a question clients keep asking account managers: how secure is our system today? It reuses outputs Priya already produced, the inventory and baseline results, so the page shows evidence rather than claims. Each client sees only their own systems, and the page is generated from the same data the platform team uses internally. The three students agree that the page must not show anything the client could not already ask for.
25.2 Dividing work
One builds the data export, one the page, and Priya the checks and wording. Dividing the work along these lines gives each student a clear output and a clear interface: the export produces a data file, the page reads it, and Priya's checks and wording decide what each status means and how it is described. Agreeing the data file's format early lets the three parts be built in parallel without waiting for each other. Priya's part also includes testing that each status matches the underlying results.
25.3 Reviews
Each change is reviewed by another student and Kwame before merge. Reviews by a fellow student catch unclear code and wording, while Kwame's review checks that the page reveals nothing it should not, such as internal image names, and reads data in the intended read-only way. A change that touches the wording also gets read aloud once, because text that sounds clear to its author can still confuse a client. No change merges without both reviews, including small wording changes made late in the project.
25.4 Communication
A short daily note lists progress and blockers. Each note fits in three lines: what was done yesterday, what is planned today and what is blocking progress. Blockers named in the notes reach Kwame without a meeting, and he resolves those that need more access. The notes also give the retrospective a written record of when problems appeared and how long they lasted. When a blocker lasts more than a day, it is raised directly with Kwame rather than repeated in notes. That rule comes from the working agreement the team signed at the start.
25.5 Client voice
They show a draft to Riverside Dental's practice manager, who asks for plain words and fewer numbers. The first draft showed baseline check names and counts, which made sense to the platform team but not to a dental practice manager. Her feedback changes the page's purpose from reporting checks to explaining status: what is fine, what is being fixed and when. The numbers remain available behind each line for staff who want them. The team rewrites every status line after this meeting, starting with the ones about baseline checks.
25.6 Result
The final page shows status in three colours with a one-line explanation each. Each colour carries a text label as well, and each explanation names what the status means for the client in plain words, such as when a fix is scheduled. The page is regenerated from the latest inventory and baseline results, so it stays current without anyone editing it by hand. Account managers now use the page in their regular client service reviews. The practice manager confirms that she can read the page without needing anyone to explain it.
Working agreement
At the start, the team agrees on working hours, how to raise problems and how decisions are made. When two members disagree about page colours, they follow the agreement: try both with the client and pick the clearer one. The agreement prevents small disputes from slowing the project.
Kwame reviews progress weekly and helps when a blocker needs someone with more access.
Accessibility
The page uses text labels as well as colours, so it works for readers who cannot distinguish colours.
Security of the page
The summary page is only available to logged-in client staff, since it describes the client's systems.
Retrospective
At the end, the team lists what worked, such as daily notes, and what did not, such as late client feedback. They agree that showing a draft to the client in the first week would have saved rework.
Final demo
The team demonstrates the page to Kwame and the account managers, who adopt it.
Worked example
A teammate's draft says "CIS non-compliant". The manager does not understand it. Priya rewrites it as "two settings differ from our standard; fixes are scheduled for next week".
Synthetic case. Project is synthetic.
Errors and limits
Team projects slow down without clear ownership.
Exercises
- EX073 — Roles. How was the work divided? Rubric: 3 = export, page, checks and wording; 2 = two; 1 = one; 0 = none.
- EX074 — Client feedback. What did the practice manager ask for? Rubric: 3 = plain words, fewer numbers; 2 = partial; 1 = vague; 0 = none.
- EX075 — Rewrite. How was "CIS non-compliant" rewritten? Rubric: 3 = two settings differ; fixes scheduled; 2 = partial; 1 = vague; 0 = none.
Synthesis
Shared work needs owners, reviews and the reader's language.
Continue studying — chapter 25 of 30
← Chapter 24 (draft) · Course chapter index · Chapter 26 (draft) →