The Same Requirement Keeps Coming Back in a Different Shape

You closed this requirement weeks ago. Everyone agreed. It was signed off. And now it is back.

Not labelled as a repeat. It arrives as a fresh ticket someone raised this morning, or a “quick clarification” in a stand-up, or a change request with a business case attached. Each version looks new enough to accept and just familiar enough to nag. Somewhere in your head a voice says: haven’t we done this already?

You have. The project just never actually finished it.

The need underneath the requirement was never resolved, so it keeps finding new ways back into the work. It never comes back wearing the same clothes. That is exactly why it keeps getting back in.

Project clinic summary

Symptom:
A requirement you thought was closed keeps returning in a new shape (a fresh ticket, a clarification, a change request, a reworded story) and is rarely recognised as the same need.

Likely causes:
The requirement was resolved on wording or sign-off rather than on the underlying need, the decision behind it was never captured, no testable rule closed it, and it has no single traceable home to match new requests against.

BA move:
Resolve the requirement once at the level of need, decision, and acceptance criteria, give it one traceable home, and match new-looking requests back to existing resolved needs before accepting them as new.

Why this hurts the project

Solve the same need three times and you pay for it three times. That is the obvious cost. The expensive part is underneath.

Each shape gets handled by whoever picks it up, often without knowing an earlier version exists, so it gets built slightly differently. The project ends up carrying two or three partial answers to one question, with the same rule enforced two ways in two places.

Traceability breaks. Ask which version is the real one and nobody can tell you. Meanwhile “done” stops meaning anything: something marked complete keeps generating fresh work. If nobody agrees what finished looks like, the two problems feed each other.

None of this means anyone did something wrong. The process let an unresolved need back in through a side door. That is a mechanics problem, and mechanics is where you fix it.

What this usually looks like in practice

The pattern is easier to spot once you know its disguises. The same need shows up in forms that all look like separate work.

Four tickets, four sprints, one need that was never closed. Each item is reasonable on its own, but together they are a project re-solving something it already paid for.

Likely causes

Every cause here sits in how the requirement was handled, not in who handled it.

It was resolved on wording, not on need. A sentence got approved and everyone nodded. But the need it was meant to serve was never pinned down independent of the phrasing. It stays live, and keeps producing new sentences.

The decision behind it was never captured. Most requirements carry an implicit decision: which rule wins, what happens at the edge, which case is in. If that decision was never made explicit and recorded, it gets re-decided every time the need resurfaces.

Nothing testable ever closed it. Without acceptance criteria that pin the behaviour, “done” gets declared when a feature ships, not when the need is met. A soft definition of done leaves the door open. You can write acceptance criteria that pin the behaviour, but only if you know what need you are closing.

It has no single traceable home. The requirement lives in a ticket, a doc, a chat thread, and someone’s memory at once, none of them canonical. When a new version appears, there is nothing to match it against.

Intake checks for validity, not for repeats. New requests get triaged for whether they are legitimate, rarely for whether the project already resolved this need in another form. A valid request and a new request are not the same thing.

Diagnostic questions

When the same requirement keeps circling back, trace it:

1. When this last “closed,” was it the wording that got approved or the need that got resolved?
2. Is there one canonical record for this requirement, or does it live in several places?
3. Is there a testable rule that confirms the need is satisfied, or was “done” declared on delivery?
4. Was the decision this requirement depends on ever made explicit and recorded, or does it get re-decided each time?
5. When the latest version arrived, did anyone check whether this need was already handled another way?
6. Are the versions consistent with each other, or has each shape been built or read slightly differently?
7. Is the recurrence logged as a change or as unfinished work? What does that classification assume?
8. Trace every ticket and change request in this area: how many are actually the same need?

If several point the same way, you are not dealing with churn. You are carrying an unresolved requirement that keeps re-entering because nothing ever truly closed it.

The IT Project Problem Diagnostic Checklist includes a Requirements Health section. Use it to check whether your requirements are actually resolved at need, rule, and acceptance level, or only signed off on wording.

What the BA can do about it

Resolve at need level, not wording level. Separate the approved sentence from the need underneath, and write the need in plain language that survives rewording. Output: a need statement that holds however the next request is phrased.

Capture the decision, not just the requirement. Surface the implicit decision and record it with an owner. Output: a decision the requirement points at, so it stops being re-decided informally.

Close it with a testable rule. Attach acceptance criteria that let anyone confirm the need is met, so “done” means satisfied, not shipped. Output: criteria that pin the behaviour and can be checked.

Give the requirement one traceable home. Pull the scattered versions into a single record: need, decision, rule, acceptance, owner, status. Output: one authoritative record; older shapes link into it instead of floating free.

Add a match-before-accept step to intake. Before a new-looking request is estimated, check it against the resolved needs you already hold and route any repeat to the existing record. Output: one triage question that catches repeats before they cost anything.

A move you can run this week: the consolidation pass

Pick the requirement that keeps coming back. Trace every shape it has arrived in and lay them side by side, then ask the only question that matters: is this one need or several? Almost always it is one.

Then merge them into one resolved record. Name the need. Record the decision. Write the acceptance criteria. Assign an owner. Set a status. Link every older shape to it. Now the need has somewhere to live, and the next version has something to be matched against.

A useful line to open the conversation:

Common mistakes

Estimating each new shape clean. Scoping every version as fresh work without checking whether the need already exists. This is how a project pays four times for one requirement.

Closing the loop with another sign-off. Getting new wording approved when the need underneath was never resolved. A more formally approved restatement of an unresolved need is still unresolved. Sign-off is not closure.

Logging the recurrence as scope change. This is unfinished existing work, not new scope. Filing it as a scope change assumes the original was finished, which was never true, and hides the pattern: the repeats look like growth instead of rework. That is a different problem from a scope boundary that keeps expanding.

Tightening intake gates and stopping there. Adding a stricter triage step without giving the need a traceable home to match against. A gate with nothing to check against just slows things down.

FAQ

How is this different from a decision being reopened?
A reopened decision is out in the open. People say “let’s revisit this.” A returning requirement is disguised: nobody flags it as a repeat, because nobody has spotted it as one.

Isn’t a returning requirement just vague requirements again?
Not quite. A vague requirement is unclear the first time you read it. Here each version can look perfectly clear on its own. The problem is the same need arriving, clearly, in different forms.

If each version looks clear, how is this a requirements problem?
Because clarity of a sentence is not resolution of a need. Every instance can be well written and still be the same unresolved need wearing a new label.

How do I tell a genuine change from the same need re-entering?
Trace it back to the need. If the underlying need is new, it is a real change. If only the phrasing moved, it is a repeat.

Where to go next

Pick one requirement that keeps reappearing and run the consolidation pass on it. Then check whatever arrives next in that area against the record before you accept it as new.

One consolidation pass will not fix a project. But it gives you the pattern. And the pattern is what stops you paying twice.

Before the same need slips back in under a new name, use the IT Project Problem Diagnostic Checklist to see whether unresolved requirements and uncaptured decisions are quietly stacking up across your project.