A revision and change-request workflow
Handle feedback and scope changes without losing the original decision.
Revisions become expensive when nobody can tell the difference between finishing what was agreed and doing something new. This workflow keeps that line visible.
Capture the change against the original approval
When feedback arrives, look at what was actually approved. The approval record carries the deliverable, the approver, and the note, which is what tells you whether this is a correction or a new request.
Decide whether it is a revision or new scope
A revision completes what was agreed. New scope changes it. Naming which one you are dealing with, out loud, before work restarts is the single most useful step in this workflow.
Record the change as its own task when scope moves
If it is new scope, create a task for it rather than absorbing it into the existing one. Absorbed scope is invisible scope, and it is why projects overrun without anyone being able to explain where the time went.
Return the work through Client Review
Send the revised deliverable back through the same review stage rather than approving it informally because it feels like a small change. Consistency here is what keeps the audit trail worth having.
Request a fresh decision and record it
Ask for a new named approval on the revised work. The previous approval stays as history, so you end with a sequence showing what was approved, what changed, and what was approved again.
What success looks like
- Each revision round has its own recorded decision, and scope changes exist as their own tasks rather than being quietly absorbed into work that was already agreed.
Common mistakes to avoid
- Absorbing new scope into an existing task, which makes overruns impossible to explain.
- Approving a revision informally because it seemed minor.
- Losing the original approval, so there is no baseline to compare the change against.
Common questions
No. Previous decisions remain as history, which is what lets you show the sequence of what changed.
Point at the approval record for the original deliverable, then at the new request as a separate task.
Related pages
Need help applying this workflow?
Tell us how your team works and we will help you set this up on a real project.