The basic idea
Every project consists of activities that depend on each other. Some activities can only begin once others are completed. Others can run in parallel. Given all these dependencies, two questions are critical:
When can the project be completed at the earliest?
Which activities would — even with a delay of just one day — push back the end date?
The Critical Path Method (CPM) answers both questions. It calculates the earliest and latest possible dates for each activity and then identifies the chain of activities that determines the project end date. This chain is the critical path.
Step 1: Forward pass
Starting from the project start, the engine works forward through all activities and calculates when each activity can begin and end at the earliest.
For a simple chain A → B → C: B can only start once A is completed. C can only start once B is completed. The earliest end of the last activity corresponds to the earliest possible project completion.
All time calculations take the work calendar into account: nights, weekends, and public holidays are automatically skipped. An activity with a duration of 2 working days that starts on Friday afternoon therefore ends on Tuesday morning — not on Sunday.
Step 2: Backward pass
Starting from the project end date, the engine works backward to calculate when each activity must start and end at the latest without delaying the project.
The difference between the latest and earliest start of an activity is referred to as buffer time (Float or Slack). An activity with 5 days of buffer can be delayed by up to 5 days without affecting the project end date.
Step 3: Critical path
Activities without buffer time form the critical path. Any delay to such an activity delays the entire project by the same amount.
The critical path is the longest chain of mutually dependent activities from start to finish.
Dependency types
Not all relationships between activities are the same. Four types are supported:
Type | Meaning | Example |
Finish-Start (FS) | B starts after A is completed | Most common: lay foundations, then build walls |
Start-Start (SS) | B starts after A begins | Two teams start concreting at the same time |
Finish-Finish (FF) | B ends after A is completed | Inspection ends after installation is completed |
Start-Finish (SF) | B ends after A begins | Rare: handover where the old process ends as the new one begins |
All dependency types support delays (lags): an additional offset or overlap. A lag of 2 days on an FS dependency means that B starts two working days after the end of A.
Calendar
Each project has a work calendar that defines which hours and days are active. Individual activities can have their own calendars if they follow a different schedule (e.g. a subcontractor working in shifts).
All durations and delays are measured in working time, not calendar time. This means: a 5-day activity always lasts 5 actual working days — regardless of when in the week it falls.
Activity constraints
In addition to dependencies, activities can be given constraints:
Constraint | Meaning |
ASAP | Start as soon as possible (default) |
ALAP | Start as late as possible |
SNET | Start no earlier than a specific date |
SNLT | Start no later than a specific date |
FNET | Finish no earlier than a specific date |
FNLT | Finish no later than a specific date |
MSO | Must start on a specific date |
MFO | Must finish on a specific date |
Parent activities (summary tasks)
Activities can be organized hierarchically, where a parent activity groups several child activities. Such an activity has no duration of its own: it automatically spans from the earliest start to the latest end of all child activities. This corresponds to the structure of construction projects with phases, sections, and work packages.
Local critical path
The global critical path shows what determines the entire project. Sometimes, however, it is important to know: what influences this specific activity?
The local critical path answers exactly that: it traces all predecessors back and identifies the chain of activities whose delays would push this activity back. This helps understand why a particular activity or date is positioned where it is.
Conflict detection
Strict constraints can conflict with dependencies. For example, an activity with a fixed start date (MSO) can have a predecessor that finishes after that date. In such cases the schedule is not feasible, and the engine reports this instead of silently producing incorrect results.
Three types of problems are detected:
Problem | Meaning |
Negative buffer | The latest allowed start is before the earliest possible start: the plan is physically not feasible |
Violated dependency | A hard constraint (MSO or MFO) forces an activity earlier than allowed by a predecessor |
Warnings | Violated dependencies with sufficient buffer are reported as a warning |