A project calendar identifies the working days and shifts that are available for scheduled activities. It is the rule set that turns a duration into dates. On its own, “five days of work” is just a number. Run it through a project calendar and the schedule model knows the work starts Monday, skips the public holiday on Wednesday, and finishes the following Tuesday.
The calendar’s whole job is to separate time that is available for scheduled work from time that is not. PMBOK 8 states that this distinction can be drawn in days or in parts of days, which is what makes shift work, half-day Fridays and round-the-clock commissioning possible inside a single schedule model.
Project calendar vs. resource calendar
These two get confused constantly, and mixing them up produces schedules that look plausible and are wrong.
| Project calendar | Resource calendar | |
|---|---|---|
| Answers | When can this work be done at all? | When is this specific resource available? |
| Applies to | The project, or a defined set of activities | One person, crew, machine or facility |
| Contains | Working days, shifts, non-working periods | Business hours, weekends, public holidays, leave, assignment windows |
| Classic mistake | Forgetting the annual shutdown week | Assuming a shared specialist is available full time |
Both constrain the same activity. Work can only progress on a day that is a working day on the project calendar and a day on which the assigned resource calendar shows availability. Whichever is more restrictive wins, and that is usually the resource.
Why a project may need more than one
PMBOK 8 says plainly that a schedule model may require more than one project calendar so that some activities can run on different work periods. In practice that shows up as:
- Different work patterns. Engineering runs Monday to Friday while commissioning runs three shifts, seven days.
- Different locations. A second site in another country has its own public holidays, and those holidays are not negotiable.
- Work that ignores humans. Concrete curing, soak tests and regulatory waiting periods run on a 7-day calendar because chemistry and authorities do not take weekends off. Modelling these on the office calendar quietly inflates the schedule.
Which calendar an activity is assigned to is one of its activity attributes — PMBOK 8 names it explicitly in that list, next to the place where the work is performed and the type of effort involved.
In practice
- Set the calendar before you commit to dates. Every date in the project schedule is computed against it. Changing the calendar after the schedule baseline is approved moves dates you have already promised.
- Non-working time is a decision, not a fact. Shutdown weeks, code freezes, month-end blackouts and change-freeze windows only exist in the schedule if somebody puts them in the calendar.
- Check the critical path after every calendar change. The critical path method computes over calendar time, so adding a holiday can shift which path is critical and how much total float the others have.
- Keep effort and duration apart. The calendar converts effort into duration. Ten person-days of work on a two-shift calendar is not the same elapsed time as ten person-days on a one-shift calendar, and the estimate itself has not changed.
- Expect updates. PMBOK 8 notes that project calendars may be updated. Newly announced holidays, an agreed weekend push or a change of shift pattern all belong in the calendar rather than in a fudged duration.
- Reuse the last one. Project calendars from previous projects are listed among the organizational process assets a new project can draw on. A calendar that already has the right holidays and shutdowns in it saves a whole class of avoidable errors.
Project calendar in PMBOK 8
The term survived the restructuring of the eighth edition intact, and it appears in three distinct places.
- Glossary entry. “A calendar that identifies working days and shifts that are available for scheduled activities.”
- Section 4, Inputs and Outputs (p. 125). Project calendars have their own entry among the inputs and outputs, with the full description of days and parts of days, multiple calendars, and updates.
- Two processes. Project calendars are an output of Develop Schedule (Figure 2-22), alongside the schedule baseline, the project schedule and schedule data. They come back as a project document input to Monitor and Control Schedule (Figure 2-24), which is where a stale calendar starts producing misleading variance.
One wording detail worth noting: the guide uses the plural, “project calendars”, in its heading and its process figures. That is deliberate. The eighth edition treats several calendars per project as the normal case, not the exception.
FAQ
What is the difference between a project calendar and a project schedule?
The calendar is the rule set; the schedule is the result. The calendar says which days are workable. The schedule says which activity happens on which of those days. Two projects can share a calendar and have nothing else in common.
Does every project need more than one calendar?
No. One calendar is fine when everybody works the same pattern in the same place. Add a second only when a real group of activities genuinely runs on different work periods, because every extra calendar is another thing to keep current.
Who owns the project calendar?
The project manager, in practice, with the working pattern coming from the organization and from any labour agreements. The calendar is not a personal preference. If the plant does not run on Sundays, no schedule model changes that.
Do calendars matter on agile projects?
Yes, in a different form. Iteration length is fixed, so non-working days do not stretch the timebox; they reduce the capacity available inside it. A two-week iteration containing two public holidays and three days of leave has roughly 30 % less capacity, and that has to be reflected in what the team commits to.
What happens if the calendar changes mid-project?
Dates move. Recalculate the schedule, compare the result with the baseline, and if the change pushes past an approved milestone, raise a change request rather than absorbing the difference silently.
Is a calendar unit the same thing?
No. A calendar unit is the smallest time increment your schedule works in — typically hours, days or weeks. The calendar says which of those units are workable.
By Tom, PMP-certified since 2004. Last updated: August 2026.