The difference between hard vs soft constraints is how severely each one restricts a schedule’s response to network logic. In a forward-scheduled network, a soft constraint prevents an activity from starting or finishing too early but still allows it to slip. A hard constraint prevents late movement or locks the activity to a specific date, which can override logic and distort float.
However, the terminology is not universal. The U.S. Government Accountability Office (GAO), Microsoft Project, and Deltek Open Plan classify or name constraints differently. Therefore, schedulers should evaluate what a constraint does to early dates, late dates, and logic rather than relying only on its label.
Hard vs Soft Constraints at a Glance
Most Integrated Master Schedules (IMSs) use forward scheduling. Activities start as soon as their logic, calendars, status, and approved date restrictions allow. Under that convention, the GAO Schedule Assessment Guide separates common date constraints as follows:
- Soft constraints: Start No Earlier Than (SNET) and Finish No Earlier Than (FNET).
- Hard constraints: Start No Later Than (SNLT), Finish No Later Than (FNLT), Must Start On (MSO), and Must Finish On (MFO).
A soft constraint creates a one-sided boundary. For example, an SNET constraint prevents an activity from starting before June 10. If its predecessor finishes on June 15, the activity can still move to June 15.
A hard constraint restricts movement in the direction that usually concerns management: schedule delay. An FNLT constraint may force late dates against a required finish date, while an MFO constraint anchors the finish to one date regardless of predecessor performance.
As Soon As Possible (ASAP) is normally the default for an automatically scheduled task in a forward-scheduled network. It does not impose a separate calendar date. Instead, logic and calendars calculate the activity’s position.
The Practical Differences Between Hard and Soft Constraints
Response to predecessor delays
A soft SNET or FNET constraint still permits predecessor delays to move the activity later. Therefore, the schedule can continue forecasting the consequence of late work.
Hard constraints may prevent or complicate that response. Mandatory constraints are especially restrictive because they can hold an activity on its assigned date even when the predecessor logic indicates that the date is no longer feasible.
Effect on total float
Constraints can change the dates used during the forward or backward pass. As a result, they can reduce, eliminate, create, or isolate total float. A no-later-than date may also generate negative float when the logic-driven forecast exceeds the required date.
For more detail on the calculation and interpretation, see what total float means in project scheduling and the related explanation of negative float and its common causes.
Effect on critical path analysis
The critical path should reveal the longest driving sequence through the remaining network. However, excessive constraints can produce constraint-driven criticality instead. They may also obscure the predecessor that actually controls an activity.
When an activity appears critical, first determine whether logic, a calendar, status, or a date restriction drives it. The distinction matters because a date-constrained task may not identify the work sequence management must accelerate. See how to identify a driving predecessor for a closer look at that analysis.
Effect on schedule risk analysis
A Schedule Risk Analysis (SRA) depends on activities responding dynamically as sampled durations change. Constraints restrict that movement. Mandatory dates can be particularly damaging because a simulated predecessor delay may not propagate through the network as expected.
The NASA Schedule Management Handbook recommends minimal constraint use and notes that constraints can affect float and critical path calculations. Soft constraints are usually less disruptive than mandatory dates, but they still need a valid planning basis.
Why Constraint Terminology Varies by Scheduling Tool
The phrase “hard constraint” does not always identify the same set of fields. Before applying a schedule-health rule, confirm the definition used by the customer, assessment tool, and scheduling application.
Microsoft Project
Microsoft describes constraints as flexible, semi-flexible, or inflexible:
- Flexible: ASAP and As Late As Possible (ALAP).
- Semi-flexible: SNET, FNET, SNLT, and FNLT.
- Inflexible: MSO and MFO.
Therefore, Microsoft groups SNET and FNLT together as semi-flexible even though GAO’s forward-scheduling convention calls SNET soft and FNLT hard. Neither description is necessarily incorrect. They use different classification systems.
Microsoft Project users should also avoid typing dates directly into the Start or Finish fields merely to position Gantt bars. For automatically scheduled tasks, Project can apply a date constraint based on that entry. Instead, build the network with durations, calendars, and dependencies so the scheduling engine calculates forecast dates.
Deltek Open Plan
Deltek Open Plan uses target dates to restrict calculated activity dates. Its target types include Not Earlier Than, Not Later Than, On Target, and Fixed Target.
A Fixed Target is the most restrictive because it sets early and late dates equal to the target. By comparison, a Not Earlier Than or Not Later Than target affects one side of the calculation. Deltek also advises using target dates sparingly because extensive use can distort float patterns and make network analysis harder.
When exchanging schedule files between tools, compare the imported behavior as well as the field name. A constraint may map to a different type or produce different float results after conversion.
When a Soft Constraint May Be Appropriate
A soft constraint can represent a real external condition that logic and calendars cannot model adequately. Examples include:
- A government-furnished item cannot arrive before an externally supplied date.
- A test facility will not become available until a confirmed opening date.
- Work cannot begin before a funding, access, or regulatory window opens.
- A supplier has provided an earliest credible delivery date, but the detailed supplier network is unavailable.
First, consider whether an external milestone, resource calendar, or explicit predecessor activity would model the condition more clearly. For example, a facility shutdown normally belongs in a calendar. An equipment delivery may be better represented by a milestone linked to the using activity.
If a soft constraint remains necessary, document its source, rationale, owner, and review date. Otherwise, an outdated assumption can continue controlling the IMS long after the external condition changes.
How to Represent a Required Completion Date
A contractual delivery date is a real management commitment. However, that does not automatically mean the delivery milestone should receive an MFO constraint.
Unless the contract, applicable data item, or customer direction specifies a particular implementation, the scheduler should preserve a logic-driven forecast. Contractual requirements vary by agency, contract, tailoring, and program. A scheduling convention does not become a contractual requirement merely because it appears in an assessment guide.
In Microsoft Project, a deadline can monitor a required completion date without locking the task to that date. Microsoft explains that the Deadline field can display an indicator and affect total slack while allowing logic to calculate the forecast finish.
Other scheduling tools may use a finish target, project completion constraint, or contractual milestone calendar. Whatever method applies, the schedule should show both the requirement and the current logic-driven forecast. If the forecast misses the requirement, management needs visible variance or negative float rather than an artificially compliant date.
Fictional Program Example
Consider the fictional Northstar Sensor Upgrade program. The team must complete system acceptance by December 18, 2027. A government-furnished test set is expected to become available on October 4.
The scheduler initially applies an MSO constraint of October 4 to “Begin System Qualification” and an MFO constraint of December 18 to “System Acceptance Complete.” Both milestones remain fixed when an upstream software release slips by eight working days. The Gantt chart still displays the required acceptance date, but the network no longer provides a credible forecast.
The scheduler revises the model. First, the team adds a “Government Test Set Available” milestone and links it to qualification testing. If the external delivery lacks enough supporting detail, the scheduler applies and documents an SNET date to that availability milestone.
Next, the scheduler removes the MFO constraint from system acceptance. The December 18 commitment becomes a deadline or equivalent completion target. After recalculation, the network forecasts acceptance on December 30 and shows the resulting schedule pressure.
Management can now see the actual problem. The driving path runs through software integration, regression testing, and system qualification. The team can evaluate recovery actions against the real path instead of managing to a milestone pinned to an impossible date.
A Constraint Review Method for Schedulers
- Inventory every constraint. Display activity ID, description, constraint type, constraint date, total float, predecessors, successors, and responsible organization.
- Classify the behavior. Determine whether the field restricts early movement, late movement, or both. Do not rely solely on the software label.
- Verify the rationale. Identify the external event, contract requirement, management decision, or planning assumption behind the date.
- Test the schedule without it. In a controlled copy, remove the constraint and recalculate. Review changes to dates, float, and the critical path.
- Replace it when possible. Use network logic, a milestone, a resource or task calendar, or a documented deadline if those methods model the condition more accurately.
- Review negative float. Confirm which required date creates it and trace the driving path to that date.
- Document retained constraints. Record the justification and approval basis in the schedule narrative, activity notes, or program scheduling procedure.
This review should form part of routine IMS critical path analysis, not just a cleanup exercise before customer delivery.
Common Constraint Mistakes
- Using constraints to draw the desired schedule. A polished Gantt chart is not necessarily a valid network model.
- Pinning every contractual milestone. This can hide a missed forecast instead of quantifying the gap to the requirement.
- Assuming every one-sided constraint is soft. Under GAO’s forward-scheduling convention, SNLT and FNLT are hard because they restrict late movement.
- Treating soft constraints as harmless. SNET and FNET can still consume float, affect path calculations, and interfere with an SRA.
- Using ALAP in a forward-scheduled execution IMS. ALAP can consume available float and delay work without an operational reason.
- Entering dates directly in Microsoft Project. Manual date entry can introduce constraints that remain unnoticed during later status cycles.
- Treating a health-check threshold as permission. Passing a numerical metric does not prove that the remaining constraints are valid or contractually acceptable.
- Ignoring schedule direction. A constraint’s practical effect can change when a project uses backward rather than forward scheduling.
Why Constraints Matter to EVMS and Program Control
An Earned Value Management System (EVMS) depends on a credible relationship among scope, schedule, and budget. Constraints do not directly change earned value calculations. However, they can weaken the schedule forecasts that Control Account Managers (CAMs) and program managers use to interpret performance and develop corrective actions.
For example, a hard-constrained milestone may continue displaying the baseline commitment after its driving work has slipped. The Schedule Performance Index (SPI) might show historical performance, but the constrained network may fail to communicate the likely completion date. Therefore, the team loses an important forward-looking indicator.
Proposal teams face a similar risk. A constrained proposal schedule can appear compliant while hiding inadequate time for design, procurement, integration, or test. Instead, proposal schedulers should model the execution approach, identify external assumptions, and show how the network supports the proposed delivery date.
Frequently Asked Questions
Are hard constraints prohibited in an IMS?
Not universally. Requirements depend on the contract, agency guidance, data item, and program procedures. Nevertheless, accepted schedule-management guidance recommends minimizing hard constraints because they can override logic and distort analysis.
Is Start No Earlier Than always a soft constraint?
It is normally treated as soft in a forward-scheduled network because it prevents early movement while allowing delay. However, terminology varies by tool and schedule direction.
Should a contractual milestone use Must Finish On?
Usually, a logic-driven milestone paired with a deadline or appropriate completion target provides better management visibility. Use MFO only when the implementation is required or its behavior accurately represents the approved scheduling method.
Can soft constraints affect the critical path?
Yes. A soft constraint can delay an activity’s early dates, consume float, and alter which sequence appears critical. It is less restrictive than a mandatory date, but it still affects network calculations.
The Bottom Line
Soft constraints restrict one side of an activity’s movement while preserving the schedule’s ability to forecast delay. Hard constraints restrict late movement or lock an activity to a date, which can override logic and distort float, critical path, and risk results.
Use logic and calendars first. When a date restriction is necessary, select the least restrictive method that represents the real condition. Then document it, test its effect, and make sure the IMS still shows management what the program is actually forecast to achieve.