Using Date Constraints
As noted previously, date constraints are generally used to demonstrate an external event’s effect on a schedule. However, because they prevent activities from responding dynamically to network logic, including actual progress and availability of resources, they can affect float calculations and the identification or continuity of the critical path and can mask progress or delays in the schedule. Date constraints should be minimized because they restrict the movement of activities and can cause false dates in a schedule. They can also imply a false level of criticality because of their effects on float. Moreover, constraints affect the analysis of risk in the schedule. Hard constraints can sometimes be impossible to meet, given the network’s characteristics, and can thereby result in schedules that are logically impossible to carry out.
SNET constraints are valuable when an activity cannot start any earlier than a fixed date and has no other logical dependencies. They are often used to represent the availability of cash flow or reliance on some external product. For example, a production line may not be available until an outside entity finishes producing its product. In that case, a SNET constraint would legitimately prevent scheduled activities from unrealistically starting before they should.
SNET constraints are also used to signal the receipt of some item, such as a hardware subcomponent or a government-furnished test article. However, often these conditions of supply by an outside vendor or contractor are better represented as actual activities in the schedule. For example, the receipt of a subcontractor’s hardware component is often modeled as a milestone with a SNET constraint. It may be more appropriate to model this as one activity or a sequence of activities representing the whole procurement process, starting with ordering the product and ending with its receipt.
These types of representative activities—referred to as “reference” activities or “schedule visibility” activities—are not part of the project scope and have no assigned resources, yet they can potentially affect project activities. For example, the time to produce the product should be represented by a fabrication activity. By modeling vendor or contractor production as an activity, the program office can track the high-level progress of the contractor and apply risk to the external production activity. Representing supplier, government, or subcontractor deliverables as date-constrained milestones rather than activities may understate the risk in the procurement process.
SNET constraints are also often used to delay activities in response to available resources such as labor or funding. However, this model should not be used for several reasons. First, it prevents the constrained activity from dynamically taking advantage of possible time savings being produced by predecessor activities. Second, logical dependencies should not be used to allocate resources because, typically, resource-constrained activities that are resolved with date constraints are forced to occur sequentially. This may temporarily solve a specific resource overallocation, but the sequential logic will remain even if additional resources are assigned to the activities.
Finally, perhaps the main disadvantage of applying SNET constraints to represent the availability of resources is that it requires constant manual upkeep of the schedule. Updating constraint dates on associated activities manually may be manageable in a relatively small schedule with few resources. However, large schedules with hundreds of SNET constraints representing tens or hundreds of resources will quickly become unmanageable, and the likelihood of errors will increase. If decision makers are not aware that an unnecessary SNET constraint on a low-level detail activity is preventing the activity from starting earlier, additional opportunities for time savings will be lost.
As described in Best Practice 3, resources should be assigned to activities so that their availability can drive the dates of planned activities according to resource calendars. For example, suspensions of work because of weather events are more appropriately indicated by a nonworking period in the working calendar than by date constraints. Updating resource calendars is easier to manage than manually updating hundreds of individual constraints (see case study 6).
GAO’s analysis of the Army’s Global Combat Support System found that dependencies within the schedule were generally sound, but 60 percent of the activities (or 1,360) had Start No Earlier Than (SNET) constraints. SNET constraints are considered “soft” date constraints because they allow an activity to slip into the future if their predecessor activity is delayed, but the activity cannot begin earlier than its constraint date.
Program officials stated that SNET constraints were used to manually allocate resources and coordinate data tests, which relied on coordination with outside partners. Officials further stated that individual control account managers monitor these constraints. GAO found that 87 percent of the constraints were actively affecting the start date of their activities. That is, without the constraint, it might have been possible to start the activity sooner.
Constraining over half of all activities to start on or after specific dates defeats the purpose of a dynamic scheduling tool and greatly reduces the program’s ability to take advantage of possible time savings.More information on resources and calendars is given in Best Practice 3 and Best Practice 4.
FNET constraints are used to prevent activities from ending too early. These constraints should be questioned because it is usually not clear why a manager would not want to end a task as soon as possible. Like SNET constraints, FNET constraints may be used in situations to force the allocation of resources. For example, preventing an activity from ending too soon can prevent a dedicated resource from going idle if a succeeding activity cannot employ that resource.
But also like SNET constraints, FNET constraints prevent a planned activity from taking advantage of any time savings that may be created by completing predecessor activities early. Because the FNET constraint sets the early finish date, the activity’s early start becomes dependent on its early finish and duration. In addition, total float calculations can become obscured because of the artificial early finish date. That is, there may be time to start the activity earlier than originally planned if its duration estimate grows, but this may not be obvious given its available float.
Finally, SNET and FNET date constraints that are not actively constraining an activity’s start or finish date should be removed from the schedule. In these cases, the constraints are meaningless.
The hard MSON and MFON constraints prevent activities from moving either forward or back in the plan in response to the status of predecessor activities. This includes preventing the constrained activities from taking advantage of time savings from predecessor activities. In other words, even if the constrained activity could start earlier, it will not do so according to network logic because the early and late dates are equal.
Placing a hard constraint on an activity fixes the date and immediately causes the activity to become critical. It is therefore possible to use hard constraints as a temporary working tool during schedule development to calculate total available float up to key milestones. The temporary use of hard constraints is also valuable for assessing the realism of available resources to achieve the planned activity date. For example, a hard constraint placed on an intermediate delivery milestone may show the need for an immediate and unrealistic peak of resources, shortening the predecessor durations because it is forcing the milestone to be achieved on an unrealistic date.
Hard constraints are useful for calculating the amount of float available in the schedule and, therefore, the realism of the required program finish date and available resources during schedule development. However, they may be abused if they force activities to specific dates that are determined off-line without much regard for the realism of the assumptions necessary to achieve them. It is important to note that just because an activity is constrained in a schedule, the activity is not necessarily constrained in reality. A customer-mandated date, including contractual obligations, does not constitute a legitimate reason to constrain an activity. A schedule is intended to be a dynamic, pro-active planning and risk mitigation tool that models the project and can be used to track progress toward important program milestones. Schedules with constrained dates can portray an artificial or unrealistic view of the program and begin to look more like calendars than schedules. Such unrealistic views are especially dangerous when they are translated to higher-level summary schedules for decision makers’ use.
Senior management may not be aware that key milestone dates in the summary schedules are artificially fixed and behind schedule in working-level detailed schedules. Working versions of schedules may include hard constraints to assess available float and available resources, but the baseline schedule and official status updates should not contain hard constraints. If a hard constraint cannot be avoided, it must be used judiciously and must be fully justified by referring to some controlling event outside the schedule in the schedule’s basis document.
In summary,
SNET and FNET constraints delay activity starts and finishes even if predecessor durations allow them to occur earlier. These constraints allow activities to slip if their predecessors cause them to slip—in this case, they become meaningless and should be deleted. However, their use must be justified because, in general, program management’s wanting to not start or finish an activity as soon as possible may be questionable.
Because SNLT and FNLT constraints prevent activities from slipping, their use is discouraged. They should never appear in the schedule baseline. If they are not properly justified in working schedules, they must be immediately questioned.
Because MSON and MFON constraints prevent activities not only from slipping but also from accelerating, their use is discouraged. They should never appear in the schedule baseline. If not properly justified in working schedules, they must be immediately questioned.
Many activities with date constraints are typically substitutes for logic and can signify that the schedule was not well planned and may not be feasible. In addition, constraints can cause misleading risk analysis results because they override network logic.