HKSM

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.