Basic Design
• The schedule model must represent all known scope that may influence key dates.
• The schedule model must be representative of the current execution plan.
• The schedule should be appropriately structured to meet the client’s reporting requirements for both schedule and cost outcomes from the analysis. Such requirements should be discussed early in the process to avert the requirement for re-design.
• The schedule should have clearly identified milestones for any RA reporting targets.
• The schedule model should be representative of the size and complexity of the work and especially not be overly-summarised.
• The schedule model must have key stakeholder “buy-in”. The stakeholder requesting the Schedule Risk Analysis should “own” the schedule to be used in the analysis and accept its validity.
Logic
• The schedule should be as fully linked as possible. Typically, an indication that the schedule is adequately connected is a relationship to activity ratio of around 2 to 1. Below 2 to 1 may be acceptable but requires increasing attention to validate the dependencies the lower the ratio.
• Each activity should have at least one start predecessor and at least one finish successor, and each of these should preferably be driving. Where this logic does not apply, it is possible for the lengthening of an activity to shorten the project duration (driving FF predecessor, driving SS successor)!
• The critical and near critical paths through the plan should be logical and make sense to the stakeholders.
• The schedule should make minimal use of FS +lag relationships as these typically represent undeclared tasks that should be subject to uncertainty.
• The validity of any SS or FF long lag relationships should be assessed against the level of detail in the schedule. Detailed schedules should use such relationships sparingly (prefer use of FS –lag relationships instead), whereas such relationships are a logical necessity of more summarised schedules. Planning “common sense” should be used.
Constraints
• The schedule should use logic in place of constraints where possible. For example, it is preferable to include predecessor logic than an early constraint which may prevent “schedule optimism” from being revealed. Start or Finish No Earlier Than constraints prevent tasks starting any earlier than their constrained dates.
• The schedule must not use “hard” constraints that could produce negative float in a plan or mandatory constraints that prevent successors from moving.
• Avoid Expected Finish Constraints and minimise the use of As Late As Possible (Zero Free Float) Constraints.
• An “Always Critical” constraint should be placed on an intermediate key milestone prior to its analysis so that criticality ratings of its logical predecessors are accentuated in cruciality tornado diagrams and not due to other overlapping pathways. Such constraints should subsequently be removed to analyse other key intermediate milestones and to analyse the true critical path(s) through the entire plan.
Schedule Size
There is no fixed guidance for this, but guidance based on experience suggests the following:
• Preferred limit is up to about 2,000 normal (non-zero duration) activities that are included in critical path calculations. PRA is able to analyse this size of schedule acceptably quickly (hardware speed advances tend to increase this limit).
• Although there is no fixed limit on the size of schedule to be analysed, increasingly large schedules become correspondingly slower to analyse. Furthermore, larger schedules require more complex correlation models to counter the central limit theory (which asserts that larger models with smaller average durations will produce narrower distributions of results around the mean).
• Use of small summarised schedules is to be avoided as they are likely to produce unrealistically optimistic Monte Carlo analyses, due to the elimination of logic nodes (eg, intermediate milestones) that bring together multiple strands of schedule logic. The
causes the probability of such logic nodes finishing by their planned date to be the product of the probability of each logic strand being completed by the planned date. The acts as a barrier to earlier completion of a schedule. Summarising schedules tends to reduce the number of such logic strands and nodes and therefore the real barriers to earlier completion.
• So the Schedule Risk Analysis size used to model the project should be as large as is required to represent the project scope and complexity adequately within the practical limits of analysis.
Resources
Plan resources have the potential to slow Schedule Risk Analysis analysis times significantly and should be removed if not required. There are also differences in the way that PRA and other planning applications (such as Primavera P6) calculate resource driven task durations which can cause unexpected differences in the two versions.
Use of larger numbers of resources may greatly increase analysis times as well as narrow the resultant distributions. This is a known problem in Integrated Cost & Schedule Risk Analysis (IRA - see later Knowledge Base discussion of this when added) and may also affect Schedule Risk Analysis.
Planning Units
Unless dealing with a high-level plan with long activity durations and long project duration, it’s almost always preferable to work with a planning unit of “Hours” over a planning unit of “Days”. When planning units are set to days, small percentage variations on shorter tasks are not expressed, as the task duration is always rounded to the nearest integer. A 4.5% variation of a 10 day task would still be expressed as 10 days, whereas the same task in a schedule planned in hours would be expressed as 10.45 days equivalent in hours.
Unlike Primavera P6, PRA is not capable of working in minutes, and instead has a minimum planning unit of ¼ hour blocks. This may result in some minor discrepancies in activity durations in plans exchanged between the two applications. It should be noted however that increasingly smaller planning unit durations result in increased scheduling and analysis times in PRA.
Planning units should always be set when first importing the schedule into PRA and careful schedule checks made to ensure discrepancies are minimised at that time.
Calendars
In multi-phase projects involving, say, design, procurement, construction and commissioning, calendar changes are generally unavoidable when modelling accuracy is important. But changes in working periods per day and/or per week may result in “gaps” in criticality when trying to determine the driving critical paths through a model. Mixed working periods occur when the calendars attached to a predecessor and a successor task are not the same. For example, if the calendar of a predecessor task were set to 24 hours a day, and the calendar of a successor task only allowed for 9am to 5pm, any time the predecessor task finished between the hours of 6pm and 8am, float would be created between the two tasks, resulting in loss of criticality. In general, when a predecessor has more available working periods in a week than its successor, the total float of the predecessor will be greater than that of the successor.
In the special case of the successor having zero float, the critical path must be defined by “longest path” rather than zero float because the predecessor task will have positive float.
• The question of whether to adapt the existing client’s schedule or construct a new schedule specifically designed for use in RA is a crucial one, and one that must always be answered at the beginning of any analysis.
• It is not uncommon to find that schedules are of poor quality after the commencement of the process and some effort should always be allocated to examining and circumventing any issues that may arise from the schedule’s construction.
• The size of the schedule is a key consideration when preparing a schedule for RA. Too few activities and key dependencies and visibility of the true drivers of the project can be missed and Merge Bias Effect s unrealistically excluded. Too many activities and the model can become unwieldy and unusable.
• RIMPL prefer to use the project schedule, with its built-in logic representing real dependencies between elements of the project, rather than create a summary schedule with the concern that key logic may be omitted.
• Ultimately, however, it is unavoidable that some client schedules are of such poor technical construction (refer to Technical Requirements for Schedules for use in risk analysis), or are of such a size (or both!) that they cannot be used or adapted. In such circumstances, a summary schedule must be constructed. Other circumstances that could require a summary schedule include combining different schedules, or a program of projects.
The choice of which distribution type to use is dependent on a multitude of factors including the type of data being collected, and if gathered by polling individuals, the way in which it was requested. For example, if people were asked to identify a “minimum”, “most likely” and “maximum” value for a distribution, a triangle distribution might be best suited. This is because the terms minimum and maximum may be most commonly interpreted as the extreme values. However, if “optimistic”, “most likely” and “pessimistic” values were requested, a Trigen distribution might be better suited, as the terms optimistic and pessimistic don’t imply that extreme values are sought. If utilising reliable data gathered from a large population sample, a BetaPert distribution may be best as described above. However, where very little is known about an uncertainty range and no central tendency can be assumed, it may be appropriate to simply specify minimum and maximum limits and use a Uniform distribution, with every value between equally possible.
Risk Factors are underlying causes of risk and uncertainty in projects that, if identified, quantified, and applied to project activities, can significantly increase ability to understand what drives project schedule risk.
Duration risk factors apply a methodology that defines and assigns uncertainty to plan tasks through identification of common contributors (or “factors”) that affect probabilistic duration outcomes. Unlike normal three-point estimates of uncertainty, risk factors are better described as causal contributors to project uncertainty that affect groups of activities (or resources) within a model equally during a simulation. For example, whereas a collection of construction tasks may all have separate duration uncertainties as they are independent tasks, there are also likely to be common factors such as site productivity rates that influence their durations to a similar extent.
The risk factors methodology has another significant benefit over traditional 3-point estimates in that it can take the guess work out of defining an effective correlation model. One of the key features of the Monte Carlo Method is that it inherently assumes all elements in a model are independent. To over-ride this invalid assumption for related tasks in a project schedule, a risk modeller is required to make educated guesses regarding the degree of relatedness between groups of tasks then enter these values as correlation percentages against each of the applicable model elements in the group. In contrast, the risk factors methodology removes this guesswork from the analysis as it effectively defines the degree of relatedness between elements by the action of multiple risk factors on overlapping groups of activities.
The validity of this is dependent on all significant risk factors being identified and applied.
The following steps briefly outline how a risk factors methodology can be applied to a schedule risk model:
• Stakeholders identify common sources of uncertainty within a model that have the potential to influence task duration outcomes. These are the risk factors. Their impacts may range from <100% of the deterministic value to >100%
• Characteristics of each risk factor are defined including:
◊ Impact range distribution (3 point probability distribution and shape),
◊ Probability of occurrence (may be 100% or less), and
◊ Correlation between related risk factors.
• Risk factors are then mapped to tasks and/or resource assignments.
• When a risk analysis is run, the Risk Factors application intercepts each iteration event and modifies each task duration and/or resource assignment value according to the net effect of the individual or multiple risk factors that have been applied.
• The modified task / resource assignment information then provides the inputs for the scheduling engine before the results are calculated and committed as the final iteration data.
Mapping risks to schedule tasks is a challenging aspect of the schedule risk analysis process, as it requires a detailed understanding of the nature of the risks and schedule tasks involved in the process. The integrity of any schedule risk model is dependent on the validity of the risk/task mappings, such that their impact is neither overstated nor understated.
When a schedule risk is mapped into a schedule model, it is then referred to as a schedule risk-task. This is a task that has a probability of occurrence less than 100%, a deterministic duration of 0 days, but a probabilistic duration distribution greater than 0 days. By definition, a risk is not a risk if it has no impact on the objectives of the project. Therefore, probabilistic impact ranges including minimums of 0 days are not recommended.
The placement of risk-tasks within the probabilistic model is a significant determinant of their impact on the probabilistic schedule outcomes. Factors which influence the effect of a risk on the schedule model include:
• The probability of the risk’s occurrence in any given iteration. If a risk is specified as 50% probable and the project model were to be simulated 1000 times, the risk will exist (occur with an impact from its distribution) 500 times. The more iterations in which a schedule risk-task is triggered, the more effect it will have on successor probabilistic completion dates.
• The risk’s probabilistic duration distribution profile. Similarly to normal tasks with duration uncertainty, risk-tasks are usually assigned a duration distribution profile. This is the duration impact that the risk-task will have on its parent task’s successors should it occur. Risk-tasks with larger duration distributions produce larger changes in probabilistic schedule outcomes of successor tasks than those with smaller duration distributions.
• The criticality of the task to which the risk is mapped. Risks must be applied in context. A risk with a high probability and high impact may have less probabilistic impact on project objectives than a low probability low impact risk if the task to which the former applies is rarely on the critical path while the latter affects a task frequently on the critical path.
• The logic applied to predecessors and successors of the risk-task. The schedule logic into which the risk is mapped (to the parent task) is also important as it determines how the project-level risk behaves when applied at the activity level. If we assume that a threat risk-task is mapped to the end of its parent task, the successor logic of the parent task should be replicated on the risk-task. However, if the parent task has no driving (or near-driving) finish-successor logic, or only successor logic stemming from its start, the risk-task cannot actually impact on any successor task. As stated earlier (3.2.2 Schedule Preparation), each task in an Schedule Risk Analysis model should have at least one start-predecessor and at least one finish successor.
Geotechnical investigations of each area of the site have produced the following probabilities of rock in each area:
Area S1: 50%; Area S2: 25%; Area S3: 5%
As for Case A, the presence of rock increases the excavation time by an impact distribution range of 15% / 25% / 50% of planned duration.
In this case there are three separate risks, applicable independently to the three different areas with their different probabilities. However, each has the same impact delay range distribution of 15% / 25% / 50% of the parent task duration.
Case C
The excavation logic is changed to accelerate the work by doing all three area excavations in parallel:
Where two or more activities affected by a risk are arranged in parallel, the impact may be applied 100% to each pathway because the delay may occur which ever path is followed in the project.
By paralleling the parent tasks the overall effect of the risks in case A and B applied to Case C will be lessened, with the largest combined task and risk uncertainty driving the model uncertainty.
If instead of expressing the schedule impact as a percentage of each duration, the project level risk were expressed in terms of an overall impact range, such as “…causing a delay of” 5d / 8d / 15d, it would be necessary to apportion the impact range between the three excavation tasks.
These examples illustrate the importance of the wording of the risk and the logic in determining how a project risk is mapped at the activity level.
• Weather uncertainty refers to the variations in normal weather conditions. This is the variability / fluctuation of normal weather patterns within specified time periods. For example, in the month of May in a specific region, there may be an average 10 hours of downtime due to inclement weather. However, historical data may show that this could be as little as 5 hours, or as much as 30 hours. An impact probability distribution would be required to express that uncertainty.
• Weather events behave somewhat like risk events and are assigned a probability of existence. Weather events typically refer to distinct events such as floods, fires and cyclones or hurricanes. These are events that may or may not occur, but if they do, may have a similar impact on productive downtime across large portions of a project plan. Similarly to risk events, weather events can be assigned optimistic, most-likely and pessimistic duration ranges, and can be applied selectively to tasks within a schedule risk model.
• Weather windows refer to periods within a schedule model in which certain operations can or cannot be undertaken. Unlike weather events, weather windows have 100% probability of existence. Their uncertainty stems from when they will start and how long the period will last. Classic examples of weather windows are the opportunity to truck materials over non-permanent ice-roads, the ability to use rivers for barging goods or the period for which roads are impassable during the wet season in tropical areas.
or “peakedness” of the distribution). This is because of the apparently “random” selection of high values from some distributions and the counter-selection of low values from others, combining together across many iterations to result in very little overall variance either side of the mean.
By correlating related activities, we ensure that commonly themed or related packets of work are constrained to greater or lesser extents (depending on the percentage correlation) to be sampled from the same end of the spectrum of possible outcomes. This results in a greater net variance either side of the mean. A correlation percentage of 0% means no association between activities. Conversely, a correlation percentage of +100% forces complete proportionality in the sampling of distributions between activities in a linear fashion. In rare situations negative correlation may apply, where a higher duration being sampled from one activity trends towards a lower duration being sampled in another.
The challenges with correlation are:
• To determine to groupings in the model to which correlation should be applied and
• To identify the levels of correlation applicable in the absence of data.
Correlation and the Merge Bias Effect (MBE) are factors to be balanced in development of realistic Schedule Risk Analysis models. The MBE causes larger and more complex schedule models to be more realistic and preferable to smaller more summarised models. But the larger and more complex the Schedule Risk Analysis model becomes, the more important realistic correlation becomes and the more challenging it is to achieve it.
Running a different number of simulations will produce different results. However, less obvious is why running two different analyses on the same plan, using the same number of iterations in each, might produce two different answers. The reason why this occurs is because Monte Carlo in its purest form is always completely random in its sampling. Therefore, if two identical analyses are run, it’s unlikely that exactly the same result will be produced. Although perfectly statistically valid, there are two problems with this approach:
• First, it can be confusing to users attempting to interpret the results; and
• Second, the computational processes required to produce and interpret useful results from such truly random sampling are quite resource intensive, and require significant processing time.
However, Monte Carlo schedule risk analysis tools may allow the user to control the use of something referred to as a “seed”. This is the starting point for the set of instructions for the random sampling processes to follow that increase analysis performance speeds and also ensure that the same plan modelled twice in the same way will always produce the same results. All subsequent values are generated randomly, so although the simulation is now following the same sampling pattern, it is still, in effect, a random process. But the apparent randomness of the results is significantly reduced.
Tests run by RIMPL have shown that the effect of changing the seed varies truly random analysis results depending on the number of iterations:
• For 1,000 iterations of a schedule model with, say, 1,000 activities, the percentage variation between analyses through seed changing may be 1-1.5%.
• If the number of iterations is increased to 5,000, the percentage variation between analyses through seed changing may drop to 0.5%.
It is important to note that any change in a model effectively changes the way that the seed interacts with the model, and therefore is tantamount to changing the seed itself. It is only by ensuring that a sufficient number of iterations have been performed in each analysis that the apparent “noise” in the analysis results associated with this seed change will be minimised. This is important if the effects of risks are being measured by difference. If the probabilistic effect of a risk is small, its effect may be exceeded by the randomness introduced by the effective seed change effect of removing the small risk. This can explain anomalous results for low probabilistic impact risks from Schedule Risk Analysis modelling.
Skewness refers to the asymmetry of data around a central point, and indicates a bias in the trending of results. Data can be positively skewed, negatively skewed, or without skew. A positive skew indicates a longer tail after the central measure, whereas a negative skew indicates a longer tail before the central point.
In schedule risk analysis, Skewness is important as it indicates the bias toward optimism or pessimism relative to the mean. If data is positively skewed, the P90 dates will be further from the mean than the P10 dates will be from the mean and the skew or bias is pessimistic. Conversely, if data is negatively skewed, the P90 dates will be closer to the mean than the P10 dates and the skew is optimistic. Understanding the potential for movement of schedule dates towards either extreme of the analysis is important in understanding overall risk exposure.
