How to plan a project on your calendar (deadlines, phases, the lot)

Project management tools (Linear, Asana, Notion) are good at what needs to happen. They're terrible at when. A Gantt chart shows you that "Discovery" runs three weeks and "Build" runs five — but it doesn't know your calendar is already 60% meetings. The project plan looks fine on the chart and quietly slips by 40%.

This is how to plan a project on the calendar where it actually has to happen.

The four-step process

1. Define the phases honestly

Most projects have 3–4 phases. Common shapes:

Software project: Discovery → Build → Launch → Stabilize
Writing project: Research → Outline → Draft → Edit
Launch: Plan → Build → Pre-launch → Launch week → Postmortem

For each phase, write down:

What "done" means. Discovery is done when there's a doc. Build is done when the feature is in production. Specific verbs and artifacts; no fuzz.
Estimated hours. Not days. Hours. "Discovery: 20 hours of focused work, spread over ~2 weeks."
Dependencies. Build can't start before discovery ships.

Hours estimates beat days estimates because hours fit into your real available calendar. Days assume 8 productive hours per day, which doesn't exist.

2. Estimate your weekly capacity

Your real deep-work capacity per week is much lower than 40 hours. For most senior knowledge workers:

5–10 hours/week if you're heavily meeting-loaded (managers, team leads)
10–20 hours/week if you're mostly an IC with light meeting load
20–25 hours/week is the realistic ceiling for almost anyone, even with a defended calendar

Be honest. If you've never sustained 20 hours of focused work in a week, don't plan for 25.

3. Place the phases on the calendar

For each phase, divide estimated hours by realistic weekly capacity:

Discovery (20 hours) ÷ 8 hours/week of deep work = ~2.5 weeks

Now place that on the calendar with a buffer. Real projects always slip. Multiply phase duration by 1.3–1.5 for buffer:

Discovery: ~3.5 calendar weeks (with buffer)

Repeat for each phase. Add them up. That's the project deadline. If the math says 16 weeks and you promised the customer 8 — you have a real problem, but at least now you know.

4. Schedule the deep-work blocks weekly, not all upfront

Don't try to plan every block of work for the next 16 weeks. The plan won't survive contact with reality. Instead:

Set the phase on the calendar with start/end dates
Each week, schedule 4–6 deep-work blocks pointing at that phase's work
Let the block placement reflow inside the week as meetings move
Review weekly: are you on pace for the phase? If behind, decide whether to extend the deadline or cut scope

This is roughly the project model TimeFlow ships: a project has phases with deadlines; tasks roll up to phases; the auto-scheduler places task blocks each week and warns when a phase is at risk.

The slip-buffer principle

Every estimate is wrong. The question is by how much.

A useful rule of thumb:

If you think it'll take X hours, plan for 1.3X. If the project is novel (you've never done this exact thing), plan for 1.7X.

This isn't padding the estimate so you look good — it's accepting that estimates have variance, and the variance compounds across phases.

If your project has 4 phases, and each phase has a 30% chance of slipping by 50%, the project ships on time roughly 24% of the time. That's why software ships late.

What to do when a phase slips

It will. The question is: when do you notice, and what do you do?

Three rules:

Notice early. Weekly review of "am I on pace for this phase?" beats noticing in week 8 that you're already a month behind.
Don't borrow from the next phase. "I'll catch up in Build" is a lie. Build is its own estimate; it can't absorb Discovery's slip without slipping itself.
Cut scope or extend the deadline. Those are the only two real options. Pick consciously, not by drift.

This is the part where the calendar earns its keep. A project tool tells you you're behind. A calendar shows you the time you don't have to make it up. The decision is forced by the calendar reality, not deferred.

A worked example

Project: ship a new product feature, 8 calendar weeks committed.

Phases:

Discovery: 16 hours of writing/spec work
Build: 50 hours of coding
Launch: 10 hours of docs/marketing/release

Total: 76 hours of deep work.

My realistic deep-work capacity: 12 hours/week.

76 ÷ 12 = 6.3 weeks of deep work, plus 30% buffer = 8.2 weeks

Tight but doable, if I actually get 12 hours of deep work each week. Pre-place 4 deep-work anchors per week pointing at the phase. Review weekly. If by week 3 I've only logged 8 hours/week, I cut scope (drop a sub-feature) before week 4 instead of slipping the whole launch.

Try it

TimeFlow ships projects with phases and deadlines, auto-schedules tasks and habits into your real available time, and warns when a phase is at risk. Connect Google Calendar in 30 seconds and have your first project planned by lunch. Free during beta.