Impact Analysis

---
name: impact-analysis
description: Analyze the likely business and operational impact of a proposed change across users, processes, systems, data, roles, controls, costs, dependencies, and transition risk.
---
# Impact Analysis

Use when a decision or requirement change may affect multiple teams, processes, customers, or systems.

## Procedure
1. Define the proposed change, current baseline, intended outcome, timing, and the assumptions being made about scope.
2. Identify affected stakeholder groups, workflows, business capabilities, systems, data, interfaces, controls, contracts, and support or training needs.
3. Classify impacts as direct, indirect, temporary transition, or long-term operating change.
4. Estimate magnitude, frequency, reversibility, and consequence using evidence proportional to the decision.
5. Identify dependencies and sequencing constraints that could turn a local change into broader disruption.
6. Capture benefits as well as costs and risks so analysis is not biased toward preserving the status quo.
7. Assign owners for mitigation, communication, migration, training, or follow-up measurement.
8. Revisit the analysis when scope changes or implementation reveals an affected area that was not originally mapped.

## Decision rules
- Impact is broader than code touched or budget spent.
- Transition cost can be material even when the final operating model is better.
- Do not count the same consequence repeatedly through several stakeholder views.
- Unknown impact should remain visible rather than be silently treated as zero.

## Quality gate
The analysis is ready when material affected people, processes, systems, data, and controls are mapped; benefits and adverse effects are separated; transition and dependency risks are explicit; and each consequential impact has an owner or decision path.