Constraint Breaking Logic
SmartPM's quality metric, Constraint Breaking Logic, flags a subtle but consequential scheduling problem: activities with hard constraints (Mandatory Start or Mandatory Finish) whose constrained date falls earlier than the schedule's logic allows.
What the Metric Detects
When an activity carries a hard constraint, the scheduling tool is being told to hold that activity to a fixed date, no matter what. But if the activity's predecessors don't finish in time to support that date, a conflict is created: the logic says the activity can't start (or finish) until later, while the constraint insists on an earlier date.
Tools like Primavera P6 and Microsoft Project resolve this conflict in favor of the constraint — they honor the mandatory date and effectively break the logic to do so. The activity shows the constrained date even though its predecessor relationships say that date isn't achievable.
Constraint Breaking Logic identifies every activity in your schedule where this is happening, so you can see exactly where dates are being driven by constraints rather than by the plan itself.
Why This Matters: Date Discrepancies Between Tools
SmartPM runs its own CPM engine on every schedule it imports, and it takes the opposite approach: logic is processed over constraints. If the network logic doesn't allow an activity to hit its mandatory date, SmartPM ignores the constraint and schedules the activity where the logic places it.
This is a deliberate design decision. Logic reflects the actual sequence of work, while a hard constraint that contradicts it reflects a date someone typed in. But it means that when a schedule contains constraint-breaking logic, you may see end date discrepancies between SmartPM and your native scheduling tool.
P6 or MS Project will report the constrained (earlier) dates; SmartPM will report the logic-driven (later) dates. Neither tool is malfunctioning — they're resolving the same contradiction differently. The discrepancy itself is the signal that your schedule contains dates that aren't logically supported.
Why Hard Constraints Are a Problem
-
Hard constraints undermine the core value of a CPM schedule. A few reasons to avoid them:
They mask real delays. If a milestone carries a Mandatory Finish, the schedule will show it hitting that date even as upstream work slips. The delay is still happening — it's just invisible until it's too late to mitigate.
-
They break float calculations. Constraint-breaking logic frequently produces negative float or distorted float values across entire paths, making it impossible to trust the critical path or prioritize work correctly.
-
They disable the schedule's forecasting ability. A CPM schedule exists to answer the question "when will this finish, given everything we know?" A hard constraint replaces that answer with a fixed assertion, regardless of whether the plan supports it.
-
They create false confidence. Stakeholders reading the schedule see dates being met on paper while the underlying logic tells a different story.
Best Practices
- Let logic drive dates. If an activity must occur at a certain time, model the reason — the predecessor relationships, the resource availability, the external dependency — rather than pinning the date.
- If a constraint is genuinely needed, use a soft constraint. "Start No Earlier Than" or "Finish No Later Than" constraints influence the schedule without overriding logic, and they surface conflicts as negative float instead of hiding them.
- Reserve constraints for true external fixed points — permit dates, contractual access dates, seasonal restrictions — and document the justification for each one.
- Treat every Constraint Breaking Logic flag as an action item. Either the logic is wrong and should be corrected, or the constrained date isn't achievable and the plan needs to change. Both are conversations worth having now rather than at the end of the job.