Project Management

Risk & Reward

I'm a risk enthusiast who likes to discuss techniques, tools and models—and use risk as a practical means to make better decisions in project environments. Join me on the ride!

About this Blog


Recent Posts

The Risk of Changing in Risk Management

(mis)Understanding Contingency

Monty Hall for Projects: To Switch or Not to Switch?

10 Wishes for your Project Risk Management adventures in 2019!

The Curse of the Moving Mountain

(mis)Understanding Contingency

Early this month I posted a poll here asking how you determine contingency and how much is generally considered.

In my venues, I usually map the risks and uncertainties as good as possible and run a simulation to understand variation regarding my goal, being it cost or schedule. I then determine a level of contingency for the project and add extra days or dollars to arrive at the percentile level.

Reading some references on risk analysis, people usually choose some references for safety. David Hulett, in his "Schedule Risk Analysis" (Gower, 2004) generally highlights P80. So I started wondering: how safe should your schedule be? How safe should your budget be?

My answer for that is that it depends. Depends on whether this project is another one in a set of 40 or 50, or if it is the only project of your firm, or the first project you are undertaking.

If you have a single project, you may be quite worried and stablish a high level of contingency, not to be caught off guard. I did some numerical experiments assuming a project would have an estimated P50 cost of 100 thousand dollars with a standard deviation of 20 thousand dollars, normally distributed.

If you want a safety level of 50%, you would always be prepared for spending the 100 thousand dollars for each project. However, as you add more projects to your portfolio, considering the results are statistically independent.

The question is how much should you add to each project in order to secure a safety level for the whole portfolio. If you have a single project, you need to add an extra US$ 32,900 to reach a 95% safety level. That's an increase in almost 33% of your budget! In the other ned, if you have 30 projects in your portfolio, adding US$ 6,000 in each project will get you to the same level of safety. 6% extra increase for a good night's sleep! If you want to see the detail, there is a graph and a table in the end of this entry with the data.

We should consider portfolio size in our decisions regarding contingency. That is why some references tell you to aim for the P50 or the average value in the simulation. If you have plenty of projects, the overall value will converge to the average in most of the cases.

Please let me know your opinion on this one. Do you run Monte Carlo to determine contingency or safety levels? Do you impose those values directly into each project? Do you have a line in your budget for the whole portfolio?

Looking forward to hear from you!

A graphical depiction of the example.


A table with the values calculated for the example

  Level of Safey required      
# of projects 50% 60% 70% 80% 90% 95%
1 100,0 105,1 110,5 116,8 125,6 132,9
2 100,0 103,6 107,5 111,9 118,1 123,3
3 100,0 102,9 106,0 109,7 114,8 119,0
4 100,0 102,5 105,2 108,4 112,8 116,5
5 100,0 102,2 104,7 107,6 111,5 114,7
6 100,0 102,0 104,3 106,9 110,5 113,4
7 100,0 101,9 104,0 106,4 109,7 112,4
8 100,0 101,8 103,7 106,0 109,0 111,6
9 100,0 101,7 103,5 105,6 108,5 111,0
10 100,0 101,6 103,3 105,3 108,1 110,4
11 100,0 101,5 103,2 105,1 107,7 109,9
12 100,0 101,5 103,0 104,9 107,4 109,4
13 100,0 101,4 102,9 104,7 107,1 109,1
14 100,0 101,4 102,8 104,5 106,9 108,8
15 100,0 101,3 102,7 104,4 106,6 108,5
16 100,0 101,3 102,6 104,2 106,4 108,2
17 100,0 101,2 102,5 104,1 106,2 108,0
18 100,0 101,2 102,5 104,0 106,0 107,8
19 100,0 101,2 102,4 103,9 105,9 107,6
20 100,0 101,1 102,3 103,8 105,7 107,4
21 100,0 101,1 102,3 103,7 105,6 107,2
22 100,0 101,1 102,2 103,6 105,5 107,0
23 100,0 101,1 102,2 103,5 105,4 106,9
24 100,0 101,0 102,1 103,4 105,2 106,7
25 100,0 101,0 102,1 103,4 105,2 106,6
26 100,0 101,0 102,0 103,3 105,0 106,5
27 100,0 101,0 102,0 103,2 105,0 106,4
28 100,0 100,9 102,0 103,2 104,9 106,3
29 100,0 100,9 101,9 103,1 104,8 106,1
30 100,0 100,9 101,9 103,1 104,7 106,0
31 100,0 100,9 101,9 103,0 104,6 105,9
32 100,0 100,9 101,9 103,0 104,6 105,8
33 100,0 100,9 101,8 102,9 104,5 105,7
34 100,0 100,9 101,8 102,9 104,4 105,6
35 100,0 100,9 101,8 102,8 104,3 105,6
36 100,0 100,9 101,8 102,8 104,3 105,5
37 100,0 100,8 101,7 102,8 104,2 105,4
38 100,0 100,8 101,7 102,7 104,2 105,4
39 100,0 100,8 101,7 102,7 104,1 105,3
40 100,0 100,8 101,7 102,7 104,1 105,2
Posted on: February 08, 2019 11:26 AM | Permalink | Comments (9)

The Curse of the Moving Mountain

When we undertake risk analyses, we are subject to our curses and nightmares. I would like to highlight one of them: the moving steep mountain! In general, our projects (at least the ones I’ve been working on) have some characteristics:

  • They are challenging on cost and schedule (and that’s okay!)
  • They are planned backwards, starting with the end date (and that’s okay, too!)
  • They don’t fit the time available from start to finish (Not okay!)
  • In general, you only find the previous bullet out when you are already working on the project (Not okay!)
  • Considering all the previous bullets, you have an unfeasible schedule (Sorry about that!)
  • Upper management is not willing to delay or add cost (Not okay, again!)

In the light of everything I listed, what do you (usually) do? You compress the schedule! You start doing crashing and fast tracking like crazy. And if you do a schedule risk analysis, you’ll see that the probability of meeting the dates tend to be very low.

In addition, you are a victim (by your own doing!) of the merge bias! This was detailed by Mr. Hulett in his book “Practical Schedule Risks Analysis” (Gower, 2009). It happens when you have a lot of parallel paths that meet in a given task of your schedule.

Suppose you have three tasks that take 5 days each in series and you “fast track” them into three tasks (of six days each) in parallel. Suppose uncertainty is a triangular distribution with the lower point at 70% of the base value and the upper point at 150% of the same value. The most likely value is the base value. When you simulate both cases, you end up with something like this:

This simulation was done using @RISK. We can see that the probability of having a value lower than the planned one is over 25 percent for the original (series) project, whereas the “fast tracked” one (parallel) has a little over 5 percent for the same situation. The parallel paths hold a larger chance of failure, and the waterfall can accommodate a larger task with a shorter one in sequence.

When we don’t consider the risk events in the simulation and we use small ranges on the variation of tasks, we end up with a very unlikely and steep distribution. That’s when the unfeasible schedule takes its toll: when the inevitable reality happens, the risks start occurring and the milestones are missed, and our planning becomes impossible.

But never fear! The management has a solution for that as well! You shift the schedule and move the mountain a little to the right. And that small probability still remains, but it is less and less credible. Eventually the project will be completed, but what is risk management doing to bring value to the table? And the answer is… NOTHING!

It would be much better to have a wide distribution considering events and broader dispersions, which we could slice into different regions and analyze for determinant factors. See below the comparison between the “moving mountains” and the “big hill”.


Let us go for the big hill, then! Let us embed the events in our analyses. Let us shed some light and free ourselves from the curse of the moving mountain and the habits that make management look like zombies.

PS: This post was inspired, of course, by Halloween but, ironically enough, came to life a bit too late! Thank you for reading! Looking forward for your feedback!

Posted on: November 05, 2018 12:37 PM | Permalink | Comments (6)

Preparing for a Schedule Risk Analysis

Recently I posted a poll right here in (here) concerning how you prepare a schedule to undertake a schedule risks analysis.

My idea was to understand how you out there see the question of getting a schedule ready for the simulation exercise. I gave you five possible answers:

  • No preparation needed, I just use my regular schedule as is (20 votes)
  • I try to reduce the number of tasks (9 votes)
  • I check the logic links and make sure all tasks are connected (61 votes)
  • I reduce tasks AND check the links (24 votes)
  • I refer to classic audit schemes, like the 14-point assessment (25 votes)

 My answer was number four, “I reduce tasks AND check the links. 17% of the respondents (139 in total) were with me on this. Now let me explain why.

In my case, I usually start with the schedule we use to monitor the progress. It tends to be quite detailed, and have a lot of information that we use to control progress, like issuing reports, preparing for meetings, doing governance, etc. All this tasks go away. Some procurement packages, for instance, have fourty steps and others have ten. I try to harmonize this, so the tasks have some similarity. This reduces a lot of work.

And of course I check the links between tasks, which is a simulation killer, one of the favorite GIGO drivers and a strong sponsor to terrible decision making. With this done, I move on to doing stress analysis and other tests to see which tasks are worthy to model with a distribution. Going further forward, I start consulting experts and doing data crunching to know how exactly I am going to model that. At last, but not surely least, I add events and their mitigation. You can check my series of articles on Qualitative and Quantitative Risk Analyses Integration, starting with this one.

Moving back to our poll, I always thought my answer would win by a landslide, but I understand all the other answers and I will develop a rationale for them, if you allow me:

  • No preparation needed, I just use my regular schedule as is (20 votes, or 14%) – Maybe you have a schedule which is already lean and you the tasks are really balanced. And it is already completely linked. I get that.
  • I try to reduce the number of tasks (9 votes, or 6%) – Reducing the number of tasks is coherent with some best practices in Schedule Risk Analysis. Hulett (2006) is one of the many who advise having a smaller schedule.
  • I check the logic links and make sure all tasks are connected (61 votes, or 44%) – This goes without saying. No logic links means you do not have a schedule. You are not ready to open the door. Go back and get that key!
  • I reduce tasks AND check the links (24 votes, or 17%) – My option, I already said something about it.
  • I refer to classic audit schemes, like the 14-point assessment (25 votes, or 18%) – it is quite interesting to use some methods like the 14-point assessment, which relies on things like logic links, very long or very small tasks, a balance between types of tasks on the schedule and some others. The reason I did not check this one is that I never found one of those schemes who served me completely, without the need for correction. But I completely understand who opted for this, especially if they are under a PMO environment, and things must adhere to a standardized process.

Anyway, thank you for responding to my poll, thank you for reading, and please post comments whether you agree or not with what I said. See you all next time!

Posted on: September 18, 2018 03:19 PM | Permalink | Comments (8)

The GIGO factor

Hello again! Today I am covering what I think is a top five threat in a Schedule Risk Analysis or any simulation / numerical exercise: the destructive power of GIGO. It can send the whole team in a wild goose chase, or calm things down when your foot is halfway into the abyss.

 For those of you who do not know or cannot remember, GIGO stands for Garbage-In-Garbage-Out. Computer models, especially those who rely heavily on assumptions and constraints to run, such as our simulation models, are prone to suffer from that factor. The term dates back to 1957, as far as we can trust Wikipedia for that, with a citation of a weapons specialist saying, “‘sloppily programmed’ inputs inevitably lead to incorrect outputs”. We can observe two main GIGO possibilities when we are simulating our schedules.

 The first one relates to the model itself. That is, if you have a schedule which is faulty, incomplete and lacking the proper detail, no good can come of doing anything but... fixing it! This may be a structural problem and require a review of the WBS and even that very dangerous but necessary question: “What is really the purpose of this Project?” There are tools for detecting a bad schedule, but no straightforward tool for detecting a bad scope. I can easily detect tasks without successors or with hard date constraints, but I cannot, without a real understanding of the Project, state that the scope is ill detailed or the breakdown does not really make sense. It can be a tricky thing.

 The second GIGO factor is the modeling of the simulation itself. Some people are mesmerized by the mere presence of a histogram or a tornado chart. They go: “Wow, so there is a 10 percent chance that we will meet the promised date. I’d better find another job”, or “No way in hell this is right, the modeling is all crooked”. This is why, in my opinion, we must not show any simulation results until the modeling is complete. Until we discussed the distributions, their upper and lower values or other ways to describe them and the risks events, we must hold our instinct to show those beautiful features of the Monte Carlo simulation. What can be worse than having a black box model that shoots numbers left and right? I will tell you: it is having a guided simulation, that is, someone saying, “The modeling doesn’t matter, but the figures for P10, P50 and P90 should be this and this and that”. This is the worst GIGO ever: a confirmation of what is expected just because it is... well, expected!

 Maybe we can model things wrongly just because we lack the training or we are just doing it wrong. That is an honest mistake. However, we must be careful using a tool that powerful, especially when we are in a company with low maturity regarding risk.

I am including a small GIGO-avoiding checklist; feel free to add more items!

  1. Check the schedule before you do anything else;
  2. Have all assumptions and constraints formalized;
  3. Have some quick documentation on the distributions you are using and why, who gave that input, etc.;
  4. Do the same for the events you are modeling;
  5. Make sure whoever models and/or runs the simulation has experience with the software and the technique;
  6. Make sure someone else does a check on the simulation, specially looking for errors and strange results;
  7. Look into the Tornado chart and make sure these correlations, regressions or whatever index you use make sense;
  8. If you are using critical index, evaluate the connection between the values and the ones you observed on step 7;
  9. Prepare a “risk story” for this project: if you were to present it to someone, how would you go about it? Does it make sense for you?
  10. Double-check and validate with external sources, if possible, to avoid the unavoidable biases.

I hope those ten steps help reduce the GIGO issue. Do you have any more tips? Let me know! Thanks for reading!

Posted on: August 22, 2018 04:11 PM | Permalink | Comments (12)

A conference is a gathering of important people who singly can do nothing, but together can decide that nothing can be done.

- Fred Allen