The waiting time is independent of any Project, Task, or Resource calendar. That is, it takes place around the clock, independent of weekends and holidays.
Create a "cure" task with a "5-day" duration and assign a 7-day x 24-hour calendar to the task.
Create a "cure" task and assign a duration of 5 "elapsed" days.
Don't create a "cure" task. Instead model the curing time as a 5-elapsed-day lag between the "place concrete" and "strip forms" tasks.
Create a "cure" task with a 5-day duration and assign a modified 7-day weekly calendar to the task.
As shown in the figures, all four techniques can be used to generate the same (early) schedule dates for the project. Which technique to use depends on a few factors.
Within MSP, a "day" is fundamentally defined according to the "hours per day" setting for the project, and any "day" entries are automatically converted to minutes using that setting. With default settings, one "day" is 8 hours (i.e. 480 minutes). This can lead to confusion when calendars are changed or assigned without taking the setting into account. For example, when a 24-hour calendar is assigned to a 3-day-duration task in a project with default (i.e. 8 hours/day) settings, then the task will finish in 24 hours (i.e. 1 calendar day). Under the same conditions, a curing time of 5 calendar days (i.e. 120 hours) would require a specified task "duration" of 120/8 = 15 days. To minimize such confusion, it is a good practice to specify durations in hours when 24-hour calendars are applied, as shown in the figure.
For most purposes, assigning an "elapsed days" duration is functionally equivalent to applying a 24-hour calendar to the task and making the necessary duration adjustments. This can reduce confusion associated with the hours per day setting. The two techniques yield identical results in the example.
Using an elapsed-lag instead of a dedicated task is functionally simple to implement, and many project schedulers routinely use this approach. Nevertheless, lags are generally discouraged or prohibited by some scheduling specifications and recommended practices for good reasons. Chiefly, lags can substantially affect schedule dates while remaining relatively invisible on typical schedule documents – this makes them easy to abuse for date-manipulation. In addition, unlike tasks, lags are not easily incorporated into external algorithms for evaluation or manipulation of project schedules – e.g. for risk simulation. This can substantially degrade the value of such algorithms.
Unfortunately, the only out-of-the-box method to ensure that the entire critical path is captured is to raise the Total Slack threshold from the default value (zero) to some number that is judged high enough to capture all the truly critical tasks. I have found such an approach unsatisfactory for a variety of reasons. In any case, the true Critical Path – i.e. the driving logical path to project completion – remains obscured.