The Client Changed the Brief. Collection Had Already Started.

The brief looked clear when the project started. The client needed audio recordings in four regional languages, from contributors in a specific age range, following a set of conversation prompts that had been approved two weeks before collection began. The contributor pool was sourced, onboarded, and recording. Completion was running ahead of schedule.

Then the client's model team ran preliminary analysis on the first batch and discovered something their acoustic engineers had not anticipated: the prompt set was producing recordings that were too phonetically similar across contributors to provide the variation the training pipeline needed. They needed a new prompt set, a broader age range, and an additional language variant that had not been in the original brief. Could the project absorb this?

Situations like this are not rare. They are a predictable feature of AI data collection projects, because the process of collecting data frequently reveals things about the data that were not visible when the brief was written. Model builders are working from assumptions about what they need until the first batch of real data arrives and tests those assumptions against reality. When the assumptions turn out to be incomplete, the brief changes. The question is how that change gets managed.

Why Scope Changes Happen Even on Well-Specified Projects

A data collection brief that has been carefully specified at the start of a project represents the client's best understanding of what they need at that moment. It does not represent a complete picture of what the training pipeline will require, because that picture only becomes fully visible once the data starts flowing and the model team begins testing it.

This is not a failure of the scoping process. It is the nature of working at the frontier of a technology that is still being refined. The acoustic properties of a training dataset only become visible when the model starts training on it. The demographic distribution that seemed adequate on paper may prove insufficient when the model's performance on specific population segments starts to diverge. The annotation schema that was designed for one use case may need adjustment when the use case evolves in response to new product requirements.

Good scoping reduces the frequency and severity of mid-project changes. It does not eliminate them. Any data collection partner that claims otherwise has not run enough projects to know what they are committing to.

What Is at Risk When a Change Arrives Mid-Collection

A scope change that arrives after collection has begun puts four things at risk simultaneously, and managing the change well requires addressing all four rather than focusing only on the most visible one.

The most visible risk is the data already collected under the original scope. If the new requirements make that data unusable for the training pipeline, the cost of the collection work already completed is at least partially lost. Before any other decision is made, both the client and the partner need a clear-eyed answer to the question of what the existing data is worth: whether it remains usable for any part of the original or revised use case, whether it can be reannotated to meet the new specification, or whether it needs to be set aside entirely.

The second risk is the contributor pool. An active contributor pool is not a static resource. It is a set of human beings who are in the middle of a task they agreed to complete, under conditions that have now changed. Some of those changes will require them to do different work than they signed up for. Others will make their contributions no longer useful. Handling this badly, by abruptly stopping collection without explanation or by suddenly changing instructions without clear communication, erodes the trust that makes contributors reliable, and reliable contributors are the scarcest resource in any data collection operation.

The third risk is the project timeline. A scope change mid-collection effectively restarts part of the project. New contributor profiles may need to be sourced, new onboarding instructions distributed, new quality checks designed. This takes time, and the client's model training schedule rarely has room for the full delay this implies. Managing expectations about timeline impact is a responsibility the partner needs to take on honestly, even when the honest answer is uncomfortable.

The fourth risk is the client relationship itself. A change that is handled with clarity, honesty about costs, and a concrete plan for recovery strengthens the relationship because it demonstrates exactly the kind of operational competence that justified the partnership. A change that is handled defensively, or that produces a surprise invoice without prior discussion, damages the relationship in ways that outlast the project.

How to Communicate a Scope Change to an Active Contributor Pool

Communicating a scope change to a contributor pool that is actively recording requires a different approach depending on how significantly the change affects what each contributor has been asked to do.

For changes that affect only new contributors going forward, the communication is relatively straightforward: update the onboarding brief, ensure all new contributors are working from the revised instructions, and maintain a clear separation in the dataset between files collected under the original brief and files collected under the new one. This separation matters for the client's model team, who will need to know which data meets which specification.

For changes that require existing contributors to redo or extend their completed work, the communication requires more care. Contributors who have already submitted work in good faith under the original brief have a reasonable expectation that they will be compensated for that work even if it is no longer usable. Asking them to redo the work at no additional cost damages the relationship and, practically, reduces the likelihood that they remain engaged through the revised project. A clear explanation of what changed, why it changed, and what the contributor will receive for both the original work and any additional work, is the only approach that keeps the contributor pool intact.

For changes that make a portion of the contributor pool unnecessary entirely, honest and timely communication is more important than delay. Contributors who have been onboarded and are waiting to begin need to know quickly if the project no longer needs their participation, both because it is the right thing to do and because contributors who are kept waiting without explanation become contributors who are unavailable or unresponsive when the project needs them again in the future.

What Data Collected Under the Old Scope Is Worth Saving

The instinct when a scope change renders part of a dataset unusable for the original purpose is to write it off entirely. This instinct is often wrong, and acting on it without analysis is one of the more expensive mistakes in data project management.

Data collected under a superseded brief frequently retains value in ways that are only visible once the change is clearly understood. Audio collected with an original prompt set that is now being replaced may still be useful for a different aspect of the training pipeline, particularly if the acoustic properties of the recordings are sound even if the semantic content has changed. Images collected for one annotation task may be reannotatable for a related but distinct task without the need for recollection. Demographic data collected for one language variant may partially overlap with the requirements of the new language variant being added.

The assessment of what is worth saving requires a conversation between the partner's quality team and the client's model team, with the actual data available for review. It cannot be done at the brief level alone. Preserving the option to have this conversation, rather than disposing of or archiving the original dataset before the scope change has been fully characterised, is a default position that costs nothing and occasionally saves significant collection time and cost.

How to Protect the Client Relationship When the Brief Moves

The clearest signal of a partner's operational maturity is how they handle a scope change that was not their fault. It is easy to perform well when conditions are exactly as specified. It is harder to stay structured, transparent, and solution-oriented when the ground has shifted mid-project and the easy path is to manage the situation quietly and hope the client does not notice the impact on quality or timeline until it is too late to address directly.

A partner who surfaces the scope change clearly, quantifies the impact honestly, proposes a recovery path concretely, and executes against it reliably becomes more trusted after the difficulty than they were before it. The disruption becomes evidence. The client has now seen what the partner does when things are hard, which is a more reliable predictor of future performance than any number of smooth projects where nothing unexpected happened.