proyek ti paling mengesalkan dan membuat marah

MANAJEMEN-TI.COM – Bagi para profesional TI, mendapatkan sebuah proyek merupakan wahana untuk mengimplementasikan ilmu yang dimilikinya, memperluas pengalaman, meninggikan jam terbang, sekaligus cara untuk mendapatkan rezeki untuk mempertebal kantong dan rekeningnya. Namun demikian ada beberapa jenis proyek TI yang paling ditakuti atau kurang disukai oleh para profesional TI karena seringkali mengesalkan bin menyebalkan.

Apa saja proyek TI yang dimaksud?

1. Proyek patching sistem yang sudah tua

Manajemen patch biasanya bukan proyek besar yang menarik, namun kegagalan padanya akan dapat menyebabkan bencana sekuriti yang meluluh-lantakkan organisasi. Proyek TI jenis ini biasanya juga melibatkan banyak sekali piranti yang mesti dipantau dari mulai server sampai dengan PC/notebook yang digunakan di lingkungan end user. Tidak menjaga keamanan dari salah satu piranti saja berarti telah membahayakan sistem secara keseluruhan. Karena kekuatan keamanan sebuah sistem berada pada titik terlemahnya.

Proyek manajemen patch ini akan semakin mengkhawatirkan jika dilakukan pada sistem yang terabaikan selama bertahun-tahun.

Momen paling ditakuti adalah ketika setelah dilakukan patching kemudian server lama sekali tidak merespon atau malah berhenti sama sekali. Pada lingkungan tertentu mungkin masih bisa dipantau dan diperbaiki melalui console yang tersedia seperti pada virtual machine. Tapi pada banyak lingkungan lain, tidak tersedia fasilitas semacam itu. Sehingga yang bisa dilakukan adalah melakukan patch dan lalu berdoa.

Pelajaran yang diambil: untuk menghindari skenario terburuk, lakukan perhatian ekstra untuk memastikan bahwa Anda sudah sepenuhnya menguji rencana backup yang memperhitungkan setiap sistem. Termasuk memberikan notifikasi kepada para pengguna terkait untuk melakukan backup data-data penting untuk mengantisipasi jika skenario patch tidak mulus seperti direncanakan. Melakukan persiapan untuk segala skenario yang mungkin adalah kuncinya.

2. Proyek Migrasi Email ke Cloud

Memindahkan dari sebuah solusi email on-premise ke cloud sepertinya terlihat sederhana prinsipnya. Namun ternyata tidak sesederhana yang dibayangkan.

Pada satu sisi, banyak user itu ternyata tipe penimbun. Mereka masih menyimpan bergiga-giga pesan email yang mestinya sudah dihapus bertahun-tahun yang lalu. Sehingga menyebabkan volume data yang mesti dipindahkan menjadi luar biasa. Belum lagi jika sistem email yang lama berbeda jauh dengan sistem email yang baru, sehingga perlu banyak usaha konversi yang harus dilakukan. Padahal beberapa informasi yang dikandungnya mungkin bersifat sangat sensitif dan terikat aturan tertentu. Seperti misalnya GDPR, ITE, SOX, atau regulasi-regulasi lainnya.

Dan tentu saja, Anda akan berurusan dengan sistem yang dibutuhkan oleh penggunanya untuk komunikasi setiap saat, 24 jam sehari dan 7 hari seminggu. Sehingga gangguan pada layanan email ini akan dapat menciptakan kegaduhan yang tidak mengenakkan.

Pelajaran yang diambil: pastikan seluruh kebutuhan sistem dan infrastruktur pendukungnya telah benar-benar siap sebelum benar-benar dilakukan. Libatkan representasi user yang berpengaruh untuk membuktikan kesiapan tersebut dan menguji-cobakannya pada sebagian lingkungan dulu sebelum melakukan migrasi secara total.

[Baca juga: Quo Vadis Perlindungan Data Pribadi di Indonesia]

3. Proyek Kepatuhan yang Minim Dukungan

Ada dua jenis proyek TI: yaitu yang mendapatkan dukungan kuat dari top management karena nilai strategisnya pada kesuksesan organisasi. Dan yang kedua adalah proyek TI lainnya. Proyek TI yang paling mengesalkan adalah ketika para staf jungkir balik berusaha menjalankan proyek TI karena tuntutan kepatuhan, tapi dukungan dari atasnya minimal. Padahal sebenarnya kepatuhan itu merupakan tanggung-jawab top management. Namun karena dikiranya itu merupakan pekerjaan TI belaka, maka diserahkan ke bagian TI dengan tanpa dukungan yang memadai karena dinilai kurang strategis.

Pelajaran yang diambil: Dokumentasikan keseluruhan proses, termasuk usaha yang gagal ketika meminta para pihak yang terkait untuk berpartisipasi. Namun Anda juga perlu mendistribusikan informasi tersebut kepada orang-orang yang tepat, sedemikian sehingga para sponsor proyek tidak dapat mengelak lagi karena kekurang-peduliannya di kemudian hari. Kalau cara ini belum berhasil, sepertinya Anda perlu berfikir cari posisi lain begitu ada kesempatan.

[Baca juga: Integrasi GRC di Era Integrasi Industri Finansial]

4. Proyek ERP

Barangkali tidak ada sebuah proyek yang menguras emosi dan energi dibandingkan dengan mengimplementasikan sebuah sistem ERP baru.

Adanya keharusan untuk mengintegrasikan ERP tersebut dengan infrastruktur eksisting juga selalu merupakan potensi bahaya tersendiri. Belum lagi kalau terdapat permasalahan perbedaan kebiasaan, budaya, bahasa dan sejenisnya yang akan membuat proyek TI yang satu ini menjanjikan tingkat kepusingan tingkat dewa.

Tantangan terbesar dalam implementasi ERP ini sebenarnya lebih pada aspek non teknis. Banyak hal non teknis yang bagi orang-orang TI tidak terbayangkan sebelumnya namun dapat membuat proyek TI tersebut tidak kunjung sampai ke ujung penyelesaiannya.

Pelajaran yang diambil: teknologi saja bukanlah jawaban. Faktor orang (people) dan proses juga sangat penting untuk diperhatikan.

[Baca juga: Sistem ERP sudah Mati?!]

5. Proyek Tak Sesuai Lingkup dan Janji

Kesalahan dalam estimasi waktu dan usaha yang diperlukan untuk menyelesaikan proyek dapat membuat proyek yang sebetulnya menantang menjadi menyeramkan. Sebabnya bisa karena optimisme yang berlebihan, keinginan untuk memberikan impresi pada pimpinan, atau kegagalan untuk memberikan batasan pada lingkup proyek TI.

Kegagalan tersebut yang mungkin didasari awalnya dengan maksud-maksud baik seperti diatas, tapi pada akhirnya akan merugikan semua pihak. Alih-alih membahagiakan pimpinan atau pelanggan, tapi akan justru membuat pimpinan atau pelanggan kecewa dan yang mengerjakan pun mengalami kerugian tak terkira baik moral maupun material.

Pelajaran yang diambil: benar-benar lakukan perencanaan proyek secara hati-hati dan sebisa mungkin akurat. Lalu setiap ada perubahan atau deviasi terhadap proyek maupun lingkup, maka pastikan kembali perencanaan yang sebelumnya telah dibuat. Apakah akan mengubah waktu penyelesaian, apakah dibutuhkan penambahan sumber daya, dan sebagainya.

[Baca juga: Bahaya Requirement Volatility]

6. Permintaan Spesial dari Direksi

Idealnya permintaan kebutuhan proyek itu selalu dikaitkan skala prioritasnya dengan kebutuhan strategis bisnis perusahaan, pada rencana-rencana yang telah disusun oleh perusahaan untuk kemajuan bisnis kedepan. Sehingga berdasarkan hal tersebutlah maka sebuah proyek TI tersebut disetujui dan dianggarkan.

Namun ternyata bukan seperti itu yang banyak terjadi di berbagai perusahaan. Seringkali yang paling berkuasa lah yang akan menentukan kebutuhan perusahaan untuk segalanya. Termasuk kebutuhan terkait proyek-proyek TI.

Sehingga jadi serba salah. Kalau kemauan tersebut dituruti, bisa jadi nilai yang didapatkan perusahaan tidak sepadan karena permintaan yang kurang relevan, biaya yang tidak diperhitungkan, dan sebagainya. Tapi kalau tidak dituruti, maka anggaran untuk proyek TI tersebut bisa tidak disetujui atau dihentikan di tengah jalan.

Pelajaran yang diambil: Jika Anda tidak memiliki cukup pengaruh dalam proyek TI tersebut, maka temukan orang yang memiliki pengaruh terhadap keputusan-keputusan pimpinan perusahaan. Kemudian coba dekati dan beri masukan dengan argumentasi yang kuat terkait dampak dari permintaan-permintaan direksi terhadap proyek maupun bisnis perusahaan.

[Baca juga: Lebih Lanjut Risiko Maut Implementasi ERP]

Itulah antara lain enam jenis proyek yang konon paling dikhawatirkan oleh para profesional TI. Seperti Anda lihat, hampir semuanya bukan permasalahan teknologi. Proyek-proyek TI seringkali jatuh tersungkur ke jurang kegagalan atau tertatih-tatih menuju finish karena aspek-aspek non teknis. Seperti ekspektasi yang tidak realistis, kesalahan dalam penentuan lingkup, benturan budaya, kurangnya dukungan dari atas, hingga ketidak tahuan para pengambil keputusan.

Bagaimana dengan proyek-proyek TI Anda?

Secara teoretis, solusi terhadap kengerian proyek-proyek TI tersebut diatas memang terlihat sederhana. Tapi bukankah katanya setan itu ada bersemayam pada detilnya?! [mti/cio]