# Project Board (ClickUp-style) — Full Lab Series **Tool:** Project Board (ClickUp-style) — in-house kanban simulator **Tool key:** `clickup-pm` **What the simulator actually gives you:** three columns (To Do / In Progress / Done), text-based cards you drag between columns, an "+ Add card" button per column, double-click on a card to delete it, and a "Save This Board as a Project" button that stores your columns + cards under a title you choose. Because cards are plain text, this series teaches you to *encode* real PM information (owner, priority, phase, blockers) into the card title itself — a skill you'll actually need, because most simplified boards, and plenty of real ones, work exactly this way. --- ## Lab 1 (Beginner): Your First Task Board **What you're practicing:** the absolute basics of day-to-day task-board management for a project coordinator — creating tasks, giving them an owner and status, and moving them honestly through a workflow. **Estimated time:** 20–30 minutes **Prerequisites:** none — this is the entry point for the tool. ### Setup 1. Click **Open** to launch the board. You'll see three columns already seeded with a few example cards — leave them for now, you'll replace them shortly. 2. Pick a small project you actually understand well enough to run start-to-finish. It does not need to be a real work project — a hobby project works just as well and is often easier to reason about. Examples if you're stuck: "Plan a weekend trip," "Launch a personal blog," "Organise a small event," "Redecorate a room." 3. Write your project's name down somewhere (you'll need it for the save step). Keep it in mind for every task you create. ### Step-by-step 1. **Clear the sample cards.** Double-click each seeded card ("Set up project brief," "Interview stakeholders," etc.) and confirm deletion. Start from an empty board — this forces you to think about *your* project rather than editing someone else's. 2. **Create 6–8 tasks for your project.** Click **+ Add card** in the "To Do" column for each one. Spread them across the columns as makes sense — most should start in "To Do." 3. **Give every task a clear owner in the title.** Since a card is just text, adopt a simple convention and use it consistently, e.g.: `Book venue — Owner: Sarah` Even if you're a one-person team, invent 2–3 fictional owners and assign tasks across them. Real boards fall apart the moment "owner" is ambiguous — practice never leaving it blank. 4. **Give every task an implied status via its column**, not just its title. A task's column *is* its status. Resist the urge to write "DONE" in a card title that's sitting in "To Do" — if it's not moved, it's not done, no matter what the text says. 5. **Move tasks through the workflow as they would actually progress.** Drag at least 2 tasks into "In Progress" and at least 1 into "Done." Do this deliberately, one at a time, narrating to yourself why each task is ready to move. 6. **Watch for pile-up.** After you've moved a few cards, look at which column has the most cards sitting in it. In almost every real board, one column becomes a bottleneck. Note which one it is for you and write one sentence on *why* you think tasks are stalling there (waiting on a decision? blocked by another task? just genuinely hard?). 7. **Add one task partway through that you didn't originally think of.** Real projects always surface forgotten work. Notice how it feels to slot it into an already-organized board — this is normal, not a sign you planned badly. 8. **Save your board.** Click **Save This Board as a Project** and give it a specific title (not "My Board" — something like "Weekend Trip Planning — Board v1"). ### Reflection (write 2–3 sentences) - Which column ended up with the most cards, and why? - Did giving tasks explicit owners change how you thought about the work, even in a fictional exercise? ### Success checklist - [ ] Board has at least 6 tasks, each with an owner named in the title - [ ] At least one task is in each of the three columns - [ ] At least one unplanned task was added mid-exercise - [ ] Board saved with a specific, descriptive title **Tip:** a task board is only useful if it's kept honest — update status as things *actually* change, not in a big batch at the end. Batch-updating a board right before a status meeting is a classic sign the board wasn't really being used. --- ## Lab 2 (Intermediate): A Multi-Phase Project with Simulated Dependencies **What you're practicing:** running a project with distinct phases, priorities, and dependency discipline — the point where a task board stops being a to-do list and starts being a *project* management tool. **Estimated time:** 35–45 minutes **Prerequisites:** Lab 1 (or comparable familiarity with the board's drag/drop and add/delete mechanics). ### Setup 1. Click **Open** to launch a fresh board (or reopen your Lab 1 project if the tool allows continuing it — otherwise start clean). 2. Choose a project big enough to have **at least 3 distinct phases**. Examples: a website relaunch (Discovery → Build → Launch), an event (Planning → Execution → Wrap-up), a home renovation (Design → Construction → Finishing). 3. Since this board has no native "phase" field, decide on a title convention up front and write it down before you start adding cards, e.g.: `[Phase] Task name — Owner: X — Priority: High/Med/Low` ### Step-by-step 1. **Build the full task list before touching the board.** On paper or in a notes app, list every task you expect across all 3 phases. Aim for at least 3–4 tasks per phase (9–12 total). Planning this outside the tool first mirrors how real project scoping works — you don't discover the whole plan by dragging cards around. 2. **Add every task to the board using your title convention.** Every card should show phase, owner (even fictional), and priority. Example: `[Planning] Book venue — Owner: Sarah — Priority: High` 3. **Assign a rough priority to each task**, thinking honestly about what would actually block launch versus what's nice-to-have. Not everything can be "High" — if more than a third of your tasks are High priority, go back and re-triage; that's a sign priority isn't doing its job. 4. **Simulate dependency by holding a later phase back.** This board has no built-in dependency logic, so you enforce it yourself: keep every task from Phase 2 and Phase 3 sitting in "To Do" and *do not* move any of them into "In Progress" until the key tasks from the phase before it are in "Done." Pick 2–3 "key" tasks per phase that count as the real gate — not every task needs to block, just the ones that genuinely do in a real project. 5. **Run the project forward.** Move Phase 1 tasks through In Progress → Done at a pace that feels realistic (don't finish everything in one pass — do it in at least 3 separate rounds of movement, as if separate days had passed). Once your Phase 1 "key" tasks are Done, start releasing Phase 2 tasks into In Progress. 6. **Introduce scope change.** Midway through — ideally once Phase 2 is underway — add **2 new tasks** that were not in your original plan. Assign them a phase, owner, and priority like everything else. Notice: do they fit cleanly into an existing phase, or do they expose that your original phase boundaries were fuzzier than you thought? 7. **Find and split an oversized task.** Look at your board for any task that's been sitting in "In Progress" the longest, or that you suspect is really two tasks glued together. Delete it and re-add it as two smaller, more specific tasks. This is a habit worth over-practicing: a task that lingers in "In Progress" for too long is almost always secretly two or three tasks. 8. **Save your board** with a title that reflects it's the multi-phase version, e.g. "Website Relaunch — Full Project Board." ### Reflection (write 3–4 sentences) - Which "key" tasks did you choose as phase gates, and would a real team agree those were the right ones to block on? - What did the 2 unplanned tasks reveal about gaps in your original phase plan? - Where did enforcing dependency manually (by *not* moving cards) feel artificial compared to how a real PM tool would handle it? What would you want the tool to do automatically instead? ### Success checklist - [ ] At least 9 tasks across 3 clearly labeled phases - [ ] Every task has an owner and a priority in its title - [ ] At least one phase was deliberately held back until a prior phase's key tasks were Done - [ ] 2 unplanned tasks were added mid-project - [ ] At least one oversized task was identified and split into two - [ ] Board saved with a phase-aware title **Tip:** almost every real project gains new tasks partway through, and almost every board eventually has one task that's secretly too big. Practicing how you absorb both — without throwing out your original plan — is a more realistic skill than trying to design a "perfect" board upfront. --- ## Lab 3 (Expert): Full Simulation + Stakeholder Status Report **What you're practicing:** the deliverable that actually matters to a project coordinator's manager — a clear, concise status report written from a board a stakeholder has never seen, plus honest reasoning about risk. **Estimated time:** 45–60 minutes **Prerequisites:** Lab 2 (this lab assumes a multi-phase board already exists, or you build one fresh to the same standard). ### Setup 1. Open your Lab 2 board if you still have it, or build a comparable one from scratch: at least 3 phases, owners and priorities in every card title, and at least one deliberately-blocked dependency. 2. This lab has two deliverables: **(a)** a board pushed to roughly the midpoint of the project, and **(b)** a written status report. Budget time for both — the writing is the harder half. ### Part A — Get the project to midpoint 1. **Advance the board to approximately 50% completion.** A rough rule: about half your total tasks should be in "Done," a handful actively "In Progress," and the rest still "To Do," including anything correctly still gated behind an earlier phase. 2. **Deliberately create one blocked task.** Pick a task that's stuck — not moving forward — because it's waiting on something outside your control (a decision, an external vendor, another team). Mark it clearly in the title, e.g.: `[Build] Integrate payment API — Owner: Dele — Priority: High — BLOCKED: waiting on vendor API keys` 3. **Introduce one at-risk item that hasn't fully blocked yet but could.** This is different from a blocker — it's a task or dependency that's still moving but is trending late or fragile. Note it in the title or keep a short separate note, e.g. "Design sign-off — running 3 days behind, no blocker yet but watch this." 4. **Save this mid-project state** as its own project, titled something like "Website Relaunch — Midpoint Checkpoint," so you have a clear snapshot to write the report from. ### Part B — Write the stakeholder status report Write this as if sending it to a manager or client who has **not** seen the board and does not have time to look at it. 1. **Lead with the headline, in the first sentence.** State plainly: On track / At risk / Blocked. Do not make a busy reader dig through details to find this out — it should be unmissable in sentence one. 2. **Summarize what's Done**, in one or two sentences — group related finished tasks rather than listing every card individually. A stakeholder doesn't need a card-by-card readout. 3. **Summarize what's In Progress**, again grouped, focusing on what's actively moving rather than everything technically "started." 4. **Name what's Blocked and why**, using the blocked task from Part A. Be specific about what's needed to unblock it and who owns resolving it (even if that's outside your fictional team). 5. **Name one risk you're watching** — the at-risk item from Part A. State what could happen if it's not addressed, and what you (or your fictional team) are doing about it. A risk without a mitigating action reads as an excuse, not a status update — always pair the two. 6. **Keep the entire report under 150 words.** This is a hard constraint, not a suggestion. Draft first without worrying about length, then cut. Removing detail a busy reader doesn't need is the actual skill being practiced here — not fitting more in. 7. **Read it back once and cut anything that doesn't serve the headline.** If a sentence doesn't help the reader understand "are we on track, and what do you need from me," cut it. ### Part C — Compare and reflect 8. **Compare this project to your Lab 2 board** (or an OpenProject-style board if you've tried that tool too). Write one sentence on which style of board you'd actually recommend to a small team, and why — there's no single right answer; the point is having a reasoned opinion. 9. **Save your final board state and your written status report together** as your final project for this tool. If the platform doesn't have a field for the report text, paste it into the board itself as a final card, or save it as a companion note alongside your project title. ### Reflection (write 3–5 sentences) - Did writing the status report change how you'd have organized the board if you'd known from the start you'd need to summarize it for someone else? - Was it harder to name the risk honestly, or to keep the report under 150 words? What does that tell you about your instincts as a communicator? ### Success checklist - [ ] Board pushed to a realistic midpoint (~50% Done, some In Progress, rest correctly gated) - [ ] One clearly blocked task with a named blocker and owner - [ ] One clearly at-risk (not yet blocked) item identified - [ ] Status report leads with an unambiguous headline in sentence one - [ ] Report covers Done / In Progress / Blocked / Risk, all grouped rather than card-by-card - [ ] Report is under 150 words - [ ] One sentence comparing this tool/workflow to an alternative PM-style board - [ ] Final board + report saved together **Tip:** a good status report leads with the answer — on track, at risk, or blocked — in the first sentence. Don't make a busy reader work through details to find the headline themselves. This single habit is the difference between a status update people actually read and one they skim past. --- ## Quick reference: title conventions used across this series | Element | Convention | Example | |---|---|---| | Owner | `— Owner: Name` | `— Owner: Sarah` | | Priority | `— Priority: High/Med/Low` | `— Priority: High` | | Phase | `[Phase Name]` prefix | `[Build]` | | Blocked | `— BLOCKED: reason` | `— BLOCKED: waiting on vendor API keys` | | At-risk | free-text note in title or a companion note | `running 3 days behind, no blocker yet` | Since the simulator only stores plain-text card titles, consistency in how you encode this information is itself part of the skill — a board where every card uses a different convention is exactly as unusable as one with no convention at all.# Project Board (ClickUp-style) — Full Lab Series **Tool:** Project Board (ClickUp-style) — in-house kanban simulator **Tool key:** `clickup-pm` **What the simulator actually gives you:** three columns (To Do / In Progress / Done), text-based cards you drag between columns, an "+ Add card" button per column, double-click on a card to delete it, and a "Save This Board as a Project" button that stores your columns + cards under a title you choose. Because cards are plain text, this series teaches you to *encode* real PM information (owner, priority, phase, blockers) into the card title itself — a skill you'll actually need, because most simplified boards, and plenty of real ones, work exactly this way. --- ## Lab 1 (Beginner): Your First Task Board **What you're practicing:** the absolute basics of day-to-day task-board management for a project coordinator — creating tasks, giving them an owner and status, and moving them honestly through a workflow. **Estimated time:** 20–30 minutes **Prerequisites:** none — this is the entry point for the tool. ### Setup 1. Click **Open** to launch the board. You'll see three columns already seeded with a few example cards — leave them for now, you'll replace them shortly. 2. Pick a small project you actually understand well enough to run start-to-finish. It does not need to be a real work project — a hobby project works just as well and is often easier to reason about. Examples if you're stuck: "Plan a weekend trip," "Launch a personal blog," "Organise a small event," "Redecorate a room." 3. Write your project's name down somewhere (you'll need it for the save step). Keep it in mind for every task you create. ### Step-by-step 1. **Clear the sample cards.** Double-click each seeded card ("Set up project brief," "Interview stakeholders," etc.) and confirm deletion. Start from an empty board — this forces you to think about *your* project rather than editing someone else's. 2. **Create 6–8 tasks for your project.** Click **+ Add card** in the "To Do" column for each one. Spread them across the columns as makes sense — most should start in "To Do." 3. **Give every task a clear owner in the title.** Since a card is just text, adopt a simple convention and use it consistently, e.g.: `Book venue — Owner: Sarah` Even if you're a one-person team, invent 2–3 fictional owners and assign tasks across them. Real boards fall apart the moment "owner" is ambiguous — practice never leaving it blank. 4. **Give every task an implied status via its column**, not just its title. A task's column *is* its status. Resist the urge to write "DONE" in a card title that's sitting in "To Do" — if it's not moved, it's not done, no matter what the text says. 5. **Move tasks through the workflow as they would actually progress.** Drag at least 2 tasks into "In Progress" and at least 1 into "Done." Do this deliberately, one at a time, narrating to yourself why each task is ready to move. 6. **Watch for pile-up.** After you've moved a few cards, look at which column has the most cards sitting in it. In almost every real board, one column becomes a bottleneck. Note which one it is for you and write one sentence on *why* you think tasks are stalling there (waiting on a decision? blocked by another task? just genuinely hard?). 7. **Add one task partway through that you didn't originally think of.** Real projects always surface forgotten work. Notice how it feels to slot it into an already-organized board — this is normal, not a sign you planned badly. 8. **Save your board.** Click **Save This Board as a Project** and give it a specific title (not "My Board" — something like "Weekend Trip Planning — Board v1"). ### Reflection (write 2–3 sentences) - Which column ended up with the most cards, and why? - Did giving tasks explicit owners change how you thought about the work, even in a fictional exercise? ### Success checklist - [ ] Board has at least 6 tasks, each with an owner named in the title - [ ] At least one task is in each of the three columns - [ ] At least one unplanned task was added mid-exercise - [ ] Board saved with a specific, descriptive title **Tip:** a task board is only useful if it's kept honest — update status as things *actually* change, not in a big batch at the end. Batch-updating a board right before a status meeting is a classic sign the board wasn't really being used. --- ## Lab 2 (Intermediate): A Multi-Phase Project with Simulated Dependencies **What you're practicing:** running a project with distinct phases, priorities, and dependency discipline — the point where a task board stops being a to-do list and starts being a *project* management tool. **Estimated time:** 35–45 minutes **Prerequisites:** Lab 1 (or comparable familiarity with the board's drag/drop and add/delete mechanics). ### Setup 1. Click **Open** to launch a fresh board (or reopen your Lab 1 project if the tool allows continuing it — otherwise start clean). 2. Choose a project big enough to have **at least 3 distinct phases**. Examples: a website relaunch (Discovery → Build → Launch), an event (Planning → Execution → Wrap-up), a home renovation (Design → Construction → Finishing). 3. Since this board has no native "phase" field, decide on a title convention up front and write it down before you start adding cards, e.g.: `[Phase] Task name — Owner: X — Priority: High/Med/Low` ### Step-by-step 1. **Build the full task list before touching the board.** On paper or in a notes app, list every task you expect across all 3 phases. Aim for at least 3–4 tasks per phase (9–12 total). Planning this outside the tool first mirrors how real project scoping works — you don't discover the whole plan by dragging cards around. 2. **Add every task to the board using your title convention.** Every card should show phase, owner (even fictional), and priority. Example: `[Planning] Book venue — Owner: Sarah — Priority: High` 3. **Assign a rough priority to each task**, thinking honestly about what would actually block launch versus what's nice-to-have. Not everything can be "High" — if more than a third of your tasks are High priority, go back and re-triage; that's a sign priority isn't doing its job. 4. **Simulate dependency by holding a later phase back.** This board has no built-in dependency logic, so you enforce it yourself: keep every task from Phase 2 and Phase 3 sitting in "To Do" and *do not* move any of them into "In Progress" until the key tasks from the phase before it are in "Done." Pick 2–3 "key" tasks per phase that count as the real gate — not every task needs to block, just the ones that genuinely do in a real project. 5. **Run the project forward.** Move Phase 1 tasks through In Progress → Done at a pace that feels realistic (don't finish everything in one pass — do it in at least 3 separate rounds of movement, as if separate days had passed). Once your Phase 1 "key" tasks are Done, start releasing Phase 2 tasks into In Progress. 6. **Introduce scope change.** Midway through — ideally once Phase 2 is underway — add **2 new tasks** that were not in your original plan. Assign them a phase, owner, and priority like everything else. Notice: do they fit cleanly into an existing phase, or do they expose that your original phase boundaries were fuzzier than you thought? 7. **Find and split an oversized task.** Look at your board for any task that's been sitting in "In Progress" the longest, or that you suspect is really two tasks glued together. Delete it and re-add it as two smaller, more specific tasks. This is a habit worth over-practicing: a task that lingers in "In Progress" for too long is almost always secretly two or three tasks. 8. **Save your board** with a title that reflects it's the multi-phase version, e.g. "Website Relaunch — Full Project Board." ### Reflection (write 3–4 sentences) - Which "key" tasks did you choose as phase gates, and would a real team agree those were the right ones to block on? - What did the 2 unplanned tasks reveal about gaps in your original phase plan? - Where did enforcing dependency manually (by *not* moving cards) feel artificial compared to how a real PM tool would handle it? What would you want the tool to do automatically instead? ### Success checklist - [ ] At least 9 tasks across 3 clearly labeled phases - [ ] Every task has an owner and a priority in its title - [ ] At least one phase was deliberately held back until a prior phase's key tasks were Done - [ ] 2 unplanned tasks were added mid-project - [ ] At least one oversized task was identified and split into two - [ ] Board saved with a phase-aware title **Tip:** almost every real project gains new tasks partway through, and almost every board eventually has one task that's secretly too big. Practicing how you absorb both — without throwing out your original plan — is a more realistic skill than trying to design a "perfect" board upfront. --- ## Lab 3 (Expert): Full Simulation + Stakeholder Status Report **What you're practicing:** the deliverable that actually matters to a project coordinator's manager — a clear, concise status report written from a board a stakeholder has never seen, plus honest reasoning about risk. **Estimated time:** 45–60 minutes **Prerequisites:** Lab 2 (this lab assumes a multi-phase board already exists, or you build one fresh to the same standard). ### Setup 1. Open your Lab 2 board if you still have it, or build a comparable one from scratch: at least 3 phases, owners and priorities in every card title, and at least one deliberately-blocked dependency. 2. This lab has two deliverables: **(a)** a board pushed to roughly the midpoint of the project, and **(b)** a written status report. Budget time for both — the writing is the harder half. ### Part A — Get the project to midpoint 1. **Advance the board to approximately 50% completion.** A rough rule: about half your total tasks should be in "Done," a handful actively "In Progress," and the rest still "To Do," including anything correctly still gated behind an earlier phase. 2. **Deliberately create one blocked task.** Pick a task that's stuck — not moving forward — because it's waiting on something outside your control (a decision, an external vendor, another team). Mark it clearly in the title, e.g.: `[Build] Integrate payment API — Owner: Dele — Priority: High — BLOCKED: waiting on vendor API keys` 3. **Introduce one at-risk item that hasn't fully blocked yet but could.** This is different from a blocker — it's a task or dependency that's still moving but is trending late or fragile. Note it in the title or keep a short separate note, e.g. "Design sign-off — running 3 days behind, no blocker yet but watch this." 4. **Save this mid-project state** as its own project, titled something like "Website Relaunch — Midpoint Checkpoint," so you have a clear snapshot to write the report from. ### Part B — Write the stakeholder status report Write this as if sending it to a manager or client who has **not** seen the board and does not have time to look at it. 1. **Lead with the headline, in the first sentence.** State plainly: On track / At risk / Blocked. Do not make a busy reader dig through details to find this out — it should be unmissable in sentence one. 2. **Summarize what's Done**, in one or two sentences — group related finished tasks rather than listing every card individually. A stakeholder doesn't need a card-by-card readout. 3. **Summarize what's In Progress**, again grouped, focusing on what's actively moving rather than everything technically "started." 4. **Name what's Blocked and why**, using the blocked task from Part A. Be specific about what's needed to unblock it and who owns resolving it (even if that's outside your fictional team). 5. **Name one risk you're watching** — the at-risk item from Part A. State what could happen if it's not addressed, and what you (or your fictional team) are doing about it. A risk without a mitigating action reads as an excuse, not a status update — always pair the two. 6. **Keep the entire report under 150 words.** This is a hard constraint, not a suggestion. Draft first without worrying about length, then cut. Removing detail a busy reader doesn't need is the actual skill being practiced here — not fitting more in. 7. **Read it back once and cut anything that doesn't serve the headline.** If a sentence doesn't help the reader understand "are we on track, and what do you need from me," cut it. ### Part C — Compare and reflect 8. **Compare this project to your Lab 2 board** (or an OpenProject-style board if you've tried that tool too). Write one sentence on which style of board you'd actually recommend to a small team, and why — there's no single right answer; the point is having a reasoned opinion. 9. **Save your final board state and your written status report together** as your final project for this tool. If the platform doesn't have a field for the report text, paste it into the board itself as a final card, or save it as a companion note alongside your project title. ### Reflection (write 3–5 sentences) - Did writing the status report change how you'd have organized the board if you'd known from the start you'd need to summarize it for someone else? - Was it harder to name the risk honestly, or to keep the report under 150 words? What does that tell you about your instincts as a communicator? ### Success checklist - [ ] Board pushed to a realistic midpoint (~50% Done, some In Progress, rest correctly gated) - [ ] One clearly blocked task with a named blocker and owner - [ ] One clearly at-risk (not yet blocked) item identified - [ ] Status report leads with an unambiguous headline in sentence one - [ ] Report covers Done / In Progress / Blocked / Risk, all grouped rather than card-by-card - [ ] Report is under 150 words - [ ] One sentence comparing this tool/workflow to an alternative PM-style board - [ ] Final board + report saved together **Tip:** a good status report leads with the answer — on track, at risk, or blocked — in the first sentence. Don't make a busy reader work through details to find the headline themselves. This single habit is the difference between a status update people actually read and one they skim past. --- ## Quick reference: title conventions used across this series | Element | Convention | Example | |---|---|---| | Owner | `— Owner: Name` | `— Owner: Sarah` | | Priority | `— Priority: High/Med/Low` | `— Priority: High` | | Phase | `[Phase Name]` prefix | `[Build]` | | Blocked | `— BLOCKED: reason` | `— BLOCKED: waiting on vendor API keys` | | At-risk | free-text note in title or a companion note | `running 3 days behind, no blocker yet` | Since the simulator only stores plain-text card titles, consistency in how you encode this information is itself part of the skill — a board where every card uses a different convention is exactly as unusable as one with no convention at all.

✅ Project Board (ClickUp-style) Intermediate · Lab 2

A Multi-Phase Project with Simulated Dependencies

Building on Lab 1: you managed a single-phase board once. Now run something closer to a real multi-phase project — with priorities, self-enforced dependencies, and scope change to absorb along the way.

~35–45 minestimated time

Lab 1prerequisite

9–12 tasksacross 3 phases

To Do

[Build] Integrate API

[Launch] Write release notes

In Progress

[Planning] Book venue

Done

[Planning] Kickoff meeting

✅ Project Board (ClickUp-style) Expert · Lab 3

Full Simulation + Stakeholder Status Report

Building on Labs 1–2: practice the deliverable that actually matters to a project coordinator's manager — a clear, concise status report written from a board a stakeholder has never seen.

~45–60 minestimated time

Lab 2prerequisite

<150 wordsreport limit

To Do

[Build] Integrate payment API — BLOCKED

In Progress

[Design] Sign-off — running late

Done

[Planning] Kickoff meeting

[Planning] Book venue