MANAJEMEN PROYEK

“Mengelola Risiko”
Dosen pengampu: Tri Wahyuningsih, S.E., M.Si

Kelompok 5:

1. Yoga Tri Anggoro (141160298 / EM-D)

2. Arfin Husein (141160301 / EM-D)
3. Faiz Darmawan (141160302 / EM-D)
4. Irsyad Darmawan (141160303 / EM-D)
5. Edo Putra Kharisma (141160313 / EM-D)
6. Affi Rahayu S (141160320 / EM-D)

FAKULTAS EKONOMI dan BISNIS

UPN “Veteran” Yogyakarta
2018/2019
 KATA PENGANTAR

Puji syukur kehadirat Tuhan Yang Maha Esa, yang telah melimpahkan rahmat
dan hidayah-Nya, sehingga kelompok kami dapat menyelesaikan makalah dengan judul
“MENGELOLA RISIKO”. Makalah ini disusun untuk memenuhi tugas mata kuliah
Manajemen Proyek. Kelompok kami menyadari bahwa makalah ini jauh dari kata
sempurna, oleh karena itu, kritik dan saran dari pembaca yang sifatnya membangun
makalah ini sangat kami butuhkan.
Kami ucapkan terima kasih kepada Ibu Tri Wahyuningsih, S.E., M.Si. selaku
dosen Manajemen Proyek, orang tua kami, teman-teman serta pihak yang bersangkutan
yang telah mendukung dalam penyelesaian makalah ini setiap saat. Semoga dengan
adanya makalah ini dapat bermanfaat bagi pembaca.

Yogyakarta, 26 September 2018

Tim Penulis
 BAB I
PEMBUKA

A. Latar Belakang

Dalam kehidupan sehari-hari kita sering mendengar kata “risiko” dan sudah
biasa dipakai dalam percakapan sehari-hari oleh kebanyakan orang. Risiko
merupakan bagian dari kehidupan kerja individual maupun organisasi. Berbagai
macam risiko, seperti risiko kebakaran, tertabrak kendaraan lain di jalan, risiko
terkena banjir di musim hujan dan sebagainya, dapat menyebabkan kita
menanggung kerugian jika risiko-risiko tersebut tidak kita antisipasi dari awal.

Risiko dikaitkan dengan kemungkinan kejadian atau keadaan yang dapat

mengancam pencapaian tujuan dan sasaran organisasi. Sebagaimana kita pahami
dan sepakati bersama bahwa tujuan perusahaan adalah membangun dan
memperluas keuntungan kompetitif organisasi. Risiko berhubungan dengan
ketidakpastian ini terjadi karena kurang atau tidak tersedianya cukup informasi
tentang apa yang akan terjadi.

Sesuatu yang tidak pasti (uncertain) dapat berakibat menguntungkan atau

merugikan. Ketidakpastian yang menimbulkan kemungkinan menguntungkan
dikenal dengan istilah peluang (opportunity), sedangkan ketidakpastian yang
menimbulkan akibat yang merugikan disebut dengan istilah risiko (risk). Dalam
beberapa tahun terakhir, manajemen risiko menjadi trend utama baik dalam
perbincangan, praktik, maupun pelatihan kerja. Hal ini secara konkret
menunjukkan pentingnya manajemen risiko dalam proyek maupun bisnis pada
masa kini.

Pada perencanaan pembuatan proyek sebuah sistem, diperlukan berbagai

macam komponen yang terlibat didalamnya. Satu hal yang harus diperhatikan
atau diutamakan oleh seorang manajer proyek dalam melakukan perencanaan
adalah menghitung, baik secara kualitatif maupun kuantitatif, risiko yang akan
terjadi dalam proses pengerjaan.
 Risiko proyek adalah peristiwa tidak pasti yang bila terjadi memiliki pengaruh
positif atau negatif terhadap minimal satu tujuan proyek (waktu, biaya, ruang
lingkup, mutu). Risiko mungkin memiliki satu atau lebih penyebab, yang bila
terjadi memiliki satu atau lebih dampaknya terhadap manajemen.

Dan apabila kita garis besarkan secara keseluruhan maka yang dimaksud
dengan manajemen proyek dan risiko adalah 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 atau dapak
negatifnya.

Manajemen risiko sangat penting bagi kelangsungan suatu usaha atau

kegiatan. Jika terjadi suatu bencana, seperti kebakaran atau kerusakan, perusahaan
akan mengalami kerugian yang sangat besar, yang dapat menghambat,
mengganggu bahkan menghancurkan kelangsungan usaha atau kegiatan operasi.
Manajemen risiko merupakan alat untuk melindungi perusahaan dari setiap
kemungkinan yang merugikan.

B. Rumusan Masalah

Berdasarkan latar belakang masalah yang telah dikemukakan sebelumnya dan

pentingnya mengelola risiko maka rumusan masalah yang akan di bahas dalam
makalah ini adalah:
1. Bagaimana proses manajemen risiko?
2. Bagaimana mengidentifikasi risiko?
3. Apa saja langkah-langkah penilaian risiko?
4. Bagaimana strategi mengembangkan respon risiko?
5. Bagaimana cara pengendalian respon risiko?
 BAB II

PEMBAHASAN

Setiap manajer proyek memahami risiko yang melekat pada proyek, risiko yang
tidak dapat bisa dipisahkan dari proyek. Tidak ada perencanaan yang dapat mengatasi
risiko atau mampu mengendalikan peristiwa kesempatan. Dalam konteks proyek, risiko
adalah suatu kondisi atau peristiwa tidak pasti yang, jika hal itu terjadi, mempunyai efek
positif atau negatif terhadap sasaran proyek. Sebuah risiko mempunyai penyebab dan jika
risiko itu terjadi akan ada konsekuensi. Jika yang terjadi adalah peristiwa yang tidak pasti,
maka dampaknya pada biaya, jadwal, dan kualitas proyek.

Risiko dapat mengantisipasi konsekuensi, misal biaya atau jadwal molor.

Sekalipun risiko dapat mempunyai konsekuensi positif seperti pengurangan harga tak
terduga pada material, namun fokus bab ini adalah pada hal-hal yang dapat menyimpang
(negatif) dan proses manajemen risiko.

Manajemen risiko berusaha mengenali dan mengelola masalah potensial dan tak
terduga yang mungkin terjadi ketika proyek diimplementasikan. Manajemen risiko
mengidentifikasikan sebanyak mungkin peristiwa risiko (sesuatu yang bisa berlangsung
salah atau menyimpang), memperkecil dampak mereka (apa yang dapat dilakukan pada
peristiwa tersebut sebelum proyek mulai), megelola respons terhadap peristiwa-peristiwa
yang sungguh-sungguh berdampak besar (rencana kontingensi), dan menyediakan dana
kontingensi untuk mengatasi peristiwa risiko yang benar-benar terjadi.

A. Proses Manajemen Risiko

Gambar 1. menunjukkan model grafis dari dilema manajemen risiko. Peluang

terbesar terjadinya sebuah peristiwa risiko (misal, kesalaham estimasi waktu, biaya,
atau teknologi desain) adalah dalam hal konsep, perencanaan, dan tahan mulai (start-
up) dari proyek. Dampak biaya suatu peristiwa risiko di dalam proyek lebih kecil jika
peristiwa peristiwa terjadi lebih awal, bukan kemudian. Tahap-tahap awal dari proyek
menunjukkan periode ketika ada kesempatan untuk memperkecil dampak atau
pekerjaan di sekitar risiko potensial. Dan sebaliknya, ketika proyek berlangsung
separuh jalan, baiaya peristiwa risiko yang terjadi meningkat dengan cepat. Mengenli
peristiwa risiko proyek dan memutuskan respons sebelum proyek mulai adalah
sebuah pendekatan yang lebih bijaksana daripada tidak mencoba menglola risiko.

Gambar 1. Grafik Peristiwa Risiko

Manajemen risiko adalah sebuah pendekatan proaktif, bukan reaktif. Ia

merupakan proses preventif yang dirancang untuk memastikan bahwa kejutan
dikurangi dan bahwa konsekuensi negatif karena peristiwa yang tidak diinginkan
diperkecil. Manajemen risiko juga menyiapkan manajer proyek untuk menanggung
risiko ketika waktu, biaya, dan atau keunggulan teknis dapat dicapai. Manajemen
risiko proyek memberi manajer proyek pengendalian yang lebih baik atas masa depan
dan dengan signifikan meningkatkan peluang mencapai sasaran proyek secara tepat
waktu, sesuai anggaran, dan memenuhi kinerja teknis (fungsional) yang diperlukan.

Sumber risiko proyek tak terbatas. Ada sumber di luar organisasi seperti inflasi,
penerimaan pasar, nilai tukar, dan peraturan pemerintah. Dalam praktik, peristiwa
risiko seperti itu sering disebut “ancaman”. Hal itu untuk membedakan mereka dari
peristiwa risiko yang tidak menjadi tanggung jawab manajer proyek atau tim. Karena
risiko eksternal tersebut pada umumnya dipertimbangkan sebelum mengambil
keputusan untuk melanjutkan proyek, maka mereka tidak dimasukkan dalam diskusi
risiko proyek. Akan tetapi, risiko eksternal sangat penting dan harus diperhatikan.
B. Langkah 1: Identifikasi Risiko

Proses manajemen risiko memulai dengan berusaha menghasilkan daftar semua

risiko yang mungkin yang dapat memengaruhi proyek. Pada umumnya manajemen
proyek bekerja sama sepanjang tahap perencaaan. Tim manajemen risiko terdiri dari
anggota tim inti dan stakeholders lain yang relevan. Tim menggunakan brainstorming
dan teknik identifikasi masalah untuk mengidentifikasikan masalah potensial. Peserta
didorong untuk terbuka dan menghasillkan sebanyak mungkin risiko yang dapat
terjadi. Kemudian, sepanjang tahap penilaian, peserta akan memiliki kesempatan
untuk menganilisi dan membuang risiko-risko yang tidak masuk akal.

Satu kesalahan umum yang dibuat pada awal proses identifikasi risiko adalah
fokus pada konsekuensi, bukan pada peristiwa-peristiwa yang dapat menghasilkan
konsekuensi. Apa yang perlu mereka fokuskan adalah peristiwa-peristiwa yang bisa
menyebabkan hal itu terjadi (yaitu estimasi yang buruk, cuaca kurang baik,
keterlambatan pengirima, dll). Hanya dengan memusatkan pada peristiwa nyata maka
solusi potensial dapat ditemukan.

Fokus pada awal seharusnya adalah pada risiko yang dapat memengaruhi proyek
keseluruhan, bukan pada satu bagian spesifik dari proyek atau jaringan. Setelah risiko
makro dikenali, area spesifik dapat dicek. Alat efektif untuk mengidentifikasi risiko
spesifik adalah work breakdown structure (WBS). Penggunaan WBS mengurngi
kesempatan luputnya sebuah peristiwa risiko.

Profil risiko adalah alat lain yang dapat membantu tim manajemen
mengidentifikasi dan pada akhirnya menganalisis risiko. Profil risiko adalah daftar
pertanyaan yang meyoroti area ketidakpastian pada sebuah proyek. Pertanyaan
tersebut dikembangkan dan ditinggalkan dari proyek-proyek sebelumnya yang
serupa.

Profil risiko yang baik dikhusukan pada jenis proyek yang dimasalahkan. Profil
risiko mengenali kelemahan dan kekuatan unik dari perusahaan. Akhirnya, profil
risiko menyoroti baik risiko teknis maupun risiko manajemen. Biasanya profil risiko
dihasilkan dan menjadi tanggung jawab personel dari kantor proyek. Profil ini jika
dijaga tetap up-to-date bisa menjadi sumber daya yang powerful dalam proses
manajemen risiko.

Catatan historis dapat melengkapi atau digunakan ketika profil risiko yang resmi
tidak tersedia. Tim desain dapat menyelidiki apa yang terjadi pada proyek serupa di
masa lalu untuk mengidentifikasi risiko potensial. Manajer proyek sebaiknya mencari
nasihat dari veteran manajer proyek. Proses identifikasi risiko tidak terbatas hanya
pada tim inti. Input dari pelanggan, sponsor, subkontsktor, penjual, dan stakeholders
lain harus dicari, stakeholder yang relevan dapat secara resmi diwawancarai atau
diliatkan dalam tim manajemen risiko. Para pemain tersebut memliki perspektif yang
sangat berharga, tetapi melinbatkan mereka dalam proses manajemen risiko juga
dapat membuat mereka lebih berkomitmen terhadap sukses proyek.

Salah satu kunci sukes mengidentfikasi risiko adalah sikap. Sikap “can do”
penting selama implementasi, dan manajer proyek harus mendorong pemikiran kritis
ketika ia mengidentifikasi risiko. Tujuannya adalah menemukan maslaah sebelum
mereka terjadi, dan peserta harus memercayai hukum Murphy –“ semua yang daoat
berjalan salah, akan berjalan salah.” WBS dan profil risiko adalah peranti yang
bermanfaat untuk memastikan bahwa tidak ada yang dibiarkan. Ketika dilakukan
dengan baik, jumlah risiko yang teridentifikasi dapat berlimpah dan sedikit
mankutkan.

C. Langkah 2: Penilaian Risiko

Langkah pertama menghasilkan daftar risiko potensial. Tidak semua risiko

tersebut mendapat perhatian. Beberapa risiko sepele dan dapat diabaikan, sedangkan
yang lainnya merupakan ancaman serius bagi sukses proyek. Para manajer harus
mengembangkan metode-metode untuk menelusuri daftar risiko dan menghapus
risiko yang tidak penting dan memerhatikan risiko dalam hal nilai pentingnya dan
kelayakannya untuk diperhatikan.

Analisis skenario adalah teknik yang paling umumm digunakan untuk

menganalisis risiko. Anggota tim menilai masing-masing risiko dalam hal:

1. Peristiwa yang tidak diinginkan.

 2. Semua hasil akhir dari kejadian sebuah peristiwa.
3. Manfaat penting atau dampak merusak atau merugikan dari sebuah peristiwa.
4. Peluang atau probabilitas terjadinya peristiwa.
5. Kapan peristiwa dapat terjadi pada proyek.
6. Interaksi dengan bagian lain dari proyek ini atau dari proyek lain.

Penundaan dalam proyek dapat menunda proyek lain atau mengharuskan

perubahan prioritas. Tersedianya informasi ini akan memfasilitasi penilaian terhadap
setiap peristiwa risiko yang layak diperhatikan.

Dokumentasi analasisi skenario dapat dilihat dalam berbagai format penilaian

risiko yang digunakan oleh perusahaan. Gambar 2. adalah contoh parsial suatu format
penilaian risiko yang digunakan pada proyek SI (sistem informasi). Tim proyek telah
mengidentifikasi risiko, termasuk masalah antarmuka dengan sistem perangkat lunak saat
ini, sistem freezing setelah instalasi, end-user, menentang dan mengeluhkan perubahan,
dan peralatan perangkat keras yang tidak berfungsi. Selain estimasi peluang, ancaman
atau kerugian, dan kapan peristiwa itu mungkin terjadi, tim proyek juga memperkirakan
apakah mereka akan mampu mendeteksi bahwa peristiwa tersebut akan terjadi untuk
mengambil tindakan mitigasi (mengurangi atau memperkecil risiko). Perhatikan bahwa
tim menilai kesukaran mendeteksi sistem freezing “tinggi” (#5) karena sistem crash tanpa
memberi peringatan, sedangkan “reaksi pemakai yang tidak menyenangkan” dinilai
sedang (#3) karena gelombang besar perlawanan bisa dideteksi sebelum ada
pemberontakan terbuka.

Gambar 2. Form Penilaian Risiko

 Organisasi sering menemukan bahwa menggolongkan tingkat keparahan risiko
yang berbeda-beda ke dalam beberapa format matriks penilaian risiko, merupakan hal
yang berguna matriks umumnya dibuat dengan memasukkan dampak dan kemungkinan
peristiwa risiko.

Matriks dibagi menjadi zone merah, kuning, dan hijau yang mewakili risiko
utama, sedang, dan minor berturut-turut. Zone merah memusat di sudut kanan atas dari
matriks (dampak tinggi atau kemungkinan tinggu), sedangkan zone hijau memusat di suut
kiri bawah (dampak rendah atau kemungkinan rendah). Risiko sedang, zone kuning dari
bagian tengah sampai bawah dari matriks. Karena dampak peristiwa risiko biasanya
dinilai lebih penting dibanding kemungkinan risiko, zone merah (risiko utama) meluas
lebih jauh sepanjang kolom dampak yang tinggi.

Masalah antarmuka dan sistem freezing akan ditempatkan pda zone mereah (risiko
utama), sedangkan reaksi yang tak menyenangkan dari pemakai dan malfungsi perangkat
keras akan ditempatkan pada zone kuning (risiko sedang). Matriks tingkat keparahan
risiko menyediakan basis untuk memprioritaskan risiko mana yang perlu diperhatikan.
Risiko zone merah mendapat prioritas pertama yang diikuti oleh risiko zone kuning.
Risiko zone hijau umumnya dianggap tidak penting atau tidak logis dan dibiarkan kecuali
jika stattus mereka berubah.

Failure Mode and Effects Analysis (FIMEA) memperluas matriks tingkat

keparahan risiko dengan memasukkan kemudahan mendeteksi, dalam persamaan berikut:

𝐷𝑎𝑚𝑝𝑎𝑘 × 𝐾𝑒𝑚𝑢𝑛𝑔𝑘𝑖𝑛𝑎𝑛 × 𝐷𝑒𝑡𝑒𝑘𝑠𝑖 = 𝑁𝑖𝑙𝑎𝑖 𝑅𝑖𝑠𝑖𝑘𝑜

Ketiga dimensi tersebut dinilai menurut skala lima poin. Deteksi digambarkan
sebagai kemapuan tim proyek untuk membedakan bahwa peristiwa risiko, segera terjadi.
Skor 1 akan diberikan bahkan jika seekor simpanse dapat menyoroti risiko yang muncul.
Skor deteksi paling tinggi, dengan nilai 5, akan diberikan ke peristiwa yang hanya dapat
ditemukan setelah peistiwa yang hanya dapat ditemukan setelah peristiwa sudah
terlambat atau sudah terjadi (yaitu sistem freezing). Skala serupa akan digunakan untuk
severitas dampak dan kemungkinan atau probabilitas terjadinya peristiwa. Ppembobotan
risiko kemudian didasarkan pada skor keseluruhan mereka. Sebagai contoh, sebuah risiko
dengan dampak “1” atau risiko dengan kemungkinan dangat rendah dan skor detejksi
kemudahan adalah 1 (1×1×1 = 1). Sebaliknya, risiko dengan dampak tinggi dengan
kemungkinan tinggi dan mustahil untuk dideteksi akan mendapat skor 125 (5×5×5 = 125).
Luasnya rentang skor numerik memudahkan untuk mengelompokkan risiko menurut
signifkansi keseluruhan.

Gambar 3. Matriks Tingkat Keparahan Risiko

1. Analisi Probabilitas

Ada beberapa teknik statistik yang tersedia bagi manajer proyek yang dapat
membantu mereka memperkirakan risiko proyek. Pohon keputusan digunakan
untuk alternatif tindakan dengan menggunakan nilai-nilai yang diharapkan.
Variasi statistik net present value (NPV) digunakan untuk menilai risiko cash cow
dalam proyek. Korelasi antara arus kas proyek yang telah lalu dan kurva-S (kurva
baiya proyek kumulatif – baseline – pada umur hidup proyek) digunakan ntuk
meniali risiko cash cow.

PERT (program evaluation and review technique) dan simulasi PERT dapat
digunakan untuk mengkaji ulang aktivitas dan risiko proyek. PERT dan teknik
yang terkait membutuhkan perspektif yang lebih makro dengan memrhatikan
biaya keseluruhan dan risiko jadwal. Disini fokus bukanlah pada sebuah peristiwa,
melainkan pada kemungkinan proyek akan selesai tepat waktu dan sesuai
anggaran. Metode ini bermanaat untuk menilai risiko keseluruhan dari proyek dan
kebutuhan akan hal-hal seperti dana kontingensi, sumber daya, dan waktu.
Penggunaan simulasi PERT meningkat karena ia menggunakan data yang sama
yang diperlukan untuk PERT dan perangkat lunak untuk melakukan simulasi telah
tersedia.

Pada dasarnya simulasi PERT mengasumsikan distribusi statistik (range

antara optimistik dan pesimistis) untuk masing-masing durasi aktivitas. Ia
kemudian mensimulasikan jaringan (barangkali lebih dari 1.000 simualsi) dengan
menggunakan sebuah generator angka acak. Hasilnya adalah probabilitas relatif,
yang disebut indkes kritis (criticality index), dimana sebuah aktivitas menjadi
kritis dibawah banyak durasi aktivitas berbeda yang mungkin terjadi untuk
masing-masing aktivitas. Simlasi PERT juga menyediakan daftar jalur kirits
potensial dan probabilitas terjadinya jalur tersebut. Tersedianya informasi ini
sanagt memfasilitas identifikasi dan penilain risiko jadwal.

2. Analisis Skenario: Semikuantitatif

Manajer proyek kerap menggunakan atau menyediakan probabilitas untuk

analisis risiko. Tantangan disini adalah membuat tim proyek mengartikulasikan
risiko (dalam kata-kata). Informasi tersebut dapat sangat praktis dan sekaligus
memberikan manfaat probabilitas dan teori utilitas.

Pendekatan ini menggunakan waktu karena kebanyakan peristiwa risiko

bergantung pada waktu, dampak keterlambatan proyek, dan kemudahan untuk
dipahami oleh anggota tim risiko. Dengan menggunakan angka untuk
memverifikasi dampak, pendekatan ini bertindak sebagai cek realitas terhadap
analisis dan risiko yang telah dikenali. Hasil akhir dari proses tersebut adalah
“megurung” risiko proyek dan durasi yang mungkin. Pendekatan ini juga sangat
berguna untuk menjelaskan kepada anggota proyek mengenai risiko-risiko yang
melekat pada sebuah proyek.
D. Langkah 3: Mengembangkan Respons Risiko
1. Mengurangi Risiko

Mengurangi atau memperkecil risiko pada umumnya menjadi alternatif

pertama yang dipertimbangkan. Pada dasarnya ada 2 strategi untuk mengurangi
risiko. (1) Mengurangi kemungkinan terjadinya peristiwa tersebut dan atau (2)
mengurangi dampak peristiwa tersebut pada proyek. Contoh strategi pertama
ditemukan pada sebuah proyek sistem informasi. Tim proyek bertanggung jawab
menginstal sebuah sistem informasi baru di perusahaan induk mereka. Sebelum
menginmplementasikan proyek, tim menguji sistem baru pada sebuah jaringan
yang lebih kecil, yang terisolasi. Dari pengujian tersebut, mereka menemukan
berbagai masalah dan dapat sampai pada solusi sebelum impleentasi. Tim masih
mendapati masalah pada instalasi, tetapi dampak buruknya sangat jauh berkurang.
Contoh lain mengurangi kemungkinan terjadinya risiko adalah penjadwalan
pekerjaan outdoor di sepanjang musim panas, melakukan investasi pelatihan
keselamatan, dan memilih material dan peralatan kualitas tinggi.

Jika durasi dan biaya diabaikan, manajer akan meningkatkan estimasi

ketidakpastian. Adalah biasa menggunakan perbandingan antara proyek lama dan
proyek baru untuk melakukan penyesuaian waktu atau biaya. Perbandingan atau
rasio pada umumnya bertindak sebagai konstanta.

Alternatif strategi mitigasi adalah mengurangi dampak risiko jika ia terjadi.

Sebagai contoh, proyek pembangunan jembatan menggambarkan pengurangan
risiko. Proyek jembatan baru untuk pelabuhan pantai akan menggunakan proses
beton curah kontinu yang dikembangkan oleh sebuah perusahaan Australia untuk
menghemat waktu dan biaya. Risiko utama adalah proses penuangan kontinu
untuk masing-masing bagian utama dari jembatan tidak bisa disela. Semua
gangguan akan menyebabkan keseluruhan bagian semen diruntuhkan dan dimulai
dari awal kembali. Penilaian risiko yang mungkin bisa terjadi berpusat pada
pengiriman semen dari pabrik. Truk bisa ditunda atau pabrik bisa berhenti
beroperasi. Risiko seperti itu akan mengakibatkan biaya penundaan yang luar
biasa. Risiko dikurangi dengan membangun dua pabrik semen portabel tambahan
di dekat jalan raya yang berbeda, 20 mil dari proyek jembatan, dan truk extra
standby segera setiap kali penuangan kontinu diperlukan.

2. Menghindarkan Risiko

Menghindarkan risiko adalah mengubah rencana proyek untuk menghapus

kondisi atau risiko. Sekalipun mustahil menghapus semua peristiwa risiko, namun
beberapa risiko spesifik dapat dihindarkan sebelum meluncurkan proyek. Sebagai
contoh, mengadopsi teknologi yang telah terbukti sebagai ganti teknologi yang
bersifat percobaan, dapat meghapuskan kegagalan teknik. Memilih pemasok
Australia versus pemasok Indonesia akan menghapuskan peluang kerusuhan
politis yang dapat mengganggu persediaan material kritis.

3. Memindahkan Risiko

Melewatkan risiko kebagian lain adalah hal biasa, pemindahan tersebut tidak
mengubah risiko. Memindahkan risiko ke bagian lain selalu menimbulkan
pengeluaran besar. Kontak fixed-price adalah contoh klasik pemindahan risiko
dari pemilik ke kontraktor. Kontraktor memahami perusahaan akan membayar
semua risiko yang kelihatan. Oleh karena itu, faktor risiko moneter ditambahkan
ke harga penawaran kontrak. Sebelum memtuskan pemindahan risiko, pemilik
perlu memtuskan bagian mana yang paling baik dapat mengendalikan aktivitas
yang akan mendorong ke arah risiko yang terjadi.

Mengindentifikasi dan mendokumentasikan tanggung jawab untuk

menangani risiko merupakan hal yang sangat mendesak. Cara lain untuk
memindahkan risiko adalah asuransi. Akan tetapi, dalam kebanyakan kasus cara
ini tidak praktis karena menggambarkan kondisi peristiwa risiko proyek kepada
broker asuransi yang tidak familiar dengan proyek adalah hal yang sulit dan
mahal. Tentu saja, peristiwa risiko dengan probabilitas rendah dan konsekuensi
tinggi seperti bencana alam lebih mudah digambarkan dan diasuransikan. Obligasi
dan garansi adalah keuangan lain yang dipakai untuk memindahkan risiko.
4. Berbagi Risiko

Berbagi risiko (sharing risk) adalah mengalokasikan proporsi risiko ke

beberapa bagian yang berbeda. Contoh, Airbus A340. Risiko riset dan
pengembangan dialokasikan antarnegara Eropa, termasuk Inggris dan Perancis.

Berbagi risiko mendapat banyak perhatian pada tahun-tahun belakangan ini

sebagai motivasi untuk memperkecil risiko, dalam beberapa kasus memangkas
biaya proyek. Metode baru mungin akan memasukkan biaya start-up tambahan
serta risiko jika proses yang baru tidak dapat bekerja. Pada umumnya biaya risiko
dan manfaat dari proses yang telah ditingkatkan berada pada baris 50/50 antara
pemilik dan perusahaan yang menerima kontrak.

5. Menahan Risiko

Dalam beberapa kasus, sebuah keputusan secara sadar dibuat untuk menerima
risiko dari sebuah peristiwa. Beberapa risiko menjadi sangat besar jika dianggap
pemindahan atau pengurangan peristiwa risiko tidak mungkin dilakukan (misal:
banjir atau gempa bumi). Pemilih proyek mengasumsikan risiko karena
kesempatan peristiwa kesempatan peristiwa itu terjadi nampaknya sangat besar.
Dalam kasus lain, risiko yang dikenali dalam cadangan anggaran dengan mudah
diasobsi jika risiko tersebut kemudian menjadi kenyataan. Dalam beberapa kasus
sebuah peristiwa risiko dapat diabaikan, karena itu membengkaknya biaya akibat
terjadinya peristiwa risiko haruslah diterima.

Semakin besar usaha yang dikeluarkan untuk merespon risiko sebelum proyek
memulai, semakin banyak kesempatan untuk memperkecil kejutan proyek.
Mengetahui respon pada sebuah peristiwa risiko akan ditahan, dipindahkan, atau
dibagi bersama sangat mengurangi ketidakpastian dan tekanan ketika peristiwa
risiko terjadi. Lagi pula, pendekatan terstruktur seperti itu memungkinkan adanya
pengendalian.
E. Perencanaan Kontingensi

Rencana kontingensi adalah sebuah rencana alternatif yang akan digunakan jika
suatu peristiwa risiko yang diperkirakan belum menjadi kenyataan. Rencana
kontingensi menghadirkan tindakan-tindakan yang akan mengurangi atau
memperkecil dampak negatif dari peristiwa risiko. Seperti semua rencana, rencana
kontingensi menjawab pertanyaan tentang apa, di mana, kapan, dan berapa banyak
tindakan yang akan berlangsung. Tidak adanya rencana kontingensi, ketika sebuah
perbaikan. Penangguhan ini dapat memicu rasa panik dan menerima perbaikan
pertama yang diusulkan. Keputusan setelah suatu kejadian, yang diambil dibawah
tekanan, dapat mahal dan berbahaya. Rencana kontingensi yang dilakukan sejak awal
dapat memfasilitasi transisi yang smooth ke tindakan perbaikan atau rencana work-
around. Ketersediaan rencana kontingensi secara signifikan dapat meningkatkan
kesempatan sukses proyek.
Kondisi-kondisi untuk mengaktifkan implementasi rencana kontingensi harus
diputuskan dan didokumentasikan dengan jelas. Rencana perlu memasukan estimasi
biaya dan mengidentifikasi sumber pembiayaan. Semua bagian yang dipengaruhi
perlu menyetujui rencana kontingensi dan membuat komitmen. Karena implementasi
rencana kontingensi dapat menggangu urutan pekerjaan, maka semua rencana
kontingensi harus dikomunikasikan ke anggota tim sedemikian sehingga perlawanan
dan kejutan diperkecil.
Berikut ini sebuah contoh: Sebuah perusahaan komputer high-tech bermaksud
memperkenalkan sebuah produk “platform” baru pada tanggal target yang sangat
spesifik. Empat puluh tujuh tim proyek semuanya setuju bahwa keterlambatan tidak
akan bisa diterima. Rencana kontingensi mereka untuk dua pemasok besar untuk
komponen yang diperlukan menunjukkan betapa seriusnya pandangan mereka
terhadap manajemen risiko. Satu pabrik pemasok berada di San Andreas Fault.
Rencana kontingensi mempunyai pemasok alternatif, yang secara konstan diperbarui.
Pemasok ini memproduksi tiruan komponen di pabrik lain. Pemasok lain di Toronto,
Kanada, menunjukan risiko pengiriman pada tanggal jauh tempo mereka karena
potensi cuaca tidak baik. Rencana kontingensi ini memerlukan pesawat carteran (telah
dikontrak agak pesawat standby) jika transportasi melalui darat menyebabkan
masalah penundaan. Bagi orang luar, rencana ini tampak sedikit ekstrem, tetapi dalam
 industri high-tech di mana waktu tiba di pasar adalah segalanya, risiko dari peristiwa
yang telah dikenali akan mendapat perhatian serius.
Matriks respons risiko seperti yang ditunjukan pada Gambar 4. bermanfaat untuk
meringkas bagaimana tim proyek berencana mengatur risiko yang telah dikenali.
Lagi, proyek Windows Office 2000 XP (lihat Gambar 4.) digunakan untuk
menggambarkan matriks tersebut. Langkah pertama adalah mengidentifikasi apakah
mengurangi, membagi, memindah, atau menerima risiko. Tim memutuskan untuk
mengurangi kesempatan system freezing dengan mengadakan percobaan dengan
sebuah prototipe sistem. Percobaan prototipe tidak hanya mengizinkan mereka
mengidentifikasi dan memperbaiki kenversi “bug” sebelum instalansi aktual, tetapi
juga menghasilkan informasi yang dapat bermanfaat untuk meningkatkan penrimaan
pemakai akhir. Tim proyek kemudian dapat mengidentifikasi dan
mendokumentasikan perubahan antara sistem lama dan sistem baru yang akan
disatukan untuk pelatihan para pemakai. Risiko malfungsi peralatan dipindahkan
dengan memilih pemasok yang dapat dipercaya dengan sebuah program jaminan yang
kuat.
Peristiwa Kemungkinan Pemicu Siapa yang
Risiko Rencana bertanggung
Kontingensi Jawab
Masalah Mengurangi Work around Tidak diselesaikan Nils
antarmuka sampai bantuan dalam 24 jam
datang
System Mengurangi Instal ulang OS Masih frozen setelah Emmylou
freezing satu jam
Keluhan Mengurangi Meningkatkan Panggilan dari Eddie
pemakai dukungan staf manajemen puncak
Malfungsi Dipindahkan Memesan merek Penggantian tidak Jim
peralatan lain bekerja
Gambar 4. Matriks Respons Risiko

Langkah berikutnya adalah mengidentifikasi rencana kontingensi jika risiko masih

terjadi. Sebagai contoh, jika masalah antarmuka terbukti tidak dapat ditanggulangi, tim
akan mencoba cara work-around sampai tenaga ahli pihak penjual datang untuk
membantu memecahkan masalah. Jika ketidakpuasan pemakai tinggi, kemudian
departemen SI akan menyediakan lebih banyak staf pendukung. Jika tim tidak mampu
mendapatkan peralatan yang dapat diandalkan dari pemasok yang asli, mereka akan
memesan merek berbeda dari penyalur kedua. Tim juga harus mendiskusikan dan
menyetujui apa yang akan menjadi “pemicu” implementasi rencana kontingens. Dalam
kasus sistem freezing, pemicu tidak mampu memecahkan sistem freezing dalam satu jam
atau, dalam kasus reaksi pemakai yang tidak menyenangkan, panggilan dengan nada
marah datang dari manajemen puncak. Akhirnya, perlu ditugaskan individu yang
bertanggung jawab untuk memonitor risiko potensial dan memulai rencana kontingensi.
Manajer proyek yang cerdas menetapkan protokol untuk merespons kontingensi sebelum
protokol diperlukan. Contoh mengenai pentingnya membangun protokol dapat dilihat
pada Snapshot dari Praktik: Manajemen Risiko di Puncak Dunia.
Beberapa dari metode yang paling umum untuk menangani risiko dibahas
dibawah ini:
1. Risiko Teknis
Risiko teknis sungguh problematis; mereka dapat sering menjadi alasan yang
menyebabkan proyek dihentikan. Bagaimana jika proses atau sistem tidak bekerja?
Rencana kontingensi atau backup dibuat untuk berbagai kemungkinan yang telah
diperkirakan. Sebagai contoh, Carrier Transicold dilibatkan dalam pengembangan
sebuah unit pendingin baru milik Phoenix untuk aplikasi truk trailer. Unit baru ini
akan menggunakan panel dibulatkan dibuat dari metal terikat, yang saat itu
merupakan teknologi baru bagi Transicold. Lagi pula, salah saty pesaingnya telah
mencoba (tidak berhasil) menyertakan barang metal yang terikat dalam produk
mereka. Tim proyek berupaya keras membuat teknologi baru tersebut bekerja, tetapi
gagal sampai akhir proyek. Namun mereka bisa mendapatkan lem baru untuk
mengikat barang metal untuk menyelesaikan proyek. Sepanjang proyek, tim
mempertahankan pendekatan pabrikasi welded-panel untuk berjaga-jaga seandainya
mereka gagal. Jika pendekatan kontingensi ini diperlukan, ia akan meningkatkan
biaya produksi, tetapi proyek akan selesai tepat waktu.
Selain strategi backup, manajer proyek harus mengembangkan metode untuk
dengan cepat menilai apakah ketidakpastian teknis dapat dipecahkan. Penggunaan
program CAD yang canggih sangat membantu memecahkan berbagai masalah desain.
Smith dan Reinertsen, dalam buku mereka, Developing Product in Half the Time,
menyatakan bahwa tidak ada pengganti untuk membuat sesuatu dan melihat
bagaimana ia bekerja, merasakan, atau melihat. Mereka menyatakan bahwa orang
perlu terlebih dahulu mengidentifikasi area teknis berisiko tinggi, kemudian
membangun model atau desain eksperimen untuk memecahkan risiko secepat
mungkin. Dengan mengisolasi dan menguji masalah teknis kunci sejak dini dalam
sebuah proyek, kelayakan proyek dapat dengan cepat di tentukan dan penyesuaian
yang diperlukan pun kemudian dilakukan, misalnya mengerjakan lagi proses atau
dalam beberapa hal menghentikan proyek. Pada umumnya manajer proyek dan
oemilik membuat keputusan mengenai risiko teknis.
2. Risiko Jadwal
Mengelola risiko penjadwalan umumnya memerlukan keputusan imbal balik.
Adalah ironis jika para manajer praktisi secara aktual meningkatkan risiko
penjadwalan dengan sebagai dari keputusan mereka. Situasi seperti itu dibahas di
bagian “Kompresi Jadwal Proyek”.
a. Penggunaan Slack
Ketika beberapa manajer mengetahui slack jaringan, mereka berhenti
mencemaskan apakah aktivitas mereka selesai tepat waktu-mengapa cemas jika
ada slack 10 hari! Sayangnya, slack itu mungkin diperlukan oleh aktivitas lain
pada jalur yang harus start tepat setelah suatu aktivitas atau meninggalkan sedikit
slack atau bahkan tidak ada slack yang tersedia karena slack jalur sudah habis
digunakan. Mengelola slack dapat menjadi sebuah metode sempurna untuk
mengurangi risiko jadwal. Ingat, penggunaan slack membuat lebih banyak
aktivitas lebih dekat dengan start akhirnya, dengan demikian risiko penundaan
proyek pun meningkat.
b. Tanggal Durasi yang Ditentukan
Pengalaman kami menunjukan bahwa 80 persen dari semua proyek
menentukan tanggal durasi. Umumnya ini berarti seseorang (dengan otoritas)
telah menentukan bahwa proyek atau milestone dapat atau harus selesai pada
suatu tanggal spesifik. Contohnya, menyelesaikan pengerjaan sebuah jalan pada
1 Januari atau mengmbangkan sebuah video game untuk menyambut Natal.
Durasi proyek yang telah ditetapkan kerap kali merupakan keputusan top-down
yang tidak melibatkan perencanaan bottom-up dan sering juga mengabaikan
waktu normal yang diperlukan untuk menyelesaikan proyek. Jika ini menjadi
 kasus, maka perlu diadakan pertemuan. Durasi proyek yang ditetapkan akan
mengakibatkan aktivitas yang sedang dilakukan dikerjakan dengan lebih cepat
dibanding waktu normal, dengan metode berbiaya rendah. Pendekatan bergerak
cepat ini meningkatkan biaya dan kesempatan bagi banyak aktivitas untuk
menjadi terlambat dan mengurangi fleksibilitas dalam sistem penjadwalan total.
Ada saat-saat dimana durasi yang dipaksakan memang diperlukan untuk
menyelesaikan sebuah proyek (misal, waktu tiba dipasar untuk memenangkan
persaingan), tetapi pada hampir semua kasus durasi proyek yang dipaksakan,
risiko keterlambatan maupun biaya yang lebih besar juga meningkat.
Pertanyaannya adalah, “Apakah perencanaannya yang buruk, atau memang ada
keperluan riil untuk mengelola proyek dengan durasi yang dipaksakan?”
c. Kompresi Jadwal Proyek
Kadang-kdanag sebelum atau ditengah-tengah proyek, muncul kebutuhan
untuk mempersingkat atau memperpendek durasi proyek. Pemendekan durasi
proyek dipenuhi dengan memperpendek (memampatkan) satu atau lebih aktivitas
pada jalur krisis. Pemendekan durasi sebuah aktivitas atau paket kerja
meningkatkan biaya langsung. Memampatkan jalur kritis juga akan mengurangi
total slack pada jalur lain, dan lebih banyak jalur menjadi kritis atau mendekati
kritis. Semakin kritis aktivitas atau hampir kritis, semakin tinggi risiko
keterlambatan penyelesaian proyek. Beberapa rencana kontingensi dapat
menghindari prosedur-prosedur yang memakan biaya besar. Sebagai contoh,
jadwal dapat diubah untuk mengerjakan beberapa aktivitas secara paralel atau
menggunakan hubungan lag start-to-start. Penggunaan orang terbaik untuk tugas-
tugas berisiko tinggi dapat menghapus atau memperkecil terjadinya peluang
risiko.
3. Risiko Biaya
Risiko biaya merupakan hal signifikan dan memberikan konsekuensi. Sebagian
besar risiko biaya terjadi karena kesalahan dan pengabaian estimasi jadwal dan teknis.
Beberapa keputusan manajemen secara aktual juga meningkatkan risiko biaya.
Beberapa risiko biaya yang ditemukan dalam praktik dibahas di bagian ini.
a. Hubungan Ketergantungan Waktu/Biaya
Ada hubungan ketergantungan antara waktu dan biaya dan masalah serta biaya
teknis. Sebagai contoh, jika aktivitas “membuat prototipe proses” memerlukan
waktu 50 persen lebih banyak dibanding estimasi asli, maka biaya juga akan naik.
Jadi, waktu dan biaya tidak terjaid secara terpisah (independen). Kesalahan risiko
biaya yang cukup signifikan akan terjadi ketergantungan tersebut diabaikan.
b. Keputusan Arus Kas
Keputusan arus kas yang dilakukan secara tergesa-gesa dapat mempertinggi
risiko jadwal. Sebagai contoh, analisis keuangan akan membandingkan jadwal
start awal dengan jadwal start akhir. Secara teoritis, mereka menyimpulkan bahwa
dengan menunda aktivitas, nilai masa depan (future value) dari uang adalah lebih
besar dibanding nilainya saat ini (pendapatan dari bunga). Sebagai alternatif, uang
dapat digunakan di tempat lain. Meningkatnya risiko karena berkurangnya slack
kadang-kadang diabaikan atau diremehkan. Jika mungkin, hindari menggunakan
jadwal untuk memecahkan masalah arus kas. Jika jadwal digunakan, maka ia
harus dilakukan dengan memahami bahwa proyek mungkin akan selesai terlambat
dan pada biaya yang lebih tinggi.
c. Risiko Proteksi Harga
Proyek dengan durasi panjang memerlukan beberapa kontingensi untuk
perubahan harga – pada umumnya naik. Hal penting untuk ingat ketika meninjau
ulang harga adalah menghindari perangkap menggunkan harga borongan untuk
menutup risiko harga. Sebagai contoh, jika inflasi berjalan sekitar 3 persen,
beberapa manajer menambahkan 3 persen untuk semua sumber daya yang
digunakan dalam proyek. Pendekatan harga seperti ini tidak menunjuk dengan
tepat di mana sebenarnya proteksi harga diperlukan. Ia juga tidak memungkinkan
peacakan dan pengendalian. Risiko harga harus dievaluasi per item. Beberapa
kontrak dan pembelian tidak akan berubah dan sepanjang umur hidup proyek.
Hal-hal yang mungkin berubah harus diidentifikasi; perubahan besar juga harus
diestimasi. Pendekatan ini memastikan pengendalian dana kontingensi ketika
proyek diimplementasikan.
4. Risiko Pembiayaan
Bagaiamana jika pembiayaan untuk proyek dipotong 25 persen atau proyeksi
penyelesaisan menunjukan bahwa biaya akan lebih besar dari dana yang tersedia?
Apakah proyek punya peluang untuk dibatalkan sebelum selesai? Manajer proyek
yang baik menyadari bahwa penilaian risiko yang lengkap harus memasukan evaluasi
persediaan pembiayaan. Ini terutama benar untuk proyek yang dibiayai oleh
pemerintah. Contoh kasus adalah helikopter Comanche RAH-66 yang sedang
dikembangkan untuk Angkatan Perang AS oleh Sikorsky Aircraft Corp, dan Boeing
Co. Delapan miliar dolar telah diinvestasikan untuk mengembangkan sebuah
helikopter pengintai dan pesawat-tempur baru, ketika pada Februari 2004 Departemen
Pertahanan AS merekomendasikan agar proyek dibatalkan. Pembatalan
mencerminkan perlunya memotong biaya dan kembali menggunakan pesawat terbang
tanpa awak untuk pengawasan dan misi serang.
Sama seperti proyek pemerintah mengalami perubahan strategi dan agenda politis,
perusahaan bisnis sering mengalami perubahan prioritas dan manajemen puncak.
Proyek kesayangan (pet project) dari sang CEO baru menggantikan proyek
kesayangan CEO sebelumnya. Sumber daya dipusatkan untuk membiayai proyek
baru, dan proyek lain pun dibatalkan.
Pemotongan anggaran atau tidak adanya pembiayaan yang cukup dapat
menghancurkan sebuah proyek. Pada umumnya, ketika hal seperti itu terjadi, ada
suatu kebutuhan untuk kembali manakala cakupan proyek agar proyek mungkin untuk
dilakukan. “Semuanya atau tidak ada proyek sama sekali” adalah target dari mereka
yang memotong anggaran. Inilah kasus helikopter Comanche ketika ada keputusan
untuk beralih dari pesawat terbang pengintai dnegan awak menjadi pesawat tanpa
awak. Di sini, proyek dengan “kemampuan untuk dipotong” (clrunkability) bisa
merupakan suatu keunggulan. Sebagai contoh, proyek jalan bebas hambatan dapat
tidak memenuhi tujuan semula, namun masih menambahkan nilai untuk setiap mil
yang telah diselesaikan.
Pada skala yang jauh lebih kecil, risiko pembiayaam dapat saja ditemukan pada
proyek yang lebih komersial. Sebagai contoh, seorang kontraktor bangunan
menemukan bahwa berkaitan dengan kecenderungan anjloknya pasar saham secara
mendadak, pemilik tidak mampu lagi membangun rumah impian mereka. Atau
sebuah perusahaan konsultan SI mungkin berakhir dengan tangan kosong ketika
sebuah klien bangkrut. Pada kasus kontraktor bangunan, kontraktor dapat memiliki
sebuah kontingensi untuk menjual rumah di pasar terbuka, sementara perusahaan
konsultan SI harus bergabung dengan deretan panjang para kreditor.

F. Dana Kontingensi dan Penyangga Waktu

Dana kontingensi dibuat untuk mengkaver resiko proyek, yang telah diidentifikasi
maupun yang belom diketahui. Pemilik proyek sering enggan menyediakan dana
kontingensi proyek karena dana tersebut dapat menyiratkan bahwa rencana proyek
buruk. Beberapa dari mereka merasa dana kontingensi sebagai dana tambahan. Pada
umumnya keengganan menetapkan cadangan kontingensi dapat diatasi dengan
identifikasi resiko yang telah didokumentasikan, penilaian, rencana kontingensi dan
merencanakan kapan dan bagaimana dana akan dikeluarkan.

Ukuran dan jumlah cadangan kontingensi tergantung pada ketidakpastian yang

tidak bisa dipisahkan dalam proyek. Ketidakpastian dicerminkan dalam “kebaruan”
proyek, estimasi biaya dan waktu yang tidak akurat, cakupan yang tidak stabil,
masalah teknis yang tidak diketahui, dan masalah-masalah yang tidak diantisipasi.

Dalam praktik, dana cadangan kontingensi umumnya dibagi menjadi dana cadangan
anggaran dan dana cadangan manajemen untuk tujuan pengendalian. Cadangan
anggaran ditetapkan untuk menutup resiko yang telah diidentifikasikan. Cadangan
tersebut adalah cadangan yang dialokasikan untuk segmen-segmen spesifik atau
deliverabel proyek. Cadangan manajemen ditetapkan untuk menutup resiko-resiko
yang tidak dikenal dan dialokasikan untuk resiko yang berhubungan dengan total
proyek. Resiko dipisahkan karena penggunaannya memerlukan persetujuan dari
berbagai tingkat otoritas yang berbeda. Karena semua resiko probabilistik, maka
cadangan tidak dimasukkan dalam baseline untuk masing-masing aktivitas atau paket
kerja, mereka diaktifkan hanya ketika sebuah resiko terjadi. Jika sebuah resiko yang
telah dikenali tidak terjadi dan keempatan terjadinya adalah masa lampau, maka dana
yang telah dialokasikan pada resiko tersebut harus di kurangkan dari cadangan
anggaran
1. Cadangan Anggaran
Cadangan ini diidentifikasikan untuk paket kerja yang spesifik atau untuk
segmen-segmen sebuah proyek yang ditemukan dalam anggaran baseline atau
WBS. Cadangan anggaran adalah untuk risiko-risiko yang telah di kenali yang
mempunyai kesempatan kecil untuk terjadi.

2. Cadangan Manajemen

Dana cadangan ini diperlukan untuk menutup risiko utama yang tak terduga
dan karena itu, berlaku untuk total proyek. Sebagai contoh, perubahan besar pada
cakupan tampaknya perlu dilakukan di tengah-tengah proyek. Karena perubahan
ini tidak diantisipasi atau diidentifikasi, maka ia di tutup dari cadangan
manajemen. Cadangan manajemen dibuat setelah cadangan anggaran
diidentifikasi dan dana ditetapkan. Cadangan manajemen tidak terikat pada
cadangan anggaran dan dikendalikan oleh manajer proyek dan pemilik proyek.
Kebanyakan cadangan manajemen ditetapkan menggunakan data historis dan
pertimbangan mengenai keunikan dan kompleksitas proyek.

Penempatan kontingensi teknis dalam cadangan manajemen adalah sebuah

kasus khusus. Identifikasi resiko teknis (fungsional) yang mungkin sering
dihubungkan dengan sebuah produk atau proses baru, belom dicoba dan inovatif.
Karena ada kesempatan dimana inovasi tidak bisa bekerja, maka rencana fallback
diperlukan. Resiko jenis ini diluar kendali manajer proyek. Karenanya, cadangan
teknis dimasukkan dalam cadangan manajemen dan dikendalikan oleh
manajemen puncak atau pemilik. Pemilik dan manajer proyek diasumsi bahwa
kemungkinan besar dana ini tidak akan pernah digunakan.

Gambar 5. menunjukkan pengembangan estimasi dana kontingensi untuk

sebuah proyek hipotesis. Perhatikan bagaimana cadangan manajemen dan
anggaran dipisahkan. Pengendalian akan mudah ditelusuri dengan menggunakan
format seperti ini.
 Gambar 5. Estimasi Dana Kontingensi

3. Penyangga Waktu (Time Buffer)

Sama seperti dana kontingensi dibuat untuk menyerap biaya-biaya yang tidak
direncanakan, para manajer menggunakan penyangga waktu untuk mengatasi
keterlambatan potensial dalam proyek. Dan seperti dana kontingensi, jumlah
waktu adalah bergantung pada ketidakpastian yang melekat pada proyek. Semakin
tidak pasti sebuah proyek, semakin banyak waktu yang harus dicadangkan untuk
jadwal. Strateginya, adalah menetapkan waktu ekstra pada momen-momen kritis
dalam proyek. Sebagai contoh, penyangga ditambahkan pada:

a. Aktivitas dengan resiko menjengkelkan.

b. Aktivitas gabungan yang cenderung akan terlambat karena satu atau lebih
aktivitas sebelumnya akan terlambat.
c. Aktivitas non kritis untuk mengurangi kemungkinan bahwa mereka akan
menciptakan jalur kritis lain.
d. Aktivitas yang memerlukan sumber daya langka untuk memastikan bahwa
sumber daya tersedia ketika diperlukan.

Ketika menghadapi ketidakpastian jadwal secara menyeluruh, penyangga

kadang-kadang ditambahkan pada akhr proyek. Sebagai contoh sebuah proyek
dengan hari kerja 300 dapat memiliki penyangga proyek 30 hari. Sekalipun
ekstra 30 hari tidak akan nampak pada jadwal, namun waktu ekstra tersebut
 tersedia jika diperlukan. Seperti cadangan manajemen, penyangga umumnya
memerlukan otorisasi manajemen puncak.

G. Langkah 4: Pengendalian Respons Risiko

Langkah terakhir proses manajemen risiko adalah pengendalian risiko –

mengeksekusi strategi respons risiko, memonitor peristiwa pencetus, memulai
rencana kontingensi, dan mengawasi resiko baru. Membangun sistem manajemen
perubahan untuk menghadapi peristiwa-peristiwa yang memerlukan perubahan resmi
dalam cakupan, anggaran, dan atau jadwal proyek adalah unsur penting dari
pengendalian risiko.

Manajer proyek harus memonitor risiko dan melacak kemajuan proyek. Penilaia
dan pembaruan (updating) risiko perlu menjadi bagian dari setiap sistem pelaporan
pemenuhan atau penyelesaian dan kemajuan proyek. Tim proyek harus tetap waspada
atas risiko baru yang tak terduga. Manajemen perlu peka karena orang lain mungkin
tidak mengetahui masalah risiko baru. Mengakui bahwa bisa jadi ada bug dalam kode
desain atau komponen yang berbeda tidak kompatibel, mencerminkan kurang baiknya
kinerja individu. Jika organisasi memberikan sanksi atau hukuman keras terhadap
kesalahan individu, adalah wajar jika orang-orang di dalam organisasi berusaha
melindungi diri mereka. Demikian pula, jika kabar buruk disambut dengan kasar dan
ada kecenderungan untuk “membunuh pembawa berita” peserta kemudian akan segan
untuk berbicara dengan bebas. Kecenderungan untuk menekan atau mengubur dalam-
dalam kabar buruk kian menumpuk jika tanggung jawab individu tidak jelas dan tim
proyek berada dibawah tekanan ekstrim dari manajemen puncak agar proyek
dikerjaka dengan cepat.

Manajer proyek perlu membangun sebuah lingkungan dimana para peserta merasa
nyaman untuk mendapatkan perhatian dan mengakui kesalahan. Seharusnya norma
yang berlaku adalah bahwa kesalahan bisa diterima, dan menyembunyikan kesalahan
tidak bisa ditoleransi. Masalah tidak harus ditolak. Peserta harus didukung untuk
mengidentifikasi masalah dan risiko baru. Kuncinya adalah, manajer proyek perlu
memiliki sikap yang positif terhadap risiko.
 Pada proyek besar yang kompleks, mungkin saja bijaksana untuk kembali
megidentifikasi atau menilai risiko dengan informasi segar. Profil risiko seharusnya
dikaji ulang untuk menguji dan mengetahui apakah respons asli sudah benar.
Stakeholder yang terkait harus diajak berdikusi. Sekalipun tidak praktis jika dilakukan
secara kontinu, namun manajer proyek perlu berinteraksi secara teratur dengan
mereka atau mengikuti rapat stakeholder khusus untuk meninjau ulang status risiko
pada proyek.

Kunci kedua untuk mengendalikan biaya risiko adalah mendokumentasikan

tanggung jawab. Dalam proyek yang melibatkan banyak organisasi dan kontraktor,
masalah ini bisa problematis. Tanggung jawab untuk risiko serimg diserahkan ke
orang lain dengan manyatakan, “ini bukan urusanku”. Mentalitas seperti ini
berbahaya. Masing-masing risiko yang telah dikenali harus ditugaskan (dibagikan)
berdasarkan kesepakatan bersama dari pemilik, manajer proyek, dan kontraktor atau
orang yang memiliki tanggung jawab atas segmen atau paket kerja dari proyek.
Adalah baik untuk mempunyai orang yang bertanggung jawab atas kesepakatan
tentang penggunaan dana cadangan anggaran dan memonitor tingkat pemakaiannya.
Jika dana cadangan manajemen diperlukan, perlu ada orang yang memainkan peran
aktif dalam estimasi dana dan biaya tambahan yang diperlukan untuk menyelesaikan
proyek. Memiliki personal yang mengambil bagian dalam proses akan membantu
memuaskan perhatian pada cadangan manajemen, pengendalian tingkat
pemakaiannya, dan secara dini memperingatkan peristiwa risiko potensial. Jika
manajemen risiko tidak disusun, tanggung jawab dan respons terhadap risiko akan
diabaikan – ini bukan bidang saya.

Intinya adalah, manajer proyek dan anggota tim itu perlu waspada ketika
memonitor risiko potensial. Mereka perlu mengidentifikasi ranjau baru yang mampu
menggelincirkan sebuah proyek. Penilaian risiko harus menjadi bagian dari agenda
pertemuan yang membahas status proyek, dan ketika muncul resiko baru, penilaian
tersebut perlu dianalisis dan digabungkan dengan proses manajemen risiko.

H. Manajemen Pengendalian Perubahan

Unsur utama dari proses pengendalian risiko adalah manajemen perubahan. Setiap
detail dari sebuah rencana proyek tidak akan menjadi nyata seperti yang diperkirakan,
 Mengatasi dan mengendalikan perubahan proyek merupakan sebuah tantangan besar
bagi kebanyakan manajer proyek. Perubahan datang dari banyak sumber seperti
pelanggan proyek, pemilik, manajer proyek, anggota tim, dan terjadinya peristiwa
risiko. Kebanyakan perubahan masuk dalam tiga kategori berikut:

1. Perubahan cakupan dalam bentuk desain atau penambahan menghadirkan

perubahan besar.
2. Implementasi rencana kontingensi, ketika peristiwa resiko terjadi dapat
menghadirkan perubahan dalam biaya dan jadwal baseline.
3. Perubahan peningkatan yang diusulkan oleh anggota tim proyek
menghadirkan kategori lain.

Sistem pengendalian perubahan melibatkan pelaporan, pengendalian, dan

perekaman perubahan pada baseline proyek. Sistem pengendalian proyek dirancang
untuk memenuhi hal berikut:

1. Mengidentifikasi perubahan yang diusulkan.

2. Mendaftarkan efek yang diharapkan dari perubahan jadwal dan anggaran yang
diusulkan.
3. Meninjau ulang, mengevaluasi, dan menyetujui atau tidak menyetujui.
perubahan secara resmi.
4. Merundingkan dan memecahkan konflik perubahan, kondisi, dan biaya.
5. Mengomunikasikan perubahan ke pihak yang terpengaruh.
6. Menetapkan tanggung jawab untuk mengimplementasikan perubahan.
7. Melakukan penyesuaian jadwal master dan anggaran.
8. Melacak semua perubahan yang diimplementasikan.

Sebagai bagian dari rencana komunikasi proyek, stakeholder sejak awal

menetapkan proses komunikasi dan pengambilan keputusan yang akan digunakan untuk
mengevaluasi dan menerima perubahan. Hal yang penting adalah menilai dampak
perubahan pada proyek. Implikasi perubahan perlu dinilai oleh orang yang perspektif dan
keahlian yang sesuai. Pada proyek konstruksi, hal tersebut sering menjadi tanggung jawab
perusahaan arsitektur, sementara pada usaha pengembangan perangkat lunak, fungsi
tersebut dilakukan oleh “arsitek perangkat lunak”.
 Setiap perubahan yang disetujui harus diidentifikasi dan disatukan ke dalam
rencana pencatatan melalui perubahan dalam WBS proyek dan jadwal baseline. Rencana
record atau catatan bertindak sebagai patok duga (benchmark) manajemen perubahan
untuk masa permintaan perubahan di masa mendatang, juga sebagai baseline untuk
mengevaulasi kemajuan proyek. Manfaat yang diambil dari sistem pengendalian
perubahan:

1. Perubahan tidak penting atau tidak logis dikurangi melalui proses formal.
2. Biaya perubahan disimpan pada sebuah log.
3. Integritas WBS dan ukuran kinerja dipertahankan.
4. Alokasi dan penggunaan dana cadangan manajemen dan anggaran dilacak.
5. Tanggung jawab implementasi diperjelas.
6. Efek perubahan diketahui oleh semua bagian yang terlibat.
7. Implementasi perubahan dimonitor.
8. Perubahan cakupan akan dengan cepat dicerminkan dalam ukuran baseline
dan kinerja.

Jelas bahwa pengendalian perubahan adalah penting dan perlu ada seseorang atau
beberapa kelompok yang bertanggung jawab untuk menyetujui perubahan, menjaga agar
proses terus diperbarui dan mengomunikasikan perubahan kepada tim proyek dan
stakeholder terkait. Pengendalian proyek sangat tergantung pada kebaruan proses
pengendalian perubahan. Catatan historis ini dapat digunakan untuk memuaskan
pemeriksaan pelanggan, mengidentifikasi masalah dalam audit paska proyek, dan
mengestimasi biaya proyek dimasa mendatang.
 BAB III

PENUTUP

A. Kesimpulan
 DAFTAR PUSTAKA

Gray, Clifford F., dan Erik W. Larson. 2006. Manajemen Proyek: Proses
Manajerial Edisi 3. Yogyakarta: Andi.