Requirements Gathering That Doesn't Morph Mid-Build

It's two days before launch. The dashboard is built, tested, and queued for the Monday demo. Then the email lands: "Hey, can you just add one more thing? We also need it sliced by region. And maybe by tenure. Oh, and the CFO mentioned wanting a YoY view." You stare at the screen. You wrote a requirements doc. You ran a kickoff. You sent meeting notes. None of it stops the ask, because none of it is the artifact that prevents the morph.

On paper, this is the BA's fault. You missed requirements. You didn't ask the right questions. You should have known the CFO would care about YoY. Engineering rebuilds the same chart for the third time in two weeks. Stakeholders quietly downgrade you from "trusted partner" to "ticket processor." You start padding every estimate by 40% just to absorb the inevitable churn.

The fix isn't more documentation. It's different documentation, written in the first 90 minutes, signed before a single ticket is cut. One page in, one page out, dated, named, and emailed to a person who has the authority to say yes. Everything else is theater.

This is the playbook I run on every internal request now: dashboard, analytics, internal tool, ad-hoc analysis. It takes 90 minutes to do correctly. It saves 2 to 3 weeks of rebuild per project. The math is not subtle.

The Intake Form: One Page, Five Boxes

The intake form is one page. Not five. Not eight. One. If it spills onto a second page, you are letting the requester hide vague thinking inside a wall of text. Five boxes. If any of the five is blank, the project does not start. That is not a guideline. That is the rule.

Box 1: The Problem. What is broken right now? Not "we need a dashboard." That is a solution. The problem is "the head of CS spends 4 hours every Monday building a churn report from three CSVs and the numbers disagree with Salesforce." If the requester answers "we need a dashboard" again, ask: what would the dashboard let you stop doing? Push until the verb is removed, not added.

Box 2: The Decision the Output Will Inform. Every dashboard, every report, every analysis exists to inform a decision. Write down the decision. "Whether to expand the SDR team to 12 or 8 reps next quarter." "Whether to sunset the legacy plan." "Whether to pull marketing budget from paid social into events." If the requester cannot name a single specific decision, the request is decoration, not decision support. Box 2 is the cleanest scope-creep killer in the form.

Box 3: The Success Metric. How will we know this worked, six weeks from now? Not "people use it." Not "it's helpful." A measurable outcome: "Monday CS report time drops from 4 hours to under 30 minutes." "Sunset decision is made by end of Q2 with documented rationale." "Marketing budget reallocation memo references this analysis." Box 3 is what you check in the post-delivery validation. If it's vague here, it's unmeasurable later, and the project quietly enters the "did it even matter?" graveyard.

Box 4: In-Scope. Specific, bulleted, finite. "Churn rate by month, by plan tier, by signup cohort. Filtered to last 12 months. Refreshes daily." Five to eight bullets max. If you have 14 bullets, you are not scoping a dashboard, you are scoping a platform.

Box 5: Anti-Scope. This is the box everyone forgets. List, explicitly, what you are not building. "Not breaking out by region. Not by sales rep. Not historical beyond 12 months. Not real-time. Not exportable to Excel." Anti-scope is the one box that pays for itself ten times over. When the requester comes back at week three asking for the regional breakout, you point to Box 5. They named it. They signed it. The conversation is short, factual, and unemotional.

If any of these five boxes is blank or hand-waved, refuse the project. Politely. "I can't start until I have a specific answer for Box 2. What decision will this inform? Can we book 30 minutes to figure that out?" Refusing is not rude. Starting on a vague request and then "missing" requirements two weeks later is rude.

The "What Would You Do With the Answer" Question

This is the single most useful question in BA work, and almost no one asks it.

The setup: the requester wants a dashboard showing customer health scores. You ask, calmly, "If the score for Customer X is 72, what would you do? What if it's 45? What if it's 88?" Three things happen.

If they can answer cleanly ("Above 80, no action. 60-80, the CSM books a check-in. Below 60, it goes to the retention queue"), you have a real requirement. The numbers map to actions. The dashboard is decision support.

If they hesitate, then say "well, we'd look at the trend" or "it depends" or "we'd discuss it in the weekly meeting," you have a decoration requirement. They want the number to exist, not because it changes behavior, but because it feels responsible to track. Decoration requirements are 60-70% of internal requests, in my experience. Build them and they sit unused for six months.

If they bristle and say "we'll know it when we see it," you have a vibes requirement. Worse than decoration, because the requester believes their vibes are a spec. Vibes requirements morph daily because they were never a spec to begin with.

The script for asking the question without sounding combative matters. Don't say "is this even useful?" Say: "I want to make sure I build the right thing. Walk me through what you'd do on a Monday morning if you opened this and the number was [X]. Then walk me through the same thing if it was [Y]." You are framing it as your problem ("I want to build the right thing"), not as cross-examination. The requester usually answers honestly because they don't realize they are revealing whether the requirement is real or decorative.

If the answer is decoration or vibes, you have three options. Option one: walk away politely, citing capacity. Option two: build a smaller, cheaper version (a SQL query they can run, not a full dashboard) and revisit in a month. Option three: have a frank conversation about whether the deeper question is "we don't know how to manage this thing yet," which is a discovery problem, not a dashboard problem, and probably needs an analyst hour, not an engineering sprint.

Prototype-First When Possible

Before any SQL is written. Before any ticket is cut. Sketch the dashboard.

Figma works. Google Sheets works better, honestly, because it lets you fake the data and the requester can squint at it the way they would squint at the real thing. PowerPoint with rectangles works in a pinch. The point is not the tool. The point is putting a picture of the answer in front of the requester before you commit any engineering hours.

A 30-minute mock kills roughly 80% of the rework that would otherwise happen during build. That number is not exact. It's what I have seen across maybe 60 internal projects in the last few years. Sometimes it's 95%. Sometimes it's 60%. It is never under 50%.

What happens in the prototype review is the requester finally sees concretely what they asked for and realizes one of three things. (a) "Oh, I actually need the rows ordered the other way." (b) "I thought I wanted a bar chart but a line chart with a 4-week rolling average is what I'm actually after." (c) "This doesn't answer my question. I need to see the breakdown by [thing not in the original ask]." All three of those discoveries are free in a Google Sheet mock. They are expensive in a built dashboard.

Prototype-first does not apply to everything. Backend changes, integration work, data pipeline cleanup, schema migrations: there is no useful 30-minute mock for "we need to merge two customer tables." When prototype-first does not apply, the substitute is a written example output: "Here is the row of data you'll get back from this integration. Here are the four fields. Here is what each field means in plain English." Written examples are the prototype equivalent for backend work. Same purpose: surface misunderstanding cheaply.

Requirements Signoff: Written, Dated, Named

This is the single most important paragraph in this entire playbook.

The signoff is the artifact. Not the doc. Not the meeting. Not the Slack thread. The email with the one-page summary attached, sent to the requester and their manager, asking for a written reply that says "approved." That email, with the date stamp and the reply, is the only thing standing between you and the morphing scope.

The mechanics: write a one-page summary of the five boxes. Send it via email (not Slack, not Teams, not a comment in Jira) to the requester and their direct manager. The email body says: "Per our intake conversation on [date], here is the summary of what we're building, the decision it informs, the success metric, what's in scope, and what's explicitly out of scope. Please reply 'approved' to proceed. Engineering work begins on receipt of approval."

Two reasons for the manager CC. First, the manager is usually the one with budget authority and is the one who will be asked "where did the engineering hours go?" if scope morphs. They need to see the original ask. Second, the manager is also the one most likely to add scope mid-build ("hey, while you're at it..."), and having them on the original signoff email gives you the artifact to push back with.

Verbal yes is not yes. Slack thumbs-up is not yes. "Sounds good" in a meeting is not yes. Reply-with-approved in email, dated, with both requester and manager on the thread. That is yes. I have lost arguments about scope creep when I had a verbal yes and zero email trail. I have not lost a single one when I had the email.

The dated paper trail is the BA's only defense when scope morphs. That sentence is not dramatic. It is the entire reason this step exists. Without it, every disputed scope change is a memory contest, and the BA always loses memory contests against requesters who have higher org rank.

Scope-Creep Handling: Three Yeses, Seven Nos

Mid-build, the requester wants to add something. This will happen. It is not a sign of failure. It is the steady state of internal work.

There are three legitimate reasons to expand scope mid-build, and seven illegitimate ones.

Three legitimate reasons (you say yes, with a new timeline):

Regulatory change. A new compliance requirement landed that affects the output. The dashboard must show the new field or it cannot ship. Yes, and here is the new date.
Blocking bug or data issue. During build, you discover the underlying data is wrong, missing, or contradictory in a way that makes the original spec impossible. Yes, and we need to pause to fix the data; new date is X.
Dependency surprise. An upstream system you didn't know about (or that just changed) means the original integration approach is dead. Yes, and we need to redesign that piece; new date is X.

Seven illegitimate reasons (you say "yes, and here is the new timeline," but the timeline is the negotiation):

"While you're at it." Stakeholder thought of a new thing.
"[Senior person] saw the prototype and wants…" The prototype review surfaced a new ask.
"Marketing also wants…" A new requester is being smuggled into the original project.
"It would be helpful to also see…" Decoration creep.
"We changed our mind on the metric." Box 3 is being rewritten mid-flight.
"Can you make it dynamic?" Hardcoded → parameterized is a rebuild, not a tweak.
"Just one small thing." This phrase is almost always a tell. Small to ask, large to build.

Notice that for both legitimate and illegitimate, the answer is "yes, and." Never "no." The word no makes you a bureaucrat. The phrase "yes, and here is the new timeline" makes you a partner who happens to be honest about cost.

The change-control form below is what makes "yes, and" enforceable. Without it, "yes, and" turns into "yes," because nothing is documented and the new date silently slips back to the old date in the requester's head.

Change-Control Template

Five fields. Email. Dated. Signed.

SUBJECT: Change request — [project name] — [date]

Original signoff date: [date]
Project: [name]

1. WHAT CHANGED (one sentence): _________________________________

2. WHY (one sentence — link to the legitimate reason or, if not, name the trade-off):
   _________________________________

3. IMPACT ON TIMELINE (new ship date in YYYY-MM-DD):
   Old date: _______
   New date: _______

4. IMPACT ON OTHER REQUESTERS (which other projects slip, by how long):
   _________________________________

5. REQUESTER SIGNOFF ON NEW DATE: Reply "approved" to confirm the new date.

That's it. Five fields. Send it within an hour of the scope-change ask. The requester replies "approved" or they don't. If they don't, the original scope and original date hold.

Never verbal. Never undated. Never "we'll just absorb it." Absorbing scope without writing it down is how BAs end up burned out, blamed, and unable to point at any single moment when the project went off the rails.

Post-Delivery Validation: The Two-Week Check-In

Two weeks after delivery, you book 30 minutes with the requester. One question: did the success metric in Box 3 actually move?

If yes, write it down. Two sentences in your portfolio doc, your performance review packet, your end-of-year self-evaluation. "Built churn dashboard for CS team. Monday report time dropped from 4 hours to 22 minutes within three weeks of launch (target: under 30 minutes). Decision: head of CS used the dashboard to justify a +2 CSM hire in Q3 planning." That is the kind of artifact that gets BAs promoted. Vague "delivered dashboard" bullets get BAs renewed, not promoted.

If no (and this is the part most BAs get wrong), that is not a failure to bury. That is a discovery finding. Write it up: "Built dashboard. Two weeks in, the head of CS has opened it 3 times. Monday report time has not changed. Hypothesis: the underlying decision (which CSMs to assign which accounts) is being made on relationship, not data, and the dashboard does not address the real bottleneck."

That writeup is gold. It is the input to the next intake. It is the reason your next request from the same team will be sharper, because you have data on what didn't work last time. Buried failures are wasted. Surfaced failures compound into expertise.

The two-week check-in also closes the loop on the requester. They feel followed-up-on. They are more likely to bring you the next real problem instead of the next vague ask, because they have learned that you actually care about the outcome, not just the deliverable.

The Workflow in 90 Minutes

Start to finish, the front-loaded work is ninety minutes.

30 minutes: intake call. Walk through the five boxes. Ask the "what would you do with the answer" question. Note the decision and the success metric.
30 minutes: prototype the answer (Sheets, Figma, or written example output). Send to requester. Ask "is this what you'd do something with on a Monday?"
30 minutes: write the one-page signoff email. CC the manager. Ask for "reply with approved." Wait for the reply.

Total: 90 minutes. After that, engineering work begins. During build, any scope ask gets the five-field change-control form within an hour. Two weeks after delivery, you run the validation check.

Ninety minutes of front-loaded discipline replaces two to three weeks of rebuild churn per project. It also replaces the slow erosion of trust that happens when stakeholders feel like every project ships late and slightly off. Both costs are invisible until you stop paying them. Once you stop, you don't go back.

The doc isn't the artifact. The meeting isn't the artifact. The Slack thread definitely isn't the artifact. The dated, named, signed-off email is the artifact. Build the rest of the practice around getting that one email, every time, before any code is written.

Business Analyst Guide