Risk identification and the risk register

A risk that nobody has named cannot be managed. It sits in the project until it turns into an issue, usually at the worst possible moment and without any money set aside to deal with it. Risk identification is therefore the foundation of everything else in this course. It is also the step most often done badly: a quick brainstorm at bid time, a list copied from the last job, and a register that is never opened again. This lesson shows how to identify risks systematically, how to describe them so they can be analysed and managed, and how to build a risk register that the team will actually use.

Throughout this course we follow one invented project, the Kingfisher Wharf Community Centre. The City of Larkspur, also invented, is building a $48 million community centre with a 25-metre pool, gymnasium, library branch and underground parking on a former industrial waterfront site. Tallgrass Builders, an invented general contractor, has won the job under a stipulated price contract after a design-bid-build tender. The site has a history of fill, the water table is high, the pool hall is a complex mechanical space and the city wants the building open for a summer festival two years away. It is a good project on which to practise risk management because almost every category from lesson 1 shows up.

Sources of information

Good identification draws on several sources rather than one meeting. Each source catches risks the others miss.

Site visits deserve special mention. Walking the site with the drawings in hand, looking at neighbouring buildings, access routes, overhead lines, drainage and signs of past use, often reveals more than any report. Many of the risks that later become claims, such as a utility pole in the path of a crane or a neighbour's foundation sitting on the property line, are visible on the first visit to anyone who looks.

Identification techniques

No single technique finds every risk, so most teams combine several.

The pre-mortem, a technique popularized by the psychologist Gary Klein, is particularly useful against the optimism bias discussed in lesson 1. The facilitator asks the team to imagine that it is a year after completion and the project has been a disaster, then gives everyone a few minutes to write down the reasons. Because the failure is presented as a given, people feel free to raise concerns they would otherwise keep to themselves. At Kingfisher Wharf a pre-mortem might surface the fear that the pool will fail its first water test, that the festival opening will be missed and the city will be embarrassed, or that the shoring subcontractor will go bankrupt mid-job.

Describing a risk well

A vague risk cannot be analysed. 'Ground conditions' is a topic, not a risk. A useful technique is to describe each risk in three parts, sometimes called a risk metalanguage: a cause, an uncertain event and an effect on objectives.

The three-part description makes the next steps easier. The cause points to mitigation, since removing or weakening the cause lowers the probability. The event is what the team watches for. The effect tells the analyst what to estimate: cost, time, safety, quality or reputation. It also stops the register from mixing causes and effects, a common fault in which 'delay' appears as a risk when it is really the effect of many different risks.

The risk register

The risk register is the central record of identified risks and what is being done about them. It can be a spreadsheet, a database or a module of project management software, but it needs the same core fields.

Ownership is the field most often neglected. A risk owned by 'the project team' is owned by nobody. Each risk should have one named person who tracks it, carries out or delegates the response, and reports on it. The owner need not be senior; a site engineer can own the dewatering risk, while the project manager owns the liquidated damages exposure.

The contract allocation field is particularly important for contractors. A risk the owner carries under the contract still matters to the contractor, because the contractor must give notice when it occurs and must document its cost to be paid (CON-220 lessons 8 and 9). But it is managed differently from a risk the contractor carries at its own expense. Some contractors keep two registers: one for risks the contractor carries and one for owner risks that create claims or change orders.

Keeping the register alive

A register is useful only if it is updated. Common practice is to review the top risks at every project meeting, the whole register monthly, and the register as a whole at major milestones such as design completion, start of excavation, enclosure and commissioning. New risks appear as the project moves forward, and old ones close when the work that carried them is finished. A register that never changes is a sign that nobody is looking at it.

# A minimal risk register in Python (illustrative Kingfisher Wharf data)
from dataclasses import dataclass

@dataclass
class Risk:
    rid: str
    title: str
    owner: str
    prob: int      # 1 (rare) to 5 (almost certain)
    impact: int    # 1 (minor) to 5 (severe)
    allocation: str
    status: str = "open"

    @property
    def score(self):
        return self.prob * self.impact

register = [
    Risk("R01", "Contaminated fill in excavation", "Site engineer", 4, 4, "Owner (contaminated soil clause)"),
    Risk("R02", "Excavation flooding in spring thaw", "Superintendent", 3, 3, "Contractor"),
    Risk("R03", "Late delivery of pool dehumidifiers", "Project manager", 3, 5, "Contractor"),
    Risk("R04", "Shoring subcontractor insolvency", "Project manager", 2, 4, "Contractor (bonded sub)"),
    Risk("R05", "Rowing club access dispute", "Project coordinator", 2, 2, "Owner"),
]
for r in sorted(register, key=lambda r: -r.score):
    band = "high" if r.score >= 15 else "medium" if r.score >= 8 else "low"
    print(f"{r.rid} {r.title:<38} {r.owner:<18} score {r.score:>2} ({band})  {r.allocation}")
print("Contractor-carried risks:", sum(1 for r in register if r.allocation.startswith("Contractor")))

R01 Contaminated fill in excavation        Site engineer      score 16 (high)  Owner (contaminated soil clause)
R03 Late delivery of pool dehumidifiers    Project manager    score 15 (high)  Contractor
R02 Excavation flooding in spring thaw     Superintendent     score  9 (medium)  Contractor
R04 Shoring subcontractor insolvency       Project manager    score  8 (medium)  Contractor (bonded sub)
R05 Rowing club access dispute             Project coordinator score  4 (low)  Owner
Contractor-carried risks: 3

A spreadsheet does the same job, but writing the register as structured data shows why consistent fields matter: once every risk has a probability, an impact, an owner and an allocation, the team can sort, filter and report automatically. Lesson 3 explains the scoring scales behind the numbers, and lesson 12 shows how the register feeds a monthly dashboard.

Owner and contractor registers

On well-run projects the owner and contractor share at least part of their registers. The owner knows things about the site, the users and the approvals that the contractor cannot; the contractor knows about methods, trades and the market. Some public owners now require a joint risk workshop at the start of every major project and a shared register for risks that both parties can influence. Collaborative delivery methods (CON-340 lessons 6 and 8) go further, with a single project register managed by the whole team. Even under a traditional stipulated price contract, sharing information about risks that the owner carries, such as contamination or permits, helps both sides prepare.

There are limits. A contractor will not want to share its view of its own pricing risks or the weaknesses of its subcontractors, and an owner may hold back information it fears will invite claims. Contract clauses about the reliance that can be placed on site information, discussed in lesson 6, affect how much is shared and what each party can claim if the information turns out to be wrong.