From Change Request to Impact Analysis in One Page

A one-line change request and the six fields of an impact analysis, filled in one at a time: what belongs in each field, and how to tell when one is wrong.

"Can we refund people as soon as they upload the photo, instead of making them wait for the parcel to come back?"

That is the whole request. One sentence, no reason attached, no deadline, no name on it. Somebody will want to know what you think before lunch.

"It depends" is usually true, and it is the answer that costs you. An impact analysis is a short, dated note that says what a proposed change touches, what it breaks, what nobody knows yet and what you recommend, written so that somebody who was not in the conversation can act on it without you in the room. One page. The same day, while the question is still worth answering.

This is one of the few moments where the difference between an analyst and somebody who reformats requirements is visible from outside. Most requirements work is slow and private, and nobody watches you do it. A change request is a stopwatch that somebody else started, in public.

In short

• The first field is the one people skip: restating the one-line request as a change to a named rule, so everybody finds out now whether they were talking about the same thing.
• The page has six fields. Five of them describe. The sixth commits, and a page without the sixth hands the decision back to the person who asked you for help.
• "I do not know" is a legitimate entry, in a specific written form: question, owner, the thing that would settle it, and the moment it starts blocking.
• Effort you have not costed with anyone who would build it is your guess. Label it as one on the page, or it gets quoted back to you as a commitment.

Where this example comes from

The case is returns and complaints at a mid-size online retailer, and it is built only from public material: the published returns policy, the help centre articles sitting next to it, and ten public complaint threads I selected myself. There was no engagement, no client, no team and no interviews. Nobody inside the company was asked anything, because there was nobody to ask.

That includes the request. I wrote it, in the form these arrive in. In a live project the first thing you do is find out who wants the change and what they think it will get them, and I cannot do that here, so the requester field stays honestly empty instead of being filled with a plausible job title. What transfers to a real project is not my answer. It is the shape of the page and the order the fields get filled in.

Why does "it depends" cost so much?

Because of what the other person does next. They came to you with a decision behind the question, and "it depends" leaves them holding it. They now have two options: wait for you, or ask somebody who will give them a number today. The second one is faster and it is always available. Two rounds of that and the next change request goes straight to a developer, and you find out about it at the release.

There is a slower cost as well. "It depends" is true of every change ever proposed, so it carries no information about this one. Say it often enough and you become the person who describes complexity rather than the person who reduces it. The one-page analysis is the cheapest way I know to stay on the right side of that line, because it says out loud what the answer depends on, in fields, with the unknowns named, and then recommends something anyway.

Six fields, filled in order. The later ones are unanswerable until the earlier ones are done, and filling them out of order is how people end up estimating something nobody asked for.

Field 1: what is actually being asked

1. REQUEST, RESTATED

Raw: "Can we refund people as soon as they upload the photo,
instead of making them wait for the parcel to come back?"

Restated: change the point at which a refund is issued for a
damaged-delivery case, from "after the returned item is received
and inspected" (help centre article on returns) to "after
photo evidence is accepted". Damaged-delivery cases only.

Requester: unknown. This case has no client, so nobody can be
named here. In a live project this field is filled first,
because the outcome the requester wants changes the answer.

Wanted outcome: not stated. Reading the public threads, the wait
rather than the decision is what people write about. Marked as
my inference, not as a requirement.

What belongs here is the request turned into a change to something specific: a rule, a published sentence, a step, a state. The test is whether a person who disagrees can now point at the exact thing they disagree with. "Speed up refunds" gives them nothing to point at, so nobody objects, and the disagreement surfaces during build instead.

What people write instead is the raw sentence, copied, with the word "Description" above it. That is transcription. It passes the request through unchanged to whoever reads next, and the reformatting is the only thing that happened to it.

Filled in wrong when: the restatement could describe two different changes and you cannot tell which one is meant, or when it names a solution nobody asked for, such as a button, a screen or a new queue.

Field 2: what it touches

2. TOUCHED BY THIS CHANGE

Rules:     the published sequence: the item is inspected on
           receipt and the inspection can change the outcome
           (help centre). No rule id in my register carries
           that sentence, which is a finding of its own
           BR-07 case closes within five working days
           BR-11 partial refunds above a stated order value
Documents: published returns policy, section 4 (the sentence
           itself changes); the help centre articles that repeat
           that sentence almost word for word
Process:   evidence upload, refund decision, parcel receipt,
           refund posting
Data:      photo evidence retention; the case state model gains
           a state that does not exist today
Out of it: change-of-mind returns and marketplace orders,
           both under separate published terms

This field is the difference between an impact analysis that takes five minutes and one that takes two hours, and the difference is whether you keep a register mapping rules to documents to process steps. Running a change request through one is most of the reason to maintain it, which is a subject of its own: the matrix that makes this field fast.

What people write instead is a list of system names. "Affects: checkout, CRM, warehouse." Systems are where the work lands, not where the change lives, and a system name tells the reader nothing about which rule stopped being true. Notice also the published text on that list. The help centre articles carry the old sentence alongside the policy, and a change that leaves customer-facing text stale generates the complaints it was meant to reduce.

Filled in wrong when: every line is a system and no line is a rule, or when the "out of it" line is empty. A change that touches everything is a change nobody scoped.

Field 3: what breaks

3. CONFLICTS AND CONSEQUENCES

C1  The published sequence makes inspection the gate before
    money moves. Refund first and inspection becomes a report.
    Somebody has to decide what happens when the report
    disagrees with the photo. No public source answers this.

C2  The parcel may never arrive. Today that case cannot exist,
    because no money has moved. After the change it exists,
    and it has no owner and no rule.

C3  Faster refunds plausibly change what people claim. I have
    no data, and there is no honest way to get any from
    outside the company. Flagged as a risk, not quantified,
    not left out.

C4  The help centre articles that repeat the sentence become
    wrong on release day, not a week later.

The first-order effect is the one already in the request. The second-order effects are the reason the request needed an analyst rather than a ticket. C2 is the shape to hunt for every time: the change creates a state that did not exist before, and a state with nobody's name against it is where cases go to sit. C3 is the other habit worth keeping, which is naming an effect you genuinely cannot size. Writing "risk: fraud, medium" with a colour next to it would look more finished and say less.

Filled in wrong when: every entry is a generic risk with a probability, and not one entry names the rule that now contradicts another rule.

Field 4: what I do not know

4. OPEN QUESTIONS

Q1  When inspection contradicts accepted photo evidence, who
    decides, and is the money recovered or written off?
    Owner: unassigned. No public source names who owns
    the published returns wording.
    Settled by: one decision in writing from that owner.
    Blocking: before any option is costed.

Q2  What share of damaged-delivery parcels come back at all?
    Owner: whoever can query returns receipts.
    Settled by: a count over the last full quarter.
    Blocking: before option C is considered.

Q3  Who approves a change to the published policy wording?
    Owner: unassigned.
    Settled by: a named approver, confirmed.
    Blocking: before release, not before build.

There is a version of "I do not know" that costs nothing and a version that costs you the room. The expensive one is the bare shrug, or its written form, "TBD". The cheap one has four parts: the question, the person who can answer it, the specific thing that would settle it, and the moment it starts blocking something. Written that way, "I do not know" reads as work in progress with a name against it, and it converts your ignorance into somebody else's task, visibly, in a document you signed. The alternative is guessing quietly, and a quiet guess holds until the day somebody reads the contract.

Filled in wrong when: there are twelve entries, or a question has no owner. A long open-questions field looks thorough and works as a way of saying nothing.

Field 5: options and what they cost

5. OPTIONS

A  Do nothing. Cost zero. The pattern visible in the public
   threads stays as it is.
B  Smallest version that helps: photo-accepted refunds for
   damaged-delivery cases below the partial-refund threshold
   in BR-11, inspection kept as an after-the-fact check.
C  Full version: all damaged-delivery cases, inspection
   becomes a report, new state and named owner for the parcel
   that never arrives.

Effort: my own estimate, not a quote from anyone who would
build it. B reads as days rather than weeks. C is a different
size, and the reason is the new state and the money recovery
rule, not the screen. What would replace this guess: one hour
with whoever owns the refund posting, plus Q1 answered.

Two things keep this field honest. The first is that doing nothing is on it, priced at zero, so the reader can see what they are buying rather than only what they are choosing between. The second is the label on the effort. Any number you write without having spoken to somebody who would build it is a guess, and by the third reader it has become a commitment with your name on it. Say what would turn it into a real number, and the label stops sounding like hedging and starts sounding like the next step.

Filled in wrong when: there is one option, or three options where two exist to make the middle one look reasonable.

Field 6: the recommendation, signed

6. RECOMMENDATION

Recommend B, subject to Q1 being answered in writing first.

Reason: it gives the requester the outcome they appear to want
for most cases, and it keeps inspection as a gate on the cases
where the money is largest.

What would change my mind: if Q2 shows that almost all parcels
come back, C is cheaper than it looks and B is a detour. If Q1
comes back as "write it off", B still holds and C becomes
affordable.

Not recommended in any form: an option that leaves the
never-arrived parcel unassigned.

Written by [name], same day the request arrived. Built from
public sources only: published returns policy, help centre
articles, ten public complaint threads. No interviews.

This is the field people leave off, and it is the reason the page exists. Five fields of description hand the decision straight back to the person who asked you for help, wearing neutrality as an excuse. Recommending is not deciding, and the page does not pretend you are the decision maker. What a recommendation does is make your reasoning attackable, which is the point, and the "what would change my mind" line is what makes it safe to write. It invites the correction instead of waiting to be corrected.

The signature earns its place for a duller reason. A page with a name and a date can be looked up in six months, when the change has shipped and the assumption under it has quietly gone stale. Field 6 is also where the change turns into work: option B, built, is a small set of acceptance criteria somebody other than you can check, and those are far easier to write from a signed recommendation than from a chat message.

Filled in wrong when: the recommendation reads "further analysis is required" and nobody is named. That is the shrug again, in a suit.

What if the six fields do not fit on one page?

Then one of the fields is wrong, and it is usually field 2 or field 4. Field 2 grows when it lists systems instead of rules, because there is no natural end to that list. Field 4 grows when open questions are used as a substitute for deciding what matters. Stacked, the six blocks above are the page: one side of A4, sent the same day, nothing attached.

The constraint is not about aesthetics. A page gets read in the meeting where the decision happens. Four pages get read afterwards, if at all, and by then somebody has already answered the question in a corridor.

Here is the blank form. Copy it, swap the labels for your organisation's words if it has its own, keep the order.

IMPACT ANALYSIS  [ref]  [one line title]
Author: [your name]   Date: [date received / date written]
Sources: [what this is built from]

1. REQUEST, RESTATED
Raw: [the request, word for word, vague bits included]
Restated: [the change, as a change to a named rule, document or step]
Requester: [who asked, and their role. Blank if unknown, never guessed]
Wanted outcome: [what they think this gets them. Mark inference as inference]

2. TOUCHED BY THIS CHANGE
Rules: [ids, not descriptions]
Documents: [including published or customer-facing text]
Process: [the steps that change]
Data: [what is stored, retained, or newly created]
Out of it: [what this does not touch, and why]

3. CONFLICTS AND CONSEQUENCES
C1 [rule that now contradicts another rule]
C2 [state or case that did not exist before this change]
C3 [effect you suspect but cannot measure. Flag it, do not price it]

4. OPEN QUESTIONS
Q1 [question] / Owner: [who can answer] / Settled by: [the specific
   thing that would answer it] / Blocking: [when it starts blocking]

5. OPTIONS
A Do nothing: [what happens if this is not done]
B Smallest version that helps: [scope]
C Full version: [scope]
Effort: [your estimate, labelled as an estimate]
Confirmed by: [what would turn it into a number]

6. RECOMMENDATION
Recommend [option], subject to [condition].
Reason: [one or two sentences]
What would change my mind: [the finding that flips it]
Signed: [name], [date]

Take the last change request that reached you as a single sentence and put it through the six fields. Give it forty minutes and stop, whatever state field 5 is in. The value is in the order and in field 6, not in the polish, and a page that is rough and recommends something beats a tidy one that ends in "it depends".

The rest of the standard I hold myself to is on this site. The scorecard is twenty-five checks across six artifacts, versioned, free, with no email address asked for. The change request page is not one of those six, and the checks it shares ground with are 05, on open questions carrying an owner and a date, and 22 to 25, on a page that asks for a decision rather than describing a situation. If you want the register that makes field 2 a five minute job, that is the traceability matrix piece; if you want what happens after field 6, it is acceptance criteria that survive a sprint review.

All field notes · The portfolio guide · More in The Document That Gets Read