Skill This
AI Skill Report Card

Analyzing Project Risk

A-87·Sep 27, 2026·Source: Web
Quick Start14 / 15

Given a project description, produce four deliverables in order:

  1. Risk Matrix (likelihood × impact, categorized)
  2. Impact Analysis (what happens if each risk materializes)
  3. Mitigation Strategy (preventive actions)
  4. Recovery Plan (response if mitigation fails)

Example trigger: "Analyze the risks in this project plan" → run the full workflow below.

Recommendation▾
Add a third example showing a low-risk/simple project to demonstrate scaling down the framework, not just narrowing scope
Workflow14 / 15
Progress:
- [ ] Gather project context (scope, timeline, budget, stakeholders, tech stack)
- [ ] Identify risks across 4 categories: technical, operational, financial, governance
- [ ] Score each risk (Likelihood 1-5 × Impact 1-5 = Severity)
- [ ] Build Risk Matrix table
- [ ] Write Impact Analysis for high/critical risks
- [ ] Define Mitigation Strategy per risk
- [ ] Define Recovery Plan (triggers, actions, owner) per high/critical risk

Step 1: Gather Context

If the input lacks detail on scope, timeline, budget, team, or systems involved, ask minimal clarifying questions only if truly blocking — otherwise make reasonable assumptions and state them explicitly.

Step 2: Identify Risks by Category

  • Technical: architecture flaws, tech debt, integration failures, scalability limits, security vulnerabilities, tooling/dependency risk.
  • Operational: process gaps, resource/staffing shortfalls, vendor/supplier reliability, execution delays, communication breakdowns.
  • Financial: budget overruns, cash flow gaps, funding dependency, cost estimation errors, currency/market exposure.
  • Governance: unclear decision rights, compliance/regulatory gaps, stakeholder misalignment, lack of accountability, documentation/audit trail gaps.

Step 3: Score and Build Matrix

Use a 1–5 scale for Likelihood and Impact. Severity = Likelihood × Impact.

  • 1–6: Low
  • 7–14: Medium
  • 15–25: High/Critical

Step 4: Write Outputs

Follow the exact output format in Best Practices below.

Recommendation▾
Include a fully worked example with all four deliverables complete (not abridged) so Claude has a full reference output
Output Format
Markdown
undefined
Risk Matrix
IDCategoryRisk DescriptionLikelihood (1-5)Impact (1-5)SeverityRating
T1Technical...3412Medium
O1Operational...............
F1Financial...............
G1Governance...............
Impact Analysis

For each Medium+ risk: [ID] – [Risk Name]

  • Trigger conditions: ...
  • Immediate impact: ...
  • Downstream/cascading impact: ...
  • Affected stakeholders: ...
Mitigation Strategy

[ID] – [Risk Name]

  • Preventive action: ...
  • Owner: ...
  • Timeline: ...
  • Cost/effort estimate: ...
Recovery Plan

[ID] – [Risk Name]

  • Trigger (when to activate): ...
  • Immediate response: ...
  • Responsible party: ...
  • Fallback/contingency budget or resource: ...
  • Post-incident review requirement: yes/no
Examples15 / 20

Example 1: Input: "MusGo is building a ride-hailing app MVP, launching in 3 months with a 5-person team and a $50k budget, relying on a third-party payment gateway."

Output (abridged):

| ID | Category | Risk | Likelihood | Impact | Severity | Rating |
|----|----------|------|-----------|--------|----------|--------|
| T1 | Technical | Third-party payment gateway API instability | 3 | 5 | 15 | High |
| O1 | Operational | 5-person team insufficient for 3-month scope | 4 | 4 | 16 | High |
| F1 | Financial | Budget overrun from scope creep | 3 | 4 | 12 | Medium |
| G1 | Governance | No formal change-approval process | 4 | 3 | 12 | Medium |

Followed by Impact Analysis, Mitigation Strategy, and Recovery Plan sections for T1 and O1 (the High risks), each with owner, trigger, and fallback defined.

Example 2: Input: "Assess governance risk only for a nonprofit's new donor data platform." Output: Risk Matrix limited to Governance category (e.g., unclear data ownership, missing privacy compliance sign-off, no board oversight of vendor contract), with full Impact/Mitigation/Recovery sections — other categories omitted since scope was explicitly narrowed.

Recommendation▾
Clarify how to handle risks that score exactly at category boundaries (e.g., 6 vs 7) to avoid inconsistent rating decisions
Best Practices
  • Always score every risk numerically — never use vague labels like "high" without the Likelihood × Impact basis.
  • Prioritize Impact Analysis and Recovery Plans for Medium-severity-and-above risks only; low risks get one-line mitigation notes to save space.
  • State assumptions explicitly when project context is incomplete.
  • Assign a named owner or role (not "the team") to each mitigation/recovery action.
  • Keep recovery plans actionable: trigger condition → action → owner → resource, not generic advice.
  • Cross-check for risks that span categories (e.g., a vendor failure is both operational and financial) — list once, tag primary category, note secondary in description.
Common Pitfalls
  • Don't list risks without scoring — an un-scored risk matrix is not usable for prioritization.
  • Don't conflate mitigation (preventive) with recovery (reactive) — keep them in separate sections.
  • Don't skip governance risk just because a project seems purely technical — decision rights and accountability gaps exist everywhere.
  • Don't produce generic, boilerplate risks ("scope creep," "team leaves") without tying them to the specific project details given.
  • Don't omit an owner/responsible party in mitigation or recovery — unassigned actions won't get executed.
0
Grade A-AI Skill Framework
Scorecard
Criteria Breakdown
Quick Start
14/15
Workflow
14/15
Examples
15/20
Completeness
18/20
Format
15/15
Conciseness
14/15
Save to My Skills