We’ve chosen to use deadlines instead of constraints in our schedule because our customer likes to see the forecast dates move left and right. However, in files where the deadline = the last task in the schedule (which is most typical), the slack only calculates negative, not positive. After digging into this, it looks like in project information, when scheduling from the project start date, the default end date becomes the latest forecasted date in the file (which, again, typically has a deadline). So, I think what project is thinking is the slack is 0 because that’s when the project is ending, and it is not taking into account the deadline that is later than the forecast. Does that make sense or does anyone know if that is correct? If this is the case, I think the solution is to put a SNET on that task/milestone (or link the last milestone into a “due date” milestone with an SNET) to force the end date of the file to be the deadline, so slack can calculate correctly, OR use a different constraint (like Finish no later than or Must Finish On). Has anyone else looked into this, can confirm this is true, or have any other ideas for how to get slack to calculate in a project with a deadline at the end while scheduling from the start date?
Thanks for your help!
It looks like you’ve done your research and drawn the right conclusions.
This is normal behavior for the critical path method, where deadlines or other late constraints (like FNLT) on the last task only become effective (controlling the late date of the task) when the task’s early finish date slips past the constraint date. As you have suggested, it is not uncommon to apply a paired SNET constraint and Deadline to the final delivery milestone – this forces the milestone’s scheduled (early) date to equal the contract date. An alternate approach is to split the milestone into two: Forecast Delivery, which is the unconstrained terminus of the project network; and Contract Delivery, hard-constrained (MSO) to the contract date and an FS successor to the Forecast Delivery milestone. Both of these approaches create positive total slack/float throughout the rest of the project as long as the project is ahead of schedule, with slack/float turning negative when the forecast slips past the contract date. This kind of behavior is presumed in a couple of the DCMA 14-point assessment metrics.
One key outcome of using either of these approaches is that the project float (also called terminal float, which is the difference between your current forecast date and the contract date) is folded into the network float (what you see now); blurring any distinction between them. [Actually, these practices are so common that I’d guess 90 out of 100 forensic schedulers would not recognize the distinction, either.] While there is general acceptance that network float is a shared resource available to both you and your customer (and other project stakeholders), there is no such general acceptance regarding project/terminal float. In fact, some contract forms explicitly reserve terminal float to the contractor as a risk-management buffer. Depending on the applicable contract forms and terms – particularly shared-float provisions, your schedule risk may be affected. Be sure to review them.
Good luck, tom