Process Experiments
Reducing rework
Find where completed work returns, clarify briefs and completion criteria, time reviews well and address recurring causes of rework.
To reduce avoidable rework, find where a deliverable changes direction after effort has been spent. Clarify the brief and completion criteria, seek feedback while changes are manageable, and investigate why finished work returns. Change the step that caused the return rather than asking people to work faster.
Decide what counts as rework
Revision is often part of the job. Planned drafting, testing and refinement should not be counted as failures. For a useful review, distinguish avoidable repetition caused by a missed requirement, approval, check or hand-off from a genuinely new request. Both take time, but they call for different responses.
Choose one recurring deliverable, such as a client proposal or monthly report. Examine a few recent returns: what was handed over, what change was requested, and when could the team reasonably have identified the issue? Check the brief, versions and feedback before assigning a cause. A return may stem from a decision outside the maker's control.
| Point in the work | Question to investigate | Possible response |
|---|---|---|
| Before work starts | Were the outcome, audience and constraints clear? | Clarify the request before committing to the full deliverable. |
| At acceptance | Did both sides agree on what complete meant? | Record conditions the recipient can check. |
| During review | Could the objection have been raised against an earlier version? | Set a review point while direction can still change. |
| At hand-off | Was a required check, file or decision missing? | Add the relevant requirement to the completion check. |
These are prompts, not assumed causes. Confirm the cause before changing the process.
Avoidable vs. Planned Revision: Key Differences
- Avoidable ReworkCaused by missed requirements, approval gaps, or hand-off errors; preventable with clearer briefs and checks.
- Planned RevisionPart of the process like drafting, testing, or refinement; expected and not a sign of failure.
Clarify the start and finish
A useful brief states the purpose, intended reader or user, deliverable, boundaries, deadline and the person who can resolve questions. If a major choice remains open, agree on an outline or sample that will help settle it before producing the full version. Keep the record proportionate to the work.
Completion criteria describe what the recipient will inspect. For a hypothetical monthly report, they might specify the reporting period, included business units, agreed data source and delivery format.
A standing team check, such as proofreading, serves a different purpose from a condition specific to this report. Name the person who will accept the work, and record any change to the criteria and its effect on scope or timing.
Pre-Hand-Off Checklist to Prevent Rework
- Purpose and audience defined?Yes – ensure clarity before starting work.
- Completion criteria documented?Include format, data source, reporting period, and acceptance person.
- Required approvals secured?Confirm all decision points are resolved before final submission.
- Proofreading and quality checks completed?Done by designated team member; record if external review required.
- Hand-off checklist signed off?Confirm all files, versions, and dependencies are included.
Ask for feedback while it can change the work
Give each reviewer a decision they are equipped to make. A sponsor may need to confirm direction; an operational user may need to check whether a draft is workable. Share an outline, sample or early draft with a specific question and response date when the answer could alter the approach.
When feedback arrives late, check whether it identifies an unmet condition, a material error or risk, or a new preference. Agree whether to correct the current work, change its scope or timing, or handle a new request later. A missed review window does not make a material concern safe to ignore.
Learn from repeated returns
For a limited period, record which deliverables returned, the stated reasons and what happened next. Group similar reasons, then inspect examples before calling any pattern a root cause. If reports return because approval occurs after the draft is marked complete, another proofreading step will not address the approval sequence.
Choose a process change that fits the evidence and give it an owner. Review later work of the same type to see whether that reason recurs or the change creates another delay. Keep expected iteration and new requests separate so the record remains useful.
In this guide
- Identifying unclear briefs before work beginsSpot missing outcomes, audience, scope and authority in a work brief, then ask focused questions before committing to the deliverable.
- Agreeing on completion criteria for a deliverableWrite observable completion criteria with the recipient, separate standing quality checks from deliverable-specific needs and manage changes clearly.
- Reviewing feedback that arrives too lateTriage late review comments, make scope and deadline trade-offs explicit, and set an earlier review point for the next deliverable.
- Tracking why completed work repeatedly returnsKeep a simple return record, investigate repeated reasons and check whether a targeted process change prevents the same rework.
