RPS minggu 11 · 2x50 menit

Manajemen Proyek Teknologi

Tantangan Khas Proyek Pengembangan Produk Baru

Pertemuan 10 · Mata Kuliah Manajemen Teknologi · Program Studi Manajemen, FEB UNDIP

Bagian I

Mengapa Proyek Teknologi Berbeda

Karakteristik proyek pengembangan produk baru berbasis teknologi dan sumber ketidakpastiannya.

Apa itu Proyek Pengembangan Produk Baru Berbasis Teknologi?

Definisi

Proyek pengembangan produk baru (new product development project) berbasis teknologi adalah upaya sementara dan bertujuan spesifik untuk menghasilkan produk, layanan, atau fitur baru yang melibatkan teknologi belum teruji sepenuhnya di pasar.

Berbeda dari operasi rutin perusahaan, proyek punya awal dan akhir yang jelas, anggaran terbatas, dan tim lintas fungsi yang dibentuk khusus.

Contoh Nyata

GoPay Later

proyek pengembangan fitur cicilan digital Gojek

Melibatkan tim engineering, risk management, legal, dan marketing yang bekerja dalam batas waktu dan anggaran tertentu sampai fitur diluncurkan ke pasar.

Proyek Teknologi vs Proyek Konvensional

Perbedaan paling mendasar: proyek teknologi menghadapi ketidakpastian ganda — belum tahu pasti apakah teknologinya akan berhasil (technical uncertainty) DAN belum tahu pasti apakah pasar akan menerimanya (market uncertainty).

Segitiga Kendala Proyek (Triple Constraint)

Kalau salah satu sisi (waktu/biaya/lingkup) berubah, sisi lain atau kualitas produk di tengah HARUS ikut menyesuaikan — tidak ada "gratis" dalam manajemen proyek.

Dua Sumber Ketidakpastian: Teknis vs Pasar

Matriks ini membantu Anda memetakan tingkat risiko proyek teknologi berdasarkan dua sumbu. Sumbu vertikal adalah ketidakpastian teknis, yaitu seberapa yakin tim bahwa teknologinya akan bekerja sesuai rencana. Sumbu horizontal adalah ketidakpastian pasar, yaitu seberapa yakin tim bahwa produk ini akan diterima pelanggan. Kuadran kanan atas, teknologi baru untuk pasar yang belum terbentuk, adalah yang paling berisiko — contohnya proyek kendaraan listrik startup baru yang sekaligus harus membangun teknologi baterai dan mendidik pasar dari nol. Sebaliknya, kuadran kiri bawah, teknologi teruji untuk pasar yang sudah dikenal, misalnya membuat aplikasi kasir sederhana untuk warung, jauh lebih aman dan dapat diprediksi. Manajer proyek yang baik harus mengenali di kuadran mana proyeknya berada sebelum menentukan pendekatan pengelolaan yang tepat.

Bagian II

Metodologi & Tahapan Pengelolaan Proyek

Stage-gate process, perbandingan waterfall vs agile, serta teknik estimasi waktu proyek.

Stage-Gate Process: Tahapan Berjenjang dengan Titik Keputusan

Di setiap gate (gerbang keputusan), manajemen meninjau: lanjutkan, hentikan, atau perbaiki dulu proyeknya — mencegah dana terus mengalir ke proyek yang sudah jelas tidak layak.

Coba Sendiri: Stage-Gate GO/KILL Decider

Simulasikan keputusan gate sungguhan — atur kriteria evaluasi proyek dan lihat apakah rekomendasinya GO, HOLD, atau KILL.

Waterfall vs Agile/Scrum: Dua Filosofi Pengelolaan Proyek

Langkah 1 — Waterfall

Seluruh requirement (kebutuhan produk) ditetapkan di awal, sebelum coding dimulai.
Tahapan berurutan: analisis → desain → bangun → uji → luncurkan — tidak kembali ke tahap sebelumnya.
Cocok untuk proyek dengan spesifikasi stabil, misalnya sistem inti perbankan (core banking) yang diatur regulasi ketat.

Langkah 2 — Agile/Scrum

Pekerjaan dipecah menjadi sprint (siklus kerja pendek, biasanya 2 minggu) dengan hasil parsial tiap sprint.
Requirement boleh berubah di setiap sprint berdasarkan umpan balik pengguna nyata.
Cocok untuk produk digital baru yang butuh iterasi cepat, misalnya fitur aplikasi e-commerce.

Banyak perusahaan teknologi Indonesia memakai pendekatan hibrida: infrastruktur inti (server, database) memakai waterfall karena butuh stabilitas, sementara fitur produk memakai agile karena butuh kecepatan iterasi.

Hitung dari Nol #1: Estimasi Waktu Proyek dengan PERT

Kasus: tim developer mengestimasi waktu penyelesaian modul pembayaran aplikasi. Estimasi optimis (O) = 8 hari, paling mungkin (M) = 14 hari, pesimis (P) = 26 hari.

Waktu Estimasi (WE) = (O + 4M + P) ÷ 6

Langkah	Perhitungan	Nilai
1. Bobot estimasi paling mungkin	4 × 14 hari	56 hari
2. Jumlahkan O + 4M + P	8 + 56 + 26	90 hari
3. Waktu estimasi (WE)	90 ÷ 6	15 hari
4. Standar deviasi (σ)	(26 − 8) ÷ 6	3 hari
5. Rentang keyakinan ~68%	15 ± 3 hari	12–18 hari

Kesimpulan

15 hari

estimasi waktu penyelesaian modul pembayaran, dengan rentang keyakinan 12–18 hari

Teknik PERT, singkatan dari Program Evaluation and Review Technique, memberi bobot lebih besar pada estimasi "paling mungkin" karena dianggap paling realistis, sementara estimasi optimis dan pesimis tetap diperhitungkan sebagai batas skenario. Pertama kita kalikan estimasi paling mungkin sebesar 14 hari dengan bobot 4, menghasilkan 56 hari. Kedua kita jumlahkan dengan estimasi optimis 8 hari dan pesimis 26 hari, totalnya 90 hari. Ketiga kita bagi dengan 6, sesuai rumus, menghasilkan estimasi waktu 15 hari. Keempat, kita hitung standar deviasi dari rentang pesimis dikurangi optimis dibagi 6, menghasilkan 3 hari, yang menunjukkan seberapa besar ketidakpastian estimasi ini. Kelima, ini memberi kita rentang keyakinan sekitar 68 persen antara 12 sampai 18 hari. Teknik ini jauh lebih realistis dibanding sekadar menebak satu angka tunggal, karena secara eksplisit mengakui ketidakpastian yang melekat dalam pengembangan produk teknologi.

Kegagalan Umum Proyek Teknologi

Sisi Lingkup & Perencanaan

Scope creep: fitur terus ditambah tanpa penyesuaian waktu/anggaran.
Estimasi waktu & biaya terlalu optimis di awal (planning fallacy).
Requirement tidak jelas sejak awal, sering berubah arah.

Sisi Eksekusi & Tim

Komunikasi buruk antar-tim lintas fungsi (engineering vs marketing).
Ketergantungan berlebih pada satu individu kunci (key person risk).
Kurangnya dukungan sponsor/manajemen puncak di tengah jalan.

Riset industri menunjukkan sebagian besar proyek teknologi mengalami ~keterlambatan atau pembengkakan biaya — jarang yang selesai persis sesuai rencana awal.

Mari kita bahas pola kegagalan yang berulang di industri teknologi. Scope creep adalah musuh nomor satu — bayangkan tim developer aplikasi belanja daring yang awalnya hanya diminta membuat fitur keranjang belanja, tapi di tengah jalan manajemen terus menambah permintaan fitur wishlist, kupon, dan chat penjual tanpa menambah waktu maupun anggota tim. Planning fallacy adalah kecenderungan manusia yang secara sistematis terlalu optimis memperkirakan waktu penyelesaian, sesuatu yang coba diatasi dengan teknik PERT yang baru kita pelajari. Di sisi eksekusi, konflik antara tim engineering yang fokus pada kualitas kode dengan tim marketing yang ingin cepat meluncurkan produk adalah sumber gesekan paling umum. Memahami pola-pola kegagalan ini adalah langkah pertama untuk mencegahnya di proyek yang Anda kelola kelak.

Coba Sendiri: Simulasikan Estimasi Waktu Proyek Anda

Masukkan estimasi optimis, paling mungkin, dan pesimis untuk aktivitas proyek Anda sendiri, lalu lihat bagaimana rentang keyakinannya berubah.

Bagian III

Tantangan Khas & Manajemen Risiko Proyek Teknologi

Risiko teknis, dinamika tim lintas fungsi, pengukuran kinerja proyek, dan studi kasus Indonesia.

Risiko Teknis: Keusangan Teknologi & Ketergantungan Vendor

Langkah 1 — Keusangan Teknologi

Teknologi yang dipilih di awal proyek bisa usang sebelum proyek selesai, terutama proyek berdurasi panjang.
Contoh: memilih kerangka kerja (framework) pemrograman yang ditinggalkan komunitasnya di tengah jalan.
Mitigasi: pilih teknologi dengan dukungan komunitas luas & roadmap jelas, bukan sekadar tercepat.

Langkah 2 — Ketergantungan Vendor

Vendor lock-in: proyek terlalu bergantung pada satu penyedia teknologi/cloud tertentu.
Risiko: harga vendor naik sepihak, atau vendor berhenti operasi di Indonesia.
Mitigasi: kontrak jelas, arsitektur modular, dan evaluasi vendor alternatif secara berkala.

Mari kita telusuri dua risiko teknis paling khas ini langkah demi langkah. Bayangkan sebuah startup logistik yang tiga tahun lalu memilih teknologi basis data tertentu karena sedang tren, namun kini komunitas pengembangnya menyusut dan sulit mencari talenta yang menguasainya — inilah keusangan teknologi yang nyata terjadi. Mitigasinya adalah selalu memilih teknologi dengan ekosistem dan dukungan jangka panjang, bukan sekadar yang paling canggih saat ini. Kedua, ketergantungan vendor sering terjadi ketika perusahaan menaruh seluruh infrastrukturnya di satu penyedia layanan cloud tunggal; jika penyedia tersebut menaikkan harga secara sepihak atau mengalami gangguan besar, seluruh operasional bisa terhenti. Perusahaan yang bijak biasanya merancang arsitektur modular sehingga bisa berpindah vendor tanpa membangun ulang semuanya dari nol.

Tim Lintas-Fungsi: Sumber Konflik & Cara Mengelolanya

Engineering

Kualitas

Fokus pada stabilitas kode & menghindari bug — sering ingin waktu lebih panjang.

Marketing

Kecepatan

Fokus pada momentum pasar & jadwal peluncuran — ingin rilis secepatnya.

Manajemen Proyek

Keseimbangan

Menjembatani kedua kepentingan lewat prioritisasi fitur & komunikasi transparan.

Proyek teknologi yang sukses biasanya punya satu manajer proyek dengan otoritas jelas untuk memediasi konflik antar-fungsi — bukan dibiarkan berdebat tanpa keputusan final.

Salah satu tantangan paling manusiawi dalam proyek teknologi adalah menyatukan tim yang berasal dari fungsi berbeda dengan kepentingan yang kadang bertentangan. Tim engineering di sebuah perusahaan fintech biasanya sangat berhati-hati karena bug pada sistem pembayaran bisa berakibat fatal, sehingga mereka cenderung meminta waktu pengujian lebih panjang. Sementara itu tim marketing sudah menjanjikan tanggal peluncuran kepada calon investor atau media, sehingga mendorong percepatan. Di sinilah peran manajer proyek menjadi krusial, sebagai penengah yang punya otoritas mengambil keputusan final berdasarkan data risiko, bukan sekadar kompromi tanpa dasar. Perusahaan yang tidak punya manajer proyek dengan otoritas jelas sering mengalami proyek yang terkatung-katung karena setiap divisi menarik ke arah masing-masing.

Hitung dari Nol #2: Earned Value Management (SPI & CPI)

Kasus: proyek pengembangan aplikasi ditargetkan menyelesaikan pekerjaan senilai Rp100 juta (Planned Value) pada bulan ke-3. Realisasi: pekerjaan yang benar-benar selesai bernilai Rp80 juta (Earned Value), dengan biaya aktual yang sudah dikeluarkan Rp95 juta (Actual Cost).

Langkah	Perhitungan	Nilai
1. Schedule Performance Index (SPI)	80 juta ÷ 100 juta	0,80
2. Cost Performance Index (CPI)	80 juta ÷ 95 juta	0,84
3. Interpretasi SPI < 1	proyek di belakang jadwal	tertinggal ~20%
4. Interpretasi CPI < 1	biaya melebihi nilai yang dihasilkan	boros ~16%

Kesimpulan

SPI 0,80 · CPI 0,84

proyek tertinggal jadwal sekaligus membengkak biaya — perlu intervensi manajemen segera

Earned value management adalah salah satu alat paling ampuh untuk mengukur kinerja proyek secara objektif, bukan sekadar perasaan "kayaknya proyek ini lancar-lancar saja". Pertama, Schedule Performance Index kita hitung dari nilai pekerjaan yang benar-benar selesai sebesar 80 juta dibagi target rencana 100 juta, menghasilkan 0,80 — nilai di bawah 1 berarti proyek tertinggal jadwal. Kedua, Cost Performance Index kita hitung dari nilai pekerjaan selesai 80 juta dibagi biaya aktual yang sudah dikeluarkan 95 juta, menghasilkan 0,84 — nilai di bawah 1 berarti setiap rupiah yang dikeluarkan menghasilkan nilai lebih kecil dari seharusnya, alias proyek boros. Kombinasi kedua indeks di bawah 1 ini adalah tanda bahaya klasik yang harus segera dilaporkan ke manajemen puncak, karena tanpa intervensi, proyek berisiko semakin jauh dari target waktu maupun anggaran.

Studi Kasus Indonesia: Proyek Fitur Baru di Startup Teknologi

Ringkasan Kasus

Sebuah startup agri-tech lokal mengembangkan fitur pembiayaan petani dalam waktu 4 bulan. Di bulan kedua, tim menemukan bahwa regulasi OJK terkait fintech lending mengharuskan proses verifikasi tambahan yang tidak diperhitungkan di rencana awal.

Manajer proyek melakukan re-scoping (penyesuaian ulang lingkup): fitur inti tetap diluncurkan tepat waktu dalam versi terbatas, sementara fitur lanjutan ditunda ke rilis berikutnya (fase 2).

Pelajaran kunci: proyek teknologi yang beroperasi di sektor teregulasi (fintech, kesehatan) HARUS memasukkan risiko regulasi sebagai bagian eksplisit dari perencanaan proyek sejak awal, bukan kejutan di tengah jalan.

Kasus ini menggambarkan tantangan yang sangat khas Indonesia, di mana banyak startup teknologi finansial beroperasi di sektor yang diawasi ketat oleh Otoritas Jasa Keuangan. Tim proyek yang hanya fokus pada aspek teknis sering lupa bahwa perubahan regulasi bisa datang tiba-tiba dan mengubah lingkup pekerjaan secara signifikan. Yang menarik dari kasus ini adalah respons manajer proyek yang tidak memaksakan semua fitur selesai tepat waktu dengan mengorbankan kepatuhan regulasi, melainkan melakukan re-scoping cerdas: meluncurkan versi inti yang sudah patuh regulasi tepat waktu, sambil menunda fitur tambahan ke fase berikutnya. Ini adalah contoh nyata bagaimana segitiga kendala proyek yang kita bahas di awal — waktu, biaya, lingkup — dinegosiasikan secara sadar, bukan dibiarkan proyek gagal total karena mencoba mempertahankan semuanya sekaligus.

Faktor Kunci Sukses Proyek Pengembangan Produk Baru

Faktor Organisasional

Dukungan penuh manajemen puncak (executive sponsorship) sepanjang proyek.
Tim lintas fungsi dengan peran & tanggung jawab jelas sejak awal.
Budaya belajar dari kegagalan, bukan menghukum eksperimen yang gagal.

Faktor Teknis & Proses

Requirement digali langsung dari calon pengguna, bukan asumsi internal.
Estimasi waktu/biaya realistis memakai teknik seperti PERT, bukan tebakan.
Pemantauan kinerja rutin (EVM) untuk deteksi dini penyimpangan.

Ringkasan Pertemuan 10

Konsep Inti

Proyek teknologi menghadapi ketidakpastian ganda: teknis & pasar.
Segitiga kendala (waktu-biaya-lingkup) selalu saling mengorbankan.
Stage-gate & agile adalah dua pendekatan pengelolaan yang saling melengkapi.

Alat Analisis yang Dikuasai

PERT: estimasi waktu proyek dengan tiga skenario (O, M, P).
SPI & CPI: mengukur kinerja jadwal & biaya proyek yang sedang berjalan.
Risiko khas: keusangan teknologi, vendor lock-in, dan risiko regulasi.

Mari kita rangkum perjalanan kita hari ini. Kita mulai dari memahami mengapa proyek teknologi begitu berbeda karena ketidakpastian ganda pada sisi teknis dan pasar, lalu mempelajari segitiga kendala yang selalu memaksa trade-off antara waktu, biaya, dan lingkup pekerjaan. Kita juga membandingkan dua filosofi pengelolaan proyek, stage-gate yang berjenjang dengan gerbang keputusan, dan agile yang iteratif dan fleksibel. Dua alat analisis kuantitatif yang sudah Anda kuasai hari ini, yaitu PERT untuk estimasi waktu dan earned value management untuk mengukur kinerja proyek yang sedang berjalan, adalah keterampilan yang akan sangat berguna baik sebagai manajer proyek maupun sebagai anggota tim yang perlu memahami laporan kinerja proyek. Pertemuan berikutnya kita akan melangkah ke topik ekosistem inovasi dan kolaborasi lintas lembaga.

Latihan & Persiapan Pertemuan 11

Tugas Individu

Pilih satu produk/fitur teknologi yang pernah Anda gunakan (aplikasi, platform, atau layanan digital apa saja). Identifikasi: (1) estimasi tingkat ketidakpastian teknis & pasarnya saat pertama diluncurkan, (2) minimal satu risiko khas proyek teknologi yang mungkin dihadapi timnya, (3) hitung simulasi PERT sederhana untuk satu aktivitas pengembangan fiktif dari produk tersebut.

Kumpulkan analisis singkat (maksimal 1 halaman) sebelum pertemuan berikutnya. Pertemuan 11 akan membahas ekosistem inovasi: kolaborasi universitas-industri-pemerintah dan open innovation.