Anda di halaman 1dari 8

MANAJEMEN RESIKO PADA SOFTWARE PROCESS SISTEM INFORMASI PENDIDIKAN (SIMPEN)

Firli Irhamni - 5106201801 Software Sistem Informasi Pendidikan (SIMPEN) adalah sebuah software yang digunakan perguruan tinggi untuk melaksanakan operasional kegiatan pendidikan. SIMPEN saat ini telah mencapai versi yang ketiga. Adapun SIMPEN ini terdiri dari lima modul utama yaitu : SI Akademik, SI Keuangan, SI Umum dan Kepegawaian, SI Kepustakaan, dan SI Laboratorium. Salah satu tampilan output dari SIMPEN adalah sebagai berikut :

Dalam proses pembuatan SIMPEN hingga versi ketiga ini terdapat beberapa kendala atau resiko yang kemudian diinventarisasi menjadi dokumen Risk Management Plan SIMPEN. Adapun beberapa resiko yang terjadi pada proses pembuatan SIMPEN adalah sebagai berikut : o Programmer dan sistem analis yang keluar masuk Sampai SIMPEN versi yang ketiga telah melibatkan 8 programmer dan 3 sistem analis dimana pada SIMPEN ver 1.0 melibatkan 4 programmer dan 1 sistem analis. Pada SIMPEN ver 2.0 melibatkan 3 programmer dan 2 sistem analis, dan terakhir pada SIMPEN ver 3.0 melibatkan 3 programmer dan 1 sistem analis. Mayoritas pada proses pembuatan SIMPEN hingga versi yang ketiga programmer dan sistem analis banyak yang keluar masuk, hanya 15% programmer dan sistem analis yang mengikuti proses pembuatan SIMPEN dari ver 1.0 sampai ver 3.0. Hal ini mengakibatkan proses pembenahan hingga versi yang terakhir menjadi kurang maskimal. o Kelemahan Project Manager dalam koordinasi Pada proses pembuatan SIMPEN ver 2.0 mempunyai satu permasalahan yang penting yaitu lemahnya project manager dalam koordinasi sehingga menyebabkan waktu penyelesaian pembuatan SIMPEN ver 2.0 tidak sesuai jadwal yang ditentukan. o Komponen file pendukung tidak lengkap Pada saat proses pembuatan SIMPEN ver 1.0 terdapat komponen file pendukung yang tidak lengkap. Hal ini disebabkan salah satu programmer menggunakan komponen yang tidak standar (download di internet). Sehingga pada saat proses implementasi sistem terjadi beberapa kendala pada komputer di user. o Tidak bisa diintegrasikan Pada saat proses pembuatan SIMPEN ver 1.0 masing-masing programmer menggunakan bahasa pemrograman yang berbeda untuk kelima modul utama tersebut. Tiga modul utama (SI Umum dan

Kepegawaian, SI Kepustakaan, dan SI Laboratorium) menggunakan bahasa Borland Delphi dan dua modul utama lainnya menggunakan bahasa Visual Basic. Sehingga pada saat integrasi sistem terdapat kendala tidak bisa diitegrasikan. Solusi permasalahan pada saat itu adalah dengan membuat form tambahan untuk menintegrasikan kelima modul utama tersebut. o Penjelasan user tentang proses bisnis tidak detail Pada semua proses pembuatan software khususnya SIMPEN hal yang paling menjadi kendala adalah penjelasan user tentang proses bisnis dari SIMPEN tidak detail. Hal ini disebabkan karena beberapa hal : User hanya menginginkan software tersebut sebagai nilai tambah bagi institusinya. Dalam hal ini perencanaan pembuatan software tersebut tidak melalui tahapan studi kelayakan. User sendiri tidak mempunyai proses bisnis yang matang, sehingga proses bisnis tersebut akhirnya dikembalikan kepada sistem analis. Sistem analis belum menguasai proses requirement engineering dimana menggunakan tiga metode yaitu : wawancara, pengumpulan data, dan kuesioner. o Pemahaman berbeda antara bagian yang terlibat Pada proses pembuatan SIMPEN dengan lima modul utama utama tersebut melibatkan user yang bertanggung jawab pada lima modul utama tersebut, antara lain BAAK, BAUK, UPT. Komputer, Ka. Laboratorium, Bagian Keuangan, dll. Karena proses bisnis yang belum matang pada user sehingga terdapat pemahaman yang berbeda pada bagaian-bagian yang terlibat. Sehingga ini menjadi kendala bagi sistem analis untuk mengakomodasi sesuai keinginan masing-masing bagian tersebut.

o Over budget Karena banyaknya resiko yang terjadi pada proses pembuatan SIMPEN hingga versi yang ketiga ini maka proses pembuatan SIMPEN ver 1.0 dan 2.0 mengalami over budget hingga 20% dari estimasi biaya. o Over time Karena banyak yang resiko yang terjadi juga menyebabkan proses pembuatan SIMPEN mengalami over time hingga versi yang ketiga. Over time paling besar pada saat pembuatan SIMPEN ver 2.0 yang mencapai 75 hari. Dari semua manajemen resiko yang ada, maka setelah proses pembuatan SIMPEN ver 2.0 pihak developer mecoba untuk membuat Strandart Operational Procedure (SOP) untuk mengeliminasi resiko pada pembuatan SIMPEN versi berikutnya. Adapun prosedur atau kegiatan yang dijelaskan dalam SOP tersebut antara lain : o Langkah-langkah dalam melakukan requirement engineering o Penentuan bahasa pemrograman dan file pendukung yang dipakai o Struktur organisasi proses pembuatan SIMPEN o Parameter penentuan Project Manager o Penentuan estimasi biaya dan waktu o Adanya assessment pada saat interaksi antara pihak developer dan user Untuk memudahkan dalam melakukan Risk Management Plan dari dokumen SIMPEN ini digunakan template yang dikembangkan oleh Pemerintah Negara Bagian Vermont Prancis. Template tersebut mencakup Document revision, Risk Management Strategy, dan Project Risk Management Approval / Signatures.

Adapun penggunaan manajemen resiko SIMPEN pada template Risk Management Plan Pemerintah Negara Bagian Vermont sebagai berikut : Prancis adalah

RISK MANAGEMENT PLAN


Project Name: Prepared by:
Sistem Informasi Manajemen Pendidikan (SIMPEN) Formasindo

Document Revision / Release Status


Revision
1.0 2.0 3.0

Date
01/07/2004 31/07/2005 03/03/2007

Description of Changes
SIMPEN ver 1.0 SIMPEN ver 2.0 SIMPEN ver 3.0

Author
Firli Firli Firli

Modify the text of this document to fit your project.

1. Risk Management Strategy


1. Define the risk management methodology to be used The risk management process is scalable to ensure that the level, type, and visibility of risk management are commensurate with both the risk and the importance of the project.

Risk Identification Identify risks by using the Risk Assessment Questionnaire and Project Planning Risk
Evaluation Checklist, augmented to include other project specific risks, as appropriate.

Risk Categorization Group the risks into categories by using the Risk Assessment Questionnaire. The
project manager can create additional categories, as required.

Risk Impact Assessment Enter all risks into the Risk Log document. For each risk identified, assess the
risk event in terms of likelihood of occurrence (Risk Probability) and its effect on project objectives if the risk event occurs (Risk Severity = Impact Score). This information will be used to prioritize the risk using established threshold criteria.

Risk Prioritization - Risks that meet the threshold criteria will be so noted in the Risk Log. These risks will be
prioritized.

1. Risk Management Strategy

Risk Response Planning For each risk in the Risk Log that is above the Risk Threshold:
Determine the options and actions to reduce the likelihood or consequences of impact to the projects objectives. Determine the response based on a cost/benefit analysis (cost vs. expected effectiveness). Describe the actions to be taken to mitigate the risk. Describe the Signs and Symptoms that may be indicators of Risk Event occurrence. Describe the actions to be taken when the risk event occurs (contingency plan). Assign responsibilities for each agreed-upon response. Assign a due date where risk responses are time-sensitive. Incorporate this information into the Risk Log.

Risk Response Tracking:

Document the dates and the actions taken to mitigate the risk. Document the actions taken when the risk event occurred (contingency plan). Document any subsequent actions taken. Incorporate this information into the Risk Log.

Risk Monitoring - Establish systematic reviews and schedule them in the project schedule, ensuring the following reviews:

Ensure that all requirements of the Risk Management Plan are being implemented. Assess currently defined risks as defined in the Risk Log. Evaluate effectiveness of actions taken. Identify status of actions to be taken. Validate previous risk assessment (likelihood and impact). Validate previous assumptions. State new assumptions. Identify new risks. Track risk response. Establish communications.

Risk Control:

Validate mitigation strategies and alternatives. Take corrective action when actual events occur. Assess impact on the project of actions taken (cost, time, and/or resources). Identify new risks resulting from risk mitigation actions. Ensure the Project Plan (including the Risk Management Plan) is maintained. Ensure change control addresses risks associated with the proposed change. Revise the Risk Assessment Questionnaire, Project Planning Risk Assessment Checklist and other risk management documents to capture results of mitigation actions. Revise Risk Log. Establish communications.

2. Define assumptions that have a significant impact on project risk 3. Define the roles and responsibilities unique to the risk management function

1. Risk Management Strategy


Risk Management Team:
<Team Member> <Team Member> <Team Member> <Name>

Risk Response Tracking Coordinator:

4. Define risk management milestones (insert rows as needed)

Milestone
Risk Management Plan approved Risk Assessment Questionnaire tailored to project Risk Assessment Questionnaire and Project Planning Risk Evaluation Checklist complete Risk Log approved Risk Management Reviews scheduled

Date
(MM/DD/YYYY)

5. Define risk rating/scoring techniques The project will rate each identified risk (e.g., Impact Score = High, Medium, Low) based on the likelihood that the risk event will occur and the effect on the projects objectives if the risk event occurs. This will be a subjective evaluation based on the experience of those assigned to the projects risk management team. Default rating/scoring system is as follows: Impact Score can be rated as 1, 3, 5, 7, or 9 (1 = Very Low, 9 = Very High). Probability can be rated as 0.1, 0.3, 0.5, 0.7 or 0.9 (0.1 = Very Low, 0.9 = Very High). 6. Establish risk thresholds State below how the project team will plan for risk events, e.g. The project will establish risk responses for risk events that have been determined to have a rating of High. Risk Score is defined as Impact Score x Probability and is shown in the following chart. Priority is based on Risk Score. Impact Score 1 3 5 7 9 .1 0.1 0.3 0.5 0.7 0.9 .3 0.3 0.9 1.5 2.1 2.7 Probability .5 0.5 1.5 2.5 3.5 4.5 .7 0.7 2.1 3.5 4.9 6.3 .9 0.9 2.7 4.5 6.3 8.1 Green = Low Risk Yellow = Medium Risk Red = High Risk
The Project Team develops a full response plan for each item rated as High risk. These risks are watched closely. The Project Team should create a response plan for any Medium risk item where they deem it necessary. However, in general no response plan is required for Medium risk items. Medium risks are monitored on a regular basis. No action is required for Low risk items. All Risk items with a response plan are to be entered into the Risk Response Plan document.

1. Risk Management Strategy


7. Define risk communications 8. Define risk-tracking process

2. Project Risk Management Plan Approval / Signatures


Project Name: Project Manager:
I have reviewed the information contained in this Project Risk Management Plan and agree. Name Title Signature Date

The signatures above indicate an understanding of the purpose and content of this document by those signing it. By signing this document, they agree to this as the formal Project Risk Management Plan document.