1.4Constraints, Deadlines & Task Calendars
The essentials in 30 seconds
- By default, a task is “As Soon As Possible” (flexible): it follows its links, with no imposed date.
- A constraint forces a date but makes the schedule rigid: reserve it for genuinely imposed dates.
- The deadline alerts without forcing, and a task calendar handles specific hours — often the right choices.
Running mini-case — Meriem handles a date imposed by the client
Meriem's client imposes a contractual date: the structural works must be completed before the winter break. Meriem hesitates between two tools. She could set a constraint “Finish No Later Than…”, but she knows that this makes the schedule rigid and can create a conflict with the links. She first prefers a deadline on the task: a visual marker and an alert indicator if it overruns, without blocking recalculation. For the pouring task, which can only be done at night, she assigns a dedicated task calendar. Meriem remembers: “As Soon As Possible” by default, the deadline for a flexible target, the constraint only when the date is truly imposed, and the task calendar for particular hours.
Standalone case for this section: it returns in the course, the diagram, the script and the 48h challenge of section 1.4.
1. Constraints make the schedule rigid
Sometimes a task must respect a precise date: that is the role of constraints. By default, a task is “As Soon As Possible” (flexible, it follows its links). You can impose “Must Start On…”, “Start No Earlier Than…”, etc.
These constraints make the schedule rigid: use them sparingly, only when a date is genuinely imposed. Too many hard constraints prevent Project from recalculating and generate conflicts.
2. Deadline and task calendar
A more flexible alternative: the deadline. It does not force the date but displays a marker and an alert indicator if the task overruns — without blocking recalculation.
Finally, a task can have its own task calendar (e.g. work possible only at night) different from the project calendar. Clearly distinguishing constraint, deadline and task calendar allows managing dates without breaking flexibility.
3. The right tool for the right need
Practical rule: leave tasks “As Soon As Possible” whenever possible; prefer a deadline for a target date; reserve the constraint for truly imposed dates (contract, internal regulation); use a task calendar for specific hours.
When a constraint contradicts the links, Project displays a scheduling conflict: soften it or review the dependencies rather than ignoring it.
🔎 Concrete example — 🔎 Concrete example — Constraint or deadline?
Forcing vs alerting:
Constraint: “it MUST be on this date” (rigid, can create a conflict).
Deadline: “it SHOULD be finished, warn me otherwise” (flexible).
→ a task's default = “As Soon As Possible”.Result: dates managed without breaking recalculation.
Reflex: minimize hard constraints.
Section vocabulary
- Constraint
- A rule imposing a date on a task (Must Start/Finish On…, Start No Earlier Than…); it makes the schedule rigid.
Simple example: Meriem sets “Finish No Later Than…” on the structural works.
What it is not: constraining every task as a principle, until recalculation breaks.
Reflex: truly imposed date → constraint (sparingly).
- As Soon As Possible
- The default flexible constraint: the task starts as early as possible according to its links, with no imposed date.
Simple example: Meriem leaves most of her tasks “As Soon As Possible”.
What it is not: imposing a date on a task that does not need one.
Reflex: by default → “As Soon As Possible”.
- Deadline
- A target date displayed as a marker, with an alert if overrun, but which does not force scheduling.
Simple example: Meriem sets a deadline on the delivery of the client's drawings.
What it is not: using a rigid constraint where a deadline would suffice.
Reflex: target date → deadline, not constraint.
- Task calendar
- A specific calendar applied to a task (particular hours) different from the project calendar.
Simple example: Meriem assigns a night calendar to the pouring task.
What it is not: scheduling night work on the standard working calendar.
Reflex: particular hours → task calendar.
- Scheduling conflict
- A situation where an imposed constraint contradicts the logic of the links (Project alerts).
Simple example: Meriem sees a conflict: the constraint contradicts a predecessor.
What it is not: ignoring the warning and delivering an inconsistent schedule.
Reflex: conflict → soften the constraint or review the links.
In practice — In practice — Managing imposed dates and deadlines
- Check that a “normal” task is “As Soon As Possible” (flexible) — let it follow its links.
- For a truly imposed date, set a constraint (e.g. “Start No Earlier Than…”) knowing its rigidifying effect.
- Prefer a deadline when you just want an overrun alert without blocking recalculation.
- If a task has specific hours, assign it a dedicated task calendar (double-click > Advanced).
Step-by-step script — manage dates like Meriem (4 min)
1) Leave tasks “As Soon As Possible”: they follow their links. 2) For a flexible target, double-click the task and set a deadline in the Advanced tab. 3) Only for a truly imposed date, add a constraint (“Start No Earlier Than…”) knowing that it makes the schedule rigid. 4) For particular hours, assign a task calendar. 5) If Project reports a conflict, soften the constraint or review the links.
Prefer the deadline to the constraint: it alerts on overrun without preventing the schedule from recalculating.
Copy-paste template — my date requirements
Task: ___
Need: flexible date (target) / imposed date / specific hours
Tool chosen: deadline / constraint / task calendar
If constraint: type = Start No Earlier Than / Must Finish On…
Effect checked: recalculation preserved (yes / no)
Scheduling conflict: none / resolved in __Imposed date
Meriem sets a “Finish No Later Than…” constraint on the structural works, accepting the rigidifying effect.
Flexible target date
Meriem prefers a deadline on the drawing delivery: overrun alert without blocking recalculation.
Night work
Meriem assigns a task calendar to the pouring task, possible only at night.
Reported conflict
Faced with a scheduling conflict, Meriem softens the constraint or reviews the dependencies.
✓ Best practices
- Leave tasks “As Soon As Possible” by default.
- Prefer a deadline to a constraint for a target date.
- Reserve constraints for truly imposed dates.
✗ Common pitfalls
- Multiplying rigid constraints (conflicts, broken recalculation).
- Using a constraint where a deadline would suffice.
- Ignoring a scheduling conflict reported by Project.
Key takeaways
- By default, a task is “As Soon As Possible” (flexible): it follows its links.
- Constraints impose a date but make the schedule rigid: reserve them for truly imposed dates.
- The deadline alerts on overrun without forcing the date: often preferable.
- A task calendar handles specific hours different from the project calendar.
48h challenge — apply it tomorrow
Take a task with an imposed date and choose the right tool like Meriem: constraint (rigid) only if the date is truly imposed, otherwise deadline (flexible). Check that recalculation stays active. Write in one sentence why a deadline often beats a constraint.
- I distinguish constraint, deadline and task calendar.
- I know when a constraint is justified and when a deadline suffices.
- I handle specific hours with a task calendar.
Frequently asked questions
Project shows me a conflict or a constraint warning. What should I do?
It means an imposed constraint contradicts the links: for example, requiring a task to “start on the 5th” while its predecessor finishes on the 8th. Project alerts because it cannot satisfy both. Solutions: delete or soften the constraint (switch back to “As Soon As Possible”), or review the dependencies and durations upstream. Golden rule: minimize hard constraints.
Constraint or deadline: what is the real difference?
A constraint forces scheduling: it requires Project to position the task on a date, even if that creates conflicts with the links. A deadline forces nothing: it places a visual marker and triggers an alert indicator if the task finishes later, while letting the schedule recalculate. In short: the constraint says “it MUST be on this date”, the deadline says “it SHOULD be finished by this date, warn me otherwise”. In most cases, the deadline is the right choice.
What is the effect of a rigid “Must Start On…” constraint?