A review that looks healthy on a dashboard can still be stuck. Reviewed-document counts may rise while processing queues sit idle, privilege calls pile up, and finished batches bounce back from quality control. This checklist identifies where work stalls most often. Each item has a clear done/not-done state and a description of what good looks like. You don't need to rebuild your process. You need to find where work is waiting and fix that one spot.
Prerequisites
Before you start, ensure you have:
- A current list of datasets and their processing status
- Access to your review platform's batch and coding reports
- The written review protocol and any coding guidance issued since kickoff
- Named owners for privilege decisions, redactions, and quality control
- The production deadline and the current scope (custodians, sources, date ranges)
If any of these don't exist, items 1 and 8 will show you why that matters.
Checklist
1. Confirm which data is actually ready for review.
Pull a dataset-by-dataset status list showing what is processed, what is still processing, and what has open processing exceptions like missing searchable text or unsupported formats. Assign an owner and an expected date to each open exception. Tell reviewers what they can start now.
Done when: every dataset has a status, every exception has an owner and date, and no reviewer is waiting on work that was promised.
Good looks like: reviewers start on ready data while remaining data processes, and a late dataset shifts a batch schedule, not the whole timeline.
2. Test context on a sample from every source before bulk assignment.
Open a sample of documents from each source and confirm a reviewer can follow a chat thread, find the attachment an email mentions, and see dates and participants. Chat and collaboration data is where this fails first.
Done when: each source has a documented sample test with a pass or fail result.
Good looks like: reviewers rarely leave the review workflow to hunt for related items, and when they do, the cause is traced to missing data, document presentation, or unclear instructions.
3. Log recurring reviewer questions and route them.
Collect the questions reviewers ask more than once. Answer each one in writing and store the answer where every reviewer can find it. Name a qualified backup for routine coding questions.
Done when: a shared guidance log exists, has a date on each entry, and has an owner.
Good looks like: a question gets answered once. Privilege determinations stay with the responsible attorney. The backup covers routine calls only, so the speed gain never comes at the cost of a legal judgment.
4. Sample early and read the returned documents for patterns.
Pull small samples from the first completed batches and review the overturned or returned documents. Look for one misread instruction, one confusing document type, or a guidance change that never reached everyone.
Done when: you can state the cause of each rework pattern, not just the volume of rework.
Good looks like: a single clarified instruction or worked example corrects the pattern before it repeats across more batches.
5. Version and distribute coding guidance deliberately.
Every change to coding instructions gets a date, a version, and confirmed delivery to every active reviewer. Retire superseded guidance so two versions never circulate at once.
Done when: you can show which version each reviewer was working under on any given day.
Good looks like: inconsistent coding traces to individual judgment calls, not to reviewers working from different instructions. Version control here also supports defensibility if you later have to explain how decisions were made.
6. Track privilege and redaction as their own queues.
Report on documents awaiting privilege decisions, documents awaiting redaction, and documents awaiting redaction quality check, separately from first-pass review. Set interim dates for each queue rather than leaving them for the end.
Done when: you can read three separate counts at any time, each with an owner.
Good looks like: privilege and redaction work moves alongside first-pass review. A privilege log, where your jurisdiction or order requires one, is built incrementally. Clawback protections such as an order under Federal Rule of Evidence 502(d) are in place before production, not after.
7. Answer the "produce tomorrow" question in one place.
Ask: if we had to produce tomorrow, what would still need to happen? The answer should come from one view, not from searching email and spreadsheets.
Done when: a single status view lists completed work, pending work, blockers, and the owner of each blocker.
Good looks like: review completion percentage is never your only progress measure. Pending decisions, redactions, quality checks, and production preparation all appear on the same page.
8. Reopen schedule and budget when scope changes.
Any new custodian, source, or late-arriving dataset triggers a written review of the timeline and cost estimate within a defined window.
Done when: every scope change has a dated schedule and budget update attached to it.
Good looks like: nobody learns about a cost or deadline problem from the production date itself.
Common Mistakes
- Adding reviewers to a data-readiness problem. More people waiting on the same unprocessed data raises cost without raising throughput.
- Reading completion counts as progress. Documents marked complete that later return from quality control weren't complete.
- Delegating judgment instead of routine. Backups should clear coding questions, not privilege determinations.
- Leaving privilege and redaction to the final days. That work needs careful attention and often a second look, so it needs time on the schedule.
- Keeping guidance in email threads. Instructions buried in messages reach some reviewers and miss others.
Next Steps
Don't try to complete all eight at once. Start with three questions: where is work getting stuck, what is preventing it from moving, and what is the simplest change you can make now? Run items 1 and 7 first, since they expose the most delay for the least effort. Then work down to whichever item matches your team's loudest complaint.
Once the matter closes, carry the guidance log, sample test results, and status views into your Records and Information Management files for that matter. They document how decisions were made, and they give the next review team a starting point instead of a blank page.
