0
Mobile Farming APP Risk Management Plan
Posted by jujur
on
9:58 AM
Mobile Farming APP
Risk Management Plan
Version Number: 1.1
Version Date: 12/May/2015
VERSION HISTORY
|
Version
Number |
Implemented
By
|
Revision
Date
|
Approved
By
|
Approval
Date
|
Description of
Change |
|
1.0
|
CreatedRoom
Dev.
|
10/May/2015
|
Andrianto
|
12/May/2015
|
-
|
|
1.1
|
CreatedRoom
Dev.
|
18/May/2015
|
Andrianto
|
18/May/2015
|
Penambahan Risk – risk yang
sebelumnya belum dicantumkan.
|
|
|
|
|
|
|
|
TABLE OF CONTENTS
1.0 INTRODUCTION
1.1 Purpose Of The Risk Management Plan
Risiko adalah suatu peristiwa atau kondisi itu, jika terjadi, bisa berdampak positif atau
negatif pada tujuan proyek.
Manajemen risiko adalah proses identifikasi, mengkaji, menanggapi, pengawasan dan pengendalian,
serta pelaporan risiko. Rencana Manajemen Risiko ini mendefinisikan bagaimana risiko yang terkait dengan Proyek
Mobile Farming App akan diidentifikasi, dianalisis,
dan dikelola. Dokumen ini memaparkan bagaimana aktivitas manajemen risiko akan dilakukan, dicatat, dan dipantau di seluruh siklus hidup proyek dan menyediakan template dan praktek untuk merekam dan memprioritaskan risiko
oleh Risk Manager dan /
atau Risk Management Team.
Risiko yang berkaitan dengan sistem IT atau
aplikasi harus diidentifikasi dan didokumentasikan berdasarkan
metodologi dalam NIST SP 800-30, Risk Management Guide for Information
Technology Systems. Kelemahan sistem IT atau aplikasi harus
diidentifikasi pada rencana terkait action dan milestone (POA & M) dan dilacak sesuai dengan pedoman HHS POA & M. Tindakan perlindungan yang tepat harus diambil untuk menjaga
sistem TI yang sensitif atau kelemahan aplikasi atau kerentanan dari pengungkapan
yang tanpa izin.
2.0 risk management Procedure
2.1 Process
Manajer proyek bekerja sama dengan
tim proyek dan sponsor
proyek akan memastikan bahwa
risiko diidentifikasi secara aktif, dianalisis, dan dikelola sepanjang hidup proyek. Risiko akan diidentifikasi
sedini mungkin dalam proyek sehingga dapat meminimalkan dampaknya. Langkah-langkah untuk mencapai ini diuraikan dalam bagian berikut.
Manajer proyek akan berfungsi
sebagai Risk Manager untuk proyek ini
Perbedaan mungkin perlu dibuat antara manajemen risiko proyek secara keseluruhan dan sistem IT atau application
risk management.
Risiko yang berkaitan dengan sistem
IT atau aplikasi harus
diidentifikasi dan didokumentasikan berdasarkan metodologi dalam
NIST SP 800-30,
Risk Management Guide for Information Technology Systems.
2.2 ROLES AND RESPONSIBILITIES
Table
1
Peran dan Tanggung Jawab
|
Role
|
Responsibilities
|
|
Risk Manager atau Project Manager (PM)
|
Risiko Manager atau PM adalah anggota dari
Tim Proyek Terpadu (IPT). Risiko Manager atau PM menentukan apakah risiko yang
terjadi itu unik, mengidentifikasi risiko
yang mungkin saling ketergantungan di seluruh
proyek, memverifikasi jika suatu risiko bersifat internal atau eksternal untuk proyek, memberikan klasifikasi risiko
dan nomor pelacakan. Selama hidup proyek, mereka terus memantau proyek-proyek
untuk potensi risiko.
|
|
Integrated Project Team
|
IPT bertanggung jawab untuk mengidentifikasi
risiko, dependensi risiko dalam proyek, konteks
dan konsekuensi dari risiko. Mereka juga
bertanggung jawab untuk menentukan dampak, waktu, dan
prioritas risiko serta merumuskan laporan
risiko.
|
|
Pemilik Resiko
|
Pemilik risiko menentukan risiko mana yang memerlukan rencana mitigasi dan
contingency, dia menghasilkan strategi mitigasi dan contingency risiko dan melakukan analisis manfaat biaya dari strategi yang diusulkan. Pemilik Risiko bertanggung jawab untuk memantau
dan mengendalikan dan memperbarui status risiko
di seluruh siklus hidup proyek. Pemilik risiko
dapat menjadi anggota tim
proyek.
|
2.3 Risk Identification
Identifikasi risiko akan melibatkan tim proyek, stakeholder yang tepat, dan akan mencakup evaluasi dari faktor lingkungan, budaya organisasi dan rencana manajemen proyek termasuk ruang lingkup proyek, jadwal, biaya, atau kualitas. Perhatian
akan diberikan kepada deliverable proyek,
asumsi, kendala, WBS,
perkiraan biaya / usaha, rencana sumber daya, dan dokumen-dokumen proyek utama lainnya.
2.3.1 Methods for Risk Identification
Metode berikut akan digunakan untuk
membantu dalam identifikasi risiko yang terkait dengan Proyek Mobile
Farming App.
·
Brainstorming
·
Interviewing
·
SWOT (Strengths, Weaknesses, Opportunities and
Threats)
·
Diagramming
·
Dll.
Sebuah Risiko Manajemen Log
akan dibuat dan diperbarui jika
diperlukan dan akan disimpan
secara elektronik di perangkat PC milik proyek manager.
2.4 Risk Analysis
All
risks identified will be assessed to identify the range of possible project
outcomes. Risks will be prioritized by
their level of importance.
Semua risiko yang teridentifikasi akan dinilai
untuk mengidentifikasi berbagai
kemungkinan yang akan terjadi dalam proyek.
Risiko akan diprioritaskan oleh tingkat pentingnya.
2.4.1 Qualitative Risk Analysis
Probabilitas dan dampak dari kejadian untuk setiap risiko
yang diidentifikasi akan dinilai oleh
manajer proyek, dengan masukan dari tim proyek menggunakan pendekatan
sebagai berikut:
Probability
·
High – Lebih besar dari 70% probabilitas kejadian.
·
Medium – Antara 30% dan 70% probabilitas kejadian.
·
Low – Lebih kecil dari 30% probabilitas kejadian.
Impact
|
Impact
|
H
|
|
|
|
|
M
|
|
|
|
|
|
L
|
|
|
|
|
|
|
L
|
M
|
H
|
|
|
|
Probability
|
|||
·
High – Risiko yang memiliki potensi untuk sangat berdampak
pada biaya proyek, jadwal atau kinerja proyek
·
Medium – Risiko yang memiliki potensi
untuk sedikit berdampak pada biaya proyek, jadwal atau kinerja proyek
·
Low – Risiko yang hampir tidak memiliki dampak pada biaya, jadwal atau kinerja
Risiko yang berada dalam zona merah dan kuning akan memiliki rencana tanggap risiko yang mungkin mencakup strategi respon risiko dan rencana darurat risiko.
2.4.2 Quantitative Risk Analysis
Analisis peristiwa risiko yang telah
diprioritaskan menggunakan proses analisis risiko kualitatif dan pengaruh
mereka pada kegiatan proyek akan segera diestimasikan, rating numerik
diterapkan untuk setiap risiko berdasarkan analisis kuantitatif, kemudian
didokumentasikan dalam bagian rencana manajemen risiko.
2.5 Risk Response Planning
Setiap resiko besar (yang jatuh di zona
merah & kuning) akan informasikan kepada pemilik risiko pemantauan dan
mengendalikan tujuan untuk memastikan bahwa risiko tidak akan " fall
through the cracks".
Untuk setiap resiko besar, salah satu pendekatan berikut akan dipilih untuk mengatasinya :
·
Avoid
– Menghilangkan ancaman atau ketentuan atau untuk
melindungi tujuan proyek dari
dampaknya dengan menghilangkan penyebabnya
· Mitigate – Mengidentifikasi cara-cara untuk mengurangi kemungkinan atau dampak risiko
·
Accept
– Tidak ada yang akan dilakukan
·
Contingency – Tentukan tindakan yang akan diambil dalam
menanggapi risiko
·
Transfer
– Menggeser konsekuensi dari risiko kepada pihak ketiga bersama dengan kepemilikan respon dengan membuat pihak
lain yang bertanggung jawab atas resiko yang terjadi. (membeli asuransi, outsourcing, dll)
Untuk
setiap risiko yang akan dikurangi, tim proyek akan mengidentifikasi cara-cara untuk
mencegah risiko terjadi atau mengurangi dampak yang dihasilkan. Cara ini termasuk prototipe, menambahkan tugas untuk jadwal
proyek, menambahkan sumber, dll Setiap risiko sekunder yang dihasilkan dari respon
mitigasi risiko akan didokumentasikan dan mengikuti protokol manajemen risiko sebagai
risiko utama.
Untuk
setiap resiko besar yang harus dikurangi atau yang diterima, suatu tindakan akan
diuraikan secara langsung agar risiko tidak terwujud bermaksud untuk meminimalkan dampaknya.
2.6 Risk Monitoring, Controlling, And Reporting
Tingkat risiko pada proyek akan
dilacak, dipantau dan dikendalikan
dan dilaporkan di seluruh siklus
hidup proyek.
Risiko akan diberi pemilik
risiko yang akan melacak, memantau dan mengkontrol dan juga melaporkan status dan efektivitas setiap tindakan respon risiko
kepada Manajer Proyek dan Tim Manajemen Risiko.
Sebuah
"Top 10 Risk List" akan iris oleh Manajer PM / Risk atau IPT dan akan dilaporkan sebagai komponen dari
pelaporan proses status proyek untuk proyek ini.
Semua permintaan perubahan proyek akan dianalisis untuk dampak yang
mungkin mereka timbulkan terhadap proyek
Sebagaimana Events Risiko terjadi,
daftar akan kembali diprioritaskan pada ulasan
mingguan dan rencana manajemen risiko akan mencermikan semua perubahan pada daftar risiko termasuk risiko
menengah dan residual.
Manajemen akan diberitahu perubahan penting untuk risiko statusnya
sebagai komponen untuk Laporan Status Proyek Eksekutif
Manager Risiko (PM) akan:
·
Review, mengevaluasi kembali, dan memodifikasi kemungkinan dan dampak untuk setiap
risiko
·
Menganalisis risiko baru yang
diidentifikasi dan menambahkan item
ini ke daftar risiko
(atau database risiko).
·
Memantau dan mengkontrol risiko yang telah
diidentifikasi
·
Meninjau dan memperbarui daftar sepuluh risiko setiap dua minggu.
·
Menyampaikan
isu / masalah manajemen
Pemilik
Risiko akan :
·
Membantu mengembangkan respon risiko dan
risiko pemicu dan juga melaksanakan eksekus respon
risiko, jika peristiwa
risiko terjadi.
·
Berpartisipasi dalam review, evaluasi
ulang, dan modifikasi kemungkinan
dan dampak untuk
setiap item risiko secara
mingguan.
·
Mengidentifikasi dan berpartisipasi dalam analisis risiko baru
yang terjadi.
·
Menyampaikan
isu / masalah kepada PM jika,
1.
Berdampak secara signifika pada projects triple constraint atau memicu peristiwa
risiko lain terjadi.
2.
Membutuhkan tindakan sebelum
review mingguan berikutnya
3.
Strategi Risiko tidak
efektif atau menyebabkan kebutuhan untuk melaksanakan rencana darurat.
Table 2. Risks Analysis
|
Risk
|
Impact
|
Probability
|
||||
|
Salah satu staff penting dalam tim meninggalkan proyek
|
H |
L |
||||
|
Estimasi biaya dan waktu yang tidak realistis
|
M |
H |
||||
|
Perubahan spesifikasi kebutuhan selama coding
|
H |
H |
||||
|
Kegagalan pada personil
|
H |
M |
||||
|
Mengembangkan fungsi software yang salah
|
M |
L |
||||
|
Mengembangkan antarmuka pengguna yang salah
|
L |
M |
||||
|
Gold plating
|
M |
M |
||||
|
Terlambat untuk mengubah kebutuhan
|
H |
L |
||||
|
Kegagalan pada komponen yang disuplai pihak eksternal
|
H |
M |
||||
|
Kegagalan kinerja real-time
|
H |
H |
||||
|
This Week
|
Last week
|
Weeks on list
|
Risk
|
Risk resolution progress
|
||
1 |
- |
1 |
Perubahan
spesifikasi kebutuhan selama coding
|
· Libatkan
customer dan pengembang
· Melakukan meeting dengan customer secara
rutin
|
||
2 |
- |
1 |
Kegagalan
kinerja real-time
|
· Simulasi
· Benchmarking
· Prototipe
· Tuning
· Analisis
Teknis
|
||
3 |
- |
1 |
Kegagalan
pada komponen yang disuplai pihak eksternal
|
· Melakukan
benchmarking
· Inspeksi
· Spesifikasi
formal
|
||
4 |
- |
1 |
Kegagalan
pada personil
|
· Memperkerjakan
staf yang handal
· Job
matching
· Membangun
tim
· Mengadakan
pelatihan dan peningkatan karir
· Membuat
jadwal lebih awal bagi personil utama
|
||
5 |
- |
1 |
Estimasi
biaya dan waktu yang tidak realistis
|
· Membuat
beberapa estimasi
· Desain
untuk biaya
· Meningkatkan
pengembangan
· Merekam
dan menganalisa proyek sebelumnya
· Standarisasi
metode
|
||
6 |
- |
1 |
Salah
satu staff penting dalam tim meninggalkan proyek
|
· Tingkatkan
kolaborasi
·
Lakukan rolling
·
Tukar informasi
|
||
7 |
- |
1 |
Mengembangkan
fungsi software yang salah
|
· Evaluasi
proyek ditingkatkan
· Buat
metode spesifikasi yang formal
· Survey
pengguna
·
Buat prototype
·
Buat user manual lebih awal
|
||
8 |
- |
1 |
Mengembangkan
antarmuka pengguna yang salah
|
· Membuat
prototype
·
Analisis tugas
·
Keterlibatan pengguna
|
||
9 |
- |
1 |
Terlambat
untuk mengubah kebutuhan
|
· Mengubah
prosedur kendali
· Membatasi
perubahan yang terlalu banyak
·
Meningkatkan prototype
·
Meningkatkan pengembangan
(akibat perubahan)
|
||
10 |
- |
1 |
Gold
plating
|
· Mengurangi
kebutuhan
· Membuat
prototype
·
Analisis biaya manfaat
·
Desain biaya
|
||
