Manajemen
resiko adalah proses pengukuran atau penilaian resiko serta pengembangan
strategi pengelolaannya. Strategi yang dapat diambil antara lain adalah
memindahkan resiko kepada pihak lain, menghindari resiko, mengurangi efek
negatif resiko, dan menampung sebagian atau semua konsekuensi resiko tertentu.
Penyebab
kegagalan rekayasa perangkat lunak adalah :
-
Perencanaan
yang tidak realistik, terlalu optimis dalam perhitungan.
-
Sistem
pemantauan kerja yang tidak berjalan dengan seharusnya.
-
Perubahan
kebutuhan.
Ada
resiko yang terlihat lebih penting dari pada resiko lainnya. Baik penting atau
tidaknya resiko tergantung pada resiko tersebut, pengaruhnya pada aktivitas
tertentu dan kekeritisan aktivitas tersebut.
Untuk mengurangi bahaya tersebut maka harus ada jaminan untuk
meminimalkan resiko atau paling tidak mendistribusikan selama pengembangan.
Resiko dalam
perangkat lunak memiliki dua karakteristik :
-
Uncertainty
: tidak ada resiko yang 100% pasti muncul.
-
Loss
: resiko berimbas pada kehilangan.
Dan resiko
memiliki tiga kategori :
-
Resiko
proyek : berefek pada perencanaan proyek.
-
Resiko
teknikal : berefek pada kualitas dan waktu pembuatan perangkat lunak.
-
Resiko
bisnis : berefek pada nilai jual produk
Identifikasi
Resiko Proyek Pembuatan Sistem Informasi PT. Yonote
No
|
Risiko
|
Jenis Risiko
|
Kategori (check list risiko)
|
Usaha yang dilakukan
|
1
|
Dokumentasi
tidak detail.
|
Risiko yang
sudah diketahui
|
Resiko proyek
|
Melakukan
validasi mereview ulang.
|
2
|
Waktu
pengerjaan lebih lama dari yang direncanakan
|
Resiko
yang dapat diramalkan
|
Resiko proyek
Resiko
teknikal
Resiko
bisnis
|
Memastikan milestone dilaksanakan sesuai dengan jadwalnya,
jika tidak maka setiap stakeholder yang terkait harus menerima risiko agar
bisa mengembalikan sesuai jadwal, seperti lembur.
|
3
|
Server
tidak kuat menangani banyaknya permintaan
|
Risiko
yang dapat diramalkan
|
Resiko
teknikal
|
Melakukan
peningkatan spesifikasi server dan mendistribusikan server sehingga operasi
tidak dilakukan oleh satu server.
|
4
|
User
Interface (UI) yang kurang user-friendly
|
Risiko
yang dapat diramalkan
|
- Risiko teknikal
|
Melakukan
teknik validasi UI dengan prototyping, bekerja sama dengan pengguna sebagai tester.
|
5
|
Server
rusak
|
Risiko
yang tidak diharapkan
|
- Resiko proyek
Resiko
teknikal
|
Back up
data dari satu server ke server lain yang merupakan replikasi server utama.
|
6
|
Terjadi
hal yang tidak di inginkan pada developer saat pengerjaan.
|
Risiko
yang tidak diharapkan
|
- Resiko proyek
|
Mengatur
waktu kerja seefektif mungkin untuk menghindari kerja berlebihan dan stress
|
Analisa
Resiko
Penentuan
probabilitas terjadinya suatu event sangatlah subyektif dan lebih berdasarkan
nalar dan pengalaman. Beberapa risiko memang mudah untuk diukur, namun
sangatlah sulit untuk memastikan probabilitas suatu kejadian yang sangat jarang
terjadi. Sehingga, pada tahap ini sangtalah penting untuk menentukan dugaan
yang terbaik supaya nantinya kita dapat memprioritaskan dengan baik dalam
implementasi perencanaan manajemen risiko. Kesulitan dalam pengukuran risiko
adalah menentukan kemungkinan terjadi suatu risiko karena informasi statistik
tidak selalu tersedia untuk beberapa risiko tertentu. Selain itu, mengevaluasi
dampak severity (kerusakan) seringkali cukup sulit untuk asset immateriil.
Dampak adalah efek biaya, waktu dan kualitas yang dihasilkan suatu resiko.
Dampak
|
Biaya
|
Waktu
|
Kualitas
|
Sangat
rendah
|
Dana
mencukupi
|
Agak
menyimpang dari target
|
Kualitas
agak berkurang namun masih dapat digunakan
|
Rendah
|
Membutuhkan
dana tambahan
|
Agak
menyimpang dari target
|
Gagal
untuk memenuhi janji pada stakeholder
|
Sedang
|
Membutuhkan
dana tambahan
|
Penundaan
berdampak terhadap stakeholder
|
Beberapa
fungsi tidak dapat dimanfaatkan
|
Tinggi
|
Membutuhkan
dana tambahan yang signifikan
|
Gagal
memenuhi deadline
|
Gagal
untuk memenuhi kebutuhan banyak stakeholder
|
Sangat
tinggi
|
Membutuhkan
dana tambahan yang substansial
|
Penundaan
merusak proyek
|
Proyek
tidak efektif dan tidak berguna
|
Setelah
mengetahui probabilitas dan dampak dari suatu resiko, maka kita dapat
mengetahui potensi suatu resiko. Untuk mengukur bobot resiko kita dapat
menggunakan skala dari 1 – 5 sebagai berikut :
Skala
|
Probabilitas
|
Dampak
|
Sangat
rendah
|
Hampir
tidak mungkin terjadi
|
Dampak
kecil
|
Rendah
|
Kadang
terjadi
|
Dampak
kecill pada biaya, waktu dan kualitas
|
Sedang
|
Mungkin
tidak terjadi
|
Dampak
sedang pada biaya, waktu dan kualitas
|
Tinggi
|
Sangat
mungkin terjadi
|
Dampak
substansial pada biaya, waktu dan kualitas
|
Sangat
tinggi
|
Hampir
pasti terjadi
|
Mengancam
kesuksesan proyek
|
Setelah
resiko yang dapat mempengaruhi pengembangan teridentifikasi maka diperlukan
cara untuk menentukan tingkat kepentingan dari masing-masing resiko. Beberapa
resiko secara relatif tidak terlalu fatal (misal resiko keterlambatan
penyerahan dokumentasi) sedangkan beberapa resiko lainnya berdampak
besar. (misal resiko keterlambatan penyerahan software). Beberapa
resiko sering terjadi (salah satu anggota tim sakit sehingga tidak bisa bekerja
selama beberapa hari). Sementara itu resiko lainnya jarang terjadi (misal
kerusakan perangkat keras yang dapat mengakibatkan sebagian program hilang).
Pengelolaan Resiko
Terdapat beberapa cara untuk mengelola resiko yaitu sebagai
berikut :
1. Risk
Avoidance
Yaitu memutuskan untuk
tidak melakukan aktivitas yang mengandung resiko sama sekali. Dalam memutuskan
untuk melakukannya, maka harus dipertimbangkan potensial keuntungan dan
potensial kerugian yang dihasilkan oleh suatu aktivitas
2.
Risk Reduction
Risk reduction atau disebut
juga risk mitigation yaitu merupakan metode yang
mengurangi kemungkinan terjadinya suatu resiko ataupun mengurangi dampak
kerusakan yang dihasilkan oleh suatu resiko.
3.
Risk Transfer
Yaitu memindahkan resiko pada pihak lain, umumnya melalui
suatu kontrak (asuransi) maupun hedging.
4.
Risk Deferral
Dampak suatu resiko tidak selalu konstan. Risk deferral meliputi menunda aspek suatu proyek
hingga saat dimana probabilitas terjadinya resiko tersebut kecil.
5.
Risk Retention
Walaupun resiko tertentu dapat dihilangkan dengan cara
mengurangi maupun mentransfernya, namun beberapa resiko harus tetap diterima
sebagai bagian penting dari aktivitas.
Penanganan
resiko:
- High probability, high impact: resiko jenis ini umumnya dihindari
ataupun ditransfer.
- Low probability, high impact: respon paling tepat untuk
tipe resiko ini adalah dihindari. Dan jika masih terjadi, maka lakukan
mitigasi resiko serta kembangkan contingency plan.
- High probability, low impact: mitigasi resiko dan
kembangkan contingency plan.
- Low probability, low impact: efek dari resiko ini dapat
dikurangi, namun biayanya dapat saja melebihi dampak yang dihasilkan.
Dalam kasus ini mungkin lebih baik untuk menerima efek dari resiko
tersebut.
Contigency plan
Untuk resiko yang mungkin terjadi maka perlu
dipersiapkan contingency plan seandainya
benar-benar terjadi. Contigency plan haruslah
sesuai dengan proposional terhadap dampak resiko tersebut. Dalam banyak kasus
seringkali lebih efisien untuk mengalokasikan sejumlah sumber daya untuk
mengurangi resiko dibandingkan mengembangkan contingency plan yang
jika diimplementasikan akan lebih mahal. Namun beberapa skenario memang
membutuhkan full contingency plan, tergantung
pada proyeknya. Namun jangan sampai tertukar antaracontingency planning dengan
re-planning normal yang memang dibutuhkan karena adanya perubahan dalam proyek
yang berjalan.
Tabel resiko proyek software dan strategi mengurangi resiko :
Resiko
|
Teknik
mengurangi resiko
|
Kegagalan
pada personil
|
·
Memperkerjakan staf yang handal
·
Job matching
·
Membangun tim
·
Mengadakan pelatihan dan peningkatan karir
·
Membuat jadwal lebih awal bagi personil utama
|
Estimasi
biaya dan waktu yang tidak realistis
|
·
Membuat beberapa estimasi
· Desain untuk biaya
· Meningkatkan pengembangan
· Merekam dan menganalisa proyek sebelumnya
· Standarisasi metode
|
Mengembangkan
fungsi software yang salah
|
·
Evaluasi proyek ditingkatkan
· Buat metode spesifikasi yang formal
· Survey pengguna
· Buat prototype
· Buat user manual lebih awal
|
Mengembangkan
antarmuka pengguna yang salah
|
·
Membuat prototype
· Analisis tugas
· Keterlibatan pengguna
|
Gold
plating
|
·
Mengurangi kebutuhan
· Membuat prototype
· Analisis biaya manfaat
· Desain biaya
|
Terlambat
untuk mengubah kebutuhan
|
·
Mengubah prosedur kendali
· Membatasi perubahan yang terlalu banyak
· Meningkatkan prototype
· Meningkatkan pengembangan (akibat perubahan)
|
Kegagalan
pada komponen yang disuplai pihak eksternal
|
·
Melakukan benchmarking
· Inspeksi
· Spesifikasi formal
· Kontrak perjanjian
· Prosedur dan sertifikasi jaminan kualitas
|
Kegagalan
menjalankan tugas eksternal
|
·
Prosedur jaminan kualitas
· Desain / prototype yang kompetitif
· Membangun tim
· Kontrak insentif
|
Kegagalan
kinerja real-time
|
·
Simulasi
· Benchmarking
· Prototipe
· Tuning
· Analisis teknis
|
Pengembangnya
terlalu sulit secara teknis
|
·
Analisa teknis
· Analisis biaya manfaat
· Prototipe
· Melatih dan mengembangkan staf
|
Daftar
Resiko
No
|
Rank
|
Risk
|
Category
|
Root
Cause
|
Risk
Owner
|
Status
|
R5
|
1
|
Server rusak
|
Resiko Teknologi
|
Server
|
Stakeholder
|
Active
|
R1
|
2
|
Dokumentasi yang tidak mendetail
|
Struktur/Proses risiko
|
Developer
|
Developer
|
Active
|
R3
|
3
|
Waktu pengerjaan yang lebih lama dibandingkan dengan rencana
pengerjaan
|
Struktur/Proses risiko
|
Developer
|
Developer
|
Active
|
Mitigasi
No
|
Risk
|
Risiko
|
Anti-Risk
|
1
|
Risk 1
|
Dokumentasi yang tidak mendetail
|
-
Melakukan penggalian kebutuhan secara
maksimal
-
Analisis scope lebih diperdalam
-
Melakukan pengecekan dokumen secara berkala
|
2
|
Risk 2
|
Waktu pengerjaan yang lebih lama dibandingkan dengan rencana
pengerjaan
|
-
Pengecekan milestone secara teratur sesuai
dengantimelinenya
-
Peningkatan otoritas project manager
-
Peningkatan frekuensi pemantauan project
-
Pemilihan project manager yang paling berpengalaman
-
Meningkatkan komunikasi dan pemahaman project
goals
-
Peningkatan penanganan masalah dan
komunikasi antar
|
3
|
Risk 3
|
Server tidak kuat menangani banyak pengguna
|
-
Memperkirakan jumlah pengguna yang akan
mengakses
-
Melakukan proses dengan beberapa server
replikasi sehingga operasi tidak dilakukan oleh satu server saja
|
4
|
Risk 4
|
Desain UI yang kurang user-friendly
|
-
Melakukan evaluasi secara berkala ke
stakeholder
-
Sistem Analyst mengecek secara berkala
sudahkah sesuai atau mdah digunakan oleh stakeholder
|
5
|
Risk 5
|
Server rusak
|
-
Back up data dari satu server ke server
lain yang merupakan replikasi server utama
|
6
|
Risk 6
|
Developer sakit pada saat pengerjaan proyek
|
-
Peningkatan otoritas project manager
-
Pengaturan waktu seefektif mungkin
|