How to Get a Job For Project Managers

Learn how to write resume and interview

Leadership for Project Managers

Learn how to lead and drive project success.

Project Management with AI

From a beginner to project management professional.

Agile Project Management and SCRUM with AI

Learn to run Scrum and Agile with AI.

Project calendars

A project calendar specifies the working and non-working days and hours that apply to the entire project or a set of activities. It guides when work can be scheduled, independent of individual resource availability.

Key Points

  • Defines default working time and non-working time for the project schedule.
  • Different from resource calendars, which reflect availability for specific people or equipment.
  • Impacts activity start and finish dates, float, and the critical path.
  • Includes exceptions such as holidays, maintenance windows, and blackout periods.
  • Essential for multi-shift, multi-time-zone, or regulated work environments.
  • Must be configured and validated before developing or baselining the schedule.

Purpose of Analysis

  • Identify the time windows when project work can and cannot occur.
  • Harmonize organizational policies, vendor hours, and regulatory restrictions into the schedule model.
  • Expose constraints and opportunities that affect sequencing, lead/lag usage, and resource planning.
  • Support realistic duration estimates and iteration or cadence planning in adaptive approaches.
  • Reduce schedule risk by preventing work from being planned during blackout periods.

Method Steps

  • Collect calendars and policies: standard workweek, holidays, labor rules, facility hours, vendor blackout periods.
  • Define project working patterns: days per week, daily work hours, shift coverage, iteration or sprint cadence.
  • List exceptions: statutory holidays, planned outages, cutover freezes, quarter-end blackout windows.
  • Align with resource calendars: identify overlaps and gaps between project-wide availability and specific resources.
  • Configure the project calendar in the scheduling tool and apply it to relevant activities and WBS areas.
  • Validate with stakeholders and key suppliers; adjust based on feedback and constraints.
  • Baseline or record the calendar configuration and establish a change control method for updates.

Inputs Needed

  • Organizational work time policy and HR guidelines.
  • Holiday lists and regional observances across team locations.
  • Labor agreements, overtime rules, and legal restrictions.
  • Facility or system maintenance windows and operational blackout periods.
  • Vendor and partner support hours and service-level commitments.
  • Time zone data and daylight saving time changes.
  • Resource calendars and stakeholder availability constraints.
  • Assumptions and constraints from the schedule management approach or agile cadence.

Outputs Produced

  • Project calendar configured in the scheduling tool and documented in schedule management artifacts.
  • Calendar exception list capturing holidays, outages, and freezes.
  • Updated schedule model with activity timing constrained by calendar availability.
  • Updates to assumptions log, risk register (e.g., blackout risks), and stakeholder communications plan.
  • Change-controlled updates to the schedule baseline when calendar changes affect dates.

Interpretation Tips

  • Use project calendars for default availability; use resource calendars for person or equipment-specific constraints.
  • Recognize that tighter calendars can lengthen durations and shift the critical path.
  • To compress schedules, consider adding shifts or redefining working time rather than padding durations.
  • For agile, align sprint, review, and release events to the project calendar and note non-working days in the team charter.
  • In global teams, plan for overlap windows and clearly mark non-overlap periods to avoid unrealistic handoffs.
  • Review and adjust for daylight saving changes and regional variations to prevent missed dependencies.

Example

A global project sets a project calendar with Monday–Friday, 8 hours per day, excluding local holidays for all delivery locations. Monthly vendor maintenance windows are marked as non-working time. When activities are scheduled, tasks do not start during the maintenance window, and handoffs are planned within a 3-hour daily overlap between regions. This prevents unrealistic overnight dependencies and avoids scheduling work during system outages.

Pitfalls

  • Confusing project calendars with resource calendars, causing misaligned availability.
  • Ignoring vendor or operations blackout windows, leading to repeated schedule slippage.
  • Failing to update calendars after policy changes, time zone shifts, or added team locations.
  • Overusing duration padding instead of configuring appropriate working time or shifts.
  • Not communicating calendar assumptions to stakeholders, creating expectation gaps.
  • Missing regulatory constraints (e.g., mandated rest periods), resulting in noncompliance risk.

PMP Example Question

A project involves teams across three time zones and monthly production blackout windows. To build a realistic schedule, what should the project manager do first?

  1. Configure only resource calendars for each team member.
  2. Define and apply a project calendar with working hours and blackout windows before sequencing activities.
  3. Add lag to all activities to account for non-working days.
  4. Increase all activity durations by a fixed percentage to cover delays.

Correct Answer: B — Define and apply a project calendar with working hours and blackout windows before sequencing activities.

Explanation: The project calendar sets default availability for all work and prevents scheduling during blackout periods. Padding durations or adding generic lag is a poor substitute and reduces schedule transparency.

AI Systems with Claude, for Scrum Masters and Project Managers

Most AI pilots in project management do not fail on the model. They fail because somebody pointed the thing at a decision instead of at a task. This course is built around that distinction, and around the work that follows once you get it right.

Seven sections, taught against one running project from the first lecture to the last. You watch a system get built, then you build the same one against your own sprint. Nothing here is a demo that works only on the example.

You finish with five working systems and you keep them. The sprint report machine turns your board export and standup notes into the report you currently write by hand. The retro intelligence system tells you what the team keeps saying, not just what it said this time. The stakeholder comms engine drafts the update in the register the audience expects. The backlog health monitor flags the quiet decay nobody has time to check for. The risk and dependency tracker follows the chains that actually bite.

Seventy-six working files ship with it, across four sections, so every system is built against real sprint data rather than material invented for a slide. Four sprints of retrospectives, board exports, standup notes, backlog and risk data.

Explore the Course


Become an AI-First Agile Leader!

HK School of Management helps you apply AI to Agile work with practical, prompt-based workflows for real-world Scrum challenges. Practical skills, tools, and guidance you can apply right away. Covered by Udemy's 30-day refund policy.

Learn More