How to create a project schedule step by step

Knowing how to create a project schedule is mostly a matter of order. Most people open a calendar or a blank chart and start dropping bars on dates, then wonder why the plan falls apart in week two. A good schedule is built in a fixed sequence: first what has to be done, then how long it takes, then what depends on what, and only then the dates. This guide walks through that sequence with a small, concrete example you can copy.

What a project schedule actually is

A project schedule is a list of tasks, each with a start, a duration and an end, connected by the order in which they must happen. It answers three questions: when does each piece of work happen, what is waiting on what, and when does the whole thing finish.

A Gantt chart is the most common way to show it, because it draws every task as a bar on a timeline and lets you see overlaps and sequences at a glance. If you want the background on how those links work, read our guide to task dependencies in a Gantt chart. Here we focus on building the schedule from scratch.

Our example: launching a landing page

To keep things concrete, we will schedule a small project: a landing page and a newsletter announcement for a new product. It has one designer, one developer and one person who writes copy. Nothing exotic, which is exactly why it is a good example: even a small project has hidden ordering problems.

Step 1: Define the outcome and the deadline

Write one sentence that says what "done" means. For our example: the landing page is live and the announcement newsletter has been sent. Then note whether the end date is fixed (a conference, a campaign) or flexible. This matters later, because a fixed date means you plan backwards and a flexible one means you plan forwards.

Every task you add afterwards should help reach that sentence.

Step 2: List the work, not the dates

Break the outcome into tasks. Write them as short actions that start with a verb and finish with something you can check:

• Agree the brief and scope
• Write the page copy
• Design the page
• Build the page
• Review copy and build together
• Fix review feedback
• Write and schedule the newsletter

Aim for tasks that last between one day and about two weeks. A task of "Marketing" is too vague to schedule; a task of "Write the page copy" is something a person can start and finish.

Group related tasks into phases

When a plan grows past ten or fifteen tasks, group them. In ProGantt Flow you can nest tasks as subtasks under a task group, and the group's bar spans its subtasks automatically. In our example you might have a "Content" group (copy and newsletter) and a "Web" group (design, build, fixes). Groups keep a long schedule readable and let you collapse the detail you do not need today.

Step 3: Estimate durations

Give every task a duration in days. Estimate the time the work takes from start to finish, including the waiting that normally happens around it, not only the hours of pure effort.

A few habits make estimates more honest:

• Ask the person who will do the work, not the person who wants it done.
• Estimate each task separately rather than guessing a total.
• Compare with something similar you did before, if you have it.
• Round up for anything that involves other people's feedback.

Our example estimates:

Task	Duration
Agree the brief and scope	2 days
Write the page copy	4 days
Design the page	5 days
Build the page	6 days
Review copy and build together	2 days
Fix review feedback	2 days
Write and schedule the newsletter	3 days

Step 4: Link tasks with dependencies

Now decide which tasks cannot start until another one finishes. This is the step that turns a list of bars into a real schedule.

In our example:

• Copy and design both wait for the brief.
• The build waits for the design.
• The review waits for both the copy and the build.
• The fixes wait for the review.
• The newsletter waits for the copy.

Notice that copy and design can run at the same time. A schedule that puts everything in a single line is longer than it needs to be, and one that ignores dependencies finishes earlier than reality will allow. Only add a link when one task truly cannot begin before the other ends; every unnecessary link makes the plan more rigid.

Step 5: Find the longest chain

With dependencies in place, look for the longest chain of linked tasks from start to finish. In our example it is brief (2) then design (5) then build (6) then review (2) then fixes (2), a total of 17 days. The copy path (2 + 4 = 6 days) finishes long before the build does, so it has slack: it could slip by several days without moving the end date.

This is the part of the schedule that decides your finish date. A delay on the longest chain delays the project; a delay on a task with slack may not matter at all. Knowing which is which tells you where to spend your attention. Gantt charts make this visible because the chain of connected bars runs across the whole timeline.

Step 6: Add milestones and a buffer

A milestone is a date, not a task: it has no duration and marks something important, such as "Page approved" or "Launch". Put one at each point where a decision or hand-off happens, and one at the end.

Then add a buffer. Our chain is 17 days, so a realistic launch milestone might be placed at day 19 or 20, leaving a couple of days for the surprises that every project has. Be open about the buffer instead of hiding extra time inside every task. Padding each estimate makes it impossible to tell later where time was really lost.

Step 7: Assign people and check the load

Give each task an owner. Then look at the timeline for any person with two heavy tasks at the same moment. In our example the developer is only busy during the build, but if a second project lands on the same days, the schedule needs to move or the work needs to be shared.

Step 8: Share it and keep it current

A schedule is only useful while it matches reality, so two habits matter more than the first draft:

1. Update progress regularly. Set the percentage complete on each task once or twice a week, or whenever something changes.
2. Move dates when reality moves. When a task slips, change it and let the dependent tasks follow, then look at the new finish date. Do it the same day, not at the end of the month.

Share the plan with the people who need it. In ProGantt Flow you can invite collaborators as editors or viewers, so a client or stakeholder can see the schedule without being able to change it.

If you use an AI assistant such as Claude, it can also do the routine updates for you: ProGantt Flow has an MCP connector that lets the assistant read the plan and move tasks. Our post on managing a project plan with Claude shows how, and the connector docs cover the setup.

Not every project needs this level of structure. If your work is a steady flow of small, independent items, a board may serve you better; we compare the two in Gantt chart vs Kanban.

Try it on your next project

Take a project you are about to start and run the eight steps in order: outcome, tasks, durations, dependencies, longest chain, milestones, people, updates. Doing it once on paper takes less than an hour, and you can build the same plan in ProGantt Flow by adding tasks, setting durations and linking them on the timeline.