Schedule Risk Analysis (SRA) is an established best practice for managing complex projects. Multiple software tools such as Primavera Risk and others allow teams to input uncertainty ranges and discrete risks and then run their schedule through Monte Carlo simulation. Although this process can have great benefits, we believe that it too often suffers from fatal drawbacks, and suggest an alternative approach.
Typical SRA’s use the project team schedule, which may include hundreds of activities, as the basic building block for analysis. This approach has critical drawbacks including:
Logic Unsuited For Risking - Most deterministic schedules are not built with “risking” in mind and therefore have numerous logic relationships that are not really valid when simulating uncertainty. Examples include activities with constraints that are not truly constrained, or numerous mostly parallel activities with sequences of start to start relationships.
Excessive Detail Driving Narrowness of Results - When probabilistically simulating large numbers of activities there will be a statistical tendency for narrow ranges of outcomes. Some argue that this tendency can be counteracted by adding correlations - which is true but is a not very transparent process.
Poor Input Due to SME’s Not Aligned With Detail - Input ranges are usually developed by key project team members who draw from data, judgment and experience. However their experience helps them express risk at a more aggregate level than the detail in most schedules. For example, they may have experience with the overall duration of constructing a piece of equipment, while the detail schedule represents that as twenty different component activities.
Non-Transparency - In almost all cases, the assumptions embedded in a detailed schedule are known only by the schedule; it is rare indeed for all those assumptions to be shared in a transparent manner where all parties can discuss and agree to them. That lack of transparency further dilutes the impact of any SRA findings.
We argue instead that - the project team itself should participate in the building of a more strategic schedule risk model. The schedule risk model should be simple enough to be visualized and the number of activities high-graded to the most important critical or potentially at risk parts of the project. In addition, the schedule risk model should make the logic dependencies easily visible so that the project team can discuss and debate and build further alignment. Our experience has shown that these strategic schedule risk models typically encompass 25-75 activities. In most cases, the scheduler or facilitator creates a first draft schedule risk model and then iterates with a core group of the project team to agree on the appropriate level of detail and what activities are represented.
Although this requires a little bit more investment of time up front, that investment of time more than pays for itself in value to the project:
Project team members are thoroughly familiar and aligned with the schedule being risked and the activities and logic, and can focus on risk discussion knowing that the underlying schedule has been vetted and is fully transparent
The process of developing the strategic schedule risk model almost always yields additional clarifications among the team and challenging of preconceived notions and assumptions
The simpler representation of the project also often means that results of the SRA can be generated and communicated more quickly, in real-time, improving the ability to run sensitivities or other mitigation scenarios as well as improving buy-in.
In summary - to get the most value out of Schedule Risk Analysis, we advocate that the project team develop, in a collaborative fashion, a strategic schedule risk model that is a better representation of the key activities and relationships and is more suited to generating insights and meaningful results.
Which is more likely to generate quality inputs, discussion and results from a Schedule Risk Analysis?
THIS:
OR THIS:
댓글