Some readers might have noticed that projects do not always go exactly as planned. Actually they never go exactly as planned. What's more, they have a tendency to go worse than planned more often than they go better than planned.
Why is this?
Project plans are just forecasts, so the reason projects don't go exactly to plan is the same as the reason weather forecasts are not always correct. It is because our knowledge of the future is uncertain. Yet mainstream project management systems expect project managers to give single-point estimates of how much each task will cost and how long it will take. From this they produce single-point estimates of what the project will cost and when it will be finished. The only thing certain about these estimates is that they will be proved wrong.
Pembahasan - Sapto Hari Wibowo
Dear Friends,
Please find below an introductory article provided to us that offers a useful insight into cost and schedule risk analysis.
Watch this space, as more on this interesting subject will be provided in the coming weeks / months...
PROJECT COST AND SCHEDULE RISK ANALYSIS...
Article provided by Mr. Risk, one of our growing team of Experts
Some readers might have noticed that projects do not always go exactly as
planned. Actually they never go exactly as planned. What's more, they have a tendency to go worse than planned more often than they go better than planned.
Why is this?
Project plans are just forecasts, so the reason projects don't go exactly to plan is the same as the reason weather forecasts are not always correct. It is because our knowledge of the future is uncertain. Yet mainstream project management systems expect project managers to give single-point estimates of how much each task will cost and how long it will take. From this they produce single-point estimates of what the project will cost and when it will be finished. The only thing certain about these estimates is that they will be proved wrong.
The first attempt to address this issue came with the introduction of PERT in the late 1950's. Unfortunately, PERT works only when there is only one path through the project network with any chance of being critical. Even more unfortunately, it is not easy to determine whether this is the case without using more sophisticated methods such as Monte Carlo simulation.
So, what is Monte Carlo simulation? Like PERT, Monte Carlo starts with the user specifying a range of values for the duration and cost of each task, typically in the form of a probability distribution based on a 3-point estimate. (I will come back later to the perceived difficulty of making these estimates.) Monte Carlo simulation samples from these distributions – that is to say it generates a value for each duration or cost in a way that is random but which relative probabilities implied by the specified distribution – and then does a CPM calculation (i.e. a forward and backward pass) using these durations. It then stores the CPM results – dates, floats, and costs – in a summary form such as a histogram. It repeats the whole process thousands of times, each time with a different set of random samples, and so builds up a picture of the whole range of possible outcomes and their relative probabilities.
This enables one to answer questions such as "what is the chance that the project will be finished by December 15th?" or "what is the chance that the project will not cost more than $15 million?" These are intrinsically more sensible and more useful questions than "when will the project finish?" or "how much will the project cost?" because we know that the answers to these will not be precise, and yet they do not tell us how imprecise they might be. At best we might expect to have a 50% chance of meeting the projected date and cost, and a 50% chance is hardly good enough odds for the completion of an important project. What's more, due to a phenomenon called merge bias which I might go into in a future post, the chance of meeting a single-point estimate of project completion is often much less than 50%.
Each set of duration samples and the resulting CPM calculation is called a
trial. It is important to do a large number of trials to get reliable results.
I recommend at least 10,000. This may sound like it would be time consuming, but it does not need to be. Software products vary widely – by a factor of at least 100 -- in the speed with which they do these calculations, so a simulation that would take 10 minutes on one product may require an overnight run on another.
A common objection to doing risk analysis is that project managers (or their subject matter experts) say they cannot provide the three-point estimates required. But if they cannot provide a three-point estimate how can they possibly provide a single-point estimate? Surely it is easier to estimate a range of values than to provide a single figure? (If one were asked to estimate someone's weight, would one not be more confident in saying "170 to 200 pounds" rather than "185 pounds?")
The more stubborn may further argue that they do not know enough about the task to give optimistic and pessimistic estimates of its duration, but that demonstrates a fundamental misunderstanding of what uncertainty is. Uncertainty is not a property of the task -- which will actually take a definite length of time to complete – but a property of our own current knowledge. So, the fact we do not know enough about the task is exactly what we are trying to model with the probability distribution. The less we know about a task the less valid would be our single-poit estimate and the more important it is to give a range. (The meaning of uncertainty is quite a philosophical subject, justifying a post of its own some time.)
There remains the question of how one chooses a distribution shape, to which I would answer that it does not matter much. Recognizing that there is a distribution is the main thing. (It does matter to some degree because some distributions have much thinner tails than others, but this can be largely overcome by giving the user the opportunity to frame his optimistic and pessimistic values in terms of percentiles rather than absolute limits.) As Sam Savage says (in his excellent book, "the Flaw of Averages"), in the land of the average the man with the wrong distribution is King.
There is a lot more to Monte Carlo than explained above, but this is enough to get you started. And if you do just this you will be on the path to more realistic project plans. There is just one more point I would like to make, however. I have mentioned cost and schedule several times, and ideally one would do these together in a single simulation because uncertainty about cost and schedule are related. Some systems separate them, bringing them together only at the end of the process. This loses valuable information about how they are correlated. I hope to talk about this further in future posts, as well as about sensitivity analysis, correlations, and risk drivers.
We hope you found this to be of value.
Look out for future articles provided by Mr. Risk; Tony Welsh
Tanggapan 1 - Sketska N.
Terimakasih pak Sapto,
Btw adakah contoh yang aplikatif terutama penerapan pada project2 upstream Migas? Mohon berguru dari yg senior.
Tanggapan 2 - Sapto Hari Wibowo
Pak Sketsa,
Kalau senioritas kayaknya tidak Pak, kita sama2 saling belajar.
Penerapan aplikatif ya itu memang salah satu bidang kerja project control.
Sebagai contoh secara simpelnya seperti berikut :-
Project "A" dengan durasi 50 bulan, completion date katakanlah 15 Desember 2017
(deterministic Schedule) dengan total estimate cost US$ 20 Billion.
Kalau kita olah schedule dan Cost ke dalam Risk analysis, bisa jadi Schedule tersebut akan menjadi P10 - 49 bulan dengan cost US$ 19.5 Billion, P-50nya 55 bulan dengan cost US$ 21 Billion dan P-90 selama 60 bulan dgn cost US$ 22 Billion.
Itu sebagai contoh saja.
Valid tidaknya risk analysis tergantung dari semua input & knowledge/ experience oleh Team Leader, Semua Manager & Project Managernya.
Untuk suksesnya Project on schedule, semua harus memperhatikan risk2 yang bisa mengakibatkan schedule delay dan Cost naik.
Catatan : dalam risk analysis, schedule jangan lebih dari 250 activities, semua logic harus betul, tanpa lag dan tanpa contraint activities.
Mohon dikoreksi kalau salah penulisan.
Tanggapan 3 - Sketska N. sketska
Trims pak Sapto, berarti setting Pesimistic schedule utk mengawali nya. Lalu metoda apa yang biasa di gunakan untuk menganalisa? Maksud sy dalam tataran praktis untuk skala project besar. Sy pernah ikutan mentoring perihal ini sampe akhirnya jadi "Copy Darat", akan tetapi aplikasi nya lebih kepada CIvil Construction.
Sy butuh input/ masukkan terutama utk upstream project, yaa minimal sekelas kalo kita mau running plan of dev (POD). Punya standart / metoda praktis nya?
Sesekali sy pake Risk Analysis, minimal utk menganalisa sched rekan2 Contractor krn cepat dengan hasil yg cukup detail (Terlihat dimana constraint, apakah ada open end, dll). Butuh mentor lagi utk memaksimalkan penggunaan nya dari para sesepuh :)
Tanggapan 4 - Burhanudin hans_oke
Mas Sapto,
Klo boleh tahu di Shell, QRA (SRA & CRA) nya memakai method apa ya ? dan saya ingin tahu kenapa harus ada limit 250 activities schedulenya., mohon
pencerahannya.
Thanks
Tanggapan 5 - Sapto Hari Wibowo
@Mas Sketsa,
Kalau hanya untuk menganalisa schedule tentang constraint, open end, relationship etc kenapa harus pake Risk Analysis??
Kenapa tidak pakai Acumen Fuse saja, dalam hitungan kurang dari 2 menit Acumen Fuse akan mendapatkan hasil yang sangat fantastis komplit dengan semua informasi dan grafiknya sekalian.
Bisa langsung diupload/ export kedalam bentuk excel format.
Mungkin Acumen Fuse masih baru di dunia Project Control, belum banyak perusahaan yang punya software ini, sayapun baru ikut course-nya 7 bulan yang lalu (Gratisan)
@Mas Burhan,
Saya di Shell menggunakan Primavera Risk Analysis saja, Kalau Mas Burhan di Petronas gimana?
Methodology nya secara qualitative dan quantitative.
Alasan saya membatasi 250 activities karena masalah waktu yang akan tersita sewaktu risk workshop.
Mungkin di setiap perusahaan akan lain tergantung dari audience (sekitar 7 – 12 orang) di dalam risk workshop.
Pengalaman 3 Project terakhir di Shell, melakukan risk workshop di Japan & Australia dengan hanya 250 activities memakan waktu 1 minggu penuh karena setiap orang bebas mengemukakan pendapatnya untuk menentukan duration (Minimum, Most Likely & Maximum Duration) juga Assumption, discrete risknya dll.
Belum tentu pendapat dari seorang Project Manager akan diterima oleh semua Audience untuk kesepakatan bersama.
Two Step Process during Workshops (SRA) :
- Agree Uncertainty Ranges & identify Correlations for line items / activities
- Risk Mapping
Two Step Process during Workshops(CRA) :
- Agree Uncertainty Ranges & identify Correlations for cost line items
- Risk Mapping to ensure that risks & opportunities identified in the register
are reflected in the analysis + identification of new risks & opportunities that
can affect cost or schedule
Kalau Mas Burhan/ Mas Sketsa dan teman2 lain punya pandangan lain mohon
dikoreksi karena sayapun masih belajar.
Tanggapan 6 - Sketska N.
Trims pak Sapto,
Ya memang sayang karena software ini di atas usd 5000,- harga nya dan memang analisa schedule hanyalah "pembuka" jika kt menggunakan Primavera Risk Analysis (Cucu dari Pertmaster).
Thx for info, akan tetapi problem nya diminta dalam 1 platform yang utuh walaupun begitu si empunya (Oracle) masih terus mengembangkan EPPM (Enterprise project planning management). Btw, biar sama2 belajar nya makin mantap berkenan kah kita buat workshop SRA Risk Analysis kecil2an dgn mengangkat studi case project Migas?
Tanggapan 7 - Sapto Hari Wibowo
Bagaimana implementasinya Mas Sketsa? Lha saya sekarang di Malaysia?
Sedang Risk Workshop harus dilakukan secara face to face yang paling tidak harus ada Minimum 7 - 12 orang?
Kalau sekedar digaris bawahi "BUAT LATIHAN" atau pingin tahu secara kasar
hasilnya coba saja Mas Sketsa buat Summary schedule level 1.5 atau 2 terus
masukkan semua duration minimum & maksimumnya, untuk Most likely duration ambil saja dari original duration yang sudah ada di Schedule, juga masukkan Duration Correlationnya.
Masukkan semua info tentang risk register (ya dikira2 saja) secara qualitative dan quantitative premitigate & post mitigate, calendarnya termasuk Weather Model Calendar dsb mapping risk model . Terus run saja maka anda akan tahu berapa P10, P50 dan P90 nya secara kasar.
Itu saja sebagai contoh latihan secara kasar/ mudah tanpa mengambil input dari orang lain (Project team)
Schedule yang kita pakai (deterministic Schedule) yang biasa seorang Planner buat, seharusnya diantara P10 - P90. Kalau deterministic Schedule dibawah P0, bisa dipertanyakan kenapa masih harus dipakai dan kenapa tidak direvise kalau sudah jelas2 tidak akan tercapai targetnya???
Tanggapan 8 - Sketska N.
Pak Sapto ysh, maksudnya jika ada waktu bapak ke Jakarta / kami silaturahim ketempat bapak disana? Namanya juga belajar, anytime - anywhere kita usahakan dgn maksimal :)
Terimakasih banyak p Sapto, ok akan coba saya running dulu dengan sample beberapa project yang ada. Semoga tidak bosan2 berbagi ilmu aplikatif semacam ini.
Comments
Post a Comment