How to plan a project

Most projects don't fail at execution. They fail at the start, in the gap between "we should do this" and "here is exactly what we're doing, in what order, by when". A plan is what fills that gap. It doesn't have to be heavy — a one-person project deserves a lighter touch than a building site — but the thinking is the same at every scale: decide what done looks like, work out the pieces, put them in order, and commit to a schedule you can hold yourself to.

This guide walks through nine stages, in order, using one running example: launching a small online course. It's deliberately modest — one person, a few weeks, a real deadline — so you can see every step without drowning in detail. Scale the same moves up and they still hold.

1. Define the goal and what success looks like

Start with a single sentence that says what you're delivering and why. Not a wish — a deliverable. "Launch a four-module course on spreadsheet basics, with paid enrolment open, by the end of September." Then add success criteria you could actually check: the course is live on the platform, four modules are recorded and edited, the sales page converts at all, and at least ten people have enrolled in the first week.

The point of writing this down is that it settles arguments before they happen. When someone later asks "should we add a bonus module?", you hold it against the goal and the deadline instead of saying yes on instinct. A goal you can measure is also a goal you can declare finished — which is harder than it sounds, and the reason so many projects drift.

2. Set the scope — what's in, and what's out

Scope is the fence around the work. The trick that almost no one does and everyone should: write an explicit out-of-scope list next to the in-scope one. For the course, in might be four recorded modules, a sales page, and an email autoresponder. Out: a mobile app, live cohort sessions, translations, a community forum. Those out items aren't bad ideas — they're version two.

3. Break the work down

Now turn the deliverables into pieces of work. The disciplined way to do this is a work breakdown structure — a hierarchy that decomposes each deliverable into smaller deliverables until you reach chunks small enough to estimate and assign. For the course, the top level is the deliverables themselves: Course content, Sales page, Launch. Under "Course content" sit the four modules; under each module sit script, record, edit. Under "Launch" sit the email sequence, the platform setup, and the announcement.

Resist the urge to jump straight to a flat to-do list. The hierarchy is what stops you forgetting whole branches of work — and it's the subject of its own guide, so this article won't re-derive the technique. The output you carry into the next stage is a list of the lowest-level items, each one a real piece of work: "Record module 2", not "do the course".

4. Sequence the work and add dependencies

With a list of tasks, the next question is order. Some tasks genuinely must follow others; some can run in parallel. You can't edit a module before you've recorded it, and you can't record it before the script is written — that's a chain. But you can write module 3's script while module 1 is being edited. Capturing this is the job of task dependencies: the rules that say one task can't proceed until another reaches a point.

Go through your list and, for each task, ask only one question: what must be true before this can start? Link those, and nothing else. The most common beginner error here is over-linking — chaining tasks that merely happen to come one after another but don't actually depend on each other. A false dependency makes the plan look more rigid than reality and hides the parallel work that could save you time.

5. Estimate how long each task takes

Put a duration on every task. This is where optimism does its damage, so estimate the work in effort first, then map it to calendar time honestly — a two-day editing job doesn't finish in two days if you only touch it on Tuesdays. Our deeper guide on estimating task durations covers the techniques (three-point estimates, analogy, breaking big unknowns down); the headline rule is that a number you can't defend is a guess wearing a tie.

For the course: scripting a module, half a day each; recording, half a day; editing, a full day because it always takes longer than you think; the sales page, two days; the email sequence, a day; platform setup, half a day. Write these down per task — you'll need them in a moment, and a plan with no durations is just a wish list with arrows.

6. Build the schedule

Now you have tasks, an order, and durations — everything a calendar needs. Laying them out as a Gantt chart turns the abstract plan into a picture of time: bars for tasks, arrows for dependencies, a real start and end date. Our walkthrough on how to make a Gantt chart takes you through it click by click; the value is that the moment you draw it, the shape of the project becomes visible. You'll see the total length, you'll see where work piles up, and you'll often discover the plan you sketched doesn't fit the deadline — which is far better to learn now than in week three.

7. Find the critical path

Some chains of tasks have slack; one chain doesn't. The longest chain of dependent tasks — the one that sets your earliest possible finish — is the critical path. For the course, it's likely script → record → edit for the last module, then platform setup, then launch. Tasks on that path have zero room: a one-day slip there is a one-day slip to the whole launch. Tasks off it (say, drafting the sales page) can wobble without moving the end date.

Knowing your critical path changes how you manage. It tells you where to spend your attention, what to protect, and which "we're a bit behind" warnings actually matter. Almost everything in the next three stages is about defending that path.

8. Assign owners, then identify risks and add buffers

Give every task a single owner — even on a solo project, "owner" means "the version of me responsible on that day", which forces you to confront whether you've booked yourself to do three things at once. Check for over-commitment by reading down the chart for bars that overlap on the same person.

Then list what could go wrong and what you'll do about it. For the course: the recording mic fails (keep a backup app on your phone), the platform's payment setup takes longer than expected (start it early, off the critical path), a module turns out to need re-recording (you padded the edit estimate for exactly this). Add buffer where the risk is real — but as an explicit, named reserve at the end of a phase, not by quietly padding every task. Hidden padding evaporates; a visible buffer is a decision you can defend and draw down on purpose.

9. Set a baseline and track against it

Before the first task starts, take a snapshot of the agreed plan — every task's planned start, finish, and duration. That snapshot is your baseline, and it's the single most useful thing you can do for tracking, because it gives you something to compare reality against. Without it, "are we behind?" has no answer; with it, you can see drift the moment it appears.

From launch day onward, the job is simple and relentless: update progress on each task, watch where actual diverges from the baseline, and act early when something on the critical path starts to slip. A plan is not a document you write once and file. It's a live instrument, and its whole value is in being kept honest — which is also how you'll know, weeks later, exactly why the project landed where it did.

The shape of the whole thing

Read the nine stages back and you'll notice they fall into three movements. First you decide what (goal, scope). Then you work out the how and when (breakdown, sequence, estimate, schedule, critical path). Finally you make it real and resilient (owners, risk, baseline, tracking). Skip the first movement and you build the wrong thing efficiently. Skip the last and you have a beautiful plan that quietly rots. The middle is where most guides stop — but the bookends are where projects are actually won or lost.

Frequently asked questions

How much planning is too much for a small project?

Match the plan to the stakes. A two-week solo project needs a goal, a short task list with durations, and a glance at the critical path — an afternoon of planning, not a week. The stages do not change; the depth does. The mistake is skipping the thinking entirely, not doing it lightly.

Should I plan the whole project up front or just the next phase?

Plan the whole thing at a coarse level so you can see the shape and the deadline, then detail the near term precisely and leave the far term rough. This is sometimes called rolling-wave planning. Detailed plans for work months away tend to be fiction anyway.

What is the difference between scope and a goal?

The goal is the outcome you want and how you will know you got it. Scope is the boundary of the work you will do to get there — including an explicit list of what you will not do. The goal says where you are going; the scope says how far the fence around the work extends.

When in the process should I build the Gantt chart?

After you have tasks, their order, and durations — stages three to five. The Gantt chart is where those three ingredients combine into a real timeline. Building it earlier means dragging bars around with no underlying logic, which gives you a drawing rather than a plan.