How to keep a project plan up to date: a 15-minute routine

Every project plan is accurate on the day it is made. A week later, a task finished early, another one slipped, and a new request appeared in a chat message. Nobody updated the chart, so it quietly turns into fiction. If you want to keep a project plan up to date, you do not need more discipline. You need a small, repeatable routine that takes minutes, not hours.

This article gives you a 15-minute weekly routine, a worked example and a few rules that stop the plan from drifting again.

Why plans go stale

Plans rarely go stale because people are lazy. They go stale because updating them feels expensive. A few common causes:

• The plan is too detailed. If every half-day task is tracked, updating it becomes a chore, so it gets skipped. The fix is in the structure, not in willpower.
• There is no fixed moment to update. "Whenever something changes" really means "never".
• Changes live somewhere else. Decisions are made in meetings and chats, and the plan is the last place to hear about them.
• Nobody owns it. When everyone can edit and nobody is responsible, everyone assumes someone else did it.

A stale plan is worse than no plan. People make decisions from it, such as when to book the next person or what to promise a client, and those decisions are wrong from the start.

Before you start: make the plan cheap to maintain

A routine only works if the plan is built to be updated. Three habits help.

Keep tasks at a useful size

Tasks that last one to five working days are easy to update because they are either done, in progress or not started. If you have many tasks shorter than a day, group them into one. If a task lasts six weeks, split it. Our guide on estimating task duration covers how to size tasks, and subtasks and task groups shows how to keep the structure readable.

Use dependencies instead of fixed dates

When tasks are linked, moving one task moves the ones that follow it. That is what makes a delay a one-edit change instead of twenty. If you have not linked your tasks yet, start with task dependencies in a Gantt chart.

Name one owner

One person is responsible for the plan. Others can edit parts of it, but one person runs the weekly update. If you share the plan with a team or client, decide who gets editor and who gets viewer access so changes do not collide.

The 15-minute weekly routine

Pick a fixed slot, for example Friday at 4 p.m. or Monday morning, and put it in your calendar. The routine has five steps.

1. Record progress (3 minutes)

Open the plan and go through every task that was supposed to be active this week. For each one, set the progress to what is true now, not what you hoped. A task you thought was done on Wednesday but is really at 80% should say 80%.

Mark finished tasks as complete and add the real status of anything that started late. Do not touch future tasks yet.

2. Check the dates against today (3 minutes)

Look at where today falls on the timeline. Anything that should be finished but is not, anything that should have started but has not: these are your exceptions. List them in your head or on a sticky note. Most weeks there are only two or three.

3. Move what slipped and let dependencies do the rest (4 minutes)

For each exception, decide the honest new date and move the task. If the tasks after it are linked, they follow automatically, and you can see the effect on the final date straight away. If a milestone moved, that is the important result of the week: write it down.

Resist the urge to hide a slip by squeezing later tasks without a reason. Compressing the schedule is a decision, not a default. How to handle project delays explains the real recovery options.

4. Add what is new and remove what is dead (3 minutes)

Scope changes are the second reason plans drift. Add tasks that appeared since last week, with an estimate and a dependency. Delete or rename tasks that no longer make sense. If a change is large, put a note on the task so the reason is not lost.

5. Tell people what changed (2 minutes)

An updated plan nobody reads is half the job. Send a two-line summary: what moved, what the new key date is, and what you need from them. If the plan is shared with viewer access, they will see the chart itself, so your message only needs to point at the change.

A worked example

Imagine a six-week website relaunch with the phases Discovery, Design, Build and Launch. On Friday you run the routine.

1. Progress. Discovery is complete. Design is at 70%. Build has not started.
2. Exceptions. Design was due to finish today and is not. It needs three more working days because the client sent late feedback.
3. Move. You extend Design by three days. Because Build depends on Design and Launch depends on Build, both shift. The launch milestone now sits three working days later. That is the headline.
4. New and dead. The client asked for a newsletter signup form. You add a two-day task under Build and link it to the launch milestone. A "Logo exploration" task that was dropped is removed.
5. Communicate. You write: "Design feedback arrived late, so launch moves from 27 Nov to 2 Dec. We also added a signup form. Please confirm the copy by Wednesday."

Total time: about fifteen minutes. More importantly, the plan now matches reality, and nobody is surprised.

Rules that stop drift

• Update on a schedule, not on a feeling. The weekly slot beats good intentions.
• Record reality first, then plan. Do not change future dates before you have updated progress.
• One source of truth. If a decision is made in chat or in a meeting, the plan is updated within the week, and people know that is the place to check.
• Keep a short change log in your head or notes. "Launch moved three days because of X" is the sentence you will need when someone asks.
• Do not chase precision. A plan that is right within a day or two is more useful than one that is perfect and a month old.

Let an agent do the chores

The routine above is mostly mechanical: set progress, shift dates, add a task, summarize. These are good jobs to delegate. If you connect an AI assistant such as Claude, Cursor or VS Code to your plan through MCP, you can describe the week in plain language and let it apply the edits, then read the result yourself.

For example: "In my Website relaunch project, mark Design as 70% done, push it back three days with everything that depends on it, and tell me the new launch date." The assistant reads the dependencies, moves the tasks and reports the result. You still decide what the honest new date is; the agent saves you the clicking. The guide to managing a project plan with Claude has more example prompts, and the connector docs explain how to set it up.

Try it this week

Pick a slot, open your plan and run the five steps once. If you do not have a plan yet, you can build one for free in ProGantt Flow and link your tasks so that the next update is a two-minute job instead of a rewrite. The goal is not a perfect chart. It is a plan you can trust on any given Monday.