Project plan vs project schedule: what each one contains and who reads it

Ask four people on a project for "the plan" and two of them may open a Gantt chart while the other two forward a document with the scope and the budget. The chart shows when the work happens. The document says what the work is and who may change it. Trouble arrives with the first change request, when only one of the two exists.

This guide sets the project plan beside the project schedule. A table shows what goes in each and who reads it. Then a one-day customer conference follows a single change request, counted in days by the schedule and decided under the rules of the plan.

Project plan vs project schedule: what each one is#

A project plan is the agreed document that sets out a project's scope and the rules for running it, including who may change them. Its counterpart, the project schedule, models that plan and gives each task its dates and links^[1]. Without a written plan, a change that adds 4 days of work and spends the last free day before a date fixed by contract can be approved with nobody named to accept it. If the schedule is the missing half, the same change looks free, since nothing counts the days it consumes.

The order between the two comes from the US Government Accountability Office (GAO). Its Schedule Assessment Guide (GAO-16-89G) says the overall execution strategy is documented in the project plan, which defines the scope and the work breakdown structure among other things, and that scheduling is a distinct process that follows planning^[1]. In GAO's words, the schedule is "essentially a model of the project plan"^[1].

NASA treats the plan as an agreement. Under NPR 7120.5F the project plan is agreed among the project manager, the programme manager, the Center Director and the Mission Directorate Associate Administrator, and its template holds a summary of the integrated master schedule in a Schedule Baseline section^[2].

Who needs a plan and a schedule, and when#

Our recommendation: write a plan from three people or four weeks of work upwards, once the objective and scope are agreed and before the schedule is final, because the scope decides which tasks exist. With two people the scope lives in one conversation. A third person is the first who did not hear it, and four weeks is long enough for a change request to arrive while work is under way.

Skip it for two people working two weeks on a scope fixed by contract. The contract already does the plan's job.

The project manager writes the plan with the sponsor and builds the schedule with the people doing the work. The readers differ:

• The sponsor agrees the plan before work starts and goes back to the exclusions and the change rule whenever a request comes in.
• A team of 3 to 8 people reads the schedule every week; above 8, each sub-team lead reads their own branch.
• Suppliers get their slice and nothing more. The caterer in the example needs one date, day 22, when the headcount arrives.

Our rule of thumb for length: half a page of plan covers three people over a month, and one to three pages cover up to about 8 people and 6 months. Above 8 people the team tends to split into sub-teams, and each lead needs a written slice of the scope. Past 6 months the change log alone outgrows a paragraph.

Once the plan is agreed, build the schedule from the work breakdown structure (WBS), as the guide to the WBS shows. The schedule changes at every progress entry, while the plan is revised only when the scope or the team changes.

What goes in the plan, what goes in the schedule, and who reads each#

The plan holds the scope and the rules and is read by the sponsor; the schedule holds the tasks and their dates and is read by the team every week.

GAO expects schedules to be developed by the project team, including the managers responsible for specific areas of work^[1]. That is why the "Who writes it" row names the people doing the work as co-authors of the schedule.

Read the change-request row first. A request needs an answer from both columns before anyone can say yes, and in the example below the schedule supplies the number of days while the plan names the person who decides. Delays are measured against the baseline dates, and the guide to baselines and variance covers how to read them.

A worked example: a customer conference#

A third track requested on day 8 adds 4 days of work to this conference and moves its "venue ready" milestone from day 25 to day 26, onto the only free day before the event.

A software company runs a one-day conference for 300 customers. The venue contract fixes the date: the event is on day 27. The project team is the project manager plus two people, an events coordinator and a marketing assistant, and the sales director is the sponsor. The schedule has two paths that meet at the set-up; all links are finish-to-start and durations are in working days.

Path A takes 5 + 15 + 2 = 22 days and is the critical path. Path B takes 12 + 4 + 3 = 19. So the set-up runs on days 23 to 25 and day 26 is free.

Two terms need keeping apart. Float here means total float, the amount of time an activity can slip before the end date is affected^[1]; path B has 22 − 19 = 3 days of it. Margin is the free time between the "venue ready" milestone and the fixed event date: 1 day, day 26.

The plan runs to one page and sets two rules. Any change to the scope needs the sponsor's approval, whatever it does to the dates. A change of dates or method that leaves the scope alone and stays within float is the project manager's call, written in the change log.

On day 8, with "Book the speakers" still running, the sponsor asks for a third track: four more speakers and a third room. The events coordinator, who has booked every speaker so far, estimates 4 more days of work. Little else moves. The caterer's headcount stays at 300 because the same people attend, the printer quotes the same 3 days for a longer programme, and the set-up crew confirms that a third room still fits in 3 days. The room hire costs money and no time, so the schedule cannot show it.

Path B becomes 16 + 4 + 3 = 23 days against 22 on path A. The set-up moves to days 24 to 26 and the critical path switches to B. Float absorbs 3 of the 4 extra days, and the fourth takes day 26, leaving zero margin.

The event date is intact, yet the decision belongs to the sponsor, because the plan gives every scope change to the sponsor. The project manager puts three options in front of them:

1. Accept the track and run the last week with zero margin.
2. Split the new bookings. The marketing assistant books two of the four new speakers on days 9 and 10. The coordinator keeps the other two, both partner executives they have negotiated with before, and books them on days 13 and 14, after the original bookings end on day 12. "Book the speakers" then ends on day 14 and path B is 14 + 4 + 3 = 21 days. Day 26 stays free, with 1 day of float left on B.
3. Refuse it.

Option 2 has a limit. It keeps day 26 free only while the assistant can start by day 14: two days begun on day 14 end on day 15, path B becomes 15 + 4 + 3 = 22 days, level with path A, and the margin survives with no float left on B.

Our recommendation: send the sponsor the cost of a request in days and in money on the day it arrives, with the options, in five lines or fewer, even when the date holds. A request that spends the last free day leaves any later one-day slip landing on the event itself.

The sponsor picks option 2.

On day 10 one of the assistant's two speakers declines, and finding a replacement takes until day 11. Four new speakers are still coming, so the scope is unchanged, and the assistant's work still ends before the coordinator's on day 14. The project manager records it in the change log without going back to the sponsor.

In the original schedule, a printing delay would have been the same kind of decision. A busy press pushing the print job from days 17–19 to days 19–21 ends path B on day 21, the set-up still starts on day 23 and the margin is untouched, so the project manager logs it alone.

Why a Gantt chart is not a plan#

A Gantt chart cannot be the plan because it shows only work that has been scheduled: tasks as bars on a calendar, with the links between them (the Gantt chart guide explains how to read one). Four things a plan carries have no place on it:

• Exclusions. Work that is out of scope has no bar, and a missing bar looks exactly like work nobody has thought of yet.
• The approval rule.
• The reason behind a date. Day 27 can appear as the project deadline, while the venue contract that makes it immovable appears nowhere, so a reader cannot tell a fixed date from a target.
• Costs that take no time, such as the hire of the third room.

GAO raises the same gap from the schedule side: its best practice on baselines asks for a basis document that details the ground rules and assumptions behind the schedule and justifies its constraints and lags^[1].

Take a production manager who joins the conference in week 3 and receives only the Gantt chart. They see seven tasks and a "venue ready" milestone at the end of day 25, with the event date marked as the project deadline on day 27, one free day later. A supplier offers them a photo booth that needs half a day of set-up, and since nothing on the chart says whether additions are in scope, they agree, so the set-up grows into day 26. Nobody tells the sponsor. The rule that covered the case, "any change to the scope needs the sponsor's approval", sat in a plan nobody had sent them.

How to write the plan and build the schedule from it#

Six steps take a project from an agreed objective to a baselined schedule, and each one has an output to check before the next.

1. Write the objective and the fixed date in one sentence. For the conference: "A one-day conference for 300 customers on day 27, date fixed by the venue contract."
2. List what is out of scope and name who approves changes. The sponsor agrees both in writing before any task is estimated; an email reply is enough.
3. Break the scope into deliverables. Output: a WBS whose work packages cover the whole scope, each with an owner.
4. Turn each work package into tasks with durations and links. The people doing the work give the estimates, and the guide to estimating task durations covers the methods. You get a network with a critical path and a finish date.
5. Compare the finish with the fixed date. The margin was 1 day in the conference. A negative margin sends you back to step 2 to cut scope or ask for a later date, because GAO is explicit that work must be planned before activities can be scheduled^[1].
6. Save the baseline and copy its milestones into the plan. GAO calls the baseline the target schedule and subjects it to a configuration management control process^[1], which on a small project means it changes only through the change rule from step 2. One line in the plan then carries the milestones and the margin. Send the plan together with the schedule to anyone who joins after kick-off.

Common mistakes when the plan and the schedule get mixed up#

The mistake we would fix first is the schedule sent round as the plan, because on the day a request arrives it leaves nobody able to show what the brief contained. Five patterns to look for:

• The schedule sent round as the plan. On day 8 nobody can show whether a third track was ever in the brief, and the argument is settled from memory.
• Every change made twice, because the task list was pasted into the plan document; after the first progress update one copy is wrong.
• An imported .mpp file of 140 tasks whose top summary row is called "Scope": it groups tasks, and no exclusion is written anywhere.
• Sections nobody opens. Cut any section of the plan that was not consulted once between kick-off and close.
• No named owner for changes, so each request goes to whoever spoke to the team last.

What each document cannot do#

A plan cannot test its own deadline; only the schedule can. In the conference, path A needs 22 days before the set-up can start, and a contract promising the event on day 20 would have read perfectly well in a plan with no schedule behind it.

A schedule is blind to work nobody put in scope. Badge printing that was never written down has no bar and no float. The critical path is calculated as if the badges would print themselves.

Planning in stages keeps the order between the two. GAO accepts planning done in stages as stakeholders learn more details, an approach known as rolling wave planning, and states that in no case should planning be concurrent with scheduling^[1]. On a project planned in waves, each wave's scope is written down before its tasks get dates.

The short format has a ceiling. Our rule of thumb: once a contract or a regulator asks for a separate plan document, such as a safety plan, the project plan becomes an index that points to it. Section 3 of NASA's project plan template, on project control plans, has 29 subsections, including the Risk Management Plan (3.3) and the Configuration Management Plan (3.16)^[2].

How to do it in Planitude#

Build the schedule in the Gantt chart with links and milestones, and set the project deadline so the expected finish is checked against it. To skip the blank page, start from one of the 13 templates, which come with links and milestones already set; an event and an office move are among them. A project of your own can be saved as a template too.

Check the result in the Summary tab. It compares the expected finish with the deadline or the baseline and shows planned against actual progress, with the milestones due in the next 14 days in their own list. Planitude saves the baseline automatically at the first progress update, so delays are measured against the original dates. If the schedule already exists in Microsoft Project, import the .mpp file.

Planitude has no plan document. Keep the exclusions and the change rule in a shared document and paste its link into the notes of the "venue ready" milestone, where anyone who opens the schedule will find it.

Frequently asked questions#