How do I close out a project when some requested items remain unresolved?
Quick answer
Close out by documenting what was delivered, what remains unresolved, and what has not yet been accepted. For each open item, state its status, the next action, who is expected to act, and a target date only if one is agreed. Record acceptance only when it has actually been confirmed. If your involvement is ending before everything is settled, label that accurately rather than implying every requested item was completed.
The question, the details, the next step.
I need to wrap up a project, but a few requested items are still unresolved. How can I close it out without making it sound like everything was delivered?
Use a written summary with separate sections for completed work, open items, and pending acceptance. Start with a neutral status line, such as: “This summary records the work delivered through [date] and identifies requests that remain open or awaiting confirmation.”
For completed work, name the specific deliverables and their status. For unresolved requests, say what is missing or undecided and what would move the item forward. Don’t list unfinished work as completed just because the rest of the project is ending.
Clarify what is closing: the project, your involvement, or both. If a next step or timing is not agreed, mark it “to be confirmed” rather than implying a commitment.
What details should I include for each open item so someone can act on it?
Give each item a brief, recognizable name, then record its current status and why it remains open. Add the next action, the person or group expected to take it, and a target date only if one has been agreed. If the next action depends on a decision or input, name that dependency.
For example:
Open item: [Requested item] Status: Not completed; awaiting [decision or input] Next action: [Specific action] Expected owner: [Name or role, if agreed] Target date: [Agreed date / To be confirmed]
Keep the wording factual. “Awaiting a decision on the requested format” is clearer than “blocked by the client,” unless that description is accurate and useful. If nobody has accepted ownership, say so rather than assigning it by implication.
How do I handle items that were sent for review but have not been accepted or rejected yet?
Put those in a distinct “Pending acceptance” section. Identify what was submitted and when, using details available to the project participants, and state what confirmation is outstanding. Do not describe a submission as accepted unless acceptance has actually been communicated.
For instance: “Draft [deliverable] submitted for review on [date]. Acceptance status: pending confirmation from [reviewer or role]. Next step: [reviewer or role] to confirm acceptance or provide requested changes by [agreed date / date to be confirmed].”
If there is no agreed review deadline, don’t invent one. Ask the relevant person to confirm the status and next step. A pending review is different from a completed, accepted deliverable and should remain visibly separate.
Can you give me a copyable closeout summary that makes those distinctions clear?
Yes. Adapt this template, remove sections that do not apply, and mark uncertain details for confirmation:
Project: [Project name] Closeout summary date: [Date] Scope of this summary: [Work or period covered] Overall status: [Project closing / my involvement ending / other accurate description]
Completed
- [Deliverable or task] — [what was delivered and when]
- Acceptance: [Confirmed / not applicable / pending; specify]
Open items
- [Requested item] — Status: [what remains unresolved]
- Next action: [action] | Expected owner: [person or role, if agreed]
- Target date: [agreed date / to be confirmed]
Pending acceptance
- [Submitted deliverable] — Submitted: [date or reference]
- Acceptance status: Pending confirmation from [person or role]
- Next step: [action and agreed timing, or “to be confirmed”]
Not included or deferred
- [Item, if applicable] — [reason or decision status]
Before sending, check that each statement reflects the current record, that open requests are not described as delivered, and that any owner or date is genuinely agreed. Ask recipients to flag corrections or confirm outstanding decisions by [date, if appropriate].
A practical checklist
List deliverables actually completed and state what was delivered.
Move unfinished or undecided requests into an open-items section.
Separate submitted work awaiting confirmation from accepted work.
For each open item, name the next action and agreed owner; mark unknowns as to be confirmed.
Use dates only when agreed, and clarify whether the project or only your involvement is closing.
A few more useful answers
Should I call the project complete if open requests remain?
Use “complete” only if it accurately describes the agreed scope and status. Otherwise, specify that the project or your involvement is closing while named items remain unresolved.
What if no one has agreed to own an open item?
Mark the owner as unassigned or to be confirmed, and identify who needs to agree on the next step. Do not imply that a particular person has accepted responsibility.
Should I include a deadline for pending acceptance?
Include a deadline only if it has been agreed. If not, say that timing is to be confirmed or request a review date.