6 Best Project Risk Analysis Tools in 2024

If you run highly complex projects, they will come with very large operating schedules (say 10,000 tasks +). Usually, there will be a lot of detail for imminent work, getting progressively less detailed projecting out into the future. Then as the project evolves, and tasks are completed, the next wave of activities are broken down into more detail. Project risk analysis is done using Monte Carlo simulation which is very computationally intensive. It uses lots of computer memory and the simulation time is roughly proportional to the number of tasks in the schedule. Historically, it has been quite impractical to run a Monte Carlo simulation on very large schedules because the software couldn’t load the schedule or perform a simulation run within a reasonable time frame (i.e. minutes, not days) so people had one master schedule for coordinating the project, and another for doing risk analysis. As schedules get big and complex, maintaining a second cutdown schedule for the risk modelling becomes impractical, as well as extremely tedious.

Breaking down a large task into smaller ones as greater detail becomes needed brings its own problems for risk analysts. I’ll give you an example – let’s say that you are building a fence, and estimate it will take Triangle(30,40,60) days to complete. As the time comes closer to building that fence, you break it down into 10 equal sections, each taking Triangle(3,4,6) days to complete. Suddenly, your risk analysis shows a dramatic reduction in the time to complete the project:

The reason is that your project risk analysis software is assuming each of these tasks is statistically independent, i.e. that if the first fence section takes a very long time (6 days), it says nothing about whether the next section will take a short or long time. The Law of Large Numbers (LLN) helpfully explains that this will reduce the calculated uncertainty. Software handle this in three different ways: (1) it does nothing and hopes you won’t notice; (2) it uses a simulation trick to ensure that all distributions in a group are sampled with 100% correlation; or (3) it asks what is driving the uncertainty, and makes all task durations dependent on that external factor.

One last practical thing – if you have a schedule of 1,000’s of tasks, imagine how tedious it would be to assign uncertainty to each one. Assigning bulk uncertainty is very useful. This is usually done by selecting a group of tasks and applying a global percent variation to each. But be careful – if the duration uncertainty for a large group is due to a common factor – like the competence of a contractor – you are faced with the LLN problem again, so make sure that is captured or you will greatly underestimate the risk.

Conclusion: if you are intending to simulate large schedules, make sure the project risk software can handle the size, runs really fast, includes a way to handle the LLN problem, and can assign uncertainty to large groups of tasks in a flash.

Probability distributions are used to describe the uncertainty of task durations and cost items. There are plenty of different distributions to choose from. Here are the most common:

Conclusion: make sure the software offers at least one of the orange or green smiley face distributions. Ignore red smiley face distributions.

Think of a risk event like a supplier goes out of business. There could be multiple impacts – delays to procurement of various materials, different additional costs, etc. These consequences will either all happen together, or not at all. If you can’t model that properly, you’ll underestimate the total risk and the value in managing your supply risk.

Conclusion: make sure the software can map single risks to multiple consequences if that’s something that could realistically happen in your world.

Risk events are things like strikes, equipment failure, and accidents. They happen or they don’t. If they happen, they add some cost or delay or both. Many risks can happen more than once, in which case you’d want to be able to describe that. The likelihood of occurrence of risks that could only happen once (like the building is destroyed) is described by a probability. The likelihood of occurrence of repeatable risk is described by an expected frequency (like 0.7 times/year). If the software only allows describing single risks, and you have repeatable ones, you’re going to have to do some juggling with the model or you’ll underestimate the uncertainty.

Conclusion: make sure the software can distinguish frequency and probability if you have repeatable risks.

Weather can be very important, e.g. if you do offshore work or operate in a part of the world with extreme seasons or weather events. Risk analysis software usually manage this with weather calendars.

Conclusion: if weather is something you fight against, check to see whether the software can handle it.

Schedule models typically allow you to enter various types of cost:

• A fixed cost incurred at the beginning, middle or end of a task
• Rates for resources (e.g. $/hr for workers, $/day for equipment), attached to tasks and prorated by their duration
• Expense rates (like office site rental) that are independent of individual tasks

Project risk analysis software typically pick these values up, adds some uncertainty as needed, and adds the possible costs of risk events to get an aggregate estimate of the total project costs. But that is only part of the picture. There will be many other costs that have no practical place in a schedule – legal and license fees, costs of materials, insurance, financing costs, etc. These are typically analysed separately by cost engineers and financial analysts – and they also have a lot of uncertainty. The results of these two risk models need to be merged somehow to get a full picture.

Conclusion: if you are interested in the uncertainty of the total cost of a project, not just the schedule-related part, the software needs to be able to integrate the two sources either by exporting the data in some form or by including a spreadsheet simulation tool within the product.

Most projects are undertaken to provide some financial return. For example, a new product is developed to sell into the market, or a new building is constructed to rent out. Typically, the upfront investment associated with the project execution is set against the forecast cashflows using a discounted cashflow (DCF) model, calculating financial metrics like net present value (NPV). When the project takes longer to finish, it will incur additional costs eroding the NPV, but the delay in receiving the compensating cashflows also reduces the NPV.

Discounted cashflow calculations are typically performed in Excel, and the uncertainty around those cashflows (and hence the NPV achieved) is evaluated using an Excel risk analysis add-in like ModelRisk. Discount rates are usually in the range of 10-15% per annum. A solid internal rate of return (IRR) would be around 20-25%, and a marginal IRR would be around 5%. Thus, if a project has a lot of upfront cost, a delay of 1-2 years can easily turn the investment from a great opportunity to a financial failure. The effect of project cost and schedule overrun risk, and the cost profile over time, need to be factored into the discounted cashflow models in such cases.

Conclusion: if your business uses risked DCF models to select potential investments, your development project risk analysis will need a mechanism to export the simulated cost time series to a spreadsheet risk analysis tool. Better still, the project risk analysis software could have a built-in spreadsheet simulation tool.

Project risk analysis tries to predict what might happen by accounting for all the major uncertainties and risks that impact a project. You can imagine that a schedule that includes milestones and task finish dates that are locked don’t really match that idea. Similarly, a schedule that has leading lags (e.g. task B will start 30 days before task A has finished) is pretending to know what the future holds (what if task A gets delayed ¾ of the way through?). Or two tasks will finish together (F-F). Most of these non-Finish-Start links are common planners’ shorthand for a more intricate network, but you should be aware how they can be in contradiction with a risk analysis model that simulates and builds on predecessors only.

Conclusion: make sure your schedulers understand that fixed milestones are banned, and that F-S link logic is the best way to go whenever possible. Also, the project risk analysis software should do a logic check on a schedule during import and highlight any problems.

If, for your purposes, you can decently summarise your project into a small set of tasks, you can build a quick schedule model in a spreadsheet. You can read about, download and play with a couple of example models here and here.