Risk management planning and identification

Every plan in PMP-130 rested on estimates and assumptions: that the permit would arrive in six weeks, that the ceiling held no surprises, that tag prices would hold. Risk management is the discipline of dealing with that uncertainty deliberately. This lesson defines risk, explains how organizations express how much risk they will accept, describes the risk management plan and walks through the techniques for identifying risks and writing them so they can be managed. Lessons 4 to 6 cover analysis, responses and monitoring. PRINCE2 users will recognize many of the ideas from PRIN-131's risk practice; the vocabulary differs in places, and this course uses the terms common in PMI-based materials.

What a risk is

A risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives. Three parts of that definition matter. It is uncertain: something that has already happened, or is certain to happen, is not a risk but an issue or a fact to plan for. It has an effect on objectives such as scope, schedule, cost, quality or benefits. And the effect can be negative (a threat) or positive (an opportunity). Exam questions regularly test whether candidates remember opportunities, which many real risk registers neglect.

It helps to distinguish individual project risks, the specific events in the risk register, from overall project risk, the effect of uncertainty on the project as a whole. Overall risk includes the combined effect of individual risks and other sources of uncertainty, such as the spread of every cost estimate. Lesson 4 shows how a Monte Carlo simulation estimates overall cost risk for Project Compass and why it can differ sharply from the sum of a few listed risks.

PMP-130 linked these categories to reserves: contingency reserve covers identified risks (known-unknowns) and sits inside the cost baseline; management reserve covers unidentified risks (unknown-unknowns) and is held outside it by management. Because some risks cannot be identified in advance, risk management also builds resilience: buffers, flexible contracts, cross-trained people and a habit of scanning for emerging risks throughout the project.

Risk attitude: appetite, tolerance and thresholds

Organizations and individuals differ in how much uncertainty they will accept. Risk appetite is the degree of uncertainty an organization is willing to take on in anticipation of a reward. Risk thresholds turn appetite into measurable limits: the level of exposure above which a risk must be escalated or acted on. Some materials also speak of risk tolerance, the amount of variation from objectives that is acceptable. Appetite is a general stance; thresholds are concrete numbers.

The library board is risk-averse about the opening date and patron safety, because the branch opening is a public commitment and the library is accountable for public money. It is more relaxed about the mobile app's feature set, where it is willing to experiment. The risk management plan records thresholds that reflect this: any risk that could delay the opening by more than ten working days, add more than $50,000, or affect patron or worker safety must be reported to the sponsor within two working days. Risks to app features within the release budget are managed by the product owner.

Risk attitude also has a human side. Individuals' perceptions of risk are influenced by biases such as optimism, anchoring on early estimates and groupthink. A project manager who knows this asks for evidence, invites dissenting views and uses techniques such as anonymous input to counter the loudest or most senior voice.

The risk management plan

The risk management plan describes how risk management activities will be structured and performed on this project. It is created early, during planning, and is a component of the project management plan. It is proportionate: a short project with familiar work needs a light plan; a large, novel or politically exposed project needs a fuller one.

A risk breakdown structure (RBS) is a hierarchical list of risk categories, for example technical (requirements, technology, quality), external (suppliers, regulatory, market, weather), organizational (resources, funding, priorities) and project management (estimating, planning, communication). It works as a prompt list during identification and as a way to see where risks cluster.

Identifying risks

Identification is an iterative activity that involves the team and stakeholders, not a one-off workshop at the start. Different techniques surface different risks, so most projects combine several.

Assumption and constraint analysis is particularly productive. PMP-130's plan for Project Compass assumed a six-week permit review, a tagging rate of 110 items per person-hour from the pilot, stable tag prices and availability of one electrician crew. Each assumption becomes a candidate risk: the permit could take longer; the rate could be lower with a new tag batch; prices could rise; the crew could be needed elsewhere. Lessons learned from earlier projects add more: the library's register records that a mall landlord restricted noisy work at another branch, and that tag lead times doubled before the holidays.

Writing risks so they can be managed

A vague risk such as "budget" or "the permit" cannot be analysed or owned. A structured risk statement, sometimes called risk metalanguage, separates cause, risk and effect: because of a cause (a fact or condition), an uncertain event may occur, which would lead to an effect on objectives. For example: because the city's permit office has a backlog (cause), the building permit may be issued later than planned (risk), which would delay demolition and the critical path and add costs for extended site overheads (effect). Writing risks this way exposes shared causes, suggests responses that act on the cause or the effect, and prevents confusing a risk with its cause or its consequence.

Triggers, also called risk symptoms or warning signs, are indications that a risk is about to occur or has occurred. For the permit risk, a trigger might be the city not acknowledging the application within ten days. Recording triggers helps owners act early, and monitoring them is part of lesson 6.

The risk register and risk report

The risk register records the details of individual risks. Early in the project it may hold just the risk statement, a potential owner and possible responses. As analysis and planning proceed, it gains probability and impact scores, priority, categories, triggers, agreed responses, response owners, residual and secondary risks, and status. The risk report, by contrast, summarizes overall project risk and the most important individual risks for stakeholders.

# The first Project Compass risk register, sorted by probability x impact score
# Scales: probability and impact each scored 1 (very low) to 5 (very high)
risks = [  # id, risk statement (cause -> event -> effect), P, I, owner
 ("R01", "Old ceiling may contain asbestos, so removal halts work and adds abatement cost", 2, 4, "Fit-out lead"),
 ("R02", "City permit review is backlogged, so permit may be late and delay demolition", 3, 3, "Project manager"),
 ("R03", "Tag supplier faces tariff costs, so tag price may rise before the order", 2, 3, "Procurement"),
 ("R04", "App store review rules change, so the app may need rework before release", 2, 2, "Product owner"),
 ("R05", "Only one electrician crew is available, so rough-in could slip", 3, 4, "Fit-out lead"),
 ("R06", "Mall landlord controls after-hours access, so noisy work may be restricted", 3, 2, "Project manager"),
 ("R07", "Kiosk firmware is new, so early failures may hit opening week", 3, 3, "Technology lead"),
 ("R08", "Volunteer turnout for the collection move may be low, so opening could slip", 2, 3, "Branch manager"),
 ("R09", "Vendor offers volume discount if tags are ordered with another branch (opportunity)", 3, 2, "Procurement"),
 ("R10", "Key staff may leave during the project, so knowledge is lost", 2, 3, "Sponsor"),
]
print(f"{'ID':4s}{'P':>3s}{'I':>3s}{'Score':>7s}  Zone   Owner")
for rid, text, p, i, owner in sorted(risks, key=lambda r: -r[2] * r[3]):
    s = p * i
    zone = "high" if s >= 12 else "medium" if s >= 6 else "low"
    print(f"{rid:4s}{p:3d}{i:3d}{s:7d}  {zone:6s} {owner}")

ID    P  I  Score  Zone   Owner
R05   3  4     12  high   Fit-out lead
R02   3  3      9  medium Project manager
R07   3  3      9  medium Technology lead
R01   2  4      8  medium Fit-out lead
R03   2  3      6  medium Procurement
R06   3  2      6  medium Project manager
R08   2  3      6  medium Branch manager
R09   3  2      6  medium Procurement
R10   2  3      6  medium Sponsor
R04   2  2      4  low    Product owner

The first register contains ten risks, nine threats and one opportunity. The only high-priority risk is R05: the project depends on a single electrician crew during rough-in, which sits on the critical path. Several medium risks share a theme of external dependencies: the city, the landlord, the tag supplier and the kiosk vendor. That pattern suggests a response at the cause level, such as earlier engagement with external parties, which lesson 5 develops. Note that the opportunity R09 is scored on the same scales but for benefit, not harm; many organizations keep a separate opportunity matrix so the two are not mixed.

Each risk has an owner: the person best placed to monitor it and ensure that the agreed response is carried out. The owner need not be the person who performs the response work. The project manager facilitates the process but should not own every risk; spreading ownership spreads attention and keeps risks close to the people who can see their triggers.

Risk in adaptive and hybrid projects

Adaptive approaches manage much uncertainty through their structure: short iterations, frequent delivery and feedback reduce the chance of building the wrong thing for long. Risks still need explicit attention. Teams can add risk-reduction work to the backlog, such as a spike to test the app's connection to the library system before building features on it, and prioritize it high, producing a risk-adjusted backlog. Daily stand-ups and retrospectives surface impediments and emerging risks quickly. A burn-up chart showing growing scope is itself an early warning of schedule risk.

On Project Compass, the app team held a two-day spike in its first sprint to confirm that the library system's interface could return real-time availability. It could, but only every five minutes, which changed the design of the holds feature and removed a risk that would otherwise have surfaced weeks later. In the predictive fit-out, the same purpose is served by investigations such as the ceiling survey analysed in lesson 4.