Adakah Proyek TI yang Sukses?

Sumber gambar dari sini.

Pernahkah proyek Teknologi Informasi (TI) yang Anda tangani atau yang Anda terlibat di dalamnya termasuk proyek yang sukses? Jika pernah apalagi lebih dari satu kali, Anda boleh berbangga sebagai orang istimewa yang ada di muka bumi ini. Kenapa istimewa? Karena proyek TI yang sukses merupakan hal yang sangat jarang terjadi. Tapi tunggu dulu. Klaim sukses Anda tadi berdasarkan apa? Kita mesti sepakat dulu apa kriteria untuk menyatakan bahwa suatu proyek itu sukses?


Proyek TI dinyatakan sukses jika memenuhi tiga kriteria berikut:

• Tepat waktu
• Biaya sesuai atau di bawah Anggaran
• Sistem bekerja sesuai kebutuhan

Salah satu dari kriteria tersebut tidak terpenuhi, maka proyek itu termasuk proyek yang gagal. Ada banyak sekali proyek TI yang sudah dilaksanakan, apalagi peranan TI dalam bisnis semakin tak terelakkan sehingga akan makin banyak lagi proyek TI. Tapi mengapa masih banyak yang gagal? Apa sebetulnya yang menjadi penyebab dari banyaknya kegagalan itu? Tulisan ini berusaha mengidentifikasi dan mengkaji enam hal yang menjadi penyebab utamanya.

1. Tidak Ada atau Jeleknya Requirements


Hal yang hampir selalu terjadi adalah bahwa Business User merasa membutuhkan sistem, software atau aplikasi tapi tidak tahu seperti apa sistem yang ia/mereka butuhkan. Jika toh tahu, hanya secara garis besar. Misalnya, bagian pelayanan pelanggan membutuhkan suatu sistem yang memudahkan mereka berinteraksi dengan pelanggan, untuk penawaran produk baru, penanganan keluhan pelanggan, dan pelaporan tentang profil pelanggan dan prospek. Tapi user tidak tahu lebih detil dari itu. Jika ditanyakan persisnya seperti apa yang dibutuhkan, user tidak bisa menerangkannya apalagi mendokumentasikannya dengan jernih dan jelas. Menghadapi situasi semacam ini, bagian TI atau para developer seringkali menanggapinya dengan membuat suatu sistem atau aplikasi yang berdasarkan kira-kira atau keyakinan akan apa yang dibutuhkan oleh user.

Begitu sistem itu dikirim ke user untuk user acceptance test (UAT), user akan mengatakan bahwa sistem yang dibikin tidak sesuai dengan yang mereka butuhkan. Situasi semacam ini jelas menjadi penyumbang terbesar bagi kegagalan suatu proyek, khususnya dalam pemenuhan kriteria ketiga: "Sistem bekerja sesuai kebutuhan".

2. Lingkup Pekerjaan Membengkak

Penyebab kedua ini ada kaitan dengan penyebab pertama. Seringkali terjadi juga, ketika sistem yang sudah jadi atau setengah jadi relatif memenuhi kebutuhan user, kini user menjadi jauh lebih "kreatif" jika dibanding pada tahap pengumpulan user requirements. "Kreatif" dalam artian mereka minta perubahan ini-itu dan penambahan ini-itu. Jika perubahan yang diminta menyangkut perubahan business process, developer akan membutuhkan waktu yang cukup lama untuk bisa memenuhinya, karena seringkali harus membongkar banyak komponen atau bahkan harus mengubah desain sistem. Demikian juga berkaitan dengan permintaan yang harus dipenuhi menyangkut penambahan ini-itu, seringkali user minta tambahan fungsi atau fitur yang sebenarnya lebih bersifat "nice to have", bukan "must have".

Ini merupakan masalah manajemen yang berkaitan erat denga pengendalian perubahan (Change Control). Manajemen harus realistis akan apa yang mereka butuhkan dan kapan kebutuhan itu harus dipenuhi, dan harus taat pada asas ini. Seringkali user meminta apa yang dibayangkan bakal dibutuhkan untuk dipenuhi saat ini, sementara apa yang dibayangkan itu bisa jadi tidak akan benar-benar dibutuhkan mengingat perubahan iklim dan persaingan bisnis yang cepat berubah.

Membengkaknya Lingkup Pekerjaan jelas mengakibatkan molornya waktu penyelesaian proyek dan membesarnya biaya proyek melampaui besaran yang sudah dianggarkan. Dua kriteria pertama secara bersamaan tidak bisa dipenuhi.

3. Kurangnya Keterlibatan User

Keterlibatan user yang kurang telah menjadi bukti fatal bagi banyak proyek. Tanpa keterlibatan user, tak seorangpun dari bagian bisnis yang merasa berkomitmen terhadap sistem, dan bahkan bisa memusuhinya. Agar sukses, manajemen senior harus dilibatkan sejak awal dan secara kontinyu hingga tahap pengembangan selesai. Jelas ini membutuhkan waktu dan upaya. Dan jika sudah disibukkan oleh pekerjaan rutin mereka, meluangkan waktu untuk terlibat dalam proyek bukan lagi menjadi prioritas. Di sini perlunya dukungan yang terus-menerus dari manajemen senior terhadap proyek yang sedang berjalan sehingga jelas bagi para staf bahwa proyek tersebut merupakan sebuah prioritas.

Dalam hal ini, saya pernah punya pengalaman yang sangat menyenangkan dan selalu saya ingat. Dalam suatu proyek TI di sebuah perusahaan besar, manajemen senior dan dalam kasus ini seorang Direktur Keuangan memberikan dukungan penuh dan kontinyu terhadap proyek yang kami kerjakan. Hampir tiap dua minggu sekali beliau memanggil tim proyek untuk ditanyai status dan kemajuan proyek, dan juga kesulitan dan hambatan yang kami hadapi. Dan seringkali beliau melibatkan diri dalam rapat proyek rutin yang diselenggarakan tim proyek. Hal ini memang sempat membuat banyak staf TI dan business user mengeluh karena harus kerja ekstra waktu. Tapi keluhan itu menjadi terbayar lebih dari suksesnya proyek dan kemudahan yang didapat dari pemakaian aplikasi hasil proyek. Dan semua orang yang terlibat dalam proyek merasa bangga.

4. Skala Waktu Tidak Realistis atau Terlalu Lama

Jangka waktu proyek yang terlalu lama dapat mengakibatkan software/aplikasi yang dihasilkannya sudah kurang/tidak relevan lagi bagi perusahaan. Tidak relevan bisa jadi karena produk atau jasa yang didukung oleh aplikasi tadi sudah tidak digunakan lagi, atau ada perubahan business process atau ada perubahan peraturan yang harus diikuti perusahaan. Saran yang harus diikuti adalah buatlah jangka waktu proyek yang singkat. Jika sistem yang akan dibangun adalah sistem yang besar, harus dipecah-pecah menjadi banyak proyek terpisah. Pendekatan ini memang akan sering menimbulkan masalah, tapi keuntungan yang didapat dengan cara ini akan sangat besar.

Dengan adanya paradigma/pendekatan baru dalam pengembangan software yakni pengembangan berbasis Service-Oriented Architecture (SOA), diharapkan masalah yang timbul dari pendekatan di atas bisa berkurang secara signifikan.

5. Tidak Ada Sistem Pengendalian Perubahan (Change Control System)

Laju perubahan di dunia bisnis semakin hari semakin kencang. Sangatlah tidak realistis jika kita mengharapkan tiadanya perubahan requirements sepanjang jangka waktu proyek. Namun demikian perubahan-perubahan yang tidak terkendali bisa menjadi malapetaka dan mengakibatkan kegagalan proyek.

Hal ini menekankan kembali betapa pentingnya jangka waktu yang lebih pendek, dan perlunya membagi pengembangan sistem menjadi beberapa fase sedemikian rupa sehingga perubahan berpeluang kecil untuk mempengaruhi pengembangan. Bagaimanapun perubahan harus dikelola seperti faktor-faktor bisnis yang lain. Bisnis harus melakukan evaluasi terhadap pengaruh perubahan requirements terhadap waktu, biaya, dan resiko proyek. Manajemen Perubahan (Change Management) dan disiplin yang terkait dengannya yakni Configuration Management merupakan keahlian yang harus dikuasai.

6. Pengujian yang Jelek

Para developer banyak melakukan pengujian (testing) pada waktu development, tapi pada akhirnya user harus melakukan user acceptanace test (UAT) untuk memeriksa apakah sistem memenuhi kebutuhan bisnis. Akan tetapi acceptance test seringkali gagal menangkap kekeliruan yang ada pada sistem sebelum Go-Live karena:

• Requirements yang jelek sehingga requirements itu sendiri sulit diuji.
• Tiadanya perencanaan pengujian (test plan) yang bagus, sehingga sistem tidak diperiksa secara metodologis.
• User tidak mendapatkan pelatihan yang memadai sehingga tidak memahami tujuan dari testing.
• Tiadanya waktu yang memadai untuk testing karena proyek sudah terlambat.

Mengatasi enam penyebab utama kegagalan proyek di atas bukanlah pekerjaan yang ringan. Untuk itu, antara lain dibutuhkan Prject Manager (PM) yang berpengalaman, ulet, tegas dan berwibawa. Untuk faktor terakhir yakni berwibawa, pernah ada kejadian seorang petinggi perusahaan konsultan TI yang pada waktu mencari calon  PM, dia memasukkan syarat fisik yaitu calon yang bertampang agak tua dan sudah beruban, tentu saja di samping kriteria wajib yang lain. Kedengarannya aneh dan lucu, tapi jangan salah, seringkali resep itu manjur.

Jakarta, Juni 2010
Samsurizal R.