The request sounded simple: change a page, add a field, connect a form. Three months later, the email thread is longer and the live experience is the same. The delay may not be a lack of effort. The job can be waiting between people who each control one necessary part.
Find the queue where it stopped
Start with the last completed action, not the first complaint. Was the change approved? Is the source content final? Does someone hold access? Is another supplier responsible for a dependency? Is the request priced but unaccepted? “Waiting on the client” is not enough detail to move it. Name the decision or input and its owner.
A useful work item describes a visible outcome, the affected page or workflow, what must be supplied, who can approve it and how the result will be checked. If those details are unknown, a short discovery task may be the real first job.
Make the next action small and finishable
Separate the request into one decision at a time: confirm the copy, identify the system owner, approve the estimate, grant access, implement, review, release. Each step gets one person and one completion condition. This exposes the true blocker without turning every small change into a programme.
Protect the request from quiet expansion
Record what is included and what would change the estimate: extra templates, new content, data cleanup or another integration. When a dependency changes, return to the named approver before work absorbs it. The job becomes manageable when the team can tell progress from waiting and waiting from new scope.
A practical inspection
- Name the requested outcome and affected workflow.
- Identify the last completed action and current blocker.
- Assign an owner and due condition to each input or approval.
- Define a visible acceptance check.
- Record what would expand scope.