0

Mobile Farming APP Risk Management Plan

Posted by Jujur Sitanggang 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 :
·     AvoidMenghilangkan ancaman atau ketentuan atau untuk melindungi tujuan proyek dari dampaknya dengan menghilangkan penyebabnya
·  MitigateMengidentifikasi cara-cara untuk mengurangi kemungkinan atau dampak risiko
·    AcceptTidak ada yang akan dilakukan
·    ContingencyTentukan tindakan yang akan diambil dalam menanggapi risiko
·    TransferMenggeser 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







 


0 Comments

Copyright Jujur Soaloon Sitangang Lipan All rights reserved. Theme by Sitanggang. | Bloggerized by Soalparna.