The field guide
How to plan a project, honestly.
No Gantt charts you don't need, no methodology you'll never use. Just the five moves that turn a goal into a plan that survives contact with a real week — and the vocabulary that makes each one obvious.
Written by the studio behind ganttchart.ai · a 6-minute read
Planning a project sounds like a discipline you need a certification for. It isn't. Strip away the software and the acronyms and every project plan is answering the same four questions in order: what does done look like, what work gets us there, in what order, and by when. Answer those honestly and you have a plan. Answer them by wishful thinking and you have a countdown.
What follows is the whole job in five movements — small enough to do on a napkin, sturdy enough to run a launch. Each links out to the plain-English glossary for the one word that carries the weight, so nothing here needs a footnote.
Start at the end
Name the finish line
A plan is a route, and a route needs a destination. Before a single task, write the one sentence that says what "done" looks like.
Most plans fail here, quietly, before they start: nobody wrote down what finishing means, so every later argument is really about that. Skip the mission statement. Name a concrete deliverable and the date it is due — "the new site is live by November 12" — and, if it helps, a milestone or two along the way. Everything downstream is just working backwards from that sentence.
The work, not the wishes
List the work, not the wishes
Break the finish line into the actual pieces of work it takes to get there — the verbs, not the vibes.
This is the work breakdown: keep splitting the goal until each piece is a real task someone could pick up on a Monday and finish by Friday. Too coarse ("build the site") and the plan hides the work; too fine ("name the CSS variables") and you are writing a diary, not a plan. Aim for tasks a day or a few days long. If you can imagine doing it in one sitting, it is probably too small; if you cannot imagine finishing it this week, split it.
Order over optimism
Put the tasks in order
Some work has to wait on other work. Draw those arrows now, on paper, before the calendar lies to you about it.
A dependency is just "this can't start until that finishes" — the paint waits on the wall, the launch waits on the copy. Most are plain finish-to-start links. Marking them is the difference between a plan and a wish list: it turns a pile of tasks into a shape, and the shape is what tells you the truth about how long this really takes. Do this by hand first. You will find dependencies you did not know you had.
Honesty, then slack
Estimate honestly, then leave a buffer
Put a duration on each task, trace the longest chain, and protect it — because that chain, not the calendar, decides your end date.
Give every task an honest duration — the time it really takes, not the time you wish it took. Better still, estimate it as a range rather than a single number, which is only ever the optimistic case in disguise. Then find the critical path: the longest chain of dependent tasks from start to finish. That chain sets the earliest you can possibly be done. Everything off it has slack and can slip a little for free; everything on it cannot. So put your one honest buffer at the end of that chain, not sprinkled across every task where it just evaporates.
See it before it slips
Draw it so you can watch it slip
A plan you cannot see is a plan you cannot defend. Lay the tasks on a timeline so a slip is visible the day it happens, not the week it is due.
This is what a Gantt chart is for: tasks down the side, time across the top, one bar per task showing when it runs. Laid out on a timeline, the dependencies become arrows and the critical path becomes the longest unbroken run of them. Freeze a copy the day everyone agrees — a baseline — and every later status update becomes a checkable question instead of a matter of vibes: lay today over the agreed version and the drift is right there, bar by bar.
All five, in one picture
What the finished plan looks like
Here is a six-week website launch after all five movements: real tasks, in dependency order, with the critical path highlighted and a launch milestone at the end. This is the whole job, drawn once.
Want five more like this — a product launch, an app MVP, a move, a meetup? See the worked examples →
The failure modes
Four ways a plan dies
Nearly every plan that falls apart falls apart the same handful of ways. Knowing the shapes is half of avoiding them.
The plan with no buffer
Every day between now and the deadline is spoken for. That is not a plan that survives a bad week — it is a bet that no week will be bad.
The task that is really a project
"Build the app" is not a task; it is the whole plan wearing one row. If a bar would run for a month, it is hiding a plan of its own inside it.
The plan nobody updates
A plan is a living document or it is decoration. If it is not touched between kickoff and the post-mortem, it was never planning — it was theater.
The false parallel
Two tasks drawn side by side that both wait on the same person are not parallel. They are a queue, and the plan should say so.
One more decision
Do you even need a Gantt chart?
Not every plan wants a timeline. If the work has no real deadlines and no dependencies, a to-do list is honest and a kanban board is plenty — a Gantt chart would just be scaffolding around nothing. The timeline earns its keep the moment dates and dependencies start to matter. We wrote a whole piece on how to choose.
Common questions
Planning, briefly
What are the basic steps to plan a project?
Name the finish line (a concrete deliverable and its due date), break it into real tasks, put those tasks in order by their dependencies, estimate each honestly and find the critical path, then lay the whole thing on a timeline so you can watch it slip. Those five steps work for a website launch or a kitchen remodel — the scale changes, the shape does not.
How detailed should a project plan be?
Detailed enough that each task is something one person could start and finish in a day or a few days, and no more. Too coarse and the plan hides the work; too fine and you are keeping a diary. A plan with the right number of tasks is one whose critical path you can trace with a finger.
Do I need project management software to plan a project?
No. You can plan a project on paper, and for small projects that is often the right first move. Software earns its place once the plan has enough moving parts that you need it to reflow dates when something slips — that is the moment a Gantt chart beats a static list.
What's the difference between a project plan and a to-do list?
A to-do list is tasks with no order and no dates. A project plan adds the two things that make it a plan: which tasks wait on which, and when each one runs. A to-do list tells you what is left; a plan tells you whether you will finish on time.
What is the fastest way to draw a project plan?
Describe the project in a sentence and let ganttchart.ai draw the first version — tasks, durations, dependencies, and milestones included. You stay the editor; the AI just saves you the blank page. It is far faster than wrestling a spreadsheet into a Gantt chart, and the chart reflows when a date changes.
Every planning term above is defined, jargon-free, in the plain-English glossary.
Skip to the drawn version
You've done the thinking. Describe the project in a sentence and let ganttchart.ai draw the first plan — tasks, durations, dependencies, and milestones included. You stay the editor.