Schedule Constraint

What it pins down

A schedule constraint ties a task's start or finish to a calendar date rather than to a predecessor relationship. The most common form is Must Start On — "this task starts on this date." Where a dependency expresses logic between tasks ("development starts after design finishes"), a constraint names a point on the calendar. Constraints split into hard ones that must hold and soft ones to satisfy when possible. Legitimate sources are dates imposed from outside the project: a contractual start, a regulatory deadline, a committed launch date.

Why it matters

The Critical Path Method computes every date from dependencies and durations. Inside that flow, when a predecessor slips, its successors follow — the schedule stays alive. A constraint is a fixed point that interrupts the flow. Used precisely where needed, it makes contractual dates visible on the schedule, and when a task is pinned earlier than its predecessor logic allows, the conflict can be measured in days. A constraint is the instrument that exposes the tension between externally given dates and internal logic.

Common misconceptions

The most common mistake is believing that pinning every date is what accurate scheduling looks like. The opposite holds: the more constraints, the less the schedule responds when predecessors slip, and the further it drifts from reality. Derive dates from dependencies wherever possible and keep constraints only for externally imposed dates. One more trap: a task with a fixed start has structurally zero float, so it looks like it sits on the Critical Path. Zero float caused by pinning and zero float caused by the path are different signals — read them separately.