An individual project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives. This definition comes from the Project Management Institute and it captures the two-sided nature of risk in project management. Unlike the ordinary use of the word risk as something bad, in projects an individual risk can be either a threat that harms objectives or an opportunity that helps them. The word individual matters because it distinguishes one specific risk from the total uncertainty surrounding a project as a whole.
Risk appears constantly in project work because projects are temporary, unique, and built on assumptions about the future. A team may plan for a supplier to deliver on a certain date, but that delivery is not guaranteed. A software module may be expected to handle a given load, but the real performance may differ. These are individual risks. They can be named, described, assigned, analyzed, and managed. That specificity is what makes individual project risk a practical unit of management rather than a vague feeling of unease.
Individual Project Risk: Key Topics Summary
| Key Concept |
Summary |
| Individual Risk Definition |
An individual project risk is a specific, identifiable event or condition that may or may not materialize; its potential impact makes it distinct from everyday uncertainty. |
| Threat and Opportunity |
Project risk carries a neutral meaning: it can be a threat that harms objectives or an opportunity that improves them, contrary to the common negative connotation of risk. |
| Persistent Nature of Risk |
Risk is inherent in project work because every project is temporary, unique, and developed around assumptions and forecasts that may not hold. |
| Cause, Event, and Effect |
A well-formed risk statement links cause, event, and effect in a causal chain. For example, contention for a shared testing environment can delay release testing, producing an estimated two-week schedule slip. |
| Risk versus Issue |
Maintaining a clear distinction is essential because risks can be avoided, mitigated, transferred, or accepted before they materialize; in practice, teams often blur this line by treating risks as current problems. |
| Expected Value Limitations |
Expected value is calculated as probability multiplied by impact, but it should be treated as a decision aid rather than a precise forecast, especially when probability and impact estimates are approximate. |
| Risk Register Data Fields |
For each individual risk, the register typically captures the risk statement, category, probability, impact, score, assigned owner, response plan, and trigger conditions to support monitoring and control. |
| Root Cause Response |
Understanding cause, event, and effect prevents misdirected responses. For example, adding expediting effort is ineffective when the root cause is a single overloaded supplier, not a lack of coordination. |
What Is Individual Project Risk?
The individual project risk definition used in project management is narrower than the general idea of risk: it refers to a specific, identifiable event or condition that may or may not happen. If the event happens, it changes at least one project objective such as scope, schedule, cost, or quality. The condition may be something that already exists in the environment, such as a limited pool of qualified specialists, but its effect on the project remains uncertain until it materializes as a problem or advantage.
This distinction between risk and issue is fundamental. A risk is something that has not yet occurred. An issue is something that is already happening or is certain to happen. A delayed permit that is currently overdue is an issue. The possibility that the permit will be delayed next month is a risk. In practice teams often blur this line, but the separation matters because risks can be avoided, reduced, transferred, or accepted before they become issues.
The individual risk concept also contains a deliberate neutrality. It includes both negative and positive possibilities. A negative risk, or threat, might be a critical team member resigning. A positive risk, or opportunity, might be a new technology reducing production time if adopted early enough. Both require identification and response. Treating opportunity as a legitimate form of risk is a distinguishing mark of mature project risk management.
Key Takeaways on Individual Project Risk
- Narrow, Specific Definition
- Individual project risk refers to an identifiable event or condition that may or may not occur, with the potential to affect at least one project objective, including scope, schedule, cost, or quality.
- Risk Versus Issue
- A risk represents uncertainty that may or may not materialize, whereas an issue is already occurring or certain to occur; this distinction matters because risks can be avoided, reduced, transferred, or accepted before they turn into issues.
- Threats and Opportunities
- Risks can be negative threats, such as the resignation of a critical team member, or positive opportunities, such as adopting a new technology early to reduce production time, and treating opportunities as legitimate risks is a hallmark of mature risk management.
Key Components of Individual Project Risk
The key components of individual project risk include probability, impact, cause, event, effect, and ownership. Each component works together to turn a vague concern into a manageable item. Probability describes how likely the risk is to occur. Impact describes the extent of the effect on objectives if it does occur. Cause is the underlying fact or situation that gives rise to the risk. The event is the uncertain occurrence itself. The effect is what the event does to the project. Ownership assigns a person responsible for monitoring and responding.
When a risk statement is well formed, it separates these elements clearly. A weak risk statement says something like "the project may be late." A stronger risk statement connects cause, event, and effect: because the specialized testing environment is shared with another program, the release may be delayed, causing a two-week schedule slip. This is often called risk metalanguage. The event is the uncertain part. The cause is already true or likely to become true. The effect is what happens to the project if the event occurs.
Probability and Impact
Probability and impact are the two dimensions that make individual risks comparable. They allow a team to rank risks and decide which ones deserve the most attention. Qualitative analysis uses descriptive scales such as very low to very high. Quantitative analysis may use percentages and monetary values. The product of probability and impact is sometimes called expected value, but practitioners should be cautious about treating expected value as a precise forecast when the underlying estimates are rough.
For an individual risk, probability and impact are assessed separately from other risks. This is where many teams struggle. A project may have many small risks that individually seem insignificant but collectively create large exposure. The individual risk view does not replace that aggregate view. It complements it. The individual level supports decisions about single responses. The aggregate level supports decisions about contingency reserves and overall project feasibility.
Risk Causes, Events, and Effects
Understanding cause, event, and effect prevents misdirected responses. If a team responds to the effect instead of the cause, the underlying driver remains active. For example, if late deliveries are caused by a single overloaded supplier, responding by adding more expediting effort may treat the symptom. Responding by qualifying a second supplier treats the cause. The cause-event-effect structure also reduces confusion about what exactly the risk owner is watching.
Some risks have multiple causes. Some causes produce multiple risks. This interconnectedness is normal. An individual risk is not isolated from the project system. Its probability may increase because another risk occurs first. Its impact may be amplified by a weak project control process. Recognizing these connections helps avoid treating the risk register as a collection of disconnected entries. The individual risk remains the unit of management, but the relationships around it matter.
Risk Ownership and the Risk Register
The risk register is the primary artifact for recording individual risks. It contains the risk statement, probability, impact, risk score, response strategy, and residual risk after response. It also contains the risk owner. The risk owner is the person accountable for monitoring the risk and ensuring the agreed response is carried out. The owner is not necessarily the person who will do all the work. The owner may coordinate others, escalate when needed, and report on changes in the risk profile.
Without ownership, individual risks often sit in a register and go stale. A named owner creates accountability. This does not mean the owner personally controls every factor. In many cases the owner cannot control the cause at all. But the owner can watch for triggers, maintain the response plan, and alert the project manager when the risk changes. This is a management function, not a technical guarantee.
Types and Categories of Individual Project Risk
The types of individual project risk are commonly split into threats and opportunities, and then further categorized by source. Common source categories include technical, management, commercial, and external risks. Technical risks include design errors, unproven technology, or integration failures. Management risks include poorly defined roles, inadequate communication, or resourcing conflicts. Commercial risks include supplier insolvency, price changes, or contract disputes. External risks include regulatory changes, weather, or political instability.
These categories are often arranged in a risk breakdown structure. A risk breakdown structure groups risks hierarchically to show where exposure is concentrated. It plays a similar role for risk that the work breakdown structure plays for scope. It can expose patterns that remain hidden when risks are listed randomly. If a project has many risks in the external category, the response strategy may need to emphasize monitoring and contingency rather than direct control.
Opportunities also come in different types. An opportunity may reduce cost, shorten duration, improve quality, or enhance reputation. They are not simply mirror images of threats. Opportunities often require proactive effort to capture. A risk that a vendor may offer a discount is not the same as a guaranteed discount. The project team must create the conditions for the opportunity to be realized, such as negotiating early or adjusting order volumes.
Key Insights on Categorizing Project Risk
- Threats and Opportunities Split
- Individual project risks are first classified as either threats or opportunities, but opportunities such as lower cost, shorter duration, or better quality materialize only when the team actively creates favorable conditions, such as negotiating supplier terms early or adjusting order volumes.
- Four Main Source Categories
- Grouping risks by source into technical, management, commercial, and external categories helps teams see the full range of exposure, from design errors, unclear roles, and contract disputes to regulatory shifts, adverse weather, and political instability.
- Risk Breakdown Structure Shows Concentration
- A risk breakdown structure arranges risks hierarchically to reveal where exposure is concentrated, and a project with many external risks should therefore rely on monitoring and contingency reserves rather than attempt direct control.
Individual Project Risk in PMBOK and PRINCE2
The treatment of individual project risk PMBOK and PRINCE2 share a structured emphasis, though the terminology and process details differ. PMBOK treats individual risk within the Project Risk Management knowledge area. PRINCE2 treats risk as one of its seven themes. Both frameworks require risks to be identified, assessed, planned for, and monitored throughout the project. Both distinguish between the individual risk and the overall risk exposure of the project.
Individual Project Risk in the PMBOK Framework
Within the PMBOK framework, individual risks are handled through a set of processes. Plan Risk Management defines how risk activities will be conducted. Identify Risks produces the initial list of individual risks. Perform Qualitative Risk Analysis prioritizes them by probability and impact. Perform Quantitative Risk Analysis numerically analyzes the combined effect of individual risks on objectives. Plan Risk Responses selects strategies for each priority risk. Implement Risk Responses carries out those strategies. Monitor Risks tracks changes and evaluates response effectiveness.
The risk register is updated throughout these processes. For each individual risk, the register typically records the risk statement, category, probability, impact, score, owner, response plan, and trigger conditions. Triggers are early warning indicators that a risk is about to occur. A trigger for a supplier risk might be a missed progress report. A trigger for an opportunity might be a regulatory decision opening a new market. Triggers make monitoring concrete.
Individual Project Risk in PRINCE2
PRINCE2 defines risk as an uncertain event or set of events that, should it occur, will have an effect on the achievement of objectives. The risk theme requires a risk management procedure with five steps: identify, assess, plan, implement, and communicate. The risk register in PRINCE2 holds individual risks and includes fields for probability, impact, proximity, risk response, risk owner, and risk actionee. Proximity indicates how soon the risk might occur, which helps prioritize near-term risks over distant ones.
PRINCE2 also introduces the concept of a risk budget. A risk budget is a sum of money set aside to fund specific risk responses. It is not the same as a contingency reserve, although in practice they can overlap. The risk budget pays for responses such as additional testing, insurance premiums, or fast-tracking activities. Individual risks that require money to manage can draw from this budget when the response is approved. This makes the cost of risk responses visible to the project board.
Individual Project Risk in Agile, Hybrid, and Predictive Environments
The management of individual project risk in agile environments takes a different outward form, but the underlying concept remains. Agile teams often do not maintain a formal risk register in the same way predictive teams do. Instead, risks are discussed during sprint planning, daily stand-ups, backlog refinement, and retrospectives. A risk that might delay a future sprint becomes visible as a dependency, a technical uncertainty, or a capacity concern. The team treats it as a backlog item or a spike if deeper investigation is needed.
In a predictive environment, individual risks are usually identified during early planning and reviewed at regular risk reviews. In hybrid environments, the approach may combine a lightweight risk register with frequent team conversations. A hybrid project might keep a simple risk list for external supplier risks while handling technical risks within the agile delivery cadence. The key is that individual risks are not ignored simply because the project uses an adaptive method.
Agile methods also create opportunities. Short iterations provide rapid feedback that can reveal a better design choice. An early integration spike may uncover a performance improvement that reduces later work. These are positive individual risks. The agile principle of welcoming changing requirements, when combined with risk awareness, can convert uncertainty into value rather than treating all change as disruption.
Key Takeaways on Individual Risk by Environment
- Agile Risks Live in Ceremonies
- Agile teams typically rely on recurring ceremonies rather than a formal risk register, using sprint planning, daily stand-ups, backlog refinement, and retrospectives to surface individual risks as they emerge.
- Risk Becomes a Backlog Item
- A risk that could affect a future sprint is usually expressed as a dependency, a technical uncertainty, or a capacity concern; it is then tracked as a backlog item, or as a spike when deeper investigation is required.
- Predictive and Hybrid Contrasts
- In predictive projects, individual risks are typically identified during early planning and revisited in scheduled risk reviews, whereas hybrid projects often pair a lightweight risk register for external supplier risks with frequent team discussions about technical uncertainties.
- Adaptive Methods Still Manage Risk
- Individual risks are not ignored under adaptive methods; pairing the agile commitment to welcoming changing requirements with explicit risk awareness can turn uncertainty into value rather than treating all change as disruption.
BVOP Perspective on Individual Project Risk
In BVOP, BVOP product risk management separates product risks from project risks and uses quantified loss size units to evaluate risk exposure. The approach also applies dynamic filtering to individual risks so that only currently relevant risks receive active attention. When def
Purpose and Importance of Individual Project Risk
The purpose and importance of individual project risk lies in converting broad uncertainty into discrete, actionable items. A project manager cannot manage all uncertainty at once. But a project manager can manage a specific supplier delay, a specific integration failure, or a specific regulatory change. Individual risks provide that granular focus. They allow teams to decide who will do what, when, and with what resources before the risk occurs.
Individual risk management also improves communication. When a risk is named and described clearly, stakeholders can discuss it without vague language. A sponsor may not understand a general statement that the project feels risky. The same sponsor can understand a specific risk that a critical permit may take six weeks instead of four, endangering the construction start date. This specificity makes risk conversations more useful for decision making.
Another important purpose is prioritization. Not all individual risks deserve the same level of attention. By assessing probability and impact, the team can separate high-priority risks from low-level ones. This avoids the common failure of trying to manage every risk equally. A project may have dozens of identified risks, but only a handful usually carry enough exposure to justify significant time or money. The individual risk concept enables that ranking.
Key Takeaways on Making Risk Actionable
- Converting Uncertainty into Action
- Individual project risks turn broad uncertainty into specific, manageable items that a project manager can actively monitor, assign, and control.
- Granular Focus Enables Ownership
- Naming individual risks provides the level of detail teams need to assign clear ownership, define concrete actions, establish timing, and allocate resources before a risk materializes.
- Specificity Improves Stakeholder Dialogue
- Clearly named and described risks eliminate vague language, enabling stakeholders to hold focused, productive conversations and make sharper decisions.
- Concrete Examples Drive Understanding
- A sponsor may dismiss a general statement that a project feels risky, yet will immediately grasp that a critical permit could take six weeks rather than four and put the construction start date at risk.
- Probability and Impact Set Priorities
- Assessing probability and impact separates high-priority risks from minor ones, because typically only a few of the many identified risks carry enough exposure to warrant meaningful time, attention, or budget.
Practical Application of Individual Project Risk
The individual project risk analysis process appears in many real project settings. In a construction project, a team may identify the risk of a concrete pour being delayed by rain. The risk owner monitors weather forecasts and establishes a trigger for moving the pour indoors. In a software project, a team may identify the risk that a third-party authentication service will be unavailable during launch week. The response may include a fallback authentication method. In both cases, the individual risk is specific enough to trigger a prepared action.
Risk identification usually begins early in the project but continues throughout. The first risk identification workshop often produces a long list of risks, many of which are duplicates or poorly defined. Facilitators use the cause-event-effect structure to sharpen weak statements. The project manager assigns owners and ensures each risk has a response before it moves into the monitoring phase. This is not a one-time exercise. New risks emerge as design decisions are made, contracts are signed, and the environment shifts.
Risk Identification and the Risk Register
The risk register is the central repository for individual risks. It can be a spreadsheet, a database, or a module in a project management information system. The register is not a static document. It should be reviewed at defined intervals, such as weekly for high-priority risks and monthly for lower-priority ones. During risk reviews, owners report whether the risk probability or impact has changed, whether triggers have fired, and whether responses remain effective.
A practical risk register also records residual risk and secondary risk. Residual risk is what remains after the response is implemented. If a team reduces the probability of a supplier delay by qualifying a second supplier, some residual risk still exists because the second supplier may also fail. Secondary risk is a new risk created by the response itself. Qualifying a second supplier may create a secondary risk of increased administrative overhead. Good practice acknowledges these secondary effects rather than pretending responses are perfect.
Qualitative and Quantitative Risk Analysis
Qualitative risk analysis assigns relative ratings to individual risks. This is the most common approach because it is fast and does not require precise data. A team may rate a risk as high probability and high impact, medium probability and medium impact, or any other combination. The resulting risk score places the risk on a priority list. Qualitative analysis is useful for filtering the risk register, but its limitations should be understood. Words like high and low mean different things to different people.
Quantitative risk analysis uses numerical methods to estimate the combined effect of individual risks. Monte Carlo simulation, decision tree analysis, and sensitivity analysis are common techniques. These methods can produce a probability distribution for project duration or cost. The individual risks feed into the model with their probability and impact ranges. The output supports decisions about contingency reserves and major scope trade-offs. Quantitative analysis is more rigorous but also more time-consuming, so it is usually reserved for high-stakes projects.
Common Challenges, Pitfalls, and Misconceptions
One of the most persistent common misconceptions about individual project risk is that risk means only negative events. This misconception leads teams to miss opportunities. A project that can be shortened or a cost that can be reduced through a favorable exchange rate fluctuation is a real risk that should be managed. When teams ignore positive risks, they leave value on the table. A mature risk culture actively scans for both threats and opportunities.
Another common misconception is that the risk register is an administrative burden. In poorly run projects, the risk register becomes a list of vague worries that nobody updates. In well-run projects, it is a focused tool with a limited number of actionable entries. The problem is not the register itself. It is the lack of discipline in maintaining it. If every risk has an owner and a trigger, the register becomes a working management instrument rather than a compliance artifact.
A subtler pitfall is confusing individual risk with overall project risk. A sponsor may ask how risky the project is. The answer requires an aggregate view of all individual risks, their correlations, and the project's capacity to absorb variation. Listing individual risks does not answer that question. Individual risk management informs the overall risk assessment but does not replace it. Both levels are necessary for sound governance.
Over-precision is another challenge. Teams sometimes assign numerical probabilities such as 37 percent to risks that cannot be estimated with that accuracy. This creates an illusion of certainty. In most projects, a rating of low, medium, or high is more honest than a false decimal point. Quantitative methods have their place, but they should be used when the data and time justify them. Otherwise the risk numbers become a form of false confidence.
Key Takeaways on Risk Misconceptions
- Risk Is Not Only Negative
- The most persistent misconception is that risk refers only to adverse events, which leads teams to overlook opportunities that could shorten schedules, reduce costs, or improve delivery quality.
- Ignoring Upside Leaves Value
- When teams fail to manage positive risks such as favorable exchange rate movements or early supplier availability, they leave measurable value unrealized.
- Risk Register as Burden Myth
- A related misconception frames the risk register as an administrative burden, when in practice it should serve as a concise, action-oriented tool with a small number of high-value entries.
- Owners and Triggers Matter
- Assigning an owner and an observable trigger to each risk transforms the register into an active management instrument rather than a compliance artifact, supported by an aggregate view of correlations and the capacity to absorb variability.
Relationship to Other Project Management Concepts
The relationship between individual project risk and overall project risk is central to understanding both concepts. Individual risks are specific uncertainties. Overall project risk is the effect of uncertainty on the project as a whole. Many individual risks may combine to create overall risk. The relationship is not simple addition because some risks offset each other and some affect multiple objectives. A project can have many low individual risks but still carry significant overall risk due to correlation or systemic weakness.
Individual project risk connects closely to the assumptions log. Many risks arise from assumptions that may prove false. If a plan assumes that a key resource will be available in March, the possibility that the resource is not available is an individual risk. Tracking assumptions and risks together prevents gaps. The issue log is also related. When a risk occurs, it becomes an issue and moves from the risk register to the issue log. This transition should be explicit so that the same problem is not tracked in two places with different owners.
Contingency reserve is another related concept. The contingency reserve is a budget or schedule buffer set aside for identified risks that may occur. Individual risks with known probabilities and impacts inform the size of the reserve. Management reserve, by contrast, covers unidentified risks or unforeseen work outside the agreed scope. The distinction between individual risks and management reserve is important for governance. Spending contingency on known risks is expected. Accessing management reserve usually requires higher-level approval.
Evolution and Current Thinking in Individual Project Risk Management
The current thinking on individual project risk has moved toward integration with broader project and organizational processes. Early project risk management often focused on separate risk reviews and static registers. Modern practice embeds risk discussion into regular project rhythm, portfolio reviews, and benefit management. The individual risk is still the core unit, but it is now seen as part of a wider system of uncertainty, assumptions, dependencies, and value drivers.
The PMBOK Guide seventh edition reflects this evolution by shifting from process groups to performance domains. Risk is addressed in the Uncertainty Performance Domain. The language still recognizes individual risks and overall risk, but the emphasis is on understanding uncertainty in all its forms. This broader view encourages teams to consider ambiguity, complexity, and volatility alongside traditional event-based risks. Event-based individual risks remain important, but they are not the whole story.
Human factors have also gained attention. Risk perception varies by stakeholder. What one engineer sees as a moderate technical risk may look catastrophic to a sponsor unfamiliar with the technology. Effective risk communication requires translating individual risk assessments into language that each stakeholder can interpret. This does not mean changing the facts. It means explaining the risk in terms of its effect on the objective that matters most to that audience.
Current practice also recognizes that risk management is only as good as the behavior around it. A team that hides bad news will not produce useful risk data. A project manager who punishes risk identification will soon stop hearing about risks. Creating psychological safety is therefore a real part of individual risk management. The tools and registers are simple. The culture that makes people willing to surface uncertain bad news is much harder to build and much more valuable.
The evolution of individual project risk management continues to blend formal process with adaptive behavior. The concept has proven durable because it gives teams a practical way to act on uncertainty. It does not promise certainty. It provides a structure for naming, assessing, and responding to the specific things that might go wrong or right. That is why individual project risk remains one of the foundational ideas in project management practice.
Key Takeaways on Risk Management Evolution
- From Static Registers to Integration
- Project risk management has moved from isolated risk reviews and static registers to continuous integration with the regular project cadence, portfolio reviews, and benefits realization.
- Individual Risk in a Wider System
- The individual risk remains the core unit of analysis, yet it is now evaluated within a broader system of uncertainty, assumptions, dependencies, and value drivers.
- Broader Uncertainty and Stakeholder Communication
- Modern practice, as reflected in the PMBOK Guide Seventh Edition Uncertainty Performance Domain, embraces ambiguity, complexity, and volatility while requiring risk assessments to be translated into language each stakeholder can interpret.
Key Distinctions & Clarifications
Individual Project Risk vs. Overall Project Risk
Individual project risk is often confused with overall project risk, but they operate at different levels. An individual project risk is a specific uncertain event or condition that, if it occurs, affects one or more project objectives. Overall project risk is the exposure of stakeholders to the implications of variation in project outcome, driven by all sources of uncertainty together.
The key difference is that individual risks are discrete items that can be named, assigned, and managed, while overall risk is an aggregate view of uncertainty that emerges from many individual risks, estimating variability, ambiguity, and assumption sensitivity. For example, a named supplier delay on a critical component is an individual risk. The broader chance that the whole project finishes late because of supplier delays, estimating errors, resource constraints, and market shifts is overall project risk.
This distinction matters because response strategies differ. An individual risk can be avoided, transferred, mitigated, or accepted by its risk owner. Overall project risk is managed through project reserves, contingency, schedule buffers, and strategic decisions about scope, schedule, and budget.
Treating a single risk as the whole project risk can lead to overconfidence, while treating overall risk as a list of individual risks can obscure systemic exposure.
Boundary Conditions: When Event-Based Risk Does Not Apply
The individual project risk model assumes that uncertainty can be broken into discrete events or conditions with assessable probability and impact, but this assumption has limits. It does not apply well to general variability that is embedded in estimates, such as an activity duration that may vary continuously within a range. Unless that variability is decomposed into named risk events, it remains a source of overall project risk rather than an individual risk.
The model also breaks down for ambiguity about the project scope, requirements, or success criteria, where the uncertainty is about what the project is trying to achieve rather than whether a specific event will occur. Emergent unknowns, sometimes called unknown unknowns, cannot be identified in advance as individual risks because the events themselves are not foreseeable. In highly novel or complex projects, forcing all uncertainty into a risk register can create false precision and may distract from systemic or structural uncertainty.
The concept also does not apply to issues, constraints, or facts. A fixed deadline or a known regulatory requirement is not an individual risk. A problem that has already occurred is an issue.
Additionally, if a stated risk cannot be assigned to an owner or linked to a possible effect on objectives, it may be a general concern rather than a manageable individual risk.
Common Misinterpretations: Negative-Only Risk and Risk-Issue Confusion
A persistent misunderstanding is that individual project risk refers only to negative events. Misinterpretation: risk is a threat or a bad outcome. Fact: in project management, an individual project risk can be either a threat that harms objectives or an opportunity that improves them.
The Project Management Institute definition explicitly includes positive and negative effects. An opportunity such as a new material that could shorten the schedule, or a vendor offering a discount for early payment, is just as much an individual risk as a delay or cost overrun, for which teams may prepare contingency plans. Another common misconception confuses risk with issue.
Misinterpretation: a risk is a problem that the team is currently facing. Fact: a risk is an uncertain future event or condition, while an issue is something that has already occurred or is certain to occur. The possibility that a permit will be delayed next month is a risk; a permit that is already overdue is an issue.
This distinction is not just semantic because risks can be avoided, reduced, transferred, or accepted before they become issues. Once an issue exists, the team must apply corrective action or workarounds. Teams that call current problems risks often fail to move from planning to problem solving, while teams that treat every future concern as an issue may expend effort on things that never happen.
Relationship to Risk Register, Risk Owner, and Issue Management
Individual project risk is embedded in a set of related project management tools and processes. In the risk management process, individual risks are identified, recorded, and tracked in a risk register, sometimes called a risk log. Each entry typically includes a risk identifier, description, cause, event, effect, probability, impact, risk owner, and planned response.
The risk owner is the person accountable for monitoring the risk and implementing the response strategy. Response strategies for threats include avoid, transfer, mitigate, and accept, while strategies for opportunities include exploit, share, enhance, and accept; alternatives analysis can support selecting the right approach. Individual risks can be organized with a risk breakdown structure, which categorizes sources of risk by technical, external, organizational, and project management areas.
The concept also connects to the issue log. When an individual risk occurs, it becomes an issue and should be moved from the risk register to the issue log for active resolution. Assumptions and constraints are closely related: an assumption that may prove false can be recorded as an individual risk, while a constraint that may change can also be treated as a risk if its change is uncertain.
Together these tools turn the abstract idea of uncertainty into concrete items that can be assigned, tracked, and closed.
