How to scope a data cleaning project so you actually get paid for it

"Can you just clean this up?" The client attaches one file and you say yes, because it looks like an afternoon. Then the afternoon reveals a second file "that should probably match this one," and a "quick" request to also fix the previous quarter, and a "while you're in there" to split one column into three. Three days later you're doing unpaid work on a project you never agreed to, and the reason is simple: you scoped a fixed price against an undefined amount of work. Cleaning projects don't lose money because cleaning is cheap. They lose money because "clean this up" has no edges.

Why "clean this up" is unbillable as written

A scope needs a boundary the client can't quietly move. "Clean this up" has none — it doesn't say how many files, how many rows, what "clean" means, or what happens when a new file appears. So every extra request feels, to the client, like it was obviously included, and to you like a favour you can't refuse without seeming difficult. The fix isn't to work faster or push back harder in the moment. It's to write a scope where the boundary is on paper before you start, so a new file is visibly a new job.

The example: turn a vague ask into a scoped one

Here's the same project written so it can actually be billed and defended:

Data cleaning — Q2 sales, statement of work
  Source:        1 file, orders_q2.csv, ~4,800 rows, 11 columns
  Cleaning:      standardize dates, dedupe on Order ID,
                 map Region to 8 approved values, validate ranges
  Deliverable:   1 cleaned CSV + change log + reconciled total
  Price:         £540 fixed
  Assumes:       one source file, columns as sampled 2026-07-06
  Extra files or columns: £90/hr, quoted before work starts

Notice what the row count and the "assumes" line do. When the client sends a second file, you don't argue about whether it's included — the scope already answered it. You reply, "happy to — that's a second source, so it's an extra £180 on the same terms," and the conversation is about a number, not about your goodwill. The scope did the pushing back so you didn't have to.

Scope a cleaning project in six lines

1. Count the inputs. Name every file and its approximate row and column count. "One file, ~4,800 rows" is a boundary; "the data" is not.
2. Define what "clean" means here — the specific operations: dates, duplicates, category mapping, validation. Anything not listed is out of scope by default.
3. Name the deliverable — a cleaned file, a change log, a reconciled total. The client should know exactly what lands in their inbox.
4. State the assumptions about data condition and structure, dated, so "the file changed" becomes a visible trigger, not a silent cost.
5. Set a change-request rate in advance — "extra files or columns billed at £90/hr, quoted first." Now scope creep has a price list.
6. Take a snapshot of the input. Save the file exactly as received so you can show what changed if the client says "it was always like that."

The scope is what lets you say yes

A written scope isn't about being rigid or difficult; it's the thing that lets you be generous safely. When the boundary is clear, you can happily absorb a tiny extra without resentment, and charge fairly for a real one without a fight, because both of you can see which is which. The analysts who make good money on cleaning aren't the ones who say no more often — they're the ones whose scope makes every "one more thing" a quick, unawkward quote instead of another evening given away. Define the edges once, and "can you just clean this up?" stops being a trap and becomes a project.