Change Requests That Never Stop: What They Actually Mean

I was brought in to assess a BI project that had produced 52 change requests since closing scope eight months earlier. The dashboards were live. The delivery had been on time. The requests had not stopped once.

The team had a name for what was happening: scope creep. Stakeholders who kept changing their minds. A brief that had not been locked tightly enough at the start. A project manager who should have pushed back harder at sprint three.

Those explanations were reasonable. They were also wrong.

Scope creep describes a situation where requirements exist and then change. What I find in most BI projects is different: the requirements never fully existed in the first place. What existed was a set of answers to questions asked under conditions that made complete, honest answers difficult. A workshop room. Senior stakeholders present. A two-hour window. Everyone managing their professional relationships in real time.

Those answers were transcribed and called a specification. The build started. And the requirements that were always there, held back by the format of the session, began surfacing at the first review, then the second, then the twentieth.

By request 52, every item on the list was something a user had known they needed before the build started. None of it was new information. It was information the specification process had no mechanism to reach.

There is a version of this pattern that looks like stakeholder indecision but is something more specific. The person who approved the specification and the person who uses the report daily are not the same person. The approver was in the meeting. The daily user was not consulted, or was consulted briefly, or was listed in the brief as "the team."

By delivery, the daily user has a set of specific needs that nobody documented, because nobody asked them in a setting where they could answer fully and without an audience. Every change request from that user is a legitimate need. It is also the direct cost of a specification process designed around availability and meeting attendance rather than usage.

This is not a stakeholder management failure. It is a structural gap. The format selected for a certain kind of output. That output was not complete requirements.

The math is straightforward. A question surfaced before the build costs a conversation and a revised specification. The same question surfaced after delivery costs a change request, a sprint to implement it, a review cycle, and often a rebuild of calculations built on the wrong assumption. Discovery done post-delivery typically costs three times what it costs pre-delivery. That ratio holds across project sizes and industries.

The change request backlog does not represent scope expansion. It represents the original discovery cost, deferred and compounded.

This is why the cycle has no natural end. Each batch of requests closes one gap and creates pressure on adjacent assumptions built on the same incomplete specification. Faster implementation does not fix the underlying cause. A more efficient process for incomplete discovery produces incomplete output on a shorter timeline.

The requests sitting in an open backlog are informative in one specific way. Read them in sequence and they map the gaps in the original specification. Most cluster around the same users, the same workflows, the same definitional questions that emerged in week one of the build and were filed under "post-go-live backlog."

That pattern is not stakeholder indecision. It is a record of the discovery phase the project never completed.

The question this raises is not "how do we manage change requests more efficiently." It is: how much of the original specification was built from what people said in a meeting, versus what they would have said with the meeting format removed? If the specification came primarily from a workshop, the backlog has more items in it than are currently visible.

A structured discovery reset addresses open change request backlogs at the root rather than one item at a time. Not by implementing requests faster. By surfacing the underlying needs those requests represent, before any more code runs on top of the existing wrong assumptions.

A reset is not a retrospective and not another stakeholder meeting. It is a process that reaches the people who were in the original workshop, the people who were not in the room, and the people who knew what they needed but had no mechanism to say it. The items that remain after root causes are addressed are almost always genuine scope changes driven by real business events after go-live. Those are a short list. They are not the cycle.

If the rate of change requests has not slowed six months after delivery, it will not slow on its own. The project is still in discovery. The discovery is just happening at the most expensive location: after delivery, in the form of individual requests, one sprint at a time.

The change requests sitting in your backlog right now are the discovery phase your project refused to pay for upfront. Each one costs more to implement after delivery than it would have cost to surface before build. If the cycle has no end in sight, the answer is not faster delivery. It is a structured reset that closes the discovery gap before the next sprint begins. → Stop the cycle