Risk Foundations and Identification

The Question Nobody Asked

Two weeks into planning the RtR relocation, Thesis Yu ran the first structured risk identification session. The core team had already worked through scope, schedule, and cost. An hour in, a team member raised a connection nobody had put on paper yet. The company had a client acquisition campaign scheduled to launch two weeks after the project's planned completion date. The campaign was built around the new address, the expanded service capacity, and the image lift from moving into a commercial district. What happened to the campaign if the project ran late? And what if the project finished early? In thirty minutes, the team had documented one threat and one opportunity, both invisible before someone thought to ask. That is what planning-phase risk identification produces: a picture the charter-level risk list cannot reach.

Risk Is Not What You Think It Is

Most people hear "risk" and think of things that go wrong. That is correct but incomplete, and the incomplete version leads to risk management that only ever looks in one direction. In project management, a risk is any uncertain future event that, if it occurs, will affect project objectives. The effect can be negative: a delay, a cost overrun, a deliverable that fails quality review. It can also be positive: an opportunity to finish early, save money, or capture a benefit the plan did not account for. Both are risks. Both require management. A team that tracks threats and ignores opportunities is leaving value on the table. The discipline of risk management is about managing uncertainty in both directions, not building a list of things to worry about.

Risks and Issues Are Not the Same Thing

Before the first risk is written down, the project team needs to be clear on a distinction that has real operational consequences. A risk is a future event. It has not happened yet, it is uncertain, and there is still time to plan a response. An issue is something that has already occurred and is actively affecting the project right now. The same event can begin as a risk and become an issue if it materializes. A supplier who may be unable to deliver on schedule is a risk. A supplier who has just confirmed they cannot deliver is an issue. The management approach differs: risks are tracked in the risk register with planned responses; issues require immediate action, escalation, and often changes to the project plan. Keeping this distinction clean in documentation and conversation prevents the reactive scrambling that happens when teams treat active problems as if they still have time to prepare.

Risk Appetite and Risk Thresholds

Before the team begins identifying risks, two organizational parameters set the boundaries for what those risks mean. Risk appetite describes how much uncertainty the organization is willing to accept in pursuit of its objectives. An organization with a high risk appetite pursues aggressive timelines and tolerates volatility in return for a higher potential payoff. One with a low risk appetite prioritizes predictability and accepts slower progress as the cost of stability. Risk thresholds define where that tolerance ends: the specific levels of probability or impact at which a risk requires an active response rather than ongoing monitoring. Both parameters are set at the organizational or program level before the project begins. The project manager does not set them, but must understand them, because they determine which risks are significant by the organization's own definition and which fall within acceptable range without requiring escalation.

Where Risks Come From — A Category Sweep

One of the most consistent failure modes in risk identification is stopping too early. Teams surface the obvious risks, delivery delays and budget overruns, and declare the session complete. What they miss are the risks sitting in less-examined categories. Working systematically through a category checklist is what closes those gaps. The table below covers the major risk categories that apply across most projects.

Not every category will produce significant risks on every project. But every category deserves a pass. The ones skipped are the ones that tend to produce the surprises.

Why One Technique Is Never Enough

No single identification technique reaches the full risk landscape. Each technique surfaces a different type of risk, from a different part of the project, through a different channel. Teams that rely on one method, usually a group brainstorm, consistently miss the risks that specialists know and that individuals will not raise in a group. Using multiple techniques across a planning cycle is not redundant. It is how you close blind spots that a single approach cannot reach.

Brainstorming — Getting It Out of People's Heads

A structured brainstorm with the core team is the fastest way to surface a large volume of risks in a short time. "Structured" is the key word. Asking the open question "what could go wrong?" produces a list dominated by the same three concerns the team always worries about. Using the risk category table above to frame the conversation produces more targeted responses and directs attention to areas the group might otherwise skip. The limitation of any group session is groupthink. Participants self-censor when the project manager is in the room and has already expressed optimism about the schedule. Strong performers who see risks clearly may stay quiet rather than be seen as obstructionist. Brainstorming captures the risks people are willing to name publicly. It will consistently miss the risks they are not.

Expert Interviews — What Groups Do Not Say

One-on-one interviews with subject matter experts surface concerns that do not emerge in group settings. A security specialist asked privately about the new building's access control design will give a different answer than the same person in a planning meeting with the project sponsor present. Individual conversations also allow deeper focus on a specific risk domain than a group session permits. For the RtR project, that meant separate conversations with the IT lead about infrastructure risks, with the facilities manager about site preparation, with the security vendor about installation risks, and with operations management about service continuity during the transition. Each conversation reached a different part of the risk landscape. The goal is not to hold separate sessions for every topic but to recognize when a risk domain requires specialized knowledge that a general group session will not reach.

Assumption Analysis — Every Assumption Is a Risk in Waiting

The project plan rests on assumptions: the resource assumed to be available, the vendor assumed to hold pricing through the project, the regulatory environment assumed to remain stable. Each assumption is invisible pressure on the plan. Assumption analysis takes the assumptions documented in the charter and planning documents and asks a structured question for each one: what if this proves wrong? A resource assumed to be available at 50% who turns out to be at 10% is not a surprise. It is an unvalidated assumption that became a risk and then became an issue before anyone noticed the transition. The RAID log formalizes this: each assumption gets a named owner and a validation date. Assumptions that are confirmed are no longer assumptions. Assumptions that look unstable become risks to manage. Assumptions that have already failed and are affecting the project become issues to resolve, not risks anymore but active problems requiring an owner and a resolution plan.

Lessons Learned — The Organization's Memory

Post-mortems and lessons learned logs from previous projects are a concentrated source of identified risks. If the last three office relocations in your organization all experienced scope disputes with facilities management over IT infrastructure cutover responsibility, that dispute is not a possibility on the current project. It is a near-certainty. Treating it as a documented, managed risk is different from discovering it mid-project when it has already escalated into a conflict. Organizations that maintain lessons learned repositories reduce risk identification effort while improving coverage simultaneously. If no formal repository exists, the risk register from a recently completed similar project serves the same function for the team that ran it. Use what has already been learned rather than paying to discover it again.

Building the Risk Register

Identified risks need a home. The risk register is where every risk lives from the moment it surfaces through the end of the project. It is not just a list. It is a structured working document that tracks each risk through identification, analysis, response planning, and monitoring. A register populated once and filed is not risk management. It is record-keeping. The fields below are what make a risk register functional rather than decorative.

Not every field is completed when a risk is first identified. The register fills in progressively as the team moves through analysis and response planning. At identification, the priority is capturing a clear risk description, its category, and a preliminary probability and impact rating, enough to determine whether the risk needs immediate attention or can wait for the next scheduled review.

Scoring Risks — Probability and Impact

Once a risk is identified, it needs to be prioritized. The mechanism is probability times impact. A risk rated High probability and High impact sits at the top of the register and demands a substantive response. A risk rated Low probability and Low impact can be noted and accepted without consuming response resources. The probability-impact matrix makes the priority zones visual.

Calibrating the scale to the project's actual stakes is as important as using the matrix. For a $368,000 relocation project, a High impact rating might mean a delay of more than two weeks or a cost increase above $25,000. For a $10 million infrastructure program, those same figures represent minor impact. Without shared definitions, one team member's High is another's Medium, and the register loses its ability to drive prioritization. Before the first risk is scored, the team should agree in writing on what High, Medium, and Low mean in concrete schedule days and dollar amounts for this specific project. The next chapter covers the full qualitative analysis process, including how to apply this matrix systematically across the complete register. At identification, the score is a triage signal only. It tells you what needs attention now, not where something will land after full analysis.

An Example from the RtR Risk Register

The three risks below were among the first identified in the RtR planning session. They illustrate how the same project, looked at through the category table, produces risks of very different types and priorities. For these scores, Low = 1, Medium = 2, and High = 3, so probability multiplied by impact produces a value from 1 to 9. The response strategy column is not yet filled in at identification. That work happens in risk analysis and response planning.

R-02 scores highest and correctly demands first attention. R-01 is an opportunity. For opportunities, impact means the size of the potential benefit, not the size of any harm. It warrants a planned response to increase the probability of realizing that benefit. R-03 was monitored and later closed when the regulatory announcement was withdrawn. All three came from deliberate category-based identification. None would have surfaced reliably in an unstructured group discussion.

The RAID Log — Four Categories, One Document

The risk register handles what is uncertain. Projects also accumulate other categories of structured information that need the same discipline: tracking, ownership, and regular review. The RAID acronym is not universal. Different organizations expand it as Risks, Actions, Issues, Dependencies or other combinations. This book uses Risks, Assumptions, Issues, and Decisions. What matters is that the project has one governed place for uncertainty, open problems, assumptions, and formal choices. The RAID log brings those four categories into one document and suits projects that prefer not to maintain multiple separate registers. On larger projects, these categories are often maintained as separate documents within a broader project management plan.

Assumptions are the conditions the plan treats as true without yet confirming them. The resource assumed to be available at 50%. The vendor assumed to hold current pricing. The regulatory environment assumed to remain stable for the project duration. Every assumption is invisible pressure on the plan. When one proves wrong, it typically produces a scope, schedule, or cost adjustment, and if the assumption was never documented, that adjustment reads as a surprise rather than the consequence of a known dependency. The RAID log gives each assumption a named owner and a validation date. Someone checks it at the agreed interval, confirms or flags it, and the log records the result. Assumptions that go untested become risks that go unmanaged.

Issues are events that have already materialized and need resolution now. A supplier who has confirmed they cannot deliver. A team member whose availability has been cut. A defect found during a pre-move test that must be resolved before the move date. Issues are not risks anymore. They are active problems requiring an owner, a resolution plan, a target date, and an escalation path if resolution falls through. An issue without an owner and a target date tends to expand quietly while the project records it as "under review."

Decisions are formal choices made during the project, particularly those with downstream consequences. Which vendor was selected and why. What the basis was for extending a milestone. Who authorized a scope change and on what date. Decisions that go undocumented become disputes when the people who made them move on or when a stakeholder who was not present challenges the outcome. The decision log is institutional memory with dates and names: not bureaucracy, but a record of what was chosen and why, available to anyone who needs to understand the project's history.

The table below shows a sample RAID log from the RtR project at the end of the planning phase. Each category is tracked in the same document, with a named owner and a clear status.

The practical test for whether a RAID log is worth maintaining is simple. If a key team member left mid-project, what would the next person need to find to understand what is currently uncertain, what is being assumed, what has gone wrong, and what has been decided? Whatever document answers that question is the one worth maintaining and reviewing at every governance checkpoint.

Risk Identification Does Not Stop at Planning

The identification session in planning is not a workshop you run once and check off the schedule. New risks surface throughout the project. When a vendor is selected, their specific constraints and communication patterns may reveal exposures the earlier plan could not see. When a team member leaves, their knowledge leaves with them. When an assumption is tested and proves false, it generates a new risk that belongs in the register immediately. Building risk identification into the regular team cadence, making it a standing question at every status meeting, is what keeps the register current and the team thinking ahead rather than reacting. What has changed? What risks does that change introduce? A risk register is not a historical artifact produced during planning. It is a live account of what the project is protecting itself from, updated as the project evolves.

What's Next

Risk identification produces a register of documented risks with preliminary scores. The next step is to analyze those risks systematically: prioritize them across the full register, distinguish which warrant active response resources, and in some cases build a quantitative picture of the project's combined risk exposure. Risk Analysis: Qualitative and Quantitative is the next chapter.

Reflect

• Think of a project where the risk list stayed focused on the obvious threats. Which category in the table above was most underrepresented? What would the team have found if they had worked through that category deliberately?
• How does your team currently handle the line between a risk and an issue? When a risk materializes, is there a documented owner with a ready response, or does the team improvise?
• Identify three assumptions in a project you are currently working on or have recently completed. For each one: who is responsible for validating it, and what would change in the plan if it proved wrong?
• When was the last time your team used lessons learned from a previous project to inform risk identification? If that step was skipped, what risks might the organization already have encountered once and paid for?
• What would a new team member joining your project mid-way need to find to understand what is currently uncertain, what is being assumed, what has gone wrong, and what has been decided? Does that document exist, and is it up to date?