How much rework does an unclear market research brief create?
A measurement protocol for counting rework caused by ambiguous research briefs, with definitions, sampling, and reporting limits.
Question and scope
This protocol asks how often a market research deliverable has to be redone because the original brief was unclear. The scope is one research request from intake through the first accepted deliverable. Rework includes a new scope, a new sample, a rewritten summary, or a second review cycle caused by a missing definition. It does not include normal copy edits or formatting changes that do not affect the evidence.
The protocol is designed for a small GTM research function that handles several requests each month. It uses records the team already keeps, such as the brief, the source log, review notes, and the delivery date. The goal is a repeatable count, not a judgment about any individual analyst. A team can run it without a new survey or a new software purchase.
Definitions and unit of analysis
Define the unit as one research request with one decision owner and one accepted deliverable. If a request is split into two deliverables for different decisions, treat each as a separate unit. If a deliverable is revised after acceptance because the decision changed, record it as a new request rather than rework. The distinction keeps the count tied to the original brief.
Classify a rework event only when the request returns to an earlier stage. Examples include a new population, a different source standard, a new deliverable format, or a second synthesis after the evidence was already reviewed. A clarification that does not change the work is not rework. Record the reason in a short code so the team can compare causes.
Data sources and sampling
Use consecutive requests over a defined window, such as one quarter, rather than selecting only the difficult cases. If the volume is too high, take every second or third request and state the sampling rule. Include requests that were cancelled, because a cancelled request may still reveal an unclear brief. Exclude requests that never reached a brief.
Record the request date, the decision owner, the analyst, the scope, and the first delivery date. Link the review notes that show why a revision was requested. If the team uses a ticket system, export the status history rather than relying on memory. A sample without the underlying notes cannot distinguish rework from a normal review.
Measures of rework
The primary measure is the share of sampled requests with at least one rework event. Report the numerator and denominator, not only the percentage. Add the median number of rework events per affected request and the median days added to delivery. These three numbers describe both frequency and cost without requiring a complex model. The count of affected assets matters more than a polished percentage.
Use secondary measures to explain the pattern. Count rework caused by a missing decision, an undefined population, an unacceptable source, or a deliverable mismatch. Track whether the brief was reviewed by the decision owner before work began. A simple cross-tab of review status and rework reason is often enough to point to a fix. A simple cross-tab by asset type is usually enough to show where to look first.
Collection procedure
Before collection, agree on the definitions with the analysts and the decision owners. Test the coding sheet on five recent requests and resolve disagreements. Then collect the sample in one pass, using the same fields for every request. Record the collector and the date so a later reviewer can repeat the exercise. Record the test result and any coding change before the full collection begins.
For each rework event, write a one-line description and assign one primary reason. Do not use a catch-all category such as unclear brief unless the note explains what was missing. If a request has several causes, choose the one that triggered the return to an earlier stage. Keep the other causes in a note for context.
Analysis and reporting
Report the sample window, the number of requests, and the inclusion rule before presenting any rate. Show the rework share with a confidence interval or, for a small sample, the raw counts. A rate based on twelve requests should not be presented as a stable organizational average. Say plainly what the sample can and cannot support.
Separate observation from interpretation. The observation might be that six of twenty requests needed a new population definition. The interpretation might be that the intake form lacks a required field, but that needs a separate check. End the report with the evidence needed to confirm the likely cause and a proposed review date. That separation keeps the report honest about what the data can support.
Limits and sources of error
The main limit is that rework depends on how the team records review cycles. A team that resolves issues in conversation may look better than a team that documents them. A team that documents every small change may look worse. State the recording practice beside the result so readers do not compare unlike teams. Record the practice in the report so readers do not mistake documentation for performance.
Small samples are sensitive to one or two requests, and the mix of request types can change over time. A quarter with several complex launches may produce more rework than a quiet quarter. Report the mix and avoid attributing the difference to analyst performance without evidence. The cited public sources frame evidence and privacy practice; they do not provide a benchmark for this sample.
Review cadence
Repeat the protocol after the team changes the brief template or the intake process. Use the same definitions and sampling rule so the comparison is meaningful. Report what moved, what did not, and which causes remain unexplained. Keep the coding sheet and the sample file with the report. Keep the prior coding sheet with the new one so the definitions can be compared.
Review the protocol once a year even if the process has not changed. The team may have new request types or a different mix of decision owners. Update the definitions only with a clear reason and keep the prior version. The purpose is a practical measure that helps the team improve its briefs, not a permanent scorecard.
Comparing brief versions
Compare the old and new brief templates on the same five requests. Use the same reviewer and the same coding sheet for both versions. Record where the new template removed a question, added a required field, or changed the evidence bar. A template change that is not tested on real requests can introduce a new ambiguity while fixing an old one.
Keep the comparison small enough to finish and specific enough to explain the result. If the new template reduces rework in the sample, check whether the reduction comes from better scoping or from a simpler request mix. Report both possibilities. The comparison is a clue, not proof that the template caused the change. Use a fixed sample so the second version is judged on the same work.
Reporting to the team
Present the result to the analysts and decision owners together. Show the definitions, the sample, and the main cause before the recommendation. Ask the analysts whether the coding matches their experience, because they may see a cause the review notes missed. A report that is not discussed with the people doing the work is less likely to change the process.
Keep the report short and attach the sample file. A one-page summary with three findings is easier to use than a long deck. End with the one change the team will make and the date it will be checked. Store the report where the next reviewer can find it without asking for the file. A short report is more likely to be read before the next request arrives.
What to do with the result
Use the result to choose one change to the brief template or the intake process. If missing decision context is the largest cause, add a required field and a short example. If the population is the largest cause, add a checklist that the decision owner must approve. Set a date to remeasure with the same definitions.
Share the change with the analysts and the decision owners. Explain what will be different at intake and what will not change. A template change that arrives without context looks like more administration. Keep the old template available for requests already in progress. Ask for one question at the next intake review. The team should agree on the example before the next request.