Bab 9: Mengawal Investasi: Berhenti Membakar Uang untuk Proyek Gagal

Track: Eksekutif (E); untuk Direksi, Manajer, dan pengambil keputusan.

Dalam skenario komposit bab ini, sebuah perusahaan utilitas air menganggarkan Rp 5 miliar untuk sistem informasi pelanggan. Setahun kemudian, sistem tidak dipakai; petugas loket tetap memakai spreadsheet. Auditor bertanya, “siapa yang menyetujui ini?” Tidak ada yang bisa menjawab. Masalahnya bukan tuduhan korupsi; masalahnya adalah ketiadaan tata kelola investasi.

Intisari Eksekutif: Tiga Bekal untuk Bertahan

Uang yang terbakar di proyek TI gagal hampir selalu berpangkal pada tiga kelalaian yang sama, dan ketiganya layak Anda jaga lebih dulu:

• Tanpa business case, proyek TI adalah perjudian yang terlalu mahal. Bagi portofolio grup yang mengelola banyak anak perusahaan, anggaran yang cair tanpa dokumen manfaat dan peta risiko yang seragam adalah jalan tol menuju pemborosan yang tidak bisa dipertanggungjawabkan di tingkat holding.
• Gate review bukan birokrasi; ia mekanisme perlindungan investasi. Keputusan menghentikan proyek TI yang melenceng sama berharganya dengan keberhasilan membangun infrastruktur fisik yang baru.
• Pemilik manfaat harus dari sisi bisnis, bukan TI. Ketika proyek TI hanya dimiliki oleh Kepala TI, tidak ada yang bertanggung jawab atas dampak bisnis yang seharusnya dihasilkan.

Navigasi Bab: Apa yang Akan Anda Hadapi?

Insiden: Proyek Rp 5 Miliar yang Menghilang

Cerita pembuka ini adalah komposit pembelajaran. Rapat darurat di ruang Direksi berlangsung tegang. Di layar terpampang angka yang sulit dibela: Rp 5 miliar sudah dianggarkan untuk implementasi Manajemen Hubungan Pelanggan (Customer Relationship Management, CRM). Dua tahun berlalu, sistem belum go-live. Vendor sudah keluar, tim proyek sudah bubar, dan yang tersisa hanya server serta dokumen kontrak yang sulit menjawab pertanyaan manfaat.

“Bagaimana ini bisa terjadi?” tanya Direktur Utama. Pertanyaan itu tidak bisa dijawab hanya dengan menyalahkan vendor atau tim TI. Proyek dimulai dengan antusias tinggi: presentasi vendor menarik, demo meyakinkan, dan janji transformasi terdengar masuk akal. Anggaran cair karena proyek disebut prioritas. Tetapi tidak ada tata kelola investasi yang nyata.

Tidak ada business case yang terukur. Tidak ada gate review yang berani menghentikan proyek ketika manfaat mulai kabur. Tidak ada project board yang mengawasi keputusan penting secara serius. Proyek berjalan mengikuti arus vendor dan konsultan, sementara pemilik manfaat dari sisi bisnis tidak memegang akuntabilitas.

Yang paling mahal bukan hanya uang yang hilang. Yang lebih mahal adalah pelajaran yang tidak ditangkap. Enam bulan kemudian, proposal proyek baru datang dengan pitch yang mirip, dan organisasi hampir mengulang keputusan yang sama.

Insiden komposit ini menunjukkan mengapa tata kelola proyek (project governance) dan tata kelola investasi (investment governance) menjadi komponen kritis dalam tata kelola TI. Tanpa tata kelola yang kuat, investasi TI mudah berubah menjadi perjudian. Uang mengalir, harapan meningkat, tetapi hasil tidak terukur. Bab ini membahas cara melindungi investasi TI melalui portofolio proyek, business case, gate review, project board, dan realisasi manfaat.

9.1 Mengapa Proyek TI Sering Gagal

Sebelum membahas solusi, kita perlu memahami masalahnya terlebih dahulu. Mengapa proyek TI, khususnya di organisasi utilitas, memiliki tingkat kegagalan yang tinggi?

9.1.1 Statistik Kegagalan Proyek TI

Berbagai studi global menunjukkan angka yang konsisten:

The Standish Group (Chaos Report): sekitar 66% proyek TI dinyatakan challenged (terlambat, over-budget, atau dengan scope yang terpotong) atau failed (dibatalkan atau jarang digunakan). PMI (Pulse of the Profession): sekitar 12% investasi proyek kurang menghasilkan nilai karena performa yang buruk. McKinsey: proyek TI besar (di atas $15 juta) rata-rata 45% melebihi anggaran dan 7% terlambat, dengan 56% memberikan nilai kurang dari yang diprediksi.

Di konteks Indonesia, khususnya sektor utilitas, risiko kegagalan bisa meningkat ketika organisasi tidak memiliki forum yang memberi wewenang kepada seseorang untuk mengatakan “ini berbahaya” tanpa takut dianggap menghambat inovasi. Penyebabnya bukan hanya teknis, tetapi juga tata kelola yang lemah.

9.1.2 Akar Masalah Kegagalan Proyek

Berikut adalah akar masalah yang paling sering ditemukan dalam studi kasus kegagalan proyek TI:

1. Strategic Alignment yang Lemah Proyek dimulai tanpa keterkaitan yang jelas dengan strategi bisnis. Seseorang mendengar teknologi baru di seminar, vendor datang dengan presentasi menarik, atau kompetitor mengumumkan adopsi sistem tertentu. Organisasi lalu ikut-ikutan tanpa analisis mendalam tentang apakah proyek itu benar-benar mendukung tujuan strategis. Di Organisasi X, proyek CRM dimulai karena CEO baru saja menghadiri konferensi di mana CRM dipresentasikan sebagai kunci transformasi digital. Tidak ada analisis tentang apakah CRM adalah prioritas dibandingkan kebutuhan TI lainnya, atau apakah organisasi sudah siap untuk perubahan proses bisnis yang diperlukan.

2. Business Case yang Tidak Realistis Proyek disetujui berdasarkan business case yang terlalu optimistis. Benefit dilebih-lebihkan, biaya diringankan, risiko diabaikan. Vendor dan konsultan tentu ingin menjual, jadi mereka cenderung memberikan estimasi yang agresif. Bagian TI yang tidak memiliki data historis yang baik mudah termakan angka-angka ini. Dalam kasus Organisasi X, business case memproyeksikan peningkatan customer satisfaction sebesar 40% dalam satu tahun, reduksi complaint sebesar 60%, dan peningkatan efisiensi operasional sebesar 30%. Tidak ada metodologi yang jelas bagaimana angka-angka ini dicapai, dan tidak ada baseline yang terukur untuk membandingkan.

3. Scope Creep yang Tidak Terkendali Proyek dimulai dengan scope yang terdefinisi, tapi seiring berjalannya waktu, berbagai kebutuhan baru ditambahkan tanpa kontrol. “Ah, sekalian saja kita tambahkan fitur ini,” “Kan sudah berinvestasi besar, mending kita lengkapi,” atau “Ini permintaan dari direksi, harus diakomodasi.” Akibatnya, proyek membengkak dari segi waktu dan biaya, sementara kualitas menurun karena terlalu banyak hal harus dikerjakan dengan sumber daya terbatas. Dalam kasus komposit Organisasi X, scope awal proyek CRM adalah 10 modul. Enam bulan kemudian menjadi 15 modul. Satu tahun kemudian menjadi 23 modul dengan integrasi ke berbagai sistem lain.

4. Vendor Management yang Lemah Ketergantungan yang berlebihan pada vendor dan konsultan adalah masalah serius. Organisasi tidak memiliki kapasitas internal untuk menilai apakah pekerjaan vendor sesuai dengan standar, apakah harga yang dibayar wajar, atau apakah alternatif yang lebih baik tersedia. Di Organisasi X, vendor yang sama yang menjual software juga menjadi implementing partner dengan hourly rate yang sangat tinggi. Tidak ada kapasitas internal yang cukup untuk mengawasi pekerjaan mereka, sehingga hampir semua keputusan teknis diserahkan kepada pihak yang memiliki insentif bisnis langsung.

5. Tidak Ada Accountability yang Jelas Siapa yang bertanggung jawab atas keberhasilan proyek? Project Manager TI? Business Owner? Direktur? Ketika tidak ada accountability yang jelas, semua orang melempar tanggung jawab ketika masalah muncul. “Itu kesalahan vendor,” “Kebutuhan bisnis tidak jelas,” “Anggaran tidak disetujui tepat waktu,” dan berbagai alasan lain muncul.

9.1.3 Dari Manajemen Proyek ke Tata Kelola Proyek

Banyak organisasi berpikir bahwa solusi dari masalah di atas adalah project management yang lebih baik. Mereka mengirim project manager untuk pelatihan PMP, mengimplementasikan alat seperti Microsoft Project atau Jira, atau menyewa consultant untuk membantu manajemen proyek.

Ini adalah langkah yang baik, tetapi tidak cukup. Manajemen proyek adalah tentang execution: bagaimana proyek dijalankan sehari-hari, bagaimana schedule dibuat, bagaimana risk diidentifikasi, dan bagaimana tim dikoordinasikan.

Tata kelola proyek adalah tentang decision-making dan oversight: bagaimana proyek dipilih, bagaimana authority untuk memulai proyek diberikan, bagaimana performa proyek dipantau pada tingkat manajerial, bagaimana keputusan kritikal dibuat ketika proyek menyimpang, bagaimana accountability ditegakkan.

Tabel 9.1 membedakan manajemen proyek dan tata kelola proyek.

Tabel 9.1 Perbedaan manajemen proyek dan tata kelola proyek

Keduanya dibutuhkan. Manajemen proyek yang baik tanpa tata kelola yang baik akan menghasilkan proyek yang efisien tetapi mungkin tidak relevan. Tata kelola proyek yang baik tanpa manajemen proyek yang baik akan menghasilkan keputusan strategis yang tepat tetapi pelaksanaan yang buruk.

9.1.5 Sunk Cost dan Escalation of Commitment: Mengapa Proyek Gagal Terus Didanai

Ini adalah pola yang paling merugikan dalam tata kelola proyek TI di Indonesia; dan jarang dibahas secara eksplisit. Proyek sudah jelas menunjukkan tanda kegagalan: tenggat meleset berulang kali, manfaat bisnis tidak terbukti, vendor sudah kehilangan tim kunci, pengguna menolak memakai sistem. Namun organisasi terus menyetujui anggaran berikutnya. Alasannya berulang: “Kita sudah terlanjur keluar Rp 5 miliar. Kalau dihentikan, rugi.”

Ini adalah sunk cost fallacy; menjadikan biaya historis yang tidak bisa dikembalikan sebagai alasan untuk terus mengeluarkan biaya baru. Dalam tata kelola proyek, ia muncul dalam bentuk escalation of commitment: organisasi meningkatkan komitmen pada proyek yang gagal justru untuk membenarkan komitmen sebelumnya.

Cara mengenali proyek yang sudah masuk escalation of commitment:

Cara menghentikan proyek yang sudah terlanjur mahal; Kill Point Protocol:

1. Tetapkan kill point di awal proyek, bukan di tengah. Setiap proyek di atas threshold tertentu harus memiliki kill criteria sejak Gate 1: kondisi spesifik dan terukur yang, jika tercapai, memicu penghentian proyek. Contoh: “Jika setelah 12 bulan, kurang dari 60% pengguna target aktif memakai sistem, proyek dihentikan.” Kill criteria ditulis di business case, ditandatangani sponsor, dan tidak bisa diubah kecuali melalui gate review formal.

2. Pisahkan keputusan melanjutkan dari orang yang memulai proyek. Sponsor yang mengusulkan proyek memiliki konflik kepentingan: menghentikan proyek berarti mengakui kesalahan. Gate review harus dihadiri oleh pengambil keputusan yang tidak terlibat langsung; idealnya dari fungsi keuangan atau audit.

3. Gunakan independent review untuk proyek yang menunjukkan 3+ tanda bahaya. Jika proyek menunjukkan tiga atau lebih tanda di tabel di atas, minta peninjauan oleh pihak yang tidak terlibat: auditor internal, konsultan independen, atau tim dari unit bisnis lain. Beri mereka wewenang untuk merekomendasikan penghentian.

4. Hitung cost to complete vs value remaining, bukan sunk cost vs total spend. Pertanyaan yang salah: “Apakah kita rugi kalau hentikan proyek yang sudah keluar Rp 5 miliar?” Pertanyaan yang benar: “Apakah Rp 3 miliar tambahan yang diminta akan menghasilkan manfaat minimal Rp 3 miliar?” Jika jawabannya tidak, menghentikan sekarang lebih murah daripada meneruskan.

5. Siapkan template memo penghentian. Salah satu alasan proyek gagal terus berjalan adalah karena tidak ada yang tahu bagaimana menghentikannya secara administratif. Template memo penghentian proyek harus tersedia sebelum proyek dimulai; berisi: alasan penghentian, biaya yang sudah dikeluarkan, aset yang bisa diselamatkan, kewajiban kontrak yang harus diselesaikan, dan rencana transisi. Template ini membuat keputusan menghentikan proyek tidak lebih sulit secara administratif daripada keputusan melanjutkan.

9.2 Kerangka Tata Kelola Proyek untuk TI

Bagian ini mempresentasikan kerangka praktis untuk tata kelola proyek yang dapat diimplementasikan di organisasi utilitas. Kerangka ini terdiri dari empat komponen utama: project portfolio management, gate reviews, business case, dan project board.

9.2.1 Project Portfolio Management (PPM)

Project portfolio management adalah proses sistematis untuk mengidentifikasi, mengprioritaskan, mengotorisasi, mengelola, dan mengontrol proyek-proyek dalam portofolio. Tujuannya adalah memastikan bahwa organisasi melakukan proyek yang “benar” (right projects), bukan hanya melakukan proyek dengan cara yang “benar” (projects right).

Prinsip Utama PPM

1. Strategic Alignment. Setiap proyek harus memiliki keterkaitan yang jelas dengan strategi organisasi. Proyek yang tidak mendukung strategi seharusnya tidak dimulai, atau jika sudah berjalan, harus dipertimbangkan untuk dihentikan. Di Organisasi X, strategi utama adalah meningkatkan reliabilitas layanan dan efisiensi operasional. Proyek CRM mungkin mendukung tujuan customer satisfaction, tetapi jika core masalah organisasi adalah reliabilitas infrastruktur produksi, maka prioritas mungkin seharusnya berbeda.

2. Balance. Portofolio proyek harus seimbang antara: (a) proyek yang bertujuan memperbaiki operasional existing vs proyek inovatif, (b) proyek dengan risiko rendah/hasil rendah vs proyek dengan risiko tinggi/hasil tinggi, (c) proyek mandatory (regulatory, compliance) vs proyek discretionary, (d) proyek jangka pendek vs jangka panjang.

3. Maximizing Value. Dengan sumber daya yang terbatas, organisasi harus memilih kombinasi proyek yang memberikan nilai maksimum. Ini bukan berarti hanya memilih proyek dengan ROI tertinggi, tetapi mempertimbangkan faktor lain seperti risiko, ketergantungan antar-proyek, dan ketersediaan sumber daya.

Proses PPM Praktis

Berikut adalah proses PPM yang dapat diimplementasikan:

1. Identifikasi Kandidat Proyek. Setiap unit dapat mengusulkan proyek. Usulan harus berisi: (a) deskripsi singkat, (b) business case awal, (c) perkiraan biaya dan jadwal, (d) expected benefits, (e) risiko utama.

2. Klasifikasi. Proyek diklasifikasikan berdasarkan: (a) ukuran (besar, sedang, kecil), (b) kompleksitas (tinggi, sedang, rendah), (c) tingkat risiko (tinggi, sedang, rendah), (d) kategori (mandatory, strategic, operational). Klasifikasi ini menentukan tingkat pengawasan yang dibutuhkan. Proyek besar dan kompleks memerlukan tata kelola yang lebih ketat.

3. Scoring dan Prioritasi. Setiap proyek diberikan skor berdasarkan kriteria: (a) strategic alignment (sejauh mana proyek mendukung strategi), (b) financial benefit (NPV, IRR, payback period), (c) risk (tingkat risiko proyek), (d) urgency (apakah ada deadline eksternal), (e) dependency (apakah proyek ini prerequisite untuk proyek lain). Scoring dapat dilakukan dengan sistem poin (1-5) untuk setiap kriteria, lalu di-weight sesuai prioritas strategis organisasi.

4. Seleksi dan Portfolio Balancing. Berdasarkan skor dan klasifikasi, dipilih kombinasi proyek yang akan dikerjakan. Pertimbangan utama adalah keterbatasan sumber daya (budget, people, infrastructure). Portofolio harus seimbang sesuai prinsip yang telah dibahas.

5. Monitoring dan Re-prioritization. Portofolio ditinjau secara periodik (misalnya kuartalan). Proyek yang tidak berperforma baik dapat dipertimbangkan untuk dihentikan. Proyek baru dapat dimasukkan jika prioritas strategis berubah.

9.2.2 Gate Reviews

Gate Reviews adalah titik keputusan formal dalam siklus hidup proyek di mana manajemen mengevaluasi apakah proyek harus dilanjutkan, dimodifikasi, atau dihentikan. Ini adalah mekanisme tata kelola paling praktis untuk mencegah “proyek zombie” yang terus berjalan tanpa tujuan yang jelas.

Tipe Gate Reviews

Ada beberapa pendekatan terhadap Gate Reviews. Pendekatan yang paling umum adalah berdasarkan fase dalam siklus hidup proyek:

Gambar 9.1 Gate Reviews dalam Siklus Hidup Proyek

Gate 0: Select Gate (Perisai Manajer TI)

Gate ini memutuskan apakah ide proyek layak untuk dianalisis lebih lanjut. Bagi Kepala Bagian TI, Gate 0 adalah senjata politik terbaik untuk berkata “TIDAK” kepada Direksi tanpa terkesan membangkang. Ketika Direktur pulang dari seminar “Smart Water City” dan tiba-tiba menuntut pembuatan aplikasi pelanggan berbasis Artificial Intelligence tanpa tambahan anggaran atau kesiapan infrastruktur, Anda tidak perlu berdebat panjang lebar. Cukup keluarkan formulir Gate 0 dan tanyakan secara tertulis: (1) Dari mana alokasi budget infrastrukturnya? (2) Data pelanggan mana yang sudah tervalidasi untuk diolah AI? (3) Siapa SDM non-teknis yang akan menindaklanjuti output AI tersebut?

Jika prasyarat dasar ini tidak terpenuhi, proyek itu gugur secara administratif, bukan karena Manajer TI “tidak inovatif”, melainkan karena framework tata kelola mendikte bahwa proyek tersebut belum layak pelaksanaan.

Keputusan: (a) Go - lanjut ke fase initiation, (b) Hold - ide disimpan tapi tidak dikerjakan saat ini, (c) Reject - ide ditolak.

Gate 1: Authorize Gate

Setelah business case dan rencana awal disusun, gate ini memutuskan apakah proyek resmi diotorisasi. Pertanyaan kunci: Apakah business case valid? Apakah risiko dapat diterima? Apakah sumber daya tersedia?

Keputusan: (a) Go - proyek diotorisasi, (b) Rework - business case atau rencana harus diperbaiki, (c) Hold - proyek ditunda, (d) Reject - proyek dibatalkan.

Gate 2: Commit Gate

Setelah perencanaan detail selesai, gate ini memutuskan apakah organisasi siap untuk berkomitmen penuh ke proyek. Ini adalah titik “tidak ada jalan balik” di mana investasi besar akan dilakukan. Pertanyaan kunci: Apakah rencana detail lengkap dan realistis? Apakah vendor sudah dipilih dengan baik? Apakah stakeholder sudah berkomitmen?

Keputusan: (a) Go - pelaksanaan dimulai, (b) Rework - perencanaan harus diperbaiki, (c) Hold - pelaksanaan ditunda, (d) Reject - proyek dibatalkan.

Gate 3: Tinjauan (Review Gate)

Selama pelaksanaan, gate ini memutuskan apakah proyek tetap pada jalur yang benar. Biasanya dilakukan pada milestone penting. Pertanyaan kunci: Apakah progres sesuai rencana? Apakah benefit yang diharapkan masih relevan? Apakah risiko masih dapat dikelola?

Keputusan: (a) Continue - proyek dilanjutkan, (b) Rework - area tertentu harus diperbaiki, (c) Redefine - scope proyek disesuaikan, (d) Terminate - proyek dihentikan.

Gate 4: Closure Gate

Setelah proyek selesai, gate ini mengevaluasi apakah proyek berhasil mencapai tujuannya dan apakah benefit terealisasi. Pertanyaan kunci: Apakah deliverables diterima dengan baik? Apakah benefit terealisasi sesuai business case? Apakah ada lesson learned yang ditangkap?

Keputusan: (a) Accept - proyek dinyatakan berhasil ditutup, (b) Conditional Accept - proyek ditutup dengan follow-up action, (c) Reject - proyek tidak diterima, (d) Re-open - proyek dibuka kembali.

Prinsip Gate Reviews yang Efektif

Agar Gate Reviews efektif, beberapa prinsip harus diikuti:

1. Bukan Sekadar Ritual. Gate Reviews bukan sekadar ritual. Keputusan yang dihasilkan harus nyata, bukan sekadar formalitas. Gatekeeping yang baik berarti ada proyek yang benar-benar dihentikan jika tidak layak.
2. Kriteria Keputusan Jelas. Kriteria keputusan harus didefinisikan sebelumnya. Tidak ada keputusan ad-hoc yang berdasarkan preferensi personal. Kriteria harus transparan dan diterapkan secara konsisten.
3. Pihak yang Tepat. Gate Reviews harus melibatkan pihak yang tepat. Ini bukan pertemuan teknis tim proyek, tetapi forum pengambilan keputusan manajerial. Partisipan harus memiliki otoritas untuk membuat keputusan.
4. Dokumentasi Lengkap. Dokumentasi harus lengkap. Keputusan, rasional, dan butir tindak lanjut harus ditulis dengan jelas untuk akuntabilitas dan referensi masa depan. Banyak proyek tidak gagal karena kurangnya alat, tetapi karena tidak jelas siapa yang berhak memutuskan.

Skalabilitas Gate Review untuk PDAM Skala Kecil Bagi PDAM di kabupaten (Tier-3) dengan anggaran TI dan jumlah staf yang terbatas, Gate Review tidak boleh diterjemahkan sebagai birokrasi baru yang menghambat operasional. Tidak perlu membentuk komite besar yang bersidang formal berhari-hari. Gate Review di organisasi kecil cukup berarti satu hal: sebelum Direktur menandatangani memo pengadaan sistem baru, ada tiga pertanyaan yang wajib dijawab di lembar disposisi: (1) Masalah bisnis apa yang diselesaikan? (2) Apakah kita punya staf untuk merawatnya? (3) Siapa yang bertanggung jawab jika ini gagal? Jika ketiga pertanyaan ini tertulis dan disetujui, Gate Review sudah terlaksana secara agile.

Realitas Lapangan: “Proyek Titipan” dan Jebakan Serapan Anggaran Banyak proyek TI di perusahaan utilitas air tiba-tiba muncul di kuartal keempat sekadar untuk “menyerap sisa anggaran” agar persentase realisasi finansial akhir tahun terlihat bagus. Proses pengadaan dipaksa, analisis kebutuhan dilewati, dan spesifikasi murni pesanan “titipan”. Jika Direksi menerapkan Gate Review dengan ketat, proyek-proyek akhir tahun ini kemungkinan besar akan gagal lolos Gate 1 dan lelangnya batal.

Ini adalah trade-off nyata: Tata kelola TI yang disiplin mungkin akan menurunkan persentase serapan anggaran jangka pendek Anda. Namun, ingatlah peringatan ini: Serapan anggaran yang rendah hanya akan membuahkan teguran administratif dari kepala daerah atau pemilik modal, tetapi mengeksekusi proyek TI miliaran rupiah secara asal-asalan bisa menyeret Anda ke ranah pidana saat BPK melakukan audit investigatif. Tata kelola adalah rem yang menyelamatkan karier Anda.

9.2.3 Business Case yang Kuat

Business case adalah dokumen yang memjustifikasi investasi pada proyek. Ini adalah fondasi dari tata kelola proyek karena tanpa business case yang kuat, keputusan untuk memulai atau melanjutkan proyek menjadi tidak berdasarkan.

Dalam pengalaman saya, business case yang buruk hampir hampir selalu punya pola yang sama: biaya dijelaskan rinci, manfaat dijelaskan kabur. Padahal Direksi tidak hanya menyetujui pengeluaran. Direksi menyetujui janji manfaat yang kelak harus dibuktikan.

Komponen Business Case

Business Case yang efektif harus mencakup komponen berikut:

1. Konteks dan Strategic Alignment. Menjelaskan konteks proyek dan bagaimana proyek ini mendukung strategi organisasi. Ini membantu memastikan bahwa semua pemangku kepentingan memahami mengapa proyek ini penting. Contoh: “Proyek ini mendukung tujuan strategis Organisasi X untuk meningkatkan skor kepuasan pelanggan dari 65 menjadi 80 dalam tiga tahun, dengan fokus pada pengurangan waktu respons keluhan.”

2. Pernyataan Masalah (Problem Statement) atau Peluang. Menjelaskan masalah yang ingin dipecahkan atau peluang yang ingin dimanfaatkan. Ini harus spesifik dan terukur, bukan pernyataan umum. Contoh: “Saat ini, rata-rata waktu respons keluhan adalah 48 jam, dengan 30% keluhan tidak diselesaikan dalam SLA. Hal ini menurunkan kepuasan pelanggan dan berpotensi mengurangi pendapatan.”

3. Solusi yang Diusulkan (Proposed Solution) dan Alternatif. Menjelaskan solusi yang diusulkan, termasuk alternatif yang dipertimbangkan. Analisis harus mencakup opsi “do nothing” sebagai baseline. Contoh: “Tiga alternatif dianalisis: memperbaiki sistem yang ada, mengimplementasikan paket CRM baru, atau menggunakan managed service provider. Alternatif kedua dipilih berdasarkan keseimbangan biaya, fungsionalitas, dan risiko.”

4. Manfaat Terukur dan Tidak Terukur. Menjelaskan manfaat yang diharapkan, baik yang dapat diukur secara finansial maupun yang tidak.

   • Manfaat terukur: peningkatan pendapatan, penghematan biaya, dan peningkatan produktivitas.
   • Manfaat tidak terukur: peningkatan kepuasan pelanggan, peningkatan employee engagement, dan penguatan reputasi merek. Penting untuk membuat benefits se-SMART mungkin: Specific, Measurable, Achievable, Relevant, Time-bound.

5. Costs. Menjelaskan total biaya yang dibutuhkan, termasuk: biaya software license, biaya implementasi, biaya hardware, biaya training, biaya operasional tahunan, dan biaya tersembunyi lainnya. Biaya harus realistis, termasuk contingency untuk risiko yang teridentifikasi.

6. Financial Analysis. Analisis finansial yang biasa digunakan: Nilai Sekarang Bersih (Net Present Value, NPV), Internal Rate of Return (IRR), Payback Period, Return on Investment (ROI). Penting untuk menjelaskan asumsi yang digunakan dalam perhitungan.

7. Risk Assessment. Identifikasi risiko utama dan bagaimana risiko tersebut akan dikelola. Risiko harus dinilai berdasarkan likelihood dan impact.

8. Implementation Roadmap. Rencana implementasi tingkat tinggi, termasuk fase-fase utama, milestone, dan jadwal.

9.2.3.1 Contoh Nyata dalam Angka: Business Case Upgrade Sistem Billing

Bagian ini adalah contoh peragaan (worked example), bukan template kosong. Gunakan sebagai pola untuk menyusun argumen investasi TI di organisasi Anda.

Konteks: Perusahaan Utilitas Air Kota Menengah (200.000 SR, pendapatan tahunan Rp 300 miliar) mempertimbangkan upgrade sistem billing lama yang sudah berusia 12 tahun. Sistem saat ini tidak mendukung pembayaran digital, pencatatan meter otomatis, atau integrasi real-time dengan bank. Akibatnya: 14% keluhan pelanggan per bulan terkait akurasi tagihan, waktu rata-rata posting pembayaran 6 hari, dan 18% pembayaran offline mengalami selisih rekonsiliasi setiap bulan.

Alternatif yang Dipertimbangkan:

Opsi yang dipilih: Upgrade. Full replacement tidak dipilih karena risiko bisnis terlalu besar dan keuangan/SDM sudah berjalan cukup baik.

Ringkasan Finansial:

Hasil Analisis Finansial (asumsi biaya modal 12%):

Analisis Sensitivitas:

Pelajaran untuk Direksi: Perhatikan tiga hal dari contoh ini. Pertama, tabel arus kas adalah bahasa yang dipahami CFO, bukan slide konseptual, melainkan angka tahun per tahun. Kedua, analisis sensitivitas menjawab pertanyaan “bagaimana kalau meleset?” sebelum ditanyakan Dewan Pengawas. Ketiga, business case bukan dokumen yang ditulis sekali dan dilupakan; ia instrumen yang dipakai di setiap gate review untuk menguji apakah manfaat masih dalam jalur. Manfaat Rp 1,2 miliar di Tahun 1 harus mulai terlihat di laporan triwulan, bukan di akhir tahun.

Untuk PDAM Skala Metropolitan (500.000+ SR)

Contoh di atas berskala kota menengah (200.000 SR, Rp 300 M/tahun). Untuk PDAM metropolitan seperti Jakarta, Surabaya, atau Bandung dengan 500.000–1.000.000+ SR, ada tiga faktor tambahan yang menentukan kelayakan:

1. Cost of delay: Proyek billing senilai Rp 40–80 miliar bisa kehilangan Rp 2–5 miliar pendapatan per hari jika posting pembayaran tertunda. Biaya keterlambatan ini wajib dimasukkan sebagai baris tersendiri di tabel manfaat (bukan catatan kaki).
2. Risiko nilai tukar: Lisensi, hardware SCADA, dan jasa konsultan asing sering dalam USD. Tambahkan sensitivitas terhadap depresiasi rupiah 10%, 20%, dan 30% di analisis sensitivitas.
3. Struktur pembiayaan alternatif: Proyek di atas Rp 20 miliar jarang bisa dibiayai murni dari laba ditahan. Siapkan perbandingan dengan skema KPBU, obligasi daerah, pinjaman lembaga multilateral, atau vendor financing. Tiap skema punya implikasi tata kelola yang berbeda, terutama pada persetujuan multi-pihak dan pelaporan ke DPRD.

9.2.4 Project Board dan Steering

Dewan Proyek (Project Board, kadang disebut Steering Committee) adalah forum pengambilan keputusan untuk proyek. Ini adalah mekanisme tata kelola yang paling langsung.

Komposisi Project Board

Project Board yang efektif harus memiliki komposisi yang tepat:

Executive Sponsor

Anggota senior manajemen yang menjadi champion proyek. Tugasnya: (a) memberikan sponsorship di tingkat eksekutif, (b) memutuskan isu yang tidak dapat diselesaikan di tingkat proyek, (c) mengamankan sumber daya yang dibutuhkan, (d) mengkomunikasikan progres proyek ke direksi.

Business Owner

Perwakilan dari fungsi bisnis yang akan menjadi user utama hasil proyek. Tugasnya: (a) memastikan solusi memenuhi kebutuhan bisnis, (b) mengambil keputusan tentang prioritas requirement, (c) memfasilitasi user acceptance.

IT Representative

Perwakilan dari fungsi TI. Tugasnya: (a) memastikan solusi selaras dengan enterprise architecture, (b) mengevaluasi implikasi teknis, (c) mengkoordinasikan sumber daya TI.

Finance Representative (untuk proyek besar)

Perwakilan dari fungsi keuangan. Tugasnya: (a) mengevaluasi aspek finansial, (b) memantau budget utilization, (c) menilai business case.

Risk Management Representative (opsional)

Perwakilan dari fungsi manajemen risiko. Tugasnya: (a) mengevaluasi risiko proyek, (b) merekomendasikan mitigasi.

Pertemuan Project Board yang Efektif

Project Board sebaiknya bertemu secara teratur (misalnya bulanan) dengan agenda yang jelas:

1. Tinjau progres sejak pertemuan terakhir
2. Diskusi isu dan risiko yang memerlukan keputusan
3. Tinjau butir tindak lanjut sebelumnya
4. Keputusan dan butir tindak lanjut baru

Pertemuan harus singkat dan fokus (maksimal 60-90 menit). Materi harus didistribusikan sebelumnya agar peserta dapat mempersiapkan diri.

9.2.5 Studi Kasus: Implementasi Smart Metering di Unit A

Untuk mengilustrasikan penerapan tata kelola proyek, berikut adalah studi kasus dari Unit A, salah satu unit operasional Organisasi X.

Konteks

Unit A ingin mengimplementasikan smart metering untuk meningkatkan akurasi pembacaan meter dan mengurangi kebocoran revenue. Estimasi investasi adalah Rp 8 miliar untuk 10.000 smart meter dan infrastruktur pendukung.

Penerapan PPM

Proyek ini berasal dari portfolio tahunan Unit A. Dalam proses PPM, proyek ini mendapat skor tinggi karena: (a) sejalan dengan strategi peningkatan efisiensi operasional, (b) memiliki financial benefit yang jelas (estimasi pengurangan kebocoran 20%), (c) risiko teknis relatif rendah karena teknologi smart meter sudah mature.

Proyek ini dipilih sebagai salah satu dari lima proyek prioritas tahun tersebut, setelah bersaing dengan 15 usulan proyek lain.

Business Case

Business case proyek dirinci sebagai berikut:

Investasi: Rp 8 miliar (CAPEX) + Rp 500 juta/tahun (OPEX)

Benefits: (a) Pengurangan kebocoran revenue: Rp 1,2 miliar/tahun, (b) Pengurangan biaya pembacaan manual: Rp 300 juta/tahun, (c) Peningkatan customer satisfaction: tidak ternilai secara finansial

Financial Analysis: Payback period ~6 tahun, ROI positif setelah tahun ke-7

Risiko: Risiko utama adalah kegagalan teknis smart meter dan resistensi dari pelanggan

Gate Reviews

Gate 0: Disetujui untuk masuk fase initiation

Gate 1: Disetujui untuk perencanaan detail, dengan catatan harus melakukan pilot terlebih dahulu

Gate 2: Disetujui untuk implementasi penuh, dengan dimodifikasi scope menjadi phased rollout (bukan big bang)

Gate 3: Dilakukan dua kali, setelah pilot dan setelah fase pertama rollout. Kedua gate menghasilkan keputusan continue dengan beberapa rekomendasi perbaikan

Project Board

Project Board dibentuk dengan komposisi: (a) Executive Sponsor: Kepala Unit A, (b) Business Owner: Kepala Operasi, (c) IT Representative: Manager TI Unit A, (d) Finance Representative: Kepala Keuangan Unit A.

Pertemuan dilakukan setiap bulan, dengan hasil: keputusan-keputusan kritikal tentang perubahan scope setelah pilot, persetujuan tambahan anggaran untuk kontinjensi, dan keputusan tentang rollout strategy.

Hasil

Proyek selesai dalam 18 bulan, 3 bulan lebih lambat dari rencana awal tetapi masih dalam anggaran (berkat penggunaan contingency yang hati-hati). Benefits mulai terealisasi setelah 12 bulan, dengan pengurangan kebocoran revenue terukur sebesar 18% (mendekati target 20%).

Pelajaran utama: tata kelola proyek membantu proyek tetap pada jalur yang benar meskipun ada tantangan yang tidak terduga.

9.2.6 Pengadaan TI di BUMD: Dari e-Katalog Sampai Penunjukan Langsung

Bagi perusahaan utilitas air berstatus BUMD/PDAM, proyek TI tidak cukup diuji oleh business case dan gate review. Proyek tersebut juga harus melewati aturan pengadaan barang dan jasa (PBJ) yang berlaku. Mengabaikan dimensi ini dapat mengakibatkan proyek yang secara teknis dan finansial sehat menjadi batal karena cacat prosedur pengadaan, atau lebih buruk, menjadi temuan hukum.

Kerangka Regulasi Pengadaan:

PBJ untuk BUMD mengacu pada Perpres No. 16 Tahun 2018 (sebagaimana diubah dengan Perpres No. 12 Tahun 2021) tentang Pengadaan Barang/Jasa Pemerintah. Beberapa BUMD juga menerbitkan aturan internal (Perdir) yang mengadopsi prinsip Perpres ini dengan penyesuaian.

Pasal-pasal kunci: Pasal 38-41 (e-Purchasing melalui e-Katalog), Pasal 42-46 (tender/seleksi), Pasal 47-49 (penunjukan langsung, dengan syarat ketat), Pasal 73 (kontrak payung untuk pengadaan berulang), Pasal 76 (e-kontrak).

Tiga Jalur Pengadaan TI:

1. e-Katalog (e-Purchasing): Jalur tercepat dan paling aman secara kepatuhan untuk pengadaan TI umum: lisensi perangkat lunak standar, perangkat keras, layanan cloud, atau jasa konsultasi yang sudah tercantum di katalog elektronik. Pengadaan melalui e-Katalog tidak memerlukan tender selama spesifikasi sesuai. Risiko untuk organisasi TI: e-Katalog menawarkan kecepatan, tetapi spesifikasi produk di katalog belum tentu cocok untuk kebutuhan integrasi SCADA, billing, atau sistem operasional yang heterogen. Periksa interoperability sebelum memilih.

2. Tender Terbatas: Digunakan untuk proyek TI kompleks yang memerlukan pembandingan beberapa vendor: implementasi ERP, pengembangan aplikasi kustom, atau penggantian sistem core. Tender dapat dilakukan secara elektronik melalui LPSE (Layanan Pengadaan Secara Elektronik). Perhatikan: TOR (Terms of Reference) harus ditulis oleh tim yang memahami kebutuhan bisnis dan spesifikasi teknis; jangan delegasikan ke vendor yang sama yang nantinya ikut tender.

3. Penunjukan Langsung: Hanya untuk kondisi khusus: (a) vendor tunggal (tidak ada alternatif), (b) keadaan darurat, atau (c) kelanjutan dari kontrak sebelumnya yang tidak bisa diputus tanpa kerugian besar. Peringatan: Penunjukan langsung adalah jalur paling berisiko secara audit. Gunakan hanya jika ketiga syarat di atas terpenuhi, dan dokumentasikan justifikasi secara tertulis.

Prinsip yang Berlaku untuk Semua Jalur:

1. TKDN (Tingkat Komponen Dalam Negeri): Banyak pengadaan TI BUMD mewajibkan preferensi produk dengan TKDN minimum (umumnya 25-40% tergantung jenis produk). Ini mempengaruhi pilihan vendor dan solusi, sekaligus membatasi opsi untuk produk niche atau vendor tunggal global.

2. HPS (Harga Perkiraan Sendiri): Sebelum pengadaan dimulai, tim TI bersama bagian pengadaan harus menetapkan HPS berdasarkan survei pasar (market sounding). HPS yang tidak realistis (terlalu rendah) akan menghasilkan pemenang tender dengan kualitas rendah.

3. Spesifikasi Teknis vs Merek: TOR tidak boleh menyebut merek spesifik kecuali untuk produk dengan alasan teknis yang bisa dipertanggungjawabkan. Sebutkan spesifikasi fungsional dan teknis, bukan “Microsoft SQL Server” tetapi “relational database management system dengan dukungan transaksi ACID dan high availability.”

4. Kontrak Berbasis Kinerja: Untuk proyek TI besar, gunakan kontrak berbasis kinerja (performance-based contract) dengan pembayaran bertahap berdasarkan milestone, bukan lump sum di awal. Ini melindungi organisasi dari vendor yang menyerahkan hasil di bawah standar setelah menerima pembayaran penuh.

Kolaborasi Tim TI dan Bagian Pengadaan:

Kesalahan paling fatal adalah menyerahkan seluruh proses PBJ ke Bagian Pengadaan tanpa pelibatan teknis, atau sebaliknya, tim TI menyusun spesifikasi tanpa memahami aturan PBJ. Dua tim ini harus bekerja bersama dari awal:

• Tim TI menyusun spesifikasi teknis, business case, dan justifikasi.
• Bagian Pengadaan memastikan jalur PBJ sesuai aturan, menyusun dokumen lelang, dan mengelola proses administrasi.

9.2.7 Kemitraan Vendor yang Sehat: Bukan Anti-Vendor, Melainkan Anti-Ketergantungan

Subtitle buku ini berbunyi “Manajemen Anda Tidak Akan Diselamatkan Vendor.” Itu bukan serangan terhadap vendor. Ia pengingat bahwa tanggung jawab akhir tata kelola ada di tangan manajemen, bukan di tangan pemasok. Namun, organisasi utilitas air tidak bisa; dan tidak perlu; membangun semuanya sendiri. SCADA, billing, GIS, ERP: semuanya membutuhkan vendor.

Pertanyaannya bukan apakah menggunakan vendor, melainkan bagaimana membangun kemitraan yang setara; di mana kedua pihak memiliki insentif yang selaras dan akuntabilitas yang jelas.

Ciri kemitraan vendor yang sehat:

1. Vendor diundang ke rapat perencanaan, bukan hanya rapat negosiasi. Vendor yang memahami strategi bisnis Anda bisa memberi saran yang lebih relevan. Vendor yang hanya bertemu Anda saat negosiasi harga akan mengoptimalkan untuk harga; bukan untuk nilai.

2. Kontrak menyebutkan “apa yang terjadi jika berhasil” dan “apa yang terjadi jika gagal.” Banyak kontrak hanya mengatur sisi gagal: denda, terminasi, sengketa. Kemitraan sehat juga mengatur sisi berhasil: insentif untuk pencapaian di atas target, perpanjangan otomatis jika SLA terlampaui, opsi ekspansi dengan harga yang sudah disepakati.

3. Tim internal dan tim vendor duduk dalam satu project board. Bukan dua board terpisah. Bukan “vendor melapor ke PM, PM melapor ke sponsor.” Satu meja. Satu daftar isu. Satu keputusan. Ini mencegah permainan “telepon rusak” yang adalah sumber utama miskomunikasi proyek.

4. Pengetahuan ditransfer secara terstruktur, bukan sebagai catatan kaki. Setiap fase proyek memiliki knowledge transfer milestone: sebelum fase berikutnya dimulai, tim internal harus bisa mendemonstrasikan bahwa mereka bisa menjalankan sistem tanpa kehadiran vendor. Jika tidak, fase berikutnya ditunda.

5. Vendor memiliki satu counterpart internal, bukan dua puluh. Jika vendor harus berurusan dengan 5 kepala bidang yang memberikan instruksi berbeda, proyek akan kacau; dan vendor akan disalahkan. Tunjuk satu vendor relationship manager internal yang menjadi satu pintu komunikasi.

Kriteria memilih vendor yang layak dipercaya:

Satu prinsip: Vendor terbaik bukan yang paling murah. Bukan yang paling canggih. Melainkan yang paling bersedia membuat Anda tidak bergantung padanya. Itu paradoks; dan itulah ukuran kemitraan sejati.

• Keputusan pemilihan vendor dibuat bersama, bukan oleh satu pihak.

Untuk Operator Swasta:

Operator swasta mitra pemerintah tidak terikat Perpres PBJ BUMD, tetapi kontrak kerja sama dengan pemerintah seringkali mewajibkan prinsip transparansi pengadaan yang setara. Periksa klausul pengadaan di kontrak kerja sama atau KPBU; jangan berasumsi bahwa Anda bebas memilih vendor tanpa prosedur.

9.2.8 Ketika Vendor Bukan Sekadar Vendor

Aturan pengadaan di §9.2.6 mengasumsikan satu hal yang tidak selalu benar: bahwa pihak yang memilih vendor menilai secara jernih. Hubungan personal antara vendor teknologi dan pengambil keputusan internal jarang dimulai dengan niat buruk. Ia tumbuh dari hal yang wajar: pernah satu almamater, dulu rekan kerja, kerabat, atau sekadar mitra lama yang sudah saling percaya bertahun-tahun. Justru karena awalnya tampak tidak berbahaya, pola risiko ini sulit terlihat sampai ia mengakar. Tata kelola yang baik tidak berangkat dari prasangka buruk terhadap siapa pun; ia berangkat dari pengakuan bahwa loyalitas pribadi, bila dibiarkan tanpa pagar, perlahan dapat menggeser penilaian profesional tanpa pemiliknya sendiri menyadarinya.

Distorsinya tidak selalu muncul utuh atau berurutan; ia bisa menyusup di satu titik saja, atau di beberapa titik dengan kombinasi yang berbeda di tiap organisasi. Ada kalanya yang bermasalah hanya tahap pemilihan, ketika spesifikasi tersusun seakan disalin dari profil satu vendor. Di tempat lain, pemilihannya wajar tetapi kontraknya yang longgar, dibuat berbasis kepercayaan tanpa denda dan tanpa klausul keluar. Kadang masalahnya pada penerimaan hasil, ketika orang yang memegang relasi juga yang menandatangani bahwa pekerjaan telah selesai. Tabel 9.2 memetakan bentuk khas di tiap tahap beserta kontrol yang menahannya, bukan sebagai urutan yang pasti terjadi, melainkan sebagai daftar titik rawan.

Tabel 9.2 Bentuk distorsi konflik kepentingan vendor di tiap tahap siklus dan kontrol yang menahannya

Mendeteksinya sejak awal lebih mudah daripada membongkarnya setelah mengakar. Tiga sinyal paling sering muncul: konsentrasi, ketika satu vendor memegang banyak kontrak berturut-turut tanpa kompetisi ulang; tumpang tindih peran, ketika satu individu selalu menjadi titik kontak vendor sekaligus pihak yang menyetujui dan menerima hasilnya; dan penolakan halus terhadap pengawasan, ketika usulan rotasi, pendapat kedua, atau audit atas vendor itu selalu menemui alasan untuk ditunda. Ketiganya bukan bukti pelanggaran, melainkan kondisi yang menuntut pemeriksaan lebih dekat.

Pencegahannya bertumpu pada dua pilar. Pilar pertama adalah pernyataan konflik kepentingan yang menjadi syarat, bukan formalitas; bila dilihat jernih, pernyataan ini justru melindungi orang yang berelasi itu sendiri, sebab ia memisahkan persahabatan yang wajar dari kecurigaan yang merusak. Bagi BUMD/PDAM, pakta integritas lazim dipakai dalam pengadaan; untuk pengadaan berdana pemerintah berlaku Perpres 16/2018 beserta perubahannya, sementara pengadaan dari pendapatan sendiri mengikuti peraturan pengadaan internal di bawah kerangka PP 54/2017, dan direksi serta pegawai BUMD dapat tunduk pada ketentuan gratifikasi. Bagi operator swasta utilitas air, pengikatnya bukan aturan pengadaan pemerintah melainkan kebijakan internal dan kode etik, dengan standar seperti ISO 37001 tentang sistem manajemen anti penyuapan (anti-bribery management system) menutup ujung penyuapannya. Pilar kedua adalah pemisahan tugas (segregation of duties) yang dibahas di Bab 6: orang yang memilih sebaiknya bukan yang menerima hasil, dan bukan pula yang menyetujui pembayaran, sehingga tidak ada satu individu yang memiliki sebuah vendor dari hulu ke hilir.

Pada akhirnya kedua sisi meja diuntungkan oleh pagar yang sama. Bagi Direksi, relasi yang tidak dideklarasikan di dekat kontrak sistem inti adalah temuan yang menunggu auditor atau berita yang menunggu terjadi; deklarasi dan pemisahan tugas menjaga agar nama Anda tidak melekat pada kontrak yang kelak dipertanyakan. Bagi Manajer TI, pagar yang sama membebaskannya dari posisi sebagai satu-satunya orang yang harus mempertanyakan vendor yang sudah lama dipercaya organisasi, sebab beban kecurigaan itu kini ditanggung oleh prosedur, bukan oleh keberaniannya seorang diri.

9.3 Penutup Bab

Tata kelola proyek dan investasi bukan birokrasi tambahan. Ia adalah mekanisme perlindungan anggaran, waktu, reputasi, dan kepercayaan organisasi. Proyek TI yang mahal tidak otomatis strategis; proyek yang populer tidak otomatis bermanfaat; proyek yang sudah berjalan lama tidak otomatis layak dilanjutkan.

Untuk perusahaan utilitas air, setiap proyek TI besar harus menjawab empat pertanyaan: manfaat bisnisnya apa, siapa pemilik manfaatnya, kapan keputusan dilanjutkan atau dihentikan dibuat, dan bukti apa yang menunjukkan manfaat itu benar-benar terjadi. Jika empat jawaban itu tidak ada, proyek belum siap menyerap anggaran besar.

Pola ini berlaku lintas industri. BUMD listrik dan gas, koperasi simpan pinjam, puskesmas atau RSUD, sekolah penerima BOS, dan korporasi swasta menengah sama-sama membutuhkan business case, gate review, dan pemilik manfaat yang jelas. Nilai proyek harus diuji sebelum uang habis, bukan setelah laporan penutupan disusun.

💡 Angka yang mengubah keputusan: 70%. Persentase proyek TI yang gagal menghasilkan manfaat yang dijanjikan, bukan karena teknologinya salah, tetapi karena business case tidak pernah ditagih setelah proyek selesai.

Catatan Akhir: Mengikat Makna

Sebelum menutup pembahasan pengawalan investasi, kita kumpulkan kembali pagar-pagar utamanya:

• Tanpa business case, proyek TI mudah berubah menjadi perjudian anggaran.
• Gate review memberi organisasi titik keputusan untuk melanjutkan, memperbaiki, menunda, atau menghentikan proyek.
• Project board harus memiliki sponsor eksekutif, pemilik bisnis, TI, keuangan, dan fungsi risiko sesuai kebutuhan.
• Pemilik manfaat harus berasal dari sisi bisnis, bukan hanya dari TI.
• Realisasi manfaat perlu diukur setelah proyek selesai; keberhasilan proyek tidak berhenti pada go-live.

Uji Nyali Eksekutif: Lima Pertanyaan yang Harus Bisa Anda Jawab

1. Berapa proyek TI aktif yang memiliki business case tertulis dan disetujui?
2. Siapa pemilik manfaat bisnis untuk setiap proyek TI besar?
3. Apakah proyek memiliki gate review dengan kriteria keputusan yang jelas?
4. Proyek mana yang seharusnya dihentikan atau diubah arah karena manfaatnya tidak lagi jelas?
5. Apakah manfaat proyek diukur setelah go-live, atau proyek dianggap selesai saat sistem dipasang?

Aksi Instan: Tiga Gebrakan untuk Minggu Ini

1. Ambil satu proyek TI yang sedang berjalan; periksa apakah ada business case tertulis dan gate review yang terjadwal.
2. Buat templat business case satu halaman: nilai investasi, manfaat yang diukur, risiko utama, dan pemilik manfaat dari sisi bisnis.
3. Tetapkan aturan Gate 0: tidak ada proposal proyek TI masuk tahap perencanaan tanpa business case awal yang disetujui komite pengarah.

Amunisi Rapat: Daftar Periksa Investasi TI

Gunakan daftar pertanyaan di bawah ini untuk memicu diskusi kritis yang memastikan seluruh tim selaras dengan target tata kelola:

• Proyek memiliki business case
• Manfaat bisnis memiliki ukuran dan baseline
• Pemilik manfaat dari sisi bisnis ditetapkan
• Gate review dan kriteria keputusan disepakati
• Risiko proyek dicatat dan memiliki mitigasi
• Rencana pengukuran manfaat setelah go-live tersedia

🛠️ Besok pagi, coba ini: Minta daftar semua proyek TI yang berjalan. Untuk setiap proyek, tanyakan: siapa sponsor dari sisi bisnis? Kalau jawabannya “Kepala TI” untuk semua, Anda tidak punya tata kelola investasi.

Untuk Disampaikan ke Direksi

Rangkuman untuk manajer TI yang perlu menyampaikan isi bab ini ke pimpinan dalam 3 menit:

1. Setiap proyek TI di atas threshold tertentu wajib punya gate review. Gate review bukan formalitas; ia adalah titik di mana proyek bisa dihentikan sebelum kerugian membesar. Tanpa gate, proyek berjalan dengan momentum anggaran, bukan dengan justifikasi bisnis.
2. Business case harus ditulis dalam bahasa manfaat bisnis, bukan spesifikasi teknis. “Migrasi ke cloud” bukan manfaat. “Pemulihan layanan dalam 4 jam setelah bencana” adalah manfaat. Kalau Direksi tidak bisa membaca business case dalam 10 menit, tulis ulang.
3. Post-implementation review adalah ritual yang paling sering dilewati; dan paling penting. Tanpa PIR, organisasi tidak tahu apakah investasi TI benar-benar menghasilkan manfaat yang dijanjikan. Ini adalah akuntabilitas, bukan opsional.

Gunakan template Business Case dan Gate Review Form dari tools.itgbook.com.

Amunisi Rapat: Satu Pertanyaan Penguji Pimpinan

Berapa proyek TI aktif saat ini yang tidak memiliki pemilik manfaat yang jelas dari sisi bisnis?

Jawaban atas pertanyaan ini biasanya membedakan proyek yang benar-benar strategis dari proyek yang hanya terlihat penting karena anggarannya besar.

Menuju Bab 10: Mengukur Kematangan Tata Kelola

Setelah struktur, dokumentasi, audit, dan tata kelola proyek dibahas, pertanyaan berikutnya adalah tingkat kematangan organisasi saat ini. Bab 10 membahas cara mengukur kematangan tata kelola TI secara terstruktur sebelum masuk ke fase implementasi.

Referensi & Eksplorasi Lanjutan

1. COBIT 2019 Framework: Governance and Management Objectives

   • ISACA (2019). Governance and management objectives untuk project management.
   • 🔗 Akses COBIT 2019 Framework

2. Pulse of the Profession Report

   • PMI (2023). Laporan tahunan tentang performa proyek globally.
   • 🔗 Akses PMI Pulse of the Profession

3. Making Project Governance Work in a Multi-Project Environment

   • Müller, R., & Turner, J. (2007). International Journal of Project Management.
   • Studi tentang praktik project governance di organisasi multi-proyek.

4. PMBOK Guide 7th Edition

   • PMI (2021). Standard for Project Management berbasis principles dan performance domains.
   • 🔗 Akses

5. PRINCE2 Foundation and Practitioner

   • AXELOS/PeopleCert (berkala). Methodology project management dengan stage-gate approach.
   • 🔗 Akses

6. ISO 21500:2021 Project, Programme and Portfolio Management

   • ISO (2021). Standar internasional untuk project portfolio management.
   • 🔗 Akses

7. Standish Group CHAOS Report

   • Standish Group (berkala). Riset tahunan tingkat keberhasilan proyek TI.
   • 🔗 Akses

Catatan akses sumber: Tautan di atas mengarah ke portal resmi pemerintah, lembaga standar, atau penerbit. Sebagian dokumen tersedia bebas; dokumen ISO/IEC dan jurnal akademik tertentu bersifat berbayar di situs resmi. Apabila tautan berubah karena pembaruan portal, gunakan judul resmi dan nomor regulasi sebagai dasar pencarian.

Penafian: Tulisan ini adalah pandangan pribadi penulis berdasarkan pengalaman praktis dan studi independen. Bukan merupakan pandangan institusional atau komitmen formal dari organisasi mana pun. Hook pembuka adalah komposit pembelajaran, bukan rekonstruksi satu organisasi tertentu.