Project Planning and Scheduling: A Step-by-Step Guide With a Worked Example

Quick answer: Planning decides what the project will do and how. Scheduling turns that into dates. Build the schedule in order — scope, work breakdown, task list, estimates, dependencies, network, critical path — then level resources and baseline it. This guide walks one real project through all ten steps.

The part most guides skip: they explain the critical path method and never show the calculation. The numbers are all in Step 7, and they add up — you can check them.

What Is Project Planning and Scheduling?

Project planning decides what the work is. Project scheduling decides when it happens.

They’re separate activities that people treat as one word, and the confusion causes real problems.

	Planning	Scheduling
Question it answers	What and how	When and in what order
Output	Scope, WBS, resource plan, risk plan	Network diagram, Gantt chart, dated milestones
Changes when	Scope or approach changes	Estimates, dependencies, or resources change
Owned by	Project manager with the team	Project manager or a dedicated planner

You cannot schedule what you haven’t planned. A Gantt chart built before the work is defined is a picture of an assumption. This is the single most common failure in project scheduling — someone opens the scheduling software first.

Project schedule management is the ongoing part: keeping the schedule accurate as reality diverges from the plan, and using the gap between the two to make decisions.

Why Is Scheduling Important in Project Management?

Because a schedule is the only document that tells you whether you’re in trouble while there’s still time to act.

Four specific things a schedule does that nothing else does:

It reveals the sequence you can’t change. Some work simply cannot start until other work finishes. Until you’ve mapped that, “we’re behind” is a feeling rather than a fact.

It tells you which delays matter. Most tasks can slip without affecting the end date. A few can’t. Without a schedule you treat every delay as equally urgent, which means you spend your attention in the wrong places.

It makes resource conflicts visible before they happen. Two tasks needing the same person in the same week is obvious on a schedule and invisible in a task list.

It gives you a baseline to measure against. Progress without a baseline is just activity.

Benefits of Project Scheduling

Benefit	What it actually looks like
Earlier warning	You see a slip on the critical path in week three, not week nine
Better decisions under pressure	You know which task to crash and which to leave alone
Realistic commitments	You promise dates the network supports, not dates you hope for
Fewer resource collisions	Conflicts surface during planning rather than on the day
Defensible change control	“That change adds 6 days to the critical path” is a fact, not an opinion
Cleaner stakeholder conversations	The schedule replaces argument with arithmetic

The benefit people undervalue is the last one. A schedule converts “I think this is too tight” into “this path is 28 days and you’ve asked for 24.” That’s a different conversation.

The Example Project

Everything below uses one project, carried all the way through: redesigning and launching a small company website.

Nine tasks, one team, a real critical path. The numbers are deliberately small enough to check by hand.

Step 1: How Do You Define the Scope?

Before any dates, write down what’s in and what’s out.

In scope: new homepage, 5 service pages, contact form, content migration from the old site, launch.

Out of scope: blog migration, e-commerce, multilingual versions, ongoing SEO work.

Assumptions: client supplies all photography; one review round per deliverable; hosting already in place.

The “out of scope” list is the one that saves you. Undefined scope is the most common source of schedule slip, and it’s cheapest to prevent here.

Step 2: What Is a Work Breakdown Structure?

A work breakdown structure (WBS) breaks the project into smaller pieces until each piece is something you can estimate and assign.

1.0 Website Redesign
    1.1 Discovery
        1.1.1 Requirements workshop
        1.1.2 Content audit
    1.2 Design
        1.2.1 Wireframes
        1.2.2 Visual design
    1.3 Build
        1.3.1 Build templates
        1.3.2 Write copy
        1.3.3 Populate content
    1.4 Launch
        1.4.1 Testing
        1.4.2 Go live

The rule for how far to break down: stop when a piece is small enough to estimate confidently and large enough that tracking it isn’t a burden. A common guideline is between 8 and 80 hours per work package — anything smaller becomes admin.

Everything in the WBS is work. Everything not in the WBS is not in the project. That’s what makes it useful for change control later.

Step 3: List the Tasks

Flatten the WBS into a task list with an ID for each one. You’ll reference these IDs constantly.

ID	Task	Owner
A	Requirements workshop	PM
B	Content audit	Content lead
C	Wireframes	Designer
D	Visual design	Designer
E	Write copy	Copywriter
F	Build templates	Developer
G	Populate content	Content lead
H	Testing	Developer
I	Go live	PM

Step 4: How Do You Estimate Durations?

Two rules before any numbers: estimate duration, not effort, and ask the person who’ll do the work.

Duration is elapsed time. Effort is person-hours. A task needing 16 hours of one person’s time takes four days if they’re only on it half-time. Confusing the two is how schedules become fiction.

The three-point estimate

For anything uncertain, take three numbers instead of one:

• O — optimistic, if everything goes well
• M — most likely
• P — pessimistic, if things go badly

Then use the PERT formula, which weights the most likely outcome four times:

PERT estimate = (O + 4M + P) ÷ 6

Worked example — Task E, Write copy:

Optimistic: 5 days. Most likely: 8 days. Pessimistic: 17 days.

PERT = (5 + 32 + 17) ÷ 6 = 54 ÷ 6 = 9 days

Notice the pessimistic case pulls the estimate above the most likely one. That’s the point — it prices in the risk that a single-point estimate quietly ignores.

(For this walkthrough we’ll use 8 days for Task E to keep the arithmetic clean.)

Our durations:

ID	Task	Duration (days)
A	Requirements workshop	3
B	Content audit	5
C	Wireframes	4
D	Visual design	6
E	Write copy	8
F	Build templates	7
G	Populate content	4
H	Testing	3
I	Go live	1

Total if done one after another: 41 days. The schedule will be shorter, because some work runs in parallel.

Step 5: What Are Task Dependencies?

For each task, ask one question: what must finish before this can start?

ID	Task	Duration	Depends on
A	Requirements workshop	3	—
B	Content audit	5	A
C	Wireframes	4	A
D	Visual design	6	C
E	Write copy	8	B
F	Build templates	7	D
G	Populate content	4	E and F
H	Testing	3	G
I	Go live	1	H

Only record dependencies that are real. If you find yourself adding a link because “we’d rather do it that way,” that’s a preference, not a dependency — and false dependencies make your schedule longer than it needs to be.

Step 6: Draw the Network

The network shows the paths through the project.

                 ┌─ B(5) ─── E(8) ─┐
    A(3) ────────┤                  ├─── G(4) ─── H(3) ─── I(1)
                 └─ C(4) ─ D(6) ─ F(7) ─┘

Two paths run from A to G:

Path	Tasks	Total
Upper	A → B → E → G → H → I	3+5+8+4+3+1 = 24 days
Lower	A → C → D → F → G → H → I	3+4+6+7+4+3+1 = 28 days

The project takes 28 days — the length of the longest path, not the shortest.

That’s the critical path paradox: the longest route through the network gives you the shortest possible project duration. You cannot finish faster than the longest chain of dependent work.

Step 7: How Do You Calculate the Critical Path?

Now the calculation almost every guide describes and none of them shows.

Forward pass — earliest dates

Start at day 0. For each task: Early Finish = Early Start + Duration. A task’s Early Start is the latest Early Finish of everything it depends on.

Task	Duration	Early Start	Early Finish	Working
A	3	0	3	starts at 0
B	5	3	8	after A
C	4	3	7	after A
D	6	7	13	after C
E	8	8	16	after B
F	7	13	20	after D
G	4	20	24	after E (16) and F (20) — takes the later
H	3	24	27	after G
I	1	27	28	after H

Project duration: 28 days. Task G is where the two paths merge, and it waits for the slower one.

Backward pass — latest dates

Now work backwards from day 28. For each task: Late Start = Late Finish − Duration. A task’s Late Finish is the earliest Late Start of everything that depends on it.

Task	Duration	Late Start	Late Finish
I	1	27	28
H	3	24	27
G	4	20	24
F	7	13	20
E	8	12	20
D	6	7	13
C	4	3	7
B	5	7	12
A	3	0	3

Float, and the critical path

Float is how long a task can slip without delaying the project. Calculate it as Late Start − Early Start (or equivalently Late Finish − Early Finish).

Task	Early Start	Late Start	Float	Critical?
A	0	0	0	Yes
B	3	7	4	No
C	3	3	0	Yes
D	7	7	0	Yes
E	8	12	4	No
F	13	13	0	Yes
G	20	20	0	Yes
H	24	24	0	Yes
I	27	27	0	Yes

The critical path is A → C → D → F → G → H → I. Seven tasks, 28 days, zero float on every one.

What this buys you, practically:

B and E have 4 days of float each. The content audit and copywriting can both run up to four days late with no effect on the launch date. If the copywriter asks for extra time, the answer is yes — up to four days.

A one-day slip on D delays the whole project by one day. Visual design has no float. Same for wireframes, template build, content population, testing, and go-live.

This is why the calculation matters. Without it, a delay on copywriting and a delay on visual design look equally alarming. With it, one is free and one costs you the launch date.

Step 8: What Is Resource Levelling?

The schedule above assumes people are available when the network says so. They usually aren’t.

Resource levelling means adjusting the schedule so nobody is assigned more work than they can do. Two things to check:

Over-allocation. Look for one person assigned to overlapping tasks. In our project, C (wireframes) and D (visual design) both belong to the designer — but they’re sequential, so there’s no conflict. If E and G had both been the content lead’s work running in parallel, you’d have a problem.

Availability. Holidays, part-time contracts, and people split across projects all change duration.

The trade-off to know: levelling often pushes the end date out. That’s not a failure — it’s the schedule becoming honest about who’s actually available.

Step 9: How Do You Compress a Schedule?

Say the client wants launch in 26 days instead of 28. Two techniques, and they cost different things.

Crashing — add resources to critical tasks

Add people or hours to shorten a task. Only works on the critical path, and only pays if you pick the cheapest day saved.

Task	Current	Crashed	Days saved	Extra cost	Cost per day
D — Visual design	6	4	2	£1,200	£600
F — Build templates	7	5	2	£2,000	£1,000

Crash D. Same two days saved for £800 less.

Now recalculate — this is the step people skip. With D at 4 days, the lower path becomes 26 days. The upper path is still 24. So the critical path holds, but float on B and E drops from 4 days to 2. Compression consumes your safety margin somewhere else, and if you crash far enough the critical path shifts to a different route entirely.

Fast-tracking — overlap tasks that were sequential

Start F before D fully finishes — begin building templates from the approved wireframes while visual design completes.

Costs nothing in money. Costs you rework risk. If the visual design changes after the build starts, some of that build is wasted.

The honest rule: crash when you have budget, fast-track when you have tolerance for rework, and do neither on tasks with float — it buys you nothing.

Step 10: What Is a Schedule Baseline?

A baseline is a saved copy of the approved schedule. Once set, you don’t edit it — you compare against it.

Without a baseline, every schedule update quietly rewrites history and “we’re on track” becomes unfalsifiable.

Baseline these three together: scope, schedule, and budget. Changing one without the others produces a schedule that no longer matches the work.

Re-baseline only through formal change control, with a version number and a recorded reason. A schedule that drifts silently is worse than no schedule, because people trust it.

The Finished Schedule

Task	Start	Finish	Float	Owner
A — Requirements workshop	Day 0	Day 3	0	PM
B — Content audit	Day 3	Day 8	4	Content lead
C — Wireframes	Day 3	Day 7	0	Designer
D — Visual design	Day 7	Day 13	0	Designer
E — Write copy	Day 8	Day 16	4	Copywriter
F — Build templates	Day 13	Day 20	0	Developer
G — Populate content	Day 20	Day 24	0	Content lead
H — Testing	Day 24	Day 27	0	Developer
I — Go live	Day 27	Day 28	0	PM

Milestones: Design approved (Day 13), Build complete (Day 20), Launch (Day 28).

That’s a complete schedule you could run a project from. Everything above it exists to produce this table.

Do Agile Projects Need a Schedule?

The method above is predictive — it assumes you can define the work up front. Plenty of projects can’t.

	Predictive	Agile
Scope	Fixed, defined early	Evolving, prioritised continuously
Schedule	Full network, dated	Fixed-length iterations, forecast by velocity
Estimating	Duration per task	Relative points per item
Forecasting	Critical path	Velocity × remaining backlog
Changes	Change control	Expected, absorbed in the next iteration

Agile still schedules. The sprint is a fixed timebox, the release plan is a forecast, and velocity does the arithmetic the critical path does in a predictive plan. It isn’t “no schedule” — it’s a different mechanism.

Hybrid is what most real projects use. Fixed external commitments — a regulatory date, a trade show, a contracted milestone — get a predictive schedule. The work inside them runs iteratively.

A practical hybrid pattern: a milestone-level schedule with dates and dependencies for anything externally committed, and a backlog with iterations for everything else. Track the milestones with float; track the backlog with velocity.

When each fits: predictive when scope is stable and dependencies are hard, agile when the problem is understood but the solution isn’t, hybrid when you have a fixed date and an uncertain scope — which is most of the time.

How Do You Track Schedule Performance?

Two numbers tell you where you are.

Schedule Variance (SV) = Earned Value − Planned Value. In money or days. Negative means behind.

Schedule Performance Index (SPI) = Earned Value ÷ Planned Value.

SPI	Meaning
1.0	Exactly on schedule
Above 1.0	Ahead
Below 1.0	Behind

Worked example. By Day 20 you planned to complete £40,000 of work. You’ve actually completed £34,000 worth.

SPI = 34,000 ÷ 40,000 = 0.85

You’re running at 85% of planned pace. Straight-line forecast: 28 days becomes roughly 33.

One honest caveat. SPI drifts toward 1.0 near the end of a project, because remaining planned value shrinks — a late project can show SPI = 1.0 on its final day. Always read SPI alongside critical path status, not instead of it.

What Are the Best Tools for Project Planning and Scheduling?

Tool	Best for	Does real CPM?
Primavera P6	Large construction, engineering, EPC projects	Yes — the standard for complex scheduling
Microsoft Project	Mid-size predictive projects, corporate environments	Yes
Smartsheet	Teams wanting spreadsheet familiarity plus dependencies	Basic
Asana / Monday / ClickUp	Task coordination, small to mid teams	Limited — timelines, not true critical path
Jira	Agile software delivery	No — sprints and velocity instead
Excel / Google Sheets	Small projects, learning the method	Only if you build it yourself

The distinction that matters: most popular work management tools draw a timeline with dependency arrows and call it a Gantt chart. That’s not the same as calculating float and identifying a critical path. If your tool can’t tell you which tasks have zero float, it’s tracking work, not scheduling it.

For a nine-task project like the example above, a spreadsheet is genuinely fine — and building the forward and backward pass by hand once teaches you more than any software will.

How to Create a Project Schedule Using Popular Digital Tools

The same nine steps, in whichever tool you use.

In Microsoft Project or Primavera P6:

1. Enter tasks in the Gantt view, indented to match your WBS
2. Set durations in the Duration column — days, not hours
3. Link predecessors in the Predecessors column using task IDs
4. Assign resources
5. The critical path calculates automatically — turn on critical task highlighting to see it
6. Level resources if anyone is over-allocated
7. Set the baseline before work starts
8. Update percent complete and actual dates weekly

In Asana, Monday, or ClickUp:

1. Create tasks and set start and due dates
2. Add dependencies in the timeline view
3. Assign owners
4. Set milestones as zero-duration tasks
5. Calculate float manually — these tools generally won’t. Run the forward and backward pass in a spreadsheet and mark your critical tasks with a tag or custom field

In a spreadsheet:

Build columns for ID, Task, Duration, Predecessors, ES, EF, LS, LF, Float. Fill ES and EF top-down, LS and LF bottom-up, then float as LS − ES. Exactly the tables in Step 7. Conditional-format float = 0 to highlight the critical path.

Two things to do whichever tool you use. Set the baseline before anyone starts work — it’s the only way to measure progress afterwards. And update the schedule on a fixed day each week. A schedule updated when someone remembers is a schedule nobody trusts.

Where to Find Templates for Project Planning and Scheduling?

Four sources, in order of usefulness:

1. The tables in this article. The task list, dependency table, forward and backward pass, float table, and finished schedule are all copyable. Together they’re a complete working template, and the worked numbers show you what a filled-in version looks like.

2. Your own past projects. Usually the best source — the durations reflect how your team actually works rather than an average. If you’ve run a similar project, that schedule is your template.

3. Your tool’s built-in templates. Microsoft Project, Smartsheet, Asana, and most others ship with templates by project type. Useful for structure; always wrong on durations.

4. Professional bodies and vendors. PMI publishes templates and insights for members. Major vendors publish scheduling templates for their platforms.

One caution. Most free schedule templates online are empty Gantt charts — a grid with no logic in it. A template without dependency relationships can’t calculate a critical path, which means it can’t tell you which delays matter. Check that the template has a predecessors column before you adopt it. If it doesn’t, it’s a picture of a schedule rather than a schedule.

Which Books and Standards Are Worth Knowing?

Two references most scheduling professionals encounter.

PMBOK Guide (Project Management Institute) covers schedule management as a knowledge area — defining activities, sequencing them, estimating durations, developing the schedule, and controlling it. It’s the framework most certifications test against.

Harold Kerzner’s Project Management: A Systems Approach to Planning, Scheduling, and Controlling (Wiley) is the long-standing textbook in this field, now in its thirteenth edition. It goes considerably deeper than any article can, particularly on earned value and organisational context. If you’re moving from running projects to teaching or certifying, it’s the standard reference.

Standards get revised. Check which edition your organisation or certification body expects.

8 Scheduling Mistakes to Avoid

1. Opening the scheduling tool first. Scope, then WBS, then tasks, then dates. Never dates first.

2. Confusing duration with effort. Sixteen hours of work at half-time availability is four days, not two.

3. Inventing dependencies. “We’d rather do it that way” is a preference. False dependencies make the schedule longer than the work requires.

4. Single-point estimates on uncertain work. Use three points and the PERT formula.

5. Crashing tasks that have float. Spends money and saves nothing.

6. Not recalculating after compression. The critical path can shift, and your float disappears somewhere you weren’t watching.

7. No baseline. Progress with nothing to compare against is just activity.

8. Updating the schedule irregularly. Update on a fixed day or people stop trusting it.

Project Schedule Checklist

• [ ] Scope defined, including what’s out
• [ ] WBS complete, work packages between 8 and 80 hours
• [ ] Every task has an ID and one named owner
• [ ] Durations are elapsed time, not effort
• [ ] Uncertain tasks estimated with three points
• [ ] Every dependency is real, not preferential
• [ ] Forward pass complete — ES and EF for every task
• [ ] Backward pass complete — LS and LF for every task
• [ ] Float calculated for every task
• [ ] Critical path identified and visible to the team
• [ ] Resources levelled, no over-allocation
• [ ] Compression recalculated if applied
• [ ] Milestones defined
• [ ] Baseline saved and approved
• [ ] Weekly update day fixed in calendars
• [ ] Change control process agreed before work starts

How Writegenic AI Fits In

The calculation is arithmetic. The documents around it are where the time goes — the project plan, the schedule narrative, the status reports, the change requests, the closure report.

Writegenic AI is an AI writing platform with 300+ templates and support for 120+ languages, with a set built for project documentation:

• AI for Project Management — drafting project documents from structured inputs
• Project management tools — templates for the surrounding deliverables
• Requirements management plan and Risk assessment plan — the documents a schedule depends on
• AI Prompt Generator — one reusable prompt encoding your document structure so every plan comes out consistent

Where the line sits. A writing tool drafts the plan document and keeps ten projects’ paperwork consistent. It cannot estimate your durations, know that this subcontractor is always late, or decide whether to crash or fast-track. Those are judgements built on your experience of the work.

Draft the documents with the tool. Do the scheduling yourself — and once you’ve run a forward and backward pass by hand, you’ll read every schedule differently.

Start with Writegenic AI free.

Frequently Asked Questions

Related reading: Risk Assessment Plan Template · Risk Response Strategies · Functional Design Specification · AI for Project Management