Program Studi Bisnis Digital · FEB UNDIP · Manajemen Proyek Digital

Ruang Lingkup Proyek
& Work Breakdown Structure

Pertemuan 3 · Menyusun Scope & WBS dari Kebutuhan Klien

Dari permintaan klien yang samar menjadi peta pekerjaan yang terukur — fondasi seluruh estimasi & jadwal proyek digital.

RPS minggu 3 · 2x50 menit

Selamat datang kembali di Manajemen Proyek Digital. Pekan lalu Anda sudah belajar tahapan siklus hidup proyek digital secara umum; hari ini kita masuk ke jantung tahap perencanaan, yaitu bagaimana menyusun ruang lingkup proyek dan memecahnya menjadi Work Breakdown Structure atau WBS. Bayangkan sebuah UMKM fesyen di Semarang meminta tim Anda membuat "aplikasi belanja online seperti Tokopedia" — kalimat itu terdengar jelas bagi klien, tetapi bagi seorang project manager, kalimat itu masih penuh ambiguitas yang bisa membengkakkan anggaran dan jadwal kalau tidak segera diperjelas. Materi hari ini akan mengajarkan Anda cara mengubah permintaan yang samar seperti itu menjadi dokumen ruang lingkup yang presisi, lalu memecahnya menjadi paket-paket pekerjaan yang bisa diestimasi dan dijadwalkan. Siapkan kalkulator Anda karena kita akan berlatih menghitung jumlah paket kerja dan alokasi persentase durasi secara langsung dari studi kasus nyata.

Tujuan Pembelajaran Hari Ini

Setelah pertemuan ini, Anda diharapkan mampu menyusun ruang lingkup proyek dan WBS berdasarkan kebutuhan klien (Sub-CPMK minggu 3):

Capaian 1 — Definisi Scope

①

Menjelaskan perbedaan product scope vs project scope, serta menyusun komponen scope statement dari kebutuhan klien.

Capaian 2 — Konsep WBS

②

Menjelaskan struktur hierarki WBS beserta aturan 100% dan fungsi WBS Dictionary.

Capaian 3 — Menyusun WBS

③

Mendekomposisi sebuah proyek digital nyata (studi kasus website UMKM) menjadi fase → deliverable → work package.

Capaian 4 — Hitung & Hindari Jebakan

④

Menghitung jumlah paket kerja & alokasi durasi dari WBS, serta mengenali kesalahan umum penyusunannya.

Proyek Gagal Bukan karena Coding Buruk — tapi Lingkup yang Kabur

Riset industri berulang kali menunjukkan: penyebab utama proyek digital molor & membengkak biaya bukan teknologi, melainkan scope yang tidak terdefinisi jelas sejak awal.

Kasus 1 — Startup E-commerce

🛍️

Klien minta "aplikasi seperti Tokopedia" tanpa rincian — tim developer membangun fitur yang tidak diminta, anggaran habis sebelum fitur inti selesai.

Kasus 2 — Bank Digital

🏦

Proyek mobile banking BBCA yang sukses selalu berangkat dari dokumen lingkup yang detail — setiap fitur transfer, QRIS, hingga biometrik didefinisikan sebelum satu baris kode ditulis.

Kasus 3 — Scope Creep

📈

"Tambah sedikit fitur chat ya, gak lama kok" — permintaan kecil tanpa WBS yang jelas menumpuk jadi keterlambatan berbulan-bulan.

Hari ini kita belajar alat pencegahnya: ruang lingkup proyek yang terdokumentasi rapi, dipecah menjadi WBS yang bisa diukur, diestimasi, dan dijadwalkan.

Saya selalu membuka topik ini dengan pertanyaan: menurut Anda, apa penyebab paling umum proyek digital gagal tepat waktu? Kebanyakan mahasiswa menjawab "coding-nya susah" atau "developernya kurang jago", padahal riset industri berulang kali membuktikan penyebab utamanya adalah ruang lingkup yang tidak jelas sejak awal. Bayangkan sebuah startup e-commerce yang hanya diberi instruksi "buatkan aplikasi seperti Tokopedia" tanpa rincian fitur — tim developer akhirnya membangun apa yang mereka kira diinginkan, dan anggaran habis sebelum fitur inti seperti pembayaran selesai dibuat. Bandingkan dengan proyek digital perbankan seperti aplikasi mobile banking BCA, yang sukses justru karena setiap fitur, mulai dari transfer antarbank sampai verifikasi biometrik, didefinisikan secara rinci sebelum pengembangan dimulai. Fenomena permintaan kecil yang menumpuk tanpa kendali ini disebut scope creep, dan akan kita bahas mitigasinya di pertemuan tujuh; hari ini kita belajar fondasi pencegahannya, yaitu menyusun ruang lingkup dan WBS yang presisi.

Bagian 1 dari 4

Menyusun Ruang
Lingkup Proyek

Membedakan lingkup produk dari lingkup proyek, menggali kebutuhan klien secara terstruktur, hingga menyusun scope statement yang jadi acuan seluruh tim.

Product vs Project Scope Kebutuhan Klien Scope Statement

Dua Lapis Lingkup: Produk vs Proyek

Istilah scope (ruang lingkup) punya dua makna berbeda yang wajib dibedakan seorang project manager:

Product Scope

📱

Fitur & fungsi dari hasil akhir yang dipesan klien. Contoh: aplikasi kasir UMKM punya fitur input barang, cetak struk, laporan harian.

Project Scope

🗂️

Seluruh pekerjaan yang harus dilakukan tim untuk menghasilkan produk itu — riset, desain, pengembangan, testing, pelatihan pengguna, dokumentasi.

Kekeliruan paling umum: klien hanya mendefinisikan product scope ("aplikasinya harus bisa begini") sementara tim melupakan project scope di baliknya (siapa yang menulis dokumentasi? siapa yang melatih staf UMKM memakainya?).

Perbedaan ini krusial karena kesalahpahaman di sini adalah sumber konflik klien-tim yang paling sering terjadi. Product scope berbicara tentang apa yang dihasilkan — misalnya sebuah aplikasi kasir untuk UMKM yang bisa mencatat barang masuk, mencetak struk, dan membuat laporan penjualan harian. Sementara itu, project scope berbicara tentang seluruh rangkaian pekerjaan yang dibutuhkan untuk mewujudkan produk tersebut, mulai dari riset kebutuhan, perancangan antarmuka, penulisan kode, pengujian, sampai pelatihan pemilik warung memakai aplikasinya. Kesalahan paling umum yang saya temui pada proyek mahasiswa adalah mereka hanya mencatat product scope dan lupa bahwa pelatihan pengguna serta dokumentasi juga bagian dari pekerjaan proyek yang harus dianggarkan waktunya. Ingatlah rumus sederhana ini: product scope menjawab "apa hasilnya", sedangkan project scope menjawab "apa saja pekerjaan untuk sampai ke hasil itu".

Menggali Kebutuhan Klien: Empat Langkah Bertahap

Permintaan klien awal hampir selalu samar. Ikuti alur ini untuk mengubahnya jadi kebutuhan yang jelas — perhatikan bagaimana tiap langkah mempersempit ambiguitas:

Langkah	Aktivitas	Hasil
1. Wawancara awal	Tanya klien: "Apa masalah bisnis yang ingin diselesaikan?" (bukan "fitur apa yang mau dibuat")	Konteks bisnis: "Toko kami kewalahan catat stok manual"
2. Identifikasi stakeholder	Cari tahu siapa pengguna akhir sebenarnya — pemilik UMKM belum tentu sama dengan kasir yang pakai aplikasi	Daftar pihak: pemilik, kasir, kurir, pelanggan
3. Dokumentasi kebutuhan	Tuliskan kebutuhan dalam kalimat "Sebagai [peran], saya butuh [fitur] agar [tujuan]"	Contoh: "Sebagai kasir, saya butuh cetak struk cepat agar antrean tak menumpuk"
4. Validasi bersama klien	Presentasikan kembali daftar kebutuhan ke klien untuk konfirmasi tertulis	Kebutuhan disepakati & ditandatangani → dasar scope statement

Lompati langkah validasi = risiko terbesar proyek digital: fitur selesai dibangun, klien bilang "bukan ini yang saya maksud".

Permintaan awal klien nyaris selalu masih kabur, dan tugas Anda sebagai project manager adalah mempersempitnya secara bertahap, bukan langsung menebak-nebak fitur. Langkah pertama adalah wawancara yang menggali masalah bisnis, bukan langsung menanyakan fitur — misalnya seorang pemilik toko kelontong mengatakan tokonya kewalahan mencatat stok secara manual, itu konteks bisnis yang jauh lebih berguna daripada sekadar "saya mau aplikasi kasir". Langkah kedua adalah mengidentifikasi seluruh pemangku kepentingan, karena pemilik usaha yang memesan aplikasi belum tentu orang yang sehari-hari memakainya, bisa jadi kasir atau kurirnya. Langkah ketiga adalah mendokumentasikan kebutuhan dalam format baku "sebagai peran tertentu, saya butuh fitur tertentu agar tujuan tertentu tercapai", sehingga kebutuhan menjadi konkret dan bisa diuji. Langkah terakhir yang paling sering dilewatkan pemula adalah validasi tertulis bersama klien — tanpa langkah ini, risiko terbesar proyek digital muncul, yaitu tim membangun fitur yang sudah jadi namun ternyata bukan yang dimaksud klien.

Lima Komponen Wajib Scope Statement

Scope statement adalah dokumen tertulis yang mengikat kesepahaman tim & klien. Lima komponen ini wajib ada:

1 · In-Scope

Daftar deliverable yang termasuk pekerjaan — mis. aplikasi Android + panel admin web.

2 · Out-of-Scope

Daftar yang sengaja tidak dikerjakan — mis. versi iOS tidak termasuk fase ini.

3 · Kriteria Penerimaan

Syarat agar deliverable dianggap selesai & diterima klien.

4 · Batasan (Constraints)

Kendala tetap: anggaran maksimal, tenggat waktu, teknologi wajib.

5 · Asumsi (Assumptions)

Hal yang dianggap benar tanpa verifikasi — mis. klien sediakan data produk siap pakai.

Setelah kebutuhan tergali, semuanya dirangkum dalam satu dokumen bernama scope statement, dan dokumen ini wajib memuat lima komponen agar tidak menyisakan celah tafsir. Komponen pertama adalah in-scope, yaitu daftar tegas apa saja yang termasuk pekerjaan, misalnya aplikasi Android beserta panel admin berbasis web. Komponen kedua sama pentingnya, yaitu out-of-scope, daftar yang secara eksplisit dinyatakan tidak dikerjakan pada fase ini, misalnya versi iOS ditunda ke fase berikutnya — inilah senjata utama Anda melawan scope creep nantinya. Komponen ketiga adalah kriteria penerimaan, yakni syarat konkret agar sebuah deliverable dianggap selesai dan bisa ditagihkan, sementara komponen keempat dan kelima, yaitu batasan dan asumsi, mencatat kendala tetap seperti anggaran maksimal serta hal-hal yang dianggap benar tanpa verifikasi ulang, misalnya asumsi bahwa klien UMKM sudah menyediakan foto produk yang siap dipakai.

Dari Kebutuhan Klien Menuju WBS: Satu Alur Utuh

Ruang lingkup bukan langkah tunggal — ia adalah alur bertahap yang berujung pada WBS, dasar seluruh estimasi & jadwal.

Tanpa WBS yang solid, estimasi biaya & jadwal (Pertemuan 4 & 6) hanya tebakan kasar — WBS adalah jembatan antara "apa yang diinginkan klien" dan "berapa lama & berapa biaya".

Diagram ini merangkum seluruh perjalanan bagian pertama kita menjadi satu alur yang mudah diingat. Semuanya dimulai dari kebutuhan klien yang digali lewat wawancara, kemudian dirangkum menjadi scope statement yang mengikat kesepahaman kedua pihak. Dari scope statement itulah kita menyusun WBS, yaitu struktur berjenjang dari fase besar, turun ke deliverable, turun lagi ke paket kerja atau work package yang siap diestimasi. Perhatikan bahwa WBS bukan langkah terakhir, melainkan jembatan menuju estimasi biaya yang akan kita bahas di pertemuan keempat dan penjadwalan Gantt chart di pertemuan keenam; tanpa WBS yang solid, estimasi biaya dan jadwal proyek digital apa pun, baik untuk UMKM kecil maupun proyek sekelas transformasi digital BCA, hanya akan menjadi tebakan kasar yang mudah meleset jauh.

Bagian 2 dari 4

Work Breakdown
Structure (WBS)

Definisi, aturan 100%, struktur hierarki tiga level, cara mendekomposisi proyek, hingga fungsi WBS Dictionary sebagai kamus tiap paket kerja.

Aturan 100% Hierarki 3 Level WBS Dictionary

Sekarang kita masuk ke inti pertemuan hari ini: Work Breakdown Structure, yang biasa disingkat WBS, sebuah alat yang menurut Coughlan menjadi fondasi hampir seluruh proses perencanaan proyek digital. Di bagian ini kita akan mendefinisikan WBS secara presisi, mempelajari aturan seratus persen yang wajib dipatuhi agar tidak ada pekerjaan yang tercecer, lalu melihat struktur hierarkinya yang biasanya terdiri dari tiga level utama. Kita juga akan mempelajari cara mendekomposisi sebuah proyek dari level tertinggi turun ke level paling rinci, serta mengenal WBS Dictionary sebagai kamus yang menjelaskan detail tiap paket kerja. Setelah bagian ini, Anda akan punya kerangka berpikir yang sama dengan yang dipakai project manager profesional saat memecah proyek sekompleks apa pun menjadi satuan kerja yang bisa diukur.

Apa Itu WBS & Aturan 100%

Work Breakdown Structure (WBS) adalah dekomposisi hierarkis seluruh project scope menjadi bagian-bagian yang lebih kecil & mudah dikelola, disebut work package (paket kerja).

Aturan 100%

💯

Total seluruh level bawah WBS harus mencakup persis 100% pekerjaan level di atasnya — tidak kurang (ada yang tercecer), tidak lebih (ada pekerjaan di luar scope).

Work Package

📦

Unit kerja terkecil di WBS — cukup rinci untuk diestimasi durasi & biayanya, ditugaskan ke satu orang/tim penanggung jawab.

Analogi sederhana: WBS seperti memotong satu kue utuh (proyek) menjadi potongan-potongan (work package) — jumlah semua potongan harus sama persis dengan kue aslinya, tidak ada remah yang hilang.

Work Breakdown Structure secara sederhana adalah cara memecah seluruh lingkup proyek menjadi bagian-bagian yang semakin kecil dan mudah dikelola, sampai akhirnya sampai pada unit terkecil yang disebut work package atau paket kerja. Prinsip yang tidak boleh dilanggar dalam menyusun WBS adalah aturan seratus persen: jumlah seluruh elemen di level bawah harus persis mencakup seratus persen pekerjaan di level atasnya, tidak boleh kurang karena berarti ada pekerjaan yang terlewat, dan tidak boleh lebih karena berarti ada pekerjaan di luar lingkup yang disepakati. Sebuah work package harus cukup rinci sehingga bisa diestimasi durasi dan biayanya dengan wajar, serta idealnya ditugaskan kepada satu orang atau satu tim kecil yang jelas penanggung jawabnya. Analogi yang saya suka pakai adalah membayangkan WBS seperti memotong satu kue utuh menjadi beberapa potongan; jumlah seluruh potongan itu harus sama persis dengan kue aslinya, tidak ada remah yang tercecer dan tidak ada potongan tambahan yang sebenarnya bukan bagian dari kue itu.

Struktur Hierarki WBS: Tiga Level Utama

WBS umumnya disusun dalam tiga level — makin ke bawah, makin rinci & makin mudah diestimasi:

Perhatikan diagram ini sebagai peta jalan menyusun WBS. Level nol adalah proyek secara keseluruhan, misalnya "Aplikasi Kasir UMKM". Level satu adalah fase-fase besar proyek, biasanya sejalan dengan siklus hidup yang sudah kita pelajari minggu lalu, seperti fase desain, fase pembangunan, dan fase pengujian. Level dua adalah work package, yaitu unit kerja paling rinci yang siap diestimasi, misalnya di bawah fase bangun ada paket kerja "coding front-end" dan "coding back-end" yang masing-masing bisa ditugaskan ke developer tertentu dengan estimasi jam kerja yang jelas. Semakin dalam Anda turun ke bawah struktur ini, semakin kecil dan konkret satuan pekerjaannya, sampai akhirnya setiap kotak di level paling bawah cukup jelas untuk diberi nomor, ditugaskan ke satu orang, dan diberi estimasi durasi serta biaya tanpa ambiguitas.

Menyusun WBS: Dekomposisi Top-Down Bertahap

Ikuti alur pemecahan berjenjang ini — setiap langkah memecah satu level menjadi bagian yang lebih kecil:

Langkah	Aktivitas	Contoh Hasil
1. Mulai dari deliverable akhir	Tulis nama proyek/produk final di puncak (Level 0)	"Aplikasi Kasir UMKM Toko Berkah"
2. Pecah jadi fase/deliverable utama	Bagi jadi 4–6 kelompok besar sejalan siklus hidup proyek	Perencanaan, Desain, Pengembangan, Pengujian, Peluncuran
3. Pecah tiap fase jadi work package	Turunkan tiap fase jadi paket kerja yang bisa diestimasi (biasanya 8–80 jam kerja)	Fase Desain → wireframe, mockup UI, review klien
4. Uji aturan 100%	Cek: apakah gabungan semua work package = persis seluruh project scope?	Tidak kurang, tidak lebih → WBS siap dipakai

Prinsip 8/80: idealnya satu work package memakan waktu 8–80 jam kerja — terlalu kecil (kurang dari 8 jam) boros administrasi, terlalu besar (lebih dari 80 jam) sulit dikendalikan.

Menyusun WBS selalu berjalan dari atas ke bawah, dan langkah pertama adalah menuliskan nama deliverable akhir di puncak struktur, misalnya "Aplikasi Kasir UMKM Toko Berkah". Langkah kedua, pecah proyek itu menjadi empat sampai enam fase besar yang biasanya sejalan dengan siklus hidup proyek yang sudah kita pelajari, seperti perencanaan, desain, pengembangan, pengujian, dan peluncuran. Langkah ketiga adalah menurunkan setiap fase menjadi work package yang cukup rinci untuk diestimasi, misalnya fase desain diturunkan menjadi pembuatan wireframe, mockup antarmuka, dan sesi review bersama klien. Langkah keempat, dan sering dilupakan pemula, adalah menguji ulang apakah gabungan seluruh work package benar-benar mencakup seratus persen lingkup proyek, tidak kurang maupun lebih; sebagai panduan praktis, gunakan prinsip delapan-delapan-puluh, artinya idealnya satu paket kerja memakan delapan sampai delapan puluh jam kerja agar tidak terlalu remeh untuk diadministrasikan maupun terlalu besar untuk dikendalikan.

WBS Dictionary: Kamus Tiap Paket Kerja

Kotak-kotak di diagram WBS hanya memuat nama singkat. Detailnya dicatat di WBS Dictionary — dokumen pendamping wajib.

Contoh Entri WBS Dictionary — Work Package "Mockup UI Kasir"

Kode WBS: 2.3 (Fase Desain, paket ke-3)
Deskripsi: Merancang tampilan antarmuka layar kasir, input barang, & struk digital
Penanggung jawab: UI/UX Designer
Estimasi durasi: 24 jam kerja (3 hari)
Kriteria selesai: Mockup disetujui tertulis oleh klien via presentasi
Dependency: Menunggu Wireframe (2.2) selesai

Tanpa WBS Dictionary, kode "2.3" di diagram hanya simbol kosong — dokumen inilah yang membuat tiap anggota tim tahu persis apa yang harus dikerjakan & kapan selesai.

Diagram WBS yang kita bahas di dua slide sebelumnya sengaja dibuat ringkas, hanya memuat nama singkat tiap kotak, dan itu sebabnya selalu didampingi dokumen bernama WBS Dictionary yang mencatat detail lengkap tiap work package. Lihat contoh di layar ini, sebuah entri untuk paket kerja "mockup UI kasir": entri itu punya kode WBS supaya mudah dirujuk, deskripsi pekerjaan yang jelas, nama penanggung jawab, estimasi durasi dalam jam kerja, kriteria yang menandakan pekerjaan itu benar-benar selesai, serta dependency atau ketergantungan pada paket kerja lain yang harus selesai lebih dulu. Tanpa dokumen pendamping ini, kode seperti "2.3" di diagram WBS hanya akan menjadi simbol kosong yang tidak berarti apa-apa bagi anggota tim baru. Justru WBS Dictionary inilah yang membuat setiap desainer, developer, dan tester tahu persis apa yang harus dikerjakan, kapan target selesainya, dan pekerjaan siapa yang harus mereka tunggu terlebih dahulu.

Bagian 3 dari 4

Praktik Menyusun WBS
— Studi Kasus

Menerapkan seluruh konsep pada satu studi kasus utuh: proyek pembuatan website toko daring untuk UMKM — lengkap dengan perhitungan jumlah paket kerja & alokasi durasi.

Studi Kasus UMKM Hitung dari Nol Kesalahan Umum

Studi Kasus: WBS Website Toko Daring UMKM Batik Semarangan

Klien: UMKM Batik Semarangan ingin website toko daring sederhana. Hasil dekomposisi lima fase:

Fase 1 — Perencanaan

Wawancara kebutuhan, scope statement, penjadwalan awal. 3 work package.

Fase 2 — Desain

Wireframe, mockup UI, review klien, revisi desain. 4 work package.

Fase 3 — Pengembangan

Setup server, coding katalog, keranjang, pembayaran, admin panel, integrasi. 6 work package.

Fase 4 — Pengujian

Uji fungsi, uji keamanan pembayaran, perbaikan bug. 3 work package.

Fase 5 — Peluncuran

Pelatihan admin toko, go-live. 2 work package.

Mari kita gunakan studi kasus yang akan terus kita pakai sampai akhir slide hari ini: UMKM Batik Semarangan ingin memiliki website toko daring sederhana agar bisa menjual produknya lebih luas, mengikuti jejak pelaku UMKM lain yang sudah lebih dulu bergabung ke Tokopedia. Setelah proses wawancara dan penyusunan scope statement seperti yang kita bahas di bagian pertama, tim proyek mendekomposisi pekerjaan menjadi lima fase besar. Fase perencanaan berisi tiga paket kerja, fase desain berisi empat paket kerja, fase pengembangan yang paling berat berisi enam paket kerja mulai dari setup server sampai integrasi pembayaran, fase pengujian berisi tiga paket kerja, dan fase peluncuran berisi dua paket kerja termasuk pelatihan admin toko. Perhatikan baik-baik angka-angka ini karena kita akan memakainya secara langsung di dua sesi hitung dari nol berikutnya.

Hitung dari Nol — HDN-1: Total Work Package & Estimasi Biaya

Dari studi kasus Batik Semarangan, hitung total work package lalu kalikan dengan rata-rata biaya per paket Rp 2.500.000.

Langkah	Perhitungan	Nilai
+ Fase Perencanaan	3 work package	Total berjalan: 3
+ Fase Desain	3 + 4 work package	Total berjalan: 7
+ Fase Pengembangan	7 + 6 work package	Total berjalan: 13
+ Fase Pengujian	13 + 3 work package	Total berjalan: 16
+ Fase Peluncuran	16 + 2 work package	Total WP: 18
Estimasi biaya total	18 WP x Rp 2.500.000	Rp 45.000.000

Hasil Akhir

18 WP

Estimasi biaya total proyek: Rp 45.000.000

Sekarang kita hitung dari nol berdasarkan lima fase yang baru saja kita lihat, dan Anda bisa mengikuti perhitungan ini di kertas Anda sendiri. Kita mulai dari fase perencanaan yang punya tiga work package, lalu kita tambahkan empat work package dari fase desain sehingga total berjalan menjadi tujuh. Kita tambahkan enam work package dari fase pengembangan, membuat total berjalan menjadi tiga belas, kemudian tiga work package dari fase pengujian membuat total menjadi enam belas, dan terakhir dua work package dari fase peluncuran membuat total keseluruhan menjadi delapan belas work package. Setelah tahu totalnya, kita kalikan dengan asumsi rata-rata biaya delegasi per paket kerja sebesar dua koma lima juta rupiah, sehingga estimasi biaya total proyek website UMKM Batik Semarangan ini adalah delapan belas dikali dua koma lima juta, yaitu empat puluh lima juta rupiah — angka inilah yang menjadi dasar proposal anggaran ke klien di pertemuan berikutnya.

Coba Sendiri: Susun WBS & Uji Rollup Biaya

Tambah atau hapus work package tiap fase dan lihat bagaimana total biaya rollup serta verifikasi aturan 100% otomatis diperbarui.

Hitung dari Nol — HDN-2: Alokasi Persentase Durasi per Fase

Total durasi proyek 60 hari kerja. Hitung persentase alokasi tiap fase — total harus persis 100% (aturan 100% berlaku juga pada jadwal).

Fase	Perhitungan	Persentase
Perencanaan (6 hari)	6 / 60 x 100	10%
Desain (12 hari)	12 / 60 x 100	20%
Pengembangan (27 hari)	27 / 60 x 100	45%
Pengujian (9 hari)	9 / 60 x 100	15%
Peluncuran (6 hari)	6 / 60 x 100	10%
Uji Aturan 100%	10% + 20% + 45% + 15% + 10%	100% ✓

Verifikasi Aturan 100%

100%

6 + 12 + 27 + 9 + 6 = 60 hari — cocok dengan total durasi proyek

Sekarang kita hitung persentase alokasi durasi, dengan total proyek berdurasi enam puluh hari kerja. Fase perencanaan memakan enam hari, sehingga persentasenya enam dibagi enam puluh dikali seratus, hasilnya sepuluh persen. Fase desain memakan dua belas hari, atau dua puluh persen dari total; fase pengembangan menjadi porsi terbesar dengan dua puluh tujuh hari, setara empat puluh lima persen, karena memang di sinilah paket kerja terbanyak berada seperti yang kita hitung di slide sebelumnya. Fase pengujian memakan sembilan hari atau lima belas persen, dan fase peluncuran memakan enam hari terakhir atau sepuluh persen; kalau kita jumlahkan seluruh persentase ini, sepuluh tambah dua puluh tambah empat puluh lima tambah lima belas tambah sepuluh, hasilnya harus persis seratus persen, dan benar saja hasilnya tepat seratus persen, sekaligus menunjukkan aturan seratus persen berlaku bukan hanya pada work package tetapi juga pada alokasi jadwal proyek.

Kesalahan Umum yang Wajib Anda Hindari

Lima jebakan paling sering ditemui pada proyek digital pemula — kenali sebelum Anda mengalaminya sendiri:

Jebakan 1 — Terlalu Umum

WBS berhenti di level fase saja (mis. "Pengembangan") tanpa turun ke work package — tidak bisa diestimasi.

Jebakan 2 — Berbasis Aktivitas, Bukan Deliverable

Menulis "meeting", "diskusi" sebagai elemen WBS, padahal WBS seharusnya berbasis hasil, bukan aktivitas harian.

Jebakan 3 — Melanggar Aturan 100%

Ada pekerjaan penting (mis. dokumentasi, pelatihan) yang lupa dimasukkan → muncul belakangan sebagai "kejutan".

Jebakan 4 — Tanpa WBS Dictionary

Kode WBS ada tapi tak ada penjelasan → tim baru bingung, penanggung jawab tidak jelas.

Jebakan 5 — Disusun sendirian tanpa validasi tim/klien: WBS yang dibuat satu orang tanpa masukan tim teknis sering meremehkan kompleksitas pekerjaan nyata.

Mari kita tutup bagian praktik dengan lima kesalahan yang paling sering saya temui pada proyek mahasiswa maupun tim pemula di industri. Kesalahan pertama adalah WBS yang berhenti terlalu umum, misalnya hanya menulis "pengembangan" tanpa turun ke work package rinci, sehingga tidak bisa diestimasi durasi maupun biayanya. Kesalahan kedua adalah menulis elemen WBS berbasis aktivitas seperti "rapat" atau "diskusi", padahal WBS seharusnya berbasis deliverable atau hasil kerja yang konkret, bukan kegiatan harian. Kesalahan ketiga adalah melanggar aturan seratus persen tanpa disadari, misalnya lupa memasukkan pekerjaan dokumentasi atau pelatihan pengguna, sehingga pekerjaan itu muncul belakangan sebagai kejutan yang mengganggu jadwal. Kesalahan keempat adalah membuat kode WBS tanpa WBS Dictionary pendamping, dan kesalahan kelima yang sering luput adalah menyusun WBS sendirian di ruangan tanpa validasi dari tim teknis atau klien, sehingga kompleksitas pekerjaan nyata sering diremehkan; ingatlah bahwa WBS yang baik selalu lahir dari diskusi, bukan asumsi satu orang saja.

Latihan Kelompok: Susun WBS Anda Sendiri

Bentuk kelompok 3–4 orang. Waktu: 20 menit. Studi kasus: klien UMKM meminta aplikasi reservasi meja untuk kafe kecil di Semarang.

Instruksi Langkah demi Langkah

Langkah 1: Tuliskan 3 kebutuhan klien memakai format "Sebagai [peran], saya butuh [fitur] agar [tujuan]".
Langkah 2: Susun scope statement ringkas — minimal 2 poin in-scope & 2 poin out-of-scope.
Langkah 3: Buat WBS 3 level: minimal 4 fase, tiap fase minimal 2 work package.
Langkah 4: Uji WBS kelompok Anda dengan aturan 100% — apakah ada pekerjaan yang tercecer?
Langkah 5: Satu kelompok akan diminta presentasi 3 menit di depan kelas.

Dosen akan berkeliling memberi masukan langsung — jangan ragu bertanya bila WBS kelompok Anda terasa "terlalu umum" atau "berbasis aktivitas" (lihat Jebakan 1 & 2 slide sebelumnya).

Sekarang saatnya Anda mempraktikkan langsung apa yang sudah dipelajari; silakan bentuk kelompok tiga sampai empat orang, dan kita punya waktu dua puluh menit untuk latihan ini. Studi kasusnya adalah klien UMKM yang meminta aplikasi reservasi meja untuk kafe kecil di Semarang, mirip dengan sistem yang mungkin pernah Anda pakai saat memesan meja secara daring. Ikuti lima langkah di layar: mulai dari menuliskan kebutuhan klien dalam format baku, menyusun scope statement ringkas, membangun WBS tiga level, menguji WBS Anda dengan aturan seratus persen, sampai bersiap untuk presentasi singkat. Saya akan berkeliling ke tiap kelompok selama latihan berlangsung, jadi jangan ragu bertanya kalau Anda ragu apakah WBS kelompok Anda sudah cukup rinci atau justru masih terjebak pada kesalahan umum yang baru saja kita bahas.

Ringkasan & Jembatan ke Pertemuan 4

Hari ini Anda telah menguasai fondasi perencanaan proyek digital: dari kebutuhan klien sampai paket kerja yang siap diestimasi.

Yang Sudah Dikuasai

Product vs project scope, cara menggali kebutuhan klien, komponen scope statement, struktur WBS 3 level, aturan 100%, WBS Dictionary, & cara menghitung jumlah paket kerja/persentase durasi.

Jembatan ke Pertemuan 4

WBS hari ini adalah input utama untuk menyusun proposal proyek & estimasi anggaran realistis minggu depan — setiap work package akan diberi harga.

Tugas mandiri: selesaikan WBS latihan kelompok Anda menjadi dokumen rapi (scope statement + diagram WBS + WBS Dictionary ringkas untuk 3 work package), kumpulkan sebelum pertemuan berikutnya.

Kita sampai di penghujung pertemuan hari ini, dan saya harap Anda kini melihat bahwa menyusun ruang lingkup dan WBS bukan pekerjaan administratif yang membosankan, melainkan fondasi yang menentukan apakah sebuah proyek digital berjalan lancar atau berantakan di tengah jalan. Hari ini kita sudah membedakan lingkup produk dari lingkup proyek, belajar menggali kebutuhan klien secara bertahap, menyusun scope statement lima komponen, memahami struktur hierarki WBS beserta aturan seratus persennya, mengenal WBS Dictionary, dan menghitung sendiri jumlah paket kerja beserta alokasi persentase durasinya memakai studi kasus UMKM Batik Semarangan. Minggu depan di Pertemuan 4, kita akan memakai WBS yang sama persis sebagai dasar menyusun proposal proyek dan estimasi anggaran yang realistis, di mana setiap work package yang Anda susun hari ini akan diberi harga rupiah yang konkret. Selesaikan tugas mandiri Anda dengan merapikan hasil latihan kelompok menjadi dokumen scope statement, diagram WBS, dan WBS Dictionary ringkas, lalu sampai jumpa di pertemuan berikutnya.

Ruang Lingkup Proyek& Work Breakdown Structure

Pertemuan 3 · Menyusun Scope & WBS dari Kebutuhan Klien

Tujuan Pembelajaran Hari Ini

Proyek Gagal Bukan karena Coding Buruk — tapi Lingkup yang Kabur

Dua Lapis Lingkup: Produk vs Proyek

Menggali Kebutuhan Klien: Empat Langkah Bertahap

Lima Komponen Wajib Scope Statement

Dari Kebutuhan Klien Menuju WBS: Satu Alur Utuh

Apa Itu WBS & Aturan 100%

Struktur Hierarki WBS: Tiga Level Utama

Menyusun WBS: Dekomposisi Top-Down Bertahap

WBS Dictionary: Kamus Tiap Paket Kerja

Studi Kasus: WBS Website Toko Daring UMKM Batik Semarangan

Hitung dari Nol — HDN-1: Total Work Package & Estimasi Biaya

Coba Sendiri: Susun WBS & Uji Rollup Biaya

Hitung dari Nol — HDN-2: Alokasi Persentase Durasi per Fase

Kesalahan Umum yang Wajib Anda Hindari

Latihan Kelompok: Susun WBS Anda Sendiri

Ringkasan & Jembatan ke Pertemuan 4

Ruang Lingkup Proyek
& Work Breakdown Structure