Project Schedule Definition, Best Practices, Gantt Chart WBS

Project Schedule: Definition, Example & How to Create One

Project Schedule: Definition and Best Practices of Project Scheduling
Project Schedule: Definition and Best Practices of Project Scheduling
Definition
Project Schedule
A project schedule is a time-ordered list of the activities needed to finish a project, with a start date, finish date, duration, owner, and dependencies for each one, plus the milestones the team has to hit. It turns the project plan into dates: who does what, in what order, and by when.

Every project has a deadline. A project schedule is how you find out whether that deadline is realistic, and what has to happen on which day to meet it. This guide explains what goes into a schedule, walks through building one in seven steps, and shows a complete worked example with dependencies, float, and a Gantt chart. You can download the same example as a free Excel template.

Key Takeaways

  • A project schedule lists activities, durations, dependencies, owners, and milestones. Without dependencies it is just a to-do list with dates.
  • Build it from the work breakdown structure: define activities, sequence them, estimate durations, then calculate dates and the critical path.
  • The critical path is the longest chain of dependent activities. Any delay on it moves the finish date; activities off it have float.
  • Approvals, reviews, and supplier lead times belong in the schedule as real activities. Leaving them out is the most common reason schedules slip.
  • Want a head start? Grab the free Excel project schedule template, or test yourself with the 10-question quiz.

What Is a Project Schedule?

A project schedule, sometimes called a project management schedule, answers three questions for everyone involved: what needs to be done, in what order, and by when. The Project Management Institute describes it as the output of a schedule model that links activities to planned dates, durations, milestones, and resources. In plain terms, it is the plan with a calendar attached.

Project scheduling is the process of building and maintaining that schedule. It starts once the scope is clear and continues until the project closes, because a schedule that is never updated stops being useful within weeks. If you are new to the vocabulary, our guide to what a project is covers the basics first.

The idea is the same whatever the method. On a construction site the schedule may run to thousands of activities in Primavera P6. On a software team using Scrum it may be a release plan split into two-week sprints. On a small marketing project it may be a single spreadsheet. The level of detail changes; the logic of activities, order, and dates does not.

What a Project Schedule Includes

A usable schedule has seven elements. Missing any one of them usually shows up later as a surprise.

  • Activities: the pieces of work, each small enough to estimate and assign. They come from the work breakdown structure (WBS).
  • Durations: how many working days each activity takes from start to finish.
  • Dependencies: which activities must finish (or start) before others can begin.
  • Start and finish dates: calculated from the durations, the dependencies, and the working calendar.
  • Owners and resources: the person accountable for each activity, plus any equipment or budget it needs.
  • Milestones: zero-duration checkpoints such as “design approved” or “go-live.”
  • Baseline: a saved copy of the approved schedule, so you can measure progress against the original plan.

Project Schedule vs. Project Plan vs. Timeline

These terms get mixed up constantly, including by experienced managers. The difference matters when someone asks you for “the plan” and actually wants dates.

DocumentWhat it answersTypical contents
Project planHow will we run this project?Scope, budget, schedule, risks, communication, quality, and procurement approach. The schedule is one part of it.
Project scheduleWhat happens when, and who does it?Activities, durations, dependencies, dates, owners, milestones, baseline.
Project timelineWhat are the big moments?A simplified visual of phases and milestones, usually for sponsors and clients. No dependencies or owners.
Project calendarWhich days count as working days?Working hours, weekends, public holidays, and shutdowns that the schedule uses to calculate dates.

How to Create a Project Schedule in 7 Steps

The steps below follow the order used in the PMBOK Guide’s schedule management processes, simplified for everyday projects. Steps 2 to 4 are where project activity planning happens; skip them and the dates in step 5 are guesses.

Step 1. Confirm the Scope and Break It Down

You cannot schedule work you have not defined. Start from the agreed project scope and break the deliverables into a work breakdown structure: deliverables at the top, smaller components below, and work packages at the lowest level. A work package is something one team can deliver and one person can be accountable for.

Step 2. Define the Project Activities

Now turn each work package into activities: the actual tasks that produce it. “Website content” becomes “write page copy,” “edit copy,” and “load copy into the CMS.” A good rule of thumb is that no activity should take more than about two weeks, or 80 hours of effort. Anything longer is hard to estimate and hard to track, because it stays “in progress” for too long to tell whether it is on time.

Write every activity as a verb and a noun, and include the ones people forget: reviews, approvals, supplier lead times, testing, and handover.

Step 3. Sequence Activities and Set Dependencies

Decide what has to happen before what. There are four types of dependency, although most schedules use the first one almost exclusively:

  • Finish-to-start (FS): B cannot start until A finishes. Design must be approved before development starts.
  • Start-to-start (SS): B cannot start until A starts. Editing can start once writing has started.
  • Finish-to-finish (FF): B cannot finish until A finishes. Testing cannot finish until development finishes.
  • Start-to-finish (SF): B cannot finish until A starts. Rare; used for handovers such as an old system running until the new one starts.

Some dependencies are hard logic (you cannot test code that does not exist). Others are preferences (the team would rather finish design before writing starts). Mark which is which, because preferences are the first thing you can change when the schedule is too long.

From the field

Eric Morkovich, PMP, project manager

Eric Morkovich, PMP
Project manager and long-time MyManagementGuide contributor

The Signature Nobody Scheduled

A few years ago I ran an office move for a 60-person company. Honestly, I was proud of that schedule. Every activity was there: IT cabling, furniture delivery, the phone system cutover, even the day the coffee machine moved. Critical path worked out, float calculated, sponsor happy.

Two weeks before the move, the electrician finished the new floor and we were ready to go. Except the building manager had to sign off the electrical work before anyone could plug in a server. I knew that. It just lived in my head as “the landlord signs,” not in the schedule as an activity with a duration and an owner. He was on vacation. The signature took nineteen days. Nineteen! The whole move slid by three weeks, and every vendor had to be rebooked.

What stung was that nothing in the schedule was wrong. The one thing that went wrong simply wasn’t in it.

Lesson: if someone outside your team has to approve, sign, or deliver something, it is an activity. Give it a duration, a name, and a dependency, or it will ambush you.

Step 4. Estimate Durations and Resources

Estimate how long each activity will take in working days, and who will do it. Ask the people doing the work, not only the people managing it. Three common techniques:

  • Analogous estimating: base the estimate on a similar past activity. Fast, but only as good as the comparison.
  • Parametric estimating: multiply a known rate by the quantity. If one page of copy takes half a day, twenty pages take ten days.
  • Three-point estimating (PERT): ask for optimistic (O), most likely (M), and pessimistic (P) durations, then use (O + 4M + P) / 6. For an activity estimated at 4, 6, and 14 days, that gives 7 days.

Keep effort and duration apart. Effort is the hours of work; duration is the calendar time from start to finish. A 16-hour task done by someone who spends half their week on another project has a duration of four days, not two. Our article on managing project duration goes deeper into this.

Expert Tip

When a developer tells me “two days,” I always ask one follow-up: two days of work, or done two days from now? The answers are almost never the same, and only the second one belongs in the schedule.

Daniel LinmanDaniel Linman, IT software consultant

Step 5. Calculate Dates and Find the Critical Path

With activities, dependencies, and durations in place, the dates calculate themselves: each activity starts on the first working day after its predecessors finish. Any scheduling tool, or the Excel template below, does this for you. Then find the critical path, the longest chain of dependent activities. Its length is the shortest possible duration of the project. More on this in the critical path section below.

Step 6. Review, Adjust, and Compress if Needed

Walk through the draft with the team and check it against reality: is anyone booked on two things at once, do the dates collide with holidays, and does the finish date meet the deadline? If it does not, you have two standard options. Fast-tracking runs activities in parallel that were planned in sequence (usually by relaxing a preferred dependency), which adds risk. Crashing adds people or money to critical activities to shorten them, which adds cost. If neither works, the honest answer is to change the scope or the deadline, and to say so now rather than in week eight.

Step 7. Approve and Save the Baseline

Once the sponsor agrees, save a copy of the schedule as the baseline. From here on, you track actual progress against it. The baseline only changes through a formal change request; otherwise you lose the ability to say how far the project has drifted, and why.

Project Schedule Example: Website Redesign

Here is a complete schedule for a small company website redesign, starting Monday, January 4, 2027. Durations are in working days (Monday to Friday). Float is how many days an activity can slip without moving the launch date.

IDActivityOwnerDaysDepends onStartFinishFloat
AKickoff and requirementsProject manager5–Jan 4Jan 80
BSitemap and content planUX lead5AJan 11Jan 150
CVisual designDesigner10BJan 18Jan 290
DContent writingContent writer15BJan 18Feb 55
EFront-end developmentFront-end developer15CFeb 1Feb 190
FCMS setup and back endBack-end developer8CFeb 1Feb 102
GLoad content into CMSContent writer5D, FFeb 11Feb 172
HTesting and fixesQA lead5E, GFeb 22Feb 260
IClient sign-off (milestone)Sponsor0HMar 1Mar 10
JLaunch and handoverProject manager2IMar 1Mar 20

The same schedule as a Gantt chart. Dark bars are on the critical path, light bars have float, and the hatched part shows how far each one can slip.

What the example tells you:

  • The project takes 42 working days, because that is the length of the critical path A, B, C, E, H, I, J. Adding up every duration would give 70 days; parallel work is what brings it down.
  • Front-end development is the activity to watch. It is the longest critical activity, so one lost day there is one day late at launch.
  • Content writing has 5 days of float. If the writer is pulled onto another project for a week, the launch date survives. A second week would not.
  • The float on F and G is shared. If CMS setup uses its 2 days, content loading has none left. Float belongs to the path, not to one activity.

Three More Project Scheduling Examples

The same method works in any industry. Only the activities and the typical traps change.

ProjectMain phases in orderWhat usually drives the critical path
Construction (small commercial fit-out)Design and permits, demolition, rough-in (electrical, plumbing, HVAC), inspections, drywall and finishes, final inspection, handoverPermit approval and inspection dates, plus long-lead items such as HVAC units
Software releaseDiscovery, design, sprint 1-4 development, QA and user acceptance testing, release preparation, go-liveIntegration with other systems and the time the business needs for acceptance testing
Corporate eventBudget and venue, speakers and agenda, registration, marketing, logistics and catering, rehearsal, event day, follow-upVenue contract and speaker confirmations, both of which have hard external deadlines

Types of Project Schedules

A schedule is one set of data that can be shown in several ways. Pick the view that suits the audience and the project.

TypeWhat it showsBest for
Gantt chartActivities as bars on a calendar, with dependencies and progressMost projects; the default view for the project team
Milestone scheduleOnly the key dates and deliverablesSponsors, clients, and steering committees
Network diagram (CPM)Activities as boxes connected by arrows, with early and late datesFinding the critical path and checking the logic
PERT chartA network diagram with three-point duration estimatesProjects with high uncertainty, such as research or first-of-a-kind work
Release and sprint planFeatures grouped into fixed-length sprints leading to releasesAgile software teams working in Scrum or similar methods
Master and detailed schedulesA summary schedule for the whole program, with detailed schedules per phase or contractorLarge projects such as construction, where schedules are often split into levels

Whatever view you use, the underlying data should be the same. A milestone chart for the client and a Gantt chart for the team drawn from two different spreadsheets will disagree within a week.

Critical Path and Float in Project Scheduling

The critical path is the longest sequence of dependent activities from the start of the project to the finish. Because nothing on it can overlap, its length is the shortest time in which the project can be completed. In the example above it runs A, B, C, E, H, I, J and takes 42 working days.

To find it, schedulers do two passes. The forward pass works from the start and gives every activity its earliest start and earliest finish. The backward pass works back from the finish date and gives the latest start and latest finish that would still hit it. The gap between the two is total float (also called slack): how long an activity can be delayed without delaying the project. Activities with zero float form the critical path.

Two practical points. First, the critical path can move: if content writing in the example slips by six days, it becomes critical and front-end development stops being the bottleneck. Second, float is not spare time to spend freely; it is a buffer shared by everyone on that path. Our guide to the critical path method covers network diagrams and a spreadsheet example.

Common Project Scheduling Mistakes

  1. Scheduling backwards from the deadline. Fitting the activities into the date someone promised produces a schedule that looks fine and has no basis. Build it forwards, then compare.
  2. Leaving out approvals and external lead times. Sign-offs, permits, legal reviews, and supplier deliveries take calendar time even when nobody on the team is busy.
  3. Activities that are too big. “Development, 60 days” will report “on track” until day 55. Break it down.
  4. Booking people at 100%. Nobody spends a full week on project work. Meetings, support, and other projects eat into it, so plan for 60-80% availability.
  5. Ignoring the calendar. Public holidays, vacations, and year-end freezes move dates. Put them in the project calendar before you calculate anything.
  6. Hiding the buffer in every estimate. Padding each activity quietly makes the whole schedule long and the padding gets used anyway. Keep estimates honest and hold a visible contingency at the end, or before key milestones.
  7. Never updating it. A schedule that still shows January’s plan in March is decoration. Update it weekly.

Keeping the Project Schedule on Track

Building the schedule takes days; managing it takes the rest of the project. A simple weekly routine is enough for most teams:

  • Collect actuals: which activities started, which finished, and how much remains on those in progress. Ask for “days remaining,” not “percent complete,” which tends to sit at 90% for weeks.
  • Recalculate and compare with the baseline. Look at the forecast finish date and at critical activities first. The gap between planned and actual on each activity is its activity variance.
  • Watch float, not just dates. An activity that has used most of its float is about to become critical, even if it is not late yet.
  • Act early and record changes. Resequence, add help, or cut scope while the options are cheap. If the finish date has to move, change the baseline through a formal change request so everyone knows why.

Many of the risks that break schedules are visible on day one in the project constraints and assumptions. When the project moves from planning into delivery, the schedule also becomes the backbone of the implementation plan.

Free Project Schedule Template (Excel)

The template contains the website redesign example from this guide, ready to overwrite with your own project. Enter activities, durations in working days, and up to two predecessors; start and finish dates calculate automatically and a weekly Gantt chart fills in next to the table. A Holidays tab removes non-working days from every date. For a simpler list without dependencies, see our activity schedule template.

⬇  Download the Project Schedule Template
Excel workbook (.xlsx), also opens in Google Sheets. No email required.

Practice: Test Yourself

10 questions on this guide: what goes into a schedule, dependencies, estimating, the critical path, and float. Multiple choice, with an explanation after each answer.

Quick Knowledge Check: Project Scheduling

10 questions. Takes about 3 minutes.

Frequently Asked Questions

It is the list of everything that has to happen in a project, in order, with dates and a person responsible for each item. It shows when each activity starts and finishes, which activities depend on each other, and when the key milestones fall.

The project plan explains how the whole project will be run: scope, budget, risks, communication, and quality. The project schedule is one part of that plan. It covers only time: activities, durations, dependencies, dates, and owners.

Float, also called slack, is how long an activity can be delayed without delaying the project finish date. Activities on the critical path have zero float. Float is shared along a path, so if one activity uses it, the activities after it have less.

It is a saved copy of the approved schedule. As the project runs, you compare actual dates with the baseline to see how far the project has drifted. The baseline should change only through a formal change request, not every time a date moves.

Weekly works for most projects: collect actual progress, recalculate the dates, and check the forecast finish and the critical path. Short or fast-moving projects may need updates every few days; long construction programs often run a formal monthly update on top of weekly checks.

For small projects, a spreadsheet such as the free Excel template in this guide is enough. For dependencies across dozens of activities and several people, dedicated tools such as Microsoft Project, Smartsheet, or a Gantt view in your project management software save time. Large construction projects typically use Primavera P6.