ITS 835 Guide: Enterprise Risk Management vs Project Risk Management

How does the scope differ?

ERM looks across the enterprise. It considers interactions among strategic, operational, financial, technology, compliance, reputational, and other exposures that may affect enterprise objectives. Project risk management narrows attention to a temporary endeavor and the uncertainty surrounding its intended outputs and benefits. That narrower scope is not inferior; it is necessary for delivery discipline.

Problems arise when a student assumes that the same boundary answers both questions. A project risk register can be excellent for the project and still fail to show an enterprise concentration that appears across several initiatives. Conversely, an enterprise risk statement may be too broad to assign a specific project response. ITS 835 analysis should identify which boundary is being governed before choosing tools, owners, and evidence.

How do enterprise objectives differ from project objectives?

Enterprise objectives express the sustained results an organization is pursuing or protecting. They may concern mission, growth, resilience, service, stakeholder value, or long-term performance. Project objectives define what a particular initiative must deliver and the constraints within which delivery occurs. A project can contribute to an enterprise objective without being identical to it.

The distinction changes the risk statement. “Vendor delay may postpone system testing and the launch date” is framed around project delivery. “Dependence on one vendor across critical services may undermine enterprise continuity and bargaining capacity” is framed around enterprise exposure. Both can be valid, and the same underlying condition may support both. A strong student response names the objective level instead of treating the wording as a cosmetic difference.

Who owns the decisions and governance?

Project risks usually sit within project governance: a project manager, sponsor, workstream owner, steering group, or delivery authority decides how to respond within delegated limits. Enterprise risks require ownership at a level capable of balancing exposure across functions, objectives, and resources. That may involve executives, enterprise risk committees, boards, or accountable business leaders, depending on the organization.

Ownership is not simply the name beside a row. The owner needs authority to choose, fund, accept, escalate, or redirect action. When a project exposure exceeds delegated tolerance, the project should not quietly keep it inside the project register. It should move through an escalation path to the enterprise decision-maker. ITS 835 reasoning becomes clearer when it separates the person monitoring an issue from the person authorized to accept the resulting exposure.

How does the time horizon change the analysis?

A project has a planned beginning, sequence, and end, even when its product or benefit continues afterward. Project risk decisions therefore often follow milestones, delivery stages, dependencies, and handoffs. ERM usually persists across planning cycles and examines how uncertainty changes as strategy, markets, operations, capabilities, and stakeholder expectations evolve.

This difference affects monitoring. A schedule indicator may matter intensely during one implementation window and become irrelevant after handoff. An enterprise dependency, talent shortage, concentration, or regulatory exposure may outlast several projects. A student should identify whether the decision is temporary, recurring, or strategic, then choose evidence at the same horizon. Using a short project window to dismiss a longer enterprise exposure is a scope error, not merely a missing data point.

Why do aggregation and portfolio effects matter?

Individual projects can appear acceptable while their combined exposure exceeds what the enterprise can absorb. Several initiatives may depend on the same specialist team, supplier, platform, funding source, or change window. Each project register may record only its local portion; the enterprise view reveals concentration, correlation, and competition for response capacity.

Aggregation also works in the other direction. Enterprise leadership may decide that a strategic opportunity justifies coordinated exposure across a portfolio, while setting constraints for each project. This is why a project risk cannot always be evaluated only through its own probability and impact score. ITS 835 analysis should ask whether the exposure repeats elsewhere, shares a cause, creates cumulative consequences, or competes for the same control and recovery resources.

How do escalation and decision output differ?

Project risk management commonly produces delivery decisions: change the plan, assign an action, add contingency, alter scope, accept an exposure within authority, or escalate. ERM produces enterprise decisions: adjust strategy, rebalance resources, change appetite, strengthen governance, accept a portfolio exposure, redesign a dependency, or direct cross-functional treatment. The outputs overlap, but the authority and tradeoffs differ.

An escalation is useful only when it carries a decision question. Sending an enterprise committee a copy of a project register does not identify what leadership must decide. A stronger escalation names the objective, the exposure outside delegated limits, the alternatives, the consequence of delay, and the decision owner. This makes the connection between project evidence and enterprise governance visible.

The Enterprise-to-Project Risk Scope Map

The Enterprise-to-Project Risk Scope Map is a Domyclass diagnostic tool for deciding which lens should lead. It is not an official University of the Cumberlands or PMI framework. The map asks students to compare objective level, duration, ownership, aggregation, escalation, and intended output before choosing a risk register or recommendation structure.

A record can travel across the map. A project team may identify a vendor delay, manage its immediate schedule effect, and escalate the broader supplier concentration to enterprise leadership. The point is not to assign one permanent label; it is to place each decision with the governance level that can act.

What does the difference look like in a fictional example?

Consider a fictional manufacturer replacing warehouse systems at three sites. The first implementation project records a risk that testing may take longer than planned because a specialist team is shared with another initiative. The project owner can resequence work, protect test time, and maintain schedule contingency. Those are project decisions tied to delivery objectives.

At enterprise level, leadership sees that six transformation projects depend on the same small specialist group. A simultaneous demand spike could delay several strategic initiatives and weaken operational resilience. Enterprise leaders may fund additional capability, change portfolio sequencing, alter sourcing strategy, or accept the concentration for a defined period. The facts overlap, but the scope, owner, time horizon, aggregation, and decision output differ. This fictional example demonstrates reasoning and is not a completed ITS 835 submission.

What mistakes blur the two lenses?

One mistake is to call every project concern an enterprise risk because the project matters to the company. A second is to keep a cross-enterprise concentration inside one project because that is where it was first noticed. A third is to assign enterprise acceptance to a project manager who lacks that authority. A fourth is to use project schedule and cost measures as the only evidence for a strategic exposure. A fifth is to compare definitions without identifying the decision that changes when the lens changes.

The correction is to test scope explicitly: whose objective, which duration, what aggregation, which authority, and what output? The answers reveal whether project governance, enterprise governance, or a connected two-level response is required.

How should a student choose the correct lens?

Begin with the decision rather than the label. If the question concerns delivery of a temporary initiative within delegated authority, the project lens should probably lead. If it concerns enterprise strategy, combined exposure, sustained operations, or tradeoffs across functions and portfolios, ERM should lead. If a project condition could exceed enterprise appetite or reveal a shared concentration, explain both levels and the escalation between them.

Write separate objective statements for the project and enterprise. Identify the owner and authority at each level. State which evidence is local and which must be aggregated. End by naming the output expected from each decision-maker. Then verify that the structure fits current classroom instructions; the existence of this comparison does not establish that ITS 835 requires a particular comparison assignment.

Related ITS 835 resources

• ITS 835 Help: Enterprise Risk Management
• How do you turn a risk list into an enterprise risk register?
• ITS 835 Assignment Planning Guide: Risk Appetite, Tolerance, Controls, and Indicators