MANAJEMEN RESIKO 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 hokum). (Wikipedia) Manajemen resiko adalah rangkaian langkah-langkah yang membantu suatu perangkat lunak untuk memahami dan mengatur ketidak pastian (Roger S. ressman). ada saat kita mengerjakan pengembangan perangkat lunak sering kita menghadapi berbagai situasi yang tidak nyaman seperti keterlambatan pengembangan atau pengeluaran biaya pengembangan yang melebihi anggaran. !al ini dikarenakan kurang siapnya kita menghadapi berbagai kemungkinan resiko yang akan terjadi. "ntuk 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. $da orang yang berusaha untuk menghindari resiko, namun ada juga yang sebaliknya sangat senang menghadapi resiko sementara yang lain mungkin tidak terpengaruh dengan adanya resiko. itu penting untuk ditangani dengan baik. %eberapa resiko lebih penting dibandingkan resiko lainnya. %aik penting maupun tidak sebuah resiko tertentu bergantung pada sifat resiko tersebut, pengaruhnya pada aktifitas tertentu dan kekritisan aktifitas tersebut. $ktifitas beresiko tinggi pada jalur kritis pengembangan biasanya merupakan penyebabnya. "ntuk mengurangi bahaya tersebut maka harus ada jaminan untuk meminimalkan resiko atau paling tidak mendistribusikannya selama emahaman atas sikap orang terhadap resiko ini dapat membantu untuk mengerti betapa resiko

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. &'aluasi resiko dan alokasi staf dan sumber daya lainnya erat kaitannya. Resiko dalam perangkat lunak memiliki dua karakteristik( "ncertainty ( tidak ada resiko yang )**+ pasti muncul. ,oss ( resiko berimbas pada kehilangan. Resiko proyek ( berefek pada perencanaan proyek. Resiko teknikal ( berefek pada kualitas dan .aktu pembuatan perangkat lunak. Resiko bisnis ( berefek pada nilai jual produk /ontoh ( Seorang programmer yang sangat pintar keluar. Resiko yang mana#

-an resiko memiliki tiga kategori(

% 0 $ 3 $ /ost 4f $'ersion

1otal %iaya

&5pected ,osses from the risk

Resiko 1ingkat 4ptimal

1ingkat Resiko

,angkah-langkah dalam manajemen proses adalah ( ). 0dentifikasi resiko roses ini meliputi identifikasi resiko yang mungkin terjadi dalam suatu akti'itas usaha. 0dentifikasi resiko secara akurat dan komplit sangatlah 'ital dalam manajemen resiko. Salah satu aspek penting dalam identifikasi resiko adalah mendaftar resiko yang mungkin terjadi sebanyak "ntuk mungkin. 1eknik-teknik yang dapat digunakan dalam identifikasi resiko antara lain( %rainstorming Sur'ei Wa.ancara 0nformasi histori 2elompok kerja keperluan identifikasi dan mengelola resiko yang dapat

1ipe-tipe resiko( menyebabkan sebuah pengembangan melampaui batas .aktu 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 e'en yang tidak terlihat (atau tidak direncanakan). %eberapa 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. "kuran yang diharapkan dari aplikasi juga sesuatu yang penting 6 sistem yang lebih besar, lebih besar dari masalah error, komunikasi dan manajemennya. Staff Factor engalaman dan kemampuan staf yang terlibat merupakan faktor utama 6 seorang programer yang berpengalaman, diharapkan akan sedikit melakukan kesalahan dibandingkan dengan programer yang sedikit pengalamannya. $kan tetapi kita harus juga mempertimbangkan ketepatan pengalaman tersebut- pengalaman membuat modul dengan /obol bisa mempunyai nilai kecil jika kita akan mengembangkan sistem kendali real-time yang komplek dengan mempergunakan /77. %eberapa faktor seperti tingkat kepuasan staf dan tingkat pergantian dari staf juga penting untuk keberhasilan sebarang pengembangan 6 staf yang tidak termoti'asi atau person utama keluar dapat menyebabkan kegagalan pengembangan.

Project Factor Merupakan hal yang penting bah.a pengembangan dan obyektifnya terdefinisi dengan baik dan diketahui secara jelas oleh semua anggota tim dan semua stakeholder utama. 8ika hal ini tidak terlaksana dapat muncul resiko yang berkaitan dengan keberhasilan pengembangan tersebut. -engan cara serupa, perencanaan kualitas yang formal dan telah disepakati harus dipahami oleh semua partisipan. 8ika perencanaan kualitas kurang baik dan tidak tersosialisasi maka dapat mengakibatkan gangguan pada pengembangan tersebut.

Project Methods -engan mempergunakan spefikasi dan metode terstruktur yang baik pada manajemen pengembangan dan pengembangan sistem akan mengurangi resiko penyerahan sistem yang tidak memuaskan atau terlambat. $kan tetapi penggunaan metode tersebut untuk pertama kali dapat mengakibatkan problem dan delay.

Hardware/software Factor Sebuah pengembangan yang memerlukan hard.are baru untuk pengembangan mempunyai resiko yang lebih tinggi dibandingkan dengan soft.are yang dapat dibangun pada hard.are yang sudah ada (dan familiar). Sebuah sistem yang dikembangkan untuk satu jenis hard.are atau soft.are platform tertentu jika dipergunakan pada hard.are atau soft.are platform lainnya bisa menimbulkan resiko tambahan (dan tinggi) pada saat instalasi.

Changeover Factor 2ebutuhan perubahan 9all-in-one: kedalam suatu sistem baru mempunyai resiko tertentu. erubahan 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 erubahan 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 $da satu isu utama yaitu faktor kesehatan dan keamanan dari partisipan yang terlibat dalam pengembangan soft.are .alaupun tidak umum (dibandingkan dengan pengembangan teknik sipil) yang dapat mempengaruhi aktifitas pengembangan. 2esalahan estimasi %eberapa pekerjaan lebih sulit untuk melakukan estimasi dibandingkan pekerjaan lainnya disebabkan karena terbatasnya pengalaman pada pekerjaan serupa atau disebabkan karena jenis pekerjaan tersebut. embuatan sebuah user manual merupakan langkah yang tepat yang dapat dipertanggungja.abkan dan sebagai bukti bah.a kita pernah mengerjakan tugas yang serupa sebelumnya. -engan 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, .aktu yang dibutuhkan untuk melakukan pengujian dan penelusuran program dapat menjadi

sesuatu hal yang sulit diprediksi dengan tingkat keakuratan yang serupa .alaupun kita pernah membuat program yang serupa sebelumnya. &stimasi dapat ditingkatkan melalui analisa data historis untuk aktifitas yang serupa dan untuk sistem yang serupa. -engan menyimpan perbandingan antara estimasi semula dengan hasil akhir akan mengakibatkan beberapa tipe pekerjaan sulit diestimasi secara tepat. Resiko ini terjadi jika perkiraan ,4/ pada kenyataan yang ada jauh melebihi ,4/ perkiraan pada perhitungan /4/4M4, yang mengakibatkan berubahnya jad.al pengerjaan dan biaya operasional. $sumsi perencanaan ada 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. 2ita biasanya membuat asumsi bah.a setelah coding, biasanya sebuah modul akan diuji dan kemudian diintegrasikan dengan modul lainnya. $kan tetapi kita tidak merencanakan pengujian modul yang dapat mangakibatkan perubahan desain a.al. !al ini dapat terjadi setiap saat. ada 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. 2emungkinan %eberapa kemungkinan dapat saja tidak pernah terlihat dan kita hanya dapat menyakinkan diri kita sendiri bah.a ada sesuatu yang tidak dapat dibayangkan, kadang-kadang dapat terjadi. $kan tetapi biasanya jarang terjadi hal seperti itu. Mayoritas kejadian yang tidak diharapkan biasanya dapat diidentifikasi setelah beberapa beberapa spesifikasi telah kebutuhan dikodekan, kemungkinan diubah modul

programmer senior meninggalkan pengembangan, perangkat keras yang diperlukan tidak dikirim tapat .aktu. %eberapa kejadian semacam itu

dapat

terjadi

se.aktu-.aktu

dan

.alaupun

kejadian

tersebut

kemungkinan terjadinya relatif rendah akan tetapi kejadian tersebut perlu dipertimbangkan dan direncanakan. Metode untuk e'aluasi pengaruh ketidakpastian ini terhadap jad.al proyek( enggunaan &R1 untuk e'aluasi pengaruh ketidakpastian &R1 dikembangkan untuk menghitung estimasi ketidakpastian lingkungan terhadap durasi pekerjaan. &R1 dikembangkan pada suatu lingkungan proyek yang mahal, beresiko tinggi dan kompleks. Metode &R1 ini memerlukan tiga estimasi( Most likely time Waktu yang diperlukan untuk menyelesaikan pekerjaan dalam situasi normal dan diberikan simbol m. 4ptimistic time Waktu tersingkat yang diperlukan untuk menyelesaikan pekerjaan dan diberi simbol a. essimistic time Waktu terlama yang diperlukan untuk menyelesaikan pekerjaan dikarenakan berbagai kemungkinan yang masuk akal dan diberikan simbol b. &R1 mengkombinasikan ketiga estimasi tersebut untuk membentuk durasi tunggal yang diharapkan, te ; a 7 <m 7 b enggunaan durasi yang diharapkan -urasi yang diharapkan dipergunakan supaya suatu for.ard pass dapat melalui sebuah jaringan= dengan mempergunakan metode yang sama dengan teknik / M. $kan tetapi dalam hal ini, tanggal aktifitas yang dihitung bukan merupakan tanggal paling a.al akan tetapi merupakan tanggal yang diharapkan dapat mencapai aktifitas tersebut.

8aringan &R1 yang diperlihatkan pada gambar > memperlihatkan bah.a kita berharap proyek tersebut dapat diselesaikan dalam .aktu )>,? minggu- tidak seperti / M yang tidak memperlihatkan tanggal paling a.al 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. 1abel @.> 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 !st "ikel# Pessimistic (b) (a) $ 3 ) 3.$ * % ) ) (m) 6 ' 3 ' 3 *, 3 ) % $ 3 $ ' *$ ' ).$

A & ( D E + .
endekatan

&R1 juga difokuskan pada ketidakpastian estimasi

durasi aktifitas. erlu tiga estimasi untuk masing-masing aktifitas yang memperlihatkan fakta bah.a kita tidak yakin dengan apa

yang akan terjadi 6 kita dipaksa untuk menghitung fakta yang diperkirakan akan terjadi.

-e'iasi stAndar aktifitas erhitungan kuantitatif tingkat ketidakpastian suatu estimasi durasi aktifitas bisa diperoleh dengan menghitung standar de'iasi s dari sebuah durasi aktifitas dengan mempergunakan rumus(

Standar de'iasi aktifitas porporsional dengan beda antara estimasi optimistic dan pessimistic, dan dapat dipergunakan sebagai tingkatan ukuran le'el ketidakpastian atau resiko masing-masing aktifitas. -urasi yang diharapkan dari masing-masing aktifitas dan

standar de'iasi dari proyek tersebut (tabel >) dapat dilihat pada tabel <.

Tabel 6.'/ 0aktu #ang 1i2arapkan 1an stan1ar 1e3iasi Durasi Aktifitas (minggu) A m b te s A $ 6 % 6.*4 ,.$, & 3 ' $ '.,, ,.33 ( ) 3 3 ).%3 ,.*4 D 3.$ ' $ '.,% ,.)$ E * 3 ' ).%3 ,.$, + % *, *$ *,.$, *.*4 ) 3 ' 3.,, ,.33 . ) ) ).$ ).,% ,.,% a5 !ptimistic b5 m!st likel# c5 pessimistic te5 e6pecte1 s5 stan1ar1 1e3iati!n Aktifitas

,ikehood target terpenuhi 2euntungan utama dari teknik &R1 adalah memberikan suatu

metode untuk melakukan estimasi probabilitas tanggal target terpenuhi atau tidak. 1eknik 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 .aktu )? minggu. 2ita berharap proyek tersebut dapat diselesaikan dalam .aktu )>.? minggu akan tetapi durasinya bisa lebih dan bisa kurang. Misalkan

aktifitas / harus diselesaikan pada minggu ke )* karena salah satu anggota yang melaksanakan aktifitas tersebut sudah dijad.alkan untuk bekerja pada proyek lain dan kejadian ? memperlihatkan penyerahan produk kepada pelanggan. "ntuk itu diperlukan tiga tanggal target pada jaringan dalam gambar <. &R1 seperti yang diperlihatkan

Bambar @.< 8aringan &R1 dengan tiga buah tanggal target dan perhitungan standar de'iasi kejadian C. $nalisa resiko Setelah melakukan identifikasi resiko, maka tahap berikutnya adalah pengukuran resiko dengan cara melihat potensial terjadinya seberapa besar se'erity (kerusakan) dan probabilitas terjadinya risiko tersebut.

enentuan probabilitas terjadinya suatu e'ent sangatlah subyektif dan lebih berdasarkan nalar dan pengalaman. %eberapa 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. 2esulitan dalam pengukuran risiko adalah menentukan kemungkinan terjadi suatu risiko karena informasi statistik tidak selalu tersedia untuk beberapa risiko tertentu. Selain itu, menge'aluasi dampak se'erity (kerusakan) seringkali cukup sulit untuk asset immateriil. -ampak adalah efek biaya, .aktu dan kualitas yang dihasilkan suatu resiko.
Dampak Sangat rendah Biaya -ana mencukupi $gak Waktu menyimpang Kualitas 2ualitas berkurang masih Rendah Membutuhkan tambahan Sedang Membutuhkan tambahan 1inggi Membutuhkan tambahan Sangat tinggi signifikan Membutuhkan tambahan substansial dana yang dana yang dana dana $gak menyimpang digunakan Bagal agak namun dapat untuk

dari target

dari target enundaan berdampak terhadap stakeholder Bagal memenuhi deadline enundaan proyek merusak

memenuhi janji pada stakeholder %eberapa fungsi tidak dapat dimanfaatkan Bagal untuk

memenuhi kebutuhan banyak stakeholder royek tidak efektif dan tidak berguna

Setelah mengetahui probabilitas dan dampak dari suatu resiko, maka kita dapat mengetahui potensi suatu resiko. "ntuk mengukur bobot resiko kita dapat menggunakan skala dari ) 6 ? sebagai berikut seperti yang disarankan oleh 80S/ 0nfoDet(
Skala Sangat rendah Probabilitas !ampir tidak mungkin terjadi Dampak -ampak kecil

Rendah Sedang 1inggi Sangat tinggi

2adang terjadi Mungkin tidak terjadi Sangat mungkin terjadi !ampir pasti terjadi

-ampak kecill pada biaya, .aktu dan kualitas -ampak sedang pada biaya, .aktu dan kualitas -ampak substansial pada

biaya, .aktu dan kualitas Mengancam kesuksesan proyek

Setelah resiko yang dapat mempengaruhi pengembangan teridentifikasi maka diperlukan cara untuk menentukan tingkat kepentingan dari masing-masing resiko. %eberapa resiko secara relatif tidak terlalu fatal (misal resiko keterlambatan penyerahan dokumentasi) sedangkan beberapa resiko lainnya berdampak besar. (misal resiko keterlambatan penyerahan soft.are). %eberapa 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). robabilitas terjadinya resiko sering disebut dengan ris li elihood= sedangkan dampak yang akan terjadi jika resiko tersebut terjadi dikenal dengan ris dengan formula ( impact dan tingkat kepentingan resiko disebut dengan ris value atau ris e!posure" Risk 'alue dapat dihitung

Risk e6p!sure 7 risk likeli2!!1 6 risk impact

0dealnya risk impact diestimasi dalam batas moneter dan likelihood die'aluasi sebagai sebuah probabilitas. -alam hal ini risk e5posure akan menyatakan besarnya biaya yang diperlukan berdasarkan perhitungan analisis biaya manfaat. Risk e5posure untuk berbagai resiko dapat dibandingkan antara satu dengan lainnya untuk mengetahui tingkat kepentingan masing-masing resiko. $kan tetapi, estimasi biaya dan probabilitas tersebut sulit dihitung, subyektif, menghabiskan .aktu dan biaya. "ntuk 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. $kan tetapi, usaha yang dilakukan untuk medapatkan sebuah estimasi kuantitatif yang baik akan menghasilkan pemahaman yang mendalam dan bermanfaat atas terjadinya suatu permasalahan.

%eberapa manajer resiko mempergunakan sebuah metode penilaian yang sederhana untuk menghasilkan ukuran yang kuantitatif pada saat menge'aluasi masing-masing resiko. %eberapa manajer memberikan kategori pada likelihood dan impact dengan high, medium atau lo.. $kan tetapi bentuk ini tidak memungkinkan untuk menghitung risk e5posure. Sebuah pendekatan yang lebih baik dan populer adalah memberikan skor pada likelihood dan impact dengan skala tertentu misal )-)*. 8ika suatu resiko kemungkinan besar akan terjadi diberi skor )*, sedangkan jika kecil jika kemungkinan terjadinya kecil maka akan diberi nilai ). enilaian likelihood dan impact dengan skala )-)* relatif mudah, akan tetapi kebanyakan manajer resiko akan berusaha untuk memberikan skor yang lebih bermakna, misal skor likelihood E akan dipertimbangkan dua kali likelihood dengan skor <. !asil pengukuran impact, dapat diukur dengan skor yang serupa, harus dimasukkan pada perhitungan total risk dari proyek tersebut. "ntuk itu harus melibatkan beberapa biaya potensial seperti ( %iaya yang diakibatkan keterlambatan penyerahan atas jad.al yang sudah ditentukan %iaya yang berlebihan dikarenakan harus menambah sumber daya atau dikarenakan mempergunakan sumber daya yang lebih mahal %iaya yang tidak terlihat pada beberapa komponen kualitas atau fungsionalitas sistem

1abel @.) berikut ini memperlihatkan contoh hasil e'aluasi nilai resiko. erhatikan bah.a resiko yang bernilai tertinggi tidak selalu akan menjadi resiko yang pasti terjadi maupun akan menjadi resiko dengan potensi impact yang terbesar.

Tabel 6 ! " #o$to% e&aluasi $ilai risk e'posure

(a)ar* R) erubahan

+ spesifikasi ) >

I E F F > ?

R E C) >? >* C*

kebutuhan selama coding RC Spesifikasi perlu lebih lama

dibandingkan yang diperlukan R> Staf sakit yang berpengaruh ? pada aktifitas yang kritis R< Staf sakit yang berpengaruh )* pada aktifitas yang tidak kritis. R? engkodean modul lebih lama < dibandingkan yang diharapkan R@ engujian modul ) memperlihatkan kesalahan atau ketidakefisiensian desain. dalam

)* )*

rioritas resiko engelolaan resiko melibatkan penggunaan dua strategi( Risk e5posure dapat dikurangi dengan mengurangi likehood atau impact

embuatan rencana kontingensi berkaitan dengan kemungkinan resiko yang akan terjadi.

Sebarang usaha untuk mengurangi sebuah risk e5posure atau untuk melakukan sebuah rencana kontigensi akan berhubungan dengan biaya yang berkaitan dengan usaha tersebut. Merupakan hal yang penting untuk menjamin bah.a 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. &stimasi nilai likehood dan impact dari masing-masing usaha tersebut akan menentukan nilai risk e5posure. Setelah risk e5posure dapat dihitung maka resiko dapat diberi prioritas high, medium atau lo. sesuai dengan besar kecilnya nilai risk e5posure. Risk e5posure yang berdasarkan pada metode penilaian perlu diberikan beberapa perhatian. !asil e'aluasi pada tabel ), contoh, tidak memperlihatkan resiko R? adalah dua kali lebih penting dibandingkan R@. ada kasus ini, kita tidak bias mengintepretasikan nilai risk e5posure secara kuantitatif disebabkan nilai tersebut didasarkan pada metode penilaian yang non-cardinal. ada kasus kedua, nilai e5posure yang terlalu berjauhan akan mampu untuk membedakan antara resiko tersebut. $kan tetapi risk e5posure akan memungkinkan kita untuk memperoleh suatu ranking sesuai dengan kepentingannya. ertimbangkan resiko pada tabel ), R> dan R< merupakan resiko yang paling penting dan kita dapat mengklasifikasikannya dengan high risk. 1ingkat kepentingan yang berbeda dapat membedakan antara skor e5posure satu dan dua ini dengan e5posure tertinggi berikutnya yaitu RC. RC dan R? mempunyai skor yang hampir sama dan dapat dikelompokkan

pada resiko dengan prioritas medium. -ua resiko lainnya, R) dan R@ mempunyai nilai e5posure yang rendah sehingga dapat dikelompokan pada prioritas rendah. -alam kenyataannya, secara umum ada beberapa factor lain, selain nilai risk e5posure, yang harus diperhitungkan pada saat menentukan prioritas resiko. 2epercayaan terhadap penilaian resiko %eberapa penilaian risk e5posure relati'e kurang. "ntuk diperlukan in'estigasi lebih lanjut sebelum tindakan diambil. enggabungan resiko %eberapa resiko saling bergantung dengan lainnya. -alam hal ini maka beberapa resiko tersebut perlu dianggap sebagai satu resiko. 8umlah resiko erlu batas jumlah resiko yang dapat dipertimbangkan secara efektif dan dapat diambil tindakannya oleh seorang manajer proyek. "ntuk itu perlu dibatasi ukuran daftar prioritas. %iaya tindakan %eberapa resiko, yang suatu saat dapat dikenali, dapat dikurangi atau dicegah segera dengan biaya atau usaha yang sedikit tanpa menganggap nilai resikonya. "ntuk 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 le'erage (RR,) dengan mempergunakan persamaan sebagai berikut(

RR" 7 REbef!re / REafter

Risk reduction cost R&before adalah nilai risk e5posure semula, R& after adalah nilai risk e5posure 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. 8ika nilai yang diharapkan ternyata lebih besar maka RR, yang lebih besar memperlihatkan bah.a kita perlu berharap untuk meningkatkan rencana pengurangan resiko disebabkan reduksi risk e5posure yang diharapkan lebih besar dibandingkan dengan biaya rencana. >. engelolaan resiko 8enis-jenis cara mengelola resiko ( a. #is Avoidance 3aitu memutuskan untuk tidak melakukan akti'itas yang mengandung resiko sama sekali. -alam memutuskan untuk melakukannya, maka harus dipertimbangkan potensial keuntungan dan potensial kerugian yang dihasilkan oleh suatu akti'itas. b. #is #eduction #is reduction atau disebut juga ris mitigation yaitu merupakan metode yang mengurangi kemungkinan terjadinya suatu resiko ataupun mengurangi dampak kerusakan yang dihasilkan oleh suatu resiko. c. #is $ransfer 3aitu memindahkan resiko pada pihak lain, umumnya melalui suatu kontrak (asuransi) maupun hedging. d. #is %eferral -ampak suatu resiko tidak selalu konstan. #is terjadinya resiko tersebut kecil. deferral meliputi menunda aspek suatu proyek hingga saat dimana probabilitas

e. #is #etention Walaupun resiko tertentu dapat dihilangkan dengan cara mengurangi maupun mentransfernya, namun beberapa resiko harus tetap diterima sebagai bagian penting dari akti'itas. enanganan resiko( a. High pro&a&ility' high impact( resiko jenis ini umumnya dihindari ataupun ditransfer. b. )ow pro&a&ility' high impact( respon paling tepat untuk tipe resiko ini adalah dihindari. -an jika masih terjadi, maka lakukan mitigasi resiko serta kembangkan contingency plan" c. High pro&a&ility' low impact( mitigasi resiko dan kembangkan contingency plan" d. )ow pro&a&ility' low impact( efek dari resiko ini dapat dikurangi, namun biayanya dapat saja melebihi dampak yang dihasilkan. -alam kasus ini mungkin lebih baik untuk menerima efek dari resiko tersebut. Contigency plan "ntuk resiko yang mungkin terjadi maka perlu dipersiapkan contingency plan seandainya benar-benar terjadi. Contigency plan haruslah sesuai dengan proposional terhadap dampak resiko tersebut. -alam banyak kasus seringkali lebih efisien untuk mengalokasikan sejumlah sumber daya untuk mengurangi resiko dibandingkan mengembangkan contingency plan yang jika diimplementasikan akan lebih mahal. Damun beberapa skenario memang membutuhkan full contingency plan' tergantung pada proyeknya. Damun jangan sampai tertukar antara contingency planning dengan re-planning normal yang memang dibutuhkan karena adanya perubahan dalam proyek yang berjalan.

1abel resiko proyek soft.are dan strategi mengurangi resiko

Resiko 2egagalan pada personil Tek$ik me$,ura$,i resiko Memperkerjakan staf yang handal 8ob matching Membangun tim Mengadakan pelatihan dan peningkatan karir Membuat jad.al lebih a.al bagi personil &stimasi biaya dan .aktu yang tidak realistis utama Membuat beberapa estimasi -esain untuk biaya Meningkatkan pengembangan Merekam sebelumnya Mengembangkan fungsi Standarisasi metode &'aluasi proyek ditingkatkan %uat metode spesifikasi yang formal Sur'ey pengguna %uat prototype Mengembangkan antarmuka yang salah Bold plating pengguna %uat user manual lebih a.al Membuat prototype $nalisis tugas 2eterlibatan pengguna Mengurangi kebutuhan Membuat prototype $nalisis biaya manfaat 1erlambat untuk -esain biaya Mengubah prosedur kendali Membatasi perubahan yang terlalu banyak Meningkatkan prototype Meningkatkan 2egagalan pada pengembangan (akibat dan menganalisa proyek

soft.are yang salah

mengubah kebutuhan

perubahan) Melakukan benchmarking

komponen yang disuplai

pihak eksternal

0nspeksi Spesifikasi formal 2ontrak perjanjian

2egagalan

menjalankan

rosedur dan sertifikasi jaminan kualitas rosedur jaminan kualitas -esain G prototype yang kompetitif Membangun tim

tugas eksternal

2egagalan kinerja realtime

2ontrak insentif Simulasi %enchmarking rototipe 1uning

engembangnya sulit secara teknis

terlalu

$nalisis teknis $nalisa teknis $nalisis biaya manfaat rototipe Melatih dan mengembangkan staf

<. 0mplementasi 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 raktek, suatu merupakan bagian penting dalam perencanaan suatu proyek. Damun, manajemen resiko tidaklah berhenti sampai disana saja. pengalaman dan terjadinya kerugian akan membutuhkan

perubahan dalam rencana dan keputusan mengenai penanganan suatu resiko. Sangatlah penting untuk selalu memonitor proses dari a.al 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. "ntuk studi kasus saya mengambil dari .eb site

http(GG....sbl.tkk.fiGteachingGcoursesG1-)CE.?>**GarticlesG&secC**).pdf A$ I$*ustrial #ase Stu*y o- Impleme$ti$, So-t.are Risk Ma$a,eme$t ABSTRA#T &5plicit risk management is ga ining ground in industrial soft.are de'elopment projects. !o.e'er, there are fe. empirical studies that in'estigate the transfer of e5plicit risk management into industry, the adeHuacy of the risk management approaches to the constraints of industrial conte5ts, or their costbenefit. 1his paper presents results from a case study that introduced a systematic risk management method, namely the Riskit method, into a large Berman telecommunication company. 1he objecti'e of the case study .as ()) to analyIe the usefulness and ade*uacy of the #is it method and (C) to analyIe the cost+&enefit of the #is it method in this industrial conte5t. 1he results of ()) also aimed at impro'ement and customiIation of the Riskit method. Moreo'er, .e compare our findings .ith results of pre'ious case studies to obtain more generaliIed conclusions on the Riskit method. 4ur results sho.ed that the Riskit method is practical, adds 'alue to the project, and that its key concepts are understood and usable in practice. $dditionally, many lessons learned are reported that are useful for the general audience .ho .ants to transfer risk management into ne. projects. Key.or*s Risk Management, /ase Study, ,essons ,earned, Riskit Method ! INTROD/#TION Since the introduction of risk management into the mainstream of soft.are engineering JFKJ)CK, the soft.are industry has gradually become more acti'e in using e5plicit risk management J)>KJCCK. $lso, the increased reHuirements for risk management by many assessment standards ha'e increased corporate interest in risk management. Risk management practices ha'e become much more operational and practical, as many guidelines, te5tbooks J)<KJC*K, and consultants help organiIations impro'e their risk management practices. 3et, .hile industry is clearly using risk management techniHues more acti'ely, there are only fe. reports a'ailable on e5periences of introducing risk management into an organiIation. 1he reports that are a'ailable ha'e been conducted as informal case studies .ithout sufficient attempt to scientific rigor or empirical research methods J<KJLKJ))KJ)FKJCLK. !o.e'er, systematic

empirical in'estigations are necessary to learn more about the transfer and application of risk management methods. 1o contribute such a systematic empirical in'estigation, this paper presents a carefully designed case study on the implementation of a specific risk management method, namely the Riskit method, into the telecommunication company 1eno'is. 1he paper builds on a series of three case studies related to the Riskit method J)EKJC<KJCFK. 1he 'alue of replicated case studies of the same method in 'arying conte5ts allo.s us to generaliIe our findings .ith respect to Riskit in particular and risk management in general. $dditionally, replication in different conte5ts allo.s us to identify important conte5t factors affecting the success of the transfer and implementation of risk management. 1he objecti'es of the case study presented in this paper .ere t.ofold. 1he first objecti'e .as to characteriIe the usefulness and ade*uacy of the #is it ris management process from the 'ie.point of the ris management participants. 1his objecti'e aimed at identifying effecti'e .ays of introducing risk management at the company in Huestion and in general, and of pro'iding feedback for impro'ing the Riskit method. 1he second objecti'e .as to characteriIe the cost+&enefit of the #is it ris management process in the conte5t of $enovis. 1his objecti'e .as to in'estigate the economic impact of the Riskit method. 1he remainder of the paper is structured as follo.s. Section C describes the transferred risk management method. Sections > and < describe the project selected for this case study and the transfer of risk management into the project. Section ? describes the design of our case study. 1he results of this case study are presented and compared .ith the results of pre'ious case studies in Section @. %ased on these results, .e infer in Section F lessons learned that are rele'ant for the general community. Section E concludes the paper .ith a summary. 0 T(E RISK MANA1EMENT MET(OD 1he risk management method transferred in this case study is called Riskit. Riskit is a comprehensi'e risk management method that is based on sound theoretical principles, yet it has been designed to ha'e sufficiently lo. o'erhead and comple5ity so that it can be used in real, time-constrained projects. %ecause of its more solid theoretical foundations, it a'oids many of the limitations and problems that are common to many other risk management approaches in soft.are engineering, such as use of biased ranking tables and e5pected 'alue calculations. $s Riskit has been e5tensi'ely presented in other publications JC>KJC<KJC?KJC@KJCFK, .e present here only the principles of the method and the features that distinguish it from other risk management approaches. Riskit contains a fully defined process, .hose o'er'ie. is presented in Migure ) as a dataflo. diagram. 1he full definition of the Riskit process is a'ailable as a separate report JC?K.

1he Riskit process includes a specific step for analyIing stakeholder interests and ho. they link to risks. 1hese links are 'isualiIed in Migure C( .hen risks are defined, their impact on the project is described through the stated project goals. 1his allo.s full traceability bet.een risks and goals and on to stakeholders( each risk can be described by its potential impact on the agreed project goals, and each stakeholder can use this information to rank risks from his perspecti'e.

0n order to describe risks during Risk analysis, the Riskit method supports unambiguous definition of risks using the #is it analysis graph (also called risk scenario) as a 'isual formalism. 1he Riskit analysis graph can be seen both as a

conceptual template for defining risks as .ell as a .ell-defined graphical modeling formalism. $n e5ample Riskit analysis graph is presented in Migure >. 1he Riskit analysis graph allo.s 'isual yet more formal documentation of risks, resulting in better communications and a comprehensi'e understanding of the risksN conte5t.

0n order to prioritiIe risks during Risk analysis, the most important risks ha'e to be selected based on their probability and loss. 1o perform this prioritiIation, most risk management approaches rely on risk estimation approaches that are either impractical or theoretically Huestionable. Mor e5ample, the e5pected 'alue calculations (i.e., risk ; probability O loss) JFK are often impractical because accurate estimates of probability and loss are seldom a'ailable and it is difficult to account for multiple goal effects and for a non-linear utility function. Riskit largely a'oids these problems by using ranking techniHues that are appropriate for the type of information a'ailable. When ratio or distance scale data are a'ailable for probability and loss, e5pected utility loss calculations are used. !o.e'er, often only ordinal scale metrics are a'ailable for probability or utility loss. Mor e5ample, the risk scenarios might be ranked in terms of probability and utility loss each as sho.n in Migure <.

1o select in this case the most important risks based on the combination of probability and utility loss, a specific #is it Pareto ran ing techni*ue is used. 1his techniHue uses a t.o-dimensional space to position risk scenarios by their relati'e probability and utility loss as sho.n in Migure ?. "sing this techniHue, the e'aluation of the risks is then based on utility theory J>KJ)@K. 1he 'alue of this Riskit areto ranking techniHue is that it pro'ides a reliable and consistent ranking approach that only ranks risks as far as the input data allo.s.

2 #ASE ST/D3 #ONTE4T 1eno'is is one of BermanyNs largest companies in the telecommunication market. 0t is a successor of %osch 1elecom and has about E?** employees. 1eno'is .orks in a .ide range of telecommunication areas such as pri'ate branch e5changes ( %P), call centers, and 0 -based telephony. 1he project considered in this case study aimed to pro'ide a unified, integrated tool to support ser'ice personnel in their task of administrating all of 1eno'isN e5isting %P platforms. 1hus, this project .as called 1ool !armoniIation roject. Starting at the end of )LLL, the projectNs duration .as planned to be appro5imately one year. 0n this project ne. and challenging technologies .ere to be applied. Web technology .as to be used in a client-ser'er application conte5t. $dditionally, object-oriented technology .as selected for design and implementation. 4n the one hand, the ne. technologies added comple5ity to the project, on the other hand, they .ere e5pected to increase the projectNs producti'ity. %esides the ne. technologies, a ne. de'elopment process and a ne. project organiIation .ere introduced, .hich in'ol'ed teams from three different locations and time Iones (0ndia, Mrance, and Bermany). 0n the early stages of the project, risk management .as performed in an informal .ay. !o.e'er, this intuiti'e risk management .as considered to be longer appropriate for a company in the telecommunication market. 1his market is characteriIed by high competition, strong demand for inno'ati'e technologies, and a 'ery short inno'ation cycle. 1hese factors usually impose risks to telecommunication projects. 1he introduction of ne. technologies and processes imposed additional risks. !ence this project .as seen as particularly risky compared to other projects at 1eno'is. 1his situation made the case for the introduction of e5plicit, systematic, and e5perience-based risk management into this project. 5 TRANS6ER O6 RISK MANA1EMENT 1he transfer of risk management to the 1eno'is conte5t .as entrusted to Mraunhofer 0&S&, .hich ser'ed as methodology pro'ider. 1he Riskit method (see Section C) method .as one part of the o'erall risk management concept proposed to 1eno'is. $dditionally, this concept included methods to support risk management by data and to re-use risk e5perience in future projects. Risk management by data uses specific data from a measurement program to pro'ide status information on a project. Risk management by e5perience enables learning from other projects by means of an e5perience factory JCK. 1his paper, ho.e'er, deals only .ith the application of Riskit. 0n the beginning, a kick-off .orkshop took place. 1he participants in this .orkshop .ere the department head, .ho sponsored the implementation of risk management, and the project management team. 0n the .orkshop, a tutorial on Riskit .as gi'en. $dditionally, the acti'ities of mandate and goal definition, risk identification, risk analysis, and risk control planning (cf. Migure )) .ere briefly performed for

the concrete project. $ similar .orkshop .as later performed for senior de'elopers. We also defined specific templates for documenting risk information during the project (see Migure F). Mor subseHuent risk management acti'ities, .hich .ere held in separate meetings in addition to the regular project meetings, a risk management team .as established. 1his team consisted of the department head and t.o members of the project management team. 1he latter ones changed o'er time. 1he risk management team .as supported by the personnel from Mraunhofer 0&S&, .ho had the role of facilitators in the risk management meetings. 0n this role they prepared the meetings by, for e5ample, selecting and preparing the risk management techniHues to be applied, pro'iding the necessary documents, and sending in'itations. -uring the meetings they moderated the discussions and took care of the correct applicat ion of the risk management techniHues. 0n addition, they .ere responsible for the documentation of the meeting results. 0n the course of the project, the introduction of risk management .as negati'ely affected by se'eral circumstances. Mirst, the project members regarded risk management as 9yet another ne. method: besides the ne. process and technologies, resulting in lo. moti'ation for it. Second, the project manager, .ho played a 'ery prominent role in risk management, changed. 1hird, the company .as sold, resulting in a major restructuring, .hich made it difficult for some time to .ork regularly on risk management. 7 #ASE ST/D3 DESI1N 1he empirical study reported in this paper is a carefully designed case study .ith predefined objecti'es and some le'el of control .ith respect to the o'erall arrangements of the study. 1he authors .ere obser'ing the study .hile facilitating it. 1he design of the case study started at the beginning of the technology transfer. We first identified the research goals sho.n belo. in the form of a BQM-goal template JEKJ>>K( B)( /haracteriIe the usefulness and ade*uacy of the #is it ris management process from the 'ie.point of the ris management participants in the conte5t of $enovis. 1o us usefulness and adeHuacy mean the ad'antages and dra.backs of risk management .ith respect to ()) the Riskit features, (i.e., the techniHues used .ithin Riskit), (C) performing e5plicit risk management in general, (i.e., Riskitindependent issues), and (>) the transfer of the risk management process and methods into the project. BC( /haracteriIe the cost+&enefit of the #is it ris management process from the 'ie.point of the department head and the project manager in the conte5t of $enovis. 1his goal aimed at assessing the economical impact of the transferred risk management technology. "sing the Boal-Question-Metric aradigm JEKJ>>K, .e refined these t.o goals in Huestions characteriIing the Huality aspects usefulness, adeHuacy, and cost-benefit. SubseHuently, .e refined these Huestions into metrics defining the data to be collected to ans.er the Huestions and e'aluate the research goals. 1he identified metrics .ere of t.o types( Huantitati'e metrics and Hualitati'e metrics.

1he Huantitati'e metrics included information like the effort spent on risk management, the number of risks and risk types o'er time, the number of controlling actions and their effecti'eness o'er time. We collected data for these metrics regularly during the performance of risk management. Most of the data .ere collected as part of the risk management documentation. 1he Hualitati'e metrics included aspects like the benefit of risk management as percei'ed by the participants and the ad'antages and dra.backs of the employed Riskit process and its techniHues as seen by the participants. 1o collect the data for these metrics, .e prepared a Huestionnaire containing >> Huestions and an associated inter'ie. procedure (cf. Migure @) for a structured inter'ie.. "sing these materials, .e inter'ie.ed all fi'e members of the 1eno'is risk management team at the end of the project, .ith each inter'ie. lasting about one hour. 1he inter'ie.s .ere held .ith one inter'ie.er and one scribe .ho recorded the inter'ie.eesN ans.ers. 1he recorded ans.ers .ere entered into a database for better analysis. &ach inter'ie.ee .as sent a report .ith his entered ans.ers for re'ie..

1he inter'ie. results .ere combined and analyIed in order to ans.er the research goals and identify the strengths and .eaknesses of the employed

approach. 0n addition to the inter'ie. results, .e also used the obser'ations .e made as facilitators of the risk management meetings. 1hese obser'ations .ere recorded after each meeting in a logbook and mainly referred to practices that .orked .ell or .ere unpractical. %ased on the inter'ie. results and the recorded obser'ations .e de'ised a set of impro'ement suggestions to impro'e the risk management process and to better tailor it to the en'ironment. 1o 'erify our conclusions and suggested process impro'ement proposals, a feedback session .ith the members of the risk management team (i.e., the inter'ie.ees) .as performed. 1he impro'ed risk management process .ill form the basis for future risk management acti'ities at 1eno'is. &mpirical studies in general and case studies in particular are prone to biases and 'alidity threats that make it difficult to control the Huality of the study and to generaliIe its results J>CKJ><K. 0n the follo.ing .e discuss selected, rele'ant 'alidity threats and describe the steps taken to reduce them or their impact on our study. 1he relia&ility of our data collection (i.e., its consistency and repeatability) .as impro'ed by documenting the inter'ie. Huestions and inter'ie. procedure in detail and applying them consistently. 1he t.o main threats to i nternal 'alidity in the study .ere e5perimenter e5pectation bias and maturation J>?K. 1he e!perimenter e!pectation &ias could occur due to the technology pro'idersN e5pectations or desire to see positi'e results in a study. 1his bias .as reduced by carefully discussing and e'aluating the facilitator obser'ations and findings and emphasiIing the 1eno'is participant feedback on them. $lso, .e kept logbooks after each meeting to record our obser'ations in their original form, .hich helped us to remember the precise obser'ations and their conte5ts e'en after some time. 1he maturation effect threatens the conclusions of a study .hen subjects react differently as time passes. 0n our case this could ha'e been possible as the participants .ere just going up their learning cur'e on risk management and thus became more fluent in its acti'ities o'er time. !o.e'er, the inter'ie.s took place at the end of the project in a short period of time .hen the participants .ere Huite mature in their risk management practices. 1herefore, .e belie'e that the maturation effect did not significantly affect our study. 1he representativeness of the project and its participants relates to ho. .ell .e can generaliIe the results, i.e., to e5ternal 'alidity. 1he project itself .as more risky and had perhaps higher e5pectation le'els than normal projects in the company. We belie'e that this had t.o impacts( 4n the one hand, this may ha'e biased the participants to recogniIe the need for risk management more clearly, resulting in a generally positi'e attitude to.ards risk management. 4n the other hand, the pressures of aggressi'e project goals may ha'e also reduced the time a'ailable for risk management acti'ities by simultaneously increasing the e5pectations from risk management results. 1his could ha'e resulted in a more negati'e attitude to.ards the impact of risk management on the project. Regarding the representati'eness of the project participants, .e

ha'e no specific reason or information to belie'e that the participants .ould be different from those of other projects. 6 #ASE ST/D3 RES/+TS 6 ! Results -or Riskit8s /se-ul$ess 0n this section .e report the findings of our obser'ations and the inter'ie.s. Section @.).) describes our findings related to the Riskit method itself, Section @.).C describes our findings related to the performance of the risk management in the 1eno'is project, and Section @.).> describes our findings related to the transfer of risk management into the conte5t of 1eno'is. ,"-"- .sefulness/Ade*uacy of the #is it Process 4ne crucial element in the inter'ie.s .as the Huestion( For each activity in the #is it process' what are the advantages and pro&lems perceived &y the participants/ 0n the follo.ing, .e report the most important findings related to the indi'idual acti'ities and techniHues in the Riskit process. Process definition( 4ne feature of Riskit is the full operational definition of its process. 1his e5plicit process .as percei'ed as systematic and 'ery helpful. "nlike 9intuiti'e: risk management, .here risks are unsystematically identified at the beginning and not appropriately tracked, the process triggers all necessary acti'ities. 4ne positi'e side effect of the e5plicit process is also that the importance of risk management is emphasiIed as people dedicate their time to .ork specifically on risk management acti'ities. #is 0dentification( 1o identify risks, the Riskit process pro'ides t.o techniHues, .hich compensate each otherNs biases. 1he t.o techniHues are brainstorming and a risk checklist. 0n this case, .e used an e5cerpt of the S&0 checklists for risks J)*K. 1he combination of these techniHues .as appreciated as being systematic and comprehensi'e. Retrospecti'ely, the participants noted that most of the projectNs risks .ere identified during risk identification. $dditionally, the composition of the risk management team of people from different roles (i.e., people .ith a different 'ie. on the project) .as beneficial, as the different 'ie.s on potential risks could be e5changed and combined. /onseHuently, almost all participants learned about risks that .ere ne. to them. #is Analysis( $s sho.n in Migure >, Riskit uses $nalysis Braphs to describe and discuss risks. 1hese $nalysis Braphs .ere rated as 'ery helpful in understanding the risk, its conte5t, and its conseHuences. 4ne benefit of these graphs .as clearly the 'isual representation, .hich made the risks more e5plicit and facilitated discussions about them. $lthough the de'elopment of these graphs .as time consuming (discussion of a risk e'ent and de'elopment of the corresponding scenario took about )F min on a'erage), participants regarded this time as .ell-in'ested due to the increased understanding of the risks. $nother feature of the Riskit method is the areto ranking techniHue to rank risks and select the most important ones. 1his areto ranking techniHue .as percei'ed as beneficial and practical as people could easily compare the risks in terms of probability and utility loss. &specially for the latter it .as appreciated that no precise, Huantitati'e estimate of the loss had to be gi'en but measurement .as performed through ranking the risks (i.e., for t.o risks it

had only to be determined, .hich risk had the larger loss). 1he selection of the most important risks based on the combination of probability and loss .as performed by means of a areto-table JC?K. 1hi s selection .as regarded as comprehensible and thus, participants appreciated this techniHue. %ocumentation( 1he documentation of the process acti'ities is performed by means of a set of forms. 1hese forms ser'e the communication bet.een different acti'ities of the process as .ell as bet.een different meetings. 1he most central form is the Risk Scenario Morm (cf. Migure F). 1his form contains a description of the risk in both te5tual and graphical form, the riskNs ranking in terms of probability and utility loss, potential and implemented controlling actions, as .ell as a history of the risk and its controlling actions. 1hus, it contains complete information both for operational purposes (i.e., monitoring of controlling actions) and documentation purposes (.hich are supposed to enable learning from risks for future projects). %ased on the inter'ie.s, three disad'antages of the forms .ere obser'ed. Mirst, the forms contain too much information for daily .ork, especially for risk monitoring. -uring risk monitoring, participants .ere only interested in the graphical description of the risk and the list of controlling actions. /onseHuently, the remaining information .as seen as superfluous for this acti'ity. Second, the te5tual description of the risks .as kept 'ery short and thus mainly consisted of key.ords. 1his amount of detail .as sufficient as long as the participants remained the same. !o.e'er, in the course of the project, ne. members joined the risk management team. Mor them it .as difficult to acHuire the necessary understanding of the risks due to their short description. 1he lack of clear descriptions has the additional disad'antage of complicating the re-use of risk e5perience in future projects. 1hird, the effort for maintaining the documentation .as considered too high (cf. Migure E). $fter a risk monitoring meeting, .hich .as to be performed bi.eekly, the facilitator team spent about t.o hours on updating the statuses of the controlling actions as .ell as the risk and controlling action histories. Responsible for the high effort .as mainly the fact that the update .as performed manually in the entire documentation, .hich .as .ritten in MSWord .ith a comple5 link structure. 1his dra.back of the process in terms of documentation o'erhead can be easily o'ercome by an appropriate tool support for the documentation, such as a simple database solution. 1his solution also enables project managers to ha'e fast access to risk information. SummariIing our findings .ith respect to the Riskit method, .e can conclude( R 1he e5plicit process of the Riskit method .as regarded as systematic and practical. R 1he techniHues used .ithin the Riskit method .ere regarded as practical and understandable. 1he distinguishing features of Riskit, especially, .ere regarded as particularly 'aluable.

,"-"1 0nstantiation of #is Management at $enovis 1he crucial Huestion For each activity in the #is it process' what are the advantages and pro&lems perceived &y the participants/also pro'ided obser'ations that did not directly refer to the Riskit method itself but more to the .ay risk management .as instantiated at 1eno'is. 1hus, these obser'ations are of a more general nature. 0ntegration with project management and project wor ( 1he acti'ities of the Riskit process .ere performed in dedicated meetings .ith the members of the risk management team. 1his .as also true for the more freHuent risk monitoring meetings. 1his separation from the project meetings .as retrospecti'ely seen as a dra.back, since the project members (especially subproject managers but also de'elopers) .ere not included in the risk management acti'ities. 1o o'ercome this problem in the future, a stronger linkage bet.een project .ork and risk management is intended. #is 0dentification( 0n this project, risk identification .as performed intensi'ely at the beginning. 3et, although during risk monitoring, se'eral ne. risks .ere identified spontaneously, no risk identification meeting .as performed in the subseHuent course of the project. 1his fact .as seen as a dra.back as risks that .ere ) 1his high-le'el Huestion .as refined in the actual Huestionnaire and related to all acti'ities and

techniHues in the Riskit process. unkno.n at the beginning of the project .ere not systematically included in risk management. 1herefore, in the future, risk identification meetings .ill be scheduled automatically at pre-defined milestones. #is Monitoring( Risk Monitoring is one of the crucial acti'ities in the risk management process. 1he importance stems from the fact that this acti'ity has to be performed regularly .ithin the regular project .ork (e.g., .eekly or bi.eekly) and therefore should also be as short and concise as possible. 1.o dra.backs .ere obser'ed .ith our approach. Mirst, although bi-.eekly risk monitoring meetings .ere intended, it turned out that the inter'als bet.een the risk management meetings .ere longer due to non-a'ailability of the facilitators and participants. 1hese long inter'als .ere percei'ed as too long, as it .as not possible to react Huickly enough to changes in the risk and controlling action statuses. Moreo'er, due to the long inter'als, it .as difficult for participants to remember the conte5t of the risks and their controlling actions. Second, it is the task of risk monitoring to assess the status and effecti'eness of the controlling actions. 0n the project, this .as done by asking about the status of the controlling action, its impact on the risk (.here usually a rating of Shigh, medium, lo.T or a short sentence .as gi'en), and .hether the combination of controlling actions effecti'ely controls the risk. Retrospecti'ely, the participants thought that the controlling actions .ere not performed as planned and therefore .ere not as effecti'e as they could ha'e been. 1his could ha'e been pre'ented Braphical representation of scenario Risk (istory9 >).>.**( risk probably smaller, because people are a.are of the importance of Huality as a result of controlling action ? )F.?.**( risk is still to be considered= there are ne. people .ithin the project= and there .ill be ne. people coming .ithin near future CL.?.**( risk unchanged= controlling actions sufficient )>.@.**( Re-ranking changed probability from > to C, ne. utility loss for project leader assessed >*.@.**( risk unchanged= controlling actions sufficient C?.E.**( action < .as stopped since an e'aluation of a /ode /hecker .as completed action ? .as stopped because this is an integral part of the tasks of the project leader and line managers #o$trolli$, A:tio$ (istory #o$trolli$, A:tio$ Impa:t ) CL.?.**( introduced= impact( see follo.-up controlling action @ C >).>.**( minor CL.?.**( re'eals the effecti'eness of training >*.@.**( currently no training

C?.*E.** effect positi'e as people do build up kno. ho.= through the monitoring the need for additional training has been detected Te$o&is Risk S:e$ario 6orm ID )-) poor Huality code 6re'ie.Gtutoring Pro;e:t9 1ool !armoniIation O.$er<Respo$sible( Date re&ie.e*( C***-*C-*) Time-rame( Priority( /ontrolled Probability( C Stake%ol*er9 1eno'is Mgmt +oss( > Stake%ol*er9 -ept. ,ead +oss( < Stake%ol*er( roject ,eader +oss( < Action Respons. State Finish Check Sele:te* risk :o$trolli$, a:tio$s ) 0ntroduce re'ie. process Smith done end May U @ erform re'ie. process Miller ongoing &nd roj. 4ct. C Monitor the results of training Miller 4ngoing &nd roj. Sept. > -e'elop coding guidelines $rchitects 4ngoing &nd roj. 4ct. < &'aluate 8a'a code checkers -oe done mid 8uly U ? /ommunicate importance of Huality Miller done end Sep U #losi$, *ate( #losi$, Ratio$ale( 6i,ure =9 Risk S:e$ario 6orm -or o$e risk e&e$t by more strongly Huestioning the controlling action. 1hus, in the future, the actual implementation of the controlling action (.hat#) and its impact on the risk (ho. good#) has to be more strongly Huestioned. SummariIing our findings related to the instantiation of risk management, .e can conclude( R Risk management should be closely integrated .ith project management and daily project .ork to foster the synergy bet.een these acti'ities. R Risk identification should be scheduled automatically at predefined milestones (and, additionally, .hene'er it is seen as necessary). R Risk monitoring should be performed regularly .ith short inter'als bet.een t.o meetings. R Risk monitoring has to sufficiently Huestion the implementation of controlling actions and their impact on risks. ,"-"2 Ade*uacy of the $ransfer 1he third set of results refers to the findings related to the transfer of risk management into the conte5t of 1eno'is. 1o assess the adeHuacy of the transfer, the Huestionnaire contained the Huestions like How did you perceive the wor split &etween $enovis and 0ESE/ and From your point of view' how strong was the commitment for ris management from the 3architects1' management' yourselfT#

$raining( 1he training gi'en to participants .as seen as essential as it pro'ided the necessary background for risk management and its techniHues in general as .ell as for Riskit in particular. 0n the future, ho.e'er, not only the project and department management should take part in the training but also the de'elopers. 1he purpose is, on the one hand, to enable de'elopers to perform risk management acti'ities (as risk management is to be more included in the project .ork). 4n the other hand, the training can also raise the a.areness of risk management and risks. Process 4wnership( $s described in Section <, the technology .as transferred by the personnel from 0&S&, .ho performed the entire facilitation in the meetings and maintained the documentation. 1he facilitators also triggered the risk management meetings. 0nitially, it .as planned to gi'e this responsibility to the 1eno'is personnel in the course of the project, but due to time restrictions this did not happen as planned. 1hus, process o.nership remained .ith the facilitators and not .ith the project management team or e'en the 1eno'is company. /onseHuently, participants often had the impression that risk management .as not part of their daily project .ork but rather an additional acti'ity for an e5ternal party. C$rchitects are senior de'elopers responsible for the SW architecture 1o impro'e this in the future, the process o.nership for risk management has to rest .ith the project manager, .ho has to take care of the e5ecution of the process, in'ite the participants to the risk management meetings, and ensure implementation of the controlling actions. 1hus, the role of the technology pro'ider 0&S& should be to facilitate the first fe. sessions, take part in the follo.ing sessions as obser'ers, and finally lea'e the entire facilitation to the 1eno'is risk management personnel. Commitment of project manager ( $ third important obser'ation concerns the in'ol'ement of the project manager in the technology transfer. 0n risk management, the project manager is the crucial person as sGhe is the person making decisions and being responsible for the acti'ities in the project. 1his also includes acti'ities that arise from controlling actions, and moti'ating the de'elopment team. Moreo'er, risk management is part of hisGher project management task. 1he actual approach of our transfer .as prone to gi'e the project manager the impression that an e5ternal party (i.e., the facilitators) inter'ened in his tasks and authorities as project manager. 1herefore, in addition to the changed technology transfer approach (see abo'e), the commitment of the project leader has to be ensured from the beginning and the transfer approach must be coordinated .ith the project manager. SummariIing our findings related to the transfer of risk management, .e can conclude( R 1raining of the employed risk management process is important to train the participants and raise a.areness for risk management and risks. R rocess 4.nership for risk management has to rest .ith the project manager.

R /ommitment of the project manager is of utmost importance and has to be ensured from the beginning. 6 0 Results -or t%e #ost>Be$e-it o- Riskit $n important criterion for introducing a ne. technology is its cost-benefit relationship. Mor risk management, ho.e'er, this relationship is hard to e5press Huantitati'ely. While the cost (i.e., effort) is easy to measure Huantitati'ely, the benefit is usually hard to Huantify. 1herefore, .e rely mostly on the subjecti'e assessment of the benefits as seen from the risk management team. 0n the follo.ing, .e first describe the costs and benefits separately and then combine both aspects. 1he cost of risk management can be measured in terms of the effort that is spent on the acti'ities of the risk management process. Migure E sho.s the effort spent in this case study. 0n total, C> person days .ere spent in total from the project team and facilitator team, .hich represents ?+ of the o'erall effort for project management.

1o assess the benefits of risk management, .e collected Huantitati'e measurement data on the number of risks, the number and effecti'eness of the controlling actions as .ell as Hualitati'e data in terms as the benefits subjecti'ely seen by the participants. 0n Migure L, the number of risks identified andGor tracked in this project is sho.n o'er the projectNs time.

0t can be seen that the number of identified but not analyIed risks (i.e., ra. risks) is Huite large. 1hus, a relati'ely small proportion of those risks identified during risk identification .as considered during risk analysis. 0t can also be obser'ed that no major risk identification took place after 8une. 1his can be attributed to problems in the project. De'ertheless, participants thought retrospecti'ely that the controlled risks contained most of the projectNs important risks. Mor the controlled risks Migure )* sho.s the impact of the controlling actions on the risk. 1he risk management team assessed the impact subjecti'ely on a scale of Shigh, medium, lo., no impact, unkno.n impactT. $s can be seen, about )G? of the defined controlling actions sho.ed high impact on pre'enting or reducing the risk. 1hus, for these controlling actions it can be concluded that their implementation .as 'aluable for the project as they effecti'ely contributed to the mitigation of the corresponding risk. 4n the other hand, it can also be seen that a large proportion of controlling actions is rated as un nown impact" 1his situation corroborates the abo'ementioned finding that the impact of the controlling actions .as not sufficiently Huestioned and that many controlling actions .ere not implemented as planned. 1o foster Hualitati'e assessment of the benefits of risk management, our Huestionnaire contained the Huestion( 5hat was the overall impact of ris management on the project/ !ere, participants stressed the systematic and sound approach of an e5plicit risk management process that .as definitely an impro'ement o'er the more intuiti'e risk management performed prior to the introduction of Riskit.

articipants learned that it is possible to systematically identify risks and, e'en more important, successfully tackle them by means of controlling actions.

0n order to decide .hether risk management should be implemented in a ne. project .ithin 1eno'is or a ne. company, the ratio bet.een cost and benefit has to be taken into account. -ue to the Hualitati'e nature of the benefits, the ratio can only be assessed subjecti'ely. 1herefore .e asked the participants( Considering the effort spent on ris management' the num&er of identified/controlled ris s' and the impact of the controlling actions' would you say that the invested effort paid off/ While the amount of effort .as seen as acceptable by the participants, they regarded the impact of risk management on the project in this case study as too lo.. 1hey rated the relationship bet.een cost and benefit for the project as negati'e or neutral at best. !o.e'er, since the lo. impact of risk management on the project can be attributed to the .eak implementation of the controlling actions, there is a clear potential for impro'ing the cost-benefit in the future .ith the e5perience from this project. 4n the other hand, at management le'el the e5istence of a more systematic and e5plicit risk management pro'iding a more professional project management .as seen as .orth the cost. %ecause of this and the prospect that impro'ed risk management .ill also ha'e a stronger impact on the project itself, management .ill continue implementing e5plicit risk management using the concepts of Riskit in future projects. SummariIing our findings related to the cost and benefit .e can conclude(

R 1he cost of risk management accounted for ?+ of the o'erall project management effort, .hich .as seen as acceptable. R $t management le'el, the e5istence of more professional project management .as seen as .orth the cost. R 1he impact of risk management on the project .as seen as too lo.. With impro'ed risk management, ho.e'er, this impact can be impro'ed respecti'ely. 6 2 #ompariso$ .it% Ot%er #ase Stu*ies 0n order to generaliIe the results of our study, .e performed a cross-case analysis J><K and compared our findings .ith the findings of three earlier case studies in'estigating the Riskit method. 1he first case study for Riskit, .hich .as performed in )LL@ at D$S$ JC>KJC<K, .as an e5ploratory study for Riskit but also compared Riskit .ith a different method. 0n this study, the 'isual appeal and understandability of the Riskit analysis graphs .as emphasiIed. Murthermore, this study found that users reported higher le'els of confidence in the results of the Riskit method. %oth of these findings seem to be in line .ith the o'erall feedback recei'ed from our study. $dditionally, the D$S$ study found that the Riskit method produced more detailed controlling actions. $lthough in our study, the 1eno'is participants regarded the implementation of the controlling actions as .eak, they, ne'ertheless, ackno.ledged that the controlling actions .ould ha'e had a useful impact on the project if they had been implemented as planned. 0n terms of effort, studies differ substantially( 0n the D$S$ study C*+ of the management effort .as spent on risk management, .hereas in the 1eno'is project this figure .as ?+. 4ne potential e5planation for this difference could be the substantially smaller siIe of the D$S$ project. $nother possible e5planation could be the fact that the Riskit method itself .as in its early de'elopment and perhaps contained more o'erhead acti'ities during the D$S$ study. 1he second study, .hich .as conducted in )LLE at Dokia and -aimler/hrysler JCFK, e'aluated the feasibility and usefulness of Riskit. $dditionally, the study tried to identify issues related to the introduction of risk management. 0n this second study, the follo.ing obser'ations .ere made( R Moti'ation and clear definition of responsibilities are necessary for successful risk management. R roject time pressures continually limit the time a'ailable for risk management. R Systematic risk management .as percei'ed as beneficial and seemed to impro'e participantsN confidence in risk management results. 1hese findings are similar to the ones presented in this paper. !o.e'er, some findings differ. 1he -aimler/hrysler study indicated that users had difficulties understanding and using Riskit analysis graphs .hereas in our study these graphs .ere considered 'ery helpful. We belie'e that a major reason for this

difference .as the amount of training gi'en to participants. 0n the -aimler/hrysler study, one to t.o hours of training .ere gi'en to the risk management participants, .hereas in the 1eno'is study, a full-day .orkshop .ith e5ercises using material from the actual project .as performed. 1his e5planation of factors impacting the understandability of the Riskit analysis graphs emphasiIes our finding that appropriate training is essential for a successful technology transfer for Riskit. 1he third study, .hich .as performed by Betto and ,andes in the conte5t of -aimler/hrysler in )LLL J)EK, emphasiIed the need for efficiency in risk management. $gain, this is similar to the findings of our study. 1his third study also emphasiIed the importance of stakeholders as defined in Riskit (cf. Migure C), a fact that .as also reported in the second study performed at Dokia and -aimler/hrysler. 0n our study, the concept of stakeholders .as not e5plicitly mentioned in the case study inter'ie.s by the inter'ie.ees. 3et, during the course of the project, discussions took place in the risk management team on stakeholders, their goals, and their goal priorities. 0n summary, the findings in all four studies seem to be fairly consistent and the natural 'ariance in the .ay the method .as applied in the 'arious conte5ts can be used to find more effecti'e .ays of applying the method. = +ESSONS +EARNED 6ROM T(E #ASE ST/D3 %ased on the results reported abo'e .e de'eloped a set of lessons learned that .e consider the essentials of our case study. 1hey are largely independent of the project and as such can be applied to other projects as .ell. R E!plicit and systematic ris management is perceived as useful &y project management. rior to RiskitNs implementation the project managers performed most of the risk management acti'ities, albeit in an informal and intuiti'e .ay. !o.e'er, the e5plicit and systematic .ay .as percei'ed as a 'aluable add-on to their daily practices. R $he distinguishing features of #is it were perceived as practical and understanda&le" -uring risk identification, the combination of checklists and brainstorming allo.s both to include the e5perience and insight of the participants and, simultaneously, check systematically for typical risks. -uring risk analysis, the Riskit scenarios pro'ided an effecti'e .ay to understand and discuss about risks. -uring selection of the most important risks, the areto table allo.s to take into account both the probability and utility loss effecti'ely and comprehensibly e'en though they are measured by ordinal scale metrics. R Monitoring is one of the most important activities" $ 'ital prereHuisite for successful risk mitigation is the ability to react Huickly to changes in the status of a risk or its controlling actions, as early as possible. Risk monitoring on a regular basis is the key to this prereHuisite. 1he method used for monitoring should be carefully selected to a'oid tedious repetition, and the documentation should support the reHuirements of monitoring, as it is the acti'ity that is performed most freHuently.

R Ensure seamless integration of ris management activities into the overall project wor " Regular project meetings should be used to perform the risk management acti'ities. 1his is especially true for risk monitoring. Regular meetings enable participants to detect and react on changes in the status of risks or their controlling actions and pre'ents unnecessary o'erhead through additional meetings. Moreo'er, de'elopers .ill not percei'e risk management acti'ities as additional burden but as part of their routine .ork. 1he integration should also force an appropriate le'el of documentation. R Ensure the commitment of the project manager when implementing ris management" $lthough upper management often decides on the introduction of a technology such as risk management, the project manager is the one .ho, in the end has to make risk management decisions in the project and con'ince his or her project team. 1herefore, the project managerNs commitment is of crucial importance for successful technology transfer. R Process ownership of customi6ed ris management process" $lthough at the beginning of the technology transfer, the technology pro'ider has the e5perience and competence .ith risk management, it is 'ery important that the project manager takes o'er responsibility for the customiIed process. 1his o.nership is necessary to adapt the process to the projectNs needs Huickly and efficiently, and to perform the process in the most effecti'e and systematic .ay. 1he role of the technology pro'ider is to ad'ise and support the project manager. ? #ON#+/SION 0n this paper, .e presented a case study of implementing risk management at 1eno'is. 1he objecti'es of the case study .ere, on the one hand, to analyIe the usefulness and adeHuacy of Riskit in order to tailor the method to 1eno'is and impro'e it in general. 4n the other hand, the objecti'e .as to analyIe the cost-benefit of Riskit in an industrial conte5t. 4ur results sho. that Riskit is a practical and understandable risk management method. 0ts techniHues for describing risks (Risk Scenarios) and for selecting the most important risks ( areto ranking techniHue) .ere highly appreciated by the risk management team. While the costs for risk management .ere seen as acceptable, its impact on the project .ere, in this particular case, considered too lo.. 3et, the e5periences from this case study can be used to impro'e risk management at 1eno'is and thus increase its cost effecti'eness. 4n a management, le'el the e5istence of a more professional project management .as seen as .orth the costs. $dditionally, .e reported se'eral lessons learned for both risk management in general, and Riskit in particular. 1hey can be useful for all project managers .ho are considering the introduction of e5plicit risk management. @ A#KNOW+ED1EMENTS We .ould like to thank the participants of the 1eno'is Risk Management Meetings for their commitment and their collaboration .hen .e performed the case study inter'ie.s. $dditionally, .e .ould like to thank Sonnhild Damingha

for proofreading the paper. Minally, .e thank "lrike %ecker- 2ornstaedt for her 'aluable comments on the contents and presentation of the paper.