Manajemen Resiko dalam Proyek Pengembangan Perangkat Lunak
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.
Manajemen resiko tradisional terfokus pada resiko-resiko yang timbul oleh
penyebab fisik atau legal (seperti bencana alam atau kebakaran, kematian serta
tuntutan hukum).
Manajemen
resiko adalah rangkaian langkah-langkah yang membantu suatu perangkat lunak
untuk memahami dan mengatur ketidak pastian (Roger S. Pressman).
Pada saat kita mengerjakan pengembangan
perangkat lunak sering kita menghadapi berbagai situasi yang tidak nyaman
seperti keterlambatan pengembangan atau pengeluaran biaya pengembangan yang
melebihi anggaran. Hal ini dikarenakan kurang siapnya kita menghadapi berbagai
kemungkinan resiko yang akan terjadi. Untuk itu perlu dilakukan identifikasi
tindakan yang harus dilakukan untuk mencegah ataupun meminimalkan resiko
tersebut.
Mengapa
manajemen resiko itu penting? Sikap orang ketika menghadapi resiko
berbeda-beda. Ada orang yang berusaha untuk menghindari resiko, namun ada juga
yang sebaliknya sangat senang menghadapi resiko sementara yang lain mungkin
tidak terpengaruh dengan adanya resiko. Pemahaman atas sikap orang terhadap
resiko ini dapat membantu untuk mengerti betapa resiko itu penting untuk
ditangani dengan baik.
Beberapa resiko lebih penting dibandingkan
resiko lainnya. Baik penting maupun tidak sebuah resiko tertentu bergantung
pada sifat resiko tersebut, pengaruhnya pada aktifitas tertentu dan kekritisan
aktifitas tersebut. Aktifitas beresiko tinggi pada jalur kritis pengembangan
biasanya merupakan penyebabnya.
Untuk
mengurangi bahaya tersebut maka harus ada jaminan untuk meminimalkan resiko
atau paling tidak mendistribusikannya selama pengembangan tersebut dan idealnya
resiko tersebut dihapus dari aktifitas yang mempunyai jalur yang kritis.
Resiko
dari sebuah aktifitas yang sedang berlangsung sebagian bergantung pada siapa
yang mengerjakan atau siapa yang mengelola aktifitas tersebut. Evaluasi resiko
dan alokasi staf dan sumber daya lainnya erat kaitannya.
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
Contoh : Seorang programmer yang sangat pintar
keluar. Resiko yang mana?
Langkah-langkah
dalam manajemen proses adalah :
- Identifikasi resiko
Proses ini meliputi identifikasi resiko yang
mungkin terjadi dalam suatu aktivitas usaha. Identifikasi resiko secara akurat
dan komplit sangatlah vital dalam manajemen resiko. Salah satu aspek penting
dalam identifikasi resiko adalah mendaftar resiko yang mungkin terjadi sebanyak
mungkin. Teknik-teknik yang dapat digunakan dalam identifikasi resiko antara
lain:
- Brainstorming
- Survei
- Wawancara
- Informasi histori
- Kelompok kerja
Tipe-tipe resiko:
Untuk keperluan identifikasi dan mengelola
resiko yang dapat menyebabkan sebuah pengembangan melampaui batas waktu dan
biaya yang sudah dialokasikan maka perlu diidentifikasikan tiga tipe resiko
yang ada yaitu:
- Resiko yang disebabkan karena kesulitan melakukan estimasi.
- Resiko yang disebabkan karena asumsi yang dibuat selama proses perencanaan.
- Resiko yang disebabkan adanya even yang tidak terlihat (atau tidak direncanakan).
Beberapa kategori faktor yang perlu
dipertimbangkan adalah sebagai berikut:
- Application Factor
Sesuatu yang alami dari aplikasi baik aplikasi
pengolahan data yang sederhana, sebuah sistem kritis yang aman maupun sistem
terdistribusi yang besar dengan elemen real time terlihat menjadi sebuah faktor
kritis. Ukuran yang diharapkan dari aplikasi juga sesuatu yang penting – sistem yang lebih besar, lebih besar dari masalah
error, komunikasi dan manajemennya.
- Staff Factor
Pengalaman dan kemampuan staf yang terlibat
merupakan faktor utama – seorang
programer yang berpengalaman, diharapkan akan sedikit melakukan kesalahan
dibandingkan dengan programer yang sedikit pengalamannya. Akan tetapi kita
harus juga mempertimbangkan ketepatan pengalaman tersebut- pengalaman membuat
modul dengan Cobol bisa mempunyai nilai kecil jika kita akan mengembangkan
sistem kendali real-time yang komplek dengan mempergunakan C++.
Beberapa
faktor seperti tingkat kepuasan staf dan tingkat pergantian dari staf juga
penting untuk keberhasilan sebarang pengembangan – staf yang tidak termotivasi
atau person utama keluar dapat menyebabkan kegagalan pengembangan.
- Project Factor
Merupakan hal yang
penting bahwa pengembangan dan obyektifnya terdefinisi dengan baik dan
diketahui secara jelas oleh semua anggota tim dan semua stakeholder utama. Jika
hal ini tidak terlaksana dapat muncul resiko yang berkaitan dengan keberhasilan
pengembangan tersebut. Dengan cara serupa, perencanaan kualitas yang formal dan
telah disepakati harus dipahami oleh semua partisipan. Jika perencanaan
kualitas kurang baik dan tidak tersosialisasi maka dapat mengakibatkan
gangguan pada pengembangan tersebut.
- Project Methods
Dengan mempergunakan
spefikasi dan metode terstruktur yang baik pada manajemen pengembangan dan
pengembangan sistem akan mengurangi resiko penyerahan sistem yang tidak
memuaskan atau terlambat. Akan tetapi penggunaan metode tersebut untuk pertama
kali dapat mengakibatkan problem dan delay.
- Hardware/software Factor
Sebuah pengembangan
yang memerlukan hardware baru untuk pengembangan mempunyai resiko yang lebih
tinggi dibandingkan dengan software yang dapat dibangun pada hardware
yang sudah ada (dan familiar). Sebuah sistem yang dikembangkan untuk satu jenis
hardware atau software platform tertentu jika dipergunakan pada hardware atau
software platform lainnya bisa menimbulkan resiko tambahan (dan tinggi) pada
saat instalasi.
- Changeover Factor
Kebutuhan perubahan
“all-in-one” kedalam suatu sistem baru mempunyai resiko tertentu. Perubahan
secara bertahap atau gradual akan meminimisasi resiko akan tetapi cara tersebut
tidak praktis. Menjalankan secara paralel dapat memberikan solusi yang aman
akan tetapi biasanya tidak mungkin atau terlalu mahal.
- Supplier Factor
Suatu pengembangan
yang melibatkan organisasi eksternal yang tidak dapat dikendalikan secara
langsung dapat mempengaruhi keberhasilan pengembangan. Misal
tertundanya instalasi jalur telpon atau pengiriman peralatan yang sulit
dihindari- dapat berpengaruh terhadap keberhasilan pengembangan.
- Environment Factor
Perubahan pada
lingkungan dapat mempengaruhi keberhasilan pengembangan. Misal terjadi
perubahan regulasi pajak, akan mempunyai dampak yang cukup serius pada
pengembangan aplikasi penggajian.
- Health and Safety Factor
Ada satu isu utama
yaitu faktor kesehatan dan keamanan dari partisipan yang terlibat dalam
pengembangan software walaupun tidak umum (dibandingkan dengan pengembangan
teknik sipil) yang dapat mempengaruhi aktifitas pengembangan.
Kesalahan estimasi
Beberapa pekerjaan lebih sulit untuk melakukan
estimasi dibandingkan pekerjaan lainnya disebabkan karena terbatasnya
pengalaman pada pekerjaan serupa atau disebabkan karena jenis pekerjaan
tersebut. Pembuatan sebuah user manual merupakan langkah yang tepat yang dapat
dipertanggungjawabkan dan sebagai bukti bahwa kita pernah mengerjakan tugas
yang serupa sebelumnya. Dengan pengalaman itu seharusnya kita mampu untuk
melakukan estimasi dengan lebih tepat mengenai berapa lama pekerjaan dapat
diselesaikan dan berapa besarnya biaya yang dibutuhkan. Selain itu, waktu yang
dibutuhkan untuk melakukan pengujian dan penelusuran program dapat menjadi
sesuatu hal yang sulit diprediksi dengan tingkat keakuratan yang serupa
walaupun kita pernah membuat program yang serupa sebelumnya.
Estimasi dapat ditingkatkan melalui analisa data
historis untuk aktifitas yang serupa dan untuk sistem yang serupa. Dengan
menyimpan perbandingan antara estimasi semula dengan hasil akhir akan
mengakibatkan beberapa tipe pekerjaan sulit diestimasi secara tepat.
Resiko ini terjadi jika perkiraan LOC pada
kenyataan yang ada jauh melebihi LOC perkiraan pada perhitungan COCOMO, yang
mengakibatkan berubahnya jadwal pengerjaan dan biaya operasional.
Asumsi perencanaan
Pada setiap tahapan perencanaan, asumsi perlu
dibuat, jika tidak benar maka dapat mengakibatkan resiko tersebut beresiko.
Misal pada jaringan aktifitas, aktifitas dibangun berdasarkan pada asumsi
menggunakan metode desain tertentu dimana memungkinkan urutan aktifitas diubah.
Kita biasanya membuat asumsi bahwa setelah coding, biasanya sebuah modul akan
diuji dan kemudian diintegrasikan dengan modul lainnya. Akan tetapi kita tidak
merencanakan pengujian modul yang dapat mangakibatkan perubahan desain awal.
Hal ini dapat terjadi setiap saat.
Pada setiap tahapan pada proses perencanaan,
sangat penting untuk memeperinci secara eksplisit semua asumsi yang dibuat dan
mengidentifikasi apa pengaruhnya jika ternyata dalam pelaksanaannya tidak
sesuai dengan yang sudah direncanakan.
Kemungkinan
Beberapa kemungkinan dapat saja tidak pernah
terlihat dan kita hanya dapat menyakinkan diri kita sendiri bahwa ada sesuatu
yang tidak dapat dibayangkan, kadang-kadang dapat terjadi. Akan tetapi biasanya
jarang terjadi hal seperti itu. Mayoritas kejadian yang tidak diharapkan
biasanya dapat diidentifikasi beberapa spesifikasi kebutuhan kemungkinan diubah
setelah beberapa modul telah dikodekan, programmer senior meninggalkan
pengembangan, perangkat keras yang diperlukan tidak dikirim tapat waktu.
Beberapa kejadian semacam itu dapat terjadi sewaktu-waktu dan walaupun kejadian
tersebut kemungkinan terjadinya relatif rendah akan tetapi kejadian tersebut
perlu dipertimbangkan dan direncanakan.
Metode untuk evaluasi pengaruh ketidakpastian
ini terhadap jadwal proyek:
- Penggunaan PERT untuk evaluasi pengaruh ketidakpastian
PERT dikembangkan untuk menghitung estimasi
ketidakpastian lingkungan terhadap durasi pekerjaan. PERT dikembangkan pada
suatu lingkungan proyek yang mahal, beresiko tinggi dan kompleks. Metode PERT
ini memerlukan tiga estimasi:
-
Most likely
time
Waktu yang diperlukan untuk
menyelesaikan pekerjaan dalam situasi normal dan diberikan simbol m.
-
Optimistic time
Waktu tersingkat yang
diperlukan untuk menyelesaikan pekerjaan dan diberi simbol a.
-
Pessimistic
time
Waktu terlama yang diperlukan
untuk menyelesaikan pekerjaan dikarenakan berbagai kemungkinan yang masuk akal
dan diberikan simbol b.
PERT mengkombinasikan ketiga estimasi tersebut
untuk membentuk durasi tunggal yang diharapkan, te = a + 4m + b
- Penggunaan durasi yang diharapkan
Durasi yang diharapkan
dipergunakan supaya suatu forward pass dapat melalui sebuah jaringan; dengan
mempergunakan metode yang sama dengan teknik CPM. Akan tetapi dalam hal ini,
tanggal aktifitas yang dihitung bukan merupakan tanggal paling awal akan tetapi
merupakan tanggal yang diharapkan dapat mencapai aktifitas tersebut.
Jaringan PERT yang
diperlihatkan pada gambar 3 memperlihatkan bahwa kita berharap proyek tersebut
dapat diselesaikan dalam waktu 13,5 minggu- tidak seperti CPM yang tidak
memperlihatkan tanggal paling awal untuk menyelesaikan proyek tersebut akan
tetapi tanggal yang diharapkan (atau most likely). Salah satu keuntungan dari
pendekatan ini adalah menempatkan sebuah emphasis dalam ketidakpastian di dunia
nyata.
Tabel 6.3 berikut ini
memperlihatkan contoh estimasi durasi aktifitas yang memperkirakan durasi
secara optimistic(a), pessimistic(b) dan most likeliy(m).
Tabel
6.3 – Estimasi waktu aktifitas PERT
Aktifitas
|
Durasi Aktifitas
(minggu)
|
||
Optimistic (a)
|
Most Likely (m)
|
Pessimistic (b)
|
|
A
|
5
|
6
|
8
|
B
|
3
|
4
|
5
|
C
|
2
|
3
|
3
|
D
|
3.5
|
4
|
5
|
E
|
1
|
3
|
4
|
F
|
8
|
10
|
15
|
G
|
2
|
3
|
4
|
H
|
2
|
2
|
2.5
|
Pendekatan PERT juga
difokuskan pada ketidakpastian estimasi durasi aktifitas. Perlu tiga estimasi
untuk masing-masing aktifitas yang memperlihatkan fakta bahwa kita tidak yakin
dengan apa yang akan terjadi – kita dipaksa untuk menghitung fakta yang
diperkirakan akan terjadi.
- Deviasi stándar aktifitas
Perhitungan
kuantitatif tingkat ketidakpastian suatu estimasi durasi aktifitas bisa
diperoleh dengan menghitung standar deviasi s dari sebuah durasi aktifitas
dengan mempergunakan rumus:
Standar deviasi
aktifitas porporsional dengan beda antara estimasi optimistic dan pessimistic,
dan dapat dipergunakan sebagai tingkatan ukuran level ketidakpastian atau
resiko masing-masing aktifitas. Durasi yang diharapkan dari masing-masing
aktifitas dan standar deviasi dari proyek tersebut (tabel 3) dapat dilihat pada
tabel 4.
Tabel
6.4- Waktu yang diharapkan dan
standar deviasi
Aktifitas
|
Durasi Aktifitas
(minggu)
|
|||||
A
|
m
|
b
|
te
|
s
|
||
A
|
5
|
6
|
8
|
6.17
|
0.50
|
|
B
|
3
|
4
|
5
|
4.00
|
0.33
|
|
C
|
2
|
3
|
3
|
2.83
|
0.17
|
|
D
|
3.5
|
4
|
5
|
4.08
|
0.25
|
|
E
|
1
|
3
|
4
|
2.83
|
0.50
|
|
F
|
8
|
10
|
15
|
10.50
|
1.17
|
|
G
|
2
|
3
|
4
|
3.00
|
0.33
|
|
H
|
2
|
2
|
2.5
|
2.08
|
0.08
|
|
a: optimistic b: most
likely c: pessimistic
te:
expected s: standard deviation
- Likehood target terpenuhi
Keuntungan utama dari
teknik PERT adalah memberikan suatu metode untuk melakukan estimasi
probabilitas tanggal target terpenuhi atau tidak. Teknik ini bisa saja hanya
mempunyai tanggal target tunggal yaitu proyek selesai, akan tetapi kita
diharapkan untuk mengatur tambahan target antara. Misalkan kita harus
menyelesaikan proyek dalam waktu 15 minggu. Kita berharap proyek tersebut dapat
diselesaikan dalam waktu 13.5 minggu akan tetapi durasinya bisa lebih dan bisa
kurang. Misalkan aktifitas C harus diselesaikan pada minggu ke 10 karena salah
satu anggota yang melaksanakan aktifitas tersebut sudah dijadwalkan untuk
bekerja pada proyek lain dan kejadian 5 memperlihatkan penyerahan produk kepada
pelanggan. Untuk itu diperlukan tiga tanggal target pada jaringan PERT seperti
yang diperlihatkan dalam gambar 4.
- Analisa resiko
Setelah
melakukan identifikasi resiko, maka tahap berikutnya adalah pengukuran resiko
dengan cara melihat potensial terjadinya seberapa besar severity (kerusakan)
dan probabilitas terjadinya risiko tersebut. 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 seperti yang disarankan oleh JISC
InfoNet:
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).
Probabilitas terjadinya resiko sering disebut dengan risk likelihood;
sedangkan dampak yang akan terjadi jika resiko tersebut terjadi dikenal
dengan risk impact dan tingkat kepentingan resiko disebut dengan risk
value atau risk exposure. Risk value dapat dihitung dengan formula :
Risk
exposure = risk likelihood x risk impact
Idealnya risk impact
diestimasi dalam batas moneter dan likelihood dievaluasi sebagai sebuah
probabilitas. Dalam hal ini risk exposure akan menyatakan besarnya biaya yang
diperlukan berdasarkan perhitungan analisis biaya manfaat. Risk exposure untuk
berbagai resiko dapat dibandingkan antara satu dengan lainnya untuk mengetahui
tingkat kepentingan masing-masing resiko.
Akan tetapi, estimasi
biaya dan probabilitas tersebut sulit dihitung, subyektif, menghabiskan waktu
dan biaya. Untuk mengatasi hal ini maka diperlukan beberapa pengukuran yang
kuantitatif untuk menilai risk likelihood dan risk impact, karena tanpa ini
sulit untuk membandingkan atau meranking resiko tersebut untuk berbagai
keperluan. Akan tetapi, usaha yang dilakukan untuk medapatkan sebuah estimasi kuantitatif
yang baik akan menghasilkan pemahaman yang mendalam dan bermanfaat atas
terjadinya suatu permasalahan.
Beberapa manajer
resiko mempergunakan sebuah metode penilaian yang sederhana untuk menghasilkan
ukuran yang kuantitatif pada saat mengevaluasi masing-masing resiko. Beberapa
manajer memberikan kategori pada likelihood dan impact dengan high, medium atau
low. Akan tetapi bentuk ini tidak memungkinkan untuk menghitung risk exposure.
Sebuah pendekatan yang lebih baik dan populer adalah memberikan skor pada
likelihood dan impact dengan skala tertentu misal 1-10. Jika suatu resiko
kemungkinan besar akan terjadi diberi skor 10, sedangkan jika kecil jika
kemungkinan terjadinya kecil maka akan diberi nilai 1.
Penilaian likelihood
dan impact dengan skala 1-10 relatif mudah, akan tetapi kebanyakan manajer
resiko akan berusaha untuk memberikan skor yang lebih bermakna, misal skor
likelihood 8 akan dipertimbangkan dua kali likelihood dengan skor 4.
Hasil
pengukuran impact, dapat diukur dengan skor yang serupa, harus dimasukkan
pada perhitungan total risk dari proyek tersebut. Untuk itu harus melibatkan
beberapa biaya potensial seperti :
Biaya yang diakibatkan keterlambatan penyerahan atas jadwal yang sudah
ditentukan
Biaya yang berlebihan dikarenakan harus menambah sumber daya atau
dikarenakan mempergunakan sumber daya yang lebih mahal
Biaya yang tidak terlihat pada beberapa komponen kualitas atau
fungsionalitas sistem
Tabel 6.1 berikut ini
memperlihatkan contoh hasil evaluasi nilai resiko. Perhatikan bahwa resiko yang
bernilai tertinggi tidak selalu akan menjadi resiko yang pasti terjadi
maupun akan menjadi resiko dengan potensi impact yang terbesar.
Tabel 6.1 –
Contoh evaluasi nilai risk exposure
Hazard
|
L
|
I
|
R
|
|
R1
|
Perubahan spesifikasi kebutuhan selama coding
|
1
|
8
|
8
|
R2
|
Spesifikasi perlu lebih lama
dibandingkan yang diperlukan
|
3
|
7
|
21
|
R3
|
Staf sakit yang berpengaruh pada aktifitas
yang kritis
|
5
|
7
|
35
|
R4
|
Staf sakit yang berpengaruh pada aktifitas
yang tidak kritis.
|
10
|
3
|
30
|
R5
|
Pengkodean modul lebih lama dibandingkan yang
diharapkan
|
4
|
5
|
20
|
R6
|
Pengujian modul memperlihatkan kesalahan atau
ketidakefisiensian dalam desain.
|
1
|
10
|
10
|
Prioritas resiko
Pengelolaan resiko
melibatkan penggunaan dua strategi:
Risk exposure dapat dikurangi dengan
mengurangi likehood atau impact
Pembuatan rencana kontingensi berkaitan dengan
kemungkinan resiko yang akan terjadi.
Sebarang
usaha untuk mengurangi sebuah risk exposure atau untuk melakukan sebuah rencana
kontigensi akan berhubungan dengan biaya yang berkaitan dengan usaha tersebut.
Merupakan hal yang penting untuk menjamin bahwa usaha ini dilaksanakan dengan
cara yang paling efektif dan diperlukan cara untuk memprioritaskan resiko
sehingga usaha yang lebih penting dapat menerima perhatian yang lebih besar.
Estimasi nilai likehood dan impact dari
masing-masing usaha tersebut akan menentukan nilai risk exposure. Setelah risk
exposure dapat dihitung maka resiko dapat diberi prioritas high, medium atau
low sesuai dengan besar kecilnya nilai risk exposure.
Risk exposure yang berdasarkan pada metode
penilaian perlu diberikan beberapa perhatian. Hasil evaluasi pada tabel 1,
contoh, tidak memperlihatkan resiko R5 adalah dua kali lebih penting
dibandingkan R6. Pada kasus ini, kita tidak bias mengintepretasikan nilai risk
exposure secara kuantitatif disebabkan nilai tersebut didasarkan pada metode
penilaian yang non-cardinal. Pada kasus kedua, nilai exposure yang terlalu
berjauhan akan mampu untuk membedakan antara resiko tersebut. Akan tetapi risk
exposure akan memungkinkan kita untuk memperoleh suatu ranking sesuai dengan
kepentingannya. Pertimbangkan resiko pada tabel 1, R3 dan R4 merupakan resiko
yang paling penting dan kita dapat mengklasifikasikannya dengan high risk.
Tingkat kepentingan yang berbeda dapat membedakan antara skor exposure satu dan
dua ini dengan exposure tertinggi berikutnya yaitu R2. R2 dan R5 mempunyai skor
yang hampir sama dan dapat dikelompokkan pada resiko dengan prioritas medium.
Dua resiko lainnya, R1 dan R6 mempunyai nilai exposure yang rendah sehingga
dapat dikelompokan pada prioritas rendah.
Dalam kenyataannya, secara umum ada beberapa
factor lain, selain nilai risk exposure, yang harus diperhitungkan pada saat
menentukan prioritas resiko.
Kepercayaan terhadap penilaian resiko
Beberapa penilaian risk exposure relative
kurang. Untuk diperlukan investigasi lebih lanjut sebelum tindakan diambil.
Penggabungan resiko
Beberapa resiko saling bergantung dengan
lainnya. Dalam hal ini maka beberapa resiko tersebut perlu dianggap sebagai
satu resiko.
Jumlah resiko
Perlu batas jumlah resiko yang dapat
dipertimbangkan secara efektif dan dapat diambil tindakannya oleh seorang
manajer proyek. Untuk itu perlu dibatasi ukuran daftar prioritas.
Biaya tindakan
Beberapa resiko, yang suatu saat dapat
dikenali, dapat dikurangi atau dicegah segera dengan biaya atau usaha yang
sedikit tanpa menganggap nilai resikonya. Untuk resiko lainnya perlu dilakukan
perbandingan antara biaya yang diperlukan dengan benefit yang diperoleh dengan
mengurangi resiko tersebut. Satu metode untuk melaksanakan perhitungan ini
adalah dengan menghitung risk reduction leverage (RRL) dengan mempergunakan
persamaan sebagai berikut:
RRL = REbefore
- REafter
Risk reduction cost
REbefore
adalah nilai risk exposure semula, REafter adalah nilai risk
exposure yang diharapkan setelah diambil tindakan dan risk education cost
adalah biaya untuk implementasi tindakan pengurangan resiko. Risk reduction
cost harus dinyatakan dengan unit yang sama dengan nilai resiko yaitu nilai
moneter yang diperlukan atau dengan nilai skor. Jika nilai yang diharapkan
ternyata lebih besar maka RRL yang lebih besar memperlihatkan bahwa kita perlu
berharap untuk meningkatkan rencana pengurangan resiko disebabkan reduksi risk
exposure yang diharapkan lebih besar dibandingkan dengan biaya rencana.
- Pengelolaan resiko
Jenis-jenis cara mengelola resiko :
a. 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.
b. 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.
c.
Risk Transfer
Yaitu memindahkan resiko pada pihak lain,
umumnya melalui suatu kontrak (asuransi) maupun hedging.
d. Risk Deferral
Dampak suatu resiko tidak selalu konstan. Risk deferral meliputi menunda aspek
suatu proyek hingga saat dimana probabilitas terjadinya resiko tersebut kecil.
e. 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:
a. High probability, high impact: resiko jenis
ini umumnya dihindari ataupun ditransfer.
b. 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.
c.
High probability, low impact: mitigasi resiko
dan kembangkan contingency plan.
d. 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 antara contingency 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
|
- Implementasi manajemen resiko
Setelah memilih respon yang akan digunakan
untuk menangani resiko, maka saatnya untuk mengimplementasikan metode yang
telah direncanakan tersebut.
- Monitoring resiko
Mengidentifikasi, menganalisa dan merencanakan
suatu resiko merupakan bagian penting dalam perencanaan suatu proyek. Namun,
manajemen resiko tidaklah berhenti sampai disana saja. Praktek, pengalaman dan
terjadinya kerugian akan membutuhkan suatu perubahan dalam rencana dan
keputusan mengenai penanganan suatu resiko. Sangatlah penting untuk selalu
memonitor proses dari awal mulai dari identifikasi resiko dan pengukuran resiko
untuk mengetahui keefektifitas respon yang telah dipilih dan untuk
mengidentifikasi adanya resiko yang baru maupun berubah. Sehingga, ketika suatu
resiko terjadi maka respon yang dipilih akan sesuai dan diimplementasikan
secara efektif.
0 Feed back:
Post a Comment