Templates & Workflows: A GTD Weekly Review and Project Planning System

The weekly review is a reset, not a planning ritual

A weekly review is easy to mistake for a longer version of Monday morning planning. In David Allen’s Getting Things Done (GTD), it has a different job: bring your system up to date so you can trust what it says. That means gathering loose inputs, clarifying what they mean, and checking that your lists reflect the work you have actually agreed to do.

Only after that cleanup should you choose priorities for the week. Otherwise, planning becomes an exercise in picking from an incomplete picture. A request sitting in an email thread, a promise made after a meeting, or a project that quietly stalled can all disappear from view while the neatest items on your task list get attention.

The method below makes the handoff explicit. First, review the commitments and open loops. Next, give each active project a concrete next action and an owner. Then use your calendar and available capacity to shape a realistic plan for the five workdays ahead. The result is not a guarantee that the week will go as expected; it is a current, visible starting point.

GTD’s familiar distinction matters throughout: a project is an outcome requiring more than one action, while a next action is a specific physical step you can take. “Improve onboarding” is a project. “Send the revised onboarding checklist to Priya for review” is an action. A project without a next action can look active in a list while being impossible to move forward.

Set up the review before you begin

Choose a recurring block that is long enough to inspect your system rather than race through it. Many people start with 45 to 60 minutes and adjust once they see how much material their inboxes and project lists contain. The right duration depends on the number of commitments and tools you use; the important part is protecting enough uninterrupted time to finish the review.

Gather the places where work can hide. That may include email, a task manager, meeting notes, paper notes, chat messages, a calendar, and a physical in-tray. Keep your project list and any reference materials close by. If your team maintains shared work in a project board, open that too—but distinguish a genuine commitment from a status label or an idea someone has not agreed to own.

Do not turn the setup into a software migration. The review works with a notebook, a spreadsheet, or a task app, provided there is a reliable place to capture incoming items and a visible list of current projects. If information is scattered across several tools, write down where you will check it so no source is silently skipped.

• Time: Reserve a recurring review block and add a short buffer if your calendar is often interrupted.
• Inputs: Gather inboxes, notes, meeting records, messages, and any physical papers that contain commitments.
• Lists: Open your next-actions list, project list, waiting-for list, and calendar.
• Rule: Capture first; decide what each item means second. Do not let an uncategorized thought vanish because it seems small.

The GTD Weekly Review: a practical sequence

Allen’s Weekly Review is commonly organized around getting clear, getting current, and getting creative. The sequence below translates that idea into a repeatable working session. It is not a test of how many boxes you can check. If you discover a major dependency or an unrecorded commitment, pause long enough to represent it accurately.

1. Clear the loose material

Collect paper and digital notes, empty your physical in-tray, and scan the places where you receive requests. Process each item far enough to decide what it is. If it requires no action, delete it, file it as reference, or discard it. If it takes one brief action, do it only when that is appropriate to your workload and context. Otherwise, put a clear action on your list or place it in a calendar slot if it must happen at a specific time.

“Reply to Alex” is often too vague to be useful. “Send Alex the two budget options for the launch” says what completion looks like. If an item is an outcome that requires multiple steps, add it to the project list and define the next visible move rather than disguising the project as one oversized task.

2. Reconcile the calendar

Review the previous two weeks and the next two weeks. The past calendar can reveal follow-up actions you did not capture: a promised document, a decision someone was meant to send, or a meeting that created work. The upcoming calendar exposes fixed commitments and preparation needs. A presentation on Thursday, for example, may require a draft, a review, and a rehearsal—not just an hour blocked on Thursday morning.

Calendar entries are not interchangeable with tasks. Keep time-specific commitments on the calendar. Put flexible actions on an action list, then schedule them when you make the weekly plan. This prevents a calendar from becoming a crowded wish list that no longer tells you which commitments are truly fixed.

3. Inspect your next actions and waiting-for list

Read each action and ask whether it is still relevant, specific, and possible. Update completed work, remove obsolete tasks, and rewrite steps that no longer describe the next move. Then review anything you are waiting for. A useful waiting-for entry names the person or team, the expected item, and a follow-up date when one is appropriate: “Finance team — confirm revised forecast — follow up Tuesday.”

Do not treat a dependency as a personal action you can complete by wishing harder. If the project cannot progress until another person responds, record the dependency and decide whether a follow-up, an alternate route, or a conversation about timing is needed.

4. Review every active project

Read the project list from top to bottom. For each item, confirm that the outcome is still wanted, note its current state, and identify its next action. If the work is waiting on someone else, record who owns the response and when you will check again. If the project is paused, label it as paused rather than leaving it among active work with no explanation.

Projects that matter but cannot move this week still need a next action or a deliberate review date. That date is not a promise to finish the project. It is a commitment to reconsider it, update the plan, and prevent it from turning into a forgotten open loop.

5. Look ahead for missing work

Check upcoming deadlines, seasonal responsibilities, and likely opportunities. Ask what is not yet on your lists but will become important soon. This is the place for creative thinking: capture a possible improvement or an idea for a future project without automatically treating it as a current commitment. A trusted system separates “I may want to do this” from “I have agreed to do this now.”

Template 1: Weekly Review checklist

Copy this checklist into a note or task manager and use it as a prompt. The aim is a complete pass through your system, not a ceremonial checkmark beside every heading.

Keep the checklist stable for several weeks before editing it. If you add a step every time something goes wrong, the review can become so elaborate that you avoid doing it. Add a new check only when it closes a recurring gap—for example, if client promises frequently appear in meeting notes but never reach your task list.

Template 2: Project planning and handoff

Use one record for each project that requires more than a single action. The fields are deliberately plain: a teammate should be able to see the outcome, the next move, and the ownership without decoding a private shorthand.

Separating the project owner from the next-action owner is useful in team settings. A project lead may remain accountable for the outcome while a colleague owns a specific task. If one person holds both roles, write that down too; visible ownership is more useful than assuming everyone knows who is responsible.

Define “done” in terms another person could recognize. For a client proposal, that might mean the approved document has been sent to the client, not merely drafted. For an internal process change, it could mean the procedure is documented, reviewed, and in use by the team. A concrete finish line makes it easier to identify the actions required and to close the project honestly.

A worked example: the stalled onboarding project

Imagine a team has an active project called “Improve new-hire onboarding.” The label sounds clear until the weekly review asks what the outcome is and what happens next. A stronger project record might read: “New hires can complete their first-week setup using one approved checklist, with required account access and training steps confirmed before their first day.”

That outcome points to several actions. Someone must gather the current setup steps, someone else may need to confirm account permissions, and a manager may need to approve the final checklist. The next action should be the first step that can actually move the project: “Ask IT to confirm the account-access steps required before day one.” The entry should name the person responsible for sending that request and a date to review the response.

If IT has already been asked and no reply has arrived, do not keep the original request on the active next-actions list as though it were still under your control. Move it to waiting-for: “IT team — confirm account-access steps — follow up Wednesday.” The project remains active, but the immediate dependency is visible. If no response arrives by the review date, the owner can follow up or discuss an alternative with the project lead.

The final checklist itself is not automatically the only measure of progress. If the team needs a trial before adopting it, the project record can include a later next action: “Run the checklist with the next two starters and collect setup issues.” The project’s definition of done determines whether that trial is essential or a separate improvement. That distinction keeps a small deliverable from growing indefinitely while still making quality expectations explicit.

Turn reviewed commitments into a realistic weekly plan

Once the project list is current, plan the coming week against the calendar—not against an imaginary blank page. First mark fixed appointments, deadlines, and work that must happen at a particular time. Add preparation and follow-up that those commitments require. Then select a limited set of outcomes that can reasonably fit around them.

A useful plan distinguishes three things:

• Fixed commitments: meetings, delivery dates, or other work tied to a particular time.
• Priority outcomes: a small number of meaningful results to advance during the week.
• Available actions: the next steps you can choose from as time and circumstances allow.

For example, if Tuesday and Thursday are filled with client meetings, placing six hours of concentrated writing on those days is not a plan; it is a forecast error. Put the demanding work where the calendar and energy make it plausible, and keep some capacity for interruptions and unexpected requests. The exact amount of buffer varies by role, but a week with no room for routine work is already overcommitted.

Choose weekly priorities from active projects, not from whichever tasks are loudest in your inbox. A project can remain important even when its next action is small. Conversely, a task can feel urgent without being the most consequential commitment. Use deadlines, dependencies, strategic importance, and available capacity to make the trade-off visible.

Then translate selected outcomes into actions. “Make progress on the report” is difficult to schedule or assess. “Draft the findings section before Wednesday’s review” gives the week a workable move. If the action requires an uninterrupted block, reserve one; if it can be handled between meetings, leave it on the next-actions list instead of pretending it needs a calendar appointment.

A shared blockers-and-dependencies section for teams

For a team, add a compact shared section to the project record or weekly review. The purpose is not to create another status report. It is to make the handoffs that could stall work easy to see. Use a consistent format such as:

This format distinguishes a blocker from a general concern. “Waiting on Legal” is hard to act on. “Final language review is needed from Legal by Thursday to meet the Friday release decision” identifies the dependency and why the date matters. If the deadline changes, the project owner can update the plan instead of allowing an invisible delay to become a last-minute surprise.

Use the shared review to clarify handoffs, not to assign blame. A dependency may be late because priorities changed, the request was incomplete, or the person responsible never received a clear date. The practical question is what needs to happen now: follow up, narrow the request, renegotiate the date, or choose a different path.

Keep the system trustworthy between reviews

A weekly review cannot compensate for a system that nobody updates. Capture new commitments when they arise, clarify them before they disappear into a backlog, and revise project records when ownership or scope changes. You do not need to reopen every project every day, but a major change should not wait a full week to become visible.

Use review dates with judgment. A project waiting for a response needed tomorrow should be checked sooner than a long-term idea parked for a month. A review date should reflect when you need to make a decision or verify progress, not simply repeat the same date on every record.

When the review repeatedly runs long, look for the source of friction. Too many unprocessed inboxes may signal that capture points need consolidating. Project descriptions may be vague. A long waiting-for list may point to unclear agreements about response times. Fix the recurring cause rather than rushing through the checklist faster.

Common breakdowns—and how to repair them

The project list contains aspirations, not commitments

Move someday possibilities into a separate list. Keeping every interesting idea among active projects makes the active list less credible. An idea can be valuable without being a promise to act this week.

Next actions are still written as outcomes

Replace “finish the launch” with the next observable step: “Review the launch checklist with the product lead.” If you do not know the next step, record a thinking action such as “Outline the decisions needed to define the launch scope.” Planning itself can be an action when it names a specific result.

Delegated work disappears from view

Move delegated items to waiting-for and record the person, expected deliverable, and a suitable follow-up date. Delegation does not mean forgetting; it means tracking the handoff without keeping the task falsely marked as work you can complete yourself.

The weekly plan is too full by Monday

Return to the calendar and compare planned work with actual available time. Defer, renegotiate, or reduce scope before the week begins. A smaller plan that preserves critical outcomes is more useful than a packed list that turns every missed task into a personal failure.

A simple measure of whether the review is working

Do not judge the system by whether every planned action gets completed. Projects change, urgent work arrives, and some forecasts will be wrong. A better test is whether you can answer three questions without reconstructing your week from memory: What outcomes are active? What is the next action on each? Who owns it, and when will the project be reviewed again?

After four weekly reviews, look for patterns. Are projects regularly missing owners? Are the same dependencies aging without follow-up? Are calendar commitments consuming more time than expected? Those observations can inform a change to the workflow, a conversation with your team, or a more realistic estimate of capacity.

The payoff is not a perfectly controlled week. It is fewer hidden commitments and clearer decisions about what to do next. GTD’s Weekly Review provides the reset; the project template gives that reset a practical destination. When every active project has a defined next action, an owner, and a review date, planning becomes less about guessing what you forgot and more about choosing what deserves your attention now.