Belajar Project Manager - Scope & Work Breakdown Structure
Scope statement mendefinisikan batasan proyek, WBS memecahnya menjadi bagian-bagian yang bisa dikelola, dan change control mencegah scope creep. Di episode ini kita pelajari cara membuat WBS proyek IT yang efektif dan mengelola perubahan scope
#Pendahuluan
Setelah di episode 3 kita menulis charter — mendefinisikan goals, deliverables, dan success criteria — pada episode ini kita masuk ke detail scope dan Work Breakdown Structure (WBS). Scope creep — penambahan requirement tanpa penyesuaian timeline/budget — adalah penyebab nomor satu keterlambatan proyek. WBS adalah senjata utama PM untuk melawannya.
Mengapa WBS penting? Karena WBS mengubah "proyek besar yang menakutkan" menjadi "kumpulan tugas kecil yang bisa dikelola". Tanpa WBS, PM akan kesulitan mengestimasi effort, melacak progress, dan mengidentifikasi blockages.
#Scope Statement
Scope statement adalah dokumen yang mendefinisikan batasan proyek secara detail. Ini berbeda dari charter — charter adalah overview, scope statement adalah detail.
#Komponen Scope Statement
| Komponen | Deskripsi |
|---|---|
| Deliverables | Apa yang harus dihasilkan proyek? |
| Acceptance Criteria | Bagaimana menilai deliverable sudah sesuai? |
| Assumptions | Asumsi apa yang berlaku? |
| Constraints | Batasan apa yang berlaku (budget, timeline, resources)? |
| Exclusions | Apa yang TIDAK termasuk dalam proyek? |
#Contoh Scope Statement
Deliverables:
1. GitHub Actions workflow untuk build, test, dan deploy
2. Infrastructure as Code (Terraform) untuk staging & production
3. Monitoring & alerting dashboard (Grafana)
4. Dokumen operasi & runbook
Acceptance Criteria:
- Deployment time < 15 menit
- Zero downtime during deployment
- Semua test otomatis berjalan sebelum deploy
Assumptions:
- GitHub Enterprise sudah tersedia
- Tim DevOps tersedia untuk support
- Cloud provider (AWS/GCP) sudah dikonfigurasi
Constraints:
- Budget: $50K
- Timeline: 3 bulan
- Tim: 3 engineer
Exclusions:
- Migration database (proyek terpisah)
- Training end user (handled oleh tim training)#Work Breakdown Structure (WBS)
WBS adalah pemecahan hierarkis dari seluruh scope proyek menjadi bagian-bagian yang lebih kecil dan bisa dikelola. Setiap level WBS memecah pekerjaan menjadi komponen yang lebih spesifik.
#Prinsip WBS
- 100% rule: WBS harus mencakup seluruh scope proyek — tidak ada yang terlewat.
- Mutually exclusive: tidak ada tugas yang overlap antar komponen.
- Outcome-oriented: fokus pada hasil, bukan aktivitas.
- Manageable chunks: setiap tugas harus cukup kecil untuk diestimasi dan di-track.
#Contoh WBS
#WBS Dictionary
Setiap komponen WBS harus didokumentasikan dalam WBS dictionary:
ID: B1
Deskripsi: GitHub Actions workflow untuk build aplikasi
Deliverables: Workflow YAML, konfigurasi caching, artifact upload
Acceptance Criteria: Build selesai < 5 menit, artifact tersimpan
Owner: [Nama engineer]
Estimasi: 3 hari
Dependencies: Repository sudah di-setup#Change Control
Change control adalah proses formal untuk menangani perubahan scope. Tanpa change control, scope creep akan terjadi secara perlahan hingga proyek tidak terkendali.
#Proses Change Control
- Submit change request: stakeholder mengajukan perubahan secara tertulis.
- Analisis dampak: PM menganalisis dampak terhadap timeline, budget, dan quality.
- Review & approval: change review board (atau sponsor) memutuskan.
- Implementasi: jika disetujui, update scope, timeline, dan budget.
- Komunikasi: informasikan perubahan ke seluruh tim.
Warning
Change control bukan berarti menolak semua perubahan. Perubahan yang bisnis-justify boleh diterima, tetapi harus dengan penyesuaian timeline atau budget yang sesuai. PM yang baik bisa berkata "ya, tetapi..." bukan "tidak" atau "ya" tanpa konsekuensi.
#Common Pitfalls
Dua kesalahan paling umum:
- WBS terlalu detail: memecah pekerjaan menjadi terlalu kecil sehingga overhead tracking lebih besar dari value-nya. Cukup sampai level yang bisa dikelola (biasanya 3-4 level).
- Skip change control: karena "hanya perubahan kecil". Perubahan kecil yang menumpuk akhirnya menjadi masalah besar.
#Penutup
Inti yang harus dibawa pulang:
- Scope statement mendefinisikan batasan proyek: deliverables, acceptance criteria, assumptions, constraints, dan exclusions.
- WBS memecah scope menjadi bagian hierarkis yang bisa dikelola, dengan 100% rule dan outcome-oriented approach.
- Change control mencegah scope creep dengan proses formal: submit, analisis, approve, implement, komunikasi.
- WBS dictionary mendokumentasikan detail setiap komponen WBS.
Di episode 5 selanjutnya kita akan membahas scheduling & timeline — bagaimana membuat Gantt chart, mengidentifikasi critical path, menetapkan milestone, dan melakukan resource leveling. Pastikan kalian sudah memiliki WBS yang lengkap, karena scheduling akan dibangun dari tugas-tugas yang sudah didefinisikan dalam WBS!