“Free Project Plan Template for Google Sheets (Download + Guide)”

What columns does a project plan template in Google Sheets actually need?

Fourteen columns, in four groups. The grouping matters because it tells you which columns are edited by humans and which are computed. Mixing the two is how sheets rot: someone overwrites a formula with a hard-coded guess and nobody notices for a month.

Two deliberate choices. First, duration in working days rather than an end-date column, because the end date is what changes when the plan slips and a computed cell should never be typed over. Second, predecessor as a Task ID, not a task name, so renaming a task does not silently break the logic.

If you want a leaner version, drop columns L and M and keep the twelve that govern schedule and ownership. Budget columns earn their place only when someone outside the team reads the sheet.

How do you build the template in Google Sheets?

Build it once, on a tab called `Plan`, then never edit that tab again. Seven steps.

1. Create the header row in row 1 with the fourteen names above, bold, frozen with *View → Freeze → 1 row*.
2. Add two helper tabs: `Lists` for the dropdown vocabularies (owners, workstreams, statuses, priorities) and `Summary` for the aggregations. Keep `Plan` for data only.
3. Create named ranges so formulas stay readable: select A2:A400 and define `TaskID`, then `Owner`, `Status`, `Workstream`, `Start`, `Duration`, `Finish`, `Planned`, `Actual`.
4. Apply data validation to D, C, I, and J: *Data → Data validation → Dropdown (from a range)* pointing at `Lists`. Typed variants (“In Progress”, “in progress “, “In-progress”) are the single most common cause of a broken `COUNTIFS`.
5. Enter the finish formula in G2 and fill down: `=IF(OR(E2=””,F2=””),””,WORKDAY(E2,F2-1))`. The `-1` matters because `WORKDAY` counts the start day itself.
6. Add conditional formatting on G: red when `=AND(G2<>“”,G2“Done”)`, amber when the task is due within five working days, grey when status is Done.
7. Protect the computed columns: *Data → Protect sheets and ranges* on G and any summary formulas, with a warning rather than a hard lock so you can still edit deliberately.

Then populate three or four real rows before inviting anyone. A template with fake rows (“Task 1”, “Task 2”) teaches people to ignore the sheet; a template with the actual first milestone teaches them to read it.

Which formulas make the plan work?

Twelve formulas cover 95% of what a spreadsheet plan needs to do. Each is copy-pasteable and written for row 2 of the layout above.

The `FILTER` formula is the one people underuse. Paste it into a `Summary` tab cell and it spills every blocked task into a list that updates itself, which is the closest a spreadsheet gets to a live dashboard.

One warning about `TODAY()`: it recalculates on every edit and every time the file opens, so a sheet left open overnight shows yesterday’s date. For status reporting, add a `Report date` cell and reference it instead of `TODAY()` so the numbers on a shared screenshot match what the reader sees.

What does a worked example look like?

Take a six-week product launch, Monday 12 January 2026 start, and five tasks.

Check the third row by hand. Start Thursday 15 January, four working days counting the start day: Thursday, Friday, Monday, Tuesday, so the finish is Tuesday 20 January. The formula `WORKDAY(E4,F4-1)` returns 2026-01-20. Now pretend the venue slips by three working days, to 21 January. Every downstream row that uses the predecessor’s finish as its start moves too, and the rehearsal date updates: that is the moment the spreadsheet earns its keep.

The second check is financial. Planned cost across the five tasks is 2,400 + 600 + 1,800 + 900 + 300 = 6,000. If actuals come in at 6,540, variance is +540, or 9.0% over plan. The `IFERROR((M-L)/L,””)` formula returns 0.09, and formatting the column as a percentage shows 9%. Nine percent over on a 6,000 budget is a 540 conversation, not a crisis, and having the number ready is what keeps it that way.

The third check is capacity. Six people at 30 available hours a week gives 180 hours of capacity. If open tasks total 214 hours of effort, the plan is over-allocated by 34 hours, about 19%. Either the timeline extends by a fifth or scope comes out. A sheet that shows this before week three is doing real project management.

How do you handle dependencies in a spreadsheet?

You approximate them, honestly. Sheets has no scheduling engine, so the dependency column is documentation plus one formula.

The workable pattern is a predecessor column plus a validation rule: `=IF(H2=””,””,IF(COUNTIF($A$2:$A$400,H2)=0,”Missing ID”,”OK”))`. That catches the common error of pointing at a task that was deleted. A second rule catches a task that starts before its predecessor finishes: `=IF(H2=””,””,IF(E2

What you cannot do is automatic rescheduling of a chain. If task 3 moves, tasks 4 through 9 keep their old dates unless someone edits them. Teams compensate with a “cascade” habit: every Monday, sort by start date, walk the chain, adjust. That is fifteen minutes for a small project and the first sign that you have outgrown the tool.

A practical middle ground is to model only the true gating dependencies, maybe eight to twelve of them, and leave the rest as parallel work with soft dates. Most project plans that fail do so because of two or three real gates, not because of a hundred phantom ones.

How do you stop a shared sheet from turning into chaos?

Six controls, all built in, all worth the ten minutes.

One canonical tab. The `Plan` tab is the only place rows live. Reporting tabs read from it with `QUERY` or `FILTER`. The moment someone starts a second data tab, you have two truths.

Filter views, not copies. When a stakeholder wants “just the design tasks”, give them a filter view (*Data → Filter views → Create new*). It is personal, it does not disturb anyone else’s sort, and it cannot be emailed around as a competing file.

Comment discipline. Use cell comments for discussion and the note column for durable context. Comments that live in chat are lost; notes that live in chat are lost too.

A weekly review slot. Thirty minutes, same time, screen shared. Read the blocked list, the late flag column, and the cost variance. Without this, the sheet becomes a museum of intentions.

Version rule. *File → Version history* is your audit log, so stop naming files `v7_final`. If a download is required for an external party, export a PDF snapshot and label it with the report date.

One owner per row. Enforced by data validation. Shared ownership is how tasks sit untouched for three weeks while everyone assumes someone else has it.

What are the trade-offs of running a project plan in Sheets?

The spreadsheet route is genuinely good at four things and genuinely bad at four others, and knowing which is which saves a pointless migration.

The honest trade-off line: a spreadsheet plan costs nothing to start and about two to four hours a month to maintain at ten people. A paid tool costs money and roughly one to two hours a month of admin. The crossover point is not about team size; it is about how many people need a view they are not allowed to edit.

When should you move off the spreadsheet?

Five triggers, and any two of them together is enough.

1. More than about 60 active rows. Beyond that, sorting and filtering stop being a reading aid and start being a hunt.
2. A dependency chain that changes weekly. Manual cascading is the clearest signal the tool is wrong.
3. Three or more stakeholders who need read-only views. Filter views do not survive contact with executives and clients.
4. Notifications become load-bearing. If a missed reminder costs money, put the reminder in a system that sends it.
5. Two projects sharing people. Cross-project workload is where a spreadsheet quietly lies, because each file thinks the person is free.

There is also a softer trigger: when the person maintaining the sheet becomes a single point of failure. If the plan only makes sense to its author, you do not have a plan, you have a private notebook with shared edit rights.

How does Doitify compare with a Google Sheets template?

Doitify is our product, so read this as disclosure, not review. The relevant difference is architectural. In Sheets, the finish date, the status flag, the roll-up, and the report all live in different formulas that someone has to maintain and re-explain each quarter. In Doitify, tasks carry owner, dates, dependency, checklist, and effort as fields, and the Gantt chart, Kanban board, workload view, and project report read from those fields directly, so moving one task updates the timeline instead of the timeline being retyped.

The AI layer is a smaller point but a real one: Doitify Copilot and AI Coach turn a stated objective into tasks, sub-tasks, and a dated plan, which is the part of building a spreadsheet template that most teams get wrong first.

Where the spreadsheet still wins: a one-off plan for a three-week project, a budget model with heavy custom arithmetic, or an environment where finance controls the tool budget and nothing new gets approved. In those cases, build the fourteen-column template above and revisit it when a trigger fires.

Conclusion

A free project plan in Google Sheets is not a lesser version of a project management tool. It is a different instrument: transparent, flexible, free, and honest about what it does not know. The template that survives is the boring one, fourteen columns and a handful of formulas, with the computed cells protected and a fixed weekly review to read them.

Build the columns, add the five formulas that matter, run the six-week example above against your own dates to prove the arithmetic, then set a review date. When two of the five triggers fire, migrate, and migrate the *structure* rather than the rows. A clean fourteen-column plan imports into almost any tool. A sheet with forty ad-hoc tabs does not.

If this post on Google Sheets project plan template was helpful, you might also enjoy What Is the Critical Path in Project Management? and Burndown vs Burnup Chart: Key Differences, Pros and Cons, and When to Use Each.