A stakeholder changes their requirements every time you meet them. How do you handle that?

Churn is a symptom, and the causes need different treatment

The instinct is to reach for process — a baseline, a change form, a signature. That sometimes works and often makes things worse, because you can freeze a requirement that was wrong and spend the rest of the project defending it. Before you install control, work out which of about five things you are looking at, because the remedy differs in each case.

The commonest cause is not indecision at all. Most people cannot evaluate a requirement stated abstractly, but they can react instantly to something concrete. So the stakeholder who approved "the user can filter the list" and then objects to everything you build has not changed their mind; they have thought about it for the first time, prompted by seeing it. That is discovery, it is the process working, and the right response is to provoke it earlier and more cheaply rather than to suppress it.

The second cause is that nothing was recorded, so each meeting re-asks a question that was already settled. What looks like a reversal is often a stakeholder answering afresh a question they do not remember answering. The third is that you are eliciting from a proxy — a manager speaking on behalf of a team, or a project coordinator relaying a director — and each new position is what the off-stage decider said this week. The fourth is that the business itself has genuinely changed: a regulator moved, a competitor launched, the sponsor was replaced. The fifth, rarest, is a person who avoids commitment because being pinned down feels like exposure.

Make the discovery happen at the front, cheaply

If the cause is discovery, your job is to burn through the changes before anything expensive is built. Stop asking what they want and start putting something in front of them to reject. A wireframe drawn on paper in the meeting, a screenshot annotated with the eight fields you think belong on the form, a spreadsheet showing what the report would contain for last month's real data — each of these gets you a specific correction where an open question gets you a vague agreement.

The strongest version of this is working the stakeholder's own past cases. Take four real records from last quarter, walk the proposed rule over each one, and show them the outcome. A rule that survives contact with four awkward historical cases rarely changes afterwards, because the exceptions that would have caused the change have already been surfaced. This is also the technique that catches the "except when" clauses nobody volunteers.

Write it down in a form that closes the question

Every session ends with a short written replay, sent inside a day, in the stakeholder's own vocabulary rather than in delivery jargon. Not minutes — decisions. One line per settled point, with who settled it and when. A decision register is not bureaucracy; it is what turns "I never said that" into a shared reference and, more usefully, turns a change into an obvious change that everybody can see is one.

Ref	Decision	Owner	Date	Supersedes or amends
D-014	Claims over 5,000 need a second approver. The limit is per claim, not per month.	R. Iyer, Finance Ops	12 Mar	—
D-021	Second approver may be any manager at grade 6 or above, not only the claimant's own line manager.	R. Iyer, Finance Ops	26 Mar	Amends D-014

That last column is the part that does work, and the distinction inside it is not pedantry. D-021 amends D-014: the 5,000 threshold survives untouched and only the question of who may approve has moved. Record it as a supersession and you have retired a threshold that nothing else in the register restates, which is exactly how a rule disappears from a build with a complete audit trail behind it. Reserve "supersedes" for a decision that replaces its predecessor in full, and write "amends" with the clause it touches when part of the earlier answer still stands. Either way the column makes revision visible without making it shameful, so nobody has to pretend the earlier answer never existed, and anyone reading the register in June can see which version the build reflects.

Price the change instead of resisting it

Once a change is visible, attach a cost to it in the currency the stakeholder cares about. "That is a change" invites an argument about semantics. "We can do that; it replaces the supplier-statement screen in this sprint, so that moves to the following one — shall I make that swap?" invites a decision. Most churn stops when it stops being free, and the ones that survive the price were worth having.

Keep count as well. If eleven rules changed in a fortnight, that number belongs in front of the sponsor, not in your head, and it belongs there before the delivery date slips rather than after. Presented as data with a projected impact on the date, it reads as analysis; presented after the fact as an explanation, it reads as an excuse.

When it is a proxy, no technique will save you

The failure worth naming is spending six weeks perfecting your elicitation craft on somebody who is not entitled to decide. If the same rule reverses twice and both reversals arrive after a meeting you were not in, you do not have an indecisive stakeholder — you have the wrong stakeholder, and every workshop you run with them is rework in advance. Say so plainly, and ask for the decider in the room for one hour rather than asking their proxy for more of their time.

Requirements that move because somebody is learning are progress; requirements that move because nobody wrote the last answer down are waste. Diagnose which you have before you install a process to stop it.