Guild of Project Controls: Compendium | Roles | Assessment | Certifications | Membership

Tips on using this forum..

(1) Explain your problem, don't simply post "This isn't working". What were you doing when you faced the problem? What have you tried to resolve - did you look for a solution using "Search" ? Has it happened just once or several times?

(2) It's also good to get feedback when a solution is found, return to the original post to explain how it was resolved so that more people can also use the results.

Microsoft Project and Start No Later Than Constraints Explained

No replies
Emily Foster
User offline. Last seen 2 years 3 weeks ago. Offline
Joined: 19 Aug 2011
Posts: 625
Groups: None

Ideally in forward scheduling you specify As Soon As Possible (ASAP) constraints to commence your tasks at the earliest possible dates. So is it therefore redundant to specify a Start No Later Than (SNLT) constraint on a particular task? Let’s examine this question

Tom Boyle
User offline. Last seen 3 weeks 4 days ago. Offline
Joined: 28 Nov 2006
Posts: 304
Groups: None


Applause for another well-written introduction to the concept.

Three quibbles related to emphasis:

  1. The most important issue with late constraints in MSP is that the tool automatically defaults to "Tasks will always honor their constraint dates." This is a trap waiting to snare all newcomers with experience in other tools (like P3/P6).  Your write-up suggests that the decision to turn the option off depends on the project manager's assessment of whether out-of-sequence progress can be PLANNED FOR on a case-by-case basis in the schedule. Leaving the option checked effectively turns ALL late constraints (not case-by-case) into one-sided mandatory constraints - a type that doesn't exist in P6 and (in my view) doesn't belong in a logic-driven schedule.  Turn it off.
  2. An extra reason to avoid any late constraints in MSP is that they may eventually come into conflict with the updating process that, in the absence of a true data date, sometimes requires the use of the single constraint available.  Deadlines are more suitable. 
  3. It seems you really had to dig to the bottom of the barrel in searching for a feasible use-case for the SNLT constraint.  The example given - constraining an asphalt paving task to start before a particular date to avoid winter conditions - would ordinarily be much better addressed using a dedicated weather calendar for the task.  (I don't fault you for the selection; I can't think of a reasonable example for SNLT off the top of my head.)