## Intro Change Impact Assessment (CIA) is a structured, time-boxed workshop that turns a proposed technology change into a decision-ready plan. It clarifies scope, stakeholders, risks, metrics, and ownership so leaders can move with confidence. This facilitation package includes pre-work, roles, a timed agenda, an impact matrix with scoring, and reusable templates. You will leave with a go/hold decision, a realistic pilot, named owners, and artifacts ready to share. Who this is for: - CTOs, CIOs, VPs of Engineering, Product leaders, program managers - Platform, security, SRE, data, and product delivery teams coordinating cross-functional change Practical takeaway: Run the 90-minute workshop using the agenda and templates below, score impacts across people, process, technology, data, and external dependencies, and commit to a pilot with clear decision gates and post-change validation. ## When to use (and when not) Use CIA when a change could affect customers, revenue, reliability, security/privacy, or cross-team workflows. Typical triggers: - Feature launches, deprecations, or behavior changes - Platform or API adjustments, gateway/middleware upgrades - Security, privacy, and control changes (e.g., access, logging, encryption) - Process or ownership changes (e.g., support handoffs, on-call rotations) - Vendor/tool shifts, contract renewals with technical migration - Compliance or SLA updates that affect operations Do not use CIA for: tiny, reversible, isolated changes within a single team; backlog grooming; or brainstorming new product strategy. Prerequisites: a single named change owner, a concrete change statement, draft success metrics, and the right stakeholders available for 90 minutes. Limitations: CIA informs decisions; it does not replace technical design reviews, threat modeling, or change-advisory board (CAB) approvals where required. ## Facilitation package at a glance ### Roles (6-10 people total) - Sponsor: accountable executive (Director/VP+). Makes the decision. - Facilitator: neutral guide/timekeeper. Enforces scope and pace. - Change owner: product or engineering manager. Presents the change. - Tech lead(s): architecture, integration, data, reliability input. - Security/privacy: ensures controls and obligations are met. - Quality/Release: test, rollout, and rollback feasibility. - Support/Customer success: impact to customers and frontline teams. - Operations/SRE/Service owner: monitoring, capacity, on-call. - Scribe: captures decisions and action items in the templates. ### Pre-work (1 slide or 1 page) - Change statement: what, why, when, where (systems), who (users) - Goals and success metrics (SMART or OKR-style targets) - Scope and constraints (what is explicitly in/out) - Stakeholders and dependencies (teams, vendors, data flows) - Assumptions, open questions, and key risks already known ### Timed agenda (90 minutes) - 0-10: Welcome, roles, goals, success criteria - 10-20: Change statement walk-through (what/why/when) - 20-40: Impact matrix brainstorming (see domains below) - 40-55: Scoring: severity, likelihood, readiness, reversibility, confidence - 55-70: Mitigations, pilot scope, and decision gates - 70-80: Ownership and RACI - 80-90: Communication plan, next steps, and dates ### Impact domains to consider - People - Process - Technology (applications, infrastructure, CI/CD, observability) - Data (quality, lineage, retention, migration) - Customers (experience, SLAs) - Vendors/partners (contracts, integrations) - Controls (security, access, logging) - Compliance (privacy, audit, industry obligations) - Support (ticketing, SLAs, runbooks) - Training (internal enablement, customer education) - Communications (internal, external, change notices) ## Scoring model and definitions Assign a 1-5 score for each relevant impact item: - Severity (of impact if it occurs) - 1 = negligible; 3 = noticeable service or process degradation; 5 = critical outage, material data error, safety/legal breach - Likelihood (within the change window) - 1 = rare (<1%); 3 = possible (10-30%); 5 = likely (>70%) - Readiness (controls and preparedness) - 1 = unprepared (no runbooks/tests/monitoring); 3 = partially prepared; 5 = fully prepared with validated runbooks, tests, and monitoring - Reversibility (speed and safety of rollback) - 1 = hard/slow to reverse, risk of data loss; 3 = reversible with coordinated steps; 5 = quick rollback with automation and low risk - Confidence (evidence behind the scores) - 1 = speculative; 3 = some evidence or pilot data; 5 = proven via similar production changes or formal testing Recommended calculations: - Inherent Risk = Severity x Likelihood (1-25) - Readiness-adjusted Risk = Inherent Risk x (6 - Readiness) / 5 - Reversibility-adjusted Risk = Readiness-adjusted Risk x (1 + (6 - Reversibility) / 5) Use Confidence to flag items (<=2 requires validation before rollout). Prioritize by highest Reversibility-adjusted Risk. ## Core workshop outputs Complete these artifacts during the session. ### 1) Impact matrix (ready-to-fill template)
DomainImpact descriptionSeverity (1-5)Likelihood (1-5)Readiness (1-5)Reversibility (1-5)Confidence (1-5)OwnerMitigation/Control
People
Process
Technology
Data
Customers
Vendors
Controls
Compliance
Support
Training
Communications
Tip: Pre-populate obvious rows to save time. ### 2) Risk and mitigation register
IDRiskInherent RiskAdjusted RiskOwnerMitigationTrigger/SignalContingencyDue
R1
### 3) RACI (responsible, accountable, consulted, informed)
Workstream/DecisionARCIDate
Pilot scope and entry/exit
Rollback plan
Release approval
### 4) Communication plan
AudienceMessageChannelOwnerSend dateApproval
Internal engineers
Support/CS
Affected customers
Vendors/partners
### 5) Decision gates Define the minimum evidence for each gate. - Gate 0: Ready for pilot (owners named, runbooks drafted, monitoring in place) - Gate 1: Pilot exit (targets met, no Sev-1/Sev-2 incidents, rollback validated) - Gate 2: Limited rollout (10-30% of scope, support trained, comms sequenced) - Gate 3: General availability (GA) (KPIs sustained, audit/compliance passed) - Gate 4: Stabilization complete (post-change metrics normal, deprecations closed) ### 6) Post-change validation checklist - Monitoring/alerts green for agreed SLIs/SLOs - Data integrity checks passed (reconciliations, migrations, lineage) - Support volumes within guardrails; top drivers understood - Customer feedback neutral-to-positive in target cohorts - Security controls verified (access, logging, encryption, keys) - Audit evidence captured; change record updated; decision log posted ## Example: database engine upgrade (illustrative) Scenario: Upgrade production PostgreSQL from 11 to 15 on a new managed service. Objective: improve performance (p95 query latency -30%) and extend support window. Constraints: zero data loss, <5 minutes of customer-facing downtime for Standard tier; zero-downtime for Enterprise tier. Assumptions (illustrative): - Blue/green migration possible using logical replication - Read replicas available; app supports dual-write for cutover window - Support and customer success can staff a 24-hour hypercare window Selected impact matrix entries (abbreviated):
DomainImpact descriptionSevLikReadyRevConfOwnerMitigation
TechnologyQuery plan changes increase CPU33343Tech LeadPerformance tests; canary 10%; auto-scaling thresholds raised
DataLogical replication lag during cutover43343DB EngineerMonitor replication lag; pause writes if >10s; extend cutover window
CustomersShort write outage for Standard tier42434PMNotify 7 days prior; schedule off-peak; status page updates
ControlsMissing audit logs on new service52242SecurityValidate log shipping; pre-approve SIEM parsers; dry run
ComplianceBackup/restore RTO/RPO unproven52222SREFull restore test; documented evidence; gate before pilot exit
SupportSurge in tickets during hypercare24353Support LeadMacro replies; runbook; extra staffing day 0-1
TrainingOn-call unfamiliar with new metrics33253SRE60-min enablement; shadow cutover rehearsal; quiz check
CommunicationsVendor IP allowlist change33343OpsSend integration notice; provide test endpoint; verify ACKs
Example scoring (for the Controls row): - Inherent Risk = 5 x 2 = 10 - Readiness-adjusted = 10 x (6-2)/5 = 8 - Reversibility-adjusted = 8 x (1 + (6-4)/5) = 8 x 1.4 = 11.2 - Confidence = 2 (flag: requires validation before Gate 1) How the assessment changed the rollout plan: Original plan (before CIA): single maintenance window, 30-minute downtime, rollback by restoring snapshot. Revised plan (after CIA): - Add blue/green approach with logical replication and dual-write, targeting <5 minutes downtime for Standard; zero-downtime for Enterprise behind feature flag - Insert Gate 0 evidence: successful full-restore test within RTO; SIEM log ingestion dry run; on-call enablement completed - Canary 10% traffic to new cluster for 24 hours, with automatic cutback on error-rate >0.5% or p95 latency regression >20% - Hypercare staffing for 24 hours post-cutover; macro replies and escalation path defined - Customer comms sequenced: T-7 days email and in-app notice; T-1 day reminder; T-0 status page banner; T+1 confirmation of completion Pilot success criteria (illustrative): - p95 query latency improvement >= 25% on canary; error-rate change <0.2% - Replication lag <10s for 95% of the canary window - No Sev-1/Sev-2 incidents; audit logs verified in SIEM within 2 minutes - Support tickets per 1,000 active users during hypercare <= baseline + 20% Decision gates (applied): - Gate 0: proceed to canary only after restore test, SIEM validation, and training passed - Gate 1: scale to 30% only if canary metrics and logs meet thresholds for 24 hours - Gate 2: full rollout after 3 days of stable metrics and no major incidents Owners (RACI excerpt): - Accountable: VP Engineering - Responsible: DB Engineer (migration), SRE (monitoring/rollback), PM (comms) - Consulted: Security (logging), Support Lead, Legal (customer notice language) - Informed: Executive team, Sales, CSMs ## Metrics that matter Define and track metrics with intent: - Leading: replication lag, error budget burn rate, staffing readiness score - Lagging: customer-reported incidents, SLA attainment, churn/expansion in affected cohorts - Diagnostic: query plan diffs, CPU/memory saturation, index hit ratio - Guardrail: error-rate, p95 latency, support ticket volume, cost per query - Vanity (avoid as decision drivers): page views of comms, meeting counts Tie each change decision to business value (performance, cost, risk posture), customer outcomes (reliability, trust), delivery (time-to-restore, deploy frequency), and governance (audit evidence, policy adherence). ## Facilitation prompts - Scope and intent: What problem are we solving? How will we know in numbers? - Stakeholders: Who benefits, who bears risk, and who must approve exceptions? - Impacts: What changes across people, process, technology, data, and partners? - Risks: What could fail first? How would we notice early? What is the rollback trigger? - Pilot: What is the smallest meaningful slice that proves value and reveals risk? - Ownership: Who is A/R/C/I for each decision and deliverable? - Communication: Who needs what, when, and through which channel? ## Run-of-show checklist (day-of and after) - Timebox strictly; park debates not needed for today’s decision - Score first, debate later: capture assumptions and confidence levels - Assign names and dates in every row, not just teams - End with a one-page digest: decision, scope, pilot, metrics, owners, dates - 48-hour follow-up: close open questions and post the decision record - Weekly during pilot: review metrics, risks, and comms cadence - Post-change: complete validation checklist and retrospective; update templates ## Conclusion A well-run Change Impact Assessment aligns leaders on value, risk, and ownership, turning uncertainty into a measured, testable plan. Use the agenda and templates to map impacts across people, process, technology, data, and external dependencies; score them with consistent rules; and commit to a pilot with clear decision gates and post-change validation. Start with your next material change: schedule the 90-minute session, pre-fill the impact matrix, and leave with a de-risked rollout you can defend.