Hard constraints are date constraints on schedule activities that may cause them to violate activity dependency relationships, i.e. the network logic. Still limited application of hard constraints is acceptable according to the Defense Contract Management Agency (DCMA) 14-point assessment.
The DCMA 14-point assessment was developed to raise the standard and quality of schedules; particularly those used as part on an integrated Earned Value Management system. Quality schedules meet or exceed the assessment, and have a higher probability for meeting project goals.
The DCMA 14-point assessment recommends the limited use of hard constraints. DCMA 14-point guidelines say they should encompass no more than 5% of incomplete activities in the schedule. This actually is quite generous (or flexible) for the DCMA 14-point assessment. I thought they would have been completely discouraged, in much the same way that negative lags (leads) are discouraged by the guidelines.
In the following blog Why You Should Avoid Mandatory Activity Constraints, we go into detail as to why hard constraints or mandatory activity constraints should be avoided at all costs.
Still, as mentioned, limited application of hard constraints is acceptable according to the DCMA 14-point assessment.
This article discusses the DCMA hard constraints assessment as a monitor for the quality of a schedule.
Schedule activities describe the work required to produce the deliverables, which are the whole purpose for the project. These deliverable producing activities or tasks have relationships that define the interaction between them. Tasks may also have constraints that provide further definition and restraint. These constraints are restrictions placed on the activities to define important external dates in the life of the project.
Activity relationships, i.e. the cause-and-effect dependencies between activities, are defined using the precedence diagram, which is displayed in Figure 1.
Note the line connecting the two tasks defines the relationship or interaction between them. Figure 2 displays the most common dependency, finish to start (FS), where the predecessor cause (task A) must be completely done before commencing the successor effect (task B).
Schedules that have these or similar driving dependencies are called dynamic, as any changes in durations or any progress updates automatically propagate through the schedule. Thus, activity dates for the entire schedule are automatically updated, accordingly, when you have a dynamic schedule.
Constraints, as mentioned above, are date restrictions placed on tasks, in addition to relationships. The intent of constraints is to provide further task definition to better describe the true narrative of the schedule. The main issue with constraints is that they make your schedule static, i.e. unable to automatically propagate changes and updates.
Here’s another thought on why constraints can be problematic: constraints can place an activity on a date that is not supported, or even possible through proper application of logic. This begs the question, “how is this date going to be achieved if the logic of the can’t get put it there?”. In short, the customer doesn’t believe it and loses faith in your schedule’s integrity. Additionally, constraints are either soft or hard. Hard constraints are unique and problematic in that the constraint date takes precedence over the task relationship. Many times this means that the task dependency relationship is violated in order to honor the constraint date.
Let’s investigate. In Figure 3 we have a Microsoft Project schedule with FS activity relationships and as soon as possible (ASAP) soft constraints.
ASAP and as late as possible (ALAP) constraint types are both considered soft, and have no constraint date assignments. ASAP and ALAP constraints simply shift an activity, accordingly, within the activities available total slack. Total slack or total float (in days) is the period of time that an activity can postpone without delaying a constraint date or the entire schedule. Activities that have a total float of zero cannot be delayed at all or the project comes in late. Negative values of total float on activities mean that these tasks are already late, and causing project schedule delays.
Yes, you know you have a problem, if any of your activities are displaying negative total float. Note that ASAP and ALAP soft constraints will not generate negative total float. Other soft constraints, however, may result in a negative total float value. This may also depend on your scheduling software.
In Figure 4 we insert a start no earlier than (SNET) soft constraint in our Microsoft Project schedule.
Note that task D is shifted right to start on the constraint date. Great! So activity D was shifted right to start on the constraint date, and network logic was not violated. This is what we want. Figure 5 is the same project, but the soft constraint is replaced with a start no later than (SNLT) hard constraint.
The SNLT constraint date is January 16, 2017. The schedule meets this hard constraint date, but in doing so it had to violate network logic, i.e. dependency relationships. Note on the Gantt chart that activity D starts before the completion of both tasks B and C, which is a violation of the FS relationship between task D and these predecessor tasks.
So in order to honor the hard constraint date on activity D the schedule violated the FS relationships with task D’s predecessors. The one saving grace in Microsoft Project is that the total slack column in the task table displays negative values, which is your clue that something with the schedule is not quite right.
Hard constraints come in different flavors depending on your schedule software, most notably Microsoft Project and Primavera P6. In Microsoft Project there are four hard constraints that may violate schedule logic: Must Start On (MSO), Must Finish On (MFO), SNLT, and Finish No Later Than (FNLT). All these constraints may violate the predecessor/successor relationship in the precedence diagram. Depending on the constraint date, all these constraints may display the successor on the Gantt chart occurring before the start or completion of the predecessor. This does not make sense, in particular, if you have a FS relationship between the two activities. In the FS relationship, the predecessor must completely finish before you can commence the successor. The above listed Microsoft Project hard constraints may violate this FS relationship, so the FS relationship successor actually comes before the completion of the predecessor.
In Primavera P6 Professional there are only two constraints that may violate schedule logic: mandatory start (MS) and mandatory finish (MF). The start on (SO), finish on (FO), start on or before (SOOB), and the finish on or before (FOOB) constraints will not violate network logic, but may display negative values for total float in the activities table. Again, whether you are dealing with a soft or hard constraint, negative total float values are your clue that your schedule is falling behind.
The hard constraint disregard and violation of the Gantt chart dependency logic breeds confusion when it comes to the start and finish of a project phase or even the end of the entire project. This is why hard constraints should be limited to no more than 5% of the total number of incomplete tasks, according to the DCMA hard constraints assessment.
So hard constraints should be few in number, and should really include a note of explanation. The DCMA counts on your knowledge of total float to understand that negative total float is your warning that your constraint is causing the schedule to go amiss.
It is possible in Microsoft Project to un-toggle the schedule option ‘tasks will always honor their constraint dates’, as per Figure 6.
If you un-toggle this setting then Microsoft Project will not breach and disregard task relationships on the Gantt chart, and will still display negative values for total slack in the task table. Figure 7 is our SNLT constrained schedule with this toggle setting off.
In Figure 7 there are no Gantt chart network logic violations, and we note the negative total slack and additional warning that the task starts after the constraint date. Toggling off ‘tasks will always honor their constraint dates’ appears to be our solution. But in reference to the DCMA 14-point assessment, we assume that this toggle is on when the assessment reviews hard constraints. So Microsoft Project hard constraints, as well as Primavera P6 hard constraints, remain an issue for DCMA.
Constraints, in addition to relationships, help define the true story of the schedule. Constraints are either soft or hard. Soft constraints will not infringe network logic. Hard constraints, however, may violate task dependencies. This is the main reason that hard constraints in the DCMA assessment are limited to 5% of uncompleted activities.
You want your schedule to have an unbroken flow of logic from start to end. Hard constraints interrupt and break that logic and cause confusion, particularly, on the Gantt chart. DCMA understands this possible unfavorable impact of hard constraints, and limits their use accordingly. The DCMA hard constraints assessment, however, is not judicious or cautious enough though. Constraints of any type, both soft and hard, should be limited as they render a schedule static, i.e. inflexible to changes and updates.
Yes, the DCMA hard constraints assessment helps determine the quality of schedule, but it does not go far enough in ensuring a logical dynamic schedule. Consider the DCMA hard constraints assessment as a bare minimum quality control restraint on the use of activity constraints.