Proyek IT yang gagal hampir tidak pernah gagal karena teknologinya kurang canggih. Ia gagal karena kesepakatan yang tidak jelas, harapan yang tidak sama, dan tidak adanya orang yang bertanggung jawab di sisi perusahaan.
Tujuh kesalahan di bawah ini muncul berulang kali di berbagai skala perusahaan, dari usaha keluarga sampai korporasi. Kabar baiknya, semuanya bisa dicegah di tahap sebelum tanda tangan — yaitu tahap yang paling murah untuk memperbaiki apa pun.
Memilih penawaran termurah
Harga terendah hampir selalu berarti salah satu dari tiga hal: cakupan pekerjaannya lebih sempit dari yang Anda kira, kualitasnya dikorbankan, atau vendor sengaja memasang harga rendah di awal dan mengejar keuntungan dari permintaan perubahan di tengah jalan.
Penangkalnya: minta setiap penawaran dipecah per komponen — analisis, desain, pengembangan, pengujian, migrasi data, pelatihan, dan garansi. Penawaran yang tidak bisa dipecah biasanya belum dipikirkan, dan yang belum dipikirkan akan menjadi tagihan tambahan nanti.
Tidak menulis definisi selesai
Ini penyebab sengketa nomor satu. Perusahaan menganggap proyek selesai ketika sistem dipakai lancar oleh seluruh tim. Vendor menganggap selesai ketika fitur sudah dikirim sesuai daftar. Dua definisi ini bisa berjarak berbulan-bulan.
Tulis kalimat ini di kontrak: “Pekerjaan dinyatakan selesai ketika sistem berhasil menjalankan proses X, Y, dan Z dengan data nyata perusahaan selama 14 hari berturut-turut tanpa kesalahan yang menghentikan operasional.” Kalimat semacam ini menghapus 90 persen potensi perselisihan.
Tidak mengatur kepemilikan source code dan data
Banyak perusahaan baru menyadari hal ini ketika ingin berpindah vendor, dan saat itu posisi tawarnya sudah nol. Pertanyaan yang harus dijawab sebelum tanda tangan cuma dua: siapa yang memiliki kode yang dibuat khusus untuk Anda, dan bagaimana cara Anda mengambil seluruh data Anda kalau kerja sama berhenti.
Tidak menunjuk pemilik proyek internal
Vendor tidak bisa menggantikan peran ini. Harus ada satu orang di perusahaan Anda yang berwenang memutuskan, yang paham prosesnya, dan yang waktunya memang dialokasikan untuk proyek. Kalau peran ini kosong, keputusan akan tertunda berminggu-minggu dan vendor akan menagih waktu tunggu.
Penangkalnya: tunjuk namanya di dalam kontrak, sebutkan berapa jam per minggu yang dialokasikan, dan tetapkan siapa penggantinya kalau ia berhalangan. Ini terlihat berlebihan, tetapi proyek yang berjalan lancar hampir selalu punya orang seperti ini.
Membeli fitur, bukan menyelesaikan masalah
Daftar fitur adalah cara termudah membandingkan penawaran, dan karena itu pula cara paling menyesatkan. Fitur yang mengesankan di demo sering kali bukan fitur yang tim Anda pakai setiap hari.
Penangkalnya: ubah daftar fitur menjadi daftar skenario. Alih-alih menulis “butuh modul laporan”, tulis “setiap Senin pagi manajer cabang harus bisa melihat penjualan mingguan per kategori tanpa meminta bantuan siapa pun”. Skenario bisa diuji, fitur hanya bisa dijanjikan.
Melewatkan uji coba dengan data nyata
Demo selalu berjalan mulus karena datanya rapi dan skenarionya dipilih. Masalah baru muncul ketika sistem bertemu data Anda yang sebenarnya: nama produk tidak konsisten, ada transaksi lama yang aneh, satuan berbeda antar cabang, dan pengecualian yang selama ini ditangani secara manual.
Minta ini sebelum tanda tangan: Uji coba terbatas memakai sebagian data nyata Anda sendiri, dijalankan oleh staf yang nanti benar-benar memakainya. Kalau vendor menolak dengan alasan yang berbelit, itu informasi yang sangat berharga.
Tidak menganggarkan biaya setelah proyek selesai
Sistem bukan gedung yang sekali dibangun lalu berdiri sendiri. Ada server yang harus dibayar, pembaruan keamanan yang harus dipasang, penyesuaian ketika layanan pihak ketiga berubah, dan permintaan perbaikan kecil yang tidak akan pernah berhenti.
Penangkalnya: sepakati biaya pemeliharaan tahunan sejak awal, beserta cakupannya secara rinci — apa yang termasuk, apa yang dihitung sebagai pekerjaan baru, dan berapa lama waktu tanggap ketika ada gangguan.
Daftar periksa singkat sebelum tanda tangan
| Yang harus ada | Kenapa penting |
|---|---|
| Rincian penawaran per komponen | Mencegah biaya tersembunyi muncul di tengah jalan |
| Definisi selesai yang terukur | Menghapus sengketa tentang kapan proyek berakhir |
| Klausul kepemilikan kode dan data | Menjaga posisi tawar Anda di masa depan |
| Nama pemilik proyek internal | Memastikan keputusan tidak menggantung |
| Skenario pemakaian, bukan daftar fitur | Bisa diuji, bukan sekadar dijanjikan |
| Uji coba dengan data nyata | Mengungkap masalah sebelum uangnya keluar |
| Anggaran pemeliharaan tahunan | Mencegah sistem terbengkalai setelah serah terima |
Pertanyaan yang Sering Diajukan
MDH biasa diminta meninjau ruang lingkup dan penawaran teknis sebelum perusahaan memutuskan. Kami akan menunjukkan bagian yang berpotensi menjadi biaya tambahan di kemudian hari.
Minta Peninjauan
