# Change Risk Explanation

> Generate change request risk explanations analyzing change scope, affected CIs, historical change failure rates, and deployment window risks

- Skill: `happy-technologies-llc/change-risk-explanation` (Agent Skill)
- Install (CLI): `npx skillmds@latest add happy-technologies-llc/change-risk-explanation`
- Raw SKILL.md: https://api.skillmd.com/api/skills/happy-technologies-llc/change-risk-explanation/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: Happy-Technologies-LLC (https://skillmd.com/u/happy-technologies-llc)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/happy-technologies-llc/change-risk-explanation

---


# Change Risk Explanation Generation

## Overview

This skill covers generating comprehensive risk explanations for ServiceNow change requests:

- Analyzing change scope to assess breadth of impact (number of CIs, services, users affected)
- Evaluating affected configuration items and their criticality tiers
- Calculating historical change failure rates for similar changes and affected CIs
- Assessing deployment window risks including timing, maintenance windows, and business cycles
- Generating human-readable risk narratives for CAB review and approval workflows
- Providing risk mitigation recommendations based on identified risk factors

**When to use:** When preparing change requests for CAB review, when automated risk assessment needs human-readable explanations, when change managers need to justify risk ratings, or when stakeholders request risk impact summaries.

## Prerequisites

- **Roles:** `change_manager`, `itil`, or `admin`
- **Plugins:** `com.snc.change_management` (Change Management), `com.snc.cmdb` (CMDB)
- **Access:** Read access to `change_request`, `task_ci`, `cmdb_ci`, `cmdb_rel_ci` tables
- **Data:** Change request with populated CI relationships and change plan
- **Related Skills:** `itsm/change-management` for change lifecycle, `cmdb/impact-analysis` for CI impact analysis

## Procedure

### Step 1: Retrieve Change Request Details

Pull the change request record with all risk-relevant fields.

**MCP Approach:**
```
Tool: SN-Get-Record
Parameters:
  table_name: change_request
  sys_id: [CHG_SYS_ID]
  fields: sys_id,number,short_description,description,type,category,risk,impact,priority,state,start_date,end_date,planned_start_date,planned_end_date,change_plan,backout_plan,test_plan,assignment_group,assigned_to,requested_by,cmdb_ci,business_service,risk_impact_analysis,conflict_status,conflict_last_run,cab_required,scope,implementation_plan
```

**REST Approach:**
```
GET /api/now/table/change_request/[CHG_SYS_ID]
  ?sysparm_fields=sys_id,number,short_description,description,type,category,risk,impact,priority,state,start_date,end_date,planned_start_date,planned_end_date,change_plan,backout_plan,test_plan,assignment_group,assigned_to,cmdb_ci,business_service,risk_impact_analysis,scope
  &sysparm_display_value=true
```

### Step 2: Identify Affected Configuration Items

Retrieve all CIs associated with the change request.

**MCP Approach:**
```
Tool: SN-Query-Table
Parameters:
  table_name: task_ci
  query: task=[CHG_SYS_ID]
  fields: sys_id,ci_item,ci_item.name,ci_item.sys_class_name,ci_item.operational_status,ci_item.busines_criticality
  limit: 50
```

**REST Approach:**
```
GET /api/now/table/task_ci
  ?sysparm_query=task=[CHG_SYS_ID]
  &sysparm_fields=sys_id,ci_item
  &sysparm_display_value=true
```

For each affected CI, get its details:
```
Tool: SN-Get-Record
Parameters:
  table_name: cmdb_ci
  sys_id: [CI_SYS_ID]
  fields: sys_id,name,sys_class_name,operational_status,busines_criticality,environment,support_group,location,used_for,managed_by
```

### Step 3: Analyze CI Relationships and Blast Radius

Determine the downstream impact of changes to affected CIs.

**MCP Approach:**
```
Tool: SN-Query-Table
Parameters:
  table_name: cmdb_rel_ci
  query: parent=[CI_SYS_ID]^type.name=Depends on::Used by
  fields: sys_id,parent,child,type,child.name,child.sys_class_name,child.busines_criticality
  limit: 100
```

**REST Approach:**
```
GET /api/now/table/cmdb_rel_ci
  ?sysparm_query=parent=[CI_SYS_ID]^type.name=Depends on::Used by
  &sysparm_fields=sys_id,parent,child,type
  &sysparm_display_value=true
```

Build the blast radius assessment:

```
BLAST RADIUS ANALYSIS:

Directly Affected CIs: [count]
  Tier 1 (Critical): [count]
  Tier 2 (High): [count]
  Tier 3 (Medium/Low): [count]

Downstream Dependencies: [count]
  Services Affected: [list]
  Users Potentially Impacted: [estimated count]
  Business Processes: [list]
```

### Step 4: Calculate Historical Change Failure Rate

Query past changes on the same CIs or category to assess failure probability.

**MCP Approach:**
```
Tool: SN-Query-Table
Parameters:
  table_name: change_request
  query: cmdb_ci=[CI_SYS_ID]^state=closed^sys_created_on>=javascript:gs.monthsAgo(12)
  fields: sys_id,number,close_code,state,risk,category,type
  limit: 100
```

```
Tool: SN-Query-Table
Parameters:
  table_name: change_request
  query: category=[SAME_CATEGORY]^state=closed^sys_created_on>=javascript:gs.monthsAgo(12)
  fields: sys_id,number,close_code,state,risk
  limit: 200
```

**Failure Rate Calculation:**

| Metric | Formula | Risk Level |
|--------|---------|------------|
| CI Failure Rate | Failed changes on CI / Total changes on CI | >20% = High, 10-20% = Medium, <10% = Low |
| Category Failure Rate | Failed changes in category / Total in category | >15% = High, 5-15% = Medium, <5% = Low |
| Team Failure Rate | Failed changes by team / Total by team | >10% = High, 5-10% = Medium, <5% = Low |
| Recent Trend | Failures in last 3 months vs prior 9 months | Increasing = Higher risk |

```
HISTORICAL CHANGE ANALYSIS:

Changes on [CI Name] (Last 12 Months):
Total: [count] | Successful: [count] | Failed: [count] | Failure Rate: [%]

Changes in [Category] (Last 12 Months):
Total: [count] | Successful: [count] | Failed: [count] | Failure Rate: [%]

Recent Failures on Same CI:
- [CHG#] ([date]): [short description] - [failure reason]
- [CHG#] ([date]): [short description] - [failure reason]
```

### Step 5: Assess Deployment Window Risk

Evaluate the timing and window of the planned change.

**MCP Approach:**
```
Tool: SN-Query-Table
Parameters:
  table_name: change_request
  query: planned_start_date>=javascript:gs.daysAgo(-7)^planned_start_dateONNext 7 days@javascript:gs.beginningOfToday()@javascript:gs.endOfNext(new GlideDateTime(), 7)^state!=closed^state!=canceled
  fields: sys_id,number,short_description,planned_start_date,planned_end_date,cmdb_ci,conflict_status
  limit: 50
```

**Window Risk Factors:**

| Factor | Low Risk | Medium Risk | High Risk |
|--------|----------|-------------|-----------|
| Time of Day | Maintenance window (2-6 AM) | Off-peak hours | Business hours |
| Day of Week | Saturday/Sunday | Tue-Thu | Monday/Friday |
| Business Calendar | Normal period | Month-end adjacent | Month/Quarter/Year end |
| Change Freeze | No freeze | Approaching freeze | During freeze period |
| Concurrent Changes | None planned | 1-2 low-risk | Multiple or conflicting |
| Rollback Window | >4 hours available | 2-4 hours | <2 hours |

### Step 6: Evaluate Change Plan Completeness

Assess whether the change plan, test plan, and backout plan are adequate.

```
PLAN COMPLETENESS ASSESSMENT:

Change Plan:
- [ ] Step-by-step implementation instructions: [Present/Missing]
- [ ] Estimated duration per step: [Present/Missing]
- [ ] Responsible parties identified: [Present/Missing]
- [ ] Pre-implementation checklist: [Present/Missing]
- [ ] Communication plan: [Present/Missing]

Test Plan:
- [ ] Test scenarios defined: [Present/Missing]
- [ ] Expected results documented: [Present/Missing]
- [ ] Test environment specified: [Present/Missing]
- [ ] Validation steps after implementation: [Present/Missing]

Backout Plan:
- [ ] Rollback procedure documented: [Present/Missing]
- [ ] Rollback time estimate: [Present/Missing]
- [ ] Data backup strategy: [Present/Missing]
- [ ] Go/No-Go decision criteria: [Present/Missing]
- [ ] Escalation contacts: [Present/Missing]

COMPLETENESS SCORE: [X/14] items present
```

### Step 7: Generate Risk Score

Calculate an overall risk score based on all factors.

```
RISK SCORING MODEL:

| Factor | Weight | Score (1-5) | Weighted |
|--------|--------|-------------|----------|
| CI Criticality | 25% | [score] | [weighted] |
| Blast Radius | 20% | [score] | [weighted] |
| Historical Failure Rate | 20% | [score] | [weighted] |
| Deployment Window | 15% | [score] | [weighted] |
| Plan Completeness | 10% | [score] | [weighted] |
| Change Complexity | 10% | [score] | [weighted] |
|                  |      | TOTAL: | [sum] |

RISK LEVEL:
1.0-2.0: Low Risk (Standard change candidate)
2.1-3.0: Moderate Risk (Normal change approval)
3.1-4.0: High Risk (CAB review required)
4.1-5.0: Critical Risk (Executive approval required)

CALCULATED RISK: [score] - [LEVEL]
```

### Step 8: Generate Risk Explanation Narrative

Compile everything into a human-readable risk explanation.

**MCP Approach:**
```
Tool: SN-Update-Record
Parameters:
  table_name: change_request
  sys_id: [CHG_SYS_ID]
  data:
    risk_impact_analysis: |
      CHANGE RISK ASSESSMENT: [CHG Number]
      Overall Risk: [HIGH/MODERATE/LOW] (Score: [X]/5.0)
      Generated: [date]

      EXECUTIVE SUMMARY:
      This change request involves [brief scope description] affecting [count]
      configuration items including [critical CI names]. The primary risk factors
      are [top 2-3 risk factors]. Historical data shows a [X]% failure rate for
      similar changes on these systems. The proposed deployment window
      [supports/raises concerns about] successful implementation.

      SCOPE ANALYSIS:
      The change directly affects [count] CIs across [count] services.
      [Count] of these are classified as Tier 1 (business critical).
      Downstream dependency analysis identifies [count] additional CIs
      that could be impacted if the change causes unexpected behavior.
      Estimated user impact: [count] users across [departments/locations].

      HISTORICAL RISK:
      Over the past 12 months, [count] similar changes have been executed
      on the affected systems with a [X]% success rate. Notable failures:
      - [CHG#] ([date]): [brief failure description and root cause]
      [If failure rate is high]: This elevated failure rate warrants
      additional testing and a robust backout plan.

      DEPLOYMENT WINDOW ASSESSMENT:
      The planned window ([date/time range]) [is within/falls outside]
      the standard maintenance window. [Count] concurrent changes are
      scheduled. The available rollback window is [duration].
      [Specific timing risks if any].

      PLAN ASSESSMENT:
      [Assessment of change plan, test plan, and backout plan completeness]
      [Specific gaps or concerns identified]

      RISK MITIGATION RECOMMENDATIONS:
      1. [Recommendation based on highest risk factor]
      2. [Recommendation for deployment approach]
      3. [Recommendation for monitoring/validation]
      4. [Recommendation for communication]

      APPROVAL RECOMMENDATION:
      [Recommend approval / Recommend approval with conditions / Recommend deferral]
      [Conditions if applicable]
```

### Step 9: Attach Risk Details to Change Tasks

Document specific risks against individual change tasks.

**MCP Approach:**
```
Tool: SN-Query-Table
Parameters:
  table_name: change_task
  query: change_request=[CHG_SYS_ID]^ORDERBYplanned_start_date
  fields: sys_id,number,short_description,state,planned_start_date,planned_end_date,assigned_to
  limit: 20
```

For high-risk tasks, add risk notes:
```
Tool: SN-Update-Record
Parameters:
  table_name: change_task
  sys_id: [TASK_SYS_ID]
  data:
    work_notes: |
      RISK NOTE: This task involves [specific risk].
      Mitigation: [specific mitigation step].
      Rollback trigger: If [condition], execute backout plan step [X].
```

### Step 10: Create Risk Record if Needed

For high-risk changes, create a formal risk record.

**MCP Approach:**
```
Tool: SN-Create-Record
Parameters:
  table_name: risk
  data:
    task: [CHG_SYS_ID]
    short_description: "Change failure risk for [CHG Number] affecting [Critical CI]"
    category: "Operational"
    probability: [1-5]
    impact: [1-5]
    response: "mitigate"
    mitigation_plan: "[Specific mitigation actions]"
    assigned_to: [CHANGE_MANAGER_SYS_ID]
    state: "open"
```

## Tool Usage

| Tool | Purpose | When to Use |
|------|---------|-------------|
| SN-Query-Table | Retrieve CIs, historical changes, relationships | Data collection and analysis |
| SN-Get-Record | Get change request and CI details | Detailed record inspection |
| SN-Update-Record | Write risk explanation to change record | Documenting risk assessment |
| SN-Natural-Language-Search | Find similar past changes by description | Pattern matching for failure analysis |

## Best Practices

1. **Base risk on data, not assumptions** -- use historical failure rates and actual CI criticality
2. **Include blast radius analysis** -- a change to one CI can cascade through dependencies
3. **Consider business context** -- the same change has different risk during quarter-end vs mid-quarter
4. **Recommend mitigations, not just risks** -- every identified risk should have a proposed mitigation
5. **Assess plan quality** -- incomplete backout plans significantly increase risk
6. **Check for change collisions** -- concurrent changes on related CIs compound risk
7. **Account for team experience** -- first-time changes on unfamiliar systems carry higher risk
8. **Document assumptions** -- state what data was used and any gaps in the analysis
9. **Update risk as change evolves** -- re-assess when scope, timing, or CIs change
10. **Use consistent scoring** -- apply the same risk model across all changes for comparability

## Troubleshooting

| Issue | Cause | Resolution |
|-------|-------|------------|
| No CI relationships found | CIs not associated with change request | Check `task_ci` table; CIs may need to be manually linked |
| Historical data insufficient | CI is new or rarely changed | Use category-level failure rates instead; note data limitation in assessment |
| Conflict detection not run | Conflict analysis not triggered | Run conflict detection manually or check `conflict_last_run` timestamp |
| Risk score seems too low | Critical factors not weighted properly | Review scoring weights; verify CI criticality data is accurate |
| Blast radius too large | CI has excessive relationships in CMDB | Filter to direct dependencies only; exclude monitoring and discovery relationships |
| Change plan field empty | Change plan in attachments not record fields | Check attachments; extract plan content for assessment |

## Examples

### Example 1: Database Upgrade Risk Explanation

**Change:** Upgrade Oracle database from 19c to 21c on production ERP server.

```
RISK ASSESSMENT: CHG0045678
Overall Risk: HIGH (Score: 3.8/5.0)

KEY FACTORS:
- Tier 1 CI (ERP Database) serving 2,500 users
- 3 downstream application dependencies
- 2 prior database upgrades on this CI: 1 successful, 1 rolled back (50% failure rate)
- 4-hour deployment window with 2-hour rollback window
- Change scheduled during month-end processing period

RECOMMENDATION: Defer to post-month-end window. If timeline is fixed,
add DBA on standby and extend maintenance window to 6 hours.
```

### Example 2: Network Switch Firmware Update

**Change:** Update firmware on access layer switches in Building C.

```
RISK ASSESSMENT: CHG0045702
Overall Risk: LOW (Score: 1.6/5.0)

KEY FACTORS:
- Tier 3 CIs (access switches), 150 users affected
- Same firmware update applied to 12 switches last month with 100% success
- Scheduled during maintenance window (Sunday 2-6 AM)
- Automated rollback available via TFTP backup config
- No concurrent changes in network domain

RECOMMENDATION: Approve as standard change. No additional mitigations needed.
```

## Related Skills

- `itsm/change-management` - Full change management lifecycle
- `cmdb/impact-analysis` - CI impact and dependency analysis
- `cmdb/relationship-mapping` - CMDB relationship discovery
- `itsm/major-incident` - Major incident management (if change fails)
- `reporting/trend-analysis` - Change success/failure trend analysis