# Project Schedule: [Project name]

> Schedule baseline for the project: milestones, activities with durations
> and dependencies, a gantt chart, resource loading, schedule risks and
> buffers, and the log of approved schedule changes. Based on common
> project management practice. Replace every `[bracketed]` value and every
> row marked *Example*.

<!--
Guidance: How to use this template
- Build activities from the work packages in the WBS; every activity references a
  WBS ID.
- Record dependencies explicitly (FS, SS, FF, SF with lag). A schedule without
  logic cannot show the critical path.
- Baseline once approved and keep the baseline column frozen; forecast in a separate
  column so variance is visible.
- Keep the gantt chart small (summary level); the activity table is the source.
-->

| Field | Value |
|---|---|
| Document ID | [SCH-PROJECT-001] |
| Project | [Project name] |
| Version | [0.1] |
| Baseline date | YYYY-MM-DD |
| Status date | YYYY-MM-DD |
| Owner | [@project-manager] |
| Scheduling tool | [Tool or "this document"] |
| Calendar | [5-day week, public holidays of country X] |

## 1. Scheduling approach

<!-- Guidance: Explain how the schedule was built and how it will be updated. Common mistake: no stated update rhythm, so the schedule goes stale. -->

The schedule was developed from the WBS ([WBS-001]) by defining activities per work package, sequencing them with dependency logic, estimating durations with the owners, and analysing the critical path. Durations are in working days. The project manager updates actuals and forecasts every [Friday]; the baseline changes only through approved change requests.

| Parameter | Value |
|---|---|
| Estimating method | [Three-point estimates for critical activities, expert judgement elsewhere] |
| Dependency types | FS finish-to-start, SS start-to-start, FF finish-to-finish, with lag in days |
| Project buffer | [10] working days before go-live |
| Status reporting | Biweekly status report, variance by milestone |

## 2. Milestones

<!-- Guidance: Milestones have zero duration and mark decisions or deliverable completion. Show baseline, forecast and variance. -->

The milestone table is the headline view used in status reports.

| ID | Milestone | Baseline | Forecast | Variance (days) | Status |
|---|---|---|---|---|---|
| M1 | Plan baselined | YYYY-MM-DD | YYYY-MM-DD | 0 | Achieved |
| M2 | Design approved | YYYY-MM-DD | YYYY-MM-DD | *Example:* +3 | At risk |
| M3 | UAT complete | YYYY-MM-DD | YYYY-MM-DD | [n] | [On track] |
| M4 | Go-live | YYYY-MM-DD | YYYY-MM-DD | [n] | [On track] |
| M5 | Handover to operations | YYYY-MM-DD | YYYY-MM-DD | [n] | [On track] |

## 3. Activity list

<!-- Guidance: One row per activity. Predecessors use activity IDs with type and lag, for example "A03 FS+2". Mark critical path activities. -->

Activities are listed with their WBS reference, duration, dependencies and owner.

| ID | Activity | WBS | Duration (d) | Predecessors | Start | Finish | Owner | Critical |
|---|---|---|---|---|---|---|---|---|
| A01 | *Example:* Current-state workshops | 1.2.1 | 10 | M1 FS | YYYY-MM-DD | YYYY-MM-DD | [@ba] | Yes |
| A02 | *Example:* Target process design | 1.2.2 | 15 | A01 FS | YYYY-MM-DD | YYYY-MM-DD | [@ba] | Yes |
| A03 | *Example:* Vendor selection | 1.3 | 25 | M1 FS | YYYY-MM-DD | YYYY-MM-DD | [@procurement] | No |
| A04 | *Example:* Front-end build | 1.3.1 | 35 | A02 FS, A03 FS | YYYY-MM-DD | YYYY-MM-DD | [@vendor-lead] | Yes |
| A05 | *Example:* Integration build | 1.3.2 | 30 | A04 SS+10 | YYYY-MM-DD | YYYY-MM-DD | [@tech-lead] | No |
| A06 | *Example:* Training material development | 1.4.1 | 20 | A02 FS | YYYY-MM-DD | YYYY-MM-DD | [@change-lead] | No |
| A07 | *Example:* User acceptance testing | 1.3.3 | 15 | A04 FS, A05 FS | YYYY-MM-DD | YYYY-MM-DD | [@test-lead] | Yes |
| A08 | *Example:* Staff training delivery | 1.4.1 | 15 | A06 FS, A07 SS+5 | YYYY-MM-DD | YYYY-MM-DD | [@change-lead] | No |
| A09 | *Example:* Production release | 1.5.1 | 3 | A07 FS, A08 FF | YYYY-MM-DD | YYYY-MM-DD | [@ops-lead] | Yes |

## 4. Gantt chart

<!-- Guidance: Keep sections aligned with WBS level 2. Use the "crit" tag for critical path tasks. -->

The chart shows the baseline schedule by workstream; critical path activities are highlighted.

```mermaid
gantt
  title Baseline schedule
  dateFormat YYYY-MM-DD
  excludes weekends
  section Process design
  Current-state workshops   :crit, a01, 2027-02-01, 10d
  Target process design     :crit, a02, after a01, 15d
  section Platform
  Vendor selection          :a03, 2027-02-01, 25d
  Front-end build           :crit, a04, after a02 a03, 35d
  Integration build         :a05, after a02, 30d
  UAT                       :crit, a07, after a04, 15d
  section Change
  Training materials        :a06, after a02, 20d
  Training delivery         :a08, after a07, 15d
  section Deployment
  Production release        :crit, a09, after a07, 3d
  Go-live                   :milestone, m4, after a09, 0d
```

## 5. Critical path

<!-- Guidance: Name the critical path and its total float. Explain what would happen if a critical activity slips. -->

The critical path runs A01, A02, A04, A07, A09 to M4, with a total duration of [78] working days and zero float. Any slip on these activities moves go-live unless absorbed by the project buffer.

Near-critical paths (float of [5] days or less): [A05 Integration build, float 5 days]. These are monitored weekly alongside the critical path.

## 6. Resource loading

<!-- Guidance: Check that the schedule is achievable with the people available. Overallocation is a schedule risk. -->

Resource demand per role and month is compared with availability; overallocations are resolved by levelling or by adding capacity.

| Role | Month 1 | Month 2 | Month 3 | Month 4 | Available FTE | Overallocated |
|---|---|---|---|---|---|---|
| *Example:* Business analyst | 1.0 | 1.0 | 0.5 | 0.2 | 1.0 | No |
| *Example:* Developer | 0 | 2.0 | 3.5 | 2.0 | 3.0 | Month 3 (+0.5) |
| *Example:* Tester | 0 | 0.5 | 1.0 | 2.0 | 1.5 | Month 4 (+0.5) |
| [Role] | [x] | [x] | [x] | [x] | [x] | [Yes/No] |

Levelling actions: [for example, shift A05 start by 5 days within its float; request 0.5 FTE tester from QA pool for month 4].

## 7. Schedule risks and buffers

<!-- Guidance: List risks that specifically threaten dates and how buffer is held and consumed. Link to the RAID log. -->

The following risks could delay milestones; they are also recorded in the RAID log.

| Risk ID | Risk | Affected activities | Exposure (days) | Response |
|---|---|---|---|---|
| RSK-003 | *Example:* Vendor team ramps up late | A04, A05 | 10 | Contract clause for named team; weekly staffing check |
| RSK-009 | *Example:* UAT testers unavailable during month-end | A07 | 5 | Book testers now; avoid month-end week |
| [ID] | [Risk] | [IDs] | [n] | [Response] |

Buffer policy: a project buffer of [10] working days sits before M4. Buffer consumption is reported as a percentage; more than [50%] consumed before UAT starts triggers a recovery plan.

$$\text{Buffer consumed} = \frac{\text{Days of buffer used}}{\text{Total buffer days}} \times 100\%$$

## 8. Schedule change log

<!-- Guidance: Record every change to the baseline with its approval reference. Forecast changes do not need an entry. -->

Approved changes to the schedule baseline are recorded below.

| Date | Change | Milestones affected | Days | Change request | Approved by |
|---|---|---|---|---|---|
| YYYY-MM-DD | *Example:* Added accessibility audit before UAT | M3, M4 | +5 | CR-004 | [@sponsor] |
| YYYY-MM-DD | [Change] | [IDs] | [n] | [CR-xxx] | [@name] |

## Standard and licence note

Based on common project management practice for schedule development,
critical path analysis and schedule control. This template is original
text written for this collection. Template licence: MIT.