The costs that quietly accumulate in a data collection project

A collection project quote covers the work that goes right: the sessions that happen, the annotation that passes review, the files that arrive in the right format. Budget overruns come from the work that goes wrong, and the pattern of what goes wrong is stable enough to plan for.

None of the categories below are exotic. Each is common enough that a project which has budgeted for none of them is not optimistic. It is unfinished.

Re-collection

Some recorded material is not usable, and the reasons are mundane: a speaker was louder than the calibration assumed, a room turned out to have a ventilation hum, a session was damaged in transfer, or a voice did not match the screening description closely enough once it was in front of a microphone.

Re-collection costs more per unit than original collection, for a structural reason: it happens in small batches. A session for one speaker costs more per hour than a session for eight, because travel, setup, and coordination do not scale down.

The mitigation is contractual rather than technical. Agree on what fraction of re-collection is included in the price and what the rate is beyond it. Without that clause, the cost lands wherever the argument ends up.

Rework is priced at a premium

Rejected annotation costs more to fix than it cost to do, for two reasons. First, understanding why a piece of annotation was wrong takes context that the original annotator had and the reworker does not. Second, rework competes with production for the same annotators, so the hours spent fixing are hours not spent producing, and the project pays twice.

The worst version is late discovery. Rework found at final delivery means the acceptance process failed earlier, and the fix now touches a batch that has already been counted and scheduled around.

Two controls help: sample annotation continuously rather than at the end, and define in the agreement what rework is covered and what counts as a new order.

Format conversion and pipeline work

Data that is correct in content can still be expensive in shape. Files arrive with a different segmentation convention, timestamps at a different precision, metadata in a schema that does not match your loader, or channel layouts the pipeline does not expect.

Conversion is usually not hard, and it is usually underestimated, because it is nobody named task. It lands on an engineer between other work, gets done twice when the convention changes, and produces subtle errors — a shifted timestamp, a dropped channel — that surface much later.

The cheap prevention is a delivery specification with one validated example: a single file, in the exact format, that the producer must match. The validation script that checks it is reusable, and it converts a class of arguments into a pass or a fail.

Delay, which is a cost even when nobody invoices it

Schedule slip in a data project rarely appears as a line item. It appears as a model release moving, a team idling, or a launch decision made on weaker data than planned. For a roadmap that assumes the data arrives on a date, delay is often the largest cost in the project and the least negotiated.

Delay also compounds. A slip in collection pushes annotation into a period with less review capacity, which produces more rework, which pushes delivery again. The compounding is what makes recovery hard, which is why milestones belong at the points where slippage is detectable — end of recruitment, end of the pilot, first accepted batch — rather than only at delivery.

Budgeting for it

The line items above can be estimated, roughly, and estimating them roughly is far better than omitting them.

• Set contingency by novelty, not by habit. A second project in a familiar language and condition is predictable; a first project in a new population is not.
• Get rework and re-collection terms into the agreement, with included allowances and agreed rates beyond them.
• Fund the review work explicitly. Acceptance sampling is a named task with named hours, not something that happens in the gaps between other work.
• Define milestone payments where slip is detectable, so the first delay is caught while it is still small.
• Keep a written record of what went wrong, in cost terms, so the next project is budgeted from that record rather than from the original quote.