Risk register

The register is the source of every other number in the product. A simulation is only a resampling of it and a report is only a summary of it, so the time spent getting a risk right here is the highest-value time in the whole workflow.

Creating a risk

From the Risk Register, choose New. The form asks two questions before it asks for any detail:

What are you creating?

• Risk: a potential threat or opportunity. Gets an ID starting R-, a probability, and both cost and schedule impacts. This is the full quantification workflow.
• Assumption: a project baseline or a given. Gets an ID starting A- and a cost entry only. No probability, no schedule impact.

How detailed should this be?

• Quick entry: the essential fields, a probability percentage with a written justification, and the basics (title, owner and so on). About five minutes.
• Detailed workflow: the full set of register columns, a probability decision tree, schedule impact, and the governance and classification fields. About fifteen minutes.

Quick entry is not a lesser record. It is the same risk with fewer fields filled in, and anything you skip can be added on the risk page later. Use it when you are capturing a workshop and use the detailed workflow when you are preparing for a review.

Every risk needs a title, a description, a root cause, an impact description and an owner. If you type a description first, the AI suggestions panel can propose a probability, impact areas, causes and response strategies from it. They are suggestions only: nothing is saved until you accept it, and the justification field is yours to write.

Probability and three-point estimates

A risk carries a probability (the chance it occurs at all) and a three-point cost estimate: minimum, most likely and maximum. From these the register derives two figures you will see everywhere:

• PERT expected value: the weighted mean (min + 4 × most likely + max) ÷ 6, which pulls the estimate toward the most likely figure rather than the midpoint.
• EMV (expected monetary value): the PERT value multiplied by the probability. This is the figure the register totals and the split above the table uses.

If a risk has a most likely figure but no minimum or maximum, the simulation assumes 85% and 120% of the most likely value respectively. That is a placeholder, not an estimate: a risk that matters should have all three points entered deliberately.

Schedule impact is entered in weeks, and is what the schedule risk analysis uses when a risk is linked to programme activities.

Cost lines and the rates library

Rather than typing a lump sum, a risk’s cost is built up from cost lines. Each line names a cost element, a quantity, a WBS code and a minimum, most likely and maximum rate. The rates come from the project’s Rates Library, so an estimate can be interrogated line by line rather than defended on authority.

The library is versioned. Only the published version supplies rates; published and archived versions are immutable, so an estimate built on one never shifts underneath you. Editing rates happens in a draft version, which an administrator then publishes.

WBS codes on cost lines are what let the simulation roll risk cost up through the breakdown structure. A line without a code lands in the portfolio total but not in any package, so the WBS Explorer will show less than the register does.

Allocation: who carries the risk

Each risk has an allocation: Project, Programme, Contractor or Undefined. Commercially there are two parties, and the register groups the values accordingly:

• Client: Project and Programme risk.
• Contractor: Contractor risk.
• Unallocated: Undefined, blank, or anything the system does not recognise.

The same grouping drives the split above the register table, the filter, the report scope and the PDF, so the client-only number in a monthly report is identical to the client-only view on screen. An unrecognised allocation is shown as unallocated rather than quietly folded into the client figure, which is how a typo shows up instead of inflating someone’s number.

Mitigation and AI assessment

A risk holds a mitigation plan in three parts: actions (preventive and corrective), controls (existing and planned) and a fallback if the primary mitigation fails. It also carries a pre-mitigation and a post-mitigation estimate, and both feed the analysis so the effect of the plan is visible on the curves.

Once a plan is written, anyone who can edit the risk can request an AI mitigation assessment. It returns a structured residual estimate with a confidence rating and a gap analysis of the plan. A Risk Manager then reviews it and accepts or rejects it, with an optional reason; the history of every assessment is kept on the risk. Nothing is applied to the estimate automatically.

The change log

Every edit to a risk writes an entry to its change log recording who made it, when, and each field’s value before and after. The log is append-only and cannot be edited or cleared by anyone, including administrators. It is the audit record for the register, and it is why the product has very few confirmation dialogs: the history is the undo.

Closing and reopening a risk

Closing a risk is the only moment the register learns what a risk actually did, as opposed to what someone estimated. The Close-out panel on the risk page asks:

1. What happened? Did not occur, occurred, partially occurred, superseded by another risk, or transferred to another party.
2. Actual cost and actual delay in weeks, both optional and only offered when the risk occurred or partially occurred.
3. Where the cost figure comes from: a figure from the cost report, or an estimate made at close-out. These are kept separate so a close-out judgement is never later mistaken for a hard actual.
4. Notes for a reviewer.

Some combinations are rejected because they would be misleading rather than merely incomplete: a cost or a delay recorded against a risk that did not occur, a negative figure, or a cost with no stated basis. Incomplete is fine; a risk can close with no cost at all.

On closure the risk’s classification, estimate and outcome are frozen into an outturn record at company level. That is the history used to sense-check future estimates in the same category. It is a copy, not a link: retagging a live risk two years later does not rewrite it.

Reopening a closed risk removes its outturn record, because a reopened risk has not finished and its outcome is not yet knowable. Closing it again writes a fresh one.