| 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
- Define the proposed change, current baseline, intended outcome, timing, and the assumptions being made about scope.
- Identify affected stakeholder groups, workflows, business capabilities, systems, data, interfaces, controls, contracts, and support or training needs.
- Classify impacts as direct, indirect, temporary transition, or long-term operating change.
- Estimate magnitude, frequency, reversibility, and consequence using evidence proportional to the decision.
- Identify dependencies and sequencing constraints that could turn a local change into broader disruption.
- Capture benefits as well as costs and risks so analysis is not biased toward preserving the status quo.
- Assign owners for mitigation, communication, migration, training, or follow-up measurement.
- 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.
