Oracle | Primavera Risk: Pertmaster Test Monte Carlo Iterations

The third step of a typical Oracle | Primavera Risk (Pertmaster) Monte Carlo analysis is to validate the integrity of the schedule logic.  Running test simulations will speed up the process of schedule audit and cleanup.  Project managers must validate that the logic is realistic before running the delivering the final reports.

Video Walkthrough of Running Test Monte Carlo Simulations in Oracle | Primavera Risk (Pertmaster) (Duration: 11 min: 31 sec)

The Value and Strategies Associated with Running Test Simulations

Test simulations allow a project manager or risk analyst to test the network logic without the detailed knowledge a scheduler might have.  It also allows planners and schedulers to see what the logic does during a simulation without having to visually trace the logic.  Risk analysts will put random levels of uncertainty or three-point-estimates on the schedule in order to test how the network of activities move and the driving activities in the schedule.  It is a very simple process and project manager’s without a scheduling background can usually interpret the histogram and tornado chart data more easily than massive chains of predecessors and successors.  Experienced schedulers can get great value as thousands of activities are filtered down to much more manageable amounts to trace the root cause of the schedule issue.

Test Simulation Steps

  • Add uncertainty to the schedule via the duration quick risk (menu path: Risk | Duration Quick Risk).  Risk analysts may want to use optimistic and pessimistic values to see how the logic network reacts to different levels of risk.
  • Run the risk analysis (menu path: Risk | Run Risk Analysis…).
  • Analyze the confidence-level histogram (distribution graph) and the tornado chart (tornado graph).  The charts are both located under the report menu, however it is recommended to right-click the reporting milestones in the Gantt chart and run the chart from the pop-up menu.  This will run a report that isolates the reporting milestones instead of including activities in the schedule that may be considered noise more than main logic chains.

What to Look for in the Reports

What does the histogram highlight?

  • Gaps in the graph may show issues with constraints, non-working periods, or static paths like milestones strings are driving the schedule.
  • A large spike at the beginning of a histogram often shows an activity cannot finish earlier than a finish-on-or-after constraint.
  • The difference between the deterministic date should make sense relative to the risk inputs. If the project has two years left and the risk inputs are skewed to the maximum (95%, 100%, 120%), then it would make no sense if the answer did not push out multiple months.  Since the value is skewed 15% to the maximum, then you would expect at least a 12 to 18% push (applied to the 2 year duration) on activities.  The push could be worse based on near critical paths, etc.  This is simply a rule of thumb, but the answers should be somewhere close or there is an indicator that the network has breaks in logic or other issues. 
  • The percent chance of completion should give a hint about how the network is working.
    • If the risk analyst put optimism on the schedule, then the percent chance should be fairly high.
    • If the user put a symetrical level of risk (plus and minus the same value) on the schedule, then an optimistic reading would highlight bad logic or very few parallel and near critical paths.  A more moderate reading would seem to dictate that the critical path is fairly linear and does not move much.  A pessimistic answer would indicate that the confidence level is reducing due to the amount of critical path movement.  As the amount of near critical paths increase, the confidence level should decrease.
    • If the risk analyst uses a pessimistic distribution, then the answer should be very negative.  A reasonable confidence level would dictate that the network has very few driving activities or the logic is broken in general.

What does the tornado chart highlight?

  • The tornado chart will list the activities that are driving the milestone or activity.
  • If a project manager knows that engineering should be a driver but it does not show up on the tornado chart, then the schedule is probably missing a link from the engineering chain of activities.
  • If a risk analyst sees a non-driving activity on the chart, then there is probably a link that should be removed in the base schedule.
  • A general rule is that the tornado chart should list mostly activities that people expect or the schedule does not reflect the project management team’s expectations.  In this case either the schedule is linked incorrectly or the project team does not understand how the job is being worked.
  • When the tornado chart does not make sense, the base schedule should be revised.  This process should be repeated until the logic reacts in a realistic fashion.  There is no value running a risk analysis unless the team believes the sequencing reflects reality.