Santosh: Great question, but not sure how much we can do if you’ve already done your research. Anyway, always up for a challenge.
In summary, every task wants to start on the project start date, unless it is told to start on some other date. The two most common ways of constraining a task’s start date is either by using a relationship to another task (as a successor) or by a constraint.
1. The primary difference between the two is that a predecessor/successor relationship constrains the task to another task. A constraint (other than As soon as possible or As late as possible) constrains it to a specific date.
2. The two methods would be used depending on the circumstance as outlined.
3. The preferred method is to use relationships as much as possible and limit constraints (as you probably have already read). If you are managing your project schedule, project can help if you link tasks using relationships.
So that’s the short version without writing a blog or reading it out of a book. I hope that helps, but you should be able to get a much deeper explanation from a book or specific article. I believe there might even be some articles on the MPUG site that were written about this…??
Our company uses Microsoft Project Professional 2016 on PWA2016 platform. We are noticing many of our PMs are finding constraints in tasks in their schedules Are there instances where MS Project “automatically” adds constraints to tasks? IF so, what are some examples where this occurs?
MS Project will automatically create a constraint when the PM manually enters (or selects) a task start or finish date. Because the PM enters it, Project see’s that as the same as entering a constraint.
Relationships and constraints are clearly differentiated in the software. Academic articles may have added to Santosh’s confusion by including both of them as “constraints,” where some are logical (i.e. sequential constraints, relationships) and some are externally imposed (i.e. early, late, and mandatory date constraints.)
Rules (for forward scheduling only): Use activities and relationships for everything. Early constraints (i.e. SNET, FNET) typically represent missing activities and logic. They should only be used to represent events that are truly external to the scope of the project, e.g. Contract Notice to Proceed or delivery of Owner-furnished equipment. Late constraints (i.e. SNLT, FNLT) are used to represent schedule obligations/commitments, where failure has negative consequences. Use them (I prefer Deadlines) only in these cases. Mandatory constraints (MSO, MFO) represent events that are fixed in time and will never change regardless of how the project progresses. There are virtually no uses for these in logic-driven project schedules.
The critical path and other logic paths in the schedule are easily affected/corrupted by constraints, especially in MS Project.