## Analisis  Risiko  Proyek  Pengembangan  Perangkat  Lunak Menggunakan Kerangka Kerja ISO 31000
Amin Ma’ruf Nuris, Aditya Maharani, Renanda Nia Rachmadita*
Program Studi Manajemen Bisnis, Jurusan Teknik Bangunan Kapal Politeknik Perkapalan Negeri Surabaya, Surabaya 60111, Indonesia
Article Info

## Abstract
Article history:
Received 26 August 2021 Accepted 1 December 2021
PT. Duta Media Cipta (DMC) is a control system and IT company based in the city of Surabaya, this company focuses on procurement, maintenance and repair services for ship equipment, both mechanical and electrical. As an information technology company, PT. DMC is committed to being a trusted IT and control system company. In working on the project, PT. DMC has not implemented risk management for every software development project it has worked on. Some of the risks that are often faced in working on software projects at PT. DMC are project risks such as technical, cost, and project scheduling which are sometimes not in accordance with the established plan and cause cost and time losses to the company. So  in  this  study  using  ISO  31000  as  a  framework  in  analyzing potential risks. The application of risk assessment consists of 3 stages, namely risk  identification, risk  analysis, and risk  evaluation. The results of this study found that there are 4 risks with 26 sub-risks, of which there are 6 sub-risks that are prioritized and require risk management.
Keywords:
Control System, ISO 31000 : 2018, Manajemen risiko

## 1. PENDAHULUAN
Proyek pengembangan perangkat lunak selalu mempunyai  risiko,  dimana  risiko  tersebut  akan mengganggu keberhasilan dari proyek. Risiko yang kemungkinan akan terjadi seperti kegagalan teknis, biaya  proyek  yang  bertambah  besar,  dan  lama pengerjaan proyek yang membutuhkan waktu lebih lama  (Prayogo  &  Setyo,  2017).    Pada  saat  ini banyak  perusahaan  IT  yang  belum  menerapkan manajemen risiko ataupun belum menjadikan risiko proyek  menjadi  prioritas.  Menurut  Apriyanto  & Putro (2018) Dari 110 proyek sistem informasi yang dievaluasi  menemukan  bahwa  hanya  27%  proyek sistem informasi yang terselesaikan sesuai anggaran,  tepat  waktu  dan  telah  dievaluasi  oleh pengguna, sisanya 55% bermasalah dan 18% gagal. Kegagalan  tersebut  dipengaruhi  pada  kondisi proyek  yang  masih  berjalan  dengan  beberapa masalah  serius  dan  banyak  proyek  yang  melebihi waktu yang ditentukan dari pada melebihi anggaran. Banyaknya  kasus  kegagalan  proyek  sistem informasi  ini  menandakan  bahwa  pada  setiap aktifitas  didalam  tahapan  pengerjaan  proyek terdapat  risiko-risiko  yang  dapat  mengganggu jalannya  sebuah  proyek.  Sebuah  risiko  harus dikelola  dengan  baik.  Pengelolaan  risiko  sangat diperlukan  didalam  melakukan  sebuah  proyek perangkat  lunak  untuk  meminimalisir  kegagalan dari  sebuah  proyek.  Penerapan  manajemen  risiko membantu  untuk  mengidentifikasi  sumber  utama
risiko, menganalisis, dan menyelesaikannya (Boehm, 1989).
PT.Duta Media Cipta (DMC) adalah perusahaan  control  system  dan  IT  yang  berada  di kota  Surabaya,  Perusahaan  ini  berfokus  pada  jasa pelayanan pengadaan, pemeliharaan, dan perbaikan peralatan  kapal  baik  bagian  mekanik  maupun elektrik.  Pada  tahun  2020,  PT  DMC  telah mengerjakan total 21 Pekerjaan proyek, dengan 13 Proyek merupakan proyek pengembangan perangkat lunak. Dalam pekerjaan proyek pengembangan  perangkat  lunak,  PT.DMC  belum menerapkan manajemen risiko untuk setiap proyek pengembangan  perangkat  lunak  yang  dikerjakan. Tingginya kasus pada pengerjaan proyek perangkat lunak  akan  menimbulkan  permasalah  bagi  PT. DMC, banyaknya kasus tersebut dapat menurunkan kredibilitas perusahaan. Keadaan tersebut menimbulkan  risiko  pada  PT.  DMC  yang  dapat merugikan  perusahaan.  Salah  satu  pendekatan manajemen  risiko  yang  dapat  digunakan  adalah pedoman  dari  ISO  31000:2018.  ISO  31000 merupakan  sebuah  standar  atau  panduan  yang dikeluarkan  oleh  organisasi  ISO  yang  dapat membantu tim manajemen risiko didalam melakukan  pengelolaan  risiko  dengan  berupa panduan,  kerangka  kerja,  dan  proses  didalam mengatur risiko (The British Standard, 2018).
Penelitian penelitian terdahulu juga menggunakan  pendekatan  ini  untuk  mengalanisa risiko yang terjadi seperti penlitian Analisis Risiko
Teknologi  Informasi  pada  Lembaga  Penerbangan dan  Antariksa  Nasional  (LAPAN)  pada  Website SWIFTS  Menggunakan  ISO  31000  (Francisca  & Radiant,  2016)  dan  Analisis  Risiko  Teknologi Informasi Menggunakan ISO 31000 pada Program HRMS (Stefan, 2017). Penggunaan ISO 31000:2018    dapat  digunakan  karena  memberikan panduan  yang  jelas  dan  terstruktur  serta  dapat menggunakan  metode-metode  analisa  risiko  yang bermacam – macam.

## 2. METODOLOGI

## 2.1 Observasi awal dan studi literatur
Pada  tahapan  awal  ini  dilakukan  dengan observasi  di  Perusahaan  Duta  Media  Cipta  di Surabaya.  Observasi  awal  ini  dilakukan  untuk memperoleh  gambaran  jelas  mengenai  proyek  - proyek  pengembangan  perangkat  lunak  yang sedang  dikerjakan  oleh  perusahaan.  Studi  literatur dilakukan untuk mencari dan mempelajari literatur guna  mendapatkan  referensi  teori  maupun  metode yang  cocok  digunakan  untuk  menganalisa  risiko proyek pengembangan perangkat lunak.

## 2.2 Identifikasi Risiko
Pada tahapan ini, peneliti melakukan identifikasi risiko dengan cara wawancara kepada 6 orang expert ( Chief  Technology  Officer,Chief Operating Officer, Project Administrator, Programmer, IT Infrastructure & SCADA, Web & UI  Designer )  guna  mencari  informasi  kondisi  dan melakukan pengamatan terhadap kejadian-kejadian sebelumnya yang mengakibatkan kerugian bagi PT. Duta  Media  Cipta.  Sehingga  didapatkan  daftar risiko  yang  selanjutnya  risiko  tersebut  akan dianalisa secara kuantitatif maupun kualitatif. Tabel daftar risiko terdapat dalam Tabel 1.

## 2.3 Analisa Risiko
Setelah  diketahui  daftar  risiko  yang  ada, dilakukan  analisa  terhadap risiko  tersebut. Analisa risiko tersebut dibagi menjadi 2 yaitu :
a. Analisa Kualitatif Analisa  kualitatif  menggunakan risk  scoring, pada  proses  ini  akan  dilakukan  penilaian terhadap  risiko  yang  sudah  diidentifikasi. Penentuan nilai ini akan dilakukan berdasarkan kemungkinan  ( likelihood )  dan  signifikansi ( consequence ).
b. Analisa Kuantitatif Setelah  diketahui risk  scoring .  Dilakukan metode  analisis  dengan  menghitung  dampak dari  risiko  menggunakan  formula.  Formula tersebut  digunakan  untuk  mengetahui risk factor , yang berguna untuk memudahkan kepala proyek  menempatkan  sumberdaya  terhadap risiko yang berprioritas .

## 2.4 Evaluasi Risiko
Pada tahapan ini, peneliti mengevaluasi risiko pada  proyek  pengembangan  perangkat  lunak  yang dikerjakan PT. Duta Media Cipta berdasarkan pada risk score dan risk factor, yang diperoleh dari hasil analisis risiko pada tahap sebelumnya.

## 2.5 Pembuatan mitigasi risiko
Pada  tahapan  ini  akan  menentukan  tindakan, mitigasi  atau  perlakuan  yang  akan  dilakukan terhadap semua risiko yang muncul saat pengerjaan proyek pengembangan perangkat lunak berlangsung  dengan  menggabungkan  semua  opini yang  diberikan  oleh  para expert pada  saat  proses diskusi atau wawancara.

## 3. HASIL DAN PEMBAHASAN

## 3.1 Identifikasi Risiko
Tahapan  identifikasi  risiko  terkait  dengan proyek  pengembangan  perangkat  lunak  yang dikerjakan PT. DMC didapatkan dengan wawancara  kepada expert yang  terlibat  langsung kedalam proyek. Risiko  identifikasi dari penyebab terjadinya peristiwa yang berpotensi menimbulkan kerugian  dan  kegagalan  sebuah  proyek  serta melakukan wawancara dan diskusi kepada 6 orang expert ( Chief  Technology  Officer,Chief  Operating Officer,  Project  Administrator,  Programmer,  IT Infrastructure & SCADA, Web & UI Designer )untuk  mengetahui  sebab  dan  dampak yang ditimbulkan dari peristiwa tersebut.

## 3.2 Analisis Risiko
Setelah dilakukan identifikasi risiko, aktifitas selanjutnya  adalah  melakukan  analisis  risiko. Analisa  risiko  dibagi  menjadi  dua  analisa  secara kualitatif ( risk scoring ) dan analisa kuantitatif ( risk factor ). Pada proses analisis risiko dimulai dengan mengisi  kuisioner  oleh  para expert .  Untuk  expert adalah para tenaga ahli yang terlibat langsung pada proyek terutama di pihak PT. Duta Media Cipta.
Kuesioner tersebut ditujukan untuk menganalisis  seberapa  besar  dampak  ( sequence ) dan kemungkinan ( likelihood ) dari setiap kemungkinan  risiko  yang  ada. Risk  scoring diberikan  ke  risiko  berdasarkan  probabilitas  dan dampak  yang  dinilai.  Evaluasi  kepentingan  dan prioritas  setiap  risiko  biasanya  dilakukan  dengan menggunakan  tabel  pencarian  atau  matriks probabilitas dan dampak. Matriks tersebut menentukan  kombinasi  probabilitas  dan  dampak yang  mengarah  pada  penilaian  risiko  sebagai prioritas rendah, sedang, atau tinggi.
Tabel 1.

## Daftar Risiko
Kode Risiko
Sub Risiko I1 Risiko
Internal Dana proyek yang diajukan tidak sesuai I2 Penjadwalan waktu proyek yang tidak sesuai I3 Penganggaran dana proyek yang tidak sesuai I4 Proses pengerjaan proyek yang melebihi batas waktu I5 Kurangnya komunikasi antar tim proyek I6 Lemahnya motivasi kerja tim E1 Risiko
Eksternal Pesanan alat ke vendor datang terlambat E2 Penjelasan acuan kerja / ruang lingkup kurang baik oleh owner E3 Kurangnya komunikasi dengan stakeholder (vendor, user dll) E4 Pembayaran pajak yang bermasalah E5 Dana anggaran yang tidak kunjung turun E6 Penambahan fitur yang mendadak dari owner E7 Terjadi bencana alam pada saat melakukan proses implementasi E8 Terjadi pemadaman listrik ketika proses eksekusi E9 Birokrasi yang menyusahkan S1 Risiko Sistem Software error ketika melakukan testing S2 Hoster down pada saat melakukan hosting S3 Kurangnya testing program ketika eksekusi S4 User interface rumit dan susah dipahami M1 Risiko Sumber Daya Manusia Hasil implementasi tidak sesuai keinginan owner M2 Kesulitan dalam menerjemahkan bisnis proses owner M3 Dokumen install guide yang kurang lengkap M4 Proggrammer tidak memahami keinginan owner M5 Kurangnya SDM secara kualitas/kuantitas M6 Penyelesaian program yang tidak tepat waktu M7 Kurang baiknya kualitas program

## Tabel 2.
Risk matriks likelihood dan consequence
Likelihood Consequence 1 2 3 4 5 Rere Unlikely Possible Likely Almost certain 5 Catastrophic 5 10 15 20 25 4 major 4 8 12 16 20 3 Moderate 3 6 9 12 15 2 Minor 2 4 6 8 10 1 Negligible 1 2 3 4 5
Tabel  2  bersumber  pada  (NHS  - National Patient  Safety  Agency, 2008).  Pada  Gambar  1 menjelaskan  mengenai  arti  warna  didalam risk matrix. Pada  Tabel  2  bisa  diketahui  terdapat  nilai pada  setiap  kolom,  nilai  tersebut  didapatkan  dari Persamaan 1.
Risk Score (R)= likelihood (L) x consequence (1)
dimana Risk  Score  (R) merupakan    Nilai Risiko, likelihoo d    (L)  merupakan  Frekuensi  dan
consequence (C) merupakan signifikansi atau dampak dari risiko. Kriteria yang digunakan untuk indikator consequence dijelaskan  pada  Tabel  3. Sementara kriteria yang digunakan untuk indikator likelihood dijelaskan pada Tabel 4.

## Gambar 1.
Arti warna risk matrix
Tabel 3. Kriteria penilaian consequence
Consequence Deskripsi Rate Kriteria 1 Insignificant Dampak yang ditimbulkan tidak terlalu merugikan  atau  bahkan  tidak  ada. Terdapat  Sedikit  kenaikan  pada  biaya operasional 2 Minor Dampak  yang  ditimbulkan    masih dapat dikelola manajemen dan terdapat kenaikan biaya < 5% dari anggaran 3 Moderate Dampak  yang  ditimbulkan  perlu dilakukan  beberapa  pengaturan  dan masih dapat dikelola, terjadi peningkatan biaya 5-10% dan peningkatan pengawasan. 4 Major Sistem tidak berjalan, kegiatan operasional  tidak  berjalan,  tujuan utama  tidak  terpenuhi  dan  terjadi peningkatan biaya 10-25% 5
Catastrophic Menimbulkan  kerugian  besar  dalam bentuk material dan immaterial, insiden  juga  menyebabkan  >25% peningkatan biaya ( overbudget )

## Tabel 4.
Kriteria penilaian likelihood
Likelihood Deskripsi Frekuensi per proyek Rate Kriteria 1 Insignificant Hampir  tidak  pernah terjadi < 0.1 % 2 Minor Kemungkinan  terjadi ada tetapi kecil (jarang) 0.1 – 10 % 3 Moderate Mungkin  saja  terjadi (kadang-kadang) 1 – 10 % 4 Major Kemungkinan  besar terjadi (sering) 10 – 50 % 5 Catastrophic Hampir selalu terjadi >50 %
Analisa  kualitatif  ini  berguna  mengurangi level  dari  ketidakpastian rare dan  lebih  fokus kepada  level  prioritas  risiko  yang  lebih  tinggi. Output  yang  diberikan  dari  metode  ini  berupa pembaruan  pada  daftar  risiko.  Setelah  mengetahui hasil kuisioner masing  – masing expert, kemudian menganalisa  dengan  menilai  dan  menggabungkan antara consequence dan likelihood yang ditimbulkan menggunakan risk scoring.

## Tabel 5.
Risk Score
Risiko ID Sub Risiko C  L R Risiko Internal I1 Dana proyek yang diajukan tidak sesuai 3 3 9 I2 Penjadwalan waktu proyek yang tidak sesuai 3 3 9 I3 Penganggaran dana proyek yang tidak sesuai 4 2 8 I4 Proses pengerjaan proyek yang melebihi batas waktu 3 2 6 I5 Kurangnya komunikasi antar tim proyek 2 3 6 I6 Lemahnya motivasi kerja tim 3 3 9 Risiko Eksternal E1 Pesanan alat ke vendor datang terlambat 3 3 9 E2 Penjelasan acuan kerja / ruang lingkup kurang baik oleh owner 2 3 6 E3 Kurangnya komunikasi dengan stakeholder (vendor, user dll) 3 3 9 E4 Pembayaran pajak yang bermasalah 4 3 12 E5 Dana anggaran yang tidak kunjung turun 4 3 12 E6 Penambahan fitur yang mendadak dari owner 3 5 15 E7 Terjadi bencana alam pada saat melakukan proses implementasi 2 1 2 E8 Terjadi pemadaman listrik ketika proses eksekusi 2 2 4 E9 Birokrasi yang menyusahkan 3 2 6 Risiko Sistem S1 Software error ketika melakukan testing 2 4 8 S2 Hoster down pada saat melakukan hosting 2 2 4 S3 Kurangnya testing program ketika eksekusi 2 3 6 S4 User interface rumit dan susah dipahami 3 2 6 Risiko Sumber Daya Manusia M1 Hasil implementasi tidak sesuai keinginan owner 3 3 9 M2 Kesulitan dalam menerjemahkan bisnis proses owner 3 3 9 M3 Dokumen install guid e yang kurang lengkap
2 2 4 M4 Proggrammer tidak memahami keinginan owner 2 2 4 M5 Kurangnya SDM secara kualitas/kuantitas 3 2 6 M6 Penyelesaian program yang tidak tepat waktu 3 3 9 M7 Kurang baiknya kualitas program 4 2 8
Berdasarkan  hasil  analisis  risk  scoring  I1  – M7,  dapat  dilihat  risiko  yang  memiliki  potensi untuk menggagalkan sebuah proyek pengembangan perangkat  lunak.  Daftar  risiko  yang  berpotensi diurutkan mulai dari yang low risk hingga extreme risk berdasarkan hasil risk score pada Tabel 5. Tabel 6  merupakan  penilaian  risiko  berdarasarkan kategori risiko. Selanjutnya adalah analisa kuantitatif.  Metode  analisa  kuantitatif  yang digunakan adalah risk factor , dimana risk factor ini digunakan untuk mengetahui risiko mana yang akan menjadi  prioritas  dan  tidak.  Tujuan  utama dilakukannya pencarian risk factor ini adalah untuk memudahkan manajer proyek dalam mengalokasikan  sumberdaya  yang  ada  guna mengatasi  risiko  yang  memiliki  prioritas  tinggi. Tabel  7  adalah  tabel  yang  akan  digunakan  dalam analisa  kuantitatif.  Dari  Tabel  7 risk  factor dapat dihitung menggunakan Persamaan 2.
𝑅𝐹 = 𝐼 + L − ( 𝐼 ∗ L )                       (2)
dimana RF merupakan Risk Factor, I merupakan ukuran  kemungkinan risk  impact dengan  skala  0 sampai  1  dan    L  adalah ukuran  kemungkinan risk likelihood dengan  skala  0  sampai  1.  Setelah melakukan  perhitungan  dilakukan  pemeringkatan. Risk factor digunakan untuk memudahkan manajer proyek dalam mengalokasikan sumberdaya terhadap risiko yang memiliki prioritas tinggi, dan memprioritaskannya berdasarkan priority area pada Gambar 2.
Tabel 6.
Risk Matrix Consequence Likelihood (1) Rare (2) Unlikel y (3) Possibl e (4) Likely (5) Almost Certain (5) Catastrophic (4) Major I3, M7 E4, E5 (3) Moderate I4, E9, S4, M5 I1, I2, I6, E1, E3, M1, M2, M6 E6 (2) Minor
E7 E8, S2, M3, M4 I5, E2, S3 S1 (1) Negligible Tabel 7. Nilai pada tiap tingkatan risiko
Risk likelihood
L Risk impact I Almost certain 0.9 Extreme 0.9 Highly likely 0.7 Very high 0.7 Likely 0.3 Medium 0.3 Unlikely 0.1 Low 0.1 Rere 0.01 Negligible 0.01
Tabel  7  dan  Gambar  2  bersumber  pada  ( The Joint Australia/New Zealand Council of Standards , 2004). Nilai  angka  dari sequence dan likelihood pada  Tabel  8  merupakan  konversi  berdasarkan Tabel 7. Berikut contoh dari pengkonversian Tabel 7:
ID C L Konversi C Konversi L I3 4 2 0.7 0.1
E6 3 5 0.3 0.9
Risk  factor dapat  dihitung  menggunakan  sebagai berikut:
Risk Factor I1 = I + L − ( I ∗ L) = 0.3 + 0.3 – (0.3 ∗ 0.3 ) = 0.51
Risk factor pada Tabel 8 adalah hasil risk factor dari tiap risiko yang ada dalam risk register .
Setelah  mendapatkan  hasil  dari  risk  factor, dapat  diketahui  bahwa  sub  risiko  yang  memiliki nilai  >0.7  adalah  risiko  yang  diprioritaskan  atau risiko  yang  memerlukan  pengawasan  lebih  lanjut. Berdasarkan Tabel 7 dapat diketahui bahwa dari 26 potensi  risiko  yang  ada  terdapat  6  potensi  risiko yang menjadi prioritas dan 20 potensi risiko lainnya tidak  menjadi  prioritas,  namun  risiko  yang  tidak
menjadi prioritas harus tetap dipantau dengan baik. Hasil  dari  analisa  kuantitatif  ini  memperkecil jumlah  prioritas  risiko  dari  analisa  kualitatif,  yang mana pada analisa kualitatif terdapat 14 kemungkinan  risiko  yang  menjadi  prioritas  (level high –  level extrim )  dan  sekarang  pada  analisa kuantitatif  menjadi  6  kemungkinan  risiko  yang menjadi prioritas. Hal ini dapat membantu manajer proyek  untuk  lebih  memperhatikan  dan  berfokus kepada  kemungkinan  risiko  yang berprioritas tinggi.

## 3.3 Evaluasi Risiko
Evaluasi  risiko  merupakan  tahapan  setelah melakukan  analisis  risiko.  Proses  evaluasi  risiko perlu  dilakukan  untuk  menentukan  prioritas penanganan  risiko,  apakah  risiko  tersebut  dapat ditoleransi atau tidak. Pada tahapan ini kemungkinann  -  kemungkinan  risiko  yang  sudah diindentifikasi dan dianalisis sebelumnya dimasukkan  kedalam  sebuah  tabel  evaluasi  risiko. Pembentukan  tabel  evaluasi  risiko  ini  berdasarkan dari  hasil  analisis  risiko  pada  tahap  sebelumnya. Tabel 9 adalah tabel pengevaluasian risiko.

## Tabel 8.
Risk Factor
Risiko ID Sub Risiko C L RF Risiko Internal I1 Dana proyek yang diajukan tidak sesuai 0.3 0.3 0.51 I2 Penjadwalan waktu proyek yang tidak sesuai 0.3 0.3 0.51 I3 Penganggaran dana proyek yang tidak sesuai 0.7 0.1 0.73 I4 Proses pengerjaan proyek yang melebihi batas waktu 0.3 0.1 0.37 I5 Kurangnya komunikasi antar tim proyek 0.1 0.3 0.37 I6 Lemahnya motivasi kerja tim 0.3 0.3 0.51 Risiko Eksternal E1 Pesanan alat ke vendor datang terlambat 0.3 0.3 0.51 E2 Penjelasan acuan kerja / ruang lingkup kurang baik oleh owner 0.1 0.3 0.37 E3 Kurangnya komunikasi dengan stakeholder (vendor, user dll) 0.3 0.3 0.51 E4 Pembayaran pajak yang bermasalah 0.7 0.3 0.79 E5 Dana anggaran yang tidak kunjung turun 0.7 0.3 0.79 E6 Penambahan fitur yang mendadak dari owner 0.3 0.9 0.93 E7 Terjadi bencana alam pada saat melakukan proses implementasi 0.1 0.01 0.11 E8 Terjadi pemadaman listrik ketika proses eksekusi 0.1 0.1 0.19 E9 Birokrasi yang menyusahkan 0.3 0.1 0.37 Risiko Sistem S1 Software error ketika melakukan testing 0.1 0.7 0.73 S2 Hoster down pada saat melakukan hosting 0.1 0.1 0.19 S3 Kurangnya testing program ketika eksekusi 0.1 0.3 0.37 S4 User interface rumit dan susah dipahami 0.3 0.1 0.37 Risiko Sumber Daya Manusia M1 Hasil implementasi tidak sesuai keinginan owner 0.3 0.3 0.51 M2 Kesulitan dalam menerjemahkan bisnis proses owner 0.3 0.3 0.51 M3 Dokumen install guid e yang kurang lengkap 0.1 0.1 0.19 M4 Proggrammer tidak memahami keinginan owner 0.1 0.1 0.19 M5 Kurangnya SDM secara kualitas/kuantitas 0.3 0.1 0.37 M6 Penyelesaian program yang tidak tepat waktu 0.3 0.3 0.51 M7 Kurang baiknya kualitas program 0.7 0.1 0.73

## 3.4 Penanganan Risiko
Pada  tahap  ini  dapat dilihat  tindakan atau strategi yang dilakukan untuk penanganan terhadap risiko  yang  berprioritas.  Ada  empat  cara  atau strategi  yang  dapat  dilakukan  dalam  menangani risiko,  keempat  cara  tersebut  adalah immediate action,  immediate  attention,  periodic  attention, annual evaluation . Immediate action ini digunakan untuk risiko dengan sequence tinggi dan likelihood tinggi  atau  wilayah extrim  risk pada risk  matrix. Dalam  menentukan  strategi  penanganan  pada  tiap
risiko  perlu  memperhatikan risk  matrix yang  telah dibuat  pada  tabel  6,  dimana  pada risk  matrix tersebut potensi risiko sudah digolongkan wilayah – wilayahnya  berdasarkan  tingkat sequence dan likelihood nya.  Selain  itu,  dilakukan  juga  diskusi dengan expert untuk menentukan strategi penanganan  yang  optimum  pada  potensi  risiko. Tabel  10  adalah  strategi  penanganan  dari  setiap risiko prioritas yang ada pada proyek pengembangan perangkat lunak PT. DMC. Tabel 9.

## Evaluasi Risiko
Risk ID Sub Risiko Dampak Pada Proyek R RF E6 Penambahan  fitur  yang mendadak dari owner Terhambatnya pekerjaan proyek, menambahnya pekerjaan para tim proyek dan berpotensi terlambatnya pekerjaan proyek 15 0.93 E4 Pembayaran  pajak  yang bermasalah Proyek tidak dapat berjalan dengan lancar 12 0.79 E5 Dana anggaran yang tidak kunjung turun Proyek berjalan tanpa adanya dana, dan proyek berpotensi berhenti sementara karena tidak adanya dana 12 0.79 I3 Penganggaran dana proyek yang tidak sesuai Terhambatnya  pekerjaan  proyek,  dan  kualitas  implementasi  yang rendah 8 0.73 S1 Software  error ketika melakukan testing Terhambatnya  proses  implementasi  dan  berpotensi  molornya pekerjaan proyek 8 0.73 M7 Kurang  baiknya  kualitas program Menurunnya tingkat kepuasan pelanggan 8 0.73 Tabel 10.

## Strategi Penanganan Resiko
ID Sub Risiko Kritis Akar Penyebab Strategi Penanganan I3 Penganggaran dana proyek  yang  tidak sesuai 1. Tenaga kerja terbatas 2. Kurangnya  tenaga  ahli pada bagian administrasi/keuangan Mengoptimalkan kemampuan sumber daya manusia yang ada dengan mengadakan pelatihan, atau bisa melakukan rekrutmen karyawan pada posisi yang dibutuhkan, tetapi hal ini susah dilakukan pada kondisi pandemi seperti ini dimana pendapatan perusahaan rendah.
3. Tenaga kerja kurang teliti 4. Manajemen Kurang Baik 5. Tenaga Kerja malas bertanya Memberikan motivasi kepada tenaga kerja supaya dapat melakukan pekerjaan dengan baik dan saling bekerjasama dalam menyelesaikan suatu pekerjaan proyek. 6. Jadwal lelang mepet 7. Menghambat pekerjaan Melakukan pekerjaan dengan tepat waktu dan pentingnya manajemen waktu yang baik sehingga dapat mempersiapkan proposal pengajuan lelang dengan maksimal dan tidak menghambat pekerjaan yang lain. E4 Pembayaran pajak yang bermasalah 1. Referensi hanya berdasarkan mulut ke mulut 2. Kurangnya pengecekan ataupun pencarian konsultan pajak terpercaya Membuat list berbagai macam konsultan pajak baik dari mulut ke mulut maupun hasil pencarian sendiri dan melakukan seleksi pemilihan konsultan pajak berdasarkan list yang telah dibuat dibuat dan memilih konsultan yang memiliki integritas baik dan terpercaya sehingga tidak merugikan perusahaan
3. DMC tidak memiliki SDM bidang perpajakan 4. Peraturan perpajakan yang rumit untuk dipahami 5. Tenaga kerja lebih fokus menangani pekerjaan proyek Melakukan rapat atau brainstroming antar karyawan mengenai permasalahan yang dihadapi oleh perusahaan maupun permasalahan di perusahaan, sehingga karyawan bisa mendapatkan solusi dari adanya rapat tersebut dan menghindari adanya tugas yang tidak sesuai dengan kemampuan karyawan
Tabel 10. (Lanjutan)

## Strategi Penanganan Resiko
ID Sub Risiko Kritis Akar Penyebab Strategi Penanganan E4 Pembayaran pajak yang bermasalah 6. Referensi hanya berdasarkan mulut ke mulut 7. Kurangnya pengecekan ataupun pencarian konsultan pajak terpercaya Membuat list berbagai macam konsultan pajak baik dari mulut ke mulut maupun hasil pencarian sendiri dan melakukan seleksi pemilihan konsultan pajak berdasarkan list yang telah dibuat dibuat dan memilih konsultan yang memiliki integritas baik dan terpercaya sehingga tidak merugikan perusahaan
8. DMC tidak memiliki SDM bidang perpajakan 9. Peraturan perpajakan yang rumit untuk dipahami 10. Tenaga kerja lebih fokus menangani pekerjaan proyek Melakukan rapat atau brainstroming antar karyawan mengenai
permasalahan yang dihadapi oleh perusahaan maupun permasalahan di perusahaan, sehingga karyawan bisa mendapatkan solusi dari adanya rapat tersebut dan menghindari adanya tugas yang tidak sesuai dengan kemampuan karyawan E5 Dana anggaran yang tidak kunjung turun 1. Pihak klien belum ada dana 2. Progres pekerjaan proyek pengembangan perangkat lunak yang susah diukur Menjalin komunikasi yang baik dengan pemilik proyek untuk menjelaskan berapa persen progres pekerjaannya dengan catatan tetap memberikan laporan progres bulanan kepada pemilik proyek sekaligus mendiskusikan solusi terbaik kepada dua belah pihak apabila pemilk proyek belum mempunyai dana. 3. Klien belum puas dengan apa yang sudah dikerjakan 4. Permintaan klien untuk mengganti fungsi atau fitur tertentu Melakukan rapat sebelum membuat Kerangka acuan kerja (KAK) dengan semua pihak yang berkepentingan mulai dari owner, stakeholder, dan kontraktor guna memperjelas semuannya mulai fitur apa yang diminta owner, bahasa pemrogramannya, database , platform, dan semua hal-hal teknis sehingga nanti diwaktu eksekusi proyek tidak ada lagi permintaan untuk mengganti fitur dan menghindari ketidakpuasan pemilik proyek.
5. Tenaga Kerja Sakit 6. Administrasi yang belum lengkap Melakukan koordinasi yang baik dengan administrasi proyek atau tenaga kerja yang lain apabila ada tenaga kerja/ programmer yang sakit dapat melimpahkan tugasnya ke teman sejawatnya sehingga progress pekerjaan selalu berjalan dan melakukan crosscheck dokumen sehingga administrasi yang akan dikirimkan ke pemilik proyek sudah lengkap. E6 Penambahan fitur yang mendadak dari owner 1. Keterbatasan waktu 2. Kurangnya persiapan dalam pekerjaan proyek Mengadakan rapat atau diskusi internal perusahaan antar tim proyek setelah dinyatakan menjadi pemenang lelang dan sesegera mungkin melakukan survey dan komunikasi perihal pekerjaan yang dilakukan kepada klien sebelum pembuatan kontrak kerja. 3. Stakeholder tidak dilibatkan dalam rapat pembuatan KAK Segera menghubungi pemilik proyek dan merekomendasikan pemilik proyek agar mengajak semua unit/orang yang berkepentingan terhadap proyek untuk rapat dalam pembuatan KAK 4. Kurangnya kualitas SDM 5. Kurangnya arahan 6. Tidak Memahami Spesifikasi pekerjaan yang diberikan 7. Kurangnya koordinasi kerja Memberikan segera training secara rutin kepada para tenaga kerja agar menambah keahliannya dan dapat dengan mudah memahami pekerjaan yang diberikan selain itu juga melakukan pengecekan setiap aktifitas dengan cara melakukan pertemuan antar manajer dan tim proyek untuk mengantisipasi adanya ketidaksesuaian program.
S1 Software error ketika melakukan testing 1. Kurangnya koordinasi antar DMC dan pihak klien 2. Adanya birokrasi yang ribet 3. Komunikasi internal perusahaan klien yang kurang baik Melakukan komunikasi yang intens kepada seseorang yang bertanggung jawab atas proyek terutama dengan pimpinan proyek atau pimpinan instansi agar proyek bisa berjalan dengan lancar sehingga dapat melakukan testing software kepada end user untuk mencari bug dari aplikasi secara menyeluruh dan juga untuk menghindari birokrasi yang ribet .

## Tabel 10. (Lanjutan)

## Strategi Penangan Resiko
ID Sub Risiko Kritis Akar Penyebab Strategi Penanganan S1 Software error ketika melakukan testing 4. Klien kurang paham akan teknologi aplikasi yang digunakan sebelumnya 5. Pihak klien merasa paling tahu mengenai teknologi Mengedukasi pihak klien mengenai aplikasi yang akan digunakan dan diterapkan baik mengenai budgetnya, fiturnya maupun fungsi dari software tersebut, apabila pihak klien tetap angkuh dan budget mereka terbatas alangkah baiknya kita menghindari risiko tersebut dengan cara mundur pelan – pelan.
6. Tidak ada dokumentasi kebutuhan Melakukan pengawasan pada setiap tim proyek dan memastikan mereka untuk menjalankan tugasnya dengan baik selain itu juga menjalankan backup dari perangkat lunak yang ada dan melakukan testing  software internal tim terlebih dahulu guna mengantisipasi software yang error ketika testing
7. Tidak ada kesepakatan diawal mengenai perubahan kebutuhan 8. Kurangnya perhatian terhadap persetujuan proyek diawal Melakukan komunikasi dan koordinasi yang baik dengan klien dan menjelaskan kepada pihak klien bahwa hal itu tidak sesuai dengan apa yang disetujui diawal, apabila pihak klien memberikan uang lebih dan waktu yang lebih bisa diterima dan Menyarankan kepada pihak klien untuk mengajak semua stakeholder rapat dalam membuat KAK supaya tidak menyesal di kemudian hari.
9. Kurangnya pengalaman 10. Pihak DMC kurang teliti terhadap kebutuhan yang diminta klien Memberikan pelatihan secara berkala kepada setiap tim proyek baik proggramer , dokumenter , implemetor dan seluruh tim yang bekerja dalam proyek, selain itu memberikan briefing sebelum melaksanakan suatu pekerjaan sehingga dapat menyelesaikan pekerjaan dengan baik, sesuai arahan dan sesuai dengan Kerangka Acuan Kerja yang diberikan oleh klien M7 Kurang baiknya kualitas program 1. Banyaknya pengadaan yang dibatalkan 2. Kurangnya pemasukan
Mencari alternatif sumber dana yang lain seperti online store , SCADA atau yang sesuai dengan visi perusahaan  dan tidak hanya mengandalkan pelelangan ditengah situasi dan kondisi yang belum menentu pada masa pandemi ini
3. Rekrutmen tidak sesuai dengan kebutuhan 4. Banyak karyawan yang pensiun/pindah 5. Jumlah tenaga kerja kurang Melakukan perencanaan, pengawasan dan manajemen SDM yang baik terkait proses rekrutmen karyawan sehingga proses bisnis di perusahaan DMC bisa berjalan dengan baik dan lancar 6. Peralatan jarang dirawat 7. Pemakaian peralatan berlebihan 8. Peralatan kerja tidak memenuhi spesifikasi 9. Listrik padam 10. Fasilitas kurang
Melakukan perawatan dan pengecekan secara berkala pada peralatan dan fasilitas yang ada seperti laptop, wifi, printer,
kulkas dll untuk menghindari kerusakan pada peralatan yang tersedia dan mengganti peralatan apabila sudah tidak layak pakai. Selain itu juga mengedukasi karyawan untuk selalu menjaga peralatan yang ada.
11. Keahlian kurang memadai 12. Permasalahan sesama karyawan 13. Kurang apresiasi dari perusahaan Memberikan suntikan motivasi dan apresiasi kepada tim proyek yang telah menjalankan pekerjaan proyek dengan baik dan melakukan pertemuan antar manajer dan tim proyek pada setiap aktifitas supaya mengetahui permasalahan dan kendala yang dialami oleh tim proyek. Apabila permasalahan yang dialami sesama tim proyek dapat mengganggu pekerjaan proyek maka manajer tim proyek dapat mengubah frameworknya atau metodenya, seperti scrum atau kanban.
14. Permasalahan dengan keluarga 15. Izin karena kepentingan mendesak Memberikan nasihat dan pengawasan serta motivasi kepada karyawan dan saling bekerjasama dalam mengerjakan tugas yang diberikan sehingga dapat meningkatkan produktivitas karyawan.

## 4. KESIMPULAN
Berdasarkan  hasil  analisis  manajemen  risiko pada  proyek  pengembangan  perangkat  lunak, terdapat  beberapa  poin  yang  menjadi  simpulan, diantaranya :
1. Setelah melakukan identifikasi risiko ditemukan 4  (empat)  kategori  risiko  pada  proyek
pengembangan  perangkat  lunak  yaitu  risiko internal,  eksternal,  sistem,  dan  sumber  daya manusia.  Dimana  pada  kategori  risiko  internal terdapat  6  sub  risiko,  kategori  risiko  eksternal terdapat  9  sub  risiko,  kategori  risiko  sistem terdapat 4 sub risiko, dan kategori risiko sumber daya manusia terdapat 7 sub risiko.
2. Strategi yang dapat dilakukan untuk menangani risiko  berprioritas  berdasarkan  peta  risiko adalah sebagai berikut :
a. Pada risiko internal dengan kode sub risiko I3 dilakukan penanganan dengan cara immediate attention yaitu  perusahaan  harus  segera melakukan  pengawasan  pada  risiko  ini.
Pengawasan yang diberikan seperti mengoptimalkan  kemampuan  sumber  daya manusia  yang  ada,  memberikan  motivasi kepada tenaga kerja dan pentingnya manajemen waktu.
b. Pada  risiko  eksternal  dengan  kode  sub  risiko E6  dilakukan  penanganan  dengan  cara immediate  action yaitu  perusahaan  harus melakukan  penanganan  yang  agresif  dan segera.  Pengawasan  yang  diberikan  seperti mengadakan  rapat  atau  diskusi  internal perusahaan  dan  memberikan  segera  training secara  rutin  kepada  para  tenaga  kerja. Sedangakan  kode  sub  risiko  E4  dan  E5 dilakukan penanganan dengan cara immediate attention yaitu  perusahaan  harus  segera melakukan  pengawasan  pada  risiko  ini. Pengawasan  yang  diberikan  seperti  membuat list berbagai macam konsultan pajak, melakukan rapat atau brainstroming melakukan rapat sebelum membuat Kerangka acuan kerja  (KAK)  dan  menjalin  komunikasi yang baik
c. Pada risiko sistem dengan kode sub risiko S1 dilakukan penanganan dengan cara immediate attention yaitu  perusahaan  harus  segera melakukan  pengawasan  pada  risiko  ini. Pengawasan yang diberikan seperti mengedukasi  pihak  klien  mengenai  aplikasi, melakukan  pengawasan  pada  setiap  tim proyek, melakukan komunikasi dan koordinasi yang baik dengan klien.
d. Pada risiko sistem dengan kode sub risiko M7 dilakukan penanganan dengan cara immediate attention yaitu  perusahaan  harus  segera melakukan  pengawasan  pada  risiko  ini. Pengawasan  yang  diberikan  seperti  mencari alternatif sumber dana, melakukan perencanaan,  pengawasan  dan  manajemen SDM  yang  baik,  melakukan  perawatan  dan pengecekan secara berkala pada peralatan

## 5. DAFTAR PUSTAKA
1. Apriyanto, R. D., & Putro, H. P. 2018. Tingkat Kegagalan  dan  Keberhasilan  Proyek  Sistem Informasi  di  Indonesia. Prosiding  Seminar
Nasional Teknologi Informasi Dan Komunikasi (SENTIKA)  2018 ,  (pp. 395–402),  Yogyakarta, Universitas Atma Jaya Yogyakarta.
2. Boehm,    Barry.W.  1991.  Software  Risk Management:  Principal  and  Practices. IEEE Software , 8(1): 32-41.
3. Francisca,  L.  N.,  &  Radiant,  V.  I.  2016.
Analisis  Risiko  Teknologi  Informasi  pada Lembaga Penerbangan dan Antariksa Nasional (LAPAN) pada Website
SWIFTS Menggunakan  ISO  31000. JUISI  (Jurnal Informatika dan Sistem Informasi, 2 (2): 1-11.
4. NHS - National Patient Safety Agency. 2008. A risk matrix for risk managers . UK: Department of Health.
5. The  Joint  Australia/New  Zealand  Council  of Standards.  2004. Risk  Management  AS/NZS 3460:2004 .  Sydney  &  Wellington:  Standards Australia  International  Ltd.  &  Standards  New Zealand.
6. Prayogo,  J.  S.,  &  Setyohadi,  D.  B.  2017. Manajemen  Risiko  Proyek  Perangkat  Lunak Menggunakan  Pendekatan  Just  In  Time  Pada Perusahaan Teknologi Informasi. Jurnal Buana Informatika , 8(3): 119–130.
7. Stefan,  A.  ,  Nugroho,A.,  &  Cahyono,  D.A. 2017.  Analisis  Risiko  Teknologi  Informasi Menggunakan  ISO  31000  pada  Program HRMS. Jurnal  Resti  (Rekayasa  Sistem  dan Teknologi Informasi ), 1(3): 250-258
8. The  British  Standard.  2018. BS  ISO  31000: 2018 Risk management - Guidelines . UK: BSI Standards Publication,.