The conventional approach to project risk management is pivoted around the Risk Register. Its primary purpose is to ensure that potential problems are identified before they become actual issues that may affect the project's budget and schedule.

A risk register is a table containing the following input columns: risk ID, description, category, probability, impact, score, the risk owner, status, alarm trigger, and others.

From an information modeling perspective, this data structure is an example of poor database architecture, matching the management theory state. It has serious flaws explained below.

The risk description actually hides an “if-then” condition loosely referencing entities (object and subject) not present in the database.

As the risk subject is missed, the risk entry can’t be automatically linked to the project budget and schedule.

The description and category define a generic risk source, while the ID value is an indicator of the project-specific risk. Mixing generic and specific instances is not a good practice.

Probability shall be an output of historical data analysis, not an expert’s input.

Impact shall be an output of the project data analysis, not an expert’s input.

Being a function output (proportional to the probability and impact values), the score shall not be stored in the table, but the function reference shall.

Status is an input, but in reality, it should be an output of some trigger constantly monitoring the “if-then” condition mentioned earlier.

Risk owner links a potential problem, which may never be realized, to actual project resources. It is a good practice to describe temporary links in another table referencing a generic risk group, not a specific one.

The mentioned flaws, not visible in the Risk Register with a small number of entries (below 50), become an insurmountable challenge in the mega-projects executed in parallel, where a number of entries may be over 200.

Crenger.com replaced Risk Register with Risk Prediction Framework, discussed below. Its starting point is the risk definition. In conventional project management, it is written as follows.

Risk = probability*impact, (A)

The equation works satisfactorily when both probability and impact are defined qualitatively – low, mid, high. Moving to quantitative values requires a more rigorous definition of the equation components.

An approach to the probability prediction may be illustrated by two base cases - technology-expertise mismatch and time-interval mismatch.

The former is so dangerous that companies prohibit quoting bespoke equipment pieces deviating in capacity by more than 20% from successfully operated ones (used as Reference Capacity-Technology Class). Probability P as a function of deviation D may be written as follows.

p(d) = 0 if d ≤ 20% and p(d) = 1 if d > 20%

In neural networks, such a condition is a first step in selecting an activation function – a close approximation of it. Popular types are Sigmoid, Tanh, ReLU, and others. Activation function is a proven way to capture non-linearity in risk perception. It is the beginning of neural work application to the project risk prediction.

The second case takes into account the sliding time window of the project schedule and its tasks.

With an accuracy sufficient for most cases, the probability may be defined as follows.

probability = Pe*Ps*Pt, (B)

Where Pe – probability of an event with a known time interval, Ps – probability of the event occurrence within the project timeline, Pt – probability of coincidence of the project-specific tasks and the event that already occurred.

The equation above converts a prior probability Pe to different time intervals.

Let’s find the bankruptcy probability of a company supplying bespoke equipment, provided that only two similar companies out of 10 have gone bankrupt over the last 30 years. The project duration is 3 years, and the cumulative duration of the project tasks that may potentially be affected by the event is 1 year.

Probability = (2/10)*(3/30)*(1/3) = 0.0067

As seen, the probability calculation requires the project schedule data. It becomes critical in the risk impact prediction. Regardless of the actual scenario, the risk impact on the project will probably not surpass the monetary value defined as follows.

impact < task_budget + schedule_drag * penalty, (C)

where schedule drag is calculated for the case where the task is 100% overdue.

The database maintained by conventional project management is insufficient for calculating Equation C right side, merging the maximum schedule and budget impacts.

The important inference from Equations B and C is that the schedule task defines the risk scope, probability, and impact. As the task is supposed to be linked to named resources, they become the risk owner automatically.

Obviously, the maximum count of entries in the risk register cannot surpass the number of project tasks. Tasks on the schedule critical path automatically define a group of critical risks.

Alarm triggers monitor task execution. Any substantial deviation in the task scope or duration shall change the risk status to an active one and launch the impact mitigation plan.

Crenger.com introduces a new indicator of the task health – Safety Integrity Level (SIL). It changes from 1 (healthy) to some minimum at which the task stops being atomic and manageable.

The task inspector constantly iterates through high-risk tasks and validates SIL. If it is below a minimum, the inspector changes the task risk status and raises an alarm.