Run Change-Request Impact Analysis Across the Whole Corpus

Workflow area: Requirements Quality · Tier: Core · Hands-on time: ~35 minutes

Impact analysis is the step change control depends on and deadlines squeeze first. Done manually, it means one analyst skimming a document set from memory — which is why the recurring failure is not the impact wrongly assessed but the impact never found: the interface spec nobody remembered, the test pack that silently assumed the old rule, the process map two teams away. A model holding the entire corpus in context does not have your memory's blind spots; it will surface the far-flung candidates. What it cannot know is which candidates are real, what the change costs, or whether it should be approved — the model widens the search, the analyst rules on the hits, and the estimate and recommendation remain human because they carry accountability the model cannot.

When to use — and when not to

• Use it on every non-trivial CR before the change boardthe pass costs thirty minutes and its whole value is the impact you would not have listed unaided.
• Use it when the corpus outgrew one headpast roughly five documents or two delivery teams, memory-based impact analysis is guessing with confidence.
• Use it for "simple" changes especiallythe threshold tweak and the renamed field are precisely the CRs whose blast radius gets waved through unexamined.
• Skip it over a stale corpusimpact against superseded documents is worse than none, because it arrives stamped with false diligence. Verify versions first (a maintained pb-17 corpus pays off here).
• Skip AI for the estimateeffort and cost claims come from the people who will do the work; a model's estimate is a fluent number with nothing underneath it.
• Skip the silent forwardan unvalidated AI impact list sent to a CCB transfers your accountability to a language model. Every row gets adjudicated before the pack ships.

The recipe

1. 1.

   Write the CR crisply and stage the corpus. One paragraph: what changes, from what, to what, and why. Vague CRs produce vague impact. Assemble current versions of the BRD, FRD, stories, process maps, interface catalog, test plan, and decision log — and note each version, because the analysis is only valid against the set it saw.

2. 2.

   Run the impact sweep. Attach the corpus to Claude (long context) with this prompt:

   Copy

   You are performing change-impact analysis over a project corpus.
   CHANGE REQUEST: [PASTE — what changes, from/to, and why]
   Corpus: [LIST documents + versions]
   
   Find every artifact element plausibly affected:
   1. REQUIREMENTS — BRD/FRD items and stories whose text, values or
      behavior the change touches.
   2. PROCESSES — process-map steps, gateways or lanes affected.
   3. TESTS — test cases whose steps or expected results the change
      invalidates.
   4. INTERFACES & DATA — integrations, field mappings, reports and
      retention rules affected.
   5. DECISIONS — prior decision-log entries this change contradicts
      or reopens.
   
   For each hit output: Artifact + ID/section | verbatim quote of
   the affected text | why it is affected (one line of reasoning) |
   Confidence HIGH/MED/LOW.
   Rules: cite verbatim, never paraphrase inside quotes. Cast a wide
   net but rate honestly — LOW hits are welcome, mislabeled HIGHs
   are not. Do not estimate effort or cost. End with SECOND-ORDER:
   impacts that only occur if a first-order impact is confirmed.
   

3. 3.

   Adjudicate every hit at source. Good output looks like this:

   Copy

   REQUIREMENTS — HIGH
   FRD §7.2.1 "Auto-approval threshold: $25,000" — CR raises the
   threshold to $50,000; value is stated verbatim here.
   
   TESTS — HIGH
   TC-041 expected result asserts "invoice for $30,000 routes to
   manual approval" — becomes wrong under the new threshold.
   
   DECISIONS — MED
   Decision D-009 (12 Mar) capped auto-approval at $25k "per audit
   recommendation" — CR reopens an audit-driven decision.
   
   SECOND-ORDER
   If FRD §7.2.1 changes, the finance SOP §2.1 referenced by BR-031
   likely needs a matching update (SOP not in corpus).
   

   Confirm or dismiss each hit by opening the citation; record dismissals with a one-line reason. Treat the DECISIONS section as gold — a CR that silently reverses an audit-driven decision is exactly the trap this pass exists to catch. Note SECOND-ORDER items pointing outside the corpus: they are your checklist of what the model could not see.

4. 4.

   Add the human layers: estimate and recommendation. Take the confirmed impact list to the owning teams for effort and cost. Then write the CCB summary yourself: impacted-artifact count by area, the two or three impacts that dominate the cost, reopened decisions flagged for the sponsor, and your recommendation with rationale. Sign it.

5. 5.

   Close the loop after approval. If the CR passes, the confirmed impact list becomes the change's work plan — every affected artifact gets updated, and a regenerated traceability matrix (pb-21) plus a contradiction sweep (pb-20) verify nothing was missed. File the impact analysis with the CR record; the next auditor will ask.

Make it yours

• Claude Project as the standing CR analyzer: keep the maintained corpus in a Project; each CR is one prompt away, and consecutive analyses stay consistent in shape and depth for the board.
• Traceability-data head start: where pb-21 matrices or Jira/ADO links exist, feed them in — explicit links catch the first-order hits mechanically and let the model spend its effort on the unlinked, far-flung ones.
• Batch mode for CR-heavy programs: run multiple pending CRs against the same corpus in one session and ask for a cross-CR collision report — two open CRs touching the same requirement is a scheduling decision the board needs to see.
• Confluence/Rovo estates: grounded Q&A over the live page tree handles quick "what mentions X?" probes; keep the structured five-category sweep for the formal CCB pack.

Quality check

• Every hit was confirmed or dismissed at sourcecitations opened, quotes verified verbatim; dismissals carry reasons, so the adjudication is auditable.
• Confidence ratings survived scrutinysampled HIGHs are genuinely certain and LOWs genuinely speculative; a model that flatters everything to HIGH gets its output re-rated by hand.
• Reopened decisions reached the sponsorany prior decision the CR contradicts is flagged explicitly in the CCB pack, with the original rationale quoted.
• Out-of-corpus impacts are listed as unknownsSECOND-ORDER pointers to documents the model never saw appear as open checks with owners, not as silence.
• The estimate came from the doerseffort and cost were provided by the owning teams; no model-generated number appears anywhere in the pack.
• The recommendation is signedthe CCB summary states your position and reasoning under your name; the AI's output is an appendix, not the author.