Work Breakdown Structure
A Work Breakdown Structure (WBS) decomposes the project into deliverables with assignments and effort estimates.
Work Breakdown Structure
What this section does
Decomposes the project into deliverables. For each deliverable, you state WHO did WHAT in HOW MANY HOURS. The panel uses this to ask 'how did you divide work?'
WBS tree (Sample Bakery Shop)
WBS table (selected rows)
| ID | Phase / Task | Owner | Hours |
|---|---|---|---|
| 1.1 | Interview owner | Member A | 4 |
| 1.2 | Observe daily operations | Member B | 6 |
| 1.3 | Compile SRS document | Member A | 8 |
| 2.1 | Draw ERD | Member B | 6 |
| 2.2 | Architectural diagram | Member A | 4 |
| 2.3 | UI mockups | Member C | 12 |
| 3.1 | Database schema | Member B | 8 |
| 3.2 | Ordering module | Member A | 30 |
| 3.3 | Inventory module | Member B | 24 |
| 3.4 | SMS integration | Member C | 16 |
| 4.1 | Unit tests | All | 12 |
| 4.2 | Acceptance survey | Member C | 20 |
| 5.1 | Manuscript draft | Member A | 40 |
| 5.2 | Diagrams + appendices | Member B | 16 |
| **TOTAL** | **206** |
Mentor's tip
The hours must be defensible. 'Build the entire system in 4 hours' invites ridicule. 'Build the ordering module in 30 hours, divided into 6 sub-tasks of 5 hours each' is real.
Panel defense checklist
- [ ] Table covers every phase from SDLC.
- [ ] Each task has a single owner (or 'All' for shared).
- [ ] Hours are realistic (not too low, not padded).
- [ ] Total matches what your Gantt chart implies.
- [ ] Distribution of hours is balanced across team members.
- [ ] Documentation hours are NOT zero.
Common mistakes
- Assigning every task to one person (panel asks why the group exists).
- Forgetting testing hours (panel infers the system was untested).
- Suspiciously low totals (200 hours for a 4-month project? Too low).
- Suspiciously high totals (800 hours for an 8-week project? Impossible).
Mentor’s tip: Three-level table: phase, deliverable, task. Owner and hours per task. Defensible totals. Documentation hours are not zero.
Discussion
Loading…