Pada artikel sebelumnya, telah disinggung mengenai bahayanya sering berubahnya kebutuhan sistem (Requirement Volatilty/RV) terhadap sebuah proyek pengembangan/implementasi software. Bahwa RV ini termasuk diantara momok yang paling ditakuti dalam sebuah proyek pengembangan aplikasi. Karena RV ini bisa membuat sebuah proyek yang tidak pernah sampai ke ujung akhirnya. Ibarat seorang pelari yang harus terus berlari karena berkejar-kejaran dengan garis finish yang selalu bergeser. Waktu yang menentukan seberapa kuat si pelari itu punya energi untuk tetap berlari. Seperti sindiran Sidney Markowits: “The software isn’t finished until the last user is dead”. Dooh…gawat!
Celakanya lagi, ternyata RV ini seringkali berada diluar kendali sang project manager [Tiwana, 2004]. Tapi walau tidak semua faktor RV dapat dikendalikan, tapi sesungguhnya bukan berarti ia tidak dapat dikelola. Misalnya seorang Project Manager (PM) bisa saja menolak permintaan perubahan yang menurutnya tidak penting atau sesuai dengan tujuan pembuatan sistem. Atau bisa saja PM menerapkan sebuah metodologi pengembangan sistem yang dapat menekan kemungkinan perubahan di akhir-akhir, karena secara umum semakin akhir permintaan perubahan itu muncul, maka “biaya” untuk menerapkan perubahan tersebut juga menjadi semakin besar pula. Dan “biaya” tersebut bisa saja tidak mampu untuk ditanggung lagi, misalnya karena harus merubah desain awal secara signifikan atau dampak perubahan yang merembet ke bagian-bagian lainnya. Belum lagi kalau perubahan itu menyebabkan waktu proyek membengkan dan berakibat personil-personil kunci proyek berguguran misalnya karena durasi kontrak yang sudah expired.
Lalu bagaimana sebenarnya metode untuk mengelola risiko-risiko RV ini? Berikut ini adalah beberapa diantaranya [Sakhtivel, 2010]:
Pertama, Tolak RV. Metode ini adalah metode yang paling mudah dalam pengelolaan RV, yaitu dengan mengunci requirement dan menolak perubahan. Tapi perlu diingat bahwa metode ini tidak selalu dapat diterapkan pada setiap kondisi, karena seringkali user akan menolak untuk menerima sistem jika perubahan yang dimintanya itu tidak dituruti. Apalagi kalau permintaan perubahan itu berasal dari orang yang berjabatan cukup tinggi. Metode ini dapat digunakan oleh PM jika permintaan perubahan tersebut bersifat tidak esensial atau kebutuhan yang sekedar nice-to-have saja.
Kedua, Eliminasi penyebab perubahan yang dapat dihindari. Salah satu faktor risiko RV yang disebutkan pada artikel sebelumnya adalah adanya proses bisnis yang unik dan tidak lazim yang berlaku pada organisasi sehingga menyebabkan kebutuhan ini tidak sepenuhnya dipahami di awal dan berevolusi terus selama proyek. Solusi untuk menekan masalah ini adalah dengan sebisa mungkin menghindari proses bisnis yang “aneh” tersebut jika ia tidak memiliki manfaat yang signifikan dan sistem yang dikembangkan bukan termasuk sistem yang cukup strategis.
Selain itu, cara yang kedua untuk menghindari penyebab perubahan ini adalah dengan meng-hire konsultan yang berpengalaman dengan teknologi dan proses bisnis yang terkait dengan sistem yang akan dibangun. Konsultan ini mesti dilibatkan sejak awal identifikasi kebutuhan. Selain itu tim proyek ini juga mesti melibatkan user yang representatif sebagai counterpart yang seimbang dengan konsultan itu, sehingga komunikasi dapat berjalan baik untuk mengerucutkan secara pasti dan jelas apa dan bagaimana sebenarnya yang dibutuhkan terhadap sistem tersebut.
Kemudian kebutuhan sistem yang disusun secara terstruktur dan sistematis serta terdokumentasi dengan baik akan bermanfaat dalam menghindari penyebab perubahan requirement. Verifikasi dan validasi kebutuhan dengan cara review, rekonfirmasi, dan mensimulasikan kebutuhan yang sudah tercatat tersebut dapat memastikan sejak dini bahwa seluruh kebutuhan tersebut memang benar, konsisten dan lengkap, sehingga kemungkinan akan berubah di tahap-tahap berikutnya akan menjadi semakin kecil.
Ketiga, gunakan metode yang tepat untuk perubahan yang sulit dihindari. Untuk sistem-sistem strategis dan menggunakan teknologi baru, umumnya RV tidak dapat ditolak atau dihindari. Oleh karena itu penting utnuk menggunakan metode pengidentifikasikan kebutuhan dan pengembangan yang tepat untuk sistem-sistem seperti ini. Untuk sistem dengan model seperti ini metode-motode iteratif seperti Rapid Application Development (RAD) dan agile development seringkali cocok untuk digunakan dalam mencegah RV, tapi metode ini belum cukup terbukti untuk proyek pengembangan sistem yang besar. Pada proyek pengembangan sistem yang besar, metode yang seringkali cocok untuk digunakan adalah penggunaan prototipe dan pilot project. Jika developer tidak memiliki pengalaman yang memadai terkait teknologi dan proses terkait, maka tim perlu diperkuat dengan memasukkan tenaga ahli untuk teknologi dan proses bisnis.
Keempat, mengelola perubahan tersebut dan dampak yang ditimbulkannya. Jelas bahwa RV dapat membengkakkan biaya dan waktu proyek, dan oleh karenanya maka penerapannya mesti dikelola secara hati-hati. Penerapan perubahan yang yang tidak tepat bisa-bisa malah memicu perubahan lain yang lebih besar dan biaya yang makin besar pula. Sebuah sistem manajemen perubahan yang baik perlu diterapkan untuk mengidentifikasi seberapa besar dampak sebuah perubahan terhadap biaya dan jadwal serta kebutuhan-kebutuhan sistem lainnya. Lalu perubahan yang memiliki dampak besar perlu persetujuan pada tingkatan yang cukup tinggi. Dalam hal ini dukungan dan komitmen top management akan sangat berpengaruh untuk memecahkan konflik-konflik yang mungkin muncul terkait manajemen perubahan ini.
Sebelum mengeksekusi sebuah proyek pengembangan sistem, PM mesti mengidentifikasi faktor-faktor risiko terkait RV ini dan kemudian menganalisis dan menerapkan manajemen risiko yang tepat untuk mengelolanya. Para project manager dan developer biasanya cukup ngeh dengan adanya risiko RV ini, tapi hati-hati bahwa pihak-pihak lainnya bisa saja tidak memahami dengan baik risiko-risiko RV dan implikasi dari risiko ini terhadap proyek [Thakurta, 2010]. Oleh karena itu salah satu tugas penting PM adalah mengkomunikasikan risiko-risiko RV ini pada para pihak terkait dan mengedukasi bagaimana pengelolaan risiko-risiko tersebut. Selama proyek berlangsung, PM juga perlu menginformasikan perkembangan pengelolaan risiko RV ini kepada top management berikut langkah-langkah mitigasi berikutnya.
Jika diringkas lebih singkat lagi, elemen yang paling vital dalam keberhasilan penanganan RV ini adalah (1) komitmen top management; (2) kualitas dan kapasitas Project Manager; (3) mekanisme verfiikasi dan validasi kebutuhan; dan (4) pemahaman yang memadai dari pihak developer maupun user terkait domain aplikasi yang dikembangkan. Keempat elemen tersebut telah terbukti sangat vital peranannya dalam mengelola RV untuk berbagai jenis pengembangan sistem.
Saya ingin menutup artikel ini dengan sebuah kalimat penuh makna dari Steve McConnel: “The most difficult part of requirements gathering is not the act of recording what the user wants, it is the exploratory development activity of helping users figure out what they want”. Dan saya sepenuhnya setuju dengannya. [manajemen-ti]
Tentang Penulis:
Umar Alhabsyi, MT, CISA, CRISC.
Merupakan konsultan senior IT Management, pendiri sekaligus direktur iValueIT Consulting (PT IVIT Konsulindo). Berpengalaman ekstensif dalam berbagai proyek konsultansi di bidang IT Planning, IT Governance, IT Audit, IT Performance Management, IT Service Management, SDM TI, dll untuk berbagai sektor organisasi dan perusahaan. Umar juga aktif dalam memberikan training dan seminar di bidang IT Management.
Umar dapat diakses melalui:
email: umar.alhabsyi@gmail.com;
twitter: @umaralhabsyi.