Prodi Bisnis Digital · FEB UNDIP

Manajemen Proyek Digital

Pertemuan 6: Penjadwalan Proyek Digital — Gantt Chart & Manajemen Waktu

Mengubah daftar tugas (WBS) menjadi jadwal yang bisa dijalankan tim dan dipantau klien.

RPS minggu 6 · 2x50 menit

Bagian 1 dari 4

Mengapa Penjadwalan Itu Kritis?

Dari WBS ke jadwal: menghubungkan "apa yang dikerjakan" dengan "kapan dikerjakan".

Tujuan Pembelajaran Hari Ini

Sub-CPMK A

Baca

Gantt chart

Mampu membaca dan menginterpretasi Gantt chart: tugas, durasi, milestone, dan garis waktu proyek digital.

Sub-CPMK B

Hitung

Durasi & jalur kritis

Mampu mengestimasi durasi tugas dan menghitung critical path (jalur kritis) sederhana dari sebuah proyek digital.

Sub-CPMK C

Petakan

Dependency tugas

Mampu mengidentifikasi ketergantungan (dependency) antar-tugas: tugas mana yang harus selesai dulu sebelum tugas lain dimulai.

Sub-CPMK D

Susun

Jadwal proyek digital

Mampu menyusun jadwal proyek digital sederhana berbasis WBS, siap dipakai di tools seperti Trello atau Asana.

Studi Kasus: Proyek Website Tokopedia UMKM

Sebuah agensi digital di Semarang mengerjakan microsite e-commerce untuk UMKM batik yang ingin listing di Tokopedia dan punya website sendiri. Tanpa jadwal, tim bekerja "asal jalan".

Minggu ke-3: tim developer menunggu 4 hari karena tim desain belum menyerahkan mockup — padahal keduanya sama-sama dibayar per hari kerja. Klien mulai bertanya-tanya kenapa progress terlihat diam.

Ini adalah gejala klasik tidak adanya penjadwalan & dependency yang jelas — bukan karena tim malas, tapi karena tidak ada peta waktu yang disepakati sejak awal.

Bagian 2 dari 4

Anatomi Gantt Chart

Komponen, cara membaca, dan cara membangunnya dari WBS.

Apa Itu Gantt Chart?

Gantt chart adalah diagram batang horizontal yang menampilkan jadwal proyek: setiap baris adalah satu tugas, sumbu horizontal adalah waktu (hari/minggu), dan panjang batang menunjukkan durasi tugas tersebut.

Dinamai dari Henry Gantt, insinyur Amerika awal abad ke-20. Hingga kini, Gantt chart tetap jadi alat visualisasi jadwal paling populer di dunia manajemen proyek, termasuk proyek digital.

Komponen Utama Gantt Chart

Task Bar

▬▬▬

Batang tugas

Satu batang = satu tugas. Panjangnya proporsional dengan durasi tugas tersebut.

Milestone

◆

Titik tonggak

Penanda pencapaian penting (durasi = 0), misalnya "Mockup Disetujui Klien".

Dependency

→

Panah keterkaitan

Garis penghubung yang menunjukkan tugas mana harus selesai sebelum tugas lain mulai.

Ketiga komponen ini adalah "abjad" Gantt chart — kalau Anda paham ketiganya, Anda bisa membaca jadwal proyek apa pun, sekompleks apa pun bentuknya.

Empat Jenis Dependency Antar-Tugas

Finish-to-Start (FS) — paling umum

Tugas B baru bisa mulai setelah Tugas A selesai.

Contoh: development baru mulai setelah desain UI selesai.

Start-to-Start (SS)

Tugas B mulai bersamaan saat Tugas A mulai.

Contoh: penulisan konten mulai bareng riset SEO.

Finish-to-Finish (FF)

Tugas B harus selesai bersamaan saat Tugas A selesai.

Contoh: dokumentasi selesai bareng testing selesai.

Start-to-Finish (SF) — jarang

Tugas B selesai saat Tugas A mulai.

Contoh: shift tim lama berakhir saat shift baru mulai.

Empat jenis dependency ini penting Anda kuasai karena kesalahan menetapkan tipe dependency adalah sumber kesalahan jadwal paling sering terjadi. Finish-to-Start adalah yang paling sering Anda temui di proyek digital, misalnya tim development tidak bisa mulai coding sebelum desain UI final disetujui. Start-to-Start berarti dua tugas berjalan paralel sejak awal, misalnya riset kata kunci SEO dan penulisan draft konten blog bisa dimulai bersamaan. Finish-to-Finish berarti dua tugas boleh berjalan kapan saja tapi harus tuntas bersamaan, misalnya dokumentasi teknis dan testing akhir. Start-to-Finish jarang dipakai dalam proyek digital dan lebih sering muncul pada penjadwalan operasional seperti pergantian shift kerja, tapi tetap penting Anda kenali agar tidak bingung bila menemuinya di tools seperti MS Project.

Hitung dari Nol: Estimasi Durasi Total Proyek

Proyek microsite UMKM batik punya 4 tugas berurutan (semua Finish-to-Start). Berapa total hari kerja proyek ini?

Langkah	Perhitungan	Nilai
1. Riset & UX	Estimasi tim: 5 hari kerja	5 hari
2. Desain UI	Estimasi tim: 6 hari kerja	6 hari
3. Development	Estimasi tim: 8 hari kerja	8 hari
4. Testing & Rilis	Estimasi tim: 3 hari kerja	3 hari
5. Total durasi (berurutan)	5 + 6 + 8 + 3	22 hari

Total Durasi Proyek

22 Hari

≈ 4,4 minggu kerja (5 hari/minggu)

Bagian 3 dari 4

Critical Path — Jalur Kritis

Menemukan rangkaian tugas yang menentukan cepat-lambatnya proyek selesai.

Apa Itu Critical Path (Jalur Kritis)?

Critical path adalah rangkaian tugas berurutan terpanjang dalam sebuah proyek — menentukan durasi minimum proyek bisa selesai.

Kalau satu saja tugas di jalur kritis terlambat, seluruh proyek otomatis terlambat. Tugas di luar jalur kritis punya "slack" (waktu longgar) — boleh sedikit molor tanpa mengganggu tanggal selesai proyek.

Contoh: dalam proyek yang punya jalur paralel "menulis konten" (4 hari) dan "membangun struktur website" (7 hari) sebelum keduanya digabung untuk rilis — jalur 7 hari itulah yang kritis, sedangkan jalur 4 hari punya slack 3 hari.

Konsep critical path ini sering jadi titik "aha" bagi mahasiswa karena mengubah cara Anda melihat prioritas dalam sebuah proyek. Bayangkan proyek Anda punya dua jalur pekerjaan yang berjalan paralel: tim konten menulis artikel selama 4 hari, sementara tim developer membangun struktur website selama 7 hari, dan keduanya harus selesai sebelum tahap rilis bisa dimulai. Karena jalur developer butuh 7 hari dan jalur konten hanya 4 hari, maka jalur developer itulah yang disebut jalur kritis — ia menentukan kapan proyek benar-benar bisa dirilis. Tim konten punya "slack" atau waktu longgar sebanyak 3 hari, artinya mereka boleh mulai belakangan atau sedikit terlambat tanpa memengaruhi tanggal rilis akhir. Sebagai project manager, perhatian dan sumber daya ekstra Anda harus difokuskan ke jalur kritis, karena keterlambatan di sana langsung berarti keterlambatan seluruh proyek.

Coba Sendiri: Hitung Jalur Kritis Jaringan Tugas

Ubah durasi tiap tugas dalam jaringan dependency lalu amati bagaimana CPM menandai jalur terpanjang & slack tiap jalur lain.

Hitung dari Nol: Menemukan Jalur Kritis

Proyek aplikasi katalog UMKM punya 2 jalur paralel menuju tugas "Rilis" (Finish-to-Finish sebelum rilis). Jalur mana yang kritis?

Langkah	Perhitungan	Nilai
1. Jalur A: Riset → Desain	4 hari + 5 hari	9 hari
2. Jalur B: Setup Server → Development	2 hari + 10 hari	12 hari
3. Bandingkan kedua jalur	12 hari > 9 hari	Jalur B lebih panjang
4. Slack Jalur A	12 − 9	3 hari longgar
5. Durasi proyek (sebelum tahap Rilis)	Diambil dari jalur terpanjang	12 hari

Jalur Kritis

Jalur B

Setup Server → Development (12 hari)

Dari WBS ke Jadwal: Langkah Praktis

Langkah 1–2

Ambil WBS (Work Breakdown Structure) yang sudah disusun pertemuan 3 — daftar semua tugas.
Estimasi durasi tiap tugas bersama tim yang akan mengerjakan (bukan tebakan sepihak PM).

Langkah 3–4

Tentukan dependency — tugas mana harus menunggu tugas lain (FS/SS/FF/SF).
Gambar Gantt chart & identifikasi jalur kritis untuk fokus pengawasan.

Prinsip kunci: jadwal yang baik disusun bersama tim, bukan dipaksakan sepihak oleh project manager — tim yang mengerjakan paling tahu realitas durasinya.

Milestone: Titik Tonggak Proyek

Milestone menandai pencapaian penting tanpa durasi kerja — dipakai untuk komunikasi progress ke klien dan manajemen.

Contoh riil: sebelum e-commerce Tokopedia atau Bukalapak merilis fitur baru, tim internal biasanya melewati milestone "beta rilis" untuk uji terbatas sebelum "go-live" ke seluruh pengguna.

Bagian 4 dari 4

Praktik & Jebakan Umum

Menerapkan penjadwalan pada kasus nyata, dan menghindari kesalahan yang sering terjadi.

Jebakan Umum dalam Penjadwalan Proyek Digital

Jebakan 1

Optimis

Estimasi berlebihan

Durasi dihitung dari skenario "semua lancar", tanpa buffer untuk revisi klien atau bug tak terduga.

Jebakan 2

Lupa

Dependency tersembunyi

Tidak menyadari bahwa tugas API integrasi bergantung pada tugas approval dari pihak ketiga (mis. payment gateway).

Jebakan 3

Statis

Jadwal tak diperbarui

Gantt chart dibuat sekali di awal, lalu tidak pernah direvisi meski realita di lapangan berubah.

Jebakan 4

Solo

Estimasi sepihak PM

Durasi ditentukan PM sendirian tanpa konfirmasi tim pelaksana — sering meremehkan kompleksitas nyata.

Keempat jebakan ini adalah yang paling sering saya temui, baik dalam studi kasus akademik maupun praktik nyata konsultasi proyek digital. Jebakan pertama, estimasi optimis, terjadi ketika PM menghitung durasi seolah semuanya akan berjalan sempurna tanpa revisi — padahal klien hampir selalu meminta revisi desain, dan bug pasti muncul saat testing. Jebakan kedua adalah dependency tersembunyi, misalnya integrasi payment gateway seperti Midtrans atau Xendit yang butuh proses approval dari pihak ketiga, dan proses itu di luar kendali tim internal. Jebakan ketiga, jadwal statis, terjadi ketika Gantt chart dibuat di awal proyek lalu tidak pernah disentuh lagi meski kondisi lapangan berubah drastis. Jebakan keempat adalah estimasi sepihak PM tanpa melibatkan tim — ingat kembali prinsip di slide sebelumnya bahwa tim pelaksana paling tahu realitas kerjanya sendiri.

Estimasi Durasi: Tiga Pendekatan

Pendekatan	Cara Kerja	Cocok Untuk
Estimasi Titik Tunggal	Satu angka pasti, mis. "5 hari"	Tugas rutin, sudah sering dikerjakan tim
Estimasi Rentang	Rentang optimis–pesimis, mis. "3–7 hari"	Tugas dengan ketidakpastian sedang
PERT (3 Titik)	(Optimis + 4×Realistis + Pesimis) ÷ 6	Tugas kompleks & berisiko tinggi, mis. integrasi API baru

PERT = (O + 4M + P) ÷ 6

O = optimis, M = paling mungkin (most likely), P = pesimis.

Diskusi Kelompok: Susun Gantt Chart Sederhana

Instruksi (15 menit, kelompok 4 orang): Sebuah startup ingin membangun aplikasi pemesanan katering online untuk pasar Semarang. Tugas: Riset pasar (3 hari) → Desain UI (4 hari) → Development (7 hari) → Testing (2 hari), semua Finish-to-Start. Ada juga tugas paralel "Setup Payment Gateway" (5 hari) yang harus selesai sebelum Testing dimulai (Finish-to-Finish dengan Development).

Pertanyaan 1

Gambarkan Gantt chart sederhana untuk kelima tugas ini di kertas/whiteboard digital.

Pertanyaan 2

Tentukan jalur kritis: apakah jalur "Development" atau jalur "Payment Gateway" yang menentukan kapan Testing bisa mulai?

Kunci Jawaban: Analisis Jalur Kritis Diskusi

Jalur	Tugas	Total Durasi
Jalur Utama	Riset (3) + Desain (4) + Development (7)	14 hari
Jalur Paralel	Setup Payment Gateway	5 hari

Jalur Utama (14 hari) > Jalur Paralel (5 hari) → Jalur Utama adalah jalur kritis. Payment Gateway punya slack 9 hari — boleh mulai belakangan, asalkan selesai sebelum hari ke-14.

Dari Kertas ke Software: Trello & Asana

Konsep Gantt chart dan dependency yang Anda pelajari hari ini adalah fondasi dari fitur "Timeline" atau "Gantt View" di tools manajemen proyek modern.

Trello

Board

Kartu & kolom

Fitur "Timeline View" menampilkan kartu tugas dalam format Gantt sederhana dengan tanggal mulai/selesai.

Asana

Timeline

Gantt bawaan

Fitur "Timeline" memungkinkan menarik garis dependency antar-tugas secara visual, drag-and-drop.

Pertemuan 13 nanti akan mempraktikkan kedua tools ini secara langsung — hari ini Anda membangun fondasi konsepnya terlebih dahulu.

Kaitan Penjadwalan dengan Scope Creep

Jadwal yang solid adalah garis pertahanan pertama melawan scope creep (perubahan ruang lingkup proyek yang merembes tanpa persetujuan formal) — topik pertemuan 7 minggu depan.

Tanpa jadwal jelas, permintaan tambahan klien ("bisa tambah fitur ini sedikit?") sulit dinilai dampaknya terhadap waktu — akhirnya "sedikit" itu menumpuk dan proyek molor tanpa disadari.

Dengan Gantt chart & jalur kritis yang sudah dipetakan, Anda bisa langsung menunjukkan ke klien: "Permintaan ini akan menggeser tanggal rilis sebanyak X hari."

Slide ini menjadi jembatan penting menuju materi pertemuan depan, karena penjadwalan yang baik ternyata juga alat pertahanan terhadap masalah lain yang sangat umum: scope creep, yaitu ketika ruang lingkup proyek merembes membesar tanpa persetujuan resmi. Bayangkan klien Anda, misalnya pemilik brand fashion online, tiba-tiba minta "tambah sedikit fitur wishlist" di tengah proyek. Tanpa jadwal yang jelas, permintaan semacam ini terasa sepele dan sering disetujui begitu saja oleh tim, padahal efeknya bisa menggeser jalur kritis. Dengan Gantt chart dan analisis jalur kritis yang sudah Anda kuasai hari ini, Anda sebagai PM punya alasan konkret dan berbasis data untuk mengatakan ke klien: permintaan tambahan ini akan menggeser tanggal rilis sekian hari, sehingga keputusan menerima atau menolak jadi lebih transparan bagi kedua pihak.

Rangkuman: Cheat Sheet Penjadwalan Proyek Digital

Konsep	Definisi Singkat
Gantt Chart	Diagram batang yang memvisualisasikan tugas, durasi, dan waktu proyek
Dependency (FS/SS/FF/SF)	Aturan urutan antar-tugas — mana harus menunggu mana
Critical Path	Rangkaian tugas terpanjang yang menentukan durasi minimum proyek
Slack	Waktu longgar pada tugas di luar jalur kritis
Milestone	Titik tonggak pencapaian penting, tanpa durasi kerja
PERT	Estimasi durasi 3-titik (optimis, realistis, pesimis) untuk tugas berisiko tinggi

Kesalahan Umum vs Solusi Praktis

Kesalahan

Estimasi durasi tanpa melibatkan tim pelaksana
Tidak ada buffer untuk revisi klien
Jadwal dibuat sekali lalu tak pernah diperbarui

Solusi Praktis

Libatkan tim saat estimasi (workshop singkat 30 menit)
Tambahkan buffer 10-20% di tugas berisiko tinggi
Review & update Gantt chart tiap minggu (stand-up meeting)

Penutup & Persiapan Pertemuan 7

Minggu Depan: Scope Creep

Pertemuan 7 membahas pengelolaan perubahan ruang lingkup proyek & dokumen change request — melanjutkan langsung dari jadwal yang Anda susun hari ini.

Tugas Anda

1 Gantt

Chart mandiri

Susun Gantt chart sederhana (min. 5 tugas + 1 dependency FF/SS) untuk ide proyek digital pilihan Anda sendiri.