When is it more appropriate to use a constraint vs lag time and vice versa? There are some situations in which it is not completely clear to me which one should I use.
Assumption: you're asking about Microsoft Project and not using the term "constraint" in a more generic way. If that assumption is correct then Microsoft's support article defines the various constraints available in Project. Constraints introduce rules that limit when MS Project will allow tasks to begin or end. In some situations, constraints can increase the accuracy with which a project task network models a real-world process. For example, a start no earlier than constraint can be used to model the beginning of a phase of work that's earliest possible start date is restricted in real life by a law or regulation. For convenience, here are the provided constraints as of 5/18/2015:
- As late as possible
- As soon as possible
- Finish no earlier than
- Finish no later than
- Must finish on
- Must start on
- Start no earlier than
- Start no later than
Microsoft Project is most useful when a project analyst uses the tool in automatic scheduling mode. This mode uses available task information like dependencies, and resources to calculate and forecast when tasks will be in work and completed. Microsoft explains how Project calculates automatic scheduling. Task constraints can mess up automatic scheduling (more on that later).
Personally, when constructing activity networks I try to limit my use of constraints to zero duration milestones with fixed completion dates, or the "must finish on" constraint. It can be convenient to collect all such milestones in a top-level task group. In order for zero day milestones to be useful, they must be linked to predecessor tasks that have a duration. With this structure in place, as task durations are updated Project will be able to recalculate the activity network and signal the project analyst which milestones are forecasting early, on time, and late finishes.
As a more concrete example, consider the following "Sandwich Project":
- Make sandwich
- Cut sandwich in half
- Serve Paul half
- Serve Bob half
- Eat (Paul)
- Eat (Bob)
- Bus tables
The following are the task relationships for this project:
- 1 [fs] 2
- 2 [fs] 3
- 2 [fs] 4
- 3 [fs] 5
- 4 [fs] 6
- 5 [fs] 7
- 6 [fs] 7
Let's introduce three milestones with constrained dates:
- Made [must finish on 1/1/2016]
- Eaten [must finish on 1/2/2016]
- Cleaned up [must finish on 1/3/2016]
These milestones can be set to a duration of 0d and can be linked to the appropriate predecessors:
- 2 [fs] Made
- 5 [fs] Eaten
- 6 [fs] Eaten
- 7 [fs] Cleaned up
With task dependencies established, as the durations and progress of the tasks and the overall project start date are adjusted the milestone completion dates will be shown to be early, on time, or late. Ideally, the only fixed date that will need to be manually entered (other than the zero day milestones) will be the project start date.
Here is a nice post explaining common issues that arise when constraints are applied. Note, the post references Project 2007 and may be outdated. I agree with the post's author that it's generally a good idea to avoid setting manual constraints. MS Project is most powerful when automatic scheduling is calculating and signaling project performance.
Lag provide a way to insert delays between tasks.
...successor tasks that can start before their predecessor tasks are finished, and other successor tasks that cannot be started until after a delay that follows the conclusion of their predecessor tasks (Microsoft Support Doc)
A lag can be useful as a way for a project analyst to model durations that don't consume project resources or that are outside the control of the project team. Using the "Sandwich Project" example again, if Paul and Bob are customers in a restaurant then they aren't part of the restaurant staff and may not be under the authority of the project manager and it can be useful to model the "Eat" tasks as a 90 minute delay between the "Serve" tasks and "Bus tables" task.
Lags can be useful to model situations like mandatory review periods in government processes where a government office will review a form submitted by a contractor in 5 business days. Lags can also be useful to model physical constraints like the drying time for paint or the curing time for a chemical adhesive. Leads allow tasks to start before a predecessor finishes. I don't recommend using Leads. Usually, I find a Lead signals insufficient breakdown of the task network by a project analyst and recommend breaking work into smaller pieces that can be correctly modeled using finish-to-start relationships. However, a Lead may be useful as a simplification in project plans requiring less precision. This article offers further examples and discussion of lead and lag time.