Practical Guide · Based on the operating approach described here. All project examples below are fictional.
Learning how to organize multiple projects became more important once I was responsible for moving all of them forward myself. I used to put everything into one large task list. A small administrative job sat beside a complicated decision and a project waiting on someone else. The list was complete, but it did not tell me what to do next.
The useful change was separating project context from weekly action. Use one overview to see the portfolio, one page to hold each project’s context, and a short weekly list drawn from those pages. The overview should help you choose; it should not contain every task.
Keep one overview of the projects that need attention
Start with the fields below. A spreadsheet, document, notebook, or existing project tool can work. Keeping the information visible and current matters more than the software. Update a row when a decision, dependency, or next action changes—not merely because you opened the project.
Fictional example: an overview prepared on a Monday. Dates are relative to that example week. On a narrow screen, scroll the table sideways.
| Project | Current status | Next action | Waiting on | Deadline / important date | Last meaningful update |
|---|---|---|---|---|---|
| Harbor service page | Active | Draft the agreed opening section | Nothing for this step | Draft due Thursday | Monday: outline approved |
| Maple monthly report | Waiting | Check for the corrected export on Tuesday | Client’s data contact | Report due Friday; data needed Tuesday | Monday: missing period identified and requested |
| Desk filing cleanup | Parked | Decide whether to resume at next week’s review | Nothing; deliberately deferred | Review next Monday; no delivery deadline | Last Friday: paused to protect delivery time |
Active means there is work you can do now. Waiting means name the dependency and the next check date. Parked means deliberately deferred, with a review date rather than a pretend deadline. Keep completed projects out of the working overview.
Give each project one page of useful context
A task such as “revise draft” is not enough after a gap. Keep the answers needed to restart beside the work. Copy this structure into the project’s existing home; do not create another database just to hold it.
Project page structure
- Objective: What result makes this project worth doing?
- Current state: What exists, and what is still incomplete?
- Next action: What specific action can be started next?
- Key decisions: What was decided, why, and what is no longer being considered?
- Important links/files: Where are the current working material and agreed scope?
- Waiting on: Who owes what, and when will it be checked?
- Restart note: Where did work stop, and what should be opened first?
Fictional restart note for Harbor: “The outline is approved. The opening still describes features instead of the customer’s problem. Open the current service-page draft, rewrite its first two paragraphs against the agreed outline, then stop for review. Leave the pricing section unchanged.”
This is the purpose of work documentation: the person receiving the handoff may simply be you several days later. A useful restart note preserves the decision and the next move, not a diary of everything you did.
Choose the next project by consequences and dependencies
When several projects compete, use this order as a starting rule:
- Check what will become impossible if delayed. Work backward from a real commitment, including the time another person needs to review or supply something. A Friday deadline may require a Tuesday request.
- Unblock a dependency you can actually affect. Send the specific request or make the decision that allows the next stage to begin. Do not keep a blocked project open on screen while waiting.
- Choose one available action with a meaningful consequence. Prefer the step that protects a commitment or enables later work over polishing something already sufficient.
- Break a tie by finishing an open stage. Close a draft, handoff, or decision before adding another half-finished stage, unless a harder constraint overrides it.
In the fictional overview, request Maple’s missing export before settling into Harbor’s draft. That request protects the reporting window; it does not mean spending the day on a report whose inputs are unavailable. Leave Desk parked. For harder tradeoffs, use the fuller guide to prioritizing tasks when everything feels important.
Pull a small weekly list from the overview
Choose the outcomes that fit the time actually available, then pull their next actions into the week. Keep waiting-on checks separate from work sessions. If a new commitment arrives, decide what moves out; do not silently expand the list. Weekly planning with room for interruptions explains that capacity decision.
I group similar work when I can, but only after choosing the priorities. Batching administration is useful; postponing a blocking request just to preserve a perfect writing block is not. This is where context switching becomes a practical scheduling question.
Leave a restart point before switching away
Before closing a project, update its current state, next action, and any new dependency. Add a restart note if the next move would otherwise be unclear. If you return after several days and still have to search old messages to understand what happened, improve that note rather than adding more task categories.
For work paused halfway through, the guide to restarting unfinished work develops this further. The operating test is simple: can you open the overview, choose a project, and begin its next meaningful action without reconstructing the whole story?
Updated 6 October 2026: added a fictional project overview, project-page structure, dependency-based selection rule, and restart example.
