How to Track Waiting Items on Paper When a Project Involves Several People
When a project is stalled because someone else needs to reply, approve, send, or decide, write that dependency on one shared paper log. Give every item a clear next step, one named person to follow up, the person or group you are waiting for, and a check-in date. Review the log at an agreed time, update its status, and close or escalate items when their condition changes. This method is for teams that need a simple way to see who owes what and what is blocking progress; it is not a full project plan or a substitute for a dated schedule.
What belongs on a waiting list?
A waiting item is a specific response, handoff, or decision that another person must provide before you can continue. Examples include a client’s approval of a proof, a supplier’s delivery estimate, or a colleague’s cost figures. Record the expected result, not just “waiting on Sam.” A useful entry might say: “Sam — send revised cost figures for the North Hall estimate; needed to finish the quote.”
The Getting Things Done organization’s explanation of a “Waiting For” list treats follow-up on other people’s commitments as part of managing open work. Its article also describes agenda items as things to raise when the relevant person is available. That distinction is useful for a project log: record a pending commitment as waiting, but put a topic you can only raise in a meeting on the agenda for that person or meeting. See [“Waiting For” Advice from Getting Things Done](https://gettingthingsdone.com/2011/01/waiting-for-advice/).
A waiting log should not become a parking place for every unfinished task. If you can make progress yourself now, write that action on the project’s action list. If a supplier has promised delivery on a specific date, retain that commitment in the schedule too; the paper log helps with follow-up but does not replace the date that drives the plan.
Choose the paper layout for your team
For a small project, use one page or a few consecutive pages in a notebook or binder. Keep it in a place project participants can consult, and assign one person to maintain it. If people cannot access the same sheet, agree where its current version lives and who updates it; two competing copies make ownership and status hard to trust.
Draw these columns across the page:
For each paper row, include an ID, the project, the expected result and person supplying it, the follow-up owner, a check-in date, and status with the last update. For example: **W-01 · North Hall quote · Sam to send revised figures · Lee follows up · check 14 May · open; requested 10 May.** A second row might be **W-02 · North Hall quote · client to approve or revise proof · Lee follows up · check 15 May · open; proof sent 11 May.**
These sample dates and people are illustrative. Adapt the columns to your team, but preserve three distinctions: who is expected to provide something, who on your team will follow up, and when that follow-up should happen. This structure builds on common action-item log fields such as an identifier, description, owner, due date, status, and notes; see [Smartsheet’s action-item template guide](https://www.smartsheet.com/content/action-items-templates). The extra “waiting for” and “check-in” fields make the dependency and your team’s next move visible.
Use one line per deliverable or decision. When several people owe separate inputs, give each a separate ID, even if they relate to the same project. If a response depends on another response, note the predecessor in the description—for example, “Finalize draft after W-03 figures arrive.” This makes the dependency easier to spot without drawing a complicated diagram.
How to start and maintain the log
1. Capture the commitment while it is fresh
At the meeting or handoff where the work is assigned, write the expected result, the person expected to provide it, and any agreed timing. Confirm the wording with the participants: “I have you sending the revised figures by Tuesday; I’ll check in Wednesday if they have not arrived.” The purpose is to remove ambiguity about the request and the next follow-up, not to imply that a date was agreed if it was not.
2. Name one follow-up owner
For each entry, choose one person on your team to monitor it. Several people may depend on the result, but one named owner prevents the follow-up from disappearing between participants. If responsibility changes, cross out the old owner neatly, write the new one, and note when the handoff happened. Avoid assigning the entire team as owner: that describes a group, not who will take the next step.
3. Pick a check-in date that reflects the work
Use the date someone actually committed to when one exists. If no date was agreed, choose a reasonable date for checking the status based on the project’s next milestone and how soon the information is needed. Mark it as your check-in date, not the other person’s promised delivery date. For a critical dependency, choose a check-in early enough to leave time for a reminder, an alternate plan, or a discussion with the project lead before the milestone is affected.
A calendar is still useful for fixed appointments and deadlines. The log answers a different question: “What do we need to follow up on, and who will do it?” Avoid copying every date in a way that makes it unclear which date is a commitment and which is your reminder.
4. Review at a predictable point
Review the open entries at a regular project check-in or at another interval that suits the project’s pace. For each row, ask: Has the result arrived? Is it still needed? Is the check-in date due? Has the dependency or owner changed? Update the last-update note briefly, such as “reminded 14 May; new ETA 16 May.” A physical log is useful only if someone looks at it and changes it when reality changes, so keep the review routine short and consistent.
When an item is overdue, follow the agreed route: contact the person, clarify a new date, or raise the impact with the project lead if the delay threatens a milestone. Record the new commitment and the next check-in. If the person cannot provide the result, capture the decision needed—such as whether to use an alternate supplier—as a new action with its own owner and date.
5. Close items visibly
When the expected result arrives, mark the row complete and add the completion date. If it is no longer needed, mark it cancelled and state why. Do not erase closed rows immediately: keeping them until the page is full helps the team understand recent changes and avoids confusion about an item that disappears without explanation. When starting a fresh page, carry forward only genuinely open items and their current details.
How to keep the log manageable with many contributors
If the page fills with dozens of entries, group rows under project workstreams or use a separate page for each workstream, while keeping the same columns and ID system. Put a page reference beside IDs that continue elsewhere. Do not create separate lists for every person unless one person truly manages an independent stream; otherwise the project lead loses the cross-team view of what is blocked.
Agree on a small set of status marks, such as **Open**, **Due**, **Complete**, **Escalated**, and **Cancelled**. Keep the meaning explicit. For example, “Due” means the team’s check-in date has arrived, not necessarily that the other person missed a promise. Use a symbol plus a written status if handwriting or photocopies may make colors unreliable.
If the project already uses a shared record, or participants work in different locations and cannot see the same paper log, use that shared record as the current version. A paper list can still serve as a meeting aid, but the team should know which record is authoritative and avoid maintaining conflicting versions.
For comparison, [Asana’s action log template](https://asana.com/templates/action-log) gives each follow-up an owner, due date and context in one current record. A paper page can carry the same minimal accountability, provided the team agrees who updates the page and where the current version lives; the template does not establish that paper works for every distributed team.
A quick decision check for a new item
Before adding a row, ask:
1. **Is another person’s specific input needed?** If no, capture your own next action elsewhere.
2. **What exact result are we waiting for?** Write the deliverable or decision in plain language.
3. **Who follows up for this project?** Enter one person from your team.
4. **When should we check again?** Separate the other person’s promised date from your reminder date.
5. **What happens if it slips?** Identify the next contact, alternate route, or escalation point when the milestone is at risk.
A well-kept waiting log is less about paperwork than shared clarity: each pending item has a visible outcome, a responsible follow-up owner, and a next review point. Set up the columns once, confirm commitments as they are made, and use the review to move each row forward or close it.