How Rework Actually Starts

A partner asks an associate to pull together a market overview ahead of an IC. No template. No defined scope. No indication of what decision this is meant to inform.

The associate makes sensible assumptions and spends a day building something thorough.

The partner reviews it. Half of it isn't what they needed. A third of it duplicates something already in the model. The angle is wrong for where the IC conversation is likely to go.

The associate revises. The partner reviews again. By the end, the output is usable but it took twice as long as it should have, and the pressure going into IC is higher than it needed to be.

Nobody made a mistake. The brief was just never clear enough.

The Cost That Doesn't Get Named

Deal teams track time on deliverables. They rarely track time on revisions, re-briefs, or the conversations that happen because an output landed wrong.

That's where a significant amount of junior time goes. Not on new work, but on correcting work that was started without enough clarity.

The senior person who gave the vague brief doesn't see that cost directly. They see a slow turnaround and chase for an update. The associate who received it absorbs the pressure of the revision without anyone acknowledging why the revision was necessary.

Over a live deal, that pattern repeats across every deliverable: the model, the memo, the management pack summary, the data room tracker. Each one starts slightly ambiguous. Each one generates at least one correction cycle. The cumulative drag is substantial.

What a Good Brief Contains

The difference between a brief that works and one that doesn't is not length. It is specificity on four things:

What decision does this feed? Output quality improves immediately when the person doing the work understands what it will be used for. A market overview for an IC conviction conversation looks different from one that's informing a bid decision.

What does done look like? Format, length, level of detail. If the partner has a mental image of the output, they should describe it. If they don't, they should say so and agree one before work starts.

What's in scope and what isn't? The fastest way to generate wasted effort is to leave scope implied. Explicit boundaries prevent the over-engineering that looks thorough but adds no value.

When is it actually needed? Not "EOD". A specific time, and enough lead time for a proper output. Work produced in the last hour before a deadline is rarely the work anyone wanted.

The Structural Fix

Individual briefing quality improves with feedback. But feedback on a brief rarely happens, because the rework gets absorbed quietly rather than traced back to its cause.

The fix is to make good briefing a habit, not a skill. Standard templates for recurring deliverables. A single clarifying question before work starts: what decision does this feed? A norm where anyone receiving a brief can ask for clarity without that being seen as a failure of initiative.

None of this is complicated. It is also not the default in most deal teams.

The Question Worth Asking

On the last piece of work that came back for revision: what would the brief have needed to say for the first version to have been right?

If the answer is clear in hindsight, the brief was fixable. It just wasn't fixed before work started.