Penyebab Struktural Kegagalan Proyek IT: Kebodohan Manajerial yang Berulang dan Biayanya

• Ringkasan singkat:
  • Topik utama: Kegagalan proyek IT bukan berasal dari tantangan teknis, melainkan dari 'ketidaktahuan yang disengaja' di tingkat manajemen dan kesombongan yang menolak belajar dari kegagalan masa lalu.
  • Angka utama: Dalam 20 tahun terakhir, belanja IT global naik 3 kali lipat (5,6 triliun dolar), tetapi tingkat keberhasilan tetap stagnan, sementara 75% anggaran habis hanya untuk pemeliharaan sistem legacy.
  • Kasus utama: Buruknya tata kelola secara menyeluruh pada sistem Phoenix di Kanada dan penutupan tidak etis dalam kasus Horizon di Inggris bukan sekadar 'blunder', melainkan 'kejahatan administratif (Administrative Evil)'.

---

1. Pendahuluan: Tingkat kegagalan yang tidak membaik meski investasi sangat besar

• Efisiensi yang stagnan dibanding investasi:
  • Sejak 2005, belanja IT global melonjak lebih dari tiga kali lipat dari 1,7 triliun dolar menjadi 5,6 triliun dolar pada 2025.
  • Namun, meski biaya yang digelontorkan sangat besar, tingkat keberhasilan proyek perangkat lunak tidak menunjukkan perbaikan yang berarti dalam 20 tahun terakhir.
• Waspada terhadap ilusi seputar AI:
  • Banyak eksekutif berharap alat AI atau coding assistant seperti Copilot akan membuat proyek berskala besar berhasil, tetapi penulis bersikap skeptis terhadap hal ini.
  • AI tidak mampu menyelesaikan kompleksitas system engineering, trade-off finansial, dan yang terpenting, 'politik organisasi (Organizational Politics)' di dalam proyek.
• Kegagalan yang bersifat universal:
  • Kegagalan perangkat lunak terjadi tanpa pandang bulu, terlepas dari negara, ukuran perusahaan, maupun status profit/nonprofit, dan ini berasal bukan dari kesalahan teknis semata, tetapi dari 'kurangnya imajinasi manusia' dan 'tujuan yang tidak realistis'.

2. Pembahasan: Analisis mendalam jenis dan penyebab kegagalan

2.1. 'Blunder' yang terus berulang dan penolakan untuk belajar

• Perbedaan antara kegagalan dan blunder:
  • Kegagalan sebagai bentuk 'creative destruction' yang terjadi saat menantang batas teknis seharusnya disambut baik.
  • Namun, sebagian besar kegagalan IT hanyalah pengulangan penyebab yang sudah terdokumentasi selama puluhan tahun—seperti ketiadaan manajemen risiko dan meremehkan kompleksitas—yakni 'blunder bodoh'.
• Kesombongan manajemen:
  • Manajer proyek cenderung mengklaim bahwa proyek mereka "khusus dan unik", lalu mengabaikan data atau contoh kegagalan masa lalu.
  • Ini bukan sekadar ketidaktahuan, melainkan 'ketidaktahuan yang disengaja (Willful Ignorance)' yang secara sadar menolak melihat tanda-tanda risiko.
• Jebakan sistem legacy:
  • Organisasi di AS menghabiskan lebih dari 520 miliar dolar per tahun hanya untuk memelihara sistem legacy, setara dengan 70–75% dari total anggaran IT.
  • Karena takut gagal saat mengganti sistem, modernisasi ditunda sampai sistem runtuh secara fisik (misalnya mainframe kantor kendaraan bermotor Louisiana) atau benar-benar kehilangan efisiensi biaya.

2.2. Detail kasus-kasus kegagalan besar dan dampaknya

• Sistem payroll Phoenix di Kanada:
  • Salah langkah awal: Saat mengadopsi solusi siap pakai (PeopleSoft), proyek ini mencoba menyesuaikan 80.000 aturan penggajian dan 105 perjanjian serikat pekerja.
  • Harga dari pemotongan anggaran: Demi menjalankan proyek dengan kurang dari 60% anggaran yang diusulkan vendor, mereka memaksa penghapusan fungsi payroll inti, pengurangan pengujian, dan penghilangan pilot test yang esensial.
  • Hasil: Sistem runtuh segera setelah mulai beroperasi pada 2016. Kesalahan pembayaran gaji menimbulkan penderitaan finansial bagi karyawan, dan bahkan disebut sebagai salah satu penyebab bunuh diri beberapa pegawai.
  • Biaya: Anggaran awalnya 310 juta dolar Kanada, tetapi biaya pemulihan dan penyelesaiannya kini melampaui 5,1 miliar dolar Kanada (sekitar 3,6 miliar dolar AS).
• Skandal Horizon di Kantor Pos Inggris:
  • Cacat teknis: Bug middleware pada sistem yang disediakan Fujitsu menyebabkan kesalahan ketidaksesuaian keuangan.
  • Penutupan terorganisir: Manajemen mengetahui cacat perangkat lunak itu tetapi menutupinya, dan justru menuntut 3.500 kepala kantor pos atas tuduhan penggelapan dan pencurian. Sebanyak 900 orang divonis bersalah dan dipenjara.
  • Biaya sosial: Para korban mengalami kebangkrutan, perceraian, pemenjaraan, dan bunuh diri. Ini tercatat sebagai kegagalan IT dan salah penegakan hukum terburuk dalam sejarah Inggris.

2.3. Pengambilan keputusan otomatis dan 'kejahatan administratif'

• Kekerasan algoritmik:
  • Sistem MiDAS di negara bagian Michigan, AS (untuk mendeteksi kecurangan tunjangan pengangguran) dan Robodebt di Australia (untuk mendeteksi kecurangan tunjangan sosial) membuat keputusan hanya berdasarkan algoritma tanpa pengawasan manusia.
  • Puluhan ribu warga tak bersalah dicap sebagai kriminal, tetapi para birokrat menolak memberi kompensasi atau menghindari tanggung jawab bahkan setelah kesalahan sistem terbukti.
• Risiko adopsi AI:
  • 'Kejahatan administratif (Administrative Evil)' semacam ini akan makin memburuk seiring AI semakin dalam masuk ke infrastruktur publik.
  • Uni Eropa telah memperkenalkan 'hak untuk meminta penjelasan', tetapi secara global transparansi dan kejelasan akuntabilitas algoritma semakin mendesak.

3. Kesimpulan: Solusi dan tugas komunitas IT

• Metodologi (Agile/DevOps) bukan kunci universal:
  • Ada laporan bahwa tingkat kegagalan proyek Agile bisa mencapai 65%, yang menunjukkan bahwa metodologi itu sendiri tidak menjamin keberhasilan. Tanpa kepemimpinan yang konsisten dan disiplin organisasi, metodologi baru apa pun akan gagal.
• Evaluasi risiko yang jujur dan tanggung jawab etis:
  • Sebelum proyek dimulai, harus ada gap analysis yang jujur tentang "apa yang diketahui, dan apa yang tidak diketahui".
  • Konsep 'AI yang berpusat pada manusia (Human-centered AI)' perlu diperluas ke semua proyek IT, sehingga dampak emosional dan finansial dari kegagalan sistem terhadap pengguna akhir dimasukkan ke dalam analisis biaya-manfaat.
• Dorongan perubahan sikap manajemen:
  • Perangkat lunak pada dasarnya rapuh (Fragile) dan kompleks. Manajemen harus menghormati dan mendukung pengembangan perangkat lunak bukan hanya sebagai pemegang kuasa atas anggaran, tetapi juga sebagai pihak yang bertanggung jawab ketika kegagalan terjadi.
  • Menghentikan pengulangan kesalahan adalah satu-satunya jalan agar industri IT keluar dari 'krisis (Crisis)'.

[baeba]

Ringkasan reaksi komentar Hacker News

1. Ketiadaan strategi peluncuran bertahap dan scaling (Start Small)

• Kegagalan yang nyaris tak terelakkan dari pendekatan 'big bang': Menerapkan proyek skala nasional sekaligus adalah tindakan bunuh diri. Strategi untuk memverifikasi secara berurutan dalam unit kecil (desa → kota → negara) lalu memperluasnya adalah hal yang esensial.
• Perbedaan produk vs sistem: Tidak seperti produk tunggal seperti WhatsApp, sistem enterprise yang kompleks harus menanggung skala besar sejak awal, sehingga pendekatannya harus berbeda.
• Solusi inti: Prinsip "bangun kecil, verifikasi, lalu tambahkan fitur" sedang diabaikan.

2. Ketidakmampuan manajemen dan penghindaran tanggung jawab (Management Issues)

• Struktur kekuasaan tanpa tanggung jawab: Saat proyek gagal, developer menutupinya dengan kerja lembur, tetapi manajemen sebagai pengambil keputusan tidak menanggung tanggung jawab, atau malah mengambil bonus—struktur yang kontradiktif ini menuai kritik.
• Kurangnya pemahaman teknis: Pemaksaan jadwal yang tidak realistis sambil mengabaikan tingkat kesulitan teknis, serta budaya komando-atasan yang menolak mendengar "kabar buruk", menghambat penyelesaian masalah.
• Pengambilan keputusan politis: Solusi cenderung ditentukan oleh politik internal perusahaan atau hubungan dengan vendor eksternal (seperti rebate), bukan oleh kecocokan teknis.

3. Requirement yang tak terkendali dan kompleksitas (Complexity & Scope Creep)

• Tidak ada penyederhanaan proses sebagai langkah awal: Seperti pada kasus Phoenix Project, upaya untuk langsung mendigitalisasi 80.000 aturan penggajian tanpa merapikannya terlebih dulu adalah akar masalahnya. Proses offline yang kacau hanya akan menghasilkan sistem digital yang kacau.
• Perubahan requirement yang sering: Perluasan cakupan pekerjaan (scope creep) akibat perubahan keinginan manajemen atau pelanggan selama proyek berjalan menyeret proyek ke dalam rawa.

4. Budaya developer dan insentif yang keliru (Developer Culture)

• Resume-Driven Development (RDD): Demi kepentingan pindah kerja, teknologi terbaru yang sedang tren (framework) dipaksakan masuk alih-alih fokus pada keberhasilan proyek, sehingga utang teknis makin bertambah.
• Terputusnya proses belajar: Budaya job hopping yang sering, dengan siklus 2–3 tahunan, menutup kesempatan bagi developer untuk menyaksikan kegagalan jangka panjang dari kode yang mereka buat sendiri dan mengambil pelajaran darinya.
• Obsesi menciptakan ulang: Praktik tidak efisien berupa menulis ulang kode dari nol demi aktualisasi ego, alih-alih memanfaatkan solusi lama yang sudah terbukti.

5. Karakteristik khusus rekayasa perangkat lunak (Engineering Nature)

• Tidak adanya batasan fisik: Berbeda dari konstruksi/ hardware, perangkat lunak tidak memiliki batasan fisik sehingga memungkinkan kompleksitas tanpa batas, dan inilah yang memicu kondisi di luar kendali.
• Tidak belajar dari masa lalu: Bidang rekayasa lain menganalisis kegagalan secara menyeluruh (misalnya runtuhnya jembatan) dan meninggalkan pelajaran, tetapi industri software menunjukkan pola pengembangan ala "YOLO" yang mengulang kesalahan masa lalu sambil berkata, "kali ini berbeda".