Free Project Plan Template for Notion (Download + Guide)

What should a project plan template for Notion contain?

A complete template has four databases and one dashboard page. Projects hold the container, Tasks hold the work, Milestones hold the commitments, and Risks hold the things that could break either. The dashboard page embeds filtered views so each audience sees one screen instead of a database.

Two rules make the difference between a template and a task list. First, every task belongs to exactly one project through a relation whose reverse side is switched on, so the project page shows its own work without a filter that someone can forget to set. Second, every milestone has a baseline date that is never edited after kickoff. The baseline is the only thing that makes “we are late” a fact rather than an opinion.

Why four databases and not one?

One database is easier to build and worse to run. If milestones live as tasks with a “type” property, they inherit task fields they do not need and lose the fields they do: an external commitment date, the audience who was promised it, and the baseline it is measured against. Separating them also lets you share the milestone view with a client without exposing the task backlog.

The cost is complexity. Four databases mean three relations to maintain and a schema that new team members must learn. For a two-week project with eight tasks, use one database and skip this guide.

How do you set up the Projects database?

Create the Projects database as a full-page database, not an inline one. A full-page database gives each project its own page, and that page becomes the project home where the plan, the decisions, and the meeting notes live together.

1. Add properties: Project (title), Owner (person), Status (select: Planning, Active, At risk, On hold, Done), Start (date), End (date), Baseline end (date).
2. Add a relation property named Tasks pointing at the Tasks database, with “Show on Tasks” enabled and the reverse property named Project.
3. Add a relation property named Milestones pointing at the Milestones database, with the reverse property named Project and no page limit.
4. Add a rollup named Tasks total over the Tasks relation, property “Task”, calculation Count all.
5. Add a second rollup named Tasks done over the same relation, property “Done flag”, calculation Sum.
6. Add a formula named Percent complete: `if(prop(“Tasks total”) > 0, prop(“Tasks done”) / prop(“Tasks total”), 0)`, formatted as a percentage.
7. Add a formula named Days remaining: `dateBetween(prop(“End”), now(), “days”)`.

Two details matter more than they look. The End date should be the committed delivery date, while Baseline end is the date promised at kickoff; the gap between them is your slippage, and it should only ever grow with a written reason. And the Status select should have exactly one red state, “At risk”, so that a red project is unambiguous in a portfolio view.

Notion’s formula editor shows a live preview per row and flags type mismatches as you type. If a formula returns a red error, the usual causes are a rollup returning a number where the formula expects text, or a date property that is empty on some rows. Notion’s formula engine also handles missing values differently from a spreadsheet: an empty date is not zero, and `dateBetween` will error rather than return a default, so guard the formula or keep the date fields mandatory.

How do relations and rollups calculate plan health?

Relations connect rows; rollups aggregate the connected rows. Applied to a project plan, that means the project’s percent complete is a calculation over its tasks, and a milestone’s slippage is a calculation over two dates. Nobody types a status that the data can compute.

Notion supports two relation directions. A one-way relation lets the project see its tasks but not the reverse; a two-way relation, enabled with “Show on Tasks”, keeps both sides in sync. Use two-way for Tasks and Projects, because the task page needs a link back to its project for anyone working from a filtered task view.

Rollups are more limited than people expect. Notion offers count, sum, average, median, min, max, range, percent empty, and unique value calculations, plus date aggregations such as earliest, latest, and date range. What it does not offer is a filtered rollup: you cannot ask for “count of tasks where status is Done”. The workaround is a helper formula on the child database.

The helper column looks inelegant and is the standard Notion pattern for weighted progress. It also gives you a second, more honest metric: effort-weighted completion, which ignores the ten one-hour tasks finished on day one and reflects the four-day migration that has not started.

Worked example: a fourteen-week website replatform

A B2B company is replatforming its marketing site over fourteen weeks with a team of six. The plan has 68 tasks, 5 milestones, and 9 risks. At the end of week 8, the numbers look like this.

The gap between 60.3% and 57.1% is the story. The team has closed many small tasks and few large ones, so the task count flatters progress by 3.2 points. Any forecast built on the count alone will be optimistic, which is why the dashboard should show both numbers side by side.

Now the schedule. Milestone 3, content migration, was due in week 7 and landed in week 8, six working days late. The remaining float before milestone 4 is four working days. Slippage is `dateBetween(prop(“Actual”), prop(“Baseline due”), “days”)`, which returns 6, against a float of 4.

That single comparison is the most valuable cell in the plan. It says the next milestone is at risk before anyone has missed it, and it gives the project lead a specific question instead of a general worry: can the four remaining days of float absorb the six days of delay, or does the launch date move?

Suppose the team adds two contractors for the final four weeks at 30 hours each per week. Capacity rises by 2 × 30 × 4 = 240 hours against 134 hours of remaining estimated work, which is enough on paper. But the critical path runs through design approval, not through production hours, so the added capacity does not move the date. This is exactly the reasoning a plan exists to support, and it requires dates and dependencies, not a task list.

How do you plan capacity inside Notion?

Add a Workload view on the Tasks database grouped by Assignee, with two rollups or a sum calculation under the Estimate column. Then compare committed hours with available hours per person for the same period.

A six-person team with 32 available hours per person per week has 192 hours of capacity in a normal week. In the replatform example, the final four weeks carry 134 hours of remaining work plus 46 hours of review and QA, or 180 hours. That is 94% loaded before any unplanned work, which is too tight: at 85% utilisation there is almost no room for the interruptions that always arrive.

The designer at 103% is the finding. Notion will not rebalance the work for you, but a grouped view makes the overload visible in one screen, and the conversation shifts from “are we late?” to “which of these four design tasks moves to the next sprint or to a contractor?” That is a better conversation, and it happens in week one rather than week twelve.

How do you run the weekly review?

Twenty-five minutes, one screen, three questions. Open the At risk view, then the My week view, then close the database.

1. Which milestone moved, and by how many days against baseline?
2. Which task is blocking someone else, and who unblocks it this week?
3. Which risk changed likelihood or impact since last week?

The plan should change as a result of the meeting, or the meeting was theatre. That means someone edits a date, an owner, or a status before the call ends, and the edit is what the next week’s review measures against. Notion’s page history records who changed what, which removes the “I thought you moved that” argument without requiring a separate audit log.

What formulas keep the plan honest?

Four formulas cover most of what a project plan needs. They are short enough to paste in and specific enough to catch the failures that spreadsheets hide.

• Percent complete: `if(prop(“Tasks total”) > 0, prop(“Tasks done”) / prop(“Tasks total”), 0)`.
• Days remaining: `dateBetween(prop(“End”), now(), “days”)`. Negative values mean the date has passed, which is the signal to change the status.
• Overdue task: `if(and(prop(“Due”) < now(), prop("Status") != "Done"), "Overdue", "")`. Notion's own documentation uses this pattern, with the optional `style()` function to render it in bold red.
• Slippage in days: `dateBetween(prop(“Actual date”), prop(“Baseline due”), “days”)`, which returns a positive number for late milestones.

Two more are useful once the plan is running. A RAG status formula that returns green, amber, or red from slippage and percent complete keeps the portfolio view readable without a manual update. A days since last update formula based on a Last edited time property catches tasks that have been “in progress” for three weeks without a single edit.

Keep the formula count low. Every formula is a small piece of logic that a new team member has to trust without reading, and a plan with twenty formulas is a plan nobody can audit.

Which views does each role need?

Notion’s strength is that one database can serve five audiences through five views. Build these and stop.

The timeline view needs both a start and an end date on each task, and it needs the dates to be real. A common failure is to set Start equal to Due for every task so the bars appear; that produces a chart with no duration and no overlap, and the dependency logic becomes meaningless. Notion’s timeline dependencies are available on the higher-tier plans, so check your workspace plan before promising a dependency map to a stakeholder.

What are the trade-offs of planning in Notion?

Notion is a strong choice for plans that are mostly information work with a small team, and a weak choice for plans that need resource leveling, cost tracking, or automated notifications.

The pattern to notice: Notion gives you most of a project management tool for a fraction of the setup cost, and the missing part is exactly the part that automates schedule logic. That trade is fine for a marketing launch and painful for a construction project.

When should you move the plan out of Notion?

Move when the plan needs calculations Notion cannot do: earned value, resource leveling, cost baselines, or automatic escalation when a milestone slips. Move earlier if the team spends more time maintaining the plan than acting on it.

That is the gap Doitify is built to close. It converts a goal into a project with multi-level tasks, sub-tasks, checklists and schedules, then tracks execution with Kanban boards, Gantt charts, WBS dependencies, milestones, workload views, risks and constraints, and work and performance reports. The difference from a doc-based plan is that the schedule logic and the reporting are native rather than assembled from formulas, and the AI Coach can draft the plan structure from a stated goal.

*Transparency note: Doitify is our product. Notion is a separate company and we have no commercial relationship with it.*

What mistakes break a Notion project plan?

Six failures repeat across almost every workspace I have reviewed.

1. Typing percent complete. It drifts from reality within two weeks. Roll it up from tasks.
2. No baseline dates. Without a baseline, slippage is invisible and every delay becomes a debate about memory.
3. Milestones as tasks. They inherit task fields and lose the external commitment date that makes them useful.
4. A due date but no start date. The timeline view cannot draw a bar, so the plan degrades into a calendar.
5. Every task assigned to one person. A single owner per task is correct; a single owner for all 68 tasks means nobody owns anything.
6. No archive rule. Completed projects left in the same database slow every view and hide the active work.

A seventh is structural: building the template inside a project page instead of as a standalone database. Templates multiply; page-level structures do not.

Conclusion

A project plan template for Notion earns its keep when progress is calculated, dates are baselined, and each audience has one view. Four databases, two rollups, four formulas, and a timeline are enough to run a fourteen-week project without a single manual status update.

Start with Projects and Tasks, add Milestones the first time you promise a date to someone outside the team, and add Risks when the first one bites. The template will grow into the shape of your projects, which is better than starting with a schema nobody understands.

If this post on project plan template for Notion was helpful, you might also enjoy Gantt Chart vs Kanban Board: Which Is Right for Your Team? and Free Weekly Project Report Template (2026).