Modul Manajemen Proyek Sistem Informasi [tm9] 4n2q3w

MODUL PERKULIAHAN

Manajemen Proyek Sistem Informasi        

Strategi Risiko Reaktif & Proaktif Risiko Perangkat Lunak Identifikasi Risiko Proyeksi Risiko Pengurangan, Monitoring dan Manajemen Risiko Risiko Keselamatan dan Bahaya RMMM Plan

Fakultas

Program Studi

Fakultas Ilmu Komputer

Sistem Informasi

Tatap Muka

09

Kode MK

Disusun Oleh

18025

Bima Cahya Putra, M.Kom

Abstract

Kompetensi

Manajemen Risiko Proyek: Proses sistematis untuk merencanakan, mengidentifikasi, menganalisis, dan merespon risiko proyek. Tujuannya untuk meningkatkan peluang dan dampak peristiwa positif, dan mengurangi peluang dan dampak peristiwa yang merugikan proyek.

Mahasiswa mampu melakukan idintifikasi risiko. Mampu menganalisa risiko, penyebab, dan akibatnya pada sebuah proyek sistem informasi. Mampu melakukan monitoring dan pengendalian atas risiko – risko yang mungkin timbul.

Manajemen Resiko Proyek Robert Charette : Pertama: Risiko berhubungan dengan kejadian di masa yang akan datang. Sekarang dan kemarin tidak mendapat perhatian aktif, karena kita telah mendapatkan apa yang kita tabur lewat sepak terjang kita di masa lalu. Persoalannya adalah dengan mengubah sepak terjang kita, kita dapat menciptakan kesempatan untuk suatu keadaan yang lebih baik dan berbeda untuk kita sendiri besok. Kedua , bahwa risiko melibatkan perubahan, seperti dalam perubahan pikiran, pendapat, aksi atau tempat. Ketiga, risiko melibatkan pilihan dan ketidakpastian bahwa pilihan itu akan dilakukan. Bila risiko dipertimbangkan dalam konteks pembangunan sistem (RPL), tiga almari Cahrette selalu menjadi bukti. Masa yang akan datang adalah perhatian kita –risiko apa yang akan menyebabkan proyek Sistem informasi menjadi serba salah? Perubahan adalah perhatian kita, bagaimana perubahan pada persyaratan pelanggan, teknologi pengembangan, komputer target, dan semua entitas lain yang berhubungan dengan proyek, mempengaruhi ketepatan waktu dan keberhasilan keseluruhan

Strategi Risiko Reaktif VS Proaktif

Strategi reaksi reaktif secara menggelikan disebut “sekolah manajemen risiko Indiana Jones”. Pada film tersebut, Indiana Jones, pada saat dihadapkan dengan bermacam-macam kesulitan akan tetap mengatakan, “jangan khawatir, aku akan memikirkan sesuatu!” Tidak pernah mengkhawatirkan masalah sampai mereka benar-benar terjadi, di mana Indi akan beraksi secara heroik. Sayangnya, rata-rata manajer proyek tidak seperti Indiana Jones. Mayoritas tim perangkat lunak hanya bersandar pada strategi reaktif. Pada titik terbaik, strategi reaktif memonitor proyek terhadap kemungkinan risiko. Strategi yang benar-benar lebih baik untuk manajemen risiko adalah bersikap proaktif. Strategi proaktif dimulai lama sebelum kerja teknis diawali. Resiko potensial diidentifikasi, probabilitas dan pengaruh proyek diperkirakan, dan dirioritaskan menurut kepentingan. Tim 2015

2

Manajemen Proyek Sistem Informasi Bima Cahya Putra, M.Kom

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

perangkat lunak kemudian membangun suatu rencana untuk manajemen resiko. Sasarannya adalah menghindari resiko.

Risiko Perangkat Lunak

Risiko selalu melibatkan dua karakteristik : 

Ketidakpastian – kejadian yang menandai risiko mungkin atau tidak mungkin terjadi;



Rugi – bila risiko menjadi realitas, akibat yang tidak diinginkan atau kerugian akan dialami.

Risiko proyek mengancam rencana proyek. Yaitu, bila risiko proyek menjadi nyata, ada kemungkinan jadwal proyek akan mengalami slip dan bahwa biaya menjadi bertambah. Risiko proyek mengidentifikasi hal potensial yang berhubungan dengan pembiayaan, jadwal, personil (staffing dan organisasi), sumber-sumber daya, pelanggan dan masalah persyaratan serta pengaruhnya terhadap proyek perangkat lunak. Risiko teknis mengancam kualitas dan ketepatan waktu perangkat lunak yang akan dihasilkan. Risiko teknis mengidentifikasi desain potensial, implementasi, interfacing, verifikasi dan masalah pemeliharaan. Ambiguitas, spesifikasi, ketidakpastian teknik, keusangan teknik, dan teknologi yang leading edge juga merupakan faktor risiko. Risiko bisnis mengancam viabilitas perangkat lunak yang akan dibangun. Kandidat untuk lima risiko bisnis utama adalah : (1). Pembangunan produk atau sistem yang baik sekali yang sebenarnya tidak pernah diinginkan oleh setiap orang (risiko pasar); (2). Pembangun sebuah produk yang tidak lagi sesuai dengan keseluruhan strategis bisnis bagi perusahaan (risiko strategis); (3). Pembangunan sebuah produk di mana bagian pemasaran tidak tahu bagaimana harus menjualnya; (4). Kehilangan dukungan manajemen senior sehubungan dengan perubahan pada fokus atau perubahan pada manusia (risiko manajemen); (5). Kehilangan hal-hal yang berhubungan dengan biaya atau komitmen personal (risiko biaya).

Kategori resiko umum lainnya telah diusulkan oleh Charette yaitu : Risiko yang sudah diketahui adalah risiko yang dapat diungkap setalh dilakukan evaluasi secara hati-hati terhadap rencana proyek, bisnis, dan lingkungan teknik di mana proyek sedang dikembangkan, dan sumber informasi reliabel lainnya (seperti tanggal penyampaian

2015

3

Manajemen Proyek Sistem Informasi Bima Cahya Putra, M.Kom

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

yang tidak realistis, kurangnya persyaratan yang terdokumentasi atau ruang lingkup perangkat lunak, lingkungan pengembangan yang buruk). Risiko yang dapat diramalkan diekstrapolasi dari pengalaman proyek sebelumnya (misalnya, pergantian staf, komunikasi yang buruk dengan para pelanggan, mengurangi usaha staf bila permintaan pemeliharaan yang sedang berlangsung dilayani). Risiko yang tidak diharapkan dapat benar-benar terjadi, tetapi sangat sulit untuk diidentifikasi sebelumnya.

Identifikasi Risiko

Identifikasi risiko adalah usaha sistematis untuk menentukan ancaman terhadap rencana proyek (perkiraan, jadwal, pemuatan sumber daya, dll). Ada dua tipe risiko yang berbeda : risiko generik dan risiko produk spesifik.. Risiko generik merupakan ancaman potensial pada setiap proyek perangkat lunak. Risiko produk spesifik hanya dapat diidentifikasi oleh mereka dengan pemahaman khusus mengenai teknologi tsb, manusia, serta lingkungan yang spesifik terhadap proyek yang ada. Tom Gilb menyatakan: “Bila anda tidak aktif menyerang risiko, maka risiko akan aktif menyerang anda.” Metode untuk mengidentifikasi risiko adalah menciptakan cheklist item risiko. Checklist dapat digunakan pada identifikasi risiko dan berfokus pada beberapa himpunan bagian risiko yang sudah diketahui dan diprediksi dalam sub kategori berikut ini : 

Ukuran produk – risiko sehubungan dengan keseluruhan ukuran perangkat lunak yang akan dibangun atau dimodifikasi.



Pengaruh bisnis – risiko sehubungan dengan batasan yang dibebankan oleh manajemen atau pasar.



Karakteristik pelanggan – risiko sehubungan dengan kepintaran pelanggan dan kemampuan pengembang untuk berkomunikasi dengan pelangan dengan cara yang tepat.



Definisi proses – risiko sehubungan dengan tingkat di mana proses perangkat lunak telah didefinisikan dan diikuti oleh organisasi pengembangan.



Lingkungan pengembang – risiko sehubungan dengan keberadaan dan kualitas peranti yang akan digunakan untuk membangun produk.



Teknologi yang akan dibangun – risiko sehubungan dengan kompleksitas sistem yang akan dibangun dan “kebaruan” teknologi yang dikemas oleh sistem.



Ukuran dan pengalaman staf – risiko sehubungan dengan keseluruhan teknik dan pengalaman proyek dari rekayasa perangkat lunak yang akan melakukan tugas tersebut.

2015

4

Manajemen Proyek Sistem Informasi Bima Cahya Putra, M.Kom

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

Risiko Ukuran Produk Checklist item risiko berikut mengidentifikasi risiko generik yang berhubungan dengan ukuran produk (perangkat lunak) : 

Berapa ukuran produk diperkirakan dalam LOC atau FP?



Ukuran produk yang diestimasi dalam jumlah program, file, transaksi?



Ukuran database yang dibuat atau digunakan oleh produk?



Jumlah pemakai produk?



Jumlah perangkat lunak yang dipergunakan kembali?

Risiko-risko Yang Mempengaruhi Bisnis Checklist item risiko berikut mengidentifikasi risiko generik yang berhubungan dengan pengaruh bisnis: 

Pengaruh produk terhadap hasil perusahaan?



Kelayakan deadline penyampaian?



Jumlah pelanggan yang akan menggunakan produk dan konsistensi kebutuhan relatif mereka dengan produk tersebut?



Kepintaran pemakai akhir?



Biaya yang berhubungan dengan penyampaian yang terlambat?

Risiko Yang Dihubungankan Dengan Pelanggan Semua pelanggan tidak diciptakan sama. Pressman dan Herron membahas masalah ini dengan menyatakan :  Pelanggan mempunyai keinginan yang berbeda.  Pelanggan memiliki kepribadian yang berbeda.  Pelanggan juga memiliki hubungan yang bervariasi dengan pemasok mereka.  Pelanggan juga kadang-kadang bertentangan.

Checklist item risiko berikut mengidentifikasi risiko generik yang berhubungan dengan para pelanggan yang berbeda: 

Pernahkah anda sebelumnya bekerja dengan pelanggan?



Apakah pelanggan memilki gagasan yang solid mengenai apa yang diperlukannya? Sudahkan pelanggan menggunakan waktunya untuk menuliskannya?

2015

5

Manajemen Proyek Sistem Informasi Bima Cahya Putra, M.Kom

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id



Apakah pelanggan bersedia membangun sambungan komunikasi cepat dengan pengembang?



Apakah pelanggan bersedia berpartisipasi dalam kajian?



Apakah pelanggan memahami proses perangkat lunak tersebut?

Risiko Proses Contoh risiko yang berhubungan dengan masalah-masalah proses : 

Apakah manajemen senior anda mendukung suatu pernyataan kebijakan yang menekankan pentingnya suatu prses standar untuk pengembangan proses?



Sudahkan organisasi anda mengembangkan suatu deskripsi tertulis mengenai proses perangkat lunak yang akan digunakan pada proyek ini?



Apakah anggota-anggota staf “ditugasi” ke proses perangkat lunak pada saat perangkat lunak didokumentasi dan bersedia menggunakannya?



Apakah proses perangkat lunak digunakan untuk proyek lain?



Apakah kajian teknis formal terhadap spesifikasi persyaratan, desain dan kode dilakukan secara reguler?

Contoh risiko yang berhubungan dengan masalah-masalah teknis : 

Apakah digunakan teknik spesifikasi aplikasi untuk membantu komunikasi di antara pelanggan dan pengembang?



Apakah metode spesifikasi digunakan untuk analisis perangkat lunak?



Apakah anda melihat suatu metode spesifik untuk data dan desain arsitektur?



Apakah digunakan peranti perangkat lunak untuk mendukung perencanaan dan aktivitas penelusuran?



Apakah metrik kualitas dikumpulkan bagi semua proyek perangkat lunak?

Risiko Teknologi Checklist item risiko berikut mengidentifikasi risiko generik yang berhubungan dengan teknologi yang akan dibangun: 

Apakah teknologi yang akan dibangun adalah hal yang baru untuk organisasi anda?



Apakah persyaratan pelanggan memerlukan kreasi algoritma baru atau teknologi input atau output?

2015

6

Manajemen Proyek Sistem Informasi Bima Cahya Putra, M.Kom

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id



Apakah perangkat lunak ber-interface dengan perangkat keras baru atau belum terbukti?



Apakah perangkat lunak yang akan dibangun ber-interface dengan produk perangkat lunak yang dipasok oleh vendor yang belum terbukti?



Apakah perangkat lunak yang akan dibangun ber-interface dengan suatu sistem database yang fungsi dan kinerjanya belum dibuktikan di dalam area aplikasi ini?

Risiko Lingkungan Pengembang Checklist item risiko berikut mengidentifikasi risiko generik yang berhubungan dengan lingkungan pengembang: 

Apakah peranti manajemen proyek dapat diperoleh?



Apakah peranti manajemen proses dapat diperoleh



Apakah peranti untuk analisis dan desain dapat diperoleh?



Apakah kompiler atau pembangkit kode dapat diperoleh dan sesuai untuk produk yang akan dibangun?



Sudahkan anggota tim proyek menerima pelatihan dengan masing-masing peranti?

Risiko Yang Berhubungan Dengan Ukuran Staf Dan Pengalaman Checklist item risiko berikut mengidentifikasi risiko generik yang berhubungan dengan ukuran staf dan pengalaman (diusulkan Boehm): 

Apakah orang-orang terbaik dapat didapatkan?



Apakah orang-orang tsb memiliki gabungan ketrampilan yang benar?



Apakah orang-orang yang ada mencukupi?



Akankah banyak staf proyek bekerja dalam paruh waktu pada proyek ini?



Sudahkan staf menerima pelatihan yang memadai?

Komponen Risiko Dan Driver Komponen risiko didefinisikan dengan cara berikut : 

Risiko kinerja – tingkat ketidakpastian di mana produk akan memenuhi persyaratannya dan cocok dengan penggunaannya.



2015

Risiko biaya – tingkat ketidakpastian di mana biaya proyek akan dijaga.

7

Manajemen Proyek Sistem Informasi Bima Cahya Putra, M.Kom

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id



Risiko dukungan – tingkat ketidakpastian di mana perangkat lunak akan mudah dikoreksi, disesuaikan dan ditingkatkan.



Risiko jadwal – tingkat ketidakpastian di mana jadwal proyek akan dijaga dan produk akan disampaikan tepat waktu.



Pengaruh driver risiko terhadap komponen risiko dibagi ke dalam satu dari empat kategori pengaruh – diabaikan, marjinal, kritis dan katastropis.

Proyeksi Risiko Proyeksi risiko yang disebut juga perkiraan risiko, berusaha menjangkau setiap risiko dalam dua cara – kemungkinan atau probabilitas di mana risiko adalah nyata dan konsekuensi masalah yang berhubungan dengan risiko, yang harus terjadi. Perencana proyek bersama dengan manajer dan staf teknik lain, melakukan empat aktivitas proyeksi risiko : 1) membangun suatu skala yang merefleksikan kemungkinan risiko yang dirasakan; 2) menggambarkan konsekuensi risiko 3) memperkirakan pengaruh risiko pada proyek dan produk 4) mencatat keseluruhan akurasi proyeksi risiko sehingga tidak akan ada kesalahpahaman.

Mengembangkan Tabel Risiko Tabel risiko memberi manajer proyek sebuah teknik sederhana bagi proyeksi risiko. Tabel risiko sampel ditunjukkan pada gambar 6.2. Risiko

Kategori

Prob.

Pengaruh

Estimasi ukuran rendah secara signifikan

PS

60%

2

Jumlah pemakai lebih besar dari yang PS

30%

3

70%

2

diharapkan Pemakaian ulang lebih rendah dari yang PS diharapkan Pemakai akhir menolak sistem

BU

40%

3

Deadline pengiriman akan diperketat

BU

50%

2

Pendanaan dihapuskan

CU

40%

1

Pelanggan akan mengubah kebutuhan

PS

80%

2

Teknologi tidak memenuhi harapan

TE

30%

1

Kurangnya pelatihan pada peranti

DE

80%

3

Staf tidak berpengalaman

ST

30%

2

2015

8

Manajemen Proyek Sistem Informasi Bima Cahya Putra, M.Kom

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

RMMM

Turnover staf tinggi

ST

60%

2

Dst Nilai pengaruh 1 – katastropis 2 – kritis

3 – marjinal

4 – dapat diabaikan

Gambar 6.2. Contoh tabel risiko yang mengutamakan pengertian

Begitu empat kolom yang pertama dari tabel risiko telah diselesaikan maka tabel itu diurutkan sesuai probabilitas dan pengaruhnya. Probabilitas yang tinggi, risiko pengaruh yang tinggi menapis ke puncak tabel, dan risiko probabilitas rendah jatuh ke dasar. Dengan demikian prioritasisasi risiko urutan pertama dapat diselesaikan. Driver risiko dapat diperkirakan pada skala probabilitas kualitatif yang memiliki nilai sebagai berikut : impossible, improbable, probable, dan frekuen. Probabilitas matematis kemudian dapat dikaitkan dengan masing-masing nilai kualitatif (misalnya, suatu probabilitas 0,7 sampai 1,0 implikasikan risiko yang sangat mungkin). 6.4.2. Menilai Pengaruh Risiko

Ada tiga faktor yang kemungkinan besar mempengaruhi konsekuensi jika suatu risiko benarbenar terjadi : sifatnya, ruang lingkupnya, dan timingnya. Sifat dari risiko menunjukkan masalah yang mungkin muncul bila ia terjadi. Ruang lingkup dari suatu risiko menggabungkan kepelikannya (seberapa serius hal ini?) dengan keseluruhan distribusi (berapa banyak proyek akan dipengaruhi atau berapa banyak pelanggan yang akan terganggu?). Akhirnya, timing dari suatu risiko mempertimbangkan kapan dan untuk berapa lama pengaruh itu akan dirasakan. Langkah-langkah berikut ini direkomendasikan untuk menentukan konsekuensi keseluruhan dari suatu risiko : 1.

Tentukan probabilitas rata-rata dari nilai kejadian untuk masing-masing komponen risiko.

2.

Dengan menggunakan gambar 6.2, tentukan pengaruh untuk masing-masing komponen berdasarkan kriteria yang diperlihatkan.

3.

Lengkapi tabel risiko dan analisis hasilnya seperti digambarkan pada subbab sebelumnya.

Penilaian Risiko

2015

9

Manajemen Proyek Sistem Informasi Bima Cahya Putra, M.Kom

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

Agar penilaian bermanfaat, tingkat referens risiko harus ditentukan. Untuk sebagian besar proyek perangkat lunak, komponen risiko yang dibicarakan sebelumnya – kinerja, biaya, dukungan dan jadwal – juga mencerminkan tingkat referensi risiko. Tingkat referens risiko adalah tingkat degradasi kinerja, pembengkakan biaya, kesulitan dukungan, dan melesetnyajadwal, yang akan menyebabkan proyek diterminasi.Jika kombinasi risiko menciptakan masalah yang menyebabkan satu atau lebih dari tingkat referen itu terlampaui, kerja akan terhenti. Dalam konteks analisis risiko perangkat lunak, tingkat referen risiko memilki titik tunggal, yang disebut referent point atau break point, di mana keputusan untuk meneruskan proyek atau menghentikannya sama-sama dapat diterima. Selama penilaian risiko, kita melakukan langkah-langkah berikut : 1) Tentukan tingkat referen risiko untuk proyek. 2) Usahakan untuk mengembangkan hubungan antara masing-masing[ri, li, xi] dan masing-masing tingkat referen. 3) Prediksikan himpunan titik referen yang menentukan daerah terminasi, dibatasi oleh kurva atau area ketidakpastian. Cobalah memprediksi bagaimana penggabungan kombinasi risiko akan mempengaruhi suatu titik referen.

Pengurangan, Monitoring, Dan Manajemen Risiko Semua aktivitas analisis risiko yang disajikan pada titik ini memiliki satu tujuan tunggal – membantu tim proyek dalam mengembangkan strategi yang berkaitan dengan risiko. Strategi yang efektif harus memiliki tiga gagasan berikut : 

Menghindari risiko



Monitoring risiko



Manajemen risiko dan perencanaan kemungkinan

Pada saat proyek berjalan, aktivitas pemonitoran risiko dimulai. Manajer proyek memonitor faktor-faktor yang dapat memberikan suatu indikasi apakah risiko sedang menjadi lebih atau kurang mungkin. Dalam kasus turnover staf tinggi, faktor-faktor berikut dapat dimonitor : 

Sikap umum anggota tim berdasarkan tekanan proyek.



Tingkat di mana tim disatu-padukan.



Hubungan interpersonal di antara anggota tim.



Masalah potensial dengan kompensasi dan manfaat.



Keberadaan pekerjaan di dalam perusahaan dan di luarnya.

2015

10

Manajemen Proyek Sistem Informasi Bima Cahya Putra, M.Kom

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

RMMM Plan Strategi manajemen risiko dapat dimasukkan dalam rencana proyek perangkat lunak; atau, langkah manajemen risiko dapat diatur ke dalam Risk Mitigating, monitoring, and Management Plan (RMMM Plan) yang terpisah. RMMM Plan mendokumentasi semua kegiatan yang dilakukan sebagai bagian dari analisis risiko dan digunakan oleh manajer proyek sebagai bagian dari keseluruhan Rencana Proyek. Uraian untuk RMMM Plan adalah sebagai berikut: I.

Pengantar 1. Lingkup dan tujuan dokumen 2. Tinjauan risiko utama 3. Tanggung jawab a. Manajemen b. Staf teknis

II. Tabel Risiko Proyek 1. Deskripsi semua risiko di atas yang ditentukan 2. Faktor-faktor yang mempengaruhi probabilitas dan pengaruh III. Pengurangan, Monitoring, dan Manajemen Risiko 1. Risiko 2. Pengurangan a. Strategi umum b. Langkah khusus untuk mengurangi risiko 3. Monitoring a. Faktor-faktor yang dimonitor b. Pendekatan monitoring 4. Manajemen a. Rencana kontingensi b. Konsiderasi khusus IV. Jadwal Iterasi Rencana RMMM V. Kesimpulan

2015

11

Manajemen Proyek Sistem Informasi Bima Cahya Putra, M.Kom

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id

Daftar Pustaka 1. David L. Olson, Information System Project Management, 2nd Edition, McGrawHill, 2003 2. ForsBerg, K., dkk. 1996. Visualizing Project Management 2TH. New York : John Willey &

sons. 3. Hughes, B., and Cotteral, M. 1999. Software Project Management Second Edition.

London : McGraw Hill. 4. Ian Somerville, “Software Engineering” 5. Kathy Schwalbe, Information Technology Project Management, 2nd Edition, Technology

Thomson Learning, 2002 6. Marchewka, Jack T., 2006, Information Technology Project Management, John Wiley &

Sons, Inc, ISBN-13 978-0-471-71539-9 7. Pressman, R. 2000. Software Engineering : A Practioners Approach 5TH Editon. Boston

: Mc Graw Hill.

2015

12

Manajemen Proyek Sistem Informasi Bima Cahya Putra, M.Kom

Pusat Bahan Ajar dan eLearning http://www.mercubuana.ac.id