Step-by-step exercises for Project Board (OpenProject-style) - read them here, then practice live in the tool above.
Beginner Level
Last updated: August 9, 2026
# Project Board (OpenProject-style) — Full Lab Series
**Tool:** Project Board (OpenProject-style) — in-house kanban simulator
**Tool key:** `openproject-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. Mechanically it's the same board engine as the ClickUp-style tool — what changes here is the *workflow discipline* you practice on it: OpenProject's open-source-PM heritage leans on an explicit **work breakdown structure (WBS)** — phases, work packages under each phase, and status moving in strict phase order — rather than a loose backlog.
Because cards are plain text, this series teaches you to encode WBS information (phase, work-package type, owner) into the card title itself, and to enforce phase-order discipline by hand — a skill that transfers directly to real WBS-driven tools.
---
## Lab 1 (Beginner): Your First Work Breakdown
**What you're practicing:** setting up a small work breakdown for a project and moving work through stages the way OpenProject structures it — plus building the habit of comparing PM tool styles rather than treating any one as "the" way to run a project.
**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 understand well enough to run start-to-finish. A hobby project works fine. Examples if you're stuck: "Plan a weekend trip," "Launch a personal blog," "Organise a small event."
3. Unlike a flat to-do list, a work breakdown groups tasks under **phases** first. Before adding any cards, sketch 2–3 phases for your project on paper, e.g. "Planning," "Execution," "Wrap-up."
### Step-by-step
1. **Clear the sample cards.** Double-click each seeded card and confirm deletion. Start from an empty board.
2. **Set up a small work breakdown.** Create 6–10 tasks total, spread across your 2–3 phases. Give each card a phase prefix so the breakdown is visible in the title itself, e.g.:
`[Planning] Book venue`
3. **Group tasks by phase mentally as you add them**, even though the board only has three status columns (To Do / In Progress / Done), not phase columns. This is the core adjustment from a flat backlog: phase is a property of the *work*, status is a property of *where it stands right now* — the two are different axes, and OpenProject-style tools keep them separate on purpose.
4. **Move work through the stages the way OpenProject structures it.** Advance a couple of Planning-phase tasks into "In Progress" and then "Done," working roughly in phase order — don't jump ahead to Execution-phase tasks yet. This single habit — respecting phase order — is the main thing distinguishing this lab from a plain kanban exercise.
5. **Watch for pile-up.** After a few moves, note which column has the most cards. Write one sentence on why you think work is stalling there.
6. **Compare this workflow to a plain kanban board.** If you've used the ClickUp-style Project Board tool, think back to it (or imagine a simple backlog board if you haven't). What's different in how work is organised here versus there? Write 1–2 sentences — this comparison habit is worth building from Lab 1, not saved for later.
7. **Save your board.** Click **Save This Board as a Project** and give it a specific, descriptive title (e.g. "Weekend Trip — Work Breakdown v1").
### Reflection (write 2–3 sentences)
- Which column ended up with the most cards, and why?
- What's one concrete difference you noticed between organising work by phase-first versus a flat backlog?
### Success checklist
- [ ] Board has 6–10 tasks grouped into 2–3 labeled phases
- [ ] Tasks were moved roughly in phase order, not scattered
- [ ] One sentence written comparing this workflow to a plain kanban/backlog style
- [ ] Board saved with a specific, descriptive title
**Tip:** try running the same fictional project through both PM-style boards in this section (this one and the ClickUp-style one) if you have access to both — noticing the differences hands-on is the real learning here, more than reading about them would be.
---
## Lab 2 (Intermediate): A Multi-Phase Work Breakdown
**What you're practicing:** running a fuller work breakdown structure — at least 3 phases with several work packages each — while enforcing phase order by hand and catching an oversized task before it causes problems.
**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).
2. Choose a project big enough to have **at least 3 phases**. Examples: a website relaunch (Discovery → Build → Launch), an event (Planning → Execution → Wrap-up), a home renovation (Design → Construction → Finishing).
3. Fix a title convention before adding any cards:
`[Phase] Work package name — Owner: X`
### Step-by-step
1. **Set up a work breakdown with at least 3 phases and 3–4 tasks per phase.** That's 9–12 work packages total. Write the full breakdown out before touching the board — real WBS work is scoped up front, not discovered by dragging cards.
2. **Add every task to the board using your title convention.** Example:
`[Build] Set up CMS — Owner: Ade`
3. **Move tasks through stages in phase order, keeping later-phase tasks parked.** Don't move any Phase 2 or Phase 3 card into "In Progress" until the Phase 1 cards you consider load-bearing are "Done." This is the discipline OpenProject-style planning is built around: work doesn't start just because someone's free — it starts because its phase is actually ready.
4. **Advance the board in at least 3 separate rounds**, not one big pass — move a few cards, pause, move a few more, as if simulating separate days or check-ins.
5. **Note one task that turns out bigger than expected once you start it.** This should happen naturally if you're being honest about scope — pick a card that's been "In Progress" a while and treat it as if it's dragging.
6. **Split that oversized task into two smaller ones instead of leaving it oversized.** Delete the original card and add two more specific replacements. Splitting the moment you notice it's too big — not weeks later — is the habit worth over-practicing: a task that's been "in progress" for way too long is almost always secretly two or three tasks.
7. **Compare this workflow's structure to the ClickUp-style board again.** Write one sentence on when you'd choose one style over the other for a real team — phase-gated WBS discipline versus a looser backlog-and-priority approach.
8. **Save your board** with a title reflecting the multi-phase version, e.g. "Website Relaunch — Work Breakdown v2."
### Reflection (write 3–4 sentences)
- Which Phase 1 tasks did you treat as "load-bearing" enough to gate Phase 2 — would a real team agree those were the right ones?
- What tipped you off that the task you split was actually oversized? Was it obvious, or did you have to look for it?
- When would you personally reach for this phase-gated style over a looser backlog board, and when would the opposite be true?
### Success checklist
- [ ] At least 9 work packages across 3 clearly labeled phases
- [ ] Later-phase tasks were kept parked until earlier-phase load-bearing tasks were Done
- [ ] Board was advanced in at least 3 separate rounds, not one pass
- [ ] One oversized task was identified and split into two
- [ ] One sentence written comparing this workflow to the ClickUp-style board
- [ ] Board saved with a phase-aware title
**Tip:** splitting an oversized task the moment you notice it's too big is a habit worth over-practicing — a task that's been "in progress" for way too long is almost always secretly two or three tasks.
---
## Lab 3 (Expert): Full Project Simulation
**What you're practicing:** running a complete project end to end and reflecting on the *workflow itself*, not just the tasks — the habit that separates someone who can fill out a board from someone who can actually judge whether a workflow fits a team.
**Estimated time:** 45–60 minutes
**Prerequisites:** Lab 2 (this lab assumes comfort with phase-gated work breakdowns; a fresh board is fine if you'd rather not reuse Lab 2's).
### Setup
1. Open a fresh board, or continue your Lab 2 project if you'd like to see it through to completion.
2. This lab has no separate written deliverable required beyond a short reflection — the emphasis is on running the *entire* project, start to finish, and paying attention to friction as you go.
3. Keep a scratch note (paper, notes app, or a spare card you delete before saving) for jotting friction points as they happen — don't try to remember them all at the end.
### Step-by-step
1. **Build a full work breakdown covering the whole project.** At least 3 phases, 3+ work packages each, using your `[Phase] Task — Owner: X` convention from Lab 2.
2. **Build and run a full project from empty board to fully Done, across all its phases.** This means every single card ends in "Done" by the end of the lab — not a snapshot at the midpoint, the entire thing, phase-gated the whole way (don't skip the discipline from Lab 2 just because you're rushing to finish).
3. **Keep brief notes on any point where the workflow felt clunky or a task didn't fit neatly into a stage.** Concrete examples to watch for: a task that's really a milestone, not a work package; a task that belongs to two phases at once; a status that doesn't map cleanly to To Do / In Progress / Done (e.g. "waiting on approval" isn't really any of the three). Write these down the moment you notice them, in the moment — not reconstructed afterward.
4. **Deliberately run into at least one of these friction points on purpose if none occur naturally.** For example, add a milestone-style card ("Design approved") and notice it doesn't behave like a normal task — it's binary and instant, not something that sits "In Progress" for days. This is a genuine limitation of a 3-column board that a real WBS tool would model differently (with explicit milestone types).
5. **Move every phase through to Done**, maintaining phase-gate discipline throughout — don't let the pressure to finish the exercise tempt you into skipping the gating you practiced in Lab 2.
6. **Write a short reflection: what would you change about this workflow if you were setting it up for a real team?** Be specific — not "make it better," but a concrete change, e.g. "I'd add a fourth column for 'Blocked' because two of my tasks needed one and I had to fake it with the card title instead."
7. **Compare your finished project to your Lab 2 ClickUp-style project, if you did that lab.** Which one would you actually recommend to a small team, and why? If you haven't done the ClickUp-style labs, compare instead to a plain flat to-do list you've used in real life.
8. **Save your finished board and reflection as your final project for this tool.** If there's no dedicated field for the written reflection, paste it into the board as a final card before saving, or keep it as a companion note alongside your project title.
### Reflection (write 3–5 sentences — this is the actual deliverable of the lab)
- What would you change about this workflow if you were setting it up for a real team? Name one concrete change.
- Which friction point taught you the most — a naturally occurring one, or the one you deliberately engineered?
- Which PM-style board (this one, or an alternative) would you actually recommend to a small team, and why?
### Success checklist
- [ ] Full work breakdown built and run from empty board to every card in Done
- [ ] Phase-gate discipline maintained the entire way through, not abandoned near the end
- [ ] At least one friction point identified and noted at the moment it happened
- [ ] One friction point deliberately engineered if none occurred naturally
- [ ] Concrete (not vague) written reflection on what you'd change about the workflow
- [ ] One comparison sentence against another PM-style board or a real to-do list
- [ ] Final board + reflection saved together
**Tip:** the "right" PM tool or workflow is the one your specific team will actually keep using — practicing noticing friction points is more valuable long-term than memorising any one tool's ideal setup. A workflow that looks correct on a whiteboard but that nobody follows in practice isn't actually working.
---
## Quick reference: title conventions used across this series
| Element | Convention | Example |
|---|---|---|
| Phase | `[Phase Name]` prefix | `[Build]` |
| Owner | `— Owner: Name` | `— Owner: Ade` |
| Milestone (Lab 3 only) | treat as its own card, note that it behaves differently | `[Launch] Design approved (milestone)` |
Since the simulator only stores plain-text card titles and has no native phase or work-package fields, consistency in how you encode this information — and discipline in respecting phase order when you move cards — is itself the core skill this series builds. A "work breakdown" that isn't actually respected in what gets moved when is just a backlog with extra labels.