tugas-manajemen-reiko.doc

7/26/2019 tugas-manajemen-reiko.doc

http://slidepdf.com/reader/full/tugas-manajemen-reikodoc 1/44

MANAJEMEnn 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 menghadapiresiko 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. emahaman atas

sikap orang terhadap resiko ini dapat membantu untuk mengerti betapa 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



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.

an resiko memiliki tiga kategori

- 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#



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 mungkin. 1eknik-teknik yang dapat digunakan dalam

identifikasi resiko antara lain

• %rainstorming

• Sur'ei

• Waancara

• 0nformasi histori

• 2elompok kerja

1ipe-tipe resiko

"ntuk keperluan identifikasi dan mengelola resiko yang dapat

menyebabkan sebuah pengembangan melampaui batas aktu dan biaya

%0$

3$

1ingkat Resiko

1otal %iaya

Resiko 1ingkat 4ptimal

&5pected ossesfrom the risk

/ost 4f$'ersion



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 baha 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 hardare baru untuk

pengembangan mempunyai resiko yang lebih tinggi dibandingkan

dengan softare yang dapat dibangun pada hardare yang sudah

ada (dan familiar). Sebuah sistem yang dikembangkan untuk satu

jenis hardare atau softare platform tertentu jika dipergunakan

pada hardare atau softare 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 softare 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 dipertanggungjaabkan dan sebagai bukti baha kita pernah

mengerjakan tugas yang serupa sebelumnya. engan pengalaman ituseharusnya 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 jadal 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 baha 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 aal. !al ini dapat terjadi setiap saat.

ada setiap tahapan pada proses perencanaan, sangat penting untukmemeperinci 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 baha 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 beberapa spesifikasi kebutuhan

kemungkinan diubah setelah beberapa modul telah dikodekan,

programmer senior meninggalkan pengembangan, perangkat keras yang

diperlukan tidak dikirim tapat aktu. %eberapa kejadian semacam itu



dapat terjadi seaktu-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 jadal

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 akaldan 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 forard 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 aal akan

tetapi merupakan tanggal yang diharapkan dapat mencapai

aktifitas tersebut.



8aringan &R1 yang diperlihatkan pada gambar > memperlihatkan

baha kita berharap proyek tersebut dapat diselesaikan dalam

aktu >,? minggu- tidak seperti /M yang tidak memperlihatkan

tanggal paling aal 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

(a)

!st "ikel#

(m)

Pessimistic (b)

A $ 6 %& 3 ' $ 3 3

D 3.$ ' $

E * 3 '

+ % *, *$

- 3 '

.$

endekatan &R1 juga difokuskan pada ketidakpastian estimasi

durasi aktifitas. erlu tiga estimasi untuk masing-masing aktifitas

yang memperlihatkan fakta baha 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 1eiasi

Aktifitas 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 epecte1 s5 stan1ar1 1eiati!n

• 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 dijadalkan

untuk bekerja pada proyek lain dan kejadian ? memperlihatkan

penyerahan produk kepada pelanggan. "ntuk itu diperlukan tiga

tanggal target pada jaringan &R1 seperti yang diperlihatkan

dalam gambar <.

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 Biaya Waktu KualitasSangat rendah ana mencukupi $gak menyimpang

dari target

2ualitas agak

berkurang namun

masih dapat

digunakanRendah Membutuhkan dana

tambahan

$gak menyimpang

dari target

Bagal untuk

memenuhi janji pada

stakeholderSedang Membutuhkan dana

tambahan

enundaan

berdampak terhadap

stakeholder

%eberapa fungsi tidak

dapat dimanfaatkan

1inggi Membutuhkan dana

tambahan yang

signifikan

Bagal memenuhi

deadline

Bagal untuk

memenuhi kebutuhan

banyak stakeholderSangat tinggi Membutuhkan dana

tambahan yang

substansial

enundaan merusak

proyek

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 Probabilitas DampakSangat rendah !ampir tidak mungkin terjadi ampak kecil



Rendah 2adang terjadi ampak kecill pada biaya,

aktu dan kualitasSedang Mungkin tidak terjadi ampak sedang pada biaya,

aktu dan kualitas1inggi Sangat mungkin terjadi ampak substansial pada

biaya, aktu dan kualitasSangat tinggi !ampir pasti terjadi 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 softare). %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

lielihood = sedangkan dampak yang akan terjadi jika resiko tersebut

terjadi dikenal dengan ris impact dan tingkat kepentingan resiko

disebut dengan ris value atau ris e!posure" Risk 'alue dapat dihitung

dengan formula

Risk ep!sure 7 risk likeli2!!1 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 jadal 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 baha resiko yang bernilai tertinggi tidak selalu akan



menjadi resiko yang pasti terjadi maupun akan menjadi resiko dengan

potensi impact yang terbesar.

Tabel !" # $onto% e&aluasi nilai risk e'posure

(a)ar* + I R

R erubahan spesifikasi

kebutuhan selama coding

E E

RC Spesifikasi perlu lebih lama

dibandingkan yang diperlukan

> F C

R> Staf sakit yang berpengaruh

pada aktifitas yang kritis

? F >?

R< Staf sakit yang berpengaruh

pada aktifitas yang tidak kritis.

* > >*

R? engkodean modul lebih lama

dibandingkan yang diharapkan

< ? C*

R@ engujian modul

memperlihatkan kesalahan atau

ketidakefisiensian dalam

desain.

* *

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 baha 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 baha 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 merupakanmetode 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 deferral meliputi

menunda aspek suatu proyek hingga saat dimana probabilitas

terjadinya resiko tersebut kecil.



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 softare dan strategi mengurangi resiko

Resiko Teknik men,uran,i resiko2egagalan pada personil •Memperkerjakan staf yang handal

•8ob matching

•Membangun tim

• Mengadakan pelatihan dan peningkatan

karir

•Membuat jadal lebih aal bagi personil

utama&stimasi biaya dan aktu

yang tidak realistis

• Membuat beberapa estimasi

• esain untuk biaya

• Meningkatkan pengembangan

• Merekam dan menganalisa proyek

sebelumnya

• Standarisasi metode

Mengembangkan fungsi

softare yang salah

• &'aluasi proyek ditingkatkan

• %uat metode spesifikasi yang formal

• Sur'ey pengguna

• %uat prototype

• %uat user manual lebih aal

Mengembangkan

antarmuka penggunayang salah

• Membuat prototype

• $nalisis tugas

• 2eterlibatan pengguna

Bold plating • Mengurangi kebutuhan

• Membuat prototype

• $nalisis biaya manfaat

• esain biaya

1erlambat untuk

mengubah kebutuhan

• Mengubah prosedur kendali

• Membatasi perubahan yang terlalu banyak

• Meningkatkan prototype

• Meningkatkan pengembangan (akibat

perubahan)2egagalan pada

komponen yang disuplai

pihak eksternal

• Melakukan benchmarking

• 0nspeksi

• Spesifikasi formal

• 2ontrak perjanjian



• rosedur dan sertifikasi jaminan kualitas

2egagalan menjalankan

tugas eksternal

• rosedur jaminan kualitas

• esain G prototype yang kompetitif

• Membangun tim

• 2ontrak insentif 2egagalan kinerja real-

time

• Simulasi

• %enchmarking

• rototipe

• 1uning

• $nalisis teknis

engembangnya terlalu

sulit secara 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 resikomerupakan bagian penting dalam perencanaan suatu proyek. Damun,

manajemen resiko tidaklah berhenti sampai disana saja. raktek,

pengalaman dan terjadinya kerugian akan membutuhkan suatu

perubahan dalam rencana dan keputusan mengenai penanganan suatu

resiko. Sangatlah penting untuk selalu memonitor proses dari aal 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

httpGG.sbl.tkk.fiGteachingGcoursesG1-CE.?>**GarticlesG&secC**.pdf

An In*ustrial $ase Stu*y o- Implementin,

So-t.are Risk Mana,ement

ABSTRA$T&5plicit risk management is ga ining ground in industrial softare de'elopmentprojects. !oe'er, there are fe empirical studies that in'estigate the transferof e5plicit risk management into industry, the adeHuacy of the riskmanagement approaches to the constraints of industrial conte5ts, or their cost-benefit. 1his paper presents results from a case study that introduced asystematic risk management method, namely the Riskit method, into a largeBerman telecommunication company. 1he objecti'e of the case study as ()to analyIe the usefulness and ade*uacy of the #isit method and (C) to analyIe

the cost+&enefit of the #isit 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 toobtain more generaliIed conclusions on the Riskit method. 4ur results shoedthat the Riskit method is practical, adds 'alue to the project, and that its keyconcepts are understood and usable in practice. $dditionally, many lessonslearned are reported that are useful for the general audience ho ants totransfer risk management into ne projects.

Key.or*sRisk Management, /ase Study, essons earned, Riskit Method"! INTROD/$TIONSince the introduction of risk management into the mainstream of softareengineering JFKJCK, the softare industry has gradually become more acti'e inusing e5plicit risk management J>KJCCK. $lso, the increased reHuirements forrisk management by many assessment standards ha'e increased corporateinterest in risk management.Risk management practices ha'e become much more operational and practical,as many guidelines, te5tbooks J<KJC*K, and consultants help organiIationsimpro'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 riskmanagement into an organiIation. 1he reports that are a'ailable ha'e beenconducted as informal case studies ithout sufficient attempt to scientific rigoror empirical research methods J<KJLKJKJFKJCLK. !oe'er, systematicempirical in'estigations are necessary to learn more about the transfer andapplication of risk management methods.1o contribute such a systematic empirical in'estigation, this paper presents acarefully designed case study on the implementation of a specific risk

http://www.sbl.tkk.fi/teaching/courses/T-128.5300/articles/Esec2001.pdf

http://www.sbl.tkk.fi/teaching/courses/T-128.5300/articles/Esec2001.pdf



management method, namely the Riskit method, into the telecommunicationcompany 1eno'is.1he paper builds on a series of three case studies related to the Riskit methodJEKJC<KJCFK. 1he 'alue of replicated case studies of the same method in'arying conte5ts allos us to generaliIe our findings ith respect to Riskit in

particular and risk management in general. $dditionally, replication in differentconte5ts allos us to identify important conte5t factors affecting the successof the transfer and implementation of risk management.1he objecti'es of the case study presented in this paper ere tofold. 1hefirst objecti'e as to characteriIe the usefulness and ade*uacy of the #isitris management process from the 'iepoint of the ris management

participants. 1his objecti'e aimed at identifying effecti'e ays of introducingrisk management at the company in Huestion and in general, and of pro'idingfeedback for impro'ing the Riskit method.1he second objecti'e as to characteriIe the cost+&enefit of the #isit rismanagement 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 follos. Section C describes thetransferred risk management method. Sections > and < describe the projectselected for this case study and the transfer of risk management into theproject. Section ? describes the design of our case study. 1he results of thiscase study are presented and compared ith the results of pre'ious casestudies in Section @. %ased on these results, e infer in Section F lessonslearned that are rele'ant for the general community. Section E concludes thepaper 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 soundtheoretical principles, yet it has been designed to ha'e sufficiently loo'erhead and comple5ity so that it can be used in real, time-constrainedprojects. %ecause of its more solid theoretical foundations, it a'oids many of the limitations and problems that are common to many other risk managementapproaches in softare engineering, such as use of biased ranking tables ande5pected 'alue calculations. $s Riskit has been e5tensi'ely presented in otherpublications JC>KJC<KJC?KJC@KJCFK, e present here only the principles of themethod and the features that distinguish it from other risk managementapproaches.

Riskit contains a fully defined process, hose o'er'ie is presented in igure as a dataflo diagram. 1he full definition of the Riskit process is a'ailable as aseparate report JC?K.



1he Riskit process includes a specific step for analyIing stakeholder interestsand ho they link to risks. 1hese links are 'isualiIed in igure C hen risks aredefined, their impact on the project is described through the stated projectgoals. 1his allos full traceability beteen risks and goals and on to

stakeholders each risk can be described by its potential impact on the agreedproject goals, and each stakeholder can use this information to rank risks fromhis perspecti'e.

0n order to describe risks during Risk analysis, the Riskit method supportsunambiguous definition of risks using the #isit analysis graph (also called riskscenario) 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 graphicalmodeling formalism. $n e5ample Riskit analysis graph is presented in igure >.1he Riskit analysis graph allos 'isual yet more formal documentation of risks,resulting in better communications and a comprehensi'e understanding of therisksN conte5t.

0n order to prioritiIe risks during Risk analysis, the most important risks ha'e tobe selected based on their probability and loss. 1o perform this prioritiIation,most risk management approaches rely on risk estimation approaches that areeither impractical or theoretically Huestionable. or e5ample, the e5pected'alue calculations (i.e., risk ; probability O loss) JFK are often impracticalbecause accurate estimates of probability and loss are seldom a'ailable and itis difficult to account for multiple goal effects and for a non-linear utilityfunction.

Riskit largely a'oids these problems by using ranking techniHues that areappropriate for the type of information a'ailable. When ratio or distance scaledata are a'ailable for probability and loss, e5pected utility loss calculations areused. !oe'er, often only ordinal scale metrics are a'ailable for probability orutility loss.or e5ample, the risk scenarios might be ranked in terms of probability andutility loss each as shon in igure <.



1o select in this case the most important risks based on the combination of probability and utility loss, a specific #isit Pareto raning techni*ue is used.1his techniHue uses a to-dimensional space to position risk scenarios by theirrelati'e probability and utility loss as shon in igure ?. "sing this techniHue,the e'aluation of the risks is then based on utility theory J>[email protected] 'alue of this Riskit areto ranking techniHue is that it pro'ides a reliableand consistent ranking approach that only ranks risks as far as the input dataallos.



2! $ASE ST/D3 $ONTE4T

1eno'is is one of BermanyNs largest companies in the telecommunicationmarket. 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 allof 1eno'isN e5isting %P platforms. 1hus, this project as called 1ool!armoniIation roject. Starting at the end of LLL, the projectNs duration asplanned to be appro5imately one year.0n this project ne and challenging technologies ere to be applied. Webtechnology as to be used in a client-ser'er application conte5t. $dditionally,object-oriented technology as selected for design and implementation. 4nthe one hand, the ne technologies added comple5ity to the project, on theother hand, they ere e5pected to increase the projectNs producti'ity. %esides

the ne technologies, a ne de'elopment process and a ne projectorganiIation ere introduced, hich in'ol'ed teams from three differentlocations and time Iones (0ndia, rance, and Bermany).0n the early stages of the project, risk management as performed in aninformal ay. !oe'er, this intuiti'e risk management as considered to belonger appropriate for a company in the telecommunication market. 1hismarket is characteriIed by high competition, strong demand for inno'ati'etechnologies, and a 'ery short inno'ation cycle. 1hese factors usually imposerisks to telecommunication projects. 1he introduction of ne technologies andprocesses imposed additional risks. !ence this project as seen as particularlyrisky compared to other projects at 1eno'is.

1his situation made the case for the introduction of e5plicit, systematic, ande5perience-based risk management into this project.

5! TRANS6ER O6 RISK MANA1EMENT1he transfer of risk management to the 1eno'is conte5t as entrusted toraunhofer 0&S&, hich ser'ed as methodology pro'ider.1he Riskit method (see Section C) method as one part of the o'erall riskmanagement concept proposed to 1eno'is. $dditionally, this concept includedmethods to support risk management by data and to re-use risk e5perience infuture projects. Risk management by data uses specific data from ameasurement 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, hoe'er, deals only ith the applicationof Riskit. 0n the beginning, a kick-off orkshop took place. 1he participants inthis orkshop ere the department head, ho sponsored the implementationof risk management, and the project management team. 0n the orkshop, atutorial on Riskit as gi'en.$dditionally, the acti'ities of mandate and goal definition, risk identification,risk analysis, and risk control planning (cf. igure ) ere briefly performed for



the concrete project. $ similar orkshop as later performed for seniorde'elopers. We also defined specific templates for documenting riskinformation during the project (see igure F).or subseHuent risk management acti'ities, hich ere held in separatemeetings in addition to the regular project meetings, a risk management team

as established. 1his team consisted of the department head and to membersof the project management team. 1he latter ones changed o'er time.1he risk management team as supported by the personnel from raunhofer0&S&, ho had the role of facilitators in the risk management meetings. 0n thisrole they prepared the meetings by, for e5ample, selecting and preparing therisk management techniHues to be applied, pro'iding the necessary documents,and sending in'itations. uring the meetings they moderated the discussionsand took care of the correct applicat ion of the risk management techniHues. 0naddition, they ere responsible for the documentation of the meeting results.0n the course of the project, the introduction of risk management asnegati'ely affected by se'eral circumstances. irst, the project members

regarded risk management as 9yet another ne method: besides the neprocess and technologies, resulting in lo moti'ation for it. Second, theproject 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 DESI1N1he empirical study reported in this paper is a carefully designed case studyith predefined objecti'es and some le'el of control ith respect to theo'erall arrangements of the study. 1he authors ere obser'ing the study hilefacilitating it. 1he design of the case study started at the beginning of the

technology transfer. We first identified the research goals shon belo in theform of a BQM-goal template JEKJ>>KB /haracteriIe the usefulness and ade*uacy of the #isit ris management

process from the 'iepoint of the ris management participants in the conte5tof $enovis.1o us usefulness and adeHuacy mean the ad'antages and drabacks of riskmanagement ith respect to () the Riskit features, (i.e., the techniHues usedithin Riskit), (C) performing e5plicit risk management in general, (i.e., Riskit-independent issues), and (>) the transfer of the risk management process andmethods into the project.BC /haracteriIe the cost+&enefit of the #isit ris management process from

the 'iepoint of the department head and the project manager in the conte5tof $enovis. 1his goal aimed at assessing the economical impact of thetransferred risk management technology. "sing the Boal-Question-Metricaradigm JEKJ>>K, e refined these to goals in Huestions characteriIing theHuality aspects usefulness, adeHuacy, and cost-benefit. SubseHuently, erefined these Huestions into metrics defining the data to be collected toanser the Huestions and e'aluate the research goals. 1he identified metricsere of to types Huantitati'e metrics and Hualitati'e metrics.



1he Huantitati'e metrics included information like the effort spent on riskmanagement, 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 forthese 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 aspercei'ed by the participants and the ad'antages and drabacks of theemployed Riskit process and its techniHues as seen by the participants. 1ocollect the data for these metrics, e prepared a Huestionnaire containing >>Huestions and an associated inter'ie procedure (cf. igure @) for a structuredinter'ie. "sing these materials, e inter'ieed all fi'e members of the1eno'is risk management team at the end of the project, ith each inter'ielasting about one hour. 1he inter'ies ere held ith one inter'ieer and onescribe ho recorded the inter'ieeesN ansers. 1he recorded ansers ereentered into a database for better analysis. &ach inter'ieee as sent a reportith his entered ansers for re'ie.

1he inter'ie results ere combined and analyIed in order to anser theresearch goals and identify the strengths and eaknesses of the employed



approach. 0n addition to the inter'ie results, e also used the obser'ationse made as facilitators of the risk management meetings. 1hese obser'ationsere recorded after each meeting in a logbook and mainly referred topractices 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 tobetter tailor it to the en'ironment.1o 'erify our conclusions and suggested process impro'ement proposals, afeedback session ith the members of the risk management team (i.e., theinter'ieees) as performed. 1he impro'ed risk management process ill formthe basis for future risk management acti'ities at 1eno'is.&mpirical studies in general and case studies in particular are prone to biasesand 'alidity threats that make it difficult to control the Huality of the studyand to generaliIe its results J>CKJ><K. 0n the folloing e discuss selected,rele'ant 'alidity threats and describe the steps taken to reduce them or theirimpact 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 procedurein detail and applying them consistently.1he to main threats to i nternal 'alidity in the study ere e5perimentere5pectation bias and maturation J>?K. 1he e!perimenter e!pectation &ias couldoccur due to the technology pro'idersN e5pectations or desire to see positi'eresults in a study. 1his bias as reduced by carefully discussing and e'aluatingthe facilitator obser'ations and findings and emphasiIing the 1eno'isparticipant feedback on them. $lso, e kept logbooks after each meeting torecord our obser'ations in their original form, hich helped us to rememberthe precise obser'ations and their conte5ts e'en after some time. 1he

maturation effect threatens the conclusions of a study hen subjects reactdifferently as time passes. 0n our case this could ha'e been possible as theparticipants ere just going up their learning cur'e on risk management andthus became more fluent in its acti'ities o'er time. !oe'er, the inter'iestook place at the end of the project in a short period of time hen theparticipants 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 elle can generaliIe the results, i.e., to e5ternal 'alidity. 1he project itself asmore risky and had perhaps higher e5pectation le'els than normal projects inthe company. We belie'e that this had to impacts 4n the one hand, this may

ha'e biased the participants to recogniIe the need for risk management moreclearly, resulting in a generally positi'e attitude toards risk management. 4nthe other hand, the pressures of aggressi'e project goals may ha'e alsoreduced the time a'ailable for risk management acti'ities by simultaneouslyincreasing the e5pectations from risk management results. 1his could ha'eresulted in a more negati'e attitude toards the impact of risk management onthe project. Regarding the representati'eness of the project participants, e



ha'e no specific reason or information to belie'e that the participants ouldbe different from those of other projects.

! $ASE ST/D3 RES/+TS!" Results -or Riskit8s /se-ulness

0n this section e report the findings of our obser'ations and the inter'ies.Section @.. describes our findings related to the Riskit method itself, [email protected] describes our findings related to the performance of the risk managementin the 1eno'is project, and Section @..> describes our findings related to thetransfer of risk management into the conte5t of 1eno'is.,"-"- .sefulness/Ade*uacy of the #isit Process 4ne crucial element in theinter'ies as the Huestion For each activity in the #isit process' what arethe advantages and pro&lems perceived &y the participants 0n the folloing,e report the most important findings related to the indi'idual acti'ities andtechniHues in the Riskit process. Process definition 4ne feature of Riskit is thefull operational definition of its process. 1his e5plicit process as percei'ed as

systematic and 'ery helpful. "nlike 9intuiti'e: risk management, here risksare unsystematically identified at the beginning and not appropriately tracked,the process triggers all necessary acti'ities. 4ne positi'e side effect of thee5plicit process is also that the importance of risk management is emphasiIedas people dedicate their time to ork specifically on risk managementacti'ities. #is 0dentification( 1o identify risks, the Riskit process pro'ides totechniHues, hich compensate each otherNs biases. 1he to techniHues arebrainstorming and a risk checklist. 0n this case, e used an e5cerpt of the S&0checklists for risks J*K.1he combination of these techniHues as appreciated as being systematic andcomprehensi'e. Retrospecti'ely, the participants noted that most of the

projectNs risks ere identified during risk identification. $dditionally, thecomposition 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'ies on potential risks could be e5changed and combined. /onseHuently,almost all participants learned about risks that ere ne to them. #is

Analysis $s shon in igure >, Riskit uses $nalysis Braphs to describe anddiscuss risks. 1hese $nalysis Braphs ere rated as 'ery helpful in understandingthe risk, its conte5t, and its conseHuences. 4ne benefit of these graphs asclearly the 'isual representation, hich made the risks more e5plicit andfacilitated discussions about them. $lthough the de'elopment of these graphsas time consuming (discussion of a risk e'ent and de'elopment of the

corresponding scenario took about F min on a'erage), participants regardedthis 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 rankrisks and select the most important ones. 1his areto ranking techniHue aspercei'ed as beneficial and practical as people could easily compare the risksin terms of probability and utility loss. &specially for the latter it asappreciated that no precise, Huantitati'e estimate of the loss had to be gi'enbut measurement as performed through ranking the risks (i.e., for to risks it



had only to be determined, hich risk had the larger loss). 1he selection of themost important risks based on the combination of probability and loss asperformed by means of a areto-table JC?K. 1hi s selection as regarded ascomprehensible 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 beteendifferent acti'ities of the process as ell as beteen different meetings. 1hemost central form is the Risk Scenario orm (cf. igure 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 andimplemented controlling actions, as ell as a history of the risk and itscontrolling actions. 1hus, it contains complete information both for operationalpurposes (i.e., monitoring of controlling actions) and documentation purposes(hich are supposed to enable learning from risks for future projects).%ased on the inter'ies, three disad'antages of the forms ere obser'ed.irst, the forms contain too much information for daily ork, especially for risk

monitoring. uring risk monitoring, participants ere only interested in thegraphical description of the risk and the list of controlling actions./onseHuently, the remaining information as seen as superfluous for thisacti'ity.Second, the te5tual description of the risks as kept 'ery short and thus mainlyconsisted of keyords. 1his amount of detail as sufficient as long as theparticipants remained the same. !oe'er, in the course of the project, nemembers joined the risk management team. or them it as difficult toacHuire the necessary understanding of the risks due to their short description.1he lack of clear descriptions has the additional disad'antage of complicatingthe re-use of risk e5perience in future projects.

1hird, the effort for maintaining the documentation as considered too high(cf. igure E). $fter a risk monitoring meeting, hich as to be performed bi-eekly, the facilitator team spent about to 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 asperformed manually in the entire documentation, hich as ritten in MS-Word ith a comple5 link structure. 1his draback of the process in terms of documentation o'erhead can be easily o'ercome by an appropriate toolsupport for the documentation, such as a simple database solution. 1hissolution also enables project managers to ha'e fast access to risk information.SummariIing our findings ith respect to the Riskit method, e can conclude

1he e5plicit process of the Riskit method as regarded as systematic andpractical. 1he techniHues used ithin the Riskit method ere regarded as practical andunderstandable. 1he distinguishing features of Riskit, especially, ere regardedas particularly 'aluable.



,"-"1 0nstantiation of #is Management at $enovis1he crucial Huestion For each activity in the #isit 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, theseobser'ations are of a more general nature.0ntegration with project management and project wor 1he acti'ities of theRiskit process ere performed in dedicated meetings ith the members of therisk management team. 1his as also true for the more freHuent riskmonitoring meetings. 1his separation from the project meetings asretrospecti'ely seen as a draback, since the project members (especially sub-project managers but also de'elopers) ere not included in the riskmanagement acti'ities.1o o'ercome this problem in the future, a stronger linkage beteen projectork and risk management is intended. #is 0dentification 0n this project, riskidentification as performed intensi'ely at the beginning. 3et, although duringrisk monitoring, se'eral ne risks ere identified spontaneously, no riskidentification meeting as performed in the subseHuent course of the project.1his fact as seen as a draback as risks that ere 1his high-le'el Huestionas refined in the actual Huestionnaire and related to all acti'ities and



techniHues in the Riskit process. unknon at the beginning of the project erenot systematically included in risk management. 1herefore, in the future, riskidentification meetings ill be scheduled automatically at pre-definedmilestones.#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 hasto 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. 1odrabacks ere obser'ed ith our approach. irst, although bi-eekly riskmonitoring meetings ere intended, it turned out that the inter'als beteenthe risk management meetings ere longer due to non-a'ailability of thefacilitators 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 andcontrolling action statuses. Moreo'er, due to the long inter'als, it as difficultfor participants to remember the conte5t of the risks and their controllingactions.

Second, it is the task of risk monitoring to assess the status and effecti'enessof the controlling actions. 0n the project, this as done by asking about thestatus of the controlling action, its impact on the risk (here usually a rating of high, medium, loT or a short sentence as gi'en), and hether thecombination of controlling actions effecti'ely controls the risk. Retrospecti'ely,the participants thought that the controlling actions ere not performed asplanned and therefore ere not as effecti'e as they could ha'e been. 1hiscould ha'e been pre'ented Braphical representation of scenario

Risk (istory9>.>.** risk probably smaller, because people are aare 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 futureCL.?.** risk unchanged= controlling actions sufficient>.@.** Re-ranking changed probability from > to C, ne utility loss for projectleader assessed>*.@.** risk unchanged= controlling actions sufficientC?.E.** action < as stopped since an e'aluation of a /ode /hecker ascompletedaction ? as stopped because this is an integral part of the tasks of the projectleader and line managers

$ontrollin, A:tion (istory$ontrollin,A:tion Impa:t CL.?.** introduced= impact see follo-up controlling action @C >.>.** minorCL.?.** re'eals the effecti'eness of training>*.@.** currently no training



C?.*E.** effect positi'e as people do build up kno ho= through themonitoring the need for additional training has been detected

Teno&is Risk S:enario 6ormID - poor Huality code 6re'ieGtutoring Pro;e:t9 1ool !armoniIation

O.ner<Responsible Date re&ie.e* C***-*C-*Time-rame Priority /ontrolled Probability CStake%ol*er9 1eno'is Mgmt +oss >Stake%ol*er9 ept. ead +oss <Stake%ol*er roject eader +oss <

Action Respons. State Finish CheckSele:te* risk:ontrollin, a:tions 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

$losin, *ate $losin, Rationale6i,ure =9 Risk S:enario 6orm -or one risk e&entby more strongly Huestioning the controlling action. 1hus, in the future, theactual implementation of the controlling action (hat#) and its impact on therisk (ho good#) has to be more strongly Huestioned.SummariIing our findings related to the instantiation of risk management, e

can conclude Risk management should be closely integrated ith project management anddaily project ork to foster the synergy beteen these acti'ities. Risk identification should be scheduled automatically at predefinedmilestones (and, additionally, hene'er it is seen as necessary). Risk monitoring should be performed regularly ith short inter'als beteento meetings. Risk monitoring has to sufficiently Huestion the implementation of controllingactions 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 riskmanagement into the conte5t of 1eno'is. 1o assess the adeHuacy of thetransfer, the Huestionnaire contained the Huestions like How did you perceivethe wor split &etween $enovis and 0ESE and From your point of view' how strong was the commitment for ris management from the 3architects1'management' yourself T#



$raining 1he training gi'en to participants as seen as essential as it pro'idedthe necessary background for risk management and its techniHues in general asell as for Riskit in particular.0n the future, hoe'er, not only the project and department managementshould 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 riskmanagement is to be more included in the project ork). 4n the other hand,the training can also raise the aareness of risk management and risks.Process 4wnership $s described in Section <, the technology as transferredby the personnel from 0&S&, ho performed the entire facilitation in themeetings and maintained the documentation. 1he facilitators also triggered therisk management meetings. 0nitially, it as planned to gi'e this responsibility tothe 1eno'is personnel in the course of the project, but due to time restrictionsthis did not happen as planned.1hus, process onership remained ith the facilitators and not ith theproject 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 1oimpro'e this in the future, the process onership for risk management has torest ith the project manager, ho has to take care of the e5ecution of theprocess, in'ite the participants to the risk management meetings, and ensureimplementation of the controlling actions.1hus, the role of the technology pro'ider 0&S& should be to facilitate the firstfe sessions, take part in the folloing sessions as obser'ers, and finally lea'ethe 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 riskmanagement, the project manager is the crucial person as sGhe is the personmaking decisions and being responsible for the acti'ities in the project. 1hisalso includes acti'ities that arise from controlling actions, and moti'ating thede'elopment team. Moreo'er, risk management is part of hisGher projectmanagement task.1he actual approach of our transfer as prone to gi'e the project manager theimpression that an e5ternal party (i.e., the facilitators) inter'ened in his tasksand authorities as project manager.1herefore, in addition to the changed technology transfer approach (seeabo'e), the commitment of the project leader has to be ensured from the

beginning and the transfer approach must be coordinated ith the projectmanager.SummariIing our findings related to the transfer of risk management, e canconclude 1raining of the employed risk management process is important to train theparticipants and raise aareness for risk management and risks. rocess 4nership for risk management has to rest ith the project manager.



/ommitment of the project manager is of utmost importance and has to beensured from the beginning.

!0 Results -or t%e $ost>Bene-it o- Riskit$n important criterion for introducing a ne technology is its cost-benefit

relationship. or risk management, hoe'er, this relationship is hard to e5pressHuantitati'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 thesubjecti'e assessment of the benefits as seen from the risk management team.0n the folloing, e first describe the costs and benefits separately and thencombine both aspects.1he cost of risk management can be measured in terms of the effort that isspent on the acti'ities of the risk management process. igure E shos theeffort spent in this case study. 0n total, C> person days ere spent in total fromthe project team and facilitator team, hich represents ?+ of the o'eralleffort for project management.

1o assess the benefits of risk management, e collected Huantitati'emeasurement data on the number of risks, the number and effecti'eness of thecontrolling actions as ell as Hualitati'e data in terms as the benefitssubjecti'ely seen by the participants.

0n igure L, the number of risks identified andGor tracked in this project isshon o'er the projectNs time.



0t can be seen that the number of identified but not analyIed risks (i.e., rarisks) is Huite large. 1hus, a relati'ely small proportion of those risks identifiedduring risk identification as considered during risk analysis. 0t can also beobser'ed that no major risk identification took place after 8une. 1his can beattributed to problems in the project. De'ertheless, participants thoughtretrospecti'ely that the controlled risks contained most of the projectNsimportant risks.or the controlled risks igure * shos the impact of the controlling actions onthe risk. 1he risk management team assessed the impact subjecti'ely on ascale of high, medium, lo, no impact, unknon impactT. $s can be seen,about G? of the defined controlling actions shoed high impact on pre'entingor reducing the risk. 1hus, for these controlling actions it can be concludedthat their implementation as 'aluable for the project as they effecti'elycontributed to the mitigation of the corresponding risk.4n the other hand, it can also be seen that a large proportion of controllingactions is rated as unnown impact" 1his situation corroborates the abo'e-mentioned finding that the impact of the controlling actions as notsufficiently Huestioned and that many controlling actions ere notimplemented as planned.1o foster Hualitati'e assessment of the benefits of risk management, ourHuestionnaire contained the Huestion 5hat was the overall impact of rismanagement on the project !ere, participants stressed the systematic and sound approach of an e5plicitrisk management process that as definitely an impro'ement o'er the moreintuiti'e risk management performed prior to the introduction of Riskit.



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

0n order to decide hether risk management should be implemented in a neproject ithin 1eno'is or a ne company, the ratio beteen cost and benefithas to be taken into account. ue to the Hualitati'e nature of the benefits, theratio can only be assessed subjecti'ely. 1herefore e asked the participantsConsidering the effort spent on ris management' the num&er of

identified/controlled riss' 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, theyregarded the impact of risk management on the project in this case study astoo lo. 1hey rated the relationship beteen cost and benefit for the projectas negati'e or neutral at best.!oe'er, since the lo impact of risk management on the project can beattributed to the eak implementation of the controlling actions, there is aclear potential for impro'ing the cost-benefit in the future ith the e5periencefrom 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 projectmanagement as seen as orth the cost. %ecause of this and the prospect thatimpro'ed risk management ill also ha'e a stronger impact on the projectitself, management ill continue implementing e5plicit risk management usingtheconcepts of Riskit in future projects. SummariIing our findings related to thecost and benefit e can conclude



1he cost of risk management accounted for ?+ of the o'erall projectmanagement effort, hich as seen as acceptable. $t management le'el, the e5istence of more professional projectmanagement as seen as orth the cost. 1he impact of risk management on the project as seen as too lo. With

impro'ed risk management, hoe'er, this impact can be impro'ed respecti'ely.

!2 $omparison .it% Ot%er $ase Stu*ies0n order to generaliIe the results of our study, e performed a cross-caseanalysis J><K and compared our findings ith the findings of three earlier casestudies 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 differentmethod. 0n this study, the 'isual appeal and understandability of the Riskitanalysis graphs as emphasiIed. urthermore, this study found that usersreported 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'edfrom our study.$dditionally, the D$S$ study found that the Riskit method produced moredetailed controlling actions. $lthough in our study, the 1eno'is participantsregarded the implementation of the controlling actions as eak, they,ne'ertheless, acknoledged that the controlling actions ould ha'e had auseful 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 themanagement effort as spent on risk management, hereas in the 1eno'isproject this figure as ?+. 4ne potential e5planation for this difference couldbe the substantially smaller siIe of the D$S$ project. $nother possible

e5planation could be the fact that the Riskit method itself as in its earlyde'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/hryslerJCFK, e'aluated the feasibility and usefulness of Riskit. $dditionally, the studytried to identify issues related to the introduction of risk management. 0n thissecond study, the folloing obser'ations ere made Moti'ation and clear definition of responsibilities are necessary for successfulrisk management. roject time pressures continually limit the time a'ailable for riskmanagement.

Systematic risk management as percei'ed as beneficial and seemed toimpro'e participantsN confidence in risk management results.

1hese findings are similar to the ones presented in this paper. !oe'er, somefindings differ. 1he aimler/hrysler study indicated that users had difficultiesunderstanding and using Riskit analysis graphs hereas in our study thesegraphs ere considered 'ery helpful. We belie'e that a major reason for thisdifference as the amount of training gi'en to participants. 0n the



aimler/hrysler study, one to to hours of training ere gi'en to the riskmanagement participants, hereas in the 1eno'is study, a full-day orkshopith e5ercises using material from the actual project as performed.1his e5planation of factors impacting the understandability of the Riskitanalysis graphs emphasiIes our finding that appropriate training is essential for

a successful technology transfer for Riskit. 1he third study, hich asperformed by Betto and andes in the conte5t of aimler/hrysler in LLL JEK,emphasiIed the need for efficiency in risk management. $gain, this is similar tothe findings of our study.1his third study also emphasiIed the importance of stakeholders as defined inRiskit (cf. igure C), a fact that as also reported in the second studyperformed at Dokia and aimler/hrysler. 0n our study, the concept of stakeholders as not e5plicitly mentioned in the case study inter'ies by theinter'ieees. 3et, during the course of the project, discussions took place inthe risk management team on stakeholders, their goals, and their goalpriorities.

0n summary, the findings in all four studies seem to be fairly consistent and thenatural 'ariance in the ay the method as applied in the 'arious conte5ts canbe 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 thate 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. E!plicit and systematic ris management is perceived as useful &y projectmanagement. rior to RiskitNsimplementation the project managers performed most of the risk management

acti'ities, albeit in an informal and intuiti'e ay. !oe'er, the e5plicit andsystematic ay as percei'ed as a 'aluable add-on to their daily practices. $he distinguishing features of #isit were perceived as practical and understanda&le" uring risk identification, the combination of checklists andbrainstorming allos both to include the e5perience and insight of theparticipants and, simultaneously, check systematically for typical risks. uringrisk analysis, the Riskit scenarios pro'ided an effecti'e ay to understand anddiscuss about risks. uring selection of the most important risks, the aretotable allos to take into account both the probability and utility losseffecti'ely and comprehensibly e'en though they are measured by ordinal scalemetrics.

Monitoring is one of the most important activities" $ 'ital prereHuisite forsuccessful risk mitigation is the ability to react Huickly to changes in the statusof a risk or its controlling actions, as early as possible. Risk monitoring on aregular basis is the key to this prereHuisite. 1he method used for monitoringshould be carefully selected to a'oid tedious repetition, and thedocumentation should support the reHuirements of monitoring, as it is theacti'ity that is performed most freHuently.



Ensure seamless integration of ris management activities into the overall project wor" Regular project meetings should be used to perform the riskmanagement acti'ities. 1his is especially true for risk monitoring. Regularmeetings 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 managementacti'ities as additional burden but as part of their routine ork. 1heintegration should also force an appropriate le'el of documentation. Ensure the commitment of the project manager when implementing rismanagement" $lthough upper management often decides on the introductionof 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'incehis or her project team. 1herefore, the project managerNs commitment is of crucial importance for successful technology transfer. Process ownership of customi6ed ris management process" $lthough at thebeginning of the technology transfer, the technology pro'ider has the

e5perience and competence ith risk management, it is 'ery important thatthe project manager takes o'er responsibility for the customiIed process. 1hisonership is necessary to adapt the process to the projectNs needs Huickly andefficiently, and to perform the process in the most effecti'e and systematicay. 1he role of the technology pro'ider is to ad'ise and support the projectmanager.

?! $ON$+/SION0n this paper, e presented a case study of implementing risk management at1eno'is. 1he objecti'es of the case study ere, on the one hand, to analyIethe 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 thecost-benefit of Riskit in an industrial conte5t.4ur results sho that Riskit is a practical and understandable risk managementmethod. 0ts techniHues for describing risks (Risk Scenarios) and for selectingthe most important risks (areto ranking techniHue) ere highly appreciated bythe risk management team. While the costs for risk management ere seen asacceptable, its impact on the project ere, in this particular case, consideredtoo lo. 3et, the e5periences from this case study can be used to impro'e riskmanagement at 1eno'is and thus increase its cost effecti'eness. 4n amanagement, le'el the e5istence of a more professional project managementas seen as orth the costs. $dditionally, e reported se'eral lessons learned

for both risk management in general, and Riskit in particular. 1hey can beuseful for all project managers ho are considering the introduction of e5plicitrisk management.

@! A$KNOW+ED1EMENTSWe ould like to thank the participants of the 1eno'is Risk ManagementMeetings for their commitment and their collaboration hen e performed thecase study inter'ies. $dditionally, e ould like to thank Sonnhild Damingha



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

tugas-manajemen-reiko.doc

Documents