An estimate for analysis work answers three separate questions with three separate numbers: how many hours the work costs, how many of those hours a plan can name before the work starts, and how many days pass before anyone can decide. Quoting one number for all three is how the date gets missed.

In short

• The case cost about thirteen hours. A step plan for the same case names seven to nine of them plus an evening. The gap is the work that happens after the document already looks finished.
• The same case took twenty-eight calendar days. Six of them sit between a finished draft and the end of the second review session, on dates two other people set. Effort does not shorten that stretch.
• Three of the five requirements in that register did not exist in v1.0. Cutting a review pass to hit a date does not cut polish, it cuts more than half the register.
• The document was reviewed on 9 April and the decision it asks for was due on 30 April. Quoting the date the analysis ends answers a question nobody asked.

What did the work actually cost?

About thirteen hours, spread over four evenings and one Saturday. The largest single block was the process model, and most of that block was one full redraw.

That figure is on the case sheet, so it can be checked against what it produced: a brief and six artifacts, namely a stakeholder map, an as-is and to-be model, a requirements register holding five requirements, a rules register, a review log and a one-page summary. It was noted rather than timed, and the word in the case is "about".

It holds no time for arranging interviews, chasing a data export or rescheduling a workshop, because there was no access to arrange. The thirteen hours are mine; the two reviewers read the document as a favour.

Which hours could a plan have named in advance?

The same case is published with a five-step method, and each step carries a time. Reading those numbers as a forecast, then holding them against what the work cost, is the useful part.

Add the hours actually stated and you get seven to nine, plus an evening not expressed in hours at all. The recorded cost was about thirteen.

The difference is not a rounding error and not sloppiness in either number. It is the work the step list does not name: the self-review against the scorecard, the redraft after each review session, and writing up the review log. All three happen after the document already looks finished, which is exactly why a plan skips them.

So an honest planning number has two lines: the hours you can name, and what the passes after the first draft cost. Here the second line is about four hours on top of nine.

The calendar clock: twenty-eight days

Hours answer what it costs. Days answer when it lands.

Twelve March to 9 April is twenty-eight days. Thirteen hours of work, spread across four weeks.

Look at rows four and five. Six of the twenty-eight days sit between a draft being finished and the second session ending, on dates set by when other people could read. That stretch does not shorten if you work harder. It shortens if you ask earlier or ask more people, and both are decisions made at the start rather than rescues at the end.

This is the number to quote when somebody asks when it will be ready, and the reason to quote it with the waiting on its own line. An estimate that hides the waiting inside the work looks smaller and is wrong in the one direction that gets noticed.

What did the extra passes actually produce?

This is where cutting a review round stops looking like a saving. Of the five requirements in that register, three did not exist in the first draft. REQ-018, the guard rail stopping an automated pre-check from refusing anybody, came out of the self-review against the scorecard, and so did the fallback on REQ-016. REQ-015, escalation ownership, and REQ-017, the condition dispute that moves after the money, both came out of the external sessions, along with a rewritten start event on REQ-014, a rule BR-12 nobody had written down, a page of rationale for BR-11, and one scope exclusion nobody had noticed.

Five objections across two sessions: four accepted, one held with the reason written down beside it.

So the passes a plan does not name, and a deadline squeezes first, produced more than half the register. The first draft was the input to the part that found the missing pieces, not a nearly-finished document waiting for corrections.

The estimate card, filled in from that case

Copy the columns, not the content. Anything on this card that I chose rather than measured says so.

The blank card

One card per piece of work. If a row has no number, write what would have to happen for it to get one.

Three rules for using it. Give the waiting its own line, because it moves the date and a single number hides it. Never quote the hours and the calendar as if one implied the other: thirteen hours landed on day twenty-eight here and could as easily have landed on day nine. And when asked to cut the estimate, cut scope or access assumptions out loud rather than quietly cutting a pass, because a pass is where three of those five requirements came from.

Why is "analysis finished" the wrong date to quote?

Because the work exists to produce a decision, and the decision has its own calendar.

The reviewed version of that case is dated 9 April 2026. The one-page summary it ends with asks for a decision by 30 April 2026 and names the three things it needs answered: whether five working days is a commitment or a target, whether partial refunds ship in release one, and who owns the weekend rota. Twenty-one days sit between the document being finished and the question being settled, and none of them belong to the analyst.

The open questions register makes the same point twice over. Six questions, each with a due date and a fallback, and one of them still carrying an open owner slot. OQ-06 asks how many cases actually stall today, and the case says plainly that if parked cases turn out to be rare and short, this work is not worth a release slot. That question is dated to the first week of access, a week that had not started when the document was finished.

An estimate measured to the document answers a question nobody in the room asked. Measure it to the decision, and say which part of that span is yours.

What do the standards put a number on?

Less than people expect, and never on the thinking.

The Scrum Guide is the document most often reached for when somebody wants a norm here. It puts a length on the Sprint and time boxes on the events, and it gives no figure for preparing a backlog item or for analysis of any kind. Sizing there sits with the people who will do the work, not with a standard. Teams quoting a number for refinement got it from their own history, which is the right place to get it and not a place anybody else can borrow from.

HM Treasury's Orange Book, the free risk management guidance for UK government organisations, asks for something a schedule can use: "clear processes for bringing significant issues to its attention more rapidly when required, with agreed triggers for doing so". That is written about risk, not estimates, and the transfer is mine. It is still the most useful sentence I know here, because the weakness in most estimates is not the number, it is that nothing is agreed in advance about what makes it wrong. Hence the trigger row above.

What this estimate does not cover

One case, one person, public sources, no client waiting. Treat the figures as mine and the shape as transferable: hours, the subset a plan can name, calendar days, waiting shown separately.

A real engagement adds a class of waiting absent here entirely. Interviews get scheduled and moved, access gets requested and granted late, a workshop needs a room full of diaries rather than two. Each of those lands in the calendar column and none of them in the hours column, which is why the two numbers have to travel separately.

And the thirteen hours were noted, not timed. If you want a figure you can defend to somebody paying for it, time your next two jobs. Two measured ones beat any number of remembered ones.

Where to start

Take the last piece of analysis you finished and write down two dates: when you started reading, and when the decision it supported was actually made. The span between them is the estimate your stakeholders experienced, whatever number you gave them at the start.

Three pieces on this site pick up where this one stops. Definition of ready for a requirement is the gate deciding whether a pass is finished, run over the same register. A risk register with owners, dates and a trigger derives its rows from artifacts that already existed, the same move this piece makes with a timeline. The questions a reviewer asks about your work sample is what those two sessions looked like from the other side of the table.

The twenty-five checks behind the artifacts named here are on the scorecard: yes or no, free, no email address asked for. The worked case this timeline comes from is at the case, and the six blank templates are on templates.

Nobody can tell you how long business analysis takes, and a page answering that with one number would be worth less than this one. What can be published is a real timeline with the waiting left in, next to the artifacts it produced, so you can hold your own against it.

A risk register is a list of events that have not happened yet, where every row names an owner who can act before it does, a date by which acting is still cheap, and a trigger: an observable event that says now rather than later. A row without those three is a worry with formatting.

The register below was not written at a workshop. It was derived from artifacts that already existed, and the derivation is the part worth copying.

In short

• Do not brainstorm risks. Derive them. A pack you have already written names most of them: the anti-goal, the section on what your change makes worse, the column saying what each stakeholder loses, and your own criteria worded as prohibitions.
• A candidate stays only if it survives the trigger test: name the observable event that says act now, and the person other than you who would see it first. Three of my eight candidates did not survive.
• If answering your open questions would delete the row, it was never a risk. It was an open question, and it belongs in the register that already has owners, dates and fallbacks.
• There is no probability times impact column in my register, and the reason is that I have no baseline. A number I chose, multiplied by another number I chose, produces a third one that looks measured.

Where do the rows actually come from?

Seven passes over sections of the case that already existed, each with a rule for what to read out of it.

The second row carries most of the weight. The case has a section naming what the to-be makes worse, written because a proposal that improves everything has not been costed. It is the only risk input in the pack guaranteed to be about your work rather than about projects in general.

The fifth row is the one people skip. A criterion phrased as a prohibition exists because the obvious implementation would break the requirement while appearing to satisfy it. REQ-015 says that assignment to a shared mailbox, a group or a queue does not satisfy it: a risk statement with the word risk missing.

What does the trigger test throw out?

Eight candidates came out of that pass, and each had to answer two questions: what observable event says act now, and who other than me sees it first. Three failed, in two different ways.

Two were open questions wearing a risk costume. A 48 hour window measured in clock hours escalates into a weekend rota that may not exist, and uploaded photographs need a retention period I could not confirm from outside the company. Both disappear the moment a named role answers a question, and both already sit in the case as OQ-04 and OQ-01 with an owner, a due point and a stated fallback. Copying them across creates a second place to track one thing, and the second place is the one that goes stale.

So the boundary is a test you can run in one sentence: if answering every open question on time would delete this row, it is not a risk. What survives is the set of things that can still go wrong when everybody answers you on time.

One had already been converted into a decision. The self-service form is built around photographic evidence, and a customer whose parcel never arrived has nothing to photograph. That arrived through review rather than my own diligence, and the fix was to name non-delivery and lost parcels out of scope, with a reason and an owner. Putting a deliberate exclusion back into a risk register reopens something closed in writing.

Five rows survived, and each can still happen after the last open question is answered.

The register, filled in

Copy the columns, not the content. Owners are roles, because public sources carry no staff list and a plausible name filled in to make a cell look complete is worse than a visible gap. Anything I chose carries [MINE].

Two honest notes on that table. Every owner is a role and says so, because the case has no access to the company, and every review point I chose rather than found is tagged. And RSK-05 is the row that looks least like a risk: it fires when the project succeeds on the number it is being judged by.

Why is there no probability and impact score?

Because I cannot produce either honestly, and a five by five grid would hide that rather than show it.

The case counts how often a case stalls today as unknown: four of the ten complaint threads I selected ended in that state [THREADS n=10], which is a count of ten threads and not a rate, and no rate is obtainable from outside the company. Measuring it is the first thing I would do with access [OPEN, OQ-06]. With no baseline, a probability of 3 out of 5 is a number I chose, an impact of 4 out of 5 is a second number I chose, and multiplying them produces a 12 that looks like it came from somewhere.

The register replaces that pair with two columns somebody else can check: the trigger, and the response when it fires. A trigger is a claim about what is observable in your system, so a reviewer can argue with it. Nobody can argue with a 12.

This is not an argument against scoring where a baseline exists. With your own incident history behind the numbers, score it. From outside a business, on public sources, scoring is decoration with arithmetic on it.

What do the standards actually ask for?

Less than the templates do, and the part they do ask for is the part templates leave out.

HM Treasury's Orange Book, the free risk management guidance for UK government organisations, last updated in July 2026, asks for "clear processes for bringing significant issues to its attention more rapidly when required, with agreed triggers for doing so", and for reporting that shows trends and supports "early warning indicators". Agreed triggers, in other words, and a route that they open. It also puts ownership with management rather than with a document: "management have primary ownership, responsibility and accountability for identifying, assessing and managing risks".

The Software Engineering Institute published its Continuous Risk Management Guidebook in 1996, and the word doing the work in that title is continuous. A register produced once, at the point where a business case needs an appendix, is not what either document describes.

What both ask for, then, is ownership held by people and a route that opens when something changes. Neither of those arrives with a file.

The blank card

One row per risk. If you cannot fill the trigger column, you have not found a risk yet.

Three rules for using it. Write the trigger before the response, because a response you cannot attach to an event is a good intention with a paragraph around it. Retire rows out loud, with a date and a reason: a register nobody ever subtracts from is read once. And when a trigger reads "somebody notices", the risk has no owner yet, whatever the owner column says.

What this register does not tell you

It does not tell you whether the change is worth making, and it prices nothing. The one-page summary in the case carries no cost figures and says why: internal effort cannot be priced from outside the company, and an invented figure is the first thing to break in the room. The risks of changing nothing sit on that page too, under what happens if nothing is decided.

It is also silent on volumes, staffing and cost, the three subjects where public sources gave me nothing. A register that looked complete would be lying about exactly that.

Where to start

Open the last pack you wrote and find the section where you said what your proposal makes worse. If there is no such section, that is the finding, and a larger one than a missing register. Then read your requirements for criteria worded as prohibitions: each is a risk you already identified and filed where no risk owner will look.

Three pieces on this site pick up where this one stops. As-is before to-be puts the two models side by side with a column for what each change breaks, which is where RSK-01 and RSK-04 came from. Definition of ready for a requirement runs a seven-condition gate over the same register and finds the failures a checklist can catch a week late. The questions a reviewer asks about your work sample is the same material seen by somebody with twenty minutes and no reason to be kind.

The twenty-five checks behind the artifacts named here are on the scorecard: yes or no, free, no email address asked for. The worked case this register was derived from, with its version history and its review log, is at the case, and the six blank templates are on templates.

One last thing, since the phrase "risk register template" belongs to tool vendors and it would be strange to pretend otherwise. They will outrank this page for a long time, and their download looks better than the card above. What they cannot hand you is a register with the derivation written beside every row, on a case whose review log is published with it.

A definition of ready for a requirement is a short list of conditions, each answerable yes or no by a stranger reading the requirement itself, that decides whether it can enter a conversation about building it. A meeting is not one of the conditions. Neither is a stage in a tool, nor a confidence score. The list is applied to one requirement at a time, by somebody who cannot ask the author what it meant.

The word ready carries Scrum baggage it never earned. The Scrum Guide defines a Definition of Done and does not mention a Definition of Ready anywhere, so whatever your team runs under that name was invented locally, by people, for reasons. That is not a criticism. It does mean nobody can appeal to an authority for the contents, and the list is yours to make answerable.

In short

• A condition earns its place on the list only if a stranger can answer it yes or no from the document. Anything that needs the author in the room has already failed, and the meeting you called to check it is the proof.
• Run the list backwards over work you have already finished. Seven conditions over my own published register found seven failures across three versions, and none of them was caught by me at the moment of writing.
• Five of those seven were caught by another person reading the document, and two by running a checklist against my own draft a week later. The list is worth keeping for those two, not for the five.
• A gate with no consequence is a ceremony. The consequence is narrow and unglamorous: the requirement goes back to the author, and nobody estimates it in the meantime.

What does the gate actually check?

Seven conditions. Each one is a property of the text on the page, which is the only thing a gate can honestly inspect.

Five of the seven are scorecard checks, carried over with no more rewording than putting them on a single requirement demands. Two ask for more than the check does, and the table names the check each one leans on. Condition 4: check 17 asks for labelled inference in the rule register, and I have extended it to every number that appears in a requirement. Condition 6: check 05 asks an open question for an owner and a date, and the fallback is mine - the returns case carries one next to every question, and the scorecard does not ask for it. Reusing the wording is deliberate. A definition of ready with its own vocabulary gives you two lists to maintain and two arguments about wording, and the second list always loses.

Condition 4 also carries the most weight for the least effort. A requirement is where a number gets laundered: a threshold somebody chose reads exactly like a threshold the business set, in the same font, in the same cell, unless one of them says [MINE]. In the published register, the 40 EUR partial refund threshold is [POLICY] and holds a rule id; the three file, 10 MB upload limit and the 48 hour decision window are both [MINE], kept visible so somebody can argue with me instead of inheriting them. One word per number, and it is the difference between a register and a rumour with decimal places.

What is not on the list matters as much. Nothing here asks whether the requirement is well written, whether the story follows a template, whether estimates exist, or whether anybody is confident about it. Those are opinions, and an opinion cannot be failed. A condition that cannot be failed is decoration on a gate.

What happened when I ran it backwards on my own register?

The published case has three versions with dates on them: v1.0 drafted 24 March 2026, v1.1 after a self-review against the scorecard on 31 March, v1.2 after external review on 9 April. Sources were read between 12 and 21 March. Two peers reviewed it across two sessions and raised five objections, four accepted in full and one accepted in part.

So I know, line by line, what was wrong and when it stopped being wrong. Here is the same seven-condition gate applied to the register as it stood at each of those dates.

Seven failures. Zero of them caught at the moment of writing, by me, while intending to do every one of these things properly.

That number is the argument of this piece and it cuts both ways. Five of the seven needed another person, which no checklist replaces and which is why the review log is the artifact I would read first in somebody else's pack. Two needed nothing but the list and a week of distance. Those two are cheap and repeatable, and they are also the two that would otherwise have reached a build conversation: neither of the five objections in the log is about a missing fallback.

There is a second pattern in that table worth naming. Four of the seven failures are the same shape: a branch where the work stops and nobody owns it. The parked case with no clock, the customer with no photograph, the open question with no fallback, the automated refusal with nobody to appeal to. That shape is what a definition of ready is actually hunting, and if you only ever ask one question of a requirement, ask what happens on the branch where it does not work.

When does a definition of ready turn into a ceremony?

Four ways, and all of them are recoverable.

The list grows. A list short enough to hold in your head gets applied. A long one gets completed, from memory, in the last two minutes before the meeting. If you want to add a condition, say which one it replaces.

A condition becomes an opinion. "Well understood by the team" is not checkable, so it gets a yes every time and quietly teaches everybody that the list is theatre. Delete it, or turn it into the thing you were really worried about, which is usually condition 2 wearing a friendlier face.

The gate becomes a meeting. The conditions are answerable from the document by somebody who did not write it. If checking them needs the author present to explain, condition 2 has already failed and the meeting is where you found out. Hand the requirement to one colleague, silently, and ask for the nos.

There is no consequence. A gate that flags a problem and waves the requirement through is worse than no gate, because it leaves a record saying the work was checked. The consequence has to be small enough to actually apply: the requirement goes back, it is not estimated, and it is not in the sprint.

One failure mode is subtler than those four. A gate can turn into a weapon against the person who writes things down. The analyst who records an open question fails condition 6 until the fallback is written; the one who never asks the question passes every condition, because their document has no visible holes. If your list rewards silence, it is producing worse requirements than no list, and the fix is to read the nos as a map of what is unresolved rather than as a verdict on the author.

The card, filled in

This is the gate applied to one requirement from the published register, in the state it is in now. Copy the shape, not the content.

Verdict: ready. Not ready on: none. Blocked by: nothing. Checked by: the author, which is the weakest version of this and says so.

Two honest notes on that card. The owner on OQ-04 and OQ-05 is a role, not a person, because this case has no access to the company: the gate accepts a role plus a note saying the person could not be named, and rejects a plausible job title filled in to make the cell look complete. And every requirement in this register is marked Must have for release 1, which is a smell the case admits on its own face and answers by naming the one it would cut first. Priority is not on my list of seven, because it cannot be failed by reading one requirement on its own. It fails at the register level, where everything says Must.

The blank card

Verdict: ☐ ready ☐ back to the author. Not ready on: __ Blocked by, with a name and a date: __ Checked by: __

Three rules for using it. Write the verdict before the evidence column, then make yourself fill the evidence in, because a yes you cannot evidence is a no you have not admitted yet. A no is not a defect report, it is a sentence you have not written, and most of them cost one clause. And run it now and then on a requirement somebody else wrote, because the gate is much easier to apply to a document you are not defending, and that is the version of your own judgement worth practising.

What this does not tell you

The gate inspects one requirement as a piece of text. It cannot tell you whether the requirement is needed, whether the rule behind it is true, whether the priority is honest, or whether the whole slice of process was worth changing. It cannot tell you that a rule owner will overturn a number the moment they see it either. The register says as much about its own 48 hour window: of everything in the case, that is the figure most likely to be changed by the person who owns the rule, and the design does not fall over if it becomes 72.

What it does is stop a particular kind of expensive silence: the criterion everybody read and nobody could test, the branch nobody owned, the question with no name against it. Those cost nothing to fix on the page and a great deal to fix in a build.

Where to start

Take the last requirement you wrote and answer condition 6 out loud: who owns the open question, by when, and what happens if that date passes with no answer. If you have no open questions at all on a requirement written from the outside of a business, that is the finding.

Then, when a criterion fails condition 2, acceptance criteria that survive a sprint review is the piece on rewriting it into something a tester can run. When condition 5 fails, the branch you are missing is usually one your process model never drew, and as-is before to-be is about finding it. When you want the view from the other side of the desk, the questions a reviewer asks about your work sample is the same gate applied by somebody with twenty minutes and no reason to be kind.

The full list of twenty-five checks behind conditions 1 to 7 is on the scorecard: yes-or-no, free, no email address asked for. The worked case whose three versions this piece pulled apart, plus six blank templates, is in the Proof Pack.

The gate did not save me from any of the seven. It caught two of them a week late, which is still before anybody built anything, and it gave the other five a place to be recorded instead of a conversation somebody would have half remembered. That is the whole claim. A definition of ready is worth having when it is seven answerable questions and a consequence, and worth deleting on the day it becomes a meeting where everyone says yes.

Five Whys assumes each answer has exactly one parent. The first answer usually has three, and the technique gives you nowhere to put the other two, so by question number two you are no longer asking about the incident. You are asking about the branch you happened to pick, and everything after that inherits the choice.

In short

• The chain does not break because you stopped at four or went on to six. It breaks at the first link where two or more answers are equally true and nothing in the method tells you to write that down.
• Run the chain three times from the same incident, once from each direction somebody would naturally take it, and compare the endpoints. Three different endpoints is the normal result, not a sign that you did it badly.
• Most chains end on a condition rather than an event: something that was true of every case that day, including the ones that went fine. Conditions are fixed by design decisions, not by more questions.
• Stop at the first link nothing public can answer. Log it as an open question with an owner, a date and a fallback. The alternative is inventing link five to reach the number.

Where does the chain actually fork?

Here is the incident, stated the way it appears in the case: a damaged-delivery case reached a state where nobody owned it and no clock was running, and the only thing that moved it again was the customer chasing it.

Three people would take that incident in three different directions, and all three are reading the same document. Below is each chain, run to its natural end. A link with a tag is a link somebody else can check. A link with no tag is one I worked out from the model, and a link marked "wall" is one nothing public answers, which is where that chain stops.

Three chains, three endpoints, one incident. None of them is wrong. Chain B ends on a rule that does not exist today and had to be proposed, which is why it carries my name in the register rather than the company's. Chain C ends on a decision about the channel, not on anything that happened in this case: the spoken description of the damage is not something a second agent can read, and that was true before the parcel was sent. Chain A ends on a wall at link three, and the useful thing about it is that the chain found a hole no other artifact in the pack had noticed: the register carries six open questions and not one of them asks who decides what counts as enough evidence.

That last one is the argument for running the chain more than once. The branch that ends in a wall is the branch that produced something new.

Why does the branch you take decide the recommendation?

Because the method rewards whoever asks first. Link one has three true answers, you write down the one that came to mind, and every question after that is a question about that answer rather than about the incident. By link three the other two branches are not rejected, they are invisible, and the chain reads as though it could not have gone anywhere else.

The published case settles this in a way I did not plan. The proposed process changes exactly two things: evidence is collected before a human sees the case, and the parked branch gets a named owner with a clock on it. Two changes, arrived at separately, both kept after review. If a single root cause had been sitting under that incident, one change would have been enough and the second would have been padding. It was not padding. Each change closes a different chain, and the reviewer who read the process model first objected that the original as-is showed only the path where things go well, which is what put the parked branch on the model at all.

So the honest reading is that this incident has at least two causes that a design has to answer, plus a third question nobody can answer from outside. A technique whose output is one sentence with the word "therefore" in front of it cannot represent that.

Cause or condition, which is the distinction that does the work

Look again at where Chains B and C end. Neither endpoint is an event. No owner exists on the parked branch, and no self-service form exists on the store front. Both were true on the day the case stalled, and both were equally true on every day that a case did not stall.

That is a condition, and the test for it takes one question. Was this also true of the cases that came out fine? If the answer is yes, you have found something that lets the failure happen rather than something that made it happen, and no further why will convert one into the other. Conditions get closed by a design decision, an owner and a date. Events get closed by an investigation.

Chains that end on a condition are the useful ones, and the method gives you no signal that you have crossed from one kind of thing to the other. On the wall in Chain A the same test says something different again: an unknown is neither, and the only correct move is to write it down as unknown.

The branch sheet

This is what I keep instead of a chain. Same ten minutes, one more column, and the column that earns the page is the last one.

Read the right-hand column on its own and you have the two chains you did not run, written down where they can be picked up later instead of lost. Read the fifth column on its own and you have a list of things that would falsify your own conclusion, which is the difference between a chain you can defend and a chain you happen to believe.

The tag column is the one people skip, and here it is the one that hurts. One link of the five carries evidence, one is an open question, and the three in between are mine: I read them off my own process model rather than out of a source anybody else can open. That chain produced a requirement and a proposed rule. It is still the honest version, because the alternative was not a better-sourced chain, it was the same chain with the middle presented as fact. Labelling an inference as an inference is check 17 on the scorecard, and it costs one word per row.

The blank version

Copy this. Fill the tag column at the same time as the answer, never afterwards, because afterwards you will remember every answer as better sourced than it was.

Incident, in one sentence: __ Stopped because: ☐ reached a condition with an owner ☐ reached a wall ☐ ran out of evidence Branches parked, with owner and date: __

Three rules for filling it in. Two links in a row marked as yours means the chain has left the evidence and what follows is your model of the process. That is allowed, and the parked branch in this case got onto the model exactly that way, but it has to be visible, because those are the links somebody can knock over without leaving the room. If column five is empty for a link, you cannot yet tell whether that link is true, so it is not a finding. And if column six is empty for link one, you have not run a chain, you have written down the first thing you thought of and asked why about it four times.

Where do you stop asking?

Not at five. Five is a number in the name, not a property of any process, and in the chains above the honest stopping points fell at three, five and five.

Stop at the first link you can only mark as unknown. Then do the thing the method does not include: turn that link into an open question with an owner and a date, which is check 05 on the scorecard, plus a fallback for when the date passes, which the scorecard does not ask for and the returns case carries anyway. An unowned question does not stay a question. It gets quietly promoted to an assumption somewhere between the workshop and the build, and nobody notices until it is expensive.

The returns case carries six open questions and every one has a fallback written next to it, because an open question without a fallback is a wish with a due date attached. The one that matters most is the measurement: how many cases actually stall today, and for how long. Until that number exists, all three chains above are descriptions of a failure mode whose size nobody knows, and the case says so in the same line where the count appears. Four of ten threads I selected myself is a count of ten threads, on every page where it appears, which is check 10.

There is a quieter reason to stop early. Every link past the evidence is a link somebody can argue with in a room where you are not present, and it will be the weakest one they quote. A three-link chain that ends in an honest unknown survives a hostile reading. A five-link chain whose last two links are guesses presented as findings does not, and the three good links go down with them.

When is it still worth the ten minutes?

More often than this piece makes it sound.

Five Whys is fast, costs nothing, and needs no preparation, which makes it the right opening move in a room where people are still describing the symptom to each other. It works properly when three things hold: one actor, one run of the process, and an answer at every step that somebody present can check on the spot. Picture the simplest possible version of that: a machine stops, the wrong part was fitted, that part was sitting in the wrong bin, the bins were relabelled last week. Four links, one actor, every one of them verifiable by walking to the bin. That chain is fine and a branch sheet on top of it would be overhead.

It also earns its keep as a boundary finder. Run it once, quickly, and watch where the answers change from "here is the document that says so" to "well, what usually happens is". That switch is the edge of what anybody in the room actually knows, and finding it in ten minutes is worth more than the chain you were nominally building.

What it cannot do is carry a process with more than one actor, an exception path and a decision that changes hands. For that shape, the model is the tool and the chain is a warm-up for drawing it.

Where to start

Take the last root cause you wrote down and try to falsify link two. Not link five, which is where the argument usually happens. Link two, where the chain narrowed to one answer for the first time, and where you can still remember what the other answers were.

Then put the branches you did not take somewhere they survive the week, with the same three columns as an open question: owner, date, and what happens if the date passes.

If the process you are working on has an exception path, as-is before to-be is the piece on drawing the branch where work stops, and the parked branch in this case is the one both Chain B and Chain C are really about. If your chain ended on a link only a person inside the business can settle, the eight questions in a first stakeholder interview is how that becomes an agenda rather than a note. If it ended on an unowned rule, the stakeholder map that survives contact with the project is where the owner column belongs.

Then run the artifacts through the scorecard: twenty-five yes-or-no checks, free, no email address asked for, and checks 05, 10 and 17 are the three this habit answers to. The worked case and the six blank templates are in the Proof Pack.

The chains above are the ones I could run from outside, and Chain A stops at a wall I cannot get past without access to the company. That is the price of a case anybody can check, and it is also the clearest demonstration I have of the point: the method gave me three answers, and the only reason you can tell which of them are load-bearing is that every link carries a tag saying where it came from.

A first stakeholder interview is the session where the things you could not establish on your own become rules with owners and dates against them. Which makes the agenda a derived document rather than a checklist: you do not walk in with eight good questions, you walk in with the eight holes in your own draft, ordered so that the answer most likely to resize the work arrives while there is still time to use it.

In short

• The agenda comes out of your draft, not out of a list somebody published. Every claim you tagged as your own inference and every owner slot you left open is a candidate question.
• Write down what a yes and a no each change in the document, before the session. A question whose two answers lead to the same next step is a question you can skip.
• Three of the eight can resize or cancel the work. Ask those first, in case the session is cut short.
• An answer with no name and no date against it cannot be rechecked by anybody, including you, and that only becomes a problem months later when somebody asks who agreed to it.

Where does a good interview question actually come from?

Not from a list of openers. "What are your main pain points" gets you a paragraph you could have written yourself before the meeting, and it puts the work of structuring the conversation on the person you came to learn from.

It comes from the draft you wrote before the meeting. Build the document first from whatever is public: the policy, the help pages, the complaints, the part of the journey you can walk yourself. Tag every claim with where it came from, then read your own tags. Every [MINE] is a number you chose and nobody confirmed. Every [OPEN] is a slot you could not fill from outside. That is your agenda, and it has a property no generic list has: you can say out loud what you will do with each answer.

The scorecard check behind this is 05, open questions listed with an owner and a date. It earns a place among twenty-five checks because a question with nobody's name on it quietly becomes an assumption, and assumptions surface during build at the worst price you will pay all year.

There is a second effect. Turning up with "your published policy says partial refunds are permitted only above 40 EUR of order value [POLICY], and I could not find who owns that figure" is a different opening from "tell me about returns". The first one can only be asked by somebody who did the reading, and it asks for a decision right rather than for a briefing.

The eight questions, and the gap each one came from

This is the plan I would take into a first session on the returns case, if access appeared tomorrow. Every row on the left exists because something on the right could not be settled from outside. The plan assumes one session and no guarantee of a second [MINE].

Six rows come straight out of the open questions register. Two do not: question 5 comes from the reach column of the stakeholder map, where the honest entry was that no public source names a route to the person who can reverse a refund, and question 6 from the exception path in the as-is, where the branch exists and everything around it is invisible from outside. Both gaps sat in the artifacts for weeks without being written down as questions, which is its own lesson about where to look.

1. Rule or target

A commitment can be breached, so it needs a mechanism, an owner and a consequence. A target cannot be breached, so anything you hang off it is decoration. "Aims to resolve" [HELP] leaves both readings open and rereading it will not settle them. Ask early: BR-07, the escalation in REQ-015 and the published wording all move with the answer.

2. Who owns the number

Owner and review trigger are separate things and you want both. A rule with a name against it can be renegotiated; one without a name can only be worked around, quietly. Scorecard check 16 asks for the name and the date, check 18 for the event that would make the rule wrong. If nobody owns it, that is not a failed question, it is a finding, and it goes in the register in those words.

3. Can you pull the queue

The one that can cancel the work. Four of the ten threads I read ended with an unowned case, and the same sentence in my case says the frequency across all cases is unknown from outside [THREADS n=10]. If the export shows parked cases are rare and short, the failure mode was real and not worth a release slot, and saying so is the job. Ask for the export rather than an impression: an impression cannot be rechecked afterwards, including by the person who gave it.

4. Which clock, and what happens at the weekend

A duration means nothing until the event that starts it is named, which is scorecard check 13. Two clocks in one process, one in clock hours and one in working days, decide a case under one and pay it under the other. Whoever runs the rota can answer immediately, and it is written down nowhere.

5. Who can undo it

The head of the department is the obvious first interview and rarely the most useful one. The person who receives the returned goods can hand an item back and unmake a refund the office has already promised [POLICY] [HELP], and nothing public says they are ever in the conversation where the refund window is set [OPEN]. Ask for the route as well as the name: a calendar invite, their manager, the weekly returns call, ten minutes on the bay. Then ask what that person loses if the change goes through, which is scorecard check 08.

6. What people do while a case waits

My as-is has a branch where work stops, and the interesting part is whatever has grown around it: a spreadsheet somebody maintains, a message to a colleague, a call made out of hours. From outside you can see that cases end there [THREADS n=10], never what happens around them, and a workaround in daily use is part of the current process whatever the documents say. If the answer is that the case simply waits, write that down too.

7. Which release, and when does the decision expire

Scope questions asked without a date come back as assumptions. The register carries this one as 30 April 2026 with a fallback for the day after. The sentence worth agreeing in the session is that fallback, not the intention to decide soon.

8. How long do you keep it

The 90 days in my draft is mine: I chose it, found no basis for it anywhere public, and tagged it so nobody inherits it by accident [MINE, OPEN, OQ-01]. It is the one question here whose right answer is somebody else's job, and where guessing produces a document that looks finished and is quietly wrong. Legal owns it, and the fallback is the shortest defensible period, escalated rather than absorbed.

What if you only get fifteen minutes?

Plan the short version before you need it. Take three: question 3, then question 1, then question 5.

Question 3 first because it can end the project, and an early no costs less than a late one. Question 1 second because more rows in the register depend on its answer than on any other: BR-07 status, the escalation in REQ-015 and the published wording all move with it. Question 5 third because it is the only one of the eight whose answer arrives from outside the room you are in, and because it costs one sentence to ask.

The other five survive being asked by email. Those three do not, because each of them needs a follow-up in the same breath.

What do you write down while they are talking?

Three habits, all of them cheap, all of them worth more later than they feel at the time.

Record the wording, not your summary of it, for anything that will become a rule. "Aims to resolve within five working days" and "must be resolved within five working days" are one word apart and produce different documents. Your paraphrase always drifts towards the version that suits your draft.

Tag the answer with the session and the date. The pack's provenance convention is built for exactly this: add a tag of your own, [INTERVIEW 2026-05-12], in the same line as the claim. The worked case carries no such tag anywhere, because it had no interviews, and that absence is visible on every page. An unattributed answer is a fact nobody can check, which is what the convention exists to prevent.

Write down what you did not get. The vague answer is more useful in your notes than the clear one, because it is the one still open in six weeks. Same three columns as the register: owner, date, and what happens if the date passes.

The review log on this case records two sessions with peer reviewers, on 2 and 6 April 2026, five objections in total. Neither reviewer works for the retailer and neither session was an interview with anybody inside it, which the log says on its face. Keep the two kinds of session apart in your own notes, because a reader who cannot tell them apart has to assume the weaker of the two.

The blank version

Copy the table, fill in the middle column first, and only then write the questions. Working in that order stops you from importing somebody else's agenda into your own document.

Two rules for filling it in. If columns four and five say the same thing, cut the row: the answer changes nothing, so the question is curiosity rather than analysis. If column six is empty, you do not yet know what the answer is for, and asking it will produce a note rather than a decision.

Then order the rows by which answer would change the most, and mark the top three. Those are the ones you ask when the meeting turns out to be fifteen minutes.

Where to start

Take the document you have now and read only your own tags. The inferences you made and the slots you left open are your first draft agenda, and it is more specific than any published list of interview questions, including this one, because it is about your case.

Then run the artifacts through the scorecard: twenty-five yes-or-no checks, free, no email address asked for, and check 05 is the one this habit answers to. The worked case and the six blank templates are in the Proof Pack. If your stakeholder map is still a list of job titles, the map that survives contact with the project is the piece to read before the session, and the questions a reviewer asks is what happens to your notes afterwards.

Six of the eight above are the open questions in my register, all eight are unanswered, and they will stay that way: the case is built from public sources on purpose and nobody at that retailer is going to be asked. That is the price of a case anybody can check. With access you can close in one session what I cannot close at all, and having closed it, with a name and a date beside the answer, is most of what a reader is looking for.

One thing straight before the method. That standoff is the shape of the conflict, not a meeting I am reporting, and it is certainly not a scene from the returns case published on this site. That case has no client, no meeting and no interviews, and nobody inside the retailer was asked anything, so nobody argued in front of me there. What it does have is the thing underneath a conflict like this one: a published 40 EUR threshold whose owner I could not find anywhere public, carried in the register as an open question rather than filled in with a plausible department.

In short

• Conflicting requirements are a decision, so the question worth asking is who gets to make it, not who is right.
• Most of them dissolve on one question: what happens if you do not get this?
• Three signals say the argument is standing in for a missing owner: nobody can name who set the rule, the argument restarts instead of resuming, and both sides hand the choice to you.
• The card that moves it off your desk: what is disputed, the options, the cost of each, your recommendation marked as yours, a named decider, and a date with a consequence attached.

For years I read a standoff like that as a communication problem. Get them in a room, find the common ground, keep the temperature down, leave with something everyone can live with. It sometimes worked, and I could never explain why.

It worked on the days the disagreement was not real. When it is real, the room has nothing to decide with, and neither do I. I have no authority to resolve it, and neither does anyone else who is likely to be sitting there. What I owe instead is a name for the thing being decided, an honest price on each option, and a form the decision can be taken in.

Is this conflict real?

Most of what arrives as a conflict is two people defending solutions whose underlying needs do not actually clash. Nobody has said the needs out loud, so the solutions do the arguing. One question separates the two: what happens if you do not get this?

Finance is not defending 40 EUR. Ask what breaks without it and the answer is that below some order value the manual check costs more than the refund it is checking. The number is a proxy for that sentence. Customer care is not defending "no threshold" either. Ask the same question and you get a customer with a damaged 30 EUR item, told the policy has nothing for them, calling three times.

Written that way, the needs stop excluding each other. If the check below the threshold stops being manual, the cost the threshold protects against goes with it, and so does most of the argument.

There is a step before that, and in the returns case published here it was the whole job: nobody could produce a reason for the number. The threshold appears in the published policy and in two help centre articles, always worded as a hard rule, and nowhere does anything say why it is 40 rather than 25. You cannot price options against a rule whose purpose nobody can state.

Only when the needs still exclude each other do you have a real conflict. Then it is a decision, not a discussion.

Three signals the conflict is fake

Fake does not mean insincere. It means the argument is standing in for something else, and that something is usually a process with no owner.

1. Nobody can tell you who set the rule, or when. The rule is published, the owner is not. Two departments are arguing over a threshold neither of them chose, defending a decision made by someone who has left, or never made deliberately at all. In my worked case it sits in the register as an open question with my own name against it: until it is answered, neither position can be taken seriously.

2. The argument restarts instead of resuming. A conflict with an owner resumes: we decided this in March, the reason was this, what changed? A conflict without one begins at zero every time, often with different people in the chairs. No record of the last round means there was no decision in the last round either.

3. Both sides ask you to decide, and then accept whatever you say. This one arrives disguised as trust. Two directors who genuinely disagree do not both hand the decision to the analyst. What they are handing over is not the choice, it is the consequence. Take it and you own a rule you cannot defend in six months, and the complaint lands on your desk rather than theirs.

When those show up, do not facilitate harder. Put the vacancy into the card as the first thing that has to be decided: who owns this rule.

The card I send when requirements conflict

One page, written before the meeting and sent ahead, so the room argues about the options instead of about what somebody said last time.

Filled in, on the threshold:

That card comes from the returns case published here, which is built from public sources. Both positions are reconstructed from a policy and two help centre articles rather than quoted from interviews, and the costs are inferences marked as inferences. On a live project you would have the quotes and the volumes. The card looks the same.

Four rules for filling it in.

Do not average. "Let us say 25 EUR, it is roughly in the middle" produces a number nobody chose, nobody can explain and nobody defends six months later. Splitting the difference usually fails both of the needs it was assembled from.

Do not leave a cost cell empty. The empty cell is where the decision goes wrong. Fill it, or write the open question with a name and a date against it.

Do not let the date be decorative. Write what happens when nobody answers, and make it something the owner would rather avoid.

Keep the card after the decision, with the answer written into it. Six months later somebody will ask why partial refunds stop where they stop. "Card of 30 April, decided by the owner of the published promise, reasoning in the register" ends that conversation. It does not answer who set the threshold originally, which no public source says and my register still leaves open. Silence starts a new one, on worse terms, with people who were not in the room the first time.

The row that fails most often is "who decides", and it fails earlier than this card does. If your map of the project holds job titles instead of decision rights, there is nothing to put in that cell, which is the argument in the note on the stakeholder map that survives contact with the project.

What would a reviewer say about this card?

"Your recommendation is you deciding, with extra steps"

Partly fair. The recommendation is not neutral, and hiding that would be worse, so it is labelled as mine and sits under the options rather than above them. The test: write the option you did not recommend well enough that its owner would sign your description of it. If Option A reads as a strawman, you wrote a decision and dressed it as a card. The second test is what happens afterwards. Record the decisions that went against your recommendation, in the same file, in the same tone, with no commentary. A register in which the analyst always turned out to be right is a register nobody believes.

"This is bureaucracy for a five minute conversation"

Usually right. Most disagreements are cheap, reversible and settled by two people at a desk, and putting a card in front of those is how an analyst becomes the person meetings get scheduled around. My rule: would reversing this after the build cost more than a sprint, or has it already come back twice? Then it gets a card. Otherwise one line in the log, which is enough to stop the third rerun.

"You do not have those cost numbers"

Often true, and truest early, when the numbers sit inside a system I cannot reach. The answer is not an invented figure and it is not a blank. It is "unknown, two days of queue data would answer it, owner me, by 12 March", written into the cost cell. That does two things a guess cannot: it puts a price on staying undecided, and it gives whoever owns the data a reason to release it. More than once the measurement closed the argument before the meeting happened, because one option turned out to cost almost nothing.

The part that stays

The threshold argument was never about 40 EUR. It is about which department absorbs the cost of a case nobody wants, and that is a question about the business, not about the requirements document.

An analyst who settles that quietly, by picking whichever option is simpler to build, has taken on a responsibility nobody gave them. Writing it down, pricing it and handing it to the person whose job it is looks like less work and is the harder thing.

Take the disagreement your project has been carrying for a month and put it on one page tonight: what is disputed, the options, what each one costs, your recommendation, the named person who decides, the date. If you cannot fill the "who decides" cell, you have not found a conflict. You have found a vacancy.

A use case is a description of how an actor and a system interact to reach a goal, written as a numbered sequence of steps together with every way that sequence can go differently. The second half of that sentence is where the work is, and it is the half that arrives empty.

In short

• The main flow is the version everyone already agrees on, which is why writing it feels productive and costs you nothing.
• The value sits in the branches: the variations that still reach the goal, and the exceptions that do not.
• In the worked case below the main flow is six steps and the exceptions run to fourteen, roughly the proportion I now expect to see.
• Every exception should carry a source. Published rule, observed complaint, or your own inference labelled as one. An exception with no provenance is a guess with a delivery date attached.

The worked case here is returns and complaints at a mid-size online retailer, built from public sources only: the published returns policy, the help centre articles, and ten public complaint threads I selected myself. No engagement, no client, no interviews, no workshop, and nobody at that company was asked about anything. Where a branch comes from my own reasoning, the document says so on its face.

Why does nobody argue about the main flow?

Because the main flow is the story the business tells about itself: the version on the marketing page, in the onboarding deck, in the sponsor's head when they approve the budget. Everyone is carrying the same picture of it, so reading it back produces nods rather than questions.

Disagreement needs a branch. It appears the moment you ask what happens when the warehouse says the item came back used and the customer says it did not. There is no shared picture of that, because most people in the room have never had to hold it.

A thin exception section costs you three things, all after you have left the document. The developer invents the missing branch at the keyboard, choosing whatever is cheapest to build. The tester cannot test a case with no stated outcome, so it ships untested. And the stakeholder who would have caught the gap never sees it on a page.

UC-03: Return an item bought online

Read this for the proportion before you read it for the content.

Actor. Customer (primary). Supporting: returns handling system, carrier, warehouse, payment provider.

Goal. Send back a delivered item and get the money back to the instrument that paid for it.

Precondition. The order is delivered, the customer can identify it, and the item is not in a category the published policy excludes from return.

Trigger. The customer decides to send the item back.

Main flow

1. The customer opens the delivered order and selects the line to return.
2. The customer picks a return reason from the list and submits the request.
3. The system checks the line against the return rules and accepts the request.
4. The system issues a return id and a shipping label.
5. The customer sends the item back; the warehouse receives it and records its condition as matching the stated reason.
6. The system refunds the line to the original payment method and closes the return with an outcome and a reason code.

Postcondition (success). The item is back in stock or written off, the refund is recorded against the paying instrument, and the return closes with a reason code that can be counted later.

Alternative flows (the goal is still reached)

• 2a. The customer chooses an exchange. Step 6 issues a replacement order, and the return closes only when the replacement is dispatched.
• 4a. The customer has no printer and uses a drop-off point with a code instead of a label. The return id is unchanged.
• 6a. The order was paid partly with store credit. The refund splits across instruments in proportion, and the split is shown before it is made.

Exceptions (the goal as stated is not reached)

• 1a. The order is outside the return window published in the policy. Refused, showing the window and the delivery date, with the statutory withdrawal right stated separately so the refusal cannot swallow it.
• 1b. The line is in a non-returnable category. Refused, naming the category and the clause rather than showing a generic block.
• 1c. The person holding the item is not the account holder: gift, guest checkout, someone acting for a relative. Out of scope for release 1, with a route to support and the exclusion written into the scope section, not left implied.
• 3a. The item arrived damaged or the wrong item was sent. The request leaves this use case for the complaint flow, where the customer does not pay return shipping.
• 3b. The parcel never arrived. There is nothing to return, so this use case does not apply and the non-delivery flow owns it.
• 4b. The label is issued but never reaches the customer, so the return sits with no movement. After the period in the policy it goes to a named owner who re-issues, and the customer hears from someone before the window closes.
• 5b. The parcel is lost in transit. The customer holds proof of postage and no item exists to inspect. The carrier claim runs in parallel and the refund decision does not wait for it.
• 5c. The warehouse records a condition that does not match the stated reason: used, missing parts, a different item in the box. The return stops. A named owner decides, the customer is told what was found, and the evidence is recorded with the decision.
• 5d. Nothing arrives by the deadline. The return closes as not received, with one notice beforehand and a route to reopen it.
• 5e. Two lines arrive under one return id, or one id arrives split across two parcels. Each line is resolved on its own; the return closes when the last one has an outcome.
• 6b. The paying card has expired or the account is closed. The refund cannot follow the original instrument, so it needs an alternative and a check that the alternative belongs to the same person.
• 6c. The provider declines the refund. That is a failed refund, not a completed return, and it needs an owner, not a retry loop.
• 6d. The line was bought under a discount applied across the whole order. Refunding it changes what the rest qualified for. Either the discount is recalculated or the rule says it is not, but somebody has to say which.
• 6e. A refund already exists for this line. The second request is refused, and the refusal names the first so nobody has to phone anyone to find out why.

Count the lines. Main flow six, alternative flows three, exceptions fourteen: about three times the space, and not padding. Every exception ends in an outcome you could write an acceptance criterion against, which is a harder standard than listing what could go wrong.

Where does each exception come from?

Every branch traces to one of four places. P is the published policy, H the help centre articles, T the ten complaint threads I picked, I my own inference.

Three of the ten threads I read ended in a condition dispute. That is a count of ten threads I picked myself, not a rate, and it is my own tally from those threads rather than a figure carried in the published case, which counts a different thing: four of the ten ended with nobody owning the case at all. Enough to know the branch exists, nowhere near enough to know how often.

The rows marked I are the interesting ones. Five of the fourteen rest on nothing public at all - 5d, 5e, 6b, 6c and 6d - and they came from reading the main flow one step at a time and asking what else can happen here. No interview would have produced them either: they are the cases nobody owns, which is why they end up unowned in the live process too.

The blank version

Copy this. The hints in square brackets are the parts that go missing first.

UC-[nn]: [verb + object, from the actor's point of view]

Actor:          [primary actor, then supporting systems]
Goal:           [what the actor has when this succeeds]
Precondition:   [what must already be true; if you cannot check it, it is a step]
Trigger:        [the event that starts this, not the screen it starts on]

Main flow
1. [actor does something]
2. [system responds]
6. [end state in business terms, not a screen message]

Postcondition (success): [what is now true, and what can be counted]

Alternative flows  [same goal, different route]
- [step]a. [variation] -> [where it rejoins the main flow]

Exceptions  [goal not reached; expect two to four per main-flow step]
- [step]a. [what goes wrong] -> [outcome, and the named owner who holds it]
            [source: policy / observed / inferred]

Out of scope on purpose: [the exception you excluded, and why]
Open questions: [question, owner, date it is needed by]

The last two lines are the ones I used to leave off. An exception you excluded on purpose is a decision. An exception you never noticed is a defect with a release date on it, and from the outside the two documents look the same.

Which questions generate the exceptions?

I do not find branches by staring at the flow. I run these against every step and stop when a question produces nothing twice running.

1. Is the actor who the system thinks they are? Gifts, guest checkout, someone acting for a relative.
2. Does the thing still exist in the state this step assumes? Already refunded, cancelled, or returned once.
3. What if the step happens twice? Double submit, two parcels, a retry after a timeout.
4. What if it never happens? Every wait needs an ending: a period, an owner, and one notice before it closes.
5. What if it happens partly? One line of three, a split payment, a parcel with an item missing.
6. What if the other side says no? The provider declines, the carrier loses it, the warehouse disagrees.
7. What does the law say where the policy says otherwise? Published rules do not override statutory rights, and the refusal message is where that goes wrong.
8. What if the actor changes their mind halfway? Started a return, now wants an exchange; posted the parcel, now wants to cancel.
9. When the flow stops, who is holding it? If the answer is a shared inbox, the case has just stopped being anybody's problem.

Question 9 is the one that changes documents. Every branch that ends without a name is a branch that will end without a decision.

Take a use case you have already written. Count the main-flow steps, count the exceptions, and if the second number is not the larger one, you wrote the easy half and stopped. Run the nine questions down the flow and watch the proportion move.

The returns case this use case is written against, with the register its criteria feed, is the worked case on this site. The pack carries the process models and the register rather than a use case document, so the flow above is the same material laid out the other way. That register is one of the six artifacts a reviewer looks for, and the outcomes in the exception list are where its acceptance criteria come from.

Nothing in that sentence looks expensive. It takes a step away. It makes the form shorter. In a corridor you would say yes to it in four seconds and mean it.

A traceability matrix is a table that ties each business rule to the requirements that carry it, each requirement to its acceptance criteria, and each criterion to the test that proves it, so that touching any one of them shows you what else has to move. Produced as a deliverable and filed, it is a table nobody opens twice. On a Thursday afternoon it is the difference between an answer and a fortnight of finding out.

The case underneath this is my own: returns and complaints at a mid-size online retailer, built only from the published returns policy, the help centre articles and ten public complaint threads I picked myself. There was no engagement and no client, nobody at that company was interviewed, and nobody there has been asked about anything. The change request above is one I wrote against my own case on purpose, to see what the matrix would catch. Waiting for a real request to find out whether your matrix works means finding out while you are answering it.

In short

• A change request rarely lands on a requirement. It lands on a mechanism, which lives in an acceptance criterion, and the matrix is what walks you from there up to the rule and down to the tests.
• Fifteen minutes of matrix gets you a list of consequences: which criteria die, which tests retire, which get rewritten, which rows are untouched. The untouched ones are half the value.
• The rows worth having are the ones people leave out: rules you inferred rather than read, things you excluded on purpose, and open questions with a due date. A change request reopens exactly those.
• It gives you impact, never judgement. Whether the change is a good idea, what it costs and who will fight it are three other conversations, and the matrix answers none of them.

Where does one sentence actually land?

Here is the part of the matrix the request touches. Six rows, five columns, no tooling.

Set a timer. The walk has four moves and none of them is clever.

Minutes one to three: find the noun

The sentence contains one concrete noun, photo, so that is what I search on. Four rows come back: AC-014-01, the pre-check in REQ-018, the scope exclusion, and OQ-01.

Notice where the request did not land. It never touched a requirement statement. Customers still need their money back for a damaged item, and REQ-014 says so without mentioning a camera. What the request actually edits is the first row: evidence collected before a human sees the case, which is not a published rule at all. It is a design decision of mine, tagged as mine, and the whole to-be stands on it. Ninety seconds in, the shape of the answer has changed: this is not a form tweak, it is a change to the decision the automated pre-check was built around, and that decision has nobody outside the document to confirm it.

Minutes four to seven: read upwards

From the criterion to the requirement to the rule.

AC-014-01 dies outright. There is no upload, so there is no upload limit to test. REQ-014 survives with a smaller criteria set. REQ-018 survives too, and that is the row worth slowing down on: the pre-check reads the delivery date and the order value, neither of which comes from a photograph, so it still approves the easy cases. What changes is the pile it does not approve. Those go to a person with no evidence attached, which puts the judgement the as-is model was criticised for, one agent deciding whether the evidence is enough with no written test, straight back where it was.

Then the answer nobody asks for and everybody wants: AC-014-03 and BR-11 are untouched. The partial refund threshold has nothing to do with photographs, and I can say so with a row behind me instead of a feeling. Naming what does not move is what stops a one sentence request from becoming a full regression pass, and it is the half of impact analysis people skip because it feels like saying nothing.

Minutes eight to eleven: read downwards

Criteria point at tests, and tests are where the estimate lives.

TC-014-01 and TC-014-02 retire. That is the cheap kind of consequence. TC-018-01 is the expensive kind: it does not retire, it gets rewritten, because its precondition assumed a case arrives with evidence attached and now a case can arrive with nothing in it. A test that was passing before the change and passes after it, while checking something different, is the failure mode that survives a whole release. Rewritten tests need a name against them for that reason, and the owner column already has one.

Then the owner column earns its place a second time. Every row that moves is mine, and that is the uncomfortable part rather than the convenient one: the thing this change edits was never published, I decided it, and I have nobody to confirm it with. The published rules in the table, BR-04 and BR-11, do not move at all, and their owner slot has been open since the register was written, OQ-03. In an engagement that sentence names an approver. Here it names an open question, which is the same job done with less authority.

Minutes twelve to fifteen: read sideways

Everything else that points at the evidence decision. This is the move people miss, and it is where the matrix pays for itself.

The scope exclusion is there. Non-delivery and lost parcels were excluded from scope in review, RL-04, and the reason written into the row is that there is nothing to photograph when a parcel never arrives. Make photos optional and that reason evaporates. The request quietly reopens a scope decision that a reviewer forced me to make, and the group it affects is the one least able to argue about it. Without the row, that comes back during build as a defect with somebody's name on it. With the row, it is a line in a Thursday afternoon reply.

OQ-01 shrinks rather than disappearing. Optional photos still means some photos, so the retention question stays open, with a smaller volume behind it and the same due date.

What you can send at the fifteen minute mark

One requirement narrowed, one criterion dead, one requirement whose easy half survives and whose hard half lands back on a person, two tests retired, one test rewritten with a name against it, two published rules confirmed as untouched, one design decision of mine now needing a decision it never had, and one scope exclusion reopened with the reason it was made.

That is a consequence list. It is not a recommendation, and the difference matters when you send it.

What does the matrix refuse to tell you?

This is the part tool guides leave out, and it is the reason a matrix disappoints people who expected more from it.

Whether the change is a good idea. Impact is not judgement. The matrix will walk you cheerfully through a change that halves the evidence quality on every case, and never once suggest that it is a bad trade.

What it costs. Three retired tests and one rewritten one is a shape, not an estimate. The people who build the thing own that number.

Anything that was never written down. A matrix knows the rows you gave it. The coupling in one developer's head, the arrangement agreed verbally, the report somebody built on your data without telling you: none of it is in the table, and reading the table harder will not find it. A matrix reduces surprises, it does not remove them.

Who will object. Consequences do not come with politics attached. The map of who can approve, block or quietly sabotage is a different artifact, and it is one of the six a reader looks for.

Whether the tests are any good. Every row having a test id proves that a link exists. It proves nothing about what the test checks. A matrix with full coverage and weak criteria is a tidy table over a soft product, which is why the criteria have to survive on their own terms before traceability means anything. That standard is a separate piece of work.

Whether it is still true. A matrix last edited three deploys ago is a map of a country that has since moved its roads. It ages faster than any other artifact you keep, because everything else changes underneath it.

The blank version

Copy this. The brackets are the hints, and the last three rows are the ones people delete when they are tidying up, which is exactly when they become useful.

How do you keep one without it becoming a second job?

Five habits, and none of them requires a tool.

One row per criterion. Requirement level rows look tidy and answer nothing, because the mechanism a change request names always sits one level down.

Ids are the product. Renumbering is how a matrix dies. Retire an id, never reuse it, and never renumber to close the gaps.

Edit it in the same sitting as the change. A matrix maintained in a Friday catch-up pass is wrong from Monday to Thursday, which is when the requests arrive.

Keep it in the same file as the register. Two files drift. One file with a table at the end survives handover to someone who has never heard of you.

Mark inference on the face of the row. Published rules and your own decisions behave differently under a change request, as BR-11 and the evidence decision did above, and you will not remember which was which in six weeks.

Take one requirement you already have and write its row: rule, criterion, test, owner, sources named. Then write a one sentence change request against it, the kind that would arrive on a Thursday, and time yourself walking it through. If the walk takes longer than a quarter of an hour, the missing pieces are the columns you skipped.

Traceability is check 01 in the scorecard, which is twenty-five checks you can run on your own case before anybody else runs them on you.

A success measure is a statement about a future observation, written so that at least one possible result counts as failure. A line that no result can contradict is decoration, and decoration is what most of these sections are made of.

There is one question that separates the two, and I ask it out loud, of every line, in the room where the document is being reviewed: what result would mean this did not work? Not what we hope to see. What we would have to see to admit the thing failed. Lines that get an answer stay. Lines that get a pause and a rewording of the same sentence come out.

In short

• A project without a measure that can fail does not get cancelled. It ends when attention moves somewhere else, and nobody has to say so.
• Three of the five measures below fail the test, and one of the three fails while carrying a percentage, which is how the appearance of rigour survives review.
• One of them is perfectly falsifiable and still does not belong in a business case, because it measures whether we shipped rather than whether it worked.
• A missing baseline calls for writing the measurement first and the target second, with a name and a date against the target, rather than for softer wording.

Why does the test ask for failure rather than success?

Because success never lacks witnesses. Any project that runs long enough produces a screen that exists, a launch date that happened and somebody willing to say the new thing is better than the old one. If your measure is satisfied by that, it was satisfied before you wrote it.

A measure earns its line by ruling something out. It has to name a world in which the money was wasted, in terms specific enough that a person who was not in the room can look at a report and say yes, that happened. The same property is what makes a non-functional requirement worth reviewing: a threshold with no way to miss it never gets built to.

And it explains why these sections sail through approval. A measure that can fail is a measure somebody will be asked about in eleven months, so it gets argued over now. A measure that cannot fail costs nobody anything, so it gets a nod. Read the silence in that review as the absence of anything at stake rather than as agreement.

What this example is built from

The returns case published here covers returns and complaint handling at a mid-size online retailer. The material is the published returns policy, the help centre articles, and ten public complaint threads I selected myself on a date I wrote down. There was no engagement and no client. I have never seen a queue export, an analytics account, a support rota or a cost line from that company, and I am not going to pretend otherwise in the middle of an article about honest measurement.

So every figure below is one of two things: a count of my own reading, labelled as one, or an assumption of mine with the source it would have to come from and the person who would confirm it written beside it. None of them is a fact about that retailer. That constraint is not a disclaimer bolted on at the end, it is the situation you are in every time you write a success measure before anybody has given you access, which is most of the time.

Five measures, one question each

These are the five as they arrive, in the wording documents actually use.

1. "Improve the customer experience around returns."

What result would mean this did not work?

There is not one. Any post-launch survey supports it, any single grateful customer supports it, and a flat result gets explained as too early to tell. There is no observation that this sentence forbids.

Out. Not because the intention is wrong, but because the intention is all it is. It can stay as the goal line above the measures. It cannot occupy a row in the table.

2. "Reduce operational costs by 15%."

What result would mean this did not work?

Costs come down 9%. That answer arrives quickly, and it is why this line survives most reviews. Then the follow-up: 15% of what, on which cost line, over which period, produced by whom? On this case nobody could name the report, because I have never seen one. If nobody can produce the number, nobody can produce the failing number either, and the measure is exactly as testable as the first one while looking like arithmetic.

Out as a measure, in as an open question, with an owner and a due date before build starts. When the answer arrives it comes back as a measure, carrying the name of whoever pulled the figure and the date they pulled it.

3. "Deliver the returns portal by the end of Q3."

What result would mean this did not work?

It ships in November. Instant answer, unambiguous, checkable by anyone with a calendar. This measure is falsifiable and it still does not belong in the success measures section, because it tests whether we did the thing, not whether the thing worked. A business case that counts delivery as success is finished on the day the code ships and can never be wrong after that.

Out of this section, on to the plan, where dates belong and where nobody mistakes them for value.

4. "Fewer damaged-delivery cases end up with nobody handling them."

What result would mean this did not work?

The share of damaged-delivery cases with no named owner after the first contact is the same or higher two months after launch than in the period we measured before it. Specific, produced by an export, and an answer somebody would have to live with.

Survives, and needs rewriting. As written it has no baseline, no target, no date, no owner and no counting rule.

5. "Reduce the number of support contacts per refund case."

What result would mean this did not work?

Contacts per case flat or higher after three months. Also a real answer. This one carries a second problem worth keeping visible: it can be met by making support harder to reach. A measure that can be satisfied by damaging the thing it stands for needs a companion that catches the cheap win, otherwise the honest team and the team gaming it file the same report.

Survives, paired with a guardrail.

Three of the five are out, and the one carrying a percentage was among them. That ratio is normal once the question gets asked of every line rather than only of the ones that already look weak.

The two survivors, written out

SM-1  Share of damaged-delivery cases with no named owner after
      first contact.

      Counting rule: cases opened under the damaged-delivery
      reason in the month, divided into those that have a named
      handler recorded against the case at the point of first
      response and those that do not.

      Baseline: not measured today. The nearest thing I have is
      that four of the ten public complaint threads I selected
      end with nobody named on the case after the first contact.
      That is a count of ten threads I chose myself, it is not a
      rate, and it says nothing about how often this happens in
      the queue. The real baseline comes from two weeks of queue
      export before build starts.

      Target: at or below one in ten, held for two consecutive
      months. This figure is my assumption and nothing else. It
      is a placeholder until the two-week measurement exists,
      and the number that ships is the one the returns queue
      owner sets against that measurement.

      This has failed if the share in either measured month is
      at or above the baseline, or if the queue is still not
      being measured at all two months after launch.

SM-2  Support contacts per refund case.

      Counting rule: contacts logged against a case id, divided
      by cases closed in the same month.

      Baseline: unknown. No public source carries contact
      counts, and I will not invent one. Same two-week export
      as SM-1, same owner.

      Target: below the measured baseline by month three,
      by a margin the support lead sets when the baseline
      exists. My placeholder margin is one fifth, marked as
      mine, and it has no evidence behind it.

      This has failed if contacts per case are at or above the
      baseline in month three.

SM-2G Guardrail on SM-2: share of started refund cases
      abandoned before a decision.

      This exists because SM-2 can be met by hiding the contact
      channel. If contacts fall and abandonment rises above its
      own baseline, SM-2 has not been met, it has been gamed,
      and the result is read as a failure regardless of what the
      contact ratio says.

What makes these usable is the last sentence of each one. If a measure does not end with a line beginning "this has failed if", it has not finished being written.

The artifact: six columns

Every surviving measure gets a row. Six columns, because those are the six things people argue about eleven months later.

And the same table empty, with what belongs in each cell.

Two of those columns do most of the work and both are usually missing. "Measured by" turns a number into somebody's job. "Counts as failure" is what keeps the other five honest, because a target with no failure condition beside it drifts on its own.

What goes into the table when there is no baseline?

This is the situation nearly every guide skips, and it is the normal one. The current figure is not collected, or it is collected in a way nobody trusts, or it sits with a person who will not hand it over until the case is approved. The tempting fix is to soften the measure until the missing number stops mattering, which is how you end up back at improving the customer experience.

Do the opposite. Make the measurement itself the first deliverable, and write it with the same six columns: two weeks of export, a stated counting rule, a named person, a date it lands. The target line then reads as a placeholder with an owner attached, in plain words: set on this date, from the first measurement, by this person, and my figure until then is X, which is an assumption and carries no evidence. When the baseline comes back and it is nothing like your placeholder, that is information the case needed before anyone spent money, not an embarrassment to be quietly reworded. The one move that is never available is a target with no baseline and no note, because the first real measurement then turns into a negotiation about whether the number was ever meant literally, and that negotiation is won by whoever is closest to the deadline.

One more thing is worth saying out loud in this position. If the queue is not measured at all today, the first result of the project is that it can be, and that belongs in the business case as an outcome rather than in a technical annex. It is also the honest answer to the sponsor asking why you cannot simply put a number in: I can, it will be mine, and the document will say so on its face.

Where to start

Open the last business case you wrote and read only the success measures. Ask the one question of each line and write the answer beside it. In my experience a third survive intact, a third turn into open questions with an owner, and a third were goals wearing a metric's clothes.

Give the survivors the six columns. That is twenty minutes of typing. The hour after it is the conversation about who owns the baseline export and when it starts, and that conversation is the actual work, the same way the counted problem statement in eleven edits is worth more than the ten edits around it.

The standard I hold my own documents to, success measures included, is the scorecard: a fixed list of checks across the six artifacts, versioned, free, no email address asked for. A measure that can come back false is the only kind that can also come back true, and a project that can be shown to have worked is a project that gets a second release.

In short

• A row earns its place when it finishes one of three sentences: can approve X, can veto Y, decides Z in practice.
• Every row carries a source, and "my inference, unconfirmed" counts as one, as long as it is written down instead of implied.
• The row that costs you month two is the one that loses something when the project succeeds, and no influence grid measures loss.
• The blank row is below, ready to copy, followed by three rows built only from public sources, so you can check every claim in them.

The grid takes ten minutes. Two axes, four quadrants, every name dropped somewhere on the square, and whoever lands top right gets a weekly meeting. I have drawn it, I have sat in workshops that produced it, and it has never once predicted the thing that later went wrong.

The axes are not the problem. The problem is that the grid answers a question nobody was going to ask. It tells me how much attention a person deserves. It never tells me what happens when that person says no.

Those are different questions and only one of them has consequences. "High influence, high interest" is a temperature reading. "Can refuse to sign the release" is a fact about the project I am standing in. The grid tells me how loudly to talk to someone. It never tells me whose no ends the conversation.

What turns a name into a row?

Take anyone on your map and finish one of these three sentences about them.

• Can approve X. Their yes is required. Without it, nothing ships.
• Can veto Y. Their no stops it, and enthusiasm everywhere else does not route around them.
• Decides Z in practice. Nothing on the org chart says so. They hold the outcome anyway, because the work passes through their hands.

If none of the three fits, you have recorded an interest rather than a decision right. Interests are worth knowing. They are not what the map is for.

The third sentence earns the artifact. Approvals and vetoes are usually written down somewhere, so a diligent reader finds them. The decision that happens in practice is written down nowhere, it is held by whoever the work physically passes through, and it is the one that turns up late.

Where do you know that from?

The second thing a row needs is evidence: where you know the first part from.

I fill it in because the stakeholder map is where I guess most and admit it least. Attitudes, fears, what somebody "obviously" wants - it all feels like knowledge, and most of it is a story I assembled from two meetings and a tone of voice.

Three answers are acceptable there. A document and the section it sits in. A sentence somebody said, and roughly when. Or "my inference, unconfirmed". The third is not a failure. Silence is, because silence is how a guess gets promoted to a fact by the second reader.

The last column does the same job from the other side. It holds the sentence a reviewer would use against the row, written down by me before they get to say it. It takes a minute per row and it is the cheapest way I know of finding out which rows I have grown attached to.

The blank row, and three filled in

Copy this. Seven columns, one row per person, hints in the brackets.

Here is the same table with the worked case in it. The rows come from the returns case published here: damaged-delivery refunds at a mid-size online retailer, built entirely from public sources - a published returns policy, the help centre, and complaint threads anyone can read. There was no engagement and no client, and nobody inside the company was asked anything, which is why the evidence column has to work hard. Two tags do the sourcing: [POLICY] is stated in the published returns policy, [HELP] in a help centre article.

Sixty to ninety minutes for a map this size, once the reading is done. Most of it goes into the last three columns, which is the honest way of saying that the first four were quick because they were half invented.

Half of that evidence column says "my inference, unconfirmed", and the version without those words would be worse. An inference marked as one is a question with somewhere to land. An inference typed as a fact is a trap set for whoever reads the document after me. The fix is not deletion, it is a line in the open questions register with an owner, a date, and a fallback for when the date passes.

The missing names work the same way. Each one stays an open question rather than turning into a plausible invention. An empty owner slot with a question against it reads as diligence. An invented name reads as something else, and it comes apart in the first interview, when somebody asks how you met her.

Which row loses something?

The head of customer care is the row that writes itself. That department owns the published promise, the change rewrites that promise, and on projects shaped like this one the owner of the promise is usually in the room from the first workshop. That last part is a guess about a room I have never been in. This case has no workshops in it, only documents.

The goods-in lead is the row I nearly did not write. The role appears in no approval flow that anyone outside the company can see. The published process still hands it the parcel, the judgement about whether its condition matches the claim, and the choice between the shelf and the scrap bin. That is a decision the published policy never mentions.

And the change I am recommending makes that position worse. Approving the refund from photographs, before the item arrives, moves every condition dispute past the point where the money is gone. Today the sequence protects that role by accident. My change removes the accident and replaces it with nothing. That is the sort of thing you want to find in your own document rather than in a meeting.

This is what the influence grid cannot do. On its axes the row is low influence and, until the first dispute, low interest. Bottom left, monitor, minimal effort. Every property the grid measures says ignore it, and the one property it does not measure says that under the change I am recommending, that inspection lands on a refund customer care has already communicated.

Read your own map with one question: which row loses something? If every row gains and nobody loses, you mapped the kick-off invite list, not the organisation. The resistance you meet in month two then arrives with no name on it, and you call it culture.

What to do with this on Saturday

Take a map you already have, from a real project or a case you built yourself. Add three columns and delete nothing.

In the first, write the sentence that person can say to stop or change the work. In the second, write where you know that from, including "my inference, unconfirmed" wherever it is true. In the third, write the objection a reviewer would raise against the row, in their words rather than yours.

Two things usually happen. Some rows turn out to be an audience rather than stakeholders and move to a list at the bottom. And one or two names appear that were never there, because the exercise makes you walk the process end to end and name every pair of hands.

The stakeholder map is the first of the six artifacts I look for in a portfolio, and the one people most often submit as decoration: twelve boxes copied off an org chart, ten minutes of work, nothing in it that could be wrong. Six rows with a decision right and a source behind each one take an afternoon and are hard to fake. The full worked case, with the register and the open questions behind these three rows, is in the Proof Pack.

The map is finished when a stranger can check every row in it without asking me a single question.

The case under this piece is the one I publish on this site: returns and refunds at a mid-size online retailer, assembled from the published policy, the help centre and ten complaint threads anybody can open. I had no client and no access. Nobody inside that company has been asked a question by me or on my behalf, which is why the matrix below carries roles and no names, and why several of its approval cells are unfilled on purpose.

A RACI matrix is a table with work or decisions in the rows, roles in the columns, and one of four letters in each cell: R for whoever does the work, A for the single role whose approval makes it count, C for whoever must be asked first, I for whoever is told afterwards. Almost everything published about it is a template for project tasks. This is the narrower use that bites: who approves a requirement, and who approves the rule underneath it.

In short

• Sign-off rows are artifacts at a version, never activities. The question that stops a requirements document is whose yes makes one sentence in it true.
• One A per row. Where no person can be named, the cell still carries the role, an open question id, a due date and the default that applies if the date passes.
• Every role in the chain can be absent, and each absence fails differently: a rule approved and never built, a policy page that stops matching the system, a decision unmade at the loading dock.
• The matrix creates no authority. It shows where authority is missing, while asking for it is still cheap.

Why do sign-off rows have to be decisions rather than activities?

The RACI that ships with a project plan puts activities in the rows: gather requirements, migrate data, run UAT. That tells you who is busy this month. It says nothing about the sentence in your register somebody will quote back at you in eighteen months.

Sign-off rows are artifacts and the decisions taken on them: this rule statement, this rationale, this criterion, this exclusion, this baseline. The difference appears the moment you fill in letters. "Write the business rules" has an obvious R and a woolly A. "BR-11 as written" has a precise A, and mine is a cell I cannot fill, which is worth knowing in April rather than in build.

The matrix, filled in, with no names in it

Columns come from the stakeholder map in the same case, seven rows written as decision rights rather than job titles. [OPEN] beside an A means the role is identified and the person is not.

One A per row, including the rows where the A is me. Where nobody could be named the letter still goes against the role. A blank cell would have been the easier lie.

Read the A column on its own. Six of the nine rows have an unclaimed A: a role identified, a person missing. This case can be written, reviewed and pulled apart, and nobody except me can baseline it.

Four unclaimed cells are the same absent person. My register tracks the gap at rule level, as OQ-02 and OQ-03, never at role level, so the Customer Care rows carry an open tag with no id behind it. Fifteen minutes of filling in letters found a hole four other artifacts walked past.

The chain: one rule, every role it has to pass

Here is the route BR-11 travels before anyone can rely on it, and what happens at each link when the role is absent.

1. The analyst, who writes it down (R)

In v1.1 my register carried the rule as one line: the number, nothing else. A business analyst reading it on 6 April 2026 asked "Why 40 EUR? Who set that?", and the answer ran to a page. The R belongs to whoever can give that answer in one breath, with the source, the status, the reasoning and the review trigger.

Absent: the figure survives as a law of nature, quoted for years and designed around, because nothing is written down to argue with.

2. Finance, whose yes makes the number real (A)

The threshold governs how much money leaves without a person looking at it, and the map gives the finance lead a veto over exactly that. I cannot name them, and typing in a job title to make the table look finished would have been the one line here a single phone call could take apart.

Absent: OQ-03, due before the register is baselined, with the default in the row: both rules stay with the A unclaimed, and neither threshold moves until it is claimed. Freezing the number is what an unclaimed A buys.

3. Customer Care, who lives with the wording (C)

The threshold is quoted at customers in the policy and in two help centre articles, and Customer Care owns the published promise. So they are C on the rule and A on anything that changes how it reads to a customer, which is why they hold criterion 3 of REQ-014 and the finance lead does not.

Absent: the system and the policy page stop agreeing, and the first customer to quote the page back at an agent runs the test for us.

4. The product owner, who owns the slot (A, one row down)

Approving a rule and making room to build the thing that enforces it are two decisions belonging to two people. This is where a two-name A cell shows up: "partial refunds in release 1" reads like one decision and is two. Split, it gives one A each, whether they are wanted (Customer Care) and whether there is room (product owner).

Absent: a rule approved and never built. The register says v1.2, agreed; the form still hides nothing and refuses nothing; and the gap stays invisible until an order under the threshold is offered a partial refund the policy forbids.

5. Goods-in, informed at best, able to undo it anyway (I)

The goods-in lead holds no approval right I can find. That role also receives the parcel, judges whether its condition matches the claim, and decides whether it is restocked or scrapped. On this matrix it is an I, and in the process it decides in practice. Finding a row like that is most of the reason to build a matrix rather than photograph the org chart.

Absent: the decision is unmade at the dock, after the money has gone. That is why REQ-017 exists, and why my one-page summary asks for whoever holds that role to be in the room before anything ships.

6. The frontline agent, who applies the rule all week (C, one row over)

No public source contains a written test for whether photographic evidence is "enough" [WALKTHROUGH], so the judgement sits with whoever picks up the case. On BR-11 the agent is an I. On BR-04, the fourteen day damage reporting window, the agent is the C I would fight hardest to keep.

Absent: the rule is enforced at a slightly different threshold by everyone applying it, and the first report to measure the variation gets read as a data quality problem.

7. Legal, absent here and able to stop the release anyway (A elsewhere)

Legal has no view on a refund threshold. They hold an absolute A one row down, on retention of the uploaded photographs, where the ninety day figure is mine and still open [MINE, OPEN, OQ-01]. A chain belongs to an artifact rather than a project, which is how a role can be irrelevant to eight rows and decisive on the ninth.

Absent: the answer is identical whenever it arrives. Asked early it costs an email. Asked after build it costs the build.

8. The customer, who has no column at all

The map gives the customer no right inside the company and one outside it. Four of the ten complaint threads I read were a customer escalating in public [THREADS n=10], which counts the threads I chose and measures nothing about the ones I did not read. Their veto arrives through a chargeback, a statutory claim or a review, months after sign-off.

Absent: they can be absent from the table and never from the process, and that is what makes the escalation look like bad luck.

What do you write when you cannot name the approver?

This is the normal condition on a case built from outside a company, on any project in week two, and on more mature projects than people admit. An unclaimed A worth writing has four parts.

The role, as a decision right. "Finance" approves nothing. "Whoever signs off refund policy in finance" is an approver with a missing name, which is a different thing to hand to the first colleague who does have access.

An id, so the gap lands in the open questions register instead of a table nobody opens twice.

A due date pinned to an event, because a date tied to an event survives a slipped plan: before the register is baselined, before build starts.

A default resolution. OQ-02 asks whether five working days is a promise or a target. If 30 April passes unanswered, it gets published as a target and the escalation hangs off my own window, which is mine to guarantee. Write the unattractive default; it is what gets an answer out of an organisation, and what protects the work when no answer comes.

The objection is fair and I have taken it more than once: a role with nobody behind it approves nothing, so the cell does less than I claim for it. What it does do is hold the position open, so the first person with real access fills it from a human being rather than from a guess.

Five ways a sign-off matrix stops working

Two A cells in one row. "We approve it jointly" resolves in practice to nobody having baselined it, and it surfaces the day somebody wants the decision reversed. When you cannot name one A, the row is cut wrong rather than the organisation being unusual, so split it. Where the two names disagree on substance, that belongs on a conflict card instead of in this table.

Everybody consulted. A C belongs to a role whose absence would make the decision wrong, rather than to one that would have liked to know. Ten C on a rule means it gets approved late and changed afterwards anyway, by the people consulted last.

Names in the columns instead of decision rights. One reorganisation and the matrix becomes a work of history. My case has the opposite problem and the same fix: decision rights in the columns, names in a list that changes without anybody reopening the table.

Approved once, then never re-read. Approval attaches to a version and expires with it. A change request that edits a rule statement expires the approval on every row tracing to it, and working out which rows those are is what a traceability matrix does in a quarter of an hour.

Treating A as seniority. The A follows the rule rather than the pay grade. Legal outranks nobody here and holds an absolute A on retention; the Head of Customer Care chairs the meeting and still does not own a money rule. The question that settles these arguments is not who is senior, but who will be asked to explain the decision in twelve months when it is quoted back at the company.

The empty matrix, hints left in

Fill the A column first, top to bottom, then go back and put a name against every letter in it. The rows where you cannot are the output. On an engagement each one is a meeting request with its agenda already written. Where the stakeholder map those columns came from sits among the other five artifacts is a separate piece; decision rights are checks 04 and 06 of the standard I hold myself to, free to run against your own case.

BR-11 still has an unclaimed A. It has carried one since 9 April, with a date and a default beside it, and the register says so on its face rather than in a footnote.

A review of a work sample is a sequence of questions asked in a fixed order, where each answer decides whether the reader asks the next one. That order is the thing nobody tells you about, and it is why a strong document can be closed after ninety seconds.

In short

• The read runs as a sequence with stoppers in it. A sample only reaches question four if one to three came back clean.
• The first two minutes go on provenance and on the decision you are asking for, which is why the summary page belongs at the front and the model does not.
• The review log answers the one question a finished draft cannot, and it is the artifact almost nobody sends.
• The filled table and the blank one are below. Run your own sample through the blank one before somebody else runs it through theirs.

What do reviewers look for in a BA work sample?

Not completeness. Completeness is easy to fake and boring to check.

What I am hunting for is seams. A document written by somebody who did the work has visible joins: a place where two sources disagreed, a number that got labelled rather than rounded, a branch added late because someone pushed back. One assembled from a template has none of that. Every heading present, every sentence smooth, nothing that had to be earned.

So the questions run in an order built to find seams fast and stop early when there are none. Below is how my own twenty minutes go. The clock is mine rather than a standard; the order is the part I would defend.

The reading order, filled in on the returns case

Two things there matter more than the rows.

Four of the seven stoppers are about honesty rather than skill, and three of those end the read before minute six: a detail you were not free to publish, a figure that turned out to be an invention, and a sample with nothing open in it. From outside a company, answering every question is not possible, so a sample with no open questions says you either missed the gaps or filled them with plausible guesses.

And the order is the reverse of the one you wrote in. You built the model first and the summary last. Lay the file out in production order and the first thing I open is a diagram with no argument attached to it.

Minute four: what does the review log say that a finished draft cannot?

A review log is a short table recording what somebody objected to, what changed as a result, and what did not change and why. Three to six rows, half an hour to keep, and it is the artifact I open before the requirements.

The reason is narrow. A polished draft tells me you can produce a polished draft. It cannot tell me what you do when somebody who knows more than you says the thing is wrong, and that is the behaviour being hired. A log answers it, and it is close to impossible to fake, because invented objections are soft. They are the ones you already knew how to answer.

Here is what came back on the returns case. Two readers, asked for objections rather than the compliment after a self-review against the scorecard: a developer on the delivery side who reads process models before registers, and a business analyst who reviews requirements documents for a living. Neither works for the retailer. Two sessions, 2 and 6 April 2026, five rows in all, and three of them show what a log does that a draft cannot.

Row one. "Your as-is is the happy path, so your to-be looks better than it is." The developer, ten minutes into a session that started with the model and never reached the register. My first as-is ran call, evidence, decision, refund, and stopped. What changed: the parked branch went on to the model, with no owner, no clock and its frequency marked unknown. That one sentence produced more than my own second pass had. REQ-015, escalation ownership, did not exist before it, and neither did BR-12, the rule naming who owns a missed window.

Row two. "A customer whose parcel never arrived has nothing to photograph." The business analyst, four days later. My proposed process routed everything through a form built around photographic evidence, which quietly made one group worse off, and it was the group least able to argue about it. What changed: non-delivery and lost parcels are out of scope now, with a reason and an owner. What did not: the placement. It went in the scope table rather than into a fourth acceptance criterion, because an exception you exclude on purpose is a scope decision and belongs where a reviewer will look for it.

Row three, the one that earns the table its fifth column. "Four in ten is a count, not a rate." I had ten complaint threads I picked myself, four of which ended with nobody owning the case, and two pages after my own source table called those threads unrepresentative, I had written a sentence about all cases. What changed: every use of the figure now names the denominator, the selection method and the date. What did not: the number. The stronger objection was to cut it and say only that the branch exists. A labelled count can be rechecked by a stranger in twenty minutes, and a shrug tells the reader less. The disagreement stands in the log, where a future reader can find out that somebody competent thought I was wrong.

The log closes with a line that takes ten seconds to write: v1.2, 9 April 2026, two peers, two sessions, five objections raised, four accepted, one held with reason. Set that against the seven questions above. It settles provenance, it dates the document, and it says the argument happened before the version in my hands. Three of the seven, at the bottom of a table.

The common failure is the log where every row was accepted. That shows compliance, and compliance is not what is being assessed. You can be wrong in the fifth column and still finish ahead of the person who has no fifth column.

The blank version, for your own sample

Copy this and run it against a document you have already written. Twenty minutes, alone, before anybody does you the favour.

The fourth column does the work. Fill in your stoppers before the answers, because the ones you cannot bring yourself to type are the ones a stranger reaches first.

Where to start

Take the sample you already have and do three things to it, in this order.

Move the summary page to the front and rewrite its first line so that it asks for a decision, names who makes it and carries a date. Add the log, even if the only reviewer so far is you two days later, marked honestly as a self-review. Then run it through the scorecard: twenty-five checks across six artifacts, free, no email address asked for, and check 20 is the one about holding your ground.

The worked case and the blank templates behind it are in the Proof Pack. If you are still deciding what to build, the six artifacts a reviewer looks for comes first.

Then send it to one person who will tell you it is wrong, and write down what they said before you answer them. Whatever lands in their first two minutes is what your reader was going to hit anyway. This time you get to fix it first.

A non-functional requirement is a measurable statement of how well a system has to work, and under what conditions, rather than what it does: how fast, how available, how secure, at what load. Measurable is the load-bearing word. With no number, no condition and no way to check it, what you have written is an adjective.

Non-functional requirements do not fail because they are technical, or because the team cannot handle percentiles. They fail because an adjective cannot come back false. Drop the number and the condition it holds under, and the sentence sails through review for the same reason it is useless: nobody argues with a promise that cannot be broken.

In short

• A line with no number, no condition and no measuring point cannot be met and cannot be missed, and nobody finds that out until production.
• The load figure sits with the engineer who was on call at the last peak and the supervisor who booked the extra shifts, not with the sponsor who names the ambition.
• Ask what the system withstood last time rather than what it should withstand. The past has a date and a witness; the future invites a wish.
• A threshold with no owner and no review trigger gets quietly relaxed by whoever sits nearest the deadline.

A requirement nobody can fail is a requirement nobody has to build. That is why adjectives survive every review and lose the first real peak.

The checks I run on acceptance criteria apply here too, and they are not enough on their own. A criterion asks whether one behaviour happened. A non-functional requirement asks how much of it the system holds under pressure, and that carries a cost somebody has to agree to pay.

Six that actually bite, as they arrive and as they go out

The case is the one I use throughout this site: returns and refunds at a mid-size online retailer, reconstructed from public material - the published returns policy, the help centre articles, and ten public complaint threads I picked myself. Nobody inside the company was asked anything. Every number below is therefore either mine and labelled as mine, or a placeholder for the figure your own evidence would put there, which is the position you are in every time you write these before anyone has handed you access.

The textbooks list more attributes than this, in a tidier order. These six bit on this case. Two more get a paragraph at the end, because a paragraph is what they were worth here.

Performance

Weak: The returns portal must be fast, even under load.

Fixed: The refund form confirms submission in under 2 seconds at the 95th percentile with 3,000 sessions active, measured in the browser, not at the load balancer. The 3,000 is my own estimate and the requirement says so on its face; where there is access, that figure comes out of analytics and carries the name of whoever pulled it, with the date.

What changed: fast picked up a number, a statistic, a stated load and a measuring point, and the load figure got a source.

The first thing a reviewer says to that is that I have swapped a vague requirement for a precise fiction, and more than once they have been right. A confident 3,000 with nothing behind it is worse than fast, because it looks defensible and gets built to. The answer is not a better guess. It is the label: a threshold carries the person, the date and the pull it came from, or it goes in as an open question and stays visible until somebody closes it.

Availability

Weak: The portal must be highly available.

Fixed: At least 99.9% availability per calendar month, measured 06:00 to 22:00 local time by an external check every 60 seconds against the refund form itself, not the home page. Maintenance announced 48 hours ahead and run outside that window does not count.

What changed: the nines got a window, a probe, a page worth probing and one written exclusion, so the monthly report means the same thing to both sides.

This is the line a developer declines to sign, and the refusal is fair: nines cost money and I am not the one paying for them. A demanding threshold goes in with the cheaper option written next to it and one sentence on what the business gives up by taking that option. Three nines and four nines are not two versions of the same sentence; they are two budgets, and the choice belongs to the person holding one.

Security

Weak: Customer data must be secure.

Fixed: Evidence photos are encrypted at rest and served over TLS 1.2 or higher. Every view of a customer's photo writes a log line with agent id, case id and timestamp, retained 12 months. No critical or high finding from the penetration test is open at go-live, and the release manager signs that line.

What changed: one adjective became three statements that can be shown to be false, and the last names the person who reads the report before release.

This is also where requirements start pulling against each other. Stronger authentication and fewer clicks want opposite things, and a conflict nobody writes down gets settled quietly at build time by whoever is nearest the code. Where two requirements pull like that, the pair gets a line saying which one wins, and who decided.

Usability

Weak: The refund flow must be intuitive and user friendly.

Fixed: A first-time customer completes a damaged-delivery refund in no more than four screens without contacting support. In the first month after launch, at least 80% of started cases reach a decision with no support contact logged against the case id.

What changed: a judgement nobody can fail became a count anyone can check, plus one outcome measured after launch, which is the half that usually goes missing.

That second half attracts the flattest objection of the lot: nobody will measure this after go-live. Often true, and fatal. An 80% target with no report behind it is a sentence in a file, exactly like an availability target with no monitor. Before I sign, every line of this kind names how it will be verified and who owns the dashboard or the report it lands on.

Compliance

Weak: The solution must be GDPR compliant.

Fixed: Evidence photos are deleted 90 days after the refund case closes, and the deletion is logged. A data subject request is answered inside the statutory window named by legal, not the one I remember. The 90 days is not mine to set: it goes in as an open question with the data protection officer as its owner and a due date before build starts, and when the answer comes back the requirement carries the rule id and the date it was confirmed in writing.

What changed: a regulation nobody can test against became two obligations this system can be tested against, with the deadline I am not qualified to state left to the person who is.

Scalability

Weak: The solution must be scalable.

Fixed: A new country is added by configuration - currency, returns window, address format - with no code change and no downtime. The architecture holds a fourfold rise in monthly cases over 18 months without re-platforming. Fourfold is a placeholder for a figure that lives in somebody's expansion plan; until it has that owner and that date, it stands as my assumption and is marked as one.

What changed: scalable got an axis to scale along, a price for adding the next country, and a note saying where the multiple has to come from before anyone builds to it.

Maintainability and browser support, kept short on purpose

Weak: The code must be maintainable and well documented. The portal must work on all devices and browsers.

Fixed: A developer who has never seen the repository runs it locally from the README in under an hour, and adding a new refund reason touches configuration and one module rather than four. Supported browsers are the current and previous major versions of Chrome, Safari, Edge and Firefox on desktop, plus Safari on iOS and Chrome on Android, drawn from real traffic rather than from anyone's preference, with a named owner and a quarterly review. Anything outside that list gets a plain message and the support number instead of an upload that fails without saying why.

These two share one entry for the reason a reviewer usually gives out loud: half of this belongs in the definition of done. Correct. The browser list holds for everything the team ships, so repeating it story by story turns it into wallpaper. Thresholds that change from feature to feature stay on the requirement; constraints that hold everywhere live in the definition of done, and the requirement points at them. Writing a full set of eight quality attributes because a textbook lists eight is how documents get long and reviews get skimmed.

Who actually knows the load figure?

Ask the sponsor how many people will use this at once and you get a figure that describes the ambition. That is not dishonesty. The sponsor sits furthest from the graphs, and their number is the one they would like to be true by next year.

The people holding the real figure sit two or three rungs down and are rarely in the workshop. The engineer who was on call knows what the system survived last time and the hour it gave up. The supervisor who staffs the support queue knows the week when volume triples, because they are the one booking the extra shifts. Somebody in marketing or operations is already sitting on the next peak without thinking of it as load at all: a campaign send, an enrolment deadline, a policy change with a cut-off date. All of them sit in a calendar weeks before they reach anybody's requirement. The infrastructure lead has last January in a dashboard and is almost never asked before the target is written. And on anything touching retention or reporting, the figure belongs to whoever would answer the regulator, not to the person who read the same summary of the regulation that you did.

None of them are hard to reach. They are simply not on the invitation list for the workshop where the number gets written, which is the whole problem: the target is drafted in the one room where nobody has the evidence.

So the question I ask is not how much this should withstand. It is: how much did it withstand last time, who was watching, and where is that written down. A wish has no author and no date. A past peak has both, usually with a graph attached, and it holds six months later when somebody wants the threshold relaxed: the conversation is then not my opinion against theirs, but a named person and a dated observation against a preference. And when nobody can answer at all, that is the finding. It goes in as an open question with a name and a due date, not as a round number chosen because the document needed one.

What makes a non-functional requirement testable?

Six slots. Every one I keep has them filled in, and the empty slots are where the argument goes once the system is live.

Template. X is number unit at statistic, under condition, measured by method at point. Set by name on date. Review when trigger.

Where to start

Open the last requirements document you wrote and read only the non-functional section. Count the sentences that could come back false. If the count is zero, that section was skimmed, not reviewed.

Then take the line that matters most and fill the six slots. Twenty minutes for the line. The twenty minutes after that are the phone call to whoever was on call last January, and that call is the actual work.

The scorecard I hold my own documents to is on the downloads page. It has no check aimed at a non-functional line, so do not go looking for one: the nearest two are 16 and 18, which ask a business rule who set it and what event would make it wrong, and those are the same two questions this page turns on.

"The current returns process is inefficient and causes customer dissatisfaction."

I have read that sentence, or one built to the same pattern, in more requirements documents than I want to count. It is not false. It is just not evidence of anything. Anybody can write it after ten minutes on the company website, which is the problem when the document is attached to a job application.

A business requirements document, a BRD, is the document that says what a business needs to change, why, and how anyone will know the change worked. Every line in it is meant to be checkable by somebody who was not there when it was written.

One limit before any of this is worth reading. I have never sat on the hiring side of the table, so I cannot tell you what happens to your document once it is submitted. What I can describe is the thing I actually do: pick up a document written by a stranger and decide, inside two minutes, whether I trust the person who wrote it. That happens on international projects, and again with the work people send me on the Polish training platform I run. Whether the first screen of a recruitment process works the same way is a guess, and it is the only claim here I cannot back.

In short

• The first version of the fragment below cannot be argued with, and that is the whole problem: not one sentence in it had to be checked with anybody.
• Count the problem instead of describing it, then say what the count is not, because four of ten complaint threads I selected myself is a count and never a rate.
• Give every business rule a source, and leave the owner slot open when no public source names one rather than filling it in with a plausible job title.
• Two of the eleven edits do most of the work in the first thirty seconds of reading: a counted problem statement, and a scope section with a reason beside every exclusion.

Who reads a BRD, and what are they looking for?

Your delivery team reads a BRD to build something. They need it complete. They will read every page, badly, over several weeks, and they will come back to you about the gaps because they have to.

A stranger deciding whether to interview you reads three paragraphs and stops. They are not auditing the document. They are looking for traces of thinking: whether you asked anyone anything, whether you noticed two rules contradicting each other, whether you wrote down what you did not know. Nobody is checking your BRD for completeness, and completeness is the cheap half anyway.

Complete and thought-through are not the same thing, and a document can be all of the first and none of the second. Most of what people send me has exactly that shape: every heading from the template present, and not one sentence that had to be earned.

What follows is a fragment of the worked case I publish here: returns handling at a mid-size retailer. There was no engagement and no client. Everything in it is built from published policy, help centre articles and public complaint threads, and every line says which. Read the numbers as a method, not as a finding about retail.

The fragment, the way it usually arrives

3. Business need

The current returns process is inefficient and causes customer
dissatisfaction. Customers must call support to request a refund,
which generates a high volume of calls and increases operational
costs. The business requires a modern, user-friendly solution to
streamline the returns process and improve the customer experience.

4. Scope

In scope:  refunds, returns, notifications, reporting.
Out of scope: TBD.

5. Requirements

BR-1  The system shall allow customers to request a refund online.
BR-2  The system should process refunds quickly.
BR-3  The system must be user-friendly and intuitive.

Nothing in there is wrong. Nothing in there can be argued with either, and that is the tell: no sentence in it had to be checked with anybody.

The same fragment after eleven edits

3. Business need

3.1  Four of the ten damaged-delivery complaint threads I read
     end with no named person owning the case after the first
     contact. Source: ten public complaint threads I selected
     and read between 12 and 21 March, with their dates. This
     is a count of the ten threads I chose, not a rate across
     all cases, and the true frequency cannot be known from
     outside until somebody measures the queue.

3.2  We are not trying to reduce the number of refunds. We are
     trying to reduce the number of cases with no owner and no
     clock. If refunds fall, that is a side effect I want to see
     explained, not celebrated.

3.3  This work is finished when the share of damaged-delivery
     cases sitting with nobody's name on them, once the queue is
     measured at all, stays under one in ten for two consecutive
     months, with the refund rate flat within one percentage
     point.

4. Scope

In scope:      damaged-delivery refunds for web store orders, from
               evidence upload to refund decision.
Out of scope:  change-of-mind returns (separate published policy,
               separate rules), marketplace orders (different
               terms, outside the returns policy), the accounting
               posting itself (unchanged by this work).
Not decided:   whether partial refunds ship in this release.
               Owner: Head of Customer Care, role identified,
               person not named in this case. Needed by
               30 April 2026. If nobody answers: out of
               release 1.

5. Business rules

BR-07  No refund case may stay open longer than five working days.
       Source: the help centre, which says the company aims to
       resolve returns within five working days. "Aims to" is not
       a rule, so the status stays open until somebody says which
       it is, and no public source names who owns the sentence.

BR-11  Partial refunds are allowed only above 40 EUR order value.
       Source: the same policy and two help centre articles, all
       three wording it identically. Rationale not published.
       My inference, marked as one: below 40 EUR the handling
       cost of a split refund plausibly exceeds what it recovers.
       I have no cost data. The inference and what would settle
       it sit in the rule register, for the rule owner to confirm
       or kill.

BR-12  A case that misses the decision window is assigned to a named
       person, not to a queue. Traces to BR-07: a deadline with no
       owner is a deadline nobody keeps and nobody breaks.

Note on the clock: the 48 h window in REQ-014 runs from the
timestamp on the submitted form, not from the moment somebody
opens the case.

Same document, same case. One version tells you nothing about its author. The other is hard to fake without having done the work.

The eleven edits

Five of them carry a note in the margin: the objection that edit has actually taken in review, next to the edit it hit. A clean list of improvements is the half that proves least.

1. Counted the problem instead of describing it. "Inefficient" is an opinion nobody can check. "Four of the ten threads I read" is a claim someone can repeat in twenty minutes and disprove, which is what makes it worth reading.

Objection I take on this one: "It reads like a data report now, and a director will not find the ask." Correct. In the full document one sentence sits above 3.1 saying which decision I want and by when. I left it out here to keep the contrast visible, which is a small dishonesty worth naming.

2. Named the source, the selection method and the denominator, and said what the number is NOT. A number with nobody attached to it is a rumour with a decimal point. A count dressed up as a rate is worse, because it survives the first challenge and collapses at the second.

Objection: "Ten threads you picked yourself are not a sample of anything, so why print the figure at all?" The stronger version of that is to cut the figure and say only that cases end up with nobody's name on them. I kept it, because a labelled count with a stated method can be rechecked by a stranger in twenty minutes and a shrug cannot. The disagreement is in the review log rather than resolved quietly in my favour.

3. Wrote down the anti-goal. Saying what I am not trying to improve stops the team optimising the one metric that would make the business worse.

4. Put the success condition next to the problem. A document that never says when the work is finished produces a project that ends when somebody gets tired.

5. Cut the solution language out of the business need. "Modern, user-friendly solution" names an answer before the scope is agreed, and every hour after that goes into defending it rather than testing it.

6. Replaced "Out of scope: TBD" with named exclusions and a reason for each. When I see TBD in a scope section I stop reading for content and start reading for who the author has spoken to. Usually the answer is nobody.

And here is the objection to the whole approach: somebody writing a portfolio piece has spoken to nobody either, and has no Head of Customer Care to name. True, and in this case it is deliberate: the entire study is built from public sources so that it can be published. Then say exactly that inside the document. "Public sources, listed, selection method stated" reads as competence. A borrowed logo and an invented stakeholder name read as something else, and I have seen both.

7. Split "not in scope" from "not decided yet", and gave the undecided item an owner and a deadline. They look similar on the page and behave nothing alike in a project, because one of them is coming back.

8. Replaced "quickly" with a threshold and the event that starts the count. Most of the argument about a deadline is never about the number. It is about which moment it runs from, and the vague version hides that there is a choice at all.

9. Deleted BR-3. "User-friendly and intuitive" is a requirement nobody can fail, so it protects nobody and takes up a line.

10. Gave every rule a source, and left the owner slot open where no public source names one. A rule with a name on it can be renegotiated. An anonymous rule can only be worked around.

    Objection: "An empty owner field is not an owner, so this edit does less than you claim." Fair. What it does do is keep the field visible, so the first person with access to the company fills it in from a person instead of from a guess. Writing "Finance" there because it sounds right would have been an invented fact wearing a name badge.

11. Wrote down the reasoning behind the 40 EUR threshold, marked it as my inference, and said where the working lives. The number is the least interesting part. The argument behind it is what stops it being changed in a corridor six months later.

    Objection, and I have earned this one more than once: "The line pointed at an appendix nobody had written." Guilty, which is why it now points at the rule register, where the reasoning actually sits. A citation to a document that does not exist is worse than no citation, because it buys trust the document has not earned.

There is a twelfth change I did not count, because it is a habit rather than an edit: the rules are numbered to match the register, so a reviewer's comment lands on one line instead of a paragraph.

Where should you start if you have one hour?

Take a document you already have and do edits 1 and 6 on it: a counted problem statement, and a scope section with a reason beside every exclusion. Give it an hour. In my experience those two change the first thirty seconds of the reading more than the other nine together.

The rest of the standard I hold myself to is on this site: the scorecard is twenty-five checks across six artifacts, versioned, free and with no email address asked for. The case this fragment comes from is in the Proof Pack, finished, with the review notes left in. If you want the requirement these numbers end up in, that is in the six artifacts piece.

Items can be returned within 30 days of delivery. Damaged or faulty items are refunded in full, including the original delivery cost. If you have changed your mind, the item must be unused and in its original packaging. Partial refunds are available on orders over 40 EUR.

Four sentences, nothing obviously missing. I read it twice and could not say what was wrong. Then I put it in a grid and by the third column it had become sixteen cases, seven of which the text does not answer.

A decision table is a grid that lists every combination of the conditions a rule depends on and states the outcome for each combination, so that the cases nobody thought about show up as empty cells instead of as arguments during build.

No client and no engagement here: a published returns policy, a few help centre articles from the same retailer, ten public complaint threads I picked myself. Nobody there was asked anything and I hold no internal data, so every number below comes from those sources or from counting cells you can recount.

In short

• A rule that reads cleanly in prose turns into sixteen cases once you lay out its conditions, and seven of them come out empty.
• An empty cell is not a gap in your table, it is a decision nobody has made, so it needs an owner, a due event and a default.
• The 40 EUR threshold everyone quotes changes the outcome in one of the seven distinct rules, and there it only removes an option.
• Sixteen rows collapse back to seven once you mark the irrelevant conditions, and that shorter version is what a developer gets.

What are the conditions, actually?

Decomposing prose means reading it for anything that can take more than one value. Most of the work is here, because prose hides conditions in adjectives.

Reason for return. Damaged or faulty, against changed my mind. The parcel that never arrived is a third case the passage does not cover: a customer with no item has nothing to return. Out of scope here on purpose, with a line saying so.

Inside the 30 day window. The text names a start event, better than most, though the carrier's delivery date and the day the box was opened are not always the same. Note that this is the general return window, and it is not the clock BR-04 runs on in the worked case: damage in transit has to be reported within 14 days of delivery. Two windows in one policy, and the table above only lays out the wider one. Anchoring a duration to a named event is the subject of acceptance criteria that survive a sprint review.

Unused and in original packaging. Two conditions wearing one coat. Used but boxed, and unused but the box went out with the recycling, get the same answer in my table. I collapsed them because splitting doubles the table, and wrote that down so a reviewer can overrule me in one line.

Order value above 40 EUR. Published, repeated in help centre wording as a hard rule, and no public source I found gives the reason for it or names who owns it. The boundary is soft as written: above 40 EUR and 40 EUR or more are different rules, and whether order value includes delivery is not stated.

Four conditions, two values each, sixteen rows. Then the outcomes, where prose was hiding a second decision. The rule reads as though there is one answer per case. There are two: whether the return is accepted, and what amount comes back. They do not always move together, and that is invisible until the columns are separate.

Sixteen rows

Open means the passage above does not answer it.

Rows 3 and 4: the policy attaches the packaging condition to the change of mind sentence only, while a help centre article asks for original packaging on all returns where possible. Two sources, one soft qualifier, nothing decidable from outside.

Rows 5 to 8: the passage says nothing about a fault found after the window closes, and whether rights of some kind outlive a retailer's own 30 days is for someone with standing to answer.

Rows 9 and 10 I did not expect: the return is accepted and no amount is stated, because the refund including delivery is promised for damaged goods only.

Row 11 is the interesting one. Read strictly, the item fails the unused and boxed condition and the return is refused. Read against the partial refund sentence, which names a threshold and never says what triggers one, a used item over 40 EUR is the case that clause would exist for. Both readings fit.

AS-1: unused and in original packaging treated as one condition. Splitting gives thirty two rows and matters in rows 11 and 12. Recorded, not resolved.

How much of this does the policy actually settle?

Sixteen rows and two outcome columns give thirty two cells: sixteen filled from the published text, sixteen open. Read row 11 the other way and the count changes, which is the useful kind of disagreement: it is about the business, not the table.

Now collapse it: where a condition makes no difference, mark it irrelevant and merge. Sixteen rows become seven rules.

1. Damaged, in window, boxed: accept, item plus delivery. Value irrelevant.
2. Damaged, in window, not boxed: open.
3. Damaged, out of window: open. Other conditions irrelevant.
4. Changed mind, in window, boxed: accept, amount open. Value irrelevant.
5. Changed mind, in window, not boxed, over 40 EUR: open.
6. Changed mind, in window, not boxed, 40 EUR or under: refuse.
7. Changed mind, out of window: refuse. Other conditions irrelevant.

Three of the seven have nothing in them and a fourth has an acceptance with no amount. Seven is also the version to hand a developer, because sixteen rows invite somebody to implement four conditions where two would do.

The collapse also shows what the threshold does. Order value survives in one rule out of seven, and only to remove partial refund from the options in rule 6. It is the most quoted number in the policy and decides less than the sentence structure around it. I am not calling it wrong, since it is published policy and I cannot price a split refund from outside. A number can be prominent and nearly inert at once, and the table is what tells the difference.

Three of my ten threads land in rows this table leaves open, on my own reading of threads I picked, which is how I choose the cell to ask about first.

Why is an empty cell worse than a wrong one?

A wrong outcome is visible. Somebody reads rule 6, disagrees, and the argument happens in review where it is cheap.

An empty cell gets filled in anyway, later and by somebody else. A developer meets the case in build and takes the branch that is easiest to write. An agent meets it on a Tuesday, makes a reasonable call, then makes a different reasonable call three weeks later. Nobody logs a decision, because from where each of them sits nothing was decided. The behaviour ends up with no author and no record, and the first time anyone reads it as a rule is when a customer holds two answers side by side.

Who fills them in, and by when?

Sixteen open cells is not sixteen questions. Grouped by the decision behind them, they are four.

The numbering carries on from the register in the worked case, which already holds OQ-01 to OQ-06. Ids are permanent and never reused, so a question raised by a decision table gets the next free number rather than a private sequence that collides with the one a reader already has.

The last three columns matter more than the question. The owner is a role, because I could not name a person from public sources and an invented one is worse than an open row. The due date is an event in the build, so it survives a change of schedule. The default is the column people leave out, and it stops the question becoming a silent decision taken by whoever sits closest to the keyboard.

The sixteen settled cells go the other way: each is now a statement a tester can run without asking me what I meant.

The blank template

Three conditions, eight rows. Add the fourth only when you have proved you need it.

Underneath it, two blocks that do most of the work.

AS-n  [a condition you collapsed, a boundary you read one way, a case you
       put out of scope. One line each, so a reviewer can overrule you]

OQ-n  [the open question, one sentence]
      Cells:   [which rows it covers]
      Owner:   [the role holding the decision right, not a name you guessed]
      Due:     [an event in the build, not a calendar date]
      Default: [what happens if that event arrives with no answer]

Then one line naming the source of every filled cell, so a reader can tell which outcomes came from a published rule and which from you.

When is the table the wrong tool?

Above five or six conditions it stops being readable, so split it by reason for return. Continuous values fit only once you band them, and the arguments then move to the band edges. Sequence it does not model at all: who holds the case while it waits is a question for a process model. And a first pass with no empty cells usually means you picked the conditions to fit the answers you already had.

The full returns case, with the register the criteria sit in and the rule register the thresholds come from, is in the proof pack. The table above is not in it: the pack carries these rules as a register rather than as a grid, so this page is the same logic laid out the other way. The scorecard carries the checks I run before anybody else sees it.

Twenty minutes, today: take a rule from a product you use, find two conditions, write the four rows and see how many you can answer. Two is a normal score. The two you cannot answer are the ones your team will decide by accident.

A context diagram is one box for the thing you are changing, a ring of everything outside it that sends it something or receives something from it, and one labelled line per exchange. No internal steps, no screens, no boxes inside the box. That is the entire notation, which is why it takes five minutes and why it closes this argument.

One limit first. That argument is a composite of ones I have sat in on real projects, not a transcript. The returns case on this site has no meeting room in it: returns and complaints at a mid-size online retailer, built only from the published returns policy, the help centre and ten public complaint threads I picked myself. No engagement, no client, nobody inside the company asked anything. Where I claim a system exists across the boundary, I am inferring it from what those sources make visible, and the row says so.

In short

• The scope argument is rarely about the thing being built. It runs on the part being left out, and on who quietly inherits it.
• Draw one box, name every entity that exchanges something with it, write one line per exchange. Anything you cannot draw a line to is outside, and the reason goes on the page.
• The column that does the work is the last one: what happens when this flow is missing. That is where an exclusion stops being an opinion and becomes a cost with a name against it.
• Both tables are below, filled in and then blank, ready to copy.

Why does the same scope argument restart every week?

Two positions, near enough word for word, because they repeat with the job titles swapped.

If inspection stays outside, we approve refunds from photographs, and the first time somebody photographs an empty box we have paid for nothing.

Inspection is a warehouse process with its own hands, its own building and its own system. Pull it in and we are rewriting the warehouse, and this ships in a year rather than a quarter.

Both are true, which is the problem. Two true sentences can sit opposite each other for as long as the meeting lasts, because the word doing the damage is "returns", and it covers at least six things: the claim, the evidence, the eligibility check, the decision, the money leaving, and the item coming back. Each person holds a different subset and uses the same word for it.

A drawing removes the option. You cannot draw a boundary and keep two versions of it, and once the line is on the page the question changes shape. It stops being "should inspection be in the project" and becomes "if inspection sits outside, what crosses the line, in which direction, and what breaks when that crossing does not happen".

The diagram, written out so you can copy it

In the middle, one box, named as narrowly as the scope line in the document: damaged-delivery refunds for web store orders, from evidence upload to decision.

Around it, the entities, each with its source. [POLICY] is stated in the published returns policy, [HELP] in a help centre article, [THREADS] in the ten threads, and [INFERRED] marks reasoning from what those sources imply rather than state.

• Customer [POLICY] [HELP]
• Support contact route, the way the help centre says a case is raised [HELP]
• Warehouse goods-in inspection [HELP]
• Order and delivery record, the web store itself [POLICY]
• Payment and refund execution [INFERRED], because the policy says refunds return to the original payment method, so something executes them
• Carrier [INFERRED], because a damaged delivery usually has a claim path behind it
• Accounting ledger [INFERRED]
• Marketplace channel [POLICY], on the diagram because it is outside

One row per exchange. The last two columns are worth your afternoon.

Read down the fourth column. Half of those failures are not system failures. They are a person receiving something late, or nothing, and absorbing it. That is the argument the two people were really having, and it took a table to make it sayable.

Which side of the line, and who is left holding the rest?

The second table is the one that goes into the document.

The third column does what the first two cannot. "Out of scope: inspection" states a boundary. "Out of scope: inspection, and the goods-in lead now sees the verdict matter after the money has left" states a decision somebody may want to make differently.

One row type is missing on purpose. Anything genuinely undecided belongs in neither column; it needs its own line with an owner and a date, which is one of the eleven edits that make a BRD worth reading. Parking an open question in the out-of-scope column is the commonest way I see a scope section lie without anybody meaning to.

What does an exclusion cost, and who pays it?

The goods-in lead approves nothing. No public source I could find puts that role in an approval flow, and on an influence grid it sits in the quadrant you are told to monitor with minimal effort. It is on the diagram anyway, because the help centre says returned items are inspected on receipt and the inspection can change the outcome. A line crosses the boundary towards it whether anybody planned it or not.

Keeping inspection outside the box is almost certainly the right call. It is also the exclusion with a cost, and the cost lands on the one role here with no veto to defend itself with. Both are true at once, and the diagram lets you write them in one sentence instead of choosing. Same pattern as the stakeholder map that survives contact with the project: the row that matters in month two is the one that loses something, and no scope bullet surfaces it.

What you do about it is not heroic: name it in the document, log it as an open question with a fallback, and make sure whoever holds that role hears it from you and not from the first dispute.

The blank version

Copy these two. Hints in the brackets.

Five minutes, no software.

1. Write the box. One line, ending at a decision or a state rather than at a department.
2. List everything that touches it, walking the process end to end, exclusions included.
3. One row per exchange, per direction, because the two directions fail differently.
4. Fill the failure column before you argue with anyone. It is the only column that changes minds.
5. Anything with no line to the box is outside. Write the reason and the inheritor beside it, or take it back in.

One fair objection: the table invites you to draw systems you have never seen. Hence the source column, and four entities tagged as inferences.

Where to start

Take a scope section you already have, with an out-of-scope bullet list. For each bullet, write what crosses the boundary in each direction and who is holding that bullet when the project succeeds. Twenty minutes, no diagramming tool, no meeting.

You will usually find one exclusion nobody has told the inheritor about. That conversation is cheaper now than after go live.

The standard I hold my own artifacts to is on this site: the scorecard is twenty-five checks across six artifacts, versioned, free, no email address asked for. Run the diagram and the scope table through it before anyone else sees them.

A context diagram is finished when a stranger can point at any line and say what breaks if it goes quiet.

"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.

A business case is the document that puts a proposed change in front of the person who controls the money, says what it costs, what it is expected to return, and under which conditions the answer should be no. That last part is the one people leave out, which is what makes a case unarguable. A page nobody can push on has not settled the question, it has hidden where the question lives.

I should say what I am not. I have never sat in the finance seat or held a budget of that size. What I do is write the paper finance takes apart, on international projects, and watch which line they go for. It is almost never the total, it is one input three lines above it, and the meeting turns on whether that input has an address.

In short

• The unarguable version is unarguable because no number in it has an owner, a source or a unit, so a reader who disagrees has nowhere to put it.
• Mark every assumption as an assumption, and name the system it would come from in a real project plus the role that would confirm it.
• Print the reversal point, the value at which your recommendation flips, rather than a payback figure that reads like a promise.
• The case below comes only from public sources, so every figure is mine and labelled as mine, which is what honest looks like without access to the books.

What is a business case for, if you already know your answer?

You do know your answer, you would not have written the page otherwise. The case exists so somebody can test it without repeating your work: a reader with a budget is not following your reasoning, they are hunting for the load-bearing number, swapping in their own, and checking whether your recommendation survives.

So the quality question is not whether your numbers are right; written from outside a company, they will not be. It is whether a reader can see which numbers do the work, where they would come from, and how far each has to move before the answer flips.

The case, and what I do not have

The worked example on this site is returns and refunds at a mid-size online retailer, built from a published returns policy, help centre articles, and ten public complaint threads I selected myself. No engagement, no client, no interview, no cost figure or volume report, ever. That is where most people stand writing a first business case: a real process they can watch from outside, no access to the money.

The usual response is to invent a plausible cost per case and hope nobody asks. The better one is to use the number anyway, label it as yours, and name who would replace it. Every figure below is my assumption, not a finding about this retailer, and saying so buys the right to use numbers at all.

The one page

BUSINESS CASE (one page)
Damaged-delivery refunds, web store
Version 1.2. Self-directed case study, built from public sources.
No company data was available to me. Every figure marked (A#) is my
own assumption. Register on page 2.

L1  DECISION REQUESTED
    Approve a named owner and a decision clock for damaged-delivery
    refund cases that stall after first contact.
    Decision owner: [role with authority over the returns process].
    Needed by: [date]. No decision means do nothing.

L2  PROBLEM, COUNTED
    Four of the ten damaged-delivery complaint threads I read end
    with no named person owning the case after first contact.
    Source: ten public threads I selected and read between 12 and
    21 March. A count of the threads I chose, not a rate.

L3  SCALE (A1, A2)
    Assumed 500 cases a month (A1), of which an assumed 20 per cent
    stall with nobody's name on them (A2), so 100 a month. A2 sits
    at half what my ten threads showed, because the threads people
    post are the failures.

L4  COST OF A STALLED CASE (A3)
    Assumed 25 EUR per stalled case (A3), mostly repeat contacts
    and manual chasing. My figure. I have seen no cost data.

L5  EFFECT OF THE CHANGE (A4)
    Assumed the change removes 60 per cent of stalls (A4).
    60 cases x 25 EUR = 1 500 EUR a month, gross.
    A4 is the one number nobody can source before the change ships.

L6  COST OF THE CHANGE (A5, A6, A7)
    Assumed 9 000 EUR one-off build (A5) and 300 EUR a month to run
    (A6). Net 1 200 EUR a month. Over a 24-month horizon (A7, a
    convention I do not own), 28 800 EUR against 9 000 EUR.
    Payback at 7.5 months.

L7  REVERSAL POINT
    The recommendation survives any ONE of A1 to A4 being half of
    what I assumed. It dies when two halve at once: the 24-month
    return then falls below the build cost. Break-even sits at
    45 per cent of assumed volume x stall rate x removal rate
    x unit cost.

L8  WHAT I WOULD MEASURE IN WEEK ONE
    Cases with no assignee after first contact, from the queue.
    One measurement, replacing A1 and A2.

L9  DO NOTHING
    The published policy already sets a deadline for closing a
    refund case, and nothing public says who owns a case that
    misses it. Doing nothing keeps a rule with no keeper.

L10 WHAT THIS PAGE IS NOT
    Not a costed proposal. An argument with its working shown from
    outside the company, every figure meant to be replaced.

The teardown, line by line

Three questions per line, always the same three. Where did this come from, what does the decision do when it is halved, who is entitled to argue with it. L1 takes them quickly: the ask is mine to write, it cannot be halved, and the only person who can argue with it owns the returns process, which is why that slot stays empty rather than holding a title I invented.

L2, the counted problem. Source: ten public threads I picked, on stated dates, with the selection method written next to the number. Halved: two of ten still shows the branch exists, and nothing below rests on it. Who can argue: anyone with twenty minutes and the same kind of public sources, and a reader calling my ten threads unrepresentative is right.

L3, the scale. Source: nowhere, both figures are mine. In a real project A1 is a monthly count by return reason from the order management system, A2 is cases with no assignee after first contact, from the queue. Halved: 750 EUR a month gross, payback at twenty months rather than seven, still positive but no longer obvious. Who can argue: whoever owns that queue, in ten minutes, with a report they already run. This is the pair I most want destroyed, because destroying it is cheap.

L4, the cost of a stalled case. Source: me. In a real project it is a small model: contacts per stalled case from the service desk, times a fully loaded cost per contact from finance. Two owners, one number. Halved: same arithmetic as halving volume, twenty months to payback. Who can argue: a finance business partner, and they will, because a cost per contact from outside their model is the fastest thing here to reject. Hand me theirs and the case gets stronger even if the number worsens.

L5, the effect. Source: judgement, and this is the dangerous one. A4 has no system behind it, because it describes a world that does not exist yet. The only honest sources are a pilot on part of the queue, or a comparable change already made here. Halved: twenty months again, the case still holds. Who can argue: everybody, which is the problem, and only whoever runs that pilot could confirm it. A number nobody can source is one nobody can refute, so it slides through while the room argues about build cost.

L6, the cost of the change. Source: the delivery team, as an estimate with a range. A7, the horizon, is not mine to pick, and choosing it yourself is a quiet way of setting your own exam. Halved: payback under four months, which tells you the build cost is the line everyone attacks and the one with least influence on the answer. Who can argue: engineering on A5 and A6, finance on A7.

L7, the reversal point. Source: arithmetic on the four inputs above, done once and written down. Halved: not applicable, which is why the line exists. Who can argue: anyone who thinks two of my four inputs are optimistic at once, a claim they can make in one sentence.

Notice what the walk exposed. A1 to A4 multiply, which makes them one number wearing four labels, so halving any of them does the same thing to the answer. That never shows up in a table of estimates, only when you write what each line does to the decision.

What happens when every number is half?

Then the case is dead, and the page should say so before the reader gets there.

Halve all four inputs and the monthly return falls to about a tenth of what I claimed, below the assumed running cost, so the change loses money before anybody pays for the build. That is the most useful sentence here: it says how wrong I have to be for the answer to change, and lets a reader judge how likely that is.

A payback figure cannot do this: a single number reads as a promise, and a promise can only be believed or disbelieved. A reversal point reads as a test, and a test can be run by somebody who does not trust you. There is a cost to this, and I would rather name it: a page this full of labels can read as a list of things you failed to find out, which is what L8 answers.

The assumption register you can copy

Page two, and the artifact worth more than the page in front of it. Copy it, keep the columns, fill the last one first.

Three rules for filling it. The last column names something somebody could observe, never "if the assumption is wrong". A row with a blank confirmer gets flagged on the case rather than quietly averaged in. And every row of type "effect of the change" says so, because no system can confirm that number before the change ships, and it is the row that gets waved through.

For the document this page sits inside, there is the BRD piece. The scorecard holds the checks I run against my own work first. The full returns case, register and review notes included, is in the Proof Pack. The business case above is not in it, on purpose: the one-pager in that pack carries no cost figures at all and says so on its face, because the assumptions I am willing to publish inside an article are not the same as the ones I would put in a decision document with nothing to source them from.

What can you do with one hour?

Take a business case you have written, or any recommendation you made in writing, and find the numbers that multiply. Give each an owner, a source it would come from in the real world, and a value. Then halve them one at a time and write one clause about what your recommendation does.

Somewhere in that hour you will hit a number you cannot attribute to anybody. That number is the whole meeting, and until now it was the one line nobody could argue with.

Then an application form asks for a link to your portfolio, and you look at what you actually have. Lecture notes. A completion badge. A folder of slide decks somebody else made.

A business analyst portfolio is a small set of documents, built on a case you are free to publish, that shows how you turned an ambiguous problem into something a team could act on. It is a work sample, not a record of what you were taught.

I run a business analysis training platform in Polish, with paying members, and some version of that message keeps arriving. The wording changes, the shape does not: I know the concepts, I cannot show the work.

I am not a recruiter and I have never run a hiring process, so I am not going to tell you what happens on the other side of the desk. What I do is write these documents on international projects, take other people's apart in review and have mine taken apart in return. So here is the narrower question I can answer. When a document lands on my desk and I have twenty minutes, what makes me believe the person who wrote it knows what they are doing?

In short

• One case taken far enough beats six half-finished ones, and the six artifacts that carry it are a stakeholder map, an as-is and to-be process, a requirements register with acceptance criteria, one business rule with its rationale, a review log and a one-page summary.
• Build the case on sources you are free to publish: a published returns policy, help centre articles, public complaint threads and your own attempt to use the process as a customer.
• Label what you cannot know from outside, because four of ten complaint threads I picked myself is a count with a method attached, while calling it 40% is the fastest way to lose the reader you were trying to impress.
• The review log is the artifact I read first, since a clean final draft is cheap and a document with the objections still visible in it is not.

Why is a BA portfolio harder to build than a designer's?

A designer shows the screen. A developer shows the repository. We write documents about somebody else's business, and most of them are the sort of thing you cannot show.

The last requirements pack I am proud of has a client name in it, transaction volumes, an internal cost figure and three screenshots of a system that is not public. None of that is mine to publish, and removing the names does not fix it. If a reader recognises the process, your best work sample turns into a reason not to hire you. It takes one reader who was on the other side of that project. The document can be good; that is not the problem.

So: you will not build a portfolio out of your paid work, and if you are new to the field you have no paid work anyway.

Build your own case on public sources instead.

Pick a process you can watch from the outside, as a customer, where the failures are visible and the rules are published somewhere. I use returns and refunds at a mid-size online retailer. Appointment booking at a clinic works. So does airline rebooking after a cancelled flight.

Then collect facts instead of inventing them.

Note the right-hand column. It is the more useful half and the half people skip. Write every gap down as an open question with an owner and a date. A case built this way is yours, it is publishable, and you can defend every decision in it.

Six artifacts turn that case into evidence somebody else can judge. Six, from one case, taken far enough that the seams show.

1. The stakeholder map

What it is. One page naming everyone who can approve, block or quietly sabotage the change, and what each of them stands to gain or lose.

What it tells me. Whether you have been in a room or only read about rooms. Anyone can list roles. Very few people write down who holds the decision right.

Bad version. The org chart with twelve boxes and job titles, or an influence grid with names in quadrants and no explanation of how they got there.

Good version. Every row carries a decision right and a piece of evidence. Not "Finance, interested", but "Whoever signs off refund policy in Finance: holds the decision right over the partial refund threshold. Evidence: the 40 EUR threshold appears in the published policy and in two help centre articles, always worded as a hard rule. No public source names the person, so the row stays open rather than being filled in with a plausible title."

In my returns case the row worth arguing about is the warehouse, not customer care. Somebody there has to physically receive the item that comes back, and nothing in the published policy suggests that person gets a say when the refund window is shortened. The row is an inference from how the process has to work, and the map says so on its face.

Time. Sixty to ninety minutes, once I have done the reading.

The one mistake. Listing who gains and leaving out who pays. The rows that matter are the ones where somebody stands to lose something when this succeeds.

2. The as-is and to-be process

What it is. Two models of the same process. How it runs today, and how you propose it should run.

What it tells me. Whether you can hold a system in your head and change one part of it on purpose.

Bad version. An as-is with no failure anywhere in it, followed by a to-be that changes everything and fixes everything. A model of the current state where nothing ever goes wrong is the first thing a reviewer goes after, and mine did.

Good version. The as-is shows where work stops. In my case there is a branch where nobody owns the outcome: the evidence is incomplete, the case is parked, and from there the customer has to chase it.

I wanted a number for how often that happens. Public sources will not give me one. Four of the first ten complaint threads I read ended there, which is a count of ten threads I picked myself and not a rate, so the model says exactly that on its face: parked branch, frequency unknown, flagged for measurement. Turning that into "40% of cases" would have been the easiest thing in the document for a reviewer to catch.

The to-be then changes as little as possible. Evidence is collected before a human sees the case, and the parked branch gets a named owner and a clock. The branch still exists in the to-be. Pretending it will not is how you lose the first review.

Use BPMN if you know it, plain boxes if you do not. Consistency beats notation purity, and a reviewer who cares more about your gateway symbols than your exception path is telling you something about the team.

Time. Three to four hours for a process this size, including one full redraw. There is always one full redraw.

The one mistake. Modelling what should happen instead of what does.

3. The requirements register with acceptance criteria

What it is. The numbered list of what the solution must do, each item written so it can be tested and traced back to a rule or a stakeholder need.

What it tells me. Most of what the job actually is.

Here is a row from the returns case, as it sits in the register after review.

REQ-014 - Refund on damaged delivery

Acceptance criteria:

1. Photo upload accepts up to 3 files, 10 MB each. A fourth file is rejected with a message that names the limit.
2. A refund decision is recorded within 48 hours of form submission. If it is not, the case escalates automatically to a named owner.
3. Partial refunds are permitted only when order value is above 40 EUR. At or below 40 EUR the refund is full or refused, never partial.

Open questions on this row: OQ-04, whether the duty rota covers weekends given a 48 clock hour window, and OQ-05, whether partial refunds ship in release 1. Both sit with the Head of Customer Care, each with a date and a fallback. The retention question lives one requirement further on, as OQ-01 against REQ-016: 90 days proposed, to be checked against the statutory limits, owner legal, due before build starts, and if it is not confirmed by then, photos default to the shortest defensible period and the decision goes up.

Bad version. "The system should handle refunds correctly and in a user friendly way." Three criteria that restate the requirement in different words. Anything containing "as appropriate", "if needed" or "etc".

Good version. Criteria a tester can run without asking what you meant, and every number traceable to somewhere you can name.

Time. Three to four hours for five requirements written this way. Most of that is not writing. Five, not fifteen: the case this row comes from carries five, and the register says on its own face that five must-haves in one release is a smell.

The one mistake. If someone has to phone you to know whether the criterion passed, it is a note, not a criterion.

4. The business rule with its rationale

What it is. A single rule, stated precisely, with the reason behind it and the person who owns it.

What it tells me. Whether you chase the why or settle for the what. Rules outlive the people who set them. I have sat in a workshop where a threshold nobody could explain survived the redesign, because changing it felt riskier than keeping it.

Bad version. "BR-11: partial refunds above 40 EUR only." Rule, no reason, no owner. It reads like a law of physics.

Good version.

BR-11 - Partial refund threshold. Partial refunds are permitted only above 40 EUR order value.

Established. The 40 EUR figure and its wording as a hard rule, from the published policy and two help centre articles.

Inferred, not confirmed. The rationale. Below 40 EUR, the handling cost of a split refund plausibly exceeds the amount recovered. I have no cost data. Flagged for the rule owner to confirm or kill.

Owner. Whoever signs off refund policy in finance. I could not name a person from public sources, so the row is open rather than blank.

Review trigger. A change in the payment provider's per-transaction fee.

Marking your own inference as an inference is not weakness. It is the difference between an analyst and someone who fills the gaps with confident guesses.

Time. Twenty to thirty minutes per rule, most of it spent chasing the why.

The one mistake. Accepting "that is our policy" as a rationale and writing it down as though it were one.

5. The review log

What it is. A short record of what a reviewer objected to, what you changed, and what you deliberately did not change.

What it tells me. More than the finished document does. Polished final drafts are cheap. A document with visible scars from a real argument is not, and it is the artifact I read first.

Bad version. No log, only the clean final draft. Or a log that records the objection and stops, so I cannot tell whether you agreed, disagreed or panicked.

Good version. Three to six entries, each one line of objection and two lines of consequence. At least one where you held your ground and said why.

Time. Thirty minutes after the review. The review itself costs you one favour from someone competent.

The one mistake. Publishing only the version that makes you look good. Hiding the objections hides the only proof that you can take feedback without collapsing.

6. The one-page summary for a decision maker

What it is. One page, written last, read first, addressed to the person who has to say yes or no.

What it tells me. Whether you can compress. I read plenty of forty-page documents and very few good one-page ones, and the one-pager is the harder of the two.

Bad version. "This document describes the current returns process and proposes improvements." That sentence asks for nothing and tells nobody anything.

Good version. The decision requested, in the first line. Two or three options, each with cost, risk and effect. A recommendation with your name against it. What happens if we do nothing. Decision owner and decision date.

For the returns case the first line reads: "Decision requested. Approve automatic escalation of undecided refund cases after 48 hours, with a named owner per case, and a self-service form that collects photographic evidence before a person sees the case. Cost: one process change and a queue configuration. Effect: cases that currently stall get an owner and a deadline. How many stall cannot be answered from outside the company, and it is the first thing I would measure."

Time. Forty-five to sixty minutes, plus two rewrites, because the first draft is always half a page too long and one degree too polite.

The one mistake. If your page has no decision, no owner and no date, it is a covering note.

What did the reviewers actually object to?

I gave the case to two people and asked for the objections rather than the compliment. A developer on the delivery side, who reads process models before registers and has spent years being handed requirements that come apart in build. A business analyst who reviews requirements documents for a living. Two sessions, five objections. Four changed the case. One I accepted only in part, and the disagreement is written down instead of quietly dropped. Neither of them works at the retailer, and nobody there was asked about anything, at any point.

"Your as-is is the happy path, so your to-be looks better than it is." The first version of the as-is ran call, evidence, decision, refund, and stopped. It took about forty seconds to spot. If the as-is only shows the path where things go well, every benefit claimed for the to-be is unearned. The parked branch went into the model with no owner, no clock and its frequency marked unknown, and two further pieces fell out of it that had not existed before: an escalation requirement and the rule behind it.

"Under 48 hours from what moment?" The first draft said "within 48 hours" and never named the start event. Two readings both fit the sentence: one counts from the moment the customer presses submit, the other from the moment an agent opens the case. Between those two readings sits most of a working day. The clock is now anchored to the timestamp on the submitted form, in the criterion rather than in a note underneath it. Anchoring it immediately exposed a second decision the vague version had been hiding, clock hours against working hours, which is now an open question with an owner.

"Four in ten is a count, not a rate." An early draft said four in ten damaged-delivery cases end without an owner. I had ten complaint threads I selected myself, four of which ended that way, and I had turned that into a statement about all cases, two pages after my own source table said complaint threads are not a representative sample. Accepted on labelling: every use of the figure now names the denominator, the selection method and the date. Held on the number, and this is the one I did not fully accept. The stronger version of the objection was to cut the figure and say only that the branch exists. A labelled count with a stated method can be rechecked in twenty minutes; a shrug tells the reader less. The disagreement stands in the log, which is where a future reader should find it.

"A customer whose parcel never arrived has nothing to photograph." The to-be routes everything through a form built around photographic evidence. Somebody whose parcel was stolen or lost has no photograph, and on the phone they at least got a person who could improvise. The change quietly made one group worse off, and it was the group least able to argue about it. Non-delivery and lost parcels are now out of scope, with a reason and an owner. Deliberately not as a fourth acceptance criterion: an exception you exclude on purpose is a scope decision and belongs where a reviewer will find it.

"Why 40 EUR? Who set that?" The threshold was published but nothing public said who set it or why. Chasing the reason produced a rule with a page of its own: the figure and its wording as established, the rationale written down and labelled as my inference because I have no cost data, the owner slot left open rather than filled in with a plausible title, and a review trigger naming the input most likely to move it. The number itself did not change. It is published policy and I cannot improve on it from outside the company. What I could fix was the silence around it.

Not one of the five is about writing style. All five are about whether somebody can act on the document without me in the room. That is the standard.

How do you lay out a portfolio so it survives a skim?

Nobody reads a portfolio the way you wrote it. Assume a skim until something makes the reader stop.

One URL, not a zip file. A single page with the six artifacts on it, or one PDF. I close anything that needs downloading, unpacking or a login, and I doubt I am unusual.

Say what this is in the first two lines. "A self-directed case study on returns handling at a mid-size online retailer, built from public sources. Not client work." That sentence protects you and buys you trust at the same time.

Order for the reader, not for the process. One-page summary first, review log second, then the register, the models, the stakeholder map, the rules. Judgement at the top, diligence underneath, all of it still there for anyone who wants it.

Two sentences of context above each artifact. What the problem was, and one thing you would do differently now. That second sentence is worth more than the artifact under it.

Cut anything you cannot defend for five minutes. Every extra document is another surface for a question you cannot answer.

The blank templates for all six artifacts, plus the worked returns case in full, are on the downloads page. The scorecard is there too: twenty-five checks across the six artifacts, so you can be unkind to your own work before anybody else gets the chance.

What can you build this weekend?

Not all six. One.

Saturday morning, take something that went wrong for you as a customer in the last month. A return that took three weeks. A booking that made you phone somebody.

Write one requirement from it, in the format above, with three acceptance criteria and the business rule it traces to. Give yourself ninety minutes and stop when the time is up.

Then send it to one person who will tell you it is wrong, and write down what they said.

It is not a portfolio yet. It is the first thing you have made that somebody could read and form an opinion about, which is more than the certificate can do.

Your certificate says you learned. This is how you prove you can.

An as-is model is a picture of a process as it actually runs, including the paths where it stalls, loops back or quietly hands the work to the customer, drawn before anybody proposes changing it. That last clause is the entire discipline.

A straight-line as-is has one consequence that survives every review. If nothing in the current state ever fails, then every benefit claimed for the future state is being measured against a process that already worked, and no reader can tell whether you improved anything or added a form.

The worked example below is returns and refunds at a mid-size online retailer. It is built only from sources I am free to publish: the retailer's published returns policy, its help centre articles, and ten public complaint threads I selected myself. There was no engagement and no client. Nobody at the company was asked about anything, at any point. No interviews, no workshops, no exports, no internal data. Where a branch comes from my reading of how the process has to work rather than from a source, the model says so on the branch.

In short

• An as-is with no failure branch in it makes the to-be look like an improvement to a process that was already fine.
• Draw the branch where the case stops before you draw anything you intend to change; here it is the point where evidence is incomplete, the case is parked, and nobody's name is on it.
• Four of the ten complaint threads I read ended in that branch, which is a count of threads I chose myself rather than a rate across cases, so the model carries the frequency as unknown and flagged for measurement.
• The artifact worth publishing is the table of differences between the two models, and its third column says what each change breaks.

Why bother with the as-is if you are going to change it anyway?

Because the to-be is an argument, and the as-is is the evidence it rests on. Remove the failure branches and the argument has nothing under it.

There is a second reason, more useful in a room. People who will not read a requirements register will look at seven boxes and tell you the third one is wrong, which is exactly what you wanted. A to-be never gets that reaction, because nobody has lived in it yet.

I do not have that room here. This case has no stakeholders to correct me, and everything below is limited by that. The compensation is labelling, not confidence.

The as-is, step by step

Damaged delivery, web store order. The customer has the parcel and the item is broken.

1. The customer notices the damage and goes looking for the route. The published policy treats change-of-mind returns and damaged deliveries as separate cases with separate rules, and the help centre has articles for both. Where the case can leave the process: the process has two doors and the customer picks one before knowing which one they need.
2. First contact. Phone or a contact form, depending on which help centre article the customer landed on.
3. Evidence is requested. Photographs of the item and the packaging, plus the order reference.
4. The customer supplies the evidence, or supplies part of it. Where the case can leave the process: this is the branch that matters. Evidence arrives incomplete, the case is parked pending more information, and from that point the only person who moves it forward is the customer. Four of my ten threads end here, with the customer chasing and no named person answering. That is a count of ten threads I selected, not a rate, and no public source will give me the real frequency.
5. An agent assesses the case. Some decisions cannot be made without the returned item being received and confirmed. Where the case can leave the process: that wait is my inference from how the process has to work, not something any source states, and the model says so on the branch. Nothing public tells me whether the wait has an owner or a limit.
6. A decision is recorded. The published policy is explicit that a case should not stay open beyond a stated number of working days.
7. The item is collected or returned, and the refund is posted.

Steps 4 and 5 are the shape of the problem: a process with a clear start, a clear end, and two places in the middle where work stops without anybody being accountable for restarting it. Neither appears in a straight-line model, and both are where the customer experience actually happens.

The to-be, step by step

1. One entry point that asks what happened before it asks what the customer wants. Damage and change of mind are separated by the answer, not by which article the customer found.
2. The form states what evidence is required and refuses an incomplete submission while the customer is still there and can fix it.
3. A case reaches an agent complete, or it does not reach an agent at all.
4. The agent assesses it. Same authority, same rules, same published windows.
5. The parked branch still exists. A case that cannot be completed goes to a named person with a deadline attached, rather than to a queue. The escalation window itself belongs in the requirements register, not in this model.
6. The dependency on the warehouse confirmation is drawn explicitly, with a state the case sits in and a person it belongs to while it waits.
7. Decision, collection and refund posting are unchanged.

This draft to-be changes five things and leaves the rest alone. That ratio is deliberate. Redraw every box and the first competent reader will ask which of the twelve changes produced the benefit you claimed, and you will not be able to answer. The version I actually recommend in the published case is narrower still, two changes out of these five: evidence collected before a human sees the case, and a named owner with a clock on the parked branch. The other three are drawn here and parked there, because a proposal you can only defend as a set is a proposal nobody can approve in parts.

The table of differences

This is the artifact. Two models are input; the table is what somebody can actually review.

The third column separates this from a list of improvements. Anyone can name what changed. Naming the cost, and naming who pays it, is the part a reviewer cannot fake having thought about. It also protects you: a change with its cost written beside it is a proposal, and a change with only a benefit beside it is a pitch, and readers who take requirements documents apart for a living tell the two apart inside a page.

Row two is the one I got wrong first. My initial to-be moved the evidence check to the front and recorded the benefit, which is real. What it did not record is that the failure had not disappeared, it had relocated to a place where no queue metric can see it.

The blank version

Copy this into your own case. The bracketed prompts are what each cell has to answer.

| What changed | What I deliberately left alone | What this change breaks |
|---|---|---|
| [the change, in one clause, naming the step] | [the neighbouring thing you did not touch, and why] | [who is worse off, which metric goes quiet, what new work appears, what perverse incentive it creates] |
| [change 2] | [kept 2] | [cost 2] |
| [change 3] | [kept 3] | [cost 3] |
| [change 4] | [kept 4] | [cost 4] |

Unknowns carried forward:
  [branch] - frequency unknown, measurable at [where], owner [name or open]

An empty third column means either the change is trivial or you have not finished thinking about it. It is almost always the second, and the missing entry is usually a person whose work increases so that somebody else's decreases.

How do you model a process you can only see from outside?

By putting the source on the branch instead of in a footnote. Every path in the as-is above carries one of three labels, visible in the model rather than in an appendix nobody opens.

Observed. A source states it or a thread demonstrates it. The parked branch is here.

Inferred. The process cannot work without it, but nothing public says so. The wait on the returned item is here, and calling it observed would be the cheapest way to lose a reviewer.

Unknown. Frequency, volume, cost. Almost every number about this process falls here, and writing unknown on a branch beats writing a plausible figure, because unknown converts into a measurement task with an owner.

A number appears in the model only if I can name where it came from. Four of ten threads keeps its denominator and its selection method every time it is written, and never becomes a percentage, because the moment it does it is describing cases I have never seen.

Notation matters less than any of this. BPMN if you know it, labelled boxes if you do not. What a reader checks is whether your gateways have both outputs drawn, and whether the unpleasant one leads anywhere other than off the edge of the page.

Where to start

Take a process you went through as a customer in the last month and draw only the branch where it stopped. One branch, with the point where you had to chase somebody marked on it, and a note saying what you know and what you are guessing.

Then write the three-column row for the one change you would make. If the third column stays empty for more than a few minutes, the change is not ready.

The full returns case, with both models and the review notes left in, is in the Proof Pack. The scorecard has the process checks in it, so you can go after your own model before anybody else does. How these two models sit alongside the other four documents is in the six artifacts piece.

A to-be is easy to make look good. It is only worth reading next to an as-is honest enough to make it look necessary.